Firewall technieken

> Index <

Er zijn meerdere firewall technieken. Iedere techniek heeft zijn voor- en nadelen. Het aangrijpingspunt van de firewall op de OSI laag in de TCP/IP stack is in hoge mate bepalend voor de eigenschappen van een firewall. Vandaar dat ik de volgende indeling hanteer:

• Pakketfilters werken op de netwerk- en transportlaag van de TCP/IP stack

• Application gateway firewalls werken op de applicatielaag van de TCP/IP stack.

• Het generieke SOCKS proxy protocol werkt op de sessielaag van de TCP/IP stack.

Daarnaast besteed ik aandacht aan:

• Netwerk adres vertaling (NAT) en poort adres vertaling (PAT) behelsen het omzetten van publieke (echte) internetadressen in slechts op uw LAN geldige adressen.

De firewall terminologie wordt niet consequent gehanteerd. Snelle ontwikkelingen in de technologie, maar ook misleidende marketing spelen hierbij een rol. Zo worden kabelmodems en (A)DSL routers met pakketfilters en NAT als "internet gateways" aangeprezen. Een pakketfilter op een internetcomputer wordt een "personal firewall" genoemd. De term persoonlijke brandmuur suggereert een mate van bescherming die er niet is. Ik zou liever van brandwerend pak willen spreken. Zoek hiermee het vuur niet op. Net zo goed als een veiligheidsgordel u geen bescherming tegen een fataal ongeluk biedt.

Ook het aangrijpingspunt van een bepaalde techniek is niet altijd evident. Een reden is dat de gelaagdheid van een TCP/IP stack op zich een abstractie is. TCP/IP bestond al voor het OSI model. Zeker in hogere OSI netwerklagen (5-7) wordt de vergelijking mistig. Veel netwerkapplicaties werken op grensvlakken of op meerdere lagen tegelijk: bijv. een proxy die sessies beheert maar in de toepassingslaag draait. Bovendien wordt software niet ontworpen om aan het OSI netwerkmodel te voldoen, maar om bestaande software te ondersteunen. Bepalend is of het op de gangbare markt werkt. Op de scherp concurrerende softwaremarkt geldt vaak: wie het eerst maalt, die het eerst haalt. De snel en massaal uitgebrachte toepassingen bepalen de standaard. Maar dat kan dus heel goed een krakkemikkige MS only versie van een nog niet uitgerijpt protocol zijn.

Programma's die in de toepassingslaag lopen kunnen dus ook op lagere niveaus ingrijpen. Desondanks is het wel goed om bij de volgende bespreking het OSI model enigszins in de gaten te houden, omdat u anders appels met peren vergelijkt. Zo maken de stuurbestanden van een pakketfilter deel uit van het besturingssysteem, terwijl een proxy een TCP/IP toepassing is. Ik ga voorlopig van de volgende schema uit:

Het OSI model geeft inzicht in de timing en de aard van de beveiliging. Elektronische indringers moeten de TCP/IP stack immers van laag naar hoog doorlopen. Het uitschakelen van het netwerkapparaat (of fysieke isolatie) vormt daarom de meest elementaire vorm van verdediging tegen indringers van buiten. De routers en packet filters in de netwerklaag vormen de tweede verdedigingslinie. Proxies en virusscanners die op de sessie- en applicatielaag van het OSI model ingrijpen vormen de laatste verdedigingslinie.

De beste firewalls maken gebruik van meerdere technieken (hybride firewalls). Meestal worden de individuele IP pakketjes eerst door screening routers van packet filters op de netwerklaag gefilterd, vervolgens wordt de controle aan een hoger niveau (proxy op de sessie- of applicatielaag) doorgegeven.

Pakketfilters

> Index <

Packet filters onderscheppen IP pakketjes bij de netwerkinterfaces van de firewall. Ze werken op een laag niveau van de TCP/IP stack (internet- en tansportlaag). Hun vaak in assembler geschreven drivers integreren met besturingssysteem. Hierdoor werken ze ondanks hun minutieuze controlewerk behoorlijk snel.

Een pakketfilter kan pakketjes al bij de netwerkkaart onderscheppen; voordat ze de kwetsbare delen van het besturingssysteem en de toepassingen bereiken. Datagrammen die deze barrière passeren kunnen de TCP/IP stack, de servers en client applicaties hinderen en misbruiken. Maar IP pakketjes die u er aan de poort al uitschift doen niemand kwaad. Vooral regels tegen gefragmenteerde pakketten, IP vermomming en niet voor het internet bestemde protocollen zijn van belang.

De door het protocol afgewezen pakketjes worden naar de eeuwige bitvelden (> device nul) gezonden: ze verdwijnen uit het geheugen. Dit gebeurt met ieder onbestelbaar pakketje. Doordat alle pakketjes een door het netwerk bepaalde levensduur (Time to Live) hebben, worden ronddolende "zombie" pakketjes op het netwerk voorkomen. De eerste schifting vindt al op de netwerktoegangslaag plaats. Frames die voor een andere netwerkkaart bestemd zijn worden door de snelle netwerkkaart weggegooid. Slechts de voor de netwerkkaart bestemde fractie bereikt via de databus de CPU. Daarna schift het IP filter de voor de TCP/IP stack bedoelde pakketjes. Maar frames van niet IP protocollen (bijv. NetBIOS) blijven buiten schot.

Packet filters grijpen in op de internetlaag (IP, ICMP) van de TCP/IP stack. Ze screenen oppervlakkig wat elementen uit de transportlaag (TCP, UDP). Aan de hand van filterregels wordt besloten of een pakketje geweigerd wordt of doorgaat (routing).

Een pakketfilter werkt als een receptionist of portier. Hij stelt geen moeilijke vragen. Hij screent voorbijgangers maar oppervlakkig. Waar komt u vandaan? Wat is uw bestemming? Maar het pakketfilter vraagt niet wat gaat doen. De briefhoofden van datagrammen (de doorreispapieren) worden alleen formeel getoetst. Zo wordt er gekeken of ze naar binnen gaan (inbound), naar buiten gaan (outbound) of op doorreis zijn (route). En wat de opgegeven, maar gemakkelijk te vervalsen (spoofen) herkomst en de eindbestemming is (IP adres en poortnummer) is. Er wordt er in de transportlaag gekeken naar het opgeven type en de aard van het bericht. Maar wat er echt onder die etikettering verborgen gaat, weten de portiers niet. Dat gaat hun ook niets aan.

Stateless versus statefull packet inspection

> Index <

Packet filters die op de internetlaag ingrijpen onderzoeken weliswaar alle pakketjes, maar niet in hun context. Ze bekijken in de briefhoofden het opgegeven IP adres van de afzender en de bestemming, maar hebben geen notie van het hoe en waarom, laat staan van de inhoud van de zending. Ze beoordelen of een pakketje op zich is toegestaan, maar zullen geen verdachte patronen in de stroom van pakketjes (de sessie) herkenen. Vergelijk het met een portier die de instructie opvolgt om alle bezoekers van de heer Van Dam toe te laten, maar niet achter zijn oor krabt als het er op een dag een paar duizend zijn. Deze manier van werken noemt men stateless packet inspection.

Dat is meteen de grote beperking van packet filters die dicht bij de netwerkkaart werken: Er wordt gekeken of een IP pakketje op zich (volgens deze beperkte regel) is toegestaan, maar het IP filter is blind voor de context. Bijvoorbeeld dat de sessieberichten van meneer Van Dam dan weer van het ene en dan weer van het andere op zich toegestane IP adres afkomstig is. Maar met op zich wettige handelingen (uw auto besturen, een touw knopen) kunt u in een bepaalde context vele onrechtmatige daden, ja zelfs moord en doodslag, plegen. Het gaat uiteindelijk niet om de afzonderlijke handelingen op zich, maar om het resultaat van de actie(s) en/of het nalaten van acties en hun gevolgen die weer afhangen van de context. Net als belastingontduikers combineren hackers de mazen in de wet om hun niet door u beoogde effecten te bereiken.

Omdat "stateless" packet filters de context van de pakketjes niet doorzien, moet u bij het opstellen van de IP filterregels behoorlijk paranoïd denken. Om u tegen fantasierijke hackers en uzelf (Murphy) te beschermen moet u met het pakketfilter vrijwel alles expliciet verbieden (deny all). Veilige permit regels bestaan eigenlijk niet. Dat geldt overigens voor iedere firewall met open poorten: stateless of niet. Maar met stateles open poorten loopt u gegarandeerd een kans op misbruik.

Stateful Packet Inspection (SPI) impliceert dat de firewall ieder pakketje in het licht van het bij de aanmelding (synchronisatie verzoek) en de daarop volgende afspraken (handshaking) tussen de communicerende hosts onderzoekt: de context of status van hun verbinding (de sessie). Stateless inspectie controleert per datagram de IP adressen en de poorten van de bron en zijn bestemming maar statefull inspectie controleert ook of dat binnen de context van het verbindingsverzoek toegestaan is.

Eerst wordt net als bij een stateless packet filter gekeken of de verbinding tussen de bron en het doel op zich is toegestaan. Zo nee, dan wordt het synchronisatie verzoek bij voorkeur genegeerd (DROP) of zo nodig geweigerd (REJECT). Is de verbinding toegestaan dan wordt de informatie uit het eerste datagram dat de sessie opbouwt (SYN) gedurende de sessie in een state-table database in het geheugen bewaard (keep-state). Als er binnen de context van die verbinding iets vreemds gebeurt (een host verandert plotseling zijn IP adres of onverwacht zijn doelpoort) zal een alarm afgaan en wordt de sessie onderbroken.

Het veranderen van de doelpoort komt voor bij het FTP protocol: De FTP client synchroniseert op de commandopoort 21 en schakelt voor de bestandsoverdracht ineens over naar de datapoort 20. Met een stateless packetfilter moet u de FTP datapoort openstellen voor iedereen die in theorie correct op poort 21 mag synchroniseren. Want of dat op poort 21 ook toeging zoals het behoorde kan een stateless packet filter niet weten. Het filter veronderstelt dit slechts. Hij moet wel, omdat anders niemand toegang krijgt tot de FTP bronnen. Maar een script voor een statefull packet filter kan expliciet definieren dat een toegestane SYNC op poort 21 toegang geeft tot de FTP datapoort 20 vanuit hetzelfde IP adres maar vanuit een hogere poort.

Een ander voorbeeld van statefull packet inspection: Uw hoge open poorten >1023 behoren alleen maar vanaf het IP adres van de host waarmee u de sessie hebt, benaderd te worden. Een poortscan vanaf een ander adres behoren poortscans niet te zien. Maar dit kunnen alleen firewalls die op meerdere nivo's van het OSI model werken (statefull packet filters) voorkomen. Ook intelligente routers met slimme (smart) pakket filters in hun kernel verstaan deze kunst (statefull multilayer inspection).

Proxy-based firewalls

> Index <

Om hun werk goed te kunnen doen moeten firewalls soms ook in de datasegmenten kunnen kijken: zo hoort een SMTP sessie zich met HELO of EHLO aan te kondigen. Gaat het om iets anders, dan kan het om een inbraakpoging gaan.

De op proxytechniek gebaseerde application gateway firewalls zijn hierin gespecialiseerd. Omdat ze op de hoogste laag van de TCP/IP stack werken, kunnen ze in de data zien en deze zo nodig bewerken. Op die manier kunnen ze ook onverenigbare protocollen verbinden. Dergelijke bemiddelende software noemt men middleware.

Zo kan een mail gateway software bevatten die exclusieve merkprotocollen als cc:Mail, Exchange en Compuserve naar internetprotocollen (smtp/mime) vertaalt. Ook kan zo'n server anti-virussoftware bevatten, het internetverkeer bijhouden, spammers weren en veel meer.

In theorie kunnen al deze keurmeesters dit, maar in de praktijk ontbreekt het hun modulen aan valide criteria. Want wat een filter wel of niet doorlaat blijft een subjectieve keus. We willen immers zowel het een als het ander. Een nieuw virus "heuristisch" vinden zonder vals alarm. Mail van onze vrienden, maar geen spam. Maar als we teveel willen kan geen systeembeheerder de benodigde configuratie nog overzien.

Overigens is ook de requester, die de bronnen van een SMB server naar een voor lokale syssteemaanroepen beschikbare netwerkschijf "mapt", een proxy. Zonder zo'n lokale bufferachtige vertaalstructuur zouden uw applicaties niets met de bestanden op een hen vreemde bijvoorbeeld Linux LAN server kunnen beginnen.

Het grote voordeel van een applicatie gateway is de uitgebreide controle van het netwerkverkeer: ideaal voor bedrijven. Een ander voordeel is dat er geen rechtstreekse verbinding tussen de proxy gebruikers en het internet is. De IP adressen van de proxy gebruikers worden niet alleen gemaskeerd, maar trucs als IP vermomming en telnetten via poort 80 zullen ook niet werken. Bovendien zal de proxy het verbindingsloze (en dus moeilijk te controleren) UDP weren. Vandaar dat de netwerkadresvertaling van een proxy meer veiligheid biedt dan die van de beste screening router.

Het nadeel van een geavanceerde applicatie proxy is dat hij alleen bepaalde TCP protocollen beheerst. Wilt u het netwerkverkeer van meerdere protocollen beheersen, dan hebt u prijzige software nodig. Daarnaast zullen bewerkingen in de applicatielaag meer overhead vergen dan het selectief routeren van data door low level drivers in de kernelspace, zoals een packet filter dat doet.

Ook een circuit level gateway is een schakelstation tussen een veilig en een onveilig netwerk. Deze techniek wordt evenwel uitgevoerd op transport- of sessielaag. Clients en servers maken contact via een SOCKS server die door een packet filtering firewall beschermd wordt. De TCP datasegmenten blijven onveranderd. Wel vindt er netwerkadresvertaling plaats. Net als bij een applicatie proxy is gebruikersauthenticatie het sterkste punt. Door het proxy principe zullen geautoriseerde clienten die via de SOCKS server (internet)verbindingen initiëren voor de buitenwereld "onzichtbaar" zijn. Hun interne IP adres wordt gemaskeerd door de netwerkadresvertaling van de circuit level gateway.

Application level gateway firewalls

> Index <

Een applicatie proxy is een nabije server. Hij zit op de firewall tussen uw applicaties en het internet in. Proxy servers genereren de data opnieuw met de gegevens die de clients en servers hun sturen. Om dat goed te kunnen doen, moeten ze de applicatie protocollen tot in de puntjes beheersen. Deze proxies zijn applicatie protocol specifiek. Zo zijn squid , smart cache en privoxy HTTP v1.1 proxies. Ze geven de HTTP verzoeken van bladerprogramma's en servers door.

De door de proxy bewerkte data wordt aan de andere kant van de firewall doorgegeven. De bewerking bestaat vrijwel altijd uit een netwerkadresvertaling in de TCP/IP headers, maar filterende HTTP proxies als Junkbuster/Privoxy veranderen de datasegmenten bovendien. Ze verbouwen de HTML code om ongewenste elementen (hier junk) te weren.

Packet filters laten selectief IP verkeer door. Pure proxy-based firewalls laten via hun forwarding packet filters helemaal geen IP verkeer door. De eigenlijke firewall-component (compertalisatie) is dan ook niet de proxy, maar het feit dat de gateway geen IP router is voor de werkstations en LAN servers die hij bedient (ipgate off). Omdat hierdoor de externe en interne netwerken volstrekt gescheiden blijven, bepaalt alleen de lokale proxy wat er aan netwerkverkeer door mag gaan. En een proxy als squid forceert een permit HTT(S)en FTP voor bepaalde IP-addressen, maar is niet in staat tot het doorgeven van de rest van het IP verkeer.

Als er geen algemene route (default route) naar het internet is, kunnen de LAN server op 192.168.1.2 en het werkstation op 192.168.1.3 het internet niet benaderen. De gateway met zijn proxy staat zelf wel op een onveilige plaats (bastion host in de DMZ), maar voor de rest van het LAN is de gateway een veilige interface, waarlangs zelfs geen als trusted host vermomd pakket zal lekken. Als de routing uitgeschakeld is kan er geen pakket meer door.

Hoe moet u dan internetten? De proxy server regelt het berichtenverkeer tussen de niet met het internet verbonden client applicaties met de TCP/IP servers op het internet via netwerkadresvertaling (NAT). Caching HTTP proxy servers als Squid, Leafnode en Smart cache kunnen zelfs internetdiensten aanbieden als ze al niet meer met het internet verbonden zijn. De proxy werkt als cache voor iedere "proxy-enabled" client op uw LAN.

Netscape stelt u met /Bewerken /Voorkeuren /Geavanceerd /Proxy's in op de poort van de computer die de proxy draait (8080, resp. 192.168.1.5). Hetzelfde geldt voor FTP clients en internet applicaties als wget.

Stel dat Netscape op werkstation 192.168.1.3 contact zoekt met het internet. Zonder proxy regent het foutmeldingen: Netscape kan zonder DNS de hostnaam niet vinden en heeft zelfs met een geldig IP adres geen route naar het internet. Maar Netscape kan via de ethernetkaart wel contact maken met de proxy server op 192.168.1.5:8080, die met het internet verbonden is. De proxy vraagt de informatie voor Netscape op en serveert het op zijn LAN adres alsof hij de internetserver zelf was.

Een goed ingestelde proxy-based firewall laat u dus met zijn routerloze netwerkadresvertaling vanaf veilige IP adressen op uw LAN werken. Afhankelijk van de filterfunctie van de proxyapplicaties blijven uw clients nog wel vatbaar voor directe schade door exploits en malicieuze java scripts, maar het zal zonder default route niet mogelijk zijn om hiermee vanaf het internet de controle van een zich achter de firewall bevindende PC over te nemen.

Ook de achter de firewall opererende LAN servers blijven beschermd, terwijl ze via de proxy nog wel hun internet-updates kunnen uitvoeren. Door de netwerkadresvertaling zijn ze alleen op het ethernet LAN te zien en te benaderen.

Een proxy biedt nog meer voordelen: U bepaalt welke protocollen aan het netwerk ter beschikking worden gesteld. Hierbij kunt u zowel een beveiliging op host- (IP) als op gebruikersniveau instellen. Een packet filter kan het IP adres van host "zolder" wel voor bepaalde sites blokkeren, maar kan bouke@zolder niet iets verbieden dat hij aan sjoerd@zolder wel toestaat. Dit kan alleen een proxy. Een proxy kan gebruikers identificeren en hun bevoegdheden aan de hand van zijn Access Control List (ACL) controleren (autorisatie). Een proxy kan bovendien controleren of degene die zich als sjoerd@zolder aanmeldt, daar ook te vinden is (authenticatie). Vergelijk het met het terugbellen van degene die zich als "politie" uitgeeft voordat u telefonisch antwoord geeft. Een IP packet filter kan dit niet. Via de proxy kan de systeembeheerder bepalen wie er bestanden mag uploaden en wanneer. Ook de logfunctie van een proxy is gedetailleerder: de wie, wat, waar en wanneer vragen zijn minutieus vast te leggen, terwijl een IP filter dit alleen op n.a.v. het opgegeven IP adres kan doen.

Het generieke SOCKS proxy protocol: circuit level gateways

> Index <

Een nadeel van de hierboven beschreven proxies is dat ze alleen met bepaalde TCP toepassingsprotocollen werken. Bovendien moeten uw TCP/IP applicaties - als ze al proxies ondersteunen - op het gebruik ervan worden ingesteld. Om deze beperkingen te omzeilen werd het op een lager niveau opererende SOCKS proxy protocol ontwikkeld.

SOCKS is een generiek (algemeen) proxy protocol. Het is dus niet aan een bepaald TCP/IP protocol gebonden. De met het internet verbonden SOCKS server kan zowel door "socksified" TCP/IP applicaties benaderd worden (via SOCKS in hun Proxy instellingen), als door de TCP/IP stack als geheel.

1. "Socksified" TCP/IP applicaties als MS Internet Explorer, Netscape, Mozilla en Opera kunnen een expliciet ("zichtbaar") opgegeven SOCKS server als proxy gebruiken.

2. De OS/2 Warp 4 TCP/IP stack ondersteunt het SOCKS 4 protocol. Latere TCP/IP versies (eComStation) ondersteunen SOCKS 5.

Een "socksified" TCP/IP stack verandert de routing zonder dat de gebruikers het merken. Zonder dat ze iets in de TCP/IP applicaties hoeven in te stellen wordt het internetverkeer via de SOCKS server op de firewall geleid (onzichtbare proxy). Vergelijk het met DOS en Windows programma's die via IBM's winsock.dll ongemerkt met de OS/2 TCP/IP stack worden verbonden. Op die manier worden ook niet "socksified" TCP/IP programma's met de SOCKS server verbonden. Dit is een elegante oplossing voor bedrijven die bijv. via de AIX firewall het internet opgaan, maar het is ook te bereiken op uw LAN.

Het instellen van een OS/2 werkstation als SOCKS client gaat via het Tabblad SOCKS van het TCP/IP configuratienotebook. Hiermee zullen alle TCP programma's automatisch van de SOCKS server gebruik maken. De "zichtbare" proxy instellingen van "socksified'' applicaties als Netscape en Mozilla laat u dan leeg.

In beide gevallen moet u een SOCKS server draaien. Dat kan onder OS/2 of een ander besturingssysteem als Linux.

SOCKS (proxies in het algemeen) bemiddelen geen verbindingsloze protocollen. Pure UDP programma's (streaming audio) zullen het alleen op het ethernet LAN doen. Gelukkig ondersteunen steeds meer van die programma's ook TCP verbindingen. Aangezien de DNS van UDP gebruik maakt, moet u met SOCKS 4 een lokale namenserveerder draaien.

Het door eComStation ondersteunde SOCKS 5 protocol ondersteunt naast TCP ook de voor de DNS benodigde UDP en kan gebruikers via wachtwoorden authenticiferen. De op zich "verbindingsloze" UDP pakketen worden via TCP verbindingen verzonden. Hiermee wordt voorkomen dat het interne netwerk blootgesteld wordt aan het onveilige UDP protocol.

In http://directory.google.com/Top/Computers/Software/Internet/Servers/Proxy/ vindt u allerlei SOCKS servers. Voor Warp 4 gebruikt u een versie 4 SOCKS server en moet er een naamserver draaien op uw LAN. Hier kunt u aan Linux denken, maar er is ook een OS/2 SOCKS server en OS/2 name server op http://www.tavi.co.uk/os2pages/sockd.html verkrijgbaar. Voor eCS en recente Warp TCP/IP versies kunt diverse Socks 4 en 5 servers for OS/2 gebruiken.

Alle SOCKS servers zijn op applicatieniveau te gebruiken. Het instellen van een SOCKS server in individuele applicaties gaat via hun proxy instellingen. De door u gebruikte TCP/IP programma's moeten SOCKS-compatibel ("socksified") zijn. Dat laatste is de regel met veel Windows, UNIX en vrijwel alle OS/2 programma's, waar u onder de PROXY instellingen ook een SOCKS versie 4 of 5 server kunt instellen.

Netwerkadresvertaling

> Index <

Ook bij de door een screening router toegepaste Netwerk Adres Vertaling (NAT, Network Address Translation) zullen de cliënts op het netwerk onzichtbaar zijn. LAN clients die slechts over een privé IP adres beschikken kunnen zich op het internet aanmelden met het IP adres van de netwerkadressen vertalende router (IP masquerading). De IP pakketjes worden wel naar hun bestemming gerouterd, maar de NAT software past vliegensvlug het bronadres in de IP headers aan. Het op het internet geldige IP adres van de router wordt "on the fly" naar een privé netwerkadres van de client op het LAN vertaald en omgekeerd.

De door een router (of dial-up programma) uitgevoerde netwerkadresvertaling is de gemakkelijkste manier om op een netwerk het internet te delen. Er is maar een IP adres nodig voor een heel netwerk. Er valt weinig te configureren. Anders dan bij een proxy zullen de meeste clients (protocollen) probleemloos lopen. Veel (A)DSL en kabelmodem hardwarerouters en personal firewalls gebruiken deze techniek. Ook de bekende firewalls van Linux en BSD kunnen deze techniek gebruiken. Vreemd genoeg kan de op BSD gebaseerde OS/2 TCP/IP versie 4.1 versie van de AIX Firewall dit weer niet. Hier zal een proxy (privoxy en/of squid) de netwerkadresvertaling moeten verzorgen.

Met een goed uitgevoerde netwerkadres vertaling zullen lokale servers vanaf het internet onzichtbaar zijn ("Stealth"). Trojaanse paarden zullen niets naar buiten lekken. Cliënten kunnen vrijwel alles, servers kunnen niets. Dat kan ook een nadeel zijn, zodat firewalls bepaalde IP adressen en/of poorten buiten de NAT kunnen laten vallen. Een computer die slechts serveerdiensten voor het internet moet leveren (www, smtp server) komt dan in de Demilitarised Zone (DMZ) te staan. Wordt die computer ook voor lokale diensten gebruikt dan is het alleen open zetten van een bepaalde poort voor die host de aangewezen weg. De servers van de niet openstaande poorten zullen alleen het LAN bedienen.

Poortadresvertaling (Port Forwarding, Port Address Translation, PAT) is soms nodig bij poortconflicten. Een bekend nadeel van NAT (of de betreffende applicaties) is dat sommige protocollen ook IP informatie in de data bevatten. De IP headers met het publieke internetadres en de private internetadressen in de data komen dan niet overeen.

Tot slot: wat is wijsheid?

De veiligste firewalls gebruiken meerdere technieken. Een proxy (of SOCKS server) wordt achter een packet filter gezet. Het packet filter beschermt de proxy. Als de firewall computer niet als router optreedt (ipgate off) kan het internetverkeer alleen maar via de proxy lopen. Hiermee worden alle directe IP routes tussen de client en server applicaties voorkomen. Een uitwendige proxy (bijv. die van de provider) kan van pas komen bij het ingewikkelde FTP protocol en om anoniem te kunnen surfen.

Welke type firewall voor u het meest geschikt zijn hangt af van wat u doet. De feiten en omstandigheden m.b.t. de hardware (firewall topologie), software (het besturingssysteem en de kans op buffer-overflows in applicaties) en het gedrag van de gebruikers (internet altijd hebben openstaan, niet geautoriseerde dial-up verbindingen, internetten met rootaccount, download- en chatgedrag, wachtwoordkeus en -opslag, deur niet op slot) hebben een immense invloed op de veiligheid van uw systeem en kunnen de beste firewalls om zeep helpen.

Tot slot drie wijsheden van de legendarische IBM consultant Bob Courtney ("What would Courtney say?")

• Nothing useful can be said about security except in the context of an application and an environment.

• Never spend more money eliminating a vulnerability than tolerating it will cost you.

• There are management solutions to technical problems, but there are no technical solutions to management problems.

Beschouw alles in zijn context. Zoek daarin het juiste midden. Maar verwacht geen oplossingen van buiten als u zelf niet weet wat u wilt. Vooral dat laatste sprak mij aan. Want de vraag hoe het internet op te gaan is net als de vraag hoe te leven een waagstuk. Een keuze die u zelf maken moet.

> Index <