Firewalls – alleen zo goed als de ingestelde policies

Policies? We don’t need no #%$# policies!

Security policies vind je op diverse niveau’s, van het verkrijgen van fysieke toegang tot een gebouw of ruimte tot de policies die in een firewall bepalen welk verkeer van en naar het Internet is toegestaan.

Wat zijn policies in IT eigenlijk?

Denk bij een policy in de security context aan een set afspraken die zijn gemaakt om toegang mogelijk te maken. Het zijn de spelregels voor veilige communicatie binnen ons lokale netwerk en naar de rest van de wereld. Hier focussen we op policies voor netwerkcommunicatie, want anders gaat deze blog nog langer worden.

Voordat ik de netwerkcommunicatie in duik, moet ik wel zo eerlijk zijn om te zeggen dat we natuurlijk veel meer policies kennen. Op Windows servers en werkstations worden policies gebruikt om restricties op te leggen aan gebruikers en wat ze mogen doen. Deze restricties hebben meestal te maken met toegang tot applicaties en resources die gebruikt mogen worden. In een EDR en SIEM context worden policies meestal gezien als een trigger voor alerts (onder welke omstandigheden wordt een alert gegenereerd). Hoewel het hier nog steeds om een set afspraken / voorwaarden gaat, ga je in deze blog met name lezen over firewall policies.

Firewall policies – complex en bepalend voor de toegang tot jouw ICT netwerk

Firewall policies dus. Je bepaalt voor de gebruikers van jouw infrastructuur wat er wel en niet wordt toegestaan als zij via jouw netwerk communiceren. De manier waarop gecommuniceerd wordt op het netwerk gaat meteen vrij ver de diepte in. Want het netwerk spreekt een eigen taal. Hier praten we TCP/IP.  Je zegt hier niet ‘ik wil iets online bestellen’. Jouw bericht of boodschap wordt opgehakt in veel kleinere stukken en meestal …in meerdere vormen van communicatie…

Puur om de complexiteit aan te geven waar firewall beheerders mee te maken hebben, geef ik hier een voorbeeld. Als dit te ver voor je gaat is dat eigenlijk helemaal niet zo erg, want dat illustreert meteen dat het dus inderdaad best complex is:

Gebruiker A wil gaan shoppen op Amazon.com.
Ja, meteen weer een toelichting: Ik wilde een naam gebruiken die klonk als een naam, maar er eigenlijk geen is om overeenkomsten met echte mensen te voorkomen. Iets als Pejonkler. Maar dat bekt zo slecht, dat ik A uiteindelijk wel prima vond.

A wil dus gaan shoppen. Op netwerkgebied betekent dit het volgende:
A maakt gebruik van een PC, tablet, telefoon of misschien wel zijn auto om verbinding te maken met het netwerk. Laten we zeggen dat het een laptop is, met IP-adres IP-A.
Omdat computers alleen (in deze context) via IP-adressen communiceren, hebben we niets aan ‘amazon.com’ en moeten je die naam in een adres zien te veranderen. Dat betekent dat IP-A aan een Domain Name Server (DNS) gaat vragen wat het IP-adres van amazon.com is. Voor dit voorbeeld kies ik ervoor dat de DNS server van Google met adres 8.8.8.8 wordt gebruikt. Met dat adres in de hand, kan er gecommuniceerd worden met amazon.com.

Dit doet A waarschijnlijk met een browser (chrome, firefox, etc) en die browser probeert dus contact te maken met amazon.com via een protocol dat TCP heet met een poort (80 of 443). Omdat er ook moet worden geantwoord, stuurt IP-A ook nog een random gekozen poort mee (ik vind 1234 wel een mooie).
Als alles goed gaat, stuurt amazon.com een antwoord terug naar IP-A, via TCP en naar die random gekozen poort 1234.
Geloof me als ik zeg dat ik hierbij echt nog een paar stappen heb overgeslagen. Voor de liefhebbers een samenvatting (met easter eggs):

• Gebruiker A wil shoppen
• IP-A stuurt een DNS request naar 8.8.8.8
• De firewall maakt weer gebruik van de bestaande NAT translatie van IP-A naar IP-FW en houdt een tabel bij van de translatie met protocol- en poort info
• 8.8.8.8 stuurt het IP adres van amazon.com naar IP-A
• De firewall maakt weer een NAT translatie van IP-FW naar IP-A
• IP-A stuurt een TCP request naar IP-Amazon op poort 80
• Het hele NAT stuk vindt steeds weer plaats, dus laat ik nu weg
• Amazon.com vindt poort 80 geen goed idee, dus stuurt een redirect naar poort 443
• IP-A stuurt na een zucht een nieuwe TCP request naar IP-Amazon op poort 443
• Amazon stuurt eindelijk antwoord en met wat geluk hebben we een pagina om te shoppen

Hier ontbreekt nog best veel aan NAT ellende, het feit dat IP-A een nieuwe poort moet kiezen bij elke sessie, encryptie informatie die nodig is als we naar poort 443 gaan....

Maar Jan... Waarom val je me hiermee lastig? Nou, dat zal ik je vertellen. Firewalls zijn best complex. Het is niet voldoende om wat termen te kennen, je moet echt iets snappen van protocollen, poorten, NAT, encryptie en de hele samenhang die communicatie tussen machines mogelijk maakt. Dit gaat je helpen bij het begrijpen en instellen van degelijke policies.

Daarnaast moet je kunnen inschatten wat veilig is en vooral ook wat niet veilig is om toe te staan. Tel daarbij op dat er altijd wel iemand op de verkeerde link in een mail klikt en de ellende onstaat dat schijnbaar legitieme communicatie misschien wel een buffet aan heerlijkheden voor hackers toegankelijk maakt. En als mijn editor besluit dat dit echt te ver gaat, heb ik dit misschien zelfs allemaal voor niets zitten typen. Ik zit hier dus echt te hopen dat het niet voor niets was!

Terug naar mijn punt: Firewalls en firewall beheer zijn dus lastig. In de basis is een firewall een apparaat dat niets doorlaat. Het is een (vuur)muur. De truuk is dus niet om iets tegen te houden, want daar begint het ding al mee. De truuk is om bijna alles tegen te houden en alleen datgene door te laten wat we nodig hebben om ons werk te doen en af en toe op Facebook zo’n boerderij spelletje te spelen.

De firewall werkt... Denk ik... Staat die policy nou wel goed?

Het komt regelmatig voor dat een firewall beheerder naar eer en geweten iets heeft ingesteld en dat – en hier komt ie – ‘het niet werkt’. Voor verreweg de meeste taken kan je zeggen ‘regel jij dat?’ en dan wordt het door een goede IT specialist ook zo geregeld. Bijvoorbeeld het instellen van een switch voor bepaalde VLAN’s gaat in de regel de eerste keer goed. Bij erg veel andere taken is dat ook het geval. Niet bij het configureren van firewalls... Je kunt de Mozart van firewall beheer zijn, fouten ga je maken. Veel zelfs. Het goed instellen van firewalls is in de IT verreweg het meest ‘trial and error’ van alle werkzaamheden die ik ooit ben tegen gekomen. Sterker nog, het is de normale modus operandi. En laten we heel duidelijk zijn: dat is echt geen onkunde. Fouten worden extreem snel gemaakt, ook door Mozart.

Policies. Rules. Of toch policies? GRRR!

Je kunt je voorstellen dat firewalls veel verschillende vormen van communicatie naar verschillende bestemmingen moeten toestaan om zowel Amazon als Facebook bereikbaar te maken.
De instelling (commando’s) in een firewall die nodig zijn om één stukje communicatie mogelijk te maken hebben we een naam gegeven: Policy. Dus een firewall policy kan betekenen: A’s PC mag met amazon.com een web sessie opzetten om te schoppen naar het boek ‘firewalls voor dummies’. Het Engelse meervoud van policy is policies en dus gebruiken wij dat ook braaf.
Maar natuurlijk komt hier dat lelijke beest dat ‘standaardisatie’ heet zijn tronie weer laten zien... Je kunt echt beter accountant zijn dan IT-specialist.

Sommige fabrikanten noemen het policies. Anderen vinden het woord rules veel beter. De ene uitleg vertelt je dat een rule een meer ‘low level’ omschrijving is waarbij policy wat abstracter en conceptueler gebruikt kan worden. Soms bestaat een policy zelfs uit meerdere rules. Ik zweer je, ze doen het er om. Ik gebruik hier het woord policy. Punt.

Firewall policies dus... Maar hoe dan?

Bij het maken van firewall policies moet je dus echt snappen wat je doet. Het is niet voldoende om een template te pakken, die erin te plakken en dan ‘klaar!’ te roepen. Elke omgeving is net even anders en moderne firewalls bieden ook veel meer mogelijkheden. Dus de aanpak kent wat fases:

1. Toegang – Wie mag wat?
2. Firewall features – wat kunnen we nog meer blokkeren?
3. Down the rabbit hole – eerst encryptie en dan weer uitpakken?
4. Wie klopt daar aan mijn huisje?
5. Ongewenste bezoekers

1* Toegang – Wie mag wat?

Bij elke nieuwe policy bekijk je wie wat mag. Het wie is in dit geval de kleinste deelverzameling van alle gebruikers in jouw netwerk. Het is dus nooit ‘iedereen mag overal heen’. Als een aanvraag wordt gedaan om een nieuwe policy te maken ontstaat er dus een gesprek. De aanvrager wil (meestal) met een container ship 20.000 containers door jouw firewall rammen. Jouw taak gaat zijn om dit te reduceren tot een liter Spa Blauw die we door een rietje in een klein firewall gaatje kunnen zuigen.

Als doorgewinterde douanebeambte wil je dus echt precies weten waarheen de reis gaat en wat er in de koffers zit. Het zal duidelijk zijn dat de policy ‘de gebruikers moeten websites kunnen bezoeken’ waarschijnlijk betekent dat echt alle gebruikers moeten kunnen browsen. Maar... De servers, OT-apparatuur, etc. hoeven dit waarschijnlijk helemaal niet. Zelfs ‘alle gebruikers’ is dus een deelverzameling. Laat dat dan vooral alleen mensen zijn die via hun laptop, tablet, etc. willen browsen.

Is het verzoek daarentegen om vanaf een bepaalde server financiële informatie op te kunnen halen bij een specifieke bank... Dan zou dat best eens heel specifiek verkeer kunnen zijn met een speciale applicatie die niet eens door iedereen gebruikt kan worden. In dat geval prik je een speciaal gaatje met jouw policy in onze mooie muur om die ene server naar die ene bestemming toe te staan voor dat specifieke protocol.
 Zijn het vijf servers die dit moeten kunnen? Vang ze dan vooral in diezelfde policy. Vaak mag een bron of bestemming in een policy ook worden aangeduid met een groep adressen in plaats van slechts een.

Wat de aanvraag ook is, blijf zoeken naar dat pijnpunt. Probeer de policy zo ver mogelijk te knijpen tot het minimale wat werkt en ook werkbaar blijft. Blijf met je tengels verder echt af van wat niet expliciet nodig is.... Het kan net voldoende zijn om de volgende hack poging tegen te gaan.

2* Firewall features – wat kunnen we nog meer blokkeren?

Oudere generaties firewalls konden vooral policies maken die bepaalden welke IP-adressen waarheen mochten communiceren. Daarnaast werd meteen bepaald welke antwoorden waren toegestaan.
 ‘Next Gen’ en ‘UTM’ firewalls kunnen veel meer. Waar die ‘oude’ firewalls alle antwoorden op legitieme verzoeken toestaan, zullen moderne firewalls in staat zijn de antwoorden te onderzoeken.

Ten eerste wordt dynamisch bepaald welk verkeer mag worden gezien als legitiem antwoord (stateful instepection) en ten tweede kan de firewall het antwoord in detail bekijken. Doe dat ook vooral! Tegenwoordig kan al het verkeer worden onderzocht op virussen. Geweldig! Je wil echt wel elk virus dat ontdekt wordt buiten de deur houden! Je kunt jouw firewall laten bepalen of een internetserver die bezocht wordt bekend staat als thuisbasis voor een hele kudde malware. Dit verandert ‘al het browser verkeer naar het internet toestaan’ in ‘al het browser verkeer naar servers in het internet die niet bekend staan om hun malware toestaan’. Dat is echt een wereld van verschil.

Het is ook mogelijk om te kijken naar gedrag van applicaties die vanaf een gebruiker PC naar de rest van de wereld communiceren. Gaat verkeer naar een enkele bestemming of worden 100 andere machines opeens bestookt met verkeer? Is een PC een YouTube clip aan het bekijken of duwt hij de corporate internet lijn zo’n beetje dicht? Je kunt jouw firewall dus veel breder naar verkeer laten kijken. Tuurlijk, we moeten toestaan wat nodig is voor normaal gebruik. Maar wordt het wel erg veel, is het naar verdachte bestemmingen of wordt een virus opgehaald? Dan wil je het eigenlijk wel blokkeren. En vaak is dat rare gedrag helemaal niet bekend bij een gebruiker. Door die ene klik op een link in dat e-mailtje is malware geactiveerd die zijn smerige werk op de achtergrond uitvoert. Ook dat wil je detecteren.... En erger voorkomen.

3* Down the rabbit hole – eerst encryptie en dan weer uitpakken?

Encryptie – Een van de methodes om communicatie in het internet veiliger te maken. Laten we alles wat we communiceren vooral onherkenbaar versleutelen, want dan kan niemand mijn wachtwoorden zien of mijn mail lezen. Slim. Verstandig.
 …En een nachtmerrie voor firewall beheerders.

Juist de analyse van wat gebruikers doen is belangrijk bij de detectie van virussen en verdachte activiteiten. Dus al die mooie encryptie werkt helemaal niet mee. Daardoor is veel minder zichtbaar van het daadwerkelijke gedrag.

Dus wat is er bedacht? SSL-inspectie. Hiermee doet de firewall net alsof het de bestemming is, hij acteert als zogenoemde proxy. Zonder dat de gebruikers zich hiervan bewust hoeven te zijn doet een firewall net alsof hij de website oid is waar een gebruiker mee wil communiceren. Dit maakt het mogelijk om al het versleutelde verkeer uit te pakken en te onderzoeken.
Naar de server waarmee gecommuniceerd moest worden doet de firewalls alsof hij de gebruiker is. Hiermee wordt al het verkeer naar de server netjes versleuteld verstuurd. Voor de gebruiker (eigenlijk de applicatie van de gebruiker) en de server is er niets aan de hand. Beide zijn ervan overtuigd dat encryptie wordt gebruikt en alles dus veilig wordt verstuurd. De firewall zit er tussenin en kan ondanks de encryptie toch mee kijken naar het verkeer. Als alles in orde is (o.a. geen vieze virussen gevonden), wordt al het verkeer netjes door gestuurd en heeft niemand wat in de gaten.

Maar wacht... Als een firewall dat kan... Dan kan een hacker dat toch ook!! Jazeker!
Dat kan een hacker ook!

Daarom is het belangrijk dat je beseft dat encryptie wel een mooi slotje in jouw browser produceert, maar geen garantie is dat niemand mee heeft zitten kijken of zelfs aanpassingen doorvoert. Juist omdat encryptie kan worden onderschept, is het belangrijk dat jij dat versleutelde verkeer kunt onderzoeken. Let wel, het onderscheppen van SSL-verkeer voor minder dan vriendelijke doeleinden vereist enige moeite en kennis. Daarom is het gebruik van encryptie altijd verstandig, maar besef dat het niet voldoende is.

4* Wie klopt daar aan mijn huisje?

Nadat we hebben geregeld wie er allemaal op Facebook mag moet je nog bedenken wat er naar binnen mag. Waarschijnlijk mogen jouw gebruikers van thuis uit op het bedrijfsnetwerk komen via bijvoorbeeld een VPN. Misschien draaien er wel servers die door bezoekers vanuit het internet bereikbaar moeten zijn. Wellicht biedt jouw firma een uitgebreide SaaS of andere aaS oplossing.

Als de voordeur moet worden opengezet, al is het op een kier, dan moet je daar ook extra waakzaam op zijn. Het is bij de meeste firewalls bijvoorbeeld geen probleem om te bepalen welke werelddelen verbinding mogen maken. Dit wordt ook wel geofencing genoemd. Met deze techniek kun je aangeven dat alleen IP-adressen uit Nederland bij jouw servers mogen komen.

Natuurlijk kan dit niet altijd, maar als jij bijvoorbeeld rittenregistratie voor Nederland als dienst aanbiedt, zou het zomaar kunnen dat een Rus daar helemaal niets te zoeken heeft. In dat geval is een geofence waar alleen Nederland in zit helemaal prima. Zelf bij verbindingen vanuit het Internet ga je dus op zoek naar dat pijnpunt, die kleinste deelverzameling die erbij moet kunnen.

5* Ongewenste bezoekers

Naast gepland bezoek, heb je vaak zo af en toe last van die mensen die even op de koffie willen komen als je net in bad zit. En als dat nog niet erg genoeg is, inbrekers zijn nog veel brutaler. Die komen als je er niet eens bent! Om ervoor te zorgen dat je dat schorriemorrie buiten de deur laat, zet je jouw Intrusion Prevention System (IPS) aan. Je zet jouw voordeur er nog net niet mee onder stroom, maar je zorgt dat jouw firewall continu in de gaten houdt of diegene die aan de deur klopt vriendelijk is... Of dat ze liefst jouw huisje (van binnenuit) opeten. Het verkeer wordt geanalyseerd en indien nodig geblokkeerd. Als je helemaal slim bent, zorg je ook dat de firewall je zo af en toe vertelt dat er iets vervelends is geblokkeerd.

Policies en het effect op performance

Een belangrijk onderdeel bij jouw ontdekkingsreis langs de vele policies en features die je aan kunt zetten is performance. Het is niet altijd de beste optie om alle opties op al het verkeer aan te zetten. Bedenk wat je waar nodig hebt. Voorbeeld? Voorbeeld. Een stom, maar helder voorbeeld:

Stel je hebt een policy gemaakt voor specifiek verkeer naar een webserver waar de toernooi score van jouw lokale dart vereniging te zien is. En iedereen, echt iedereen in jouw organisatie kijkt elke 5 minuten op die pagina. Maar... De makers van die site hebben geen SSL-encryptie aangezet voor de site. Als je een specifieke policy voor die website maakt die alleen onversleuteld verkeer toestaat, is het nutteloos om SSL-inspectie aan te zetten. SSL gaat immers nooit door die policy heen.

Dit stomme voorbeeld illustreert hopelijk dat je goed moet nadenken over de gevolgen van het activeren van features, vooral omdat sommige features jouw firewall best zwaar kunnen belasten.

Dit geldt ook als je de policies maakt. Probeer je te houden aan het KISS principe. KISS = ‘Keep It Simple, Stupid!’. (Heb ik niet verzonnen.)

Probeer alles simpel te houden als je een firewall inricht. Het is al complex genoeg, dus maak het vooral niet erger. Kan je 10 policies vereenvoudigen in een enkele zonder in te boeten op veiligheid? Doen! Naast een veel betere leesbaarheid van alle instellingen, betekent simpel ook vaak betere performance (en minder foutgevoelig).

Software updates en speciale features?

Elke zichzelf respecterende (en soms ook de andere) firewall leverancier levert met zekere regelmaat software updates voor hun producten. Soms wordt functionaliteit verbetert, soms nieuwe features toegevoegd. Maar wat je vooral fijn zal vinden: Bugs worden opgelost. Op een van onze extreem belangrijke verdedigingsmiddelen tegen hackers zullen bugs in de categorie ‘ongewenst’ vallen. Houd dus vooral in de gaten wat jouw leverancier aan updates levert en kijk in de release notes was er bij de laatste versie is veranderd.

Naast software updates voor het product zelf, bieden de meeste leveranciers ook abonnementen voor bepaalde functionaliteit. Dit kan variëren van eenvoudig beheer van meerdere firewalls tot zeer actuele lijsten van malware servers. In de meeste gevallen is het absoluut de moeite waard om het aanbod te bekijken om te zien of het voor jou van nut is.

Firewalls – so secure als de ingestelde policies

Soms wordt een bepaalde functie globaal geconfigureerd en niet specifiek per policy. Dan heet het ‘feature’. Bij een andere firewall kan het echt zo zijn dat zo’n ‘feature’ in een policy moet worden geactiveerd. Daarom is het soms lastig om features en policies volledig van elkaar te scheiden.

Hoe dan ook, gebruik ze verstandig. Zorg dat je bekend raakt met de mogelijkheden die jouw firewall biedt en activeer ze ook. Maar zoals deze blog hopelijk duidelijk maakt, zorg dat je weet wat je doet. Er is geen enkele firewall waarbij je kunt zeggen ‘doe maar’ en dan gaat het wel goed. Elke firewall moet worden geconfigureerd en het leeuwendeel hiervan zit in het maken van goede policies. Hier bepaal je wat er mag en zeker ook wat je absoluut wilt blokkeren.

Het hebben van een prachtige firewall is echt niet genoeg. Het nut ervan valt of staat met de policies die jij instelt en onderhoudt.

Bekijk ook de rest van onze IT Security Blog reeks

Volg de LinkedIn page van Procyon Networks en vind wekelijks waardevolle informatie over cybersecurity en netwerktechnologie op jouw tijdlijn. .