Wat maakt een goede firewall?

In deel 1 van deze minicursus bleek al dat een Firewall geen pasklare oplossing biedt voor de beveiligingsproblemen waar de meeste bedrijven en organisateis vandaag mee kampen. Je kunt niet zomaar een doos kopen bij de computerzaak op de hoek, een installatieprocedure doorlopen vanop een CD-ROM, en van de ene seconde op de andere verwachten dat alle beveiligingszorgen de wereld uit zijn. Er zit meer achter. Van belang is bijvoorbeeld de technische architectuur van de Firewall-oplossing.

Meer en meer bedrijven worden geconfronteerd met de ‘Microsoft-everywhere’ situatie. Ondertussen is Novell al zo goed als van de NOS-kaart (Netwerk Operating Systemen) geveegd, en krijgt UNIX het steeds moeilijker in de markt van de bedrijfswijde applicaties. Als zelfs pakketten als SAP steeds meer in de richting van NT gaan, dan stemt dit ongetwijfeld tot nadenken. Hamvraag is nu: wat doe je met de beveiligingspakketten? Na de roemruchte verhalen over beveiligingsfouten in NT, zijn er misschien niet al te veel bedrijven die Microsofts New Technology willen opstellen als meest kwetsbare (deze keer in termen van veiligheid, niet de legendarische robuustheid) machine van het netwerk. Liever een Unix-bak dus?

Misschien niet. De laatste maanden is immers – tot grote spijt van de Unix-adepten onder ons – gebleken dat het (N)OS niet meteen de bepalende factor is in de ganse beveiligingsdiscussie. We kennen barslechte Firewall-producten op NT, maar die bestaan evengoed in de verschillende Unix-smaken. En: er zijn uitstekende Firewalls beschikbaar op Unix, en uit tests blijkt dat die er meer en meer komen op NT ook.

Goede Firewall-producten laten niet toe dat de integriteit van het onderliggende OS (Operating System) ook maar een beetje in gevaar wordt gebracht. Ze nemen wat dit betreft dan ook in meer dan een opzicht de netwerkfunctionaliteit van het OS over, en laten het OS pas kennismaken met de netwerkprotocollen nadat ze er zelf de goedkeuring aan hebben gegeven. De allerbelangrijkste factor die de kwaliteit van de beveiliging van het netwerk bepaalt, blijft dan ook de architectuur van de gekozen oplossing.

De opstelling: alles in een?
Je weet ondertussen dat de beveiliging van een netwerk een sterk technisch gekleurde zaak is. Beveiliging vindt immers plaats op verschillende – meer en minder technische – lagen van het beruchte OSI-model (zie deel 2 van onze netwerkcursus voor meer uitleg hierover). Enerzijds moet je op het niveau van de Netwerk-laag kunnen bepalen welke IP-adressen van je interne netwerk toegankelijk zijn voor de buitenwereld (bijvoorbeeld: enkel de webservers en mail-servers – hun IP-adressen zijn op voorhand bepaald), maar anderzijds moet je ook op de Applicatielaag kunnen bepalen welke toepassingen er door je interne gebruikers mogen en kunnen gebruikt worden (bijvoorbeeld: enkel SMTP en HTTP, geen NNTP of FTP).

De vraag is nu of je al die activiteiten op al die verschillende OSI-lagen wil laten uitvoeren door een en dezelfde machine – zijnde de magische Firewall. Technisch gezien kan je perfect een uit de kluiten gewassen computersysteem in elkaar knutselen dat alles in een kast implementeert. Maar het passende antwoord op de vraag ligt echter niet zo voor de hand: in de meeste gevallen zal je niet willen kiezen voor die ene machine. Meestal zal je bijvoorbeeld een Firewall-opstelling implementeren die enerzijds bestaat uit een screening router – die alle zaken op het Netwerk-niveau regelt – en waartoe anderzijds ook nog een application gateway behoort, die bijvoorbeeld Proxy speelt voor alle surfers op het netwerk.

Proxy
Proxy is een vakterm voor tussenpersoon: de interne gebruikers stellen een vraag aan de proxy, deze kijkt na of die vraag wel rechtmatig is volgens de beveiligingsprocedures, en stelt vervolgens de vraag aan het externe netwerk voor rekening van diezelfde interne gebruiker. De externe informatieleverancier praat met de proxy, de proxy praat met de interne gebruiker.

DMZ
Bovendien kun je nog extra beveiligingslagen invoeren door te werken met een of meerdere DMZs (demilitarized zones). Dit is een soort van buffernetwerk, dat je plaatst voor de poort van je intern, bedrijfskritisch netwerk en waarop je enkele zwaarbeveiligde machines, maar ook meer kwetsbare/minder kritische, machines wil afzonderen van de rest van je netwerk. Je plaatst bijvoorbeeld de externe HTTP-server van de internetsite in de DMZ, en de HTTP-server van het intranet op het interne netwerk.

Een externe router zondert de DMZ af van het externe netwerk, een interne router zorgt er voor dat – indien een machine in de DMZ gekraakt wordt – de hackers nog niet automatisch op het interne netwerk geraken. Elk dergelijk netwerk vormt een extra beveiligingslaag – vandaar ook dat sommige financiële instellingen verschillende DMZs na elkaar opstellen – als verschillende schillen rond hun kloppend hart.

De manier van werken
Een laatste bepalende factor in de kwaliteit van de Firewall, is tenslotte de manier van werken. Dit zal immers bepalend zijn voor bijvoorbeeld de uitbreidbaar- en aanpasbaarheid van het systeem – een essentiële vereiste in de snelbewegende internetwereld.

Het probleem van heel wat Firewall-producten is dat ze de beveiliging van jouw netwerk beschouwen als een applicatiegerelateerd gegeven. Producten van bijvoorbeeld Altavista, Raptor en Ukiah bestaan grotendeels uit een geheel van application gateways: voor elk applicatieprotocol (de bekendste zijn HTTP, SMTP en FTP) moet er zo’n gateway voorzien worden om de beveiliging te voorzien. Concreet zal de Firewall in dat geval slechts datapakketten doorlaten indien ze beantwoorden aan een van die gateways (je kan dus geen FTP-sessies doen als je geen FTP-gateway hebt) en de regels die gelden in die gateway dat toelaten. Dit zijn nogal beperkende voorwaarden: op het internet veranderen de applicatieprotocols met de regel van de klok (denk bijvoorbeeld aan de opkomst van audio- en videotoepassingen), en hinken de application gateways dus per definitie achter de feiten aan.

Statefull inspection
De nieuwste Firewall-technologie heeft echter een oplossing bedacht voor deze problematiek. Marktleider Checkpoint brengt met Firewall-1 een oplossing op de markt die uitgaat van een principe dat men statefull inspection noemt: in plaats van enkel op applicatieniveau de controle uit te voeren met behulp van application gateways, bouwt men een generieke inspectiemotor die op netwerkniveau (twee niveau’s lager op de OSI-schaal dus) alle types van (huidige en toekomstige) protocollen en applicaties kan beveiligen. De inspectiemotor houdt daarbij rekening met de status van de pakketjes die over en weer reizen over het netwerk, en wel op een intelligente manier: hij zal in tabellen opslaan dat een bepaalde gebruiker een bepaalde HTTP-request gemaakt heeft, en zal als gevolg daarvan wel een antwoord toelaten op die aanvraag. Een ongevraagd – en potentieel gevaarlijk – HTTP-antwoord dat geen logisch gevolg is van de status van een bepaalde gebruiker, zal dus niet worden toegelaten.

Een dergelijke inspectiemotor wordt aangestuurd met behulp van een aantal scripts die precies weten hoe de verschillende protocollen zich gedragen. Wanneer er dan nieuwe toepassingen ontwikkeld worden, kan de operator van de Firewall eventueel zelf een dergelijk script schrijven, of kan hij bij een leverancier als Checkpoint een eenvoudig uitbreiding van zijn installatie aanschaffen. Alleszins een veel eenvoudiger en mooier systeem dan de omslachtige application gateways.

Conclusie
De manier waarop je een Firewall-oplossing wil implementeren is uiteraard een keuze die je zelf moet maken. Hierboven hebben we een aantal argumenten en evaluatiecriteria op een rijtje gezet, en je ook een eerste tip gegeven in de richting van een goede beveiligingsoplossing. De concrete implementatie is – we kunnen het niet genoeg benadrukken – een ander paar mouwen. Vooraleer je daaraan begint, raden we je toch een dik pak boeken, en een stevige opleiding aan. Maar laat dat je vooral niet tegenhouden.