Voor wie zijn website of webapplicatie wil beschermen tegen misbruik, is een web application firewall (WAF) onontbeerlijk. Maar in de praktijk komt er heel wat kijken bij het inzetten van een WAF.

Internetaanvallen zijn mettertijd meer van de netwerklaag naar de applicatielaag verschoven. Op het web kan een web application firewall (WAF) je helpen om deze aanvallen tegen te houden. Webwereld sprak met Erwin Geirnaert, oprichter en CEO van het Belgische beveiligingsbedrijf Zion Security, en Xavier Mertens, principal security consultant bij het Belgische beveiligingsbedrijf C-Cure. Beiden hebben ervaring met heel wat WAF's, waaronder ModSecurity, IronBee, Barracuda, Profense, BeeWare, F5 en Zion Secured (Zions eigen WAF).

Een WAF kan heel wat typen aanvallen tegenhouden, waaronder SQL/LDAP/XML-injecties, cross-site scripting, session hijacking, path traversal (zoals het lezen van ../../../../etc/passwd), en brute-force aanvallen. Alles waarvoor signatures bestaan, is eenvoudig tegen te houden. Maar er bestaan ook WAF's die zelf leren wat het gevaarlijke verkeer is, waarna je de automatisch gegeneerde signatures nog kunt fine-tunen. Bovendien zorgt een WAF voor een grote toegevoegde waarde omdat alle inkomende en uitgaande HTTP-aanvragen kunnen worden gelogd, terwijl webapplicaties hier standaard niet voor instaan en een webserver alleen GET-requests logt en geen POST-requests.

Beschikbare WAF's

Het productaanbod van WAF's is heel breed. Dat begint bij opensource-producten zoals ModSecurity, een module voor de webserver Apache, die met mod_proxy ook als reverse proxy gebruikt kan worden om IIS-applicaties af te schermen. "ModSecurity heeft een redelijk goede community. Het gebruikt wel een negatief beveiligingsmodel, wat dus betekent dat het alleen bekende aanvallen zal tegenhouden of loggen", stelt Geirnaert. Volgens Mertens is ModSecurity de beste opensource WAF van het moment, maar om zelf je eigen firewallregels te schrijven moet je wel een heuse regex-goeroe zijn. Een ander opensource-product, nog nieuw maar volgens Mertens veelbelovend, is IronBee.

De meeste WAF's zijn echter commerciële producten. Geirnaert noemt Profense van het Deense Armorlogic: "Voor een commercieel product is het vrij goedkoop, ongeveer 5000 euro voor de cluster, en het kan virtueel of op eender welke hardware worden geïnstalleerd. Profense kan na voldoende webverkeer zelf bepalen welke URL's, parameters en dergelijke zijn toegestaan. Deze WAF vereist ook niet veel bijkomende configuratie en is heel stabiel, dus dit alles maakt het de ideale oplossing voor kleinere websites." Een andere goedkope oplossing is Geirnaerts eigen product Zion Secured: "Dit is een WAF in de cloud, waarvoor je zelf geen hardware of software hoeft te installeren: je moet alleen een DNS-record aanpassen, waarna onze WAF je website afschermt, Dat kost 130 euro per maand per website."

Tot 100.000 euro

Een trapje hoger (ook qua kostprijs: 10000 tot 30000 euro) is de WAF van het Franse bedrijf BeeWare. Volgens Geirnaert is dit een goede oplossing die een combinatie biedt van een negatief en positief beveiligingsmodel, en ze laat toe om een eenvoudige workflow te definiëren op basis van de HTTP-aanvragen. "Bijkomend kan hun appliance ook authenticatie verzorgen voor verschillende webapplicaties en web services beveiligen met XML security."

En dan is er nog F5, dat sinds de overname van Sanctum AppShield een WAF heeft geïntegreerd in hun BIG-IP appliances, de Application Security Manager (ASM). Voor hard- en software spreek je dan al snel over een kostprijs van 100.000 euro zonder configuratie, maar dan is er volgens Geirnaert wel veel mogelijk: "Zelfs transactionele websites zoals voor internetbankieren kun je met ASM volledig dichttimmeren, iets wat bij andere producten heel wat moeilijker is. Bovendien hebben veel bedrijven al BIG-IP draaien, dus dan is de stap om ASM toe te voegen niet zo groot."

Vals gevoel van veiligheid

Maar welke keuze je ook maakt, Mertens waarschuwt ervoor dat een WAF een vals gevoel van veiligheid kan introduceren: "Webontwikkelaars voelen zich al vlug veilig omdat ze denken dat hun website toch beschermd is door een WAF. Maar uiteindelijk moet je al zo vroeg mogelijk in de softwareontwikkelingscyclus met beveiliging rekening houden: ontwikkelaars moeten zich bewust zijn van de risico's en veilige code schrijven.

Een WAF is zoals elke firewall slechts een domme tool, en te veel erop vertrouwen is niet slim. Je kunt je WAF immers verkeerd configureren of vergeten te updaten. Dat laatste wordt vaak onderschat: elke keer als er nieuwe aanvallen bekend worden, maar ook wanneer je applicatie verandert, moet de WAF-configuratie een update krijgen. In mijn ogen blijft een WAF dus altijd een tijdelijke 'patch' voor beveiligingsproblemen in de applicatie zelf die zo vlug mogelijk moeten gecorrigeerd worden."

Man in the middle

WAF's zijn ook geen silver bullet. Met een WAF kun je volgens Geirnaert bijvoorbeeld man-in-the-middle en browser-in-the-middle aanvallen bijna niet tegengaan: "De WAF kan immers moeilijk de businesslogica van een bestaande applicatie leren. Als die applicatie dan met verborgen velden, JavaScript en direct references werkt, dan kan een WAF niet veel doen zonder de werking van de applicatie te verstoren."

Ook een content management system zorgt volgens Geirnaert voor grote uitdagingen voor een WAF: "Updates aan een website door een CMS-gebruiker worden door een WAF meestal als aanvallen beschouwd, omdat die potentieel gevaarlijke content zoals html-tags en databasecode bevatten. De meest pragmatische manier om een CMS dan toch met een WAF te beschermen is om aanvragen van bepaalde vertrouwde IP-adressen niet tegen te houden, maar wel te loggen."

WAF omzeilen

Een ander probleem vinden we in de zogenaamde HTTP Parameter Pollution, waarbij dezelfde parameter in een aanvraag meerdere keren doorgestuurd wordt met verschillende gegevens. Hoe reageert de webapplicatie daar dan op? Er zijn bijvoorbeeld webapplicaties bekend die al deze waarden gewoon samenvoegen. Een WAF die op signatures voor bekende aanvallen vertrouwt, zal een aanval die vermomd wordt met HTTP Parameter Pollution niet detecteren.

De aanwezigheid van een WAF kan bovendien gedetecteerd worden, aldus Mertens: "Een bekende tool hiervoor is het Python-programma wafw00f. En als je eenmaal weet welke WAF een website beschermt, kun je zoeken naar geschikte technieken om de WAF te omzeilen. Een klassieke aanpak is het gebruik van een andere character encoding, zodat je aanval niet door de signatures van de WAF herkend wordt maar wel nog door de webapplicatie. En uiteraard zijn er ook wel eens beveiligingsgaten in WAF's, waarmee je dan de applicatie kunt aanvallen."

80/20-regel

Volgens Mertens zijn er drie belangrijke situaties waarin een WAF onontbeerlijk is. Ten eerste heb je vaak te maken met legacy toepassingen die je niet meer kunt updaten. De enige manier om ze te beveiligen is dan door met een WAF gevaarlijke aanvragen tegen te houden. Ten tweede kan het in veel gevallen voorkomen dat fouten in de applicatie oplossen gewoon te veel tijd vraagt. Een WAF-configuratie kan dan wel eens sneller uitgerold zijn. En ten derde kan een WAF in veel bedrijven nodig zijn om aan vereisten zoals PCI Compliance te voldoen.

Uiteraard moet je de signatures van de WAF aanpassen voor je specifieke webapplicatie, maar volgens Geirnaert kom je al heel ver met generieke regels: "Tachtig procent van de aanvallen worden zeker tegengehouden met generieke WAF-regels. Maar aanvallen op businesslogica zijn heel moeilijk te beveiligen als men niet weet welke problemen bestaan in de applicatie. Een vulnerability assessment raad ik daarom zeker aan vóór je de beveiligingsproblemen in je applicatie met een WAF gaat tegenhouden."

Uiteraard moeten de logs van de WAF ook naar behoren beheerd en bekeken worden, en Mertens raadt aan om voor een WAF te kiezen die zijn logs kan exporteren naar een gecentraliseerd logsysteem of die een API aanbiedt om ze via een third-party tool te beheren: "WAF-logs moet je echt in je Security Information and Event Manager (SIEM) integreren."

Best practices en valkuilen

Het inzetten van een WAF is niet evident, maar gelukkig is er wel wat informatie over te vinden. Zo heeft het Open Web Application Security Project (OWASP) een document gepubliceerd, OWASP Best Practices: Use of Web Application Firewalls. Geirnaert raadt ook de Web Application Firewall Evaluation Criteria van het Web Application Security Consortium (WASC) aan, waarin voornamelijk de verschillende deployment- en configuratiemogelijkheden worden besproken.

Tot slot waarschuwen beide beveiligingsspecialisten nog voor twee belangrijke valkuilen. Ten eerste is het inpassen van een WAF in een bestaande netwerkinfrastructuur niet altijd eenvoudig, zegt Geirnaert: "Grote organisaties hebben al een load balancer, reverse proxy, DNS en publieke IP-adressen, en het inzetten van een WAF kan grote wijzigingen in deze infrastructuur als gevolg hebben."

En dan is er ook nog de vraag wie de WAF gaat beheren, monitoren en ondersteunen. "Aangezien een WAF een netwerktoestel is, komt die taak meestal terecht bij de netwerkbeheerders, maar die hebben in het algemeen te weinig kennis van webapplicaties en web application security, waardoor ze niet ten volle gebruikmaken van de WAF en er veel valse positieven zijn," zegt Geirnaert. Volgens Mertens zijn ook de ontwikkelaars van de website zelf niet de juiste partij: "Een WAF moet door het securityteam van het bedrijf beheerd worden."

Bron: Webwereld.nl