Een firewallregel in de cloud is een regel die verkeer matcht op een 5-tuple (bronadres, doeladres, protocol, bronpoort en doelpoort) en dat verkeer vervolgens toestaat of laat vallen. De belangrijkste beslissing die je bij elke firewall neemt, is het standaardbeleid: standaard alles weigeren en daarna expliciet alleen toestaan wat je nodig hebt. Al het andere in dit artikel is detail dat bovenop die ene regel komt.
Waarop een firewallregel precies matcht
Elk pakket heeft een bron-IP, een doel-IP, een protocolnummer (TCP, UDP, ICMP enzovoort) en, bij TCP en UDP, een bron- en doelpoort. Cloudfirewalls (AWS security groups, Azure NSG's, GCP VPC firewall rules) evalueren regels allemaal tegen ditzelfde 5-tuple, ook al zien de interfaces er anders uit. Schrijf je een regel als "allow TCP 443 from 0.0.0.0/0", dan vertel je de firewall dat hij elk pakket moet matchen met protocol TCP, doelpoort 443 en een willekeurig bronadres.
ICMP (het protocol achter ping en path MTU discovery) wordt vaak als een aparte klasse behandeld, los van TCP/UDP. Het heeft dus een eigen expliciete allow-regel nodig als je wilt dat diagnostiek zoals ping door de firewall werkt.
Default-deny vs. default-allow
Default-deny betekent: als geen enkele regel het verkeer matcht, wordt het verworpen. Default-allow betekent het omgekeerde: alles wat niet expliciet wordt geblokkeerd, komt erdoor. Default-deny is bij elke grote cloudprovider de algemeen aanvaarde best practice voor inkomend verkeer, omdat een vergeten of verkeerd geconfigureerde service dan standaard onbereikbaar is in plaats van standaard blootgesteld.
De meeste providers stellen nieuwe firewallgroepen al standaard in op deny-all voor inbound en allow-all voor outbound:
- AWS security groups: nieuwe custom groups weigeren standaard al het inkomende verkeer, staan standaard al het uitgaande verkeer toe en ondersteunen alleen allow-regels (geen expliciete deny; verkeer dat niet matcht wordt impliciet verworpen).
- Azure NSG's: worden geleverd met standaardregels die VNet-naar-VNet- en load-balancerverkeer toestaan, al het overige inkomende verkeer weigeren en uitgaand verkeer naar het VNet en internet toestaan. Deze standaardregels kun je niet verwijderen, maar wel overschrijven met een custom regel met hogere prioriteit.
- GCP VPC firewall rules: elk netwerk heeft een impliciete allow-all-egress-regel en een impliciete deny-all-ingress-regel met de laagste prioriteit, die door je expliciete regels met hogere prioriteit worden overschreven.
De praktische les: vertrouw niet op "dat kon vast wel openblijven". Begin dicht en open poorten één voor één wanneer services ze nodig hebben.
Inbound vs. outbound: waarom beide richtingen ertoe doen
Inbound-regels bepalen wat je server kan bereiken. Outbound-regels (egress) bepalen wat je server op internet kan bereiken. De meeste mensen besteden al hun tijd aan inbound en negeren outbound volledig. Dat is een fout, want onbeperkte egress is precies wat een gecompromitteerde server in staat stelt data te exfiltreren of contact te leggen met een command-and-controlhost.
Of je voor beide richtingen aparte regels moet schrijven, hangt ervan af of de firewall stateful of stateless is:
- Stateful firewalls (AWS security groups, Azure NSG's, GCP VPC-regels voor bestaande verbindingen) volgen de verbinding aan de hand van TCP-flags (SYN, ACK, FIN). Sta je één inkomend verzoek toe, dan wordt het bijbehorende antwoordverkeer automatisch weer naar buiten doorgelaten. Je hebt geen spiegelregel nodig.
- Stateless firewalls (AWS network ACLs zijn het klassieke voorbeeld) evalueren elk pakket afzonderlijk in genummerde volgorde. Je moet dus expliciete regels schrijven voor zowel het verzoek als het antwoord, inclusief de hoge ephemeral retourpoorten.
UDP heeft helemaal geen verbindingsstatus (het is per definitie verbindingsloos). Firewalls die beweren UDP-"sessies" bij te houden, gebruiken in werkelijkheid timeouts en heuristieken, geen echte state table zoals bij TCP.
NoteAWS security groups ondersteunen alleen allow-regels, die zonder volgorde met OR worden gecombineerd. Regelprioriteit bestaat daar niet. Network ACLs, Azure NSG's en GCP firewall rules gebruiken juist een genummerde prioriteit, waarbij het laagste nummer wint.
Poorten die per ongeluk openstaan
De meeste vermijdbare inbraken zijn terug te voeren op een handvol voorspelbare fouten, niet op zero-days. Veelvoorkomende boosdoeners:
| Poort | Service | Waarom het een risico is als deze openstaat voor 0.0.0.0/0 |
|---|---|---|
| 22 | SSH | Doelwit voor brute-force; beperk tot bekende IP's of een bastion |
| 3389 | RDP | Hetzelfde probleem als SSH, wordt massaal gescand door bots |
| 3306 / 5432 | MySQL / PostgreSQL | Databases mogen nooit vanaf internet bereikbaar zijn; gebruik een privénetwerk of VPN |
| 6379 | Redis | Wordt vaak helemaal zonder authenticatie uitgerold; een geliefd doelwit van cryptomining-botnets |
| 27017 | MongoDB | Hetzelfde patroon als Redis: publiek + zonder authenticatie is een veelvoorkomende misconfiguratie |
| 9200 | Elasticsearch | Wordt vaak tijdens het testen opengezet en daarna nooit meer dichtgezet |
De oplossing is bijna altijd dezelfde: beperk de bron van de regel tot het IP-adres van je kantoor, een VPN-range of een privésubnet in plaats van 0.0.0.0/0, of zet de service achter een bastion host en verwijder de publieke regel helemaal. Een regel die "tijdelijk" openstaat tijdens een debugsessie, is precies de regel die er een jaar later waarschijnlijk nog steeds staat.
Praktijkvoorbeeld: een webserver dichtzetten
Een typische publieke webserver heeft maar drie inbound allow-regels nodig, terwijl al het andere standaard wordt geweigerd:
Allow TCP 443 from 0.0.0.0/0 # HTTPS
Allow TCP 80 from 0.0.0.0/0 # HTTP (redirect to 443)
Allow TCP 22 from 203.0.113.0/24 # SSH, office range only
Deny all * from 0.0.0.0/0 # implicit or explicit default-deny
Outbound kan meestal wat ruimer blijven (allow-all egress is gebruikelijk voor webservers die externe API's moeten aanroepen, updates moeten ophalen of uitgaande mail moeten versturen). Maar als de server niets te zoeken heeft bij willekeurige hosts, beperk dan ook egress. Dát is wat de impact echt beperkt als de machine ooit wordt gecompromitteerd.
Hoe de evaluatievolgorde van regels per provider verschilt
Hier gaan mensen het vaakst de mist in: AWS security groups hebben helemaal geen volgorde. Elke allow-regel wordt afzonderlijk geëvalueerd en de resultaten worden met OR gecombineerd, dus de volgorde van regels in de console is puur cosmetisch. Azure NSG's en GCP firewall rules gebruiken daarentegen een numerieke prioriteit waarbij het laagste nummer wint en de evaluatie stopt bij de eerste match. AWS network ACLs werken op dezelfde manier: genummerd, first-match, stop. Ben je gewend aan het model van de ene provider en stap je over naar een andere, dan is dit het detail dat de meeste verwarring veroorzaakt. Controleer het dus expliciet in plaats van ervan uit te gaan.
Firewallregels consistent houden over meerdere providers
Draai je workloads op AWS, Azure, GCP en een paar VPS-providers, dan wordt je firewalllogica gedupliceerd in drie of vier verschillende consoles, elk met eigen eigenaardigheden rond standaardinstellingen, prioriteiten en regellimieten. Dat is precies het soort drift waardoor er bij één provider nog een verouderde regel openstaat, lang nadat die overal elders is opgeruimd. Lees infrastructure drift uitgelegd om te zien hoe dat in de praktijk gebeurt. Met het firewallbeheer van InfraNest definieer en audit je regels op één plek voor elke cloudserver die je draait, zodat je een default-deny-aanpak echt kunt verifiëren in plaats van alleen aan te nemen.
Zet je vandaag een nieuwe server op? Begin met een default-deny-beleid voor inbound, open alleen de poorten waarvoor je een reden kunt noemen en audit egress minstens één keer, want dat is de richting die bijna iedereen vergeet. Bekijk firewalls voor cloudservers om dat consistent over al je providers te beheren.
Veelgestelde vragen
#Wat is het verschil tussen een stateful en een stateless firewall?
Een stateful firewall houdt de verbindingsstatus bij aan de hand van TCP-flags, zodat het toestaan van inkomend verkeer automatisch het bijbehorende retourverkeer doorlaat zonder aparte regel. Een stateless firewall, zoals AWS network ACLs, evalueert elk pakket afzonderlijk en heeft expliciete regels voor beide richtingen nodig.
#Moet uitgaand verkeer (egress) ook worden beperkt?
Ja. Onbeperkte egress is wat een gecompromitteerde server in staat stelt data te exfiltreren of contact te leggen met een command-and-controlhost. Door outbound-regels te beperken tot alleen de bestemmingen die een service echt nodig heeft, beperk je de schade als er ooit wordt ingebroken.
#Waarom zou ik een databasepoort zoals 3306 of 5432 niet openzetten naar internet?
Databases zijn veelvoorkomende doelwitten van geautomatiseerde scans en brute-force-aanvallen, en veel inbraken zijn terug te voeren op een databasepoort die openstond voor 0.0.0.0/0. Houd databasetoegang in plaats daarvan op een privénetwerk, VPN of beperkte IP-range.
#Maakt de volgorde van regels uit in cloudfirewalls?
Dat hangt af van de provider: AWS security groups hebben geen volgorde (alle allow-regels worden met OR gecombineerd), terwijl Azure NSG's, GCP firewall rules en AWS network ACLs allemaal een genummerde prioriteit met first-match-evaluatie gebruiken. Daar doet de volgorde er dus wel toe.
Probeer het met een gratis tool
Was dit artikel nuttig?
