Darren Reed is de auteur van IPFILTER, dat niet afhankelijk is van één besturingssysteem. Het is een open source applicatie die is geporteerd naar FreeBSD, NetBSD, OpenBSD, SunOS, HP/UX en Solaris besturingssystemen. IPFILTER wordt actief ondersteund en onderhouden en er worden regelmatig nieuwe versies uigebracht.
IPFILTER is gebaseerd op een firewall aan de kernelkant en een NAT mechanisme dat gecontroleerd en gemonitord kan worden door programma's in userland. De firewallregels kunnen ingesteld of verwijderd worden met het hulpprogramma ipf(8). De NAT regels kunnen ingesteld of verwijderd worden met ipnat(8). Het programma ipfstat(8) kan actuele statistieken leveren voor de kernelonderdelen van IPFILTER. ipmon(8) kan acties van IPFILTER wegschrijven naar logboekbestanden van het systeem.
IPF is oorspronkelijk geschreven met logica die regels
verwerkte volgens het principe “de laatst passende regel
wint” en gebruikte toen alleen staatloze regels. In de
loop der tijd is IPF verbeterd en zijn de opties
quick
en keep state
toegevoegd waarmee de logica van het verwerken van regels
drastisch is gemoderniseerd. In de officiële documentatie
van IPF worden alleen de regels en verwerkingslogica
behandeld. De moderne functies worden alleen behandeld als
opties, waardoor hun nut dat er een veel betere en veiligere firewall mee
te maken volledig onderbelicht blijft.
De instructies in dit hoofdstuk zijn gebaseerd op regels die
gebruik maken van de optie quick
en de
stateful optie keep state
. Dit is het
raamwerk waarmee een set van inclusieve firewallregels wordt
samengesteld.
Voor een gedetailleerde uitleg over de verwerking van de verouderde regels zie http://www.munk.me.uk/ipf/ipf-howto.html en http://coombs.anu.edu.au/~avalon/ip-filter.html.
De IPF FAQ is te vinden op http://www.phildev.net/ipf/index.html.
Een doorzoekbaar archief van de open-source IPFilter mailing lijst is beschikbaar op http://marc.theaimsgroup.com/?l=ipfilter.
IPF zit in de basisinstallatie van FreeBSD als een aparte
“run time” laadbare module. Een systeem laadt de
IPF kernel laadbare module dynamisch als
ipfilter_enable="YES"
in
rc.conf
staat. Voor de laadbare module
zijn de opties logging
en default
pass all
ingeschakeld. IPF hoeft niet in de
kernel gecompileerd te worden om het standaardgedrag te
wijzigen naar block all
. Dat is mogelijk
door op het einde van de regelverzameling een regel block
all
toe te voegen die al het verkeer blokkeert.
Het is niet verplicht om IPF in te schakelen door de volgende opties in de FreeBSD kernel te compileren. Dit wordt alleen beschreven als achtergrondinformatie. Door IPF in de kernel te compileren wordt de laadbare module niet gebruikt.
Voorbeeld kernelinstellingen voor IPF staan beschreven in
de /usr/src/sys/i386/conf/LINT
in de
kernelbroncode en worden hier beschreven:
options IPFILTER
schakelt ondersteuning
voor de “IPFILTER” firewall in.
options IPFILTER_LOG
schakelt de
optie in waarmee IPF verkeer kan loggen door het naar het
ipl
pakketloggende
pseudo-apparaat te schrijven voor iedere regel met het
sleutelwoord log
erin.
options IPFILTER_DEFAULT_BLOCK
wijzigt het standaardgedrag zodat ieder pakket waarop geen
enkele pass
regel van toepassing is
wordt geblokkeerd.
Deze instelling worden pas actief nadat een kernel waarvoor deze instellingen zijn gemaakt is gebouwd en geïnstalleerd.
De volgende instellingen moeten in /etc/rc.conf
staan om IPF bij het opstarten te activeren:
Als er een LAN achter de firewall staat dat gebruik maakt van IP-adressen uit de private reeks, dan moet de volgende optie ook ingesteld worden om NAT-functionaliteit in te schakelen:
Het commando ipf(8) wordt gebruikt om het bestand met firewallregels te laden. Gewoonlijk wordt er een bestand aangemaakt waarin de situatieafhankelijke regels staan waarmee in één keer de bestaande regels kunnen worden vervangen:
#
ipf -Fa -f /etc/ipf.rules
-Fa
: verwijder alle interne tabellen
met regels.
-f
: laad het aangegeven
bestand met regels.
Hiermee wordt het mogelijk wijzigingen te maken aan het bestand met eigen regels en met ipf(8) de firewall aan te passen met verse regels zonder het systeem te booten. Deze methode is erg handig om nieuwe regels te testen omdat dit zo vaak als nodig gedaan kan worden.
In ipf(8) worden alle opties die beschikbaar zijn toegelicht.
ipf(8) verwacht dat het bestand met regels een standaard tekstbestand is. Het accepteert geen bestand met regels dat is opgesteld als een script dat gebruik maakt van substitutie.
Er is wel een mogelijkheid om IPF regels op te stellen en gebruik te maken van substitutie. Meer informatie staat in Paragraaf 30.5.9, “Script met regels met substitutie bouwen”.
ipfstat(8) haalt de totalen van de statistieken op
die horen bij de firewall sinds die is gestart en toont deze.
Het kan ook zijn dat de tellers in tussentijd op nul zijn
gesteld met ipf -Z
.
In ipfstat(8) worden alle details behandeld.
Standaard ziet ipfstat(8) uitvoer er ongeveer als volgt uit:
Als er als optie -i
voor inkomend of
-o
voor uitgaand wordt meegegeven, dan zal het
commando de juiste lijst met regels die de kernel op dat moment gebruikt
wordt weergeven.
ipfstat -in
toont de tabel met
regels voor inkomend verkeer met regelnummers
ipfstat -on
toont de tabel met
regels voor uitgaand verkeer met regelnummers
De uitvoer ziet er ongeveer als volgt uit:
ipfstat -ih
toont de tabel met
regels voor inkomend verkeer, waarbij voor iedere regel staat
hoe vaak die van toepassing was.
ipfstat -oh
toont de tabel met
regels voor uitgaand verkeer, waarbij voor iedere regel staat
hoe vaak die van toepassing was.
De uitvoer ziet er ongeveer als volgt uit:
Een van de belangrijkste functies van
ipfstat
is de vlag -t
waarmee de staat-tabel wordt getoond op een wijze die
vergelijkbaar is met de wijze waarop top(1) de draaiende
FreeBSD procestabel toont. Als een firewall wordt aangevallen, dan
geeft deze functie de mogelijkheid om de pakketten van de
aanvaller te identificeren en nader te onderzoeken. De
optionele subvlaggen bieden de mogelijkheid om een bron of
bestemmings IP adres, poort of protocol aan
te geven dat gemonitord moet worden. Details zijn na te lezen
in ipfstat(8).
Om ipmon(8) te laten werken zoals bedoeld, moet de
kerneloptie IPFILTER_LOG
aan staan. Dit
commando kan op twee verschillende wijzen gebruikt worden.
De standaard is van toepassing als het commando op de
commandoregel wordt ingegeven zonder de optie
-D
.
De daemon wordt gebruikt als continu een systeemlogboek
bijgewerkt moet worden zodat het mogelijk is om
gebeurtenissen in het verleden te bekijken. Zo zijn FreeBSD en
IPFILTER ingesteld om samen te werken. FreeBSD heeft ingebouwde
mogelijkheden om automatisch syslogs te roteren. Daarom is
het beter om de uitvoer naar syslogd(8) te schrijven
dan naar een gewoon bestand. In de standaardversie van
rc.conf
is te zien dat de instelling
ipmon_flags
de waarde -Ds
heeft:
De voordelen van loggen zijn duidelijk. Het biedt de mogelijkheid om na het feit informatie na te zien als: welke pakketten heeft de firewall laten vallen, waar kwamen ze vandaan en waar gingen ze heen? Dit zijn allemaal voordelen als het gaat om uitvinden waar een aanvaller vandaan komt en wat deze heeft geprobeerd.
Zelfs als loggen is ingeschakeld, logt IPF nog niets uit
zichzelf. De beheerder van de firewall beslist welke regels in de
regelverzameling iets weg moeten schrijven door het sleutelwoord
log
aan die regels toe te voegen.
Gewoonlijk worden alleen deny
regels
gelogd.
Het is heel normaal om als laatste regel een
deny
regel aan de set met regels toe te
voegen waar het sleutelwoord log
in staat.
Zo krijgt een beheerder alle pakketten te zien waarop geen
enkele regel van toepassing was.
Syslogd heeft een eigen methode
om logboekgegevens te scheiden. Het maakt gebruik van speciale
groepen die “facility” en “level”
heten. ipmon(8) in -Ds
mode gebruikt
local0
als “facility”naam. Alle door ipmon(8) gelogde
gegevens gaan standaard naar de naam security
.
De nu volgende levels
kunnen gebruikt worden om de gelogde gegevens nog verder uit
elkaar te trekken als dat gewenst is.
Om IPFILTER alle gelogde gegevens naar
/var/log/ipfilter.log
te laten schrijven,
dient dat bestand vooraf te bestaan. Dat kan met het volgende
commando:
#
touch /var/log/ipfilter.log
De functionaliteit van syslogd(8) wordt beheerd met
instellingen in /etc/syslog.conf
.
Dit bestand biedt aanzienlijke
flexibiliteit in hoe syslog omgaat met
systeemberichten die door softwaretoepassingen als IPF worden
gegeven.
Zo kan de volgende instelling toegevoegd worden aan
/etc/syslog.conf
:
Het deel local0.*
betekent dat alle logberichten naar de aangegeven plaats
geschreven moeten worden.
Om de wijzigingen in
/etc/syslog.conf
actief te maken kan er opnieuw
opgestart worden of is het mogelijk de daemon syslogd(8) een schop
te geven zodat /etc/syslog.conf
opnieuw
wordt ingelezen met /etc/rc.d/syslogd
reload
. Het PID (procesnummer) is te achterhalen
door een overzicht van taken te tonen met
ps -ax
. Het PID is het nummer in de
linker kolom voor de regel waarop “syslog”
staat.
Vaak wordt vergeten
/etc/newsyslog.conf
te wijzigen om het
nieuw aangemaakte logboekbestand te laten roteren.
Berichten die door ipmon
wordt gezonden
bestaan uit velden die gescheiden worden door een spatie.
Velden die in alle berichten zitten zijn:
De datum waarop het pakket is ontvangen.
De tijd waarop het pakket is ontvangen weergegeven als HH:MM:SS.F voor uren, minuten, seconden en fracties van een seconde. De fractie kan meerdere cijfers lang zijn.
De naam van de interface waarop het pakket is
ontvangen, bijvoorbeeld
dc0
.
De groep en regelnummer van de regel, bijvoorbeeld
@0:17
.
Deze kunnen ingezien worden met
ipfstat -in
.
De acties: p
voor doorgelaten
(“passed”), b
voor
geblokkeerd (“blocked”),
S
voor een verkeerd pakket
(“short packet”), n
voor
dat er geen enkele regel van toepassing was,
L
voor een logboekregel. De volgorde
waarin deze acties getoond worden is: S, p, b, n, L. Een
hoofdletter P
of B
betekent dat het pakket gelogd is vanwege een globale
instelling, niet vanwege één regel in het
bijzonder.
De adressen. Dit zijn eigenlijk drie velden: het
bronadres en poort gescheiden door een komma, het symbool
-> en het bestemmingsadres en poort, bijvoorbeeld:
209.53.17.22,80 -> 198.73.220.17,1722
.
Achter PR
staat de naam van het
protocol of het nummer, bijvoorbeeld PR
tcp
.
Achter len
staan de lengte van de
pakketkop en de totale lengte van het pakket,
bijvoorbeeld len 20 40
.
Als het pakket een TCP pakket is, dan is er nog een veld dat begint met een verbindingsstreepje met daarachter letters die overeenkomen met vlaggen die ingeschakeld waren. In ipf(5) is een lijst met letters en bijbehorende vlaggen te vinden.
Als het pakket een ICMP pakket is, dan worden aan het
einde twee velden toegevoegd. Het eerste is altijd
ICMP
en het volgende het ICMP bericht en
subbericht type, gescheiden door een slash, bijvoorbeeld
ICMP 3/3
voor “een poort niet
bereikbaar” bericht.
Geoefende gebruikers van IPF maken een bestand dat de regels bevat en stellen dat op zo'n manier op dat het uitgevoerd kan worden als een script met substitutie. Het grote voordeel van deze werkwijze is dat er dan alleen de waarde geassocieerd met een symbolische naam gewijzigd hoeft te worden en dat als het script opnieuw wordt uitgevoerd, op alle plaatsen waar de variabele wordt gebruikt, de nieuwe waarde in de regels wordt opgenomen. Omdat het een script is, kan substitutie gebruik worden om vaak voorkomende waarden de definiëren zodat ze in meerdere regels vervangen kunnen worden. Dit wordt geïllustreerd in het onderstaande voorbeeld.
De syntaxis die in het script wordt gebruikt is compatibel met de shells sh(1), csh(1) en tcsh(1).
Velden waarvoor substitutie van toepassing is worden
vooraf gegaan door het dollarteken
$
.
Definities worden niet vooraf gegaan door het voorvoegsel $.
De waarden van een definitie moet omsloten worden door
dubbele aanhalingstekens ("
).
Een set regels begint wellicht als volgt:
Dat is alles. De regels zijn niet van belang in dit
voorbeeld, maar tonen hoe substitutievelden worden
gedefinieerd en hoe ze worden gebruikt. Als het bovenstaande
voorbeeld de inhoud van
/etc/ipf.rules.script
was, dan konden deze regels
herladen worden door het vanaf de commandoregel aan te roepen:
#
sh /etc/ipf.rules.script
Er is wel een probleem met het gebruik van regels in combinatie met substitutie. IPF snapt het niet en kan deze scripts niet direct lezen.
Dit script kan gebruikt worden op één van de volgende twee manieren:
Haal het commentaarteken weg bij de regel die begint met
cat
en zet het commentaarteken bij de
regel die begint met /sbin/ipf
. Plaats
ipfilter_enable="YES"
in
/etc/rc.conf
zoals gewoonlijk en start
het script eenmalig na elke wijziging om
/etc/ipf.rules
te maken of bij te
werken.
Schakel IPFILTER uit in de systeem opstart scripts door
ipfilter_enable="NO"
toe te voegen aan
/etc/rc.conf
(dit is de
standaardwaarde).
Voeg een script zoals de volgende toe aan de opstartmap
/usr/local/etc/rc.d
. Het
script zou een duidelijke naam moeten hebben zoals
ipf.loadrules.sh
. De uitbreiding
.sh
is noodzakelijk.
De permissies op dit script moeten zijn: lezen,schrijven
en uitvoeren voor de gebruiker root
.
#
chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh
Als het systeem nu herstart, worden de regels via het script gestart.
Een set regels is een groep IPF-regels die is gemaakt om pakketten toe te staan of te blokkeren op basis van de eigenschappen van dat pakket. De bi-directionele uitwisseling van pakketten tussen hosts bestaat uit een gesprek dat een sessie heet. De set van firewallregels verwerkt zowel de pakketten die arriveren van het publieke Internet, als de pakketten die door het systeem zijn geproduceerd als een antwoord erop. Elke TCP/IP-dienst (telnet, www, mail, enzovoorts) is vooraf gedefinieerd door een protocol en bevoorrechte (luister)poort. Pakketten bedoeld voor een speciale dienst beginnen bij het bronadres gebruik makend van een onbevoorrechte (hogere orde) poort en komen aan bij de specifieke dienstpoort op het bestemmingsadres. Alle bovengenoemde parameters (poorten en adressen) kunnen gebruikt worden als selectiecriteria om regels aan te maken die diensten zullen toestaan of blokkeren.
IPF is oorspronkelijk geschreven met logica die regels verwerkte volgens het principe “de laatst passende regel wint” en gebruikte toen alleen staatloze regels. In de loop der tijd is IPF verbeterd en zijn de opties “quick” en “keep state” toegevoegd waarmee de logica van het verwerken van regels drastisch is gemoderniseerd.
De instructies in dit hoofdstuk zijn gebaseerd op regels die gebruik maken van de optie “quick” en de stateful optie “keep state”. Dit is het raamwerk waarmee een set van inclusieve firewallregels wordt samengesteld.
Werk bij het wijzigen van firewallregels zeer voorzichtig. Met sommige instellingen is een server niet meer bereikbaar. Om het veilig te spelen is het aan te raden de eerste instellingen vanaf het console te maken, in plaats van via ssh.
De regelsyntaxis die hier wordt besproken is versimpeld door alleen de moderne stateful regels en de “eerste van toepassing zijnde regel wint” te belichten. De complete regelsyntaxis is na te lezen in ipf(8).
Het karakter #
wordt gebruikt om het
begin van een opmerking te markeren en zowel op een eigen
regel als achter een firewallregel staan. Lege regels worden
genegeerd.
Regels bevatten sleutelwoorden die in een bepaalde volgorde van links naar rechts op een regel horen te staan. Sleutelwoorden worden vet weergegeven. Sommige sleutelwoorden hebben subopties die zelf ook weer sleutelwoorden hebben die ook weer subopties kunnen hebben. Alle opties die hier direct onder staan, worden daaronder uitgebreid weergegeven en verderop in dit hoofdstuk in een aparte paragraaf behandeld.
ACTIE IN/UIT OPTIES SELECTIE STATEFUL
PROTO BRON_ADR,BEST_ADR OBJECT POORT_NUM TCP_VLAG
STATEFUL
ACTIE
= block | pass
IN/UIT
= in | out
OPTIES
= log | quick | on
interfacenaam
SELECTIE
= protowaarde |
bron/bestemming IP | poort = nummer | flags
flag-value
PROTO
= tcp/udp | udp | tcp |
icmp
BRON_ADR,BEST_ADR
= all | from
object to object
OBJECT
= IP adres | any
POORT_NUM
= poortnummer
TCP_VLAG
= S
STATEFUL
= keep state
De actie geeft aan wat er met het pakket gedaan moet worden als het van toepassing is op de rest van de filterregel. Iedere regel moet een actie hebben. De volgende acties zijn mogelijk:
block
geeft aan dat het pakket
moet verdwijnen als de parameters van toepassing zijn op
het pakket.
pass
geeft aan dat het pakket
doorgelaten moet worden als de parameters van toepassing
zijn op het pakket.
Een verplicht onderdeel voor iedere filterregel waarin
expliciet wordt aangegeven op welke zijde van de in/uit
deze van toepassing is. Het volgende sleutelwoord moet
in
of out
zijn en één van de twee moet gecodeerd worden, anders
is de regel syntactisch onjuist.
in
betekent dat de regel van
toepassing is op inkomende pakketten.
out
betekent dat de regel van
toepassing is op inkomende pakketten.
Deze opties moeten in de volgorde waarin ze hier beschreven staan gebruikt worden.
log
geeft aan dat het pakket naar het
ipl
logboekbestand geschreven moeten
worden (zoals verderop beschreven staat in de paragraaf
“Loggen”) als de regel van toepassing is op
het pakket.
quick
geeft aan dat als een regel van
toepassing is, dat de laatste regel moet zijn die wordt
gecontroleerd, waardoor er een pad wordt
“kortgesloten” waardoor de volgende regels voor
dat pakket niet meer gecontroleerd worden. Deze optie is
voor de moderne regels eigenlijk verplicht.
on
geeft de interface aan die in de
parameters meegenomen moet worden. De namen van interfaces
kunnen getoond worden met ifconfig(8). Als deze optie
wordt gebruikt, kan een regel alleen van toepassing zijn als
het pakket door de aangegeven interface gaat in de richting
die is aangegeven
(in
/out
). Ook deze
optie is verplicht voor de moderne regels.
Als een pakket wordt gelogd, dan worden de koppen van het
pakket weggeschreven naar het ipl
pakketloggende pseudo-apparaat. Direct na het
sleutelwoord log
mogen de volgende opties
gebruikt worden (in de aangegeven volgorde):
body
geeft aan dat de eerste 128 bytes
van de inhoud van het pakket worden opgeslagen na de
kop.
first
; als het sleutelwoord
log
samen met een optie keep
state
wordt gebruikt, wordt het aangeraden om
deze optie ook te gebruiken zodat alleen het pakket dat als
eerste in de sessie van toepassing was en niet ook alle
pakketten die daarna in de sessie volgens
keep state
van toepassing
zijn.
De sleutelwoorden in deze paragraaf worden gebruikt om
attributen van het pakket dat wordt geïnspecteerd te
beschrijven om te bepalen of een regel wel of niet van
toepassing is. Er is een sleutelwoord
subject
en er zijn subopties waarvan er
één of meer gekozen moeten worden. De
volgende attributen zijn beschikbaar voor het proces en
moeten in de aangegeven volgorde worden gebruikt:
proto
is het subject
sleutelwoord dat moet worden aangegeven samen met een van de
sleutelwoorden uit de subopties. De waarde geeft een bepaald
protocol aan dat van toepassing moet zijn. Ook deze optie is
verplicht voor de moderne regels.
tcp/udp
, tcp
,
udp
, icmp
of ieder
ander protocol dat in /etc/protocols
staat wordt herkend en kan gebruikt worden. Het bijzondere
protocolsleutelwoord tcp/udp
kan gebruikt
worden om zowel voor TCP- als
UDP-pakketten van toepassing te laten zijn. Het is
toegevoegd voor het gemak om vrijwel gelijke regels te
voorkomen.
Het sleutelwoord all
is in feite
hetzelfde als from any to any
zonder
overige parameters.
from bron to bestemming
; de
sleutelwoorden from
en
to
worden gebruikt om te testen op
IP-adressen. In regels moet
zowel een bron- als
bestemmings-IP-adres
aangegeven worden. any
is een
bijzonder sleutelwoord dat van toepassing is op ieder
IP-adres. Voorbeelden van gebruik: from
any to any
of from 0.0.0.0/0 to any
of
from any to 0.0.0.0/0
of from 0.0.0.0 to
any
of from any to 0.0.0.0
.
Het is vaak lastig om te komen tot een reeks IP-adressen die zich
niet gemakkelijk laten uitdrukken met de gepunte numerieke vorm/
maskerlengte notatie. De port net-mgmt/ipcalc
kan gebruikt worden om de
berekeningen te vereenvoudigen. Aanvullende informatie is beschikbaar
op de webpagina van het gereedschap: http://jodies.de/ipcalc.
Als in een regel op een poort wordt gecontroleerd, voor
bron- of bestemmingspoort of beiden, dan is dat alleen van
toepassing op TCP- en
UDP-pakketten. Bij het maken van
poortvergelijkingen kunnen zowel de dienstnamen uit
/etc/services
als een uit een
natuurlijk getal bestaand poortnummer ingesteld worden. Als
de poort onderdeel is van het from
object
dan wordt het vergeleken met het poortnummer van de bron en
als het onderdeel is van het to
object,
dan wordt het vergeleken met het poortnummer van de
bestemming. Het gebruik van het to
object
is in de moderne regels verplicht en neemt de vorm aan van
from any to any port = 80
.
Enkelvoudige poortvergelijkingen kunnen op verschillende manieren gedaan worden met een aantal verschillende operatoren. Er kunnen ook reeksen van poorten ingesteld worden.
poort "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge"
Reeksen van poorten worden met de volgende optie aangegeven: poort <> | ><
De volgende twee parameters die betrekking hebben op bron en bestemming, zijn verplicht in de moderne regels.
Vlaggen zijn alleen beschikbaar voor het filteren van TCP. De letters staan voor de mogelijke vlaggen die bekeken kunnen worden in de kop van een TCP-pakket.
In de moderne regels wordt de optie flags
S
gebruikt om het verzoek tot het starten van
een TCP sessie.
Met stateful filteren wordt verkeer benaderd als een
uitwisseling van pakketten tussen twee kanten die een sessie
zijn. Als het is ingeschakeld, dan maakt het
keep state
mechanisme dynamisch interne
regels voor pakketten die in de sessie horen te volgen. Het
kan bekijken of de karakteristieken van de sessie tussen
verzender en ontvanger de juiste procedure volgen. Alle
pakketten die niet passen in de sessie, worden automatisch
geblokkeerd.
keep state
staat ook
ICMP-pakketten toe die gerelateerd zijn aan een
TCP- of UDP-sessie. Dus als er
een ICMP-type 3 code 4 komt in antwoord op
websurfen, dat wordt toegestaan van binnen naar buiten door een
keep state
regel, dan wordt dat toegelaten.
Pakketten waarvan IPF zeker is dat ze onderdeel zijn van de
sessie worden toegelaten, zelfs als ze van een ander protocol
zijn.
Wat er gebeurt: pakketten die naar buiten gaan op de interface die met Internet is verbonden worden eerst vergeleken met de dynamische staattabel. Als een pakket voldoet aan de verwachting van het volgende pakket in de sessie, dan mag het de firewall verlaten en wordt de toestand van de sessie in de dynamische toestandstabel bijgewerkt. Pakketten die niet bij een reeds actieve sessie horen, worden tegen de uitgaande regelverzameling gecontroleerd.
Pakketten die binnenkomen op de interface die met Internet is verbonden worden eerst vergeleken met de dynamische staattabel. Als een pakket voldoet aan de verwachting van het volgende pakket in de sessie, dan mag het de firewall verlaten en wordt de toestand van de sessie in de dynamische toestandstabel bijgewerkt. Pakketten die niet bij een reeds actieve sessie horen, worden vergeleken met de regelverzameling voor binnenkomend verkeer.
Als de sessie wordt beëindigd wordt het uit de dynamische staattabel verwijderd.
Met stateful filteren is het mogelijk om de focus te leggen op het blokkeren of toestaan van nieuwe sessies. Als een nieuwe sessie tot stand mag komen, dan worden alle volgende pakketten automatisch doorgelaten en al het vervalste verkeer wordt automatisch tegengehouden. Als een nieuwe sessie wordt geweigerd, dan wordt geen enkel pakket doorgelaten. Met stateful filteren zijn er uitgebreide mogelijkheden voor onderzoek om bescherming te bieden tegen de veelheid aan aanvallen die tegenwoordig door aanvallers worden uitgevoerd.
De onderstaande regels zijn een voorbeeld van hoe een
erg veilige inclusieve firewall opgezet kan worden. Een
inclusieve firewall staat alleen diensten toe die passen bij
de pass
-regels en blokkeert al het
overige verkeer. Firewalls die bedoeld zijn om andere machines te
beschermen, ook wel “netwerk-firewalls” genoemd, dienen
tenminste twee interfaces te hebben, die over het algemeen zijn
ingesteld om de ene kant te vertrouwen (het LAN) maar
niet de andere (het publieke Internet). Ook kan een firewall worden
ingesteld om alleen het systeem te beschermen waarop het
draait—dit wordt een “host-gebaseerde firewall”
genoemd, en is in het bijzonder geschikt voor servers op een onvertrouwd
netwerk.
Alle UNIX® systemen en dus ook FreeBSD zijn zo ontworpen
dat ze voor interne communicatie de interface
lo0
en IP adres
127.0.0.1
gebruiken. De
firewall moet dit interne verkeer gewoon doorgang laten
vinden.
Voor de interface die is verbonden met het publieke
Internet worden regels gemaakt waarmee de toegang voor uitgaande en
binnenkomende verbindingen worden geautoriseerd en beheerst.
Dit kan de PPP-interface tun0
zijn of de
netwerkkaart die is verbonden met een xDSL- of kabelmodem.
In gevallen dat er één of meer netwerkkaarten zijn aangesloten op private netwerksegmenten kunnen er regels op de firewall nodig zijn om pakketten die van die LAN-interfaces afkomen vrije doorgang te geven naar elkaar en/of naar buiten (het Internet).
De regels worden opgedeeld in drie onderdelen: eerst de vertrouwde interfaces, dan het publieke uitgaande interface en als laatste het onvertrouwde publieke binnenkomende interfaces.
In iedere sectie moeten zo staan dat de regels die het meest gebruikt worden vóór de regels die minder vaak gebruikt worden staan. De laatste regel van een onderdeel geeft aan dat al het overige verkeer op die interface in die richting geblokkeerd en gelogd moet worden.
In het onderdeel Uitgaand staan alleen regels met
pass
die parameters bevatten om
uniek individuele diensten identificeren die het publieke Internet mogen
benaderen. Bij al die regels staan de opties
quick
, on
,
proto
, port
en
keep state
aan. De regels met
proto tcp
maken ook gebruik van de optie
flag
om te bekijken of het een pakket
betreft voor het opzetten van een sessie om de stateful
functionaliteit aan te sturen.
In het onderdeel Inkomend staan eerst alle regels voor het
blokkeren van ongewenste pakketten, om twee redenen.
Als eerste kan het zo zijn dat kwaadaardige pakketten gedeeltelijk
overeenkomen met legitiem verkeer. Deze pakketten moeten worden
weggegooid in plaats van binnengelaten te worden, gebaseerd op hun
gedeeltelijke match met de allow
-regels. De tweede
reden is dat bekende en oninteressante verwerpingen stil geblokkeerd
kunnen worden in plaats van gevangen en gelogd te worden door de
laatste regels in de sectie. De laatste regel in elke sectie blokkeert
en logt alle pakketten en kan worden gebruikt voor het wettelijke bewijs
nodig om degenen die uw systeem aanvallen aan te klagen.
Waar ook gezorgd voor moet worden is dat al het verkeer dat wordt
geweigerd geen antwoord verstuurd. Ongeldige pakketten dienen gewoon te
verdwijnen. Zo weet een aanvaller niet of een pakket het doelsysteem
wel heeft bereikt. Zo kan een aanvaller geen informatie verzamelen
over een systeem: hoe minder informatie er over een systeem
beschikbaar is, hoe meer tijd iemand erin moet steken voordat
er iets slechts gedaan kan worden. Regels die een optie log
first
bevatten, zullen alleen de eerste keer dat de
gebeurtenis voorkomt de gebeurtenis loggen. Deze optie is opgenomen in
de voorbeeldregel nmap OS fingerpint
. Het
gereedschap security/nmap
wordt vaak
door aanvallers gebruikt om het besturingssysteem van uw server
proberen te achterhalen.
We raden aan om telkens als er logmeldingen van een regel
met de optie log first
komen,
ipfstat -hio
uit te voeren om te
bekijken hoe vaak de regel van toepassing is geweest. Een groot aantal
overeenkomsten geeft gewoonlijk aan dat de firewall overspoeld wordt,
met andere woorden aangevallen wordt.
Het bestand /etc/services
kan gebruikt worden
om onbekende poortnummers op te zoeken. Ook kan http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
worden bezocht en het poortnummer worden opgezocht om het doel van een
bepaalde poort uit te vinden.
Op de volgende link worden poortnummers van Trojans beschreven: http://www.sans.org/security-resources/idfaq/oddports.php.
De onderstaande set regels is een complete en erg veilige
inclusieve
set met regels voor een firewall die is
getest op productiesystemen. Deze set met regels is eenvoudig aan te
passen voor uw eigen systeem. Maak gewoon commentaar van elke
pass
-regel voor een dienst die niet gewenst
is.
Logberichten die niet gewenst zijn, zijn uit te sluiten door een
block
-regel toe te voegen in het begin van het
onderdeel Inkomend.
Voor de onderstaande regels dient de
dc0
interfacenaam in iedere regel
vervangen te worden door de echte interfacenaam van de netwerkkaart
in het systeem die met het publieke Internet is verbonden.
Voor gebruikers van PPP zou dat tun0
zijn.
Dit zou de inhoud van /etc/ipf.rules
kunnen zijn:
NAT staat voor Network Address Translation (netwerkadres vertaling). In Linux® heet dit IP Masquerading. Een van de vele mogelijkheden die IPF NAT kan bieden is het delen van één IP adres op het publieke Internet met een LAN achter een firewall.
De vraag zou kunnen rijzen waarom iemand dat zou willen. ISP's wijzen normaliter namelijk dynamisch een IP adres toe aan hun niet-commerciële gebruikers. Dynamisch betekent hier dat het IP-adres iedere dat er wordt ingebeld of dat het kabel- of xDSL-modem uit- en aangeschakeld wordt anders kan zijn. Dit dynamische IP-adres wordt gebruikt om uw systeem op het publieke Internet te identificeren.
Stel dat er vijf PC's in een huis staan en iedere computer in dat huis heeft toegang tot Internet nodig. Dan zouden er bij een ISP vijf individuele accounts moeten zijn en vijf telefoonlijnen om dat te realiseren.
Met NAT is er maar één account bij een ISP nodig. De andere vier PC's moeten met kabels op een switch worden aangesloten waarop ook een FreeBSD systeem is aangesloten dat binnen uw LAN als gateway gaat opereren. NAT zal automatisch de private LAN IP adressen van alle PC's vertalen naar een enkel publiek IP-adres als de pakketten de firewall naar het Internet verlaten.
Er is een speciale reeks van IP-adressen gereserveerd voor NAT op private LANs. Volgens RFC 1918 kunnen de volgende reeksen IP-adressen gebruikt worden op private netwerken die nooit direct op het publieke Internet gerouteerd worden.
Eerste IP | – | Laatste IP |
10.0.0.0 | – | 10.255.255.255 |
172.16.0.0 | – | 172.31.255.255 |
192.168.0.0 | – | 192.168.255.255 |
NAT regels worden geladen met
ipnat
. De NAT regels worden vaak
opgeslagen in /etc/ipnat.rules
. Meer details
staan in ipnat(8).
Bij het maken van wijzigingen aan de
NAT-regels nadat NAT
gestart is, wordt aangeraden de wijziging aan het bestand met
regels te maken en daarna ipnat
-CF
te gebruiken om alle actieve
NAT-regels te wissen. Daarna kunnen de regels uit
het bestand weer als volgt geladen worden:
#
ipnat -CF -f /etc/ipnat.rules
Gebruiksgegevens over NAT kunnen getoond worden met:
#
ipnat -s
De huidige inhoud van de NAT tabellen kan getoond worden met:
#
ipnat -l
Met het volgende commando kan de uitgebreide rapportage worden ingeschakeld en dan wordt informatie over het verwerken van verkeer en de actieve regels getoond:
#
ipnat -v
NAT regels zijn erg flexibel en er kunnen veel dingen mee gedaan worden om behoeften van bedrijven en thuisgebruikers in te vullen.
De syntaxis van de regels die hier wordt toegelicht is vereenvoudigd om te passen bij een niet-commerciële omgeving. De complete syntaxis is na te lezen in ipnat(5).
De syntaxis voor een NAT regel ziet er ongeveer als volgt uit:
IF
LAN_IP_REEKS
-> PUBLIEK_ADRES
De regel begint met het sleutelwoord
map
.
IF
dient vervangen te worden
door de aanduiding van de externe interface.
LAN_IP_REEKS
is de reeks die
clients op een LAN gebruiken, meestal iets van 192.168.1.0/24
.
PUBLIEK_ADRES
kan het publieke
IP adres zijn of een speciaal sleutelwoord
0.32
, wat betekent dat het
IP adres van IF
gebruikt moet worden.
Een pakket komt vanaf het LAN aan bij de firewall en
heeft een publieke bestemming. Het wordt verwerkt door de
filterregels voor inkomend verkeer en daarna krijgt
NAT de kans zijn regels op het pakket toe
te passen. De regels worden van boven naar beneden toegepast
en de eerste regel die van toepassing is wint.
NAT controleert voor alle regels het
pakket op interfacenaam en bron IP adres.
Als de interfacenaam van een pakket past bij een
NAT regel dan wordt het bron
IP adres van dat pakket gecontroleerd, dat
is dus een IP adres op het private LAN,
om te bekijken of het valt in de reeks die is opgegeven aan
de linkerkant van een NAT regel. Als ook
dat klopt, dan wordt het bron IP adres van
het pakket vervangen (“rewritten”) door een
publiek IP adres dat verkregen kan zijn
met het sleutelwoord 0.32
.
NAT werkt dan zijn interne
NAT tabel bij, zodat als er een pakket uit
die sessie terugkomt van het publieke Internet, dat pakket
weer gepast kan worden bij het originele private
IP adres en door de firewallregels
gefilterd kan worden om daarna, als dat mag, naar een client
gestuurd te worden.
Voor IPNAT zijn de onderstaande
instellingen in /etc/rc.conf
beschikbaar.
Om verkeer tussen interfaces te kunnen routeren:
Om IPNAT automatisch te starten:
Om aan te geven waar de IPNAT regels staan:
Voor netwerken met grote aantallen PC's of netwerken met meerdere LAN's kan het een probleem worden om al die private IP adressen met één enkel publiek IP adres te vervangen, omdat vaak dezelfde poortnummers gebruikt worden. Er zijn twee manieren om dit probleem op te lossen.
Een normale regel voor NAT ziet er als volgt uit:
Met de bovenstaande regel blijft de bronpoort
ongewijzigd als het pakket door IPNAT
gaat. Door gebruik te maken van het sleutelwoord
portmap
kan IPNAT
ingesteld worden om alleen bronpoorten in de aangegeven reeks
te gebruiken. Zo stelt de onderstaande regel in dat
IPNAT de bronpoort aanpast naar een
poortnummer dat in de aangegeven reeks valt:
Het kan nog eenvoudiger door gebruik te maken van het
sleutelwoord auto
zodat
IPNAT zelf bepaalt welke poorten gebruikt
kunnen worden:
In grote netwerken komt er een moment waarop er gewoon te veel adressen zijn om te bedienen met één IP adres. Als er een blok van publiekelijke IP adressen beschikbaar is, dan kunnen deze adressen gebruikt worden in een “poel”, welke door IPNAT gebruikt kan worden om één van de adressen te gebruiken als uitgaand adres.
Bijvoorbeeld om alle pakketten te verstoppen achter één een enkel IP adres:
Een reeks van publiekelijke IP adressen kan gespecificeerd worden met een netwerkmasker:
of door gebruik van de CIDR notatie:
Het is erg gebruikelijk om een webserver, mailserver,
database server en DNS server op verschillende computers
op een LAN te draaien. Het uitgaande verkeer van die
servers kan dan met NAT afgehandeld
worden, maar er moet ook ingesteld worden dat inkomend
verkeer bij de juiste computer terecht komt.
IPNAT gebruikt daarvoor de opties in
NAT waarmee verkeer omgeleid kan worden.
Als bijvoorbeeld een webserver op het LAN-adres 10.0.10.25
draait en het enkele publieke
IP adres zou 20.20.20.5
zijn, dan zou de regel er als volgt
uit zien:
of:
Voor een DNS server op een LAN die ook vanuit Internet
bereikbaar met zijn en die draait op 10.0.10.33
zou de regel er als
volgt uit zien:
FTP is dinosaurus uit het tijdperk van voor Internet was zoals het nu is, toen onderzoeksinstellingen met elkaar verbonden waren via huurlijnen en FTP de aangewezen methode was om bestanden met elkaar uit te wisselen. Maar bij het gebruik van FTP worden gebruikersnaam en wachtwoord als platte tekst verzonden en het protocol is nooit aangepast. FTP is er in twee smaken: actief en passief. Het verschil zit 'm in hoe het datakanaal wordt opgezet. De passieve variant is veiliger voor een gebruiker omdat bij deze variant beide communicatiekanalen door de cliënt zelf worden opgezet. Op de volgende pagina zijn details over FTP na te lezen: http://www.slacksite.com/other/ftp.html.
IPNAT heeft een speciale FTP-proxy
ingebouwd die kan worden ingeschakeld met een
NAT-map
-regel. Die kan
al het uitgaande verkeer monitoren wat betreft
opstartverzoeken voor sessies voor actieve en passieve FTP en
dynamisch tijdelijke filterregels maken die alleen het
poortnummer dat echt in gebruik is voor het datakanaal
doorlaten. Hiermee wordt een veiligheidsrisico dat normaal
gepaard gaat met FTP, namelijk het toestaan van grote reeksen
hoge poortnummers, weggenomen.
De volgende regel handelt al het FTP verkeer van het LAN af:
De regel hieronder handelt het FTP verkeer van de gateway zelf af:
Deze laatste regel handelt al het niet-FTP verkeer voor het LAN af:
De FTP-afbeeldregel hoort voor de normale regels te staan. Alle pakketten worden als eerste vergeleken met de eerste regel en zo verder. Eerst wordt gekeken over de interfacenaam overeenkomt, daarna het bron IP adres van het LAN en dan of het een FTP pakket is. Als dat allemaal klopt, dan maakt de speciale FTP proxy een tijdelijke filterregel die de pakketten uit de FTP sessie naar binnen en buiten doorlaat en ook NAT toepast op de FTP pakketten. Alle pakketten van het LAN die niet van het protocoltype FTP zijn en dus niet bij de eerste regel passen, worden tegen de derde regel gehouden die van toepassing is vanwege de interface en bron IP adres, zodat er dan NAT op toegepast wordt.
Als de NAT-FTP-proxy wordt gebruikt is er maar één filterregel voor FTP nodig. Zonder de FTP-proxy zouden er drie regels nodig zijn: