[OpenBSD]

[Vorige: Tabellen] [Inhoud] [Volgende: Network Address Translation]

PF: Pakketten Filteren

Inhoudsopgave

Inleiding

Pakketten filteren is het selectief doorlaten of blokkeren van gegevenspakketten naarmate ze doorheen een netwerkinterface passeren. De criteria die pf(4) gebruikt bij het inspecteren van pakketten zijn gebaseerd op de Layer 3 (IPv4 en IPv6) en Layer 4 (TCP, UDP, ICMP en ICMPv6) hoofdingen ("headers"). De vaakst gebruikte criteria zijn bron- en bestemmingsadres, bron- en bestemmingspoort, en protocol.

Filterregels specificeren de criteria waaraan een pakket moet voldoen en de resulterende actie, ofwel blokkeren ofwel passeren, die ondernomen wordt wanneer een overeenstemming gevonden wordt. Filterregels worden in na elkaar komende volgorde geëvalueerd, eerste tot laatste. Tenzij het pakket overeenstemt met een regel die het quick sleutelwoord bevat, zal het pakket geëvalueerd worden met alle filterregels alvorens de uiteindelijke actie ondernomen wordt. De laatste regel die overeenstemt is de "winnaar" en zal dicteren welke actie er met het pakket ondernomen moet worden. Er is een impliciete pass all bij het begin van een filterregelset, wat betekent dat als een pakket met geen enkele filterregel overeenstemt, de resulterende actie pass zal zijn.

Regelsyntaxis

De algemene, erg vereenvoudigde syntaxis voor filterregels is:
actie [richting] [log] [quick] [on interface] [af] [proto protocol] \
   [from src_addr [port src_port]] [to dst_addr [port dst_port]] \
   [flags tcp_flags] [state]
actie
De actie die moet ondernomen worden voor overeenstemmende pakketten, ofwel pass ofwel block. De pass actie zal het pakket terug naar de kernel sturen voor verdere verwerking terwijl de block actie zal reageren op basis van de instelling van de block-policy optie. De standaard reactie kan opgeheven worden door ofwel block drop ofwel block return te specificeren.
richting
De richting waarin het pakket beweegt op een interface, ofwel in ofwel out.
log
Specificeert dat het pakket gelogd moet worden via pflogd(8). Als de regel de keep state, modulate state of synproxy state optie specificeert, dan wordt alleen het pakket dat de toestand ("state") opricht gelogd. Om toch alle pakketten te loggen, gebruikt u log (all).
quick
Als een pakket overeenstemt met een regel die quick specificeert, dan wordt die regel als de laatste overeenstemmende regel beschouwd en wordt de gespecificeerde actie ondernomen.
interface
De naam of groep van de netwerkinterface waar het pakket doorheen beweegt. Een interfacegroep wordt gespecificeerd als de naam van de interface maar zonder het geheel getal er aan geplakt. Bijvoorbeeld: ppp of fxp. Dit zou ervoor zorgen dat de regel overeenstemt met gelijk welk pakket dat respectievelijk gelijk welke ppp of fxp interface doorkruist.
af
De adresfamilie van het pakket, ofwel inet voor IPv4 ofwel inet6 voor IPv6. PF kan deze parameter gewoonlijk bepalen op basis van het (de) bron- en/of bestemmingsadres(sen).
protocol
Het Layer 4 protocol van het pakket:
src_addr, dst_addr
Het bron/bestemmingsadres in de IP header. Adressen kunnen gespecificeerd worden als:
src_port, dst_port
De bron/destinatiepoort in de Layer 4 pakkethoofding. Poorten kunnen gespecificeerd worden als:
tcp_flags
Specificeert de vlaggen die ingesteld moeten zijn in de TCP header bij gebruik van proto tcp. Vlaggen worden gespecificeerd als flags check/mask. Bijvoorbeeld: flags S/SA - dit draagt PF op om enkel naar de S en A (SYN and ACK) vlaggen te kijken en overeenstemming te vinden als alleen de SYN vlag "aan" staat.
state
Specificeert of toestandsinformatie bijgehouden wordt voor pakketten die overeenstemmen met deze regel.

Standaard Weigeren

Het aanbevolen gebruik bij het opzetten van een firewall is om voor een "standaard weigeren" aanpak te kiezen. Dat betekent: alles weigeren en vervolgens selectief bepaald verkeer doorheen de firewall toelaten. Deze aanpak wordt aanbevolen omdat hij het zekere voor het onzekere neemt en ook het schrijven van een regelset gemakkelijker maakt.

Om een standaard weigeren filterbeleid te creëren, zouden de eerste twee filterregels de volgende moeten zijn:

block in  all
block out all

Dit zal alle verkeer op alle interfaces in elke richting van gelijk waar naar gelijk waar blokkeren.

Verkeer Doorlaten

Verkeer moet nu expliciet doorheen de firewall doorgelaten worden ofwel zal het standaard weigeren beleid het laten vallen. Dit is waar pakketcriteria zoals bron/bestemmingspoort, bron/bestemmingsadres, en protocol in het spel komen. Telkens wanneer verkeer toegestaan wordt om doorheen de firewall te gaan wordt (worden) de regel(s) best zo beperkend mogelijk geschreven. Dit om te verzekeren dat het bedoelde verkeer, en alleen het bedoelde verkeer, toegestaan wordt om door te gaan.

Enkele voorbeelden:

# Laat verkeer binnen op dc0 vanuit het lokale netwerk,
# 192.168.0.0/24, naar het IP adres van de OpenBSD machine,
# 192.168.0.1. Laat ook het terugkerende verkeer naar buiten
# op dc0.
pass in  on dc0 from 192.168.0.0/24 to 192.168.0.1
pass out on dc0 from 192.168.0.1 to 192.168.0.0/24


# Laat TCP verkeer binnen op fxp0 naar de webserver die draait op
# de OpenBSD machine. De interfacenaam, fxp0, wordt gebruikt als
# het bestemmingsadres zodat pakketten enkel met deze regel
# overeenstemmen als ze bestemd zijn voor de OpenBSD machine.
pass in on fxp0 proto tcp from any to fxp0 port www

Het quick Sleutelwoord

Zoals eerder aangegeven, wordt elk pakket geëvalueerd met de filterregelset van boven naar onder. Standaard wordt het pakket gemarkeerd voor doorlating, wat door gelijk welke regel veranderd kan worden, en verscheidene keren heen en weer zou kunnen veranderd worden voor het einde van de filterregels. De laatste overeenstemmende regel "wint". Hierop is een uitzondering: de quick optie bij een filterregel heeft als effect dat alle verdere regelverwerking geannuleerd wordt en zorgt ervoor dat de gespecificeerde actie ondernomen wordt. Laten we naar een paar voorbeelden kijken:

Fout:

block in on fxp0 proto tcp from any to any port ssh
pass  in all

In dit geval kan de block lijn geëvalueerd worden, maar ze zal nooit enig effect hebben, aangezien ze gevolgd wordt door een lijn die alles zal doorlaten.

Beter:

block in quick on fxp0 proto tcp from any to any port ssh
pass  in all

Deze regels worden een beetje verschillend geëvalueerd. Als de block overeenstemt, door de quick optie, zal het pakket geblokkeerd worden, en zal de rest van de regelset genegeerd worden.

Toestand ("state") Bijhouden

Eén van Packet Filter's belangrijke mogelijkheden is "toestand bijhouden" of "stateful inspection". Stateful inspection verwijst naar PF's mogelijkheid om de toestand, of voortgang, van een netwerkverbinding te volgen. Door informatie over elke verbinding te bewaren in een toestandstabel ("state table"), kan PF snel bepalen of een pakket dat doorheen de firewall gaat bij een reeds opgerichte verbinding hoort. Zo ja, dan wordt het doorheen de firewall doorgelaten zonder doorheen de evaluatie van de regelset te gaan.

Toestand bijhouden heeft vele voordelen waaronder eenvoudigere regelsets en betere pakketfilterpresatie. PF kan pakketten die in gelijk welke richting bewegen, in overeenstemming brengen met toestandstabel-entries, wat betekent dat filterregels die terugkerend verkeer doorlaten niet geschreven hoeven te worden. En, aangezien pakketten die overeenstemmen met stateful verbindingen niet doorheen regelsetevaluatie hoeven te gaan, kan de tijd die PF besteedt aan het verwerken van die pakketten enorm verminderd worden.

Wanneer een regel de keep state optie heeft, creëert het eerste pakket dat overeenstemt met de regel een "state" tussen zender en ontvanger. Nu stemmen niet alleen pakketten die van zender naar ontvanger gaan, overeen met de toestand-entry en ze gaan voorbij aan regelsetevaluatie, maar ook de antwoordpakketten van ontvanger naar zender. Bijvoorbeeld:

pass out on fxp0 proto tcp from any to any keep state

Dit laat gelijk welk uitgaand TCP verkeer toe op de fxp0 interface en staat ook toe dat het antwoordverkeer terug doorheen de firewall gaat. Hoewel toestand bijhouden een leuke functionaliteit is, verbetert het gebruik ervan aanzienlijk de prestatie van uw firewall aangezien toestandsopzoekingen spectaculair sneller zijn dan een pakket doorheen de filterregels laten lopen.

De modulate state optie werkt net zoals keep state behalve dat ze alleen van toepassing is op TCP pakketten. Met modulate state wordt het Initial Sequence Number (ISN) van uitgaande verbindingen gerandomiseerd. Dit is nuttig om verbindingen te beschermen die geïnitieerd werden door bepaalde besturingssystemen die slecht ISNs kiezen. Beginnend met OpenBSD 3.5, kan de modulate state optie gebruikt worden in regels die andere protocols dan TCP specificeren.

Toestand bijhouden op uitgaande TCP, UDP en ICMP pakketten en TCP ISNs moduleren:

pass out on fxp0 proto { tcp, udp, icmp } from any \
    to any modulate state

Een ander voordeel van toestand bijhouden is dat overeenkomstig ICMP verkeer zal doorgelaten worden doorheen de firewall. Als bijvoorbeeld keep state gespecificeerd wordt voor een TCP verbinding en er komt een ICMP source-quench bericht aan dat verwijst naar deze TCP verbinding, dan zal het met de gepaste toestand-entry in overeenstemming gebracht worden en doorheen de firewall gelaten worden.

Het bereik van een toestand-entry wordt globaal gecontroleerd door de state-policy runtime optie en op een per regel basis door de if-bound, group-bound en floating state optie sleutelwoorden. Deze per regel sleutelwoorden hebben dezelfde betekenis als wanneer ze gebruikt worden met de state-policy optie. Voorbeeld:

pass out on fxp0 proto { tcp, udp, icmp } from any \
    to any modulate state (if-bound)

Deze regel zou opdragen dat opdat pakketten zouden overeenstemmen met de toestand-entry, ze de fxp0 interface moeten doorkruisen.

Merk op dat nat, binat en rdr regels impliciet toestand creëren voor overeenstemmende verbindingen zolang de verbinding doorgelaten wordt door de filterregelset.

Toestand ("state") Bijhouden voor UDP

Men zal soms horen zeggen dat, "Men geen toestand mag creëren met UDP aangezien UDP een toestandloos protocol is!" Hoewel het waar is dat een UDP communicatiesessie geen concept van toestand (een expliciet begin en einde van communicatie) heeft, heeft dit geen impact op PF's mogelijkheid om toestand te creëren voor een UDP sessie. In het geval van protocols zonder "begin" en "eind" pakketten, houdt PF eenvoudigweg bij hoe lang het geleden is dat er een overeenstemmend pakket doorgelaten werd. Als de timeout bereikt wordt, wordt de toestand leeggemaakt. De timeout-waarden kunnen ingesteld worden in de opties sectie van het pf.conf bestand.

"Stateful" Traceringsopties

Wanneer een filterregel een toestandstabel-entry aanmaakt via het gebruik van gelijk welk van de sleutelwoorden keep state, modulate state of synproxy state, kunnen bepaalde opties gespecificeerd worden die het gedrag van toestandscreatie regelen. De volgende opties zijn beschikbaar:
max aantal
Beperk het maximum aantal toestandsentries die de regel kan aanmaken tot aantal. Indien het maximum bereikt is, worden pakketten die normaal toestand creëren gedropt tot het aantal bestaande toestanden afneemt.
source-track
Deze optie schakelt het traceren in van het aantal toestanden aangemaakt per bron IP adres. Deze optie heeft twee formaten: Het totale aantal globaal getraceerde bron IP adressen kan geregeld worden via de src-nodes runtime optie.
max-src-nodes aantal
Wanneer de source-track optie gebruikt wordt, zal max-src-nodes het aantal bron IP adressen beperken die gelijktijdige toestand kunnen aanmaken. Deze optie kan alleen gebruikt worden met source-track rule.
max-src-states aantal
Wanneer de source-track optie gebruikt wordt, zal max-src-states het aantal gelijktijdige toestandsentries beperken die per bron IP adres kunnen aangemaakt worden. Het bereik van deze limiet (bv. toestanden aangemaakt door alleen deze regel of toestanden aangemaakt door alle regels die source-track gebruiken) is afhankelijk van de gespecificeerde source-track optie.

Een voorbeeldregel:

pass in on $ext_if proto tcp to $web_server \
    port www flags S/SA keep state \
    (max 200, source-track rule, max-src-nodes 100, max-src-states 3)

De bovenstaande regel definieert het volgende gedrag:

Een afzonderlijk stel beperkingen kan geplaatst worden op "stateful" TCP verbindingen die de 3-wegs handdruk voltooid hebben.

max-src-conn aantal
Beperk het maximum aantal gelijktijdige TCP verbindingen die de 3-wegs handdruk voltooid hebben die een enkele host kan maken.
max-src-conn-rate aantal / interval
Beperk de snelheid waarmee nieuwe connecties gemaakt worden tot een bepaalde hoeveelheid per tijdsinterval.

Beide opties roepen automatisch de source-track rule optie op en zijn niet compatibel met source-track global.

Aangezien deze beperkingen alleen geplaatst worden op TCP verbindingen die de 3-wegs handdruk voltooid hebben, kunnen meer agressieve acties genomen worden op overtredende IP adressen.

overload <tabel>
Zet het IP adres van een overtredende host in de genoemde tabel.
flush [global]
Verwijder andere toestanden die met deze regel overeenstemmen en die aangemaakt werden door dit bron IP adres. Wanneer global gespecificeerd wordt, verwijder alle toestanden die overeenstemmen met dit bron IP adres, ongeacht welke regel de toestand aanmaakte.

Een voorbeeld:

table <abusive_hosts> persist
block in quick from <abusive_hosts>

pass in on $ext_if proto tcp to $web_server \
    port www flags S/SA keep state \
    (max-src-conn 100, max-src-conn-rate 15/5, overload <abusive_hosts> flush)

Dit doet het volgende:

TCP Vlaggen

TCP pakketten overeenstemmen op basis van vlaggen wordt het vaakst gebruikt om TCP pakketten te filteren die een nieuwe verbinding proberen te openen. De TCP vlaggen en hun betekenis worden hier opgesomd:

Om PF de TCP vlaggen te laten inspecteren tijdens de evaluatie van een regel, wordt het flags sleutelwoord gebruikt met de volgende syntaxis:

flags check/mask

Het mask gedeelte vertelt PF alleen de gespecificeerde vlaggen te inspecteren en het check gedeelte specificeert welke vlag(gen) "aan" moeten staan in de hoofding opdat overeenstemming zou plaatsvinden.

pass in on fxp0 proto tcp from any to any port ssh flags S/SA

De bovenstaande regel laat TCP verkeer door met de SYN vlag aangezet terwijl hij enkel kijkt naar de SYN en ACK vlaggen. Een pakket met de SYN en ECE vlaggen zou overeenstemmen met de bovenstaande regel, maar een pakket met SYN en ACK of gewoon ACK niet.

Opmerking: in vorige versies van OpenBSD werd de volgende syntaxis ondersteund:

. . . flags S

Dit is niet langer het geval. Een mask moet nu altijd gespecificeerd worden.

Vlaggen worden vaak gebruikt in samenhang met keep state regels om het aanmaken van toestand-entries te helpen beheersen:

pass out on fxp0 proto tcp all flags S/SA keep state

Dit zou het aanmaken van een toestand toestaan op gelijk welk uitgaand TCP pakket met de SYN vlag aangezet, uit de SYN en ACK vlaggen.

Men moet voorzichtig zijn met het gebruik van vlaggen -- begrijp wat u aan het doen bent en waarom, en wees voorzichtig met de raad die mensen geven aangezien veel ervan slecht is. Sommige mensen hebben gesuggereerd toestand te creëren "alleen als de SYN vlag aangezet is en geen andere". Zo'n regel zou eindigen op: 

     . . . flags S/FSRPAUEW  slecht idee!!

De theorie is: creëer toestand alleen bij het begin van de TCP sessie, en de sessie zou moeten beginnen met een SYN vlag, en geen andere. Het probleem is dat sommige sites de ECN vlag beginnen te gebruiken en gelijk welke site die ECN gebruikt en met u probeert te verbinden, zou afgewezen worden door zulk een regel. Een veel betere richtlijn is:

. . . flags S/SAFR

Hoewel dit praktisch en veilig is, is het onnodig om de FIN en RST vlaggen na te kijken indien trafiek ook geschrobd wordt. Het schrob-proces zal ervoor zorgen dat PF binnenkomende pakketten met illegale TCP vlag combinaties (zoals SYN en RST) laat vallen en mogelijk dubbelzinnige combinaties (zoals SYN en FIN) normaliseert. Het wordt ten zeerste aanbevolen om altijd binnenkomend verkeer te schrobben ("scrub"):

scrub in on fxp0
.
.
.
pass in on fxp0 proto tcp from any to any port ssh flags S/SA \
   keep state

TCP SYN Proxy

Normaal gezien, wanneer een client een TCP verbinding met een server initieert, zal PF de handdruk ("handshake") pakketten tussen de twee eindpunten doorlaten als ze aankomen. PF heeft echter de mogelijkheid om de handdruk te proxy'en. Wanneer de handdruk geproxied wordt, zal PF zelf de handdruk met de client voltooien, een handdruk met de server initiëren, en vervolgens pakketten tussen beide doorsturen. Het voordeel van dit proces is dat er geen pakketten naar de server gestuurd worden alvorens de client de handdruk voltooit. Dit elimineert de bedreiging van gespoofte TCP SYN floods die de server treffen omdat een gespoofte client verbinding de handdruk niet zal kunnen voltooien.

De TCP SYN proxy wordt ingeschakeld met de synproxy state sleutelwoorden in filterregels. Voorbeeld:

pass in on $ext_if proto tcp from any to $web_server port www \
   flags S/SA synproxy state

Hier zullen verbindingen naar de webserver TCP-geproxied worden door PF.

Omwille van de manier waarop synproxy state werkt, omvat het ook dezelfde functionaliteit als keep state en modulate state.

De SYN proxy zal niet werken als PF draait op een bridge(4).

Gespoofte Pakketten Blokkeren

Adres-"spoofing" is wanneer een kwaadwillige gebruiker het bron-IP adres vervalst in pakketten die hij verstuurt ofwel om zijn echt adres te verbergen ofwel om zich uit te geven voor een ander knooppunt op het netwerk. Zodra de gebruiker zijn adres gespooft heeft kan hij een netwerkaanval lanceren zonder de ware bron van de aanval te onthullen, of toegang proberen te verkrijgen tot netwerkdiensten die beperkt zijn tot bepaalde IP adressen.

PF biedt wat bescherming tegen adres-spoofing via het antispoof sleutelwoord:

antispoof [log] [quick] for interface [af]
log
Specificeert dat overeenstemmende pakketten gelogd moeten worden via pflogd(8).
quick
Als een pakket overeenstemt met deze regel dan zal deze beschouwd worden als de "winnende" regel en zal de regelsetevaluatie stoppen.
interface
De netwerkinterface om spoofing-bescherming op te activeren. Dit kan ook een lijst van interfaces zijn.
af
De adresfamilie om spoofing-bescherming voor te activeren, ofwel inet voor IPv4 of inet6 voor IPv6.

Voorbeeld:

antispoof for fxp0 inet

Wanneer een regelset geladen wordt, zal het voorkomen van het antispoof sleutelwoord ontvouwen worden in twee filterregels. In de veronderstelling dat interface fxp0 IP adres 10.0.0.1 heeft en een subnet mask van 255.255.255.0 (dus een /24), zou de bovenstaande antispoof regel ontvouwen tot:

block in on ! fxp0 inet from 10.0.0.0/24 to any
block in inet from 10.0.0.1 to any

Deze regels bereiken twee dingen:

OPMERKING: De filterregels waarin de antispoof regel zich ontvouwt, zullen ook pakketten blokkeren die over de loopback interface naar lokale adressen verzonden worden. De beste gewoonte is om het filteren over te slaan op loopback interfaces, dit wordt echter een noodzaak bij gebruik van antispoof regels:

set skip on lo0

antispoof for fxp0 inet

Gebruik van antispoof wordt best beperkt tot interfaces waaraan een IP adres is toegekend. Gebruik van antispoof op een interface zonder IP adres zal leiden tot filterregels als:

block drop in on ! fxp0 inet all
block drop in inet all

Met deze regels is er een risico om alle ingaand verkeer op alle interfaces te blokkeren.

Passieve Besturingssysteem "Fingerprinting"

Passive OS Fingerprinting (OSFP) is een methode om passief het besturingssysteem van een remote host te detecteren op basis van bepaalde karakteristieken binnen de TCP SYN pakketten van die host. Deze informatie kan vervolgens gebruikt worden als criteria binnen filterregels.

PF bepaalt het remote besturingssysteem door karakteristieken van een TCP SYN pakket te vergelijken met het fingerprints bestand, dat standaard /etc/pf.os is. Zodra PF ingeschakeld wordt, kan de huidige fingerprint lijst bekeken worden met dit commando:

# pfctl -s osfp

Binnen een filterregel kan een fingerprint gespecificeerd worden per OS klasse, versie, of subtype/patchniveau. Elk van deze items wordt opgesomd in de uitvoer van het hierboven getoonde pfctl commando. Om een fingerprint te specificeren in een filterregel, wordt het os sleutelwoord gebruikt:

pass  in on $ext_if from any os OpenBSD keep state
block in on $ext_if from any os "Windows 2000"
block in on $ext_if from any os "Linux 2.4 ts"
block in on $ext_if from any os unknown

De speciale besturingssysteemklasse unknown laat toe pakketten te laten overeenstemmen wanneer de OS fingerprint niet gekend is.

NOTEER het volgende:

IP Opties

Standaard blokkeert PF pakketten waarbij IP opties zijn ingesteld. Dit kan de taak moeilijker maken voor "OS fingerprinting" utilities zoals nmap. Als u een toepassing hebt die het doorlaten van deze pakketten vereist, zoals multicast of IGMP, kan u de allow-opts opdracht gebruiken:
pass in quick on fxp0 all allow-opts

Filterregelset Voorbeeld

Hieronder staat een voorbeeld van een filterregelset. De machine die PF draait, fungeert als firewall tussen een klein, intern netwerk en het Internet. Alleen de filterregels zijn getoond; queueing, nat, rdr, enz. werden uit dit voorbeeld gelaten. 

ext_if  = "fxp0"
int_if  = "dc0"
lan_net = "192.168.0.0/24"

# tabel die alle IP adressen bevat die toegekend zijn aan de firewall
table <firewall> const { self }

# filter niet op de loopback interface
set skip on lo0

# schrob binnenkomende pakketen
scrub in all

# stel een standaard weigeren beleid in
block all

# activeer spoofing-bescherming voor de interne interface.
antispoof quick for $int_if inet

# laat alleen ssh verbindingen toe vanaf het lokale netwerk als het vanaf de
# vertrouwde computer, 192.168.0.15, komt. gebruik "block return" zodat een
# TCP RST verzonden wordt om geblokkeerde verbindingen meteen te sluiten.
# gebruik "quick" zodat deze regel niet opgeheven wordt door de "pass" regels
# hieronder.
block return in quick on $int_if proto tcp from ! 192.168.0.15 \
   to $int_if port ssh flags S/SA

# laat alle verkeer naar en vanuit het lokale netwerk door
pass in  on $int_if from $lan_net to any
pass out on $int_if from any to $lan_net

# laat tcp, udp en icmp naar buiten op de externe (Internet) interface. 
# houd toestand bij op udp en icmp en moduleer toestand op tcp.
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state

# laat ssh verbindingen binnen op de externe interface zolang ze NIET
# bestemd zijn voor de firewall (ze zijn dus bestemd voor een machine in
# het lokale netwerk). log het initiële pakket zodat we later kunnen
# zeggen wie er probeert te verbinden. gebruik de tcp syn proxy om de
# verbinding te proxy'en.
pass in log on $ext_if proto tcp from any to ! <firewall> \
   port ssh flags S/SA synproxy state

[Vorige: Tabellen] [Inhoud] [Volgende: Network Address Translation]

[terug] www@openbsd.org
$OpenBSD: filter.html,v 1.14 2006/05/01 09:48:11 jufi Exp $