[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 een toestand creëert, 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. Interfaces kunnen toegevoegd worden aan willekeurige groepen met het ifconfig(8) commando. Verscheidene groepen worden ook automatisch aangemaakt door de kernel: Dit zou ervoor zorgen dat de regel overeenstemt met gelijk welk pakket dat respectievelijk gelijk welke ppp of carp 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 (dit is standaard van toepassing op alle TCP filterregels). flags any instrueert PF om de vlaggen niet te controleren.
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 to 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 to 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 een "state" creëert, 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.

Alle pass regels creëren automatisch een "state entry" wanneer een pakket overeenstemt met de regel. Dit kan expliciet worden uitgezet met de no state optie.

pass out on fxp0 proto tcp from any to any

Deze regel laat ieder uitgaand TCP verkeer toe op de fxp0 interface en staat ook toe dat het antwoordverkeer terug doorheen de firewall gaat. Het bijhouden van de toestand verbetert de prestatie van uw firewall aanzienlijk 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. Voor eenvoudiger regelsets kan de modulate state optie worden gebruikt in regels die andere protocollen dan TCP specificeren; in die gevallen wordt deze behandeld als keep state.

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 een TCP verbinding die door de firewall gaat met "state" opgevolgd wordt 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 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.

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

Filterregels die "state entries" creëren, kunnen verscheidene opties specificeren om het gedrag van de resulterende "state entry" te controleren. De volgende opties zijn beschikbaar:
max aantal
Beperk het maximum aantal toestandsentries die de regel kan aanmaken tot aantal. Indien het maximum bereikt is, stemmen pakketten die normaal toestand creëren niet overeen met deze regel totdat het aantal bestaande toestanden afneemt tot onder de limiet.
no state
Voorkomt dat de regel automatisch een "state entry" creëert.
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.

Opties worden gespecificeerd tussen haakjes en onmiddellijk na één van de state sleutelwoorden (keep state, modulate state of synproxy state). Meerdere opties worden gescheiden door komma's. Vanaf OpenBSD 4.1 werd de keep state optie impliciet de standaard voor alle filterregels. Desondanks moet, wanneer men stateful opties specificeert, één van de state sleutelwoorden nog steeds gebruikt worden vóór de opties.

Een voorbeeldregel:

pass in on $ext_if proto tcp to $web_server \
    port www 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
flags any

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. Het gebruik van het any sleutelwoord laat gelijk welke combinatie van vlaggen toe in de hoofding.

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

Aangezien flags S/SA standaard gebruikt wordt, zijn bovenstaande regels equivalent. Beide regels laten 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.

De standaardvlaggen kunnen overschreden worden door de flags optie zoals hierboven beschreven.

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 helemaal geen vlaggen specificeren en PF de standaardvlaggen laten toepassen op uw regels. Als u werkelijk zelf de vlaggen moet specificeren, dan zou deze combinatie veilig moeten zijn:

. . . flags S/SAFR

Hoewel dit praktisch en veilig is, is het onnodig om de FIN en RST vlaggen na te kijken indien verkeer 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.

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. In geval van een TCP SYN flood aanval zal de aanvaller nooit de 3-wegs handdruk voltooien, dus de pakketen van de aanvaller bereiken nooit de beveiligde server. Legitieme clients voltooien de handdruk wel en zullen dus passeren. Dit minimaliseert het effect van gespoofde TCP SYN floods op de beschermde dienst, door deze in PF af te handelen. Het wordt echter afgeraden om deze optie als standaard te gebruiken, omdat het het standaard gedrag van het TCP protocol verbreekt als de server de aanvraag niet kan verwerken of als er load balancers worden toegepast.

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

pass in on $ext_if proto tcp to $web_server port www 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.

Unicast Reverse Path Forwarding

PF biedt een Unicast Reverse Path Forwarding (uRPF) functionaliteit. Wanneer een pakket doorheen de uRPF controle gehaald wordt, wordt het bron IP adres van het pakket opgezocht in de routeringstabel. Als de uitgaande interface die gevonden werd in de routeringstabel dezelfde is als de interface waarop het pakket net binnenkwam, dan slaagt de uRPF controle. Als de interfaces niet overeenstemmen, dan is het mogelijk dat het bronadres van het pakket "gespoofed" werd.

De uRPF controle kan op pakketten uitgevoerd worden door het urpf-failed sleutelwoord te gebruiken in filterregels:

block in quick from urpf-failed label uRPF

Merk op dat de uRPF controle alleen steek houdt in een omgeving waar routering symmetrisch is.

uRPF biedt dezelfde functionaliteit als antispoof regels.

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 proto tcp from any os OpenBSD keep state
block in on $ext_if proto tcp from any os "Windows 2000"
block in on $ext_if proto tcp from any os "Linux 2.4 ts"
block in on $ext_if proto tcp 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
match in all scrub (no-df)

# stel een standaard weigeren beleid in
block all

# activeer spoofing-bescherming voor alle interfaces
block in quick from urpf-failed

# 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

# laat alle verkeer naar en vanuit het lokale netwerk door.
# deze regels zullen state entries aanmaken dankzij de standaard
# "keep state" optie die automatisch wordt toegepast.
pass in  on $int_if from $lan_net
pass out on $int_if to $lan_net

# laat tcp, udp en icmp naar buiten op de externe (Internet) interface. 
pass out on $ext_if proto { tcp udp icmp } all modulate 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.
# Haal het commentaar-teken op het einde weg om de tcp syn proxy de
# verbinding te proxy'en.
pass in log on $ext_if proto tcp to ! <firewall> \
   port ssh # synproxy state

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

[terug] www@openbsd.org
$OpenBSD: filter.html,v 1.38 2012/11/02 11:41:14 ajacoutot Exp $