Zie ook:

http://www.security.nl/forum/i/59667/NAT

Hmm, het is dus overbodig?

Nou, ik denk dat de conclusie van dat forum het volgende is:

Een firewall van je werkstation heeft meer mogelijkheden dan de
firewall in je router. Zo kun je bijvoorbeeld instellen dat alleen
bepaalde programma's mogen internetten. Daarnaast maakt het het
inbreken vanaf het LAN moeilijker. Als je hier allemaal geen behoefte
aan hebt, dan is een firewall op je werkstation niet echt noodzakelijk.

Op zondag 10 april 2005 09:26 schreef Anoniem m.b.t. een
Gentoo box:
> is een software firewall nou echt nodig op mijn
> systeem?

en (dezelfde Anoniem?):

> Hmm, het is dus overbodig?

Kort antwoord: hangt ervan af wat je wilt. Lang antwoord:

Ingress filter (inkomend verkeer)
Scenario: je hebt daemons draaien (en hebt die locaal ook
echt nodig) die wachten op inkomende connecties ("netstat
-an | head") en je vertrouwt je router niet voor 100% (een
gezonde aanname), of je hebt je modem zo ingesteld
dat jouw Gentoo machine voor die poorten als server
fungeert: dan kun je in de Linux firewall instellen welke
remote IP-adressen (of reeksen) verbinding met die poorten
mogen maken (je kunt dit daarnaast ook in je router/modem
doen als deze dit ondersteunt).

Natuurlijk mag dit geen argument zijn om security patches
voor die daemons over te slaan, maar in de praktijk kan deze
ingreep het risico flink verlagen, bijv. als je een paar
weken op vakantie bent, en je alleen redelijk vertrouwde
remote sites toegang geeft.

Ook kun je bewust inkomend verkeer op poorten blokkeren (of
adres restricties opleggen) zolang je met bepaalde services
aan het experimenteren bent.

Stateful inspection
Iptables heeft het voordeel dat deze "stateful inspection"
kent, d.w.z. per opgezette verbinding gegevens bijhoudt en
daarmee sommige typen pakketjes van de betrokken remote host
wel doorlaat, terwijl vergelijkbare pakketjes van
andere hosts (waar geen verbinding mee bestaat)
worden gedropped. Daarnaast is de "related" eigenschap
handig als je bijv. een FTP daemon draait; met "related"
worden secundaire (parallelle) verbindingen naar een remote
host toegestaan als daar al een bepaalde primaire verbinding
mee bestaat.

Stateful inspection van UDP is per definitie brak maar kan
wel helpen om bijv. "gratuitous" (ongevraagde en gespoofde)
DNS replies zoveel mogelijk buiten de deur te houden.

Logging
M.i. worden de logging mogelijkheden van iptables vaak
onderschat of geheel over het hoofd gezien. Je kunt veel
leren van wat er zich op je netwerk afspeelt. Bijv. een
verkeerde configuratie van je router (of crack ervan) kan zo
eerder aan het licht komen. Als je het root account alleen
gebruikt indien strikt noodzakelijk, kan logging van
onverwacht uitgaand verkeer een aanwijziging zijn dat je
(als gewone user) een trojaned binary hebt gedraaid (zie
verderop).

Logging van (o.a. locaal) verkeer dat aan dichtstaande
poorten rammelt kan je doen inzien dat je wat over het hoofd
gezien hebt. Veel admins gaan er bijv. van uit dat DNS
verkeer alleen UDP is, maar TCP komt ook echt voor. Als je
"knocks on 53/tcp" logt en ziet dat dit legitiem verkeer is,
kun je besluiten dit (selectief) open te zetten.
Vergelijkbare zaken gelden voor div. soorten ICMP.

Als er ook Windows machines op je netwerk voorkomen zul je
snel zien dat je sommige pakketjes (broadcasts) niet wilt
loggen omdat je logfiles dan te hard groeien. Aan de andere
kant, veel Windows malware scant het subnet op typische MS
poorten; selectieve logging daarvan kan enorm behulpzaam
zijn bij het localiseren van gecompromitteerde MS PC's
(waarbij logging van MAC-adressen in DHCP omgevingen een
extra hulp kan betekenen).

Belangrijk: als je pas op je netwerk gaat kijken op het
moment dat je een inbraak vermoedt, zie je overal spoken
(het barst in het begin van de "onverklaarbare" pakketjes).
Het is op zo'n moment extreem handig om je netwerk en je
computers door en door te kennen. De keerzijde van de
medaille is dat het opzetten en bijhouden hiervan zeer veel
tijd kost en waarschijnlijk overkill is voor thuissituaties.
Heb je de tijd en vind je het leuk, dan kan deze kennis
wel van pas komen op de werkvloer en/of in een
toekomstige baan - mits je deze kant opwilt.

Persoonlijk vind ik het prettig om als gewone user firewall
logs te kunnen lezen maar sommigen zullen zelfs dit
onverantwoord vinden.

Egress filter (uitgaand verkeer)
Als je niet wilt dat gewone users (en evt. trojans die zij
starten) bepaalde verbindingen van binnen naar buiten kunnen
opzetten, kun je ook uitgaand verkeer filteren (en loggen
natuurlijk). Zorg dan wel dat je kernel e.d. up-to-date
blijven en er geen andere gapende privilege escalation holes
zijn, anders heeft dit niet zo veel zin.

M.i. wordt de zin van firewalls die uitgaand verkeer
filteren zowiezo enorm overschat, waarschijnlijk omdat deze
feature als verkoopargument gehyped wordt door met
name PFW fabrikanten (een stelling die veelvuldig door
nablatende en incompetente gebruikers wordt overgenomen). In
mijn ervaring vormt egress filtering vaker een blok aan het
been van legitieme gebruikers dan van eventuele malware die
onbedoeld op het systeem wordt gedraaid (waarmee je systeem,
tot het tegendeel is bewezen, feitelijk al gecompromitteerd
is; in elk geval is elk bestand waar de user schijfrechten
op heeft daarna verdacht).

Hoewel iptables geen per process filtering
ondersteunt, is deze eigenschap onder Windows onvoldoende
effectief; telkens blijkt malware bijv. d.m.v. injection
technieken de weg via "trusted" applications naar buiten te
kunnen vinden. Als lid van Administrators internetten, ervan
uitgaande dat je PFW (Personal FireWall) je wel zal
beschermen, is natuurlijk helemaal naief (tuurlijk zal het
in een deel van de gevallen wel helpen; door rood rijden
betekent ook niet per definitie dat je tussen 6 planken het
kruispunt verlaat).

Wel kun je egress filters bewust aanbrengen als je niet wilt
dat jouw users contact maken met bepaalde IP-ranges en/of
bijv. IRC servers op 6667/tcp. Overigens, het dichtzetten
van alleen deze poort om malware te blokkeren heeft
onvoldoende zin; zie
http://www.sarc.com/avcenter/venc/data/w32.randex.dfj.html
voor een Windows voorbeeld. N.B. er mogen dan niet veel
Linux virussen in omloop zijn; exploits, trojans en
(userland) rootkits daarvoor bestaan wel degelijk.

Rate limiting
In iptables kun je aangeven dat bepaalde pakketjes anders
moeten worden behandeld (bijv. droppen en loggen) als deze
in een te hoog tempo worden aangeboden. Dit kan bijv. een
hulpje zijn bij het bestrijden van DoS attacks. Houd wel
logging ervan in de gaten; bij legitiem vekeer kan
foutzoeken erg lastig zijn.

Ten slotte
Vergeet niet dat er bij elke TCP verbinding sprake is van
zowel inkomende als uitgaande pakketjes, en dat een
succesvolle verbinding vereist dat beide worden doorgelaten.
De termen ingress en egress hierboven hebben betrekking op
de richting bij het opzetten van de verbinding,
d.w.z. wie de initiator is.

Het vaststellen van wat een firewall wel en niet moet doen,
en daarna het bouwen ervan, is geen eenvoudige opgave; denk
niet dat dit in een uurtje gepiept is en je er nooit meer
naar hoeft om te kijken. Bovendien is het een vaak overschat
security hulpje dat ook in je nadeel kan werken. Heb je geen
tijd/zin, ga dan s.v.p. geen domme "hoe doe ik A" en "ik zie
pakket B, wat nu" vragen op fora (voor gevorderden) stellen;
begin er dan liever helemaal niet aan.

Erik van Straten