Azure Web Application Firewall: aanzetten en klaar? Niet helemaal.

Wanneer het over beveiliging van Azure webapplicaties gaat, komt een Azure Web Application Firewall (WAF) vaak snel ter sprake. En terecht. Een WAF helpt bij het beschermen tegen veelvoorkomende aanvallen, zoals SQL-injecties en cross-site scripting, en vormt daarmee een belangrijke beveiligingslaag voor moderne webapplicaties.

Maar tijdens gesprekken met klanten en collega's merk ik regelmatig dezelfde gedachte:

"We hebben een WAF ingericht, dus dat onderdeel van security is afgevinkt."

Was het maar zo simpel.

Tijdens een presentatie over Azure Web Application Firewall heb ik laten zien dat een WAF veel meer is dan alleen een beveiligingsmechanisme dat verkeer blokkeert. De echte waarde zit in het inzicht dat je ermee krijgt én in de manier waarop je de oplossing blijft testen en optimaliseren.

Preventie voor greenfield, detection voor bestaande applicaties

De meeste organisaties implementeren een WAF vanuit een preventiegedachte. Verdacht verkeer wordt herkend en tegengehouden voordat het de applicatie bereikt. Dat is uiteraard belangrijk en vaak ook de primaire reden om een WAF te implementeren.

Toch zie ik in de praktijk dat juist de detectiekant vaak onderbelicht blijft.

Wanneer een bestaande applicatie achter een prevention WAF wordt geplaatst, zal ook direct voor false positives het verkeer worden geblokkeerd. Om er voor te zorgen dat dit gedrag eerst goed te zien valt is de detectivemodus op een WAF relevant. Welke aanvalspatronen zie je terug? Welke regels worden geactiveerd op endpoints die crucial zijn voor je dienstverlening? Zonder monitoring en analyse mis je een belangrijk deel van de informatie die een WAF je kan bieden. De presentatie benadrukte daarom zowel preventie als detectie als essentiële onderdelen van een effectieve inrichting. Application gateway versus Azure Frontdoor

Een veelgestelde vraag is of er gekozen moet worden voor een application gateway of ene Azure Frontdoor. Er zijn meerdere belangrijke afwegingen die je daarin moet maken namelijk:

Moet jouw applicatie global beschikbaar zijn?
Moet jouw oplossing mTLS ondersteunen?
Wil je het beheer meer in eigen hand of meer uit handen geven?

De application gateway is een regionale Dienst terwijl frontdoor global beschikbaar is. Dat geeft wat extra Beheer bij Azure uit handen. Waardoor je met een Frontdoor meer afhankelijk bent van DNS storingen. Wil je mutual TLS ondersteunen vanaf de voorkant dan kom je voor nu uit bij een application gateway. Wanneer je een nieuwe application gateway gaat uitrollen, zorg er dan voor dat je hebt nagedacht over ipv6 en zone redundancy. Dit zorgt ervoor dat je de resource niet opnieuw hoeft uit te rollen.

Een standaardconfiguratie bestaat eigenlijk niet

Een van de meest gehoorde vragen is:

"Wat is de beste configuratie?"

Het antwoord is meestal minder spectaculair dan gehoopt:

"It depends."

Elke applicatie heeft andere functionaliteiten, risico's en gebruikers. Wat voor de ene omgeving perfect werkt, kan voor een andere omgeving leiden tot foutieve blokkades of juist onvoldoende bescherming.

Daarom geloof ik niet in een universele WAF-configuratie. Een goede inrichting vraagt om kennis van de applicatie én om regelmatig testen en bijsturen.

Vertrouwen is goed, testen is beter

Een firewall die nooit getest wordt, biedt vooral een gevoel van veiligheid.

Tijdens de sessie liet ik daarom verschillende testscenario's zien waarmee gecontroleerd kan worden of de WAF daadwerkelijk reageert zoals verwacht. Pas wanneer je zelf ziet welke aanvallen worden gedetecteerd, welke verzoeken worden geblokkeerd en welke waarschuwingen worden gegenereerd, weet je of de configuratie echt doet wat je ervan verwacht.

Juist deze stap wordt nog regelmatig overgeslagen. Terwijl testen vaak waardevolle inzichten oplevert die je met alleen configureren nooit had ontdekt.

Minimale changes

Een WAF bevat Meestal een Core RuleSet (CRS). In zo’n CRS zitten allemaal regels waarop gekeken wordt of een request een potentieel lek bevat. Wanneer een false positive onderdeel is ontdekt kun je ervoor kiezen de specifieke Rule in een CRS uit te schakelen, maar dit kan ook met specifieke condities. Zoals voor een specifiek endpoint of fieldname in je body van een request.

Een van de meest voorkomende false positives zit in cookies waarbij een gehashte cookie van .NET door de WAF geblocked wordt door een aantal combinaties van characters.

“Statuscode 403 is de default statuscode om requests te blokkeren.”

Wanneer je een 403 statuscode ziet weet je dus dat je moet gaan kijken in de logging van de application gateway in jouw Log analytics workspace.

Security is een proces

Wat ik misschien wel het belangrijkste vind om mee te geven, is dat een WAF geen eindstation is.

Cybersecurity is geen project dat je afrondt. Het is een proces van monitoren, leren, verbeteren en opnieuw controleren. Een Web Application Firewall kan hierin een belangrijke rol spelen, maar alleen wanneer je verder kijkt dan alleen het aanvinken van een beveiligingsmaatregel.

Of zoals ik het zelf graag samenvat:

Bescherm je applicaties tegen bekende OWASP-aanvallen.
Kijk verder dan alleen blokkeren.
Maak gebruik van detectie en monitoring.
Test regelmatig of de configuratie nog doet wat je verwacht.
Blijf optimaliseren op basis van inzichten uit de praktijk.

De techniek achter een WAF is interessant, maar uiteindelijk draait het om iets veel eenvoudigers: weten wat er gebeurt aan de rand van je applicatie en op tijd kunnen reageren wanneer dat nodig is.

Dat is wat een goede WAF-inrichting voor mij zo waardevol maakt.