Wanneer gebruik je een cloudfirewall?

Gebruik een cloudfirewall als eerste verdedigingslinie voor alles wat vanaf internet bereikbaar is, en laat daaronder een hostfirewall draaien als tweede, onafhankelijke laag. Cloudfirewalls (security groups, network security groups, packetfilters op cloudniveau) bevinden zich buiten de server en blokkeren verkeer voordat het ook maar CPU, bandbreedte of een luisterende socket verbruikt. Hostfirewalls (iptables, nftables, ufw, Windows Defender Firewall) draaien op de machine zelf en vormen je laatste verdedigingslinie als de netwerklaag verkeerd is geconfigureerd of wordt omzeild.

Kort gezegd: cloudfirewalls voor perimetercontrole en het beperken van de impact, hostfirewalls voor defence-in-depth en alles wat de cloudlaag niet kan zien (loopbackverkeer, regels tussen containers, filtering op basis van processen). De meeste productieomgevingen hebben beide nodig.

Wat is het verschil tussen een cloudfirewall en een hostfirewall?

Een cloudfirewall wordt afgedwongen door de netwerkinfrastructuur van de provider, stroomopwaarts van de netwerkinterface van je server. Geweigerd verkeer raakt de CPU of NIC van je instance nooit: het wordt al op de hypervisor- of software-defined-networklaag gedropt. Daardoor zijn cloudfirewalls goedkoop in gebruik (ze verbruiken geen serverresources) en effectief tegen volumetrische aanvallen en eenvoudige portscans, omdat die ruis je machine nooit bereikt.

Een hostfirewall draait als software binnen het besturingssysteem en inspecteert pakketten nadat ze al bij de netwerkinterface zijn aangekomen. Hij is flexibeler: je kunt filteren op proces, gebruiker of applicatielogica, en hij werkt precies hetzelfde of de server nu bare metal is, een cloud-VM, of helemaal geen cloudfirewall voor zich heeft. Maar hij verbruikt per pakket een klein beetje CPU, en als het besturingssysteem gecompromitteerd of verkeerd geconfigureerd is, kan een aanvaller hem mogelijk uitschakelen.

Wanneer gebruik je een cloudfirewall?

Gebruik een cloudfirewall zodra je server een publiek IP-adres heeft. Je standaardregel zou moeten zijn: weiger al het inkomende verkeer, behalve op de poorten die je expliciet nodig hebt, toegepast op de netwerklaag voordat er iets de instance bereikt.

Een cloudfirewall is de juiste tool als je:

• SSH- of RDP-toegang wilt beperken tot een vaste lijst met IP-adressen van je kantoor of VPN, in plaats van beheerpoorten bloot te stellen aan het hele internet.
• lagen van een applicatie wilt segmenteren, bijvoorbeeld door alleen je webservers toegang te geven tot je databaseservers op de databasepoort en al het andere verkeer tussen subnets te blokkeren.
• scanverkeer en eenvoudige aanvallen wilt opvangen zonder daar server-CPU aan te besteden. Een pakket dat stroomopwaarts wordt gedropt, raakt de TCP-stack van je instance nooit.
• consistente regels wilt toepassen op een hele vloot servers door dezelfde regelset (vaak een security group of firewallbeleid genoemd) te koppelen aan elke instance met een bepaalde rol, in plaats van elke machine afzonderlijk te configureren.
• tijdens een incident snel een poort op al je servers wilt dichtzetten of openen, zonder op elke server in te loggen via SSH.

Als je meerdere cloudservers bij verschillende providers draait, wordt het handmatig consistent houden van deze regelsets al snel foutgevoelig: een firewallregel die in de console van de ene provider goed staat, kan bij een andere vergeten worden. Wanneer je je cloudservers vanuit één dashboard beheert, kun je veel makkelijker controleren welke poorten er daadwerkelijk openstaan binnen je hele vloot, in plaats van erop te vertrouwen dat iedereen eraan heeft gedacht om de console van elke provider op dezelfde manier bij te werken.

Wanneer gebruik je een hostfirewall (of allebei)?

Gebruik op elke server een hostfirewall, ongeacht of er ook een cloudfirewall actief is. Het is je vangnet als een cloudregel per ongeluk wordt versoepeld, als de server later naar bare metal of een andere provider zonder vergelijkbare mogelijkheden verhuist, of als je filterlogica nodig hebt die de cloudlaag niet kan uitdrukken, zoals rate limiting per bron-IP, filteren op proces/UID of het afhandelen van oost-westverkeer tussen containers op dezelfde host.

Gebruik beide wanneer:

• de server vanaf internet bereikbaar is en iets gevoeligs verwerkt: betaalgegevens, authenticatie, klantgegevens. Defence-in-depth betekent dat één verkeerde configuratie niet meteen een datalek oplevert.
• je de server beheert binnen een vloot waarin cloudfirewallregels kunnen afwijken of overschreven kunnen worden door iemand met consoletoegang.
• je verbindingsstatus wilt bijhouden of logging nodig hebt die lokaal makkelijker te configureren en te inspecteren is dan via een cloudconsole.

Gebruik alleen een hostfirewall als er echt geen firewall op cloudniveau beschikbaar is (sommige kleinere providers en dedicated/bare-metal hosts bieden er geen aan) of als de server helemaal geen publiek IP heeft en volledig binnen een privénetwerk draait dat je al op routerniveau beheert.

WarningVertrouw nooit alleen op de cloudfirewall en laat de hostfirewall niet uitgeschakeld "omdat de cloud het toch al blokkeert". Eén verkeerd toegepaste regel, een tijdelijke debugwijziging die iemand vergeet terug te draaien, of een server die naar een nieuwe security group met lossere standaardinstellingen wordt verplaatst, haalt je enige beschermingslaag weg.

Verstandige standaard firewallregels om mee te beginnen

Een redelijk uitgangspunt voor een typische webserver, toegepast op zowel de cloud- als de hostlaag:

# Cloud firewall (security group) — inbound
Allow  tcp/22   from <your office/VPN IP only>
Allow  tcp/80   from 0.0.0.0/0
Allow  tcp/443  from 0.0.0.0/0
Deny   all      from 0.0.0.0/0

# Host firewall (ufw) — mirrors and backs up the above
ufw default deny incoming
ufw default allow outgoing
ufw allow from <your office/VPN IP> to any port 22
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Een paar gewoontes die dit op de lange termijn beheersbaar houden:

• Weiger standaard alle inkomend verkeer en sta daarna expliciet alleen toe wat nodig is; sta nooit standaard alles toe om vervolgens te proberen het kwaadaardige verkeer te blokkeren.
• Stel databasepoorten (5432, 3306, 27017, enz.) op geen van beide lagen open voor 0.0.0.0/0; beperk ze tot de specifieke applicatieservers die ze nodig hebben.
• Log na elke wijziging een tijdlang geweigerde verbindingen op hostniveau, zodat je een te strenge regel opmerkt voordat die iets in productie kapotmaakt.
• Controleer de regels telkens wanneer een server van rol verandert: een oude regel "alles toestaan om te testen" die op een machine is blijven staan die later naar productie gaat, is een veelvoorkomende manier waarop een perimeter ongemerkt verzwakt.

Inzicht over alle providers heen

Het lastigste aan goede firewallhygiëne is niet het schrijven van de regels, maar in één oogopslag weten welke poorten er daadwerkelijk openstaan op elke server die je draait, zeker zodra je over meer dan één cloudprovider verspreid zit. Zie je firewallconfiguratie als iets wat je regelmatig controleert, niet als iets wat je één keer instelt en daarna vergeet.

Beheer je servers bij meerdere clouds en wil je op één plek zien wat er daadwerkelijk openstaat? Bekijk dan de cloudserverfunctie van InfraNest.