'Firewalls voor webservers zijn makkelijk te omzeilen'

Firewalls voor webservers, zoals ModSecurity voor Apache, zijn eenvoudig te omzeilen. Dat beweert een beveiligingsonderzoeker, die op Black Hat een tool heeft vrijgegeven waarmee dergelijke firewalls om de tuin kunnen worden geleid.

Web application firewalls worden steeds vaker gebruikt, maar ze zijn nog niet goed genoeg, vindt beveiligingsonderzoeker Ivan Ristic van Qualys. Ristic is de originele auteur van ModSecurity, een web-firewall voor de Apache-webserver, en werkt bij Qualys momenteel aan de IronBee-firewall. Dergelijke firewalls moeten mogelijk schadelijke http-requests voor webservers tegenhouden, zoals pogingen tot sql-injectie.

De firewalls slagen daar echter onvoldoende in, meent Ristic. De onderzoeker presenteerde zijn bevindingen op de Black Hat-beveiligingsconferentie en heeft een tool vrijgegeven die 150 technieken biedt om een web-firewall te omzeilen. Door met http-headers of url's te knoeien, kunnen requests toch door dergelijke beveiligingsapplicaties worden doorgelaten. Ristic richtte zijn pijlen vooral op ModSecurity, maar ook andere web-firewalls zouden kwetsbaar zijn.

Overigens werden op de Black Hat-conferentie juist nieuwe versies van ModSecurity voor Microsofts IIS-server en nginx vrijgegeven. Volgens de huidige ontwikkelaars van de opensource-firewall is daartoe besloten om dat nginx en IIS steeds meer marktaandeel van Apache afsnoepen. Dat was nog veruit de meestgebruikte webserver toen in 2002 met de ontwikkeling van ModSecurity werd begonnen.

Reacties (44)

Volgens de huidige ontwikkelaars van de opensource-firewall is daartoe besloten om dat nginx en IIS steeds meer marktaandeel van Apache afsnoepen.

Dat nginx een goeie nieuwkomer is, ok, maar IIS heeft de afgelopen 5 jaar een flinke dalende lijn laten zien (van bijna 40% naar minder dan 15% tegenwoordig). Als er van marktaandeel afsnoepen sprake is, is het eerder andersom.

Bron: http://news.netcraft.com/

Is het niet zo dat een deel van de nginx websites deze server als caching proxy ingesteld heeft staan, zodat aan de buitenkant de daadwerkelijke application/content server niet meer te onderscheiden is?

In dat geval zijn de statistieken niet geheel betrouwbaar.

Nginx wordt inderdaad regelmatig als cache, proxy, load balancer of een combinatie hiervan ingezet, voordat het verkeer bij de webserver aan komt. Echter gebeurt dit voor zover ik weet vooral met apache als backend. Ik weet zelfs niet eens zeker of het uberhaupt op Windows draait.
De statistieken kunnen inderdaad een beetje anders zijn dan de realiteit, maar ik denk niet dat de echte resultaten positiever voor MS uit zouden vallen. Wie draait er nou nog IIS tegenwoordig?

Webapplicaties zijn daar ook helemaal niet voor bedoeld naar mijn idee...
Dan draai je een firewall binnen een andere applicatie die gevoelig is voor dergelijke verzoeken. Een firewall moet je gewoon als losstaand software op een dedicated server hangen die vervolgens al het verkeer filtert op gewenst of ongewenst.

Inderdaad, ipv een "firewall" te draaien tegen SQL-injecties moet je gewoon de code goed schrijven.

Inderdaad. Het klinkt een beetje zoals de magic quotes van PHP: een 'handige' security feature die feitelijk gewoon een vals gevoel van veiligheid geeft omdat op de verkeerde plaats een handeling wordt uitgevoerd die in de helft van de gevallen niet eens nut heeft, of gewenst is.

Een extra laag beveiliging tegen script kiddies met geautomatiseerde "hack" tools is nooit slecht als een website het primaire product/visite kaartje van je bedrijf is.

Inderdaad, SQL injecties dien je elders af te vangen maar als de CEO zoals gewoonlijk weer een last minute verandering heeft (spoed, prio, NU!) dan wil er helaas wel eens een foutje in sluipen. Een tool die dit soort gaten afdicht totdat QA hem vind en ECHT oplost is nooit verkeerd.

Hier is een mooie defcon presentatie over SQL Injection door een Penetration tester die van al dit soort maatregelen fun maakt:

http://www.youtube.com/watch?v=rdyQoUNeXSg

Als je troep zoals dit nodig hebt dan moet je toch echt eens eventjes 2x nadenken over of je code wel goed in elkaar zit....

Thanks! Best wel interessant wat hij aan informatie verteld!

Een web-application firewall is verplicht voor banken... regelgevers en IT: altijd een success.

Alleen dubbel escapen is gelijk aan niet escapen...en dan heb je een ernstig beveiligingslek...

Inderdaad, ipv een "firewall" te draaien tegen SQL-injecties moet je gewoon de code goed schrijven.

Dat klinkt een beetje als "Je hebt geen veiligheidsgordels nodig, je moet gewoon veilig rijden".
Ik denk dat het een combinatie van die 2 moet zijn.
Geen enkele programmeur werkt perfect, foutjes zijn zo gemaakt, zekerheid voor alles.

Nee, deze foutjes zijn niet 'zo' gemaakt. De vele 'hacks' die in het nieuws komen zijn zo goed als altijd simpele database dumps d.m.v. exploitatie van SQL/XSS vulns. Dit is met twee regels code op te lossen. Programmeurs hebben er gewoon maling aan. Zij denken dat zij met wat hobbyisme op de zolder van papa en mama een geweldige taak hebben verricht als zij Wordpress eindelijk werkend hebben gekregen.

Deze hobbyisten zitten ook op de kantoren van de grotere organisaties, omdat recruiters geen idee hebben wat zij binnen halen in een voor hen onbekende wereld. Ik durf te wedden dat het grootste deel van de code-kloppers hier gewoon lekker de 9-5 centjes ophalen na weer een 'succesvolle' werkdag bij de baas, ondanks dat zij de oorzaak van de vele 'hacks' zijn.

Je hebt een verantwoordelijkheid, erg jammer dat programmeurs niet hoofdelijk aansprakelijk worden gesteld. Dit zou erg veel MBO-mentaliteit op de werkvloer schelen.

wat is MBO-mentaliteit en waarom noemt men dit niet gewoon lui/slordig etc
ik ken genoeg MBO ers die gewoon goed hun best doen alleen niet beter kunnen

ik vind de term MBO-mentaliteit ongepast

Ik vind incompetentie in IT-security ongepast. Niet beter kunnen heeft alles te maken met scholing, interesse en inzet. Met de kennis die de gemiddelde MBO'er (er zijn uitzonderingen) bezit, hoor je geen IT-security in grote organisaties te regelen. Overigens krijgt de gemiddelde HBO'er en WO'er dit ook niet mee in de opleiding, maar die hebben meestal nog iets van een self-learning mentaliteit.

maar die hebben meestal nog iets van een self-learning mentaliteit.

goeie MBO'ers hebben dat ook.

En genoeg HBO en WO'ers die dat niet hebben. Hoeveel ik er wel niet ben tegengekomen....

Wat een mafkees ben je. Eigenlijk loop je MBO'ers af te kraken, zeker gezien ik op het moment een opleiding doe op het MBO niveau. Kan je verzekeren dat er niks mis is met mijn intelligentie.

Maar om even je MBO fantasie helemaal door te breken, ik heb denk in 3 maand tijd HTML, PHP en MySQL geleerd. Dat deed ik trouwens met Notepad++, niks HTML editors of zulke onzin alles met de hand. Browserspel gemaakt en €700,- in 3 maand mee verdient. Ik wil zelfs een gemiddelde WO'er dat zien doen Laten we eerlijk zijn gemiddelde WO'er in de ICT denkt dat hij alles maar weet, net als de mensen die Biologie hebben gestudeerd maar wel worden aangenomen omdat ze een titel hebben. Zulke mensen worden dan je leidinggevende... Dan heb ik liever een MBO'er die ICT heeft gedaan als leidinggevende.

Helemaal eens... Mbo-mentaliteit klinkt negatief, hbo-mentaliteit ook en wo-mentaliteit ook.
Zo gauw je een woord vóór mentaliteit zet, dan is dat stigmatiserend en dus negatief.

Probleem zit hem in laksheid van de programmeur ongeacht zijn opleiding. Maar ook in project opleverdrang van projectmanagers. het gaat alleen om de deadlines en de décharge. Opdrachtgevers zijn vervolgens naief en willen voor een dubbeltje op de eerste rang zitten.

Allemaal eigen schuld dikke bult. Heel html/http is gewoon niet voorbereid op enige vorm van security. Dat moet het onderliggende os afhandelen op de punten waar de ontwikkelaar faalt. Dat weten alle betrokkenen, maar ze vinden het wel best zo. We kunnen de put ook nog dempen als de halve kudde al verzopen is.

Wat is er dan precies onveilig aan HTML en HTTP? Dat zijn nu juist twee protocollen die het erg goed doen. Dat je met HTTP zo mee kunt lezen is niet een gebrek van het protocol. Niet dat 'internet' veilig is: DNS is onveilig, en dingen als ARP leiden ook tot een hoop ellende (cache poisoning).

Wat ik bedoel is onder andere dat je http gewoon kan meelezen. Ik weet natuurlijk dat we daarvoor tegenwoordig https gebruiken, maar daarvoor geldt weer dat de programmeur niets doet. Het is een laagje beveiliging wat later toegevoegd wordt. Door een beheerder.
Http is inherent onveilig. dat is ook niet raar voor een protocol dat alleen voor intern gebruik van medewerkers van het CERN bedacht was in een tijd dat niemand nog Internet had.
in feite is aan die onveiligheid nooit iets veranderd. de introductie van javascript heeft het echter wel nóg onveiliger gemaakt.

daarnaast natuurlijk de zwakte van de dynamische server talen. PHP, ASP en wat dies meer zij. Het rammelende formulieren mechanisme in html en magere aansluiting in de parameteroverdracht, zorgt voor 95% van de injection poblemen.

als programmeur moet je dus zelf aan iedere zwakheid denken en er zelf omheen programmeren. Iedere keer weer. En los je het op dezelfde wijze op als een van je conculega's dan heb je grote kans dat je een patentzaak of auteursrechten kwestie aan je broek hebt.

Ik heb een browserspel gemaakt en er €700,- in 3 maanden mee verdiend.

Ik zie dat het "spellen ende keurig schrijven" der Nederlandsche taal niet in de opleiding zit? Ah, me bad, sorry, kon het niet laten.

Maar ik ben met je eens dat MBO'ers afkraken niet echt constructief is in dit verband. Overigens: zeggen dat je HTML, PHP en MySQL in drie maanden hebt geleerd is hetzelfde als zeggen dat je kunt rijden als je een week je rijbewijs hebt. Dus misschien ben jij toch het type persoon waar hij zijn pijlen op richt?

Ah... eigenlijk moet ik mijn mond ook houden

Mede-verantwoordelijk hoor je je eigenlijk wel te voelen ja, maar aansprakelijk stellen gaat veels te ver.
Het probleem ligt hoofdzakelijk aan de ene kant bij de scholing en aan de andere kant bij het bedrijfsmanagement. Daarnaast is het natuurlijk ook een stukje zelf-educatie van de software engineer om op de hoogte blijven binnen zijn expertise en te blijven bijleren.

Ik heb bijvoorbeeld in mijn opleiding nauwelijk te maken gekregen met de beveiligingsaspecten. En waar ik door eigen onderzoek (mede gevoed door de vele "lek/hack"-berichten op Tweakers) beveiligingsgaten ontdek bij m'n werkgevers, worden de schouders sneller opgehaald dan dat ik de kans krijg oplossingen te zoeken. Want tsja, de al wachtende projecten gaan voor.

Geld/tijd speelt dus zeker ook een grote rol bij dit soort zaken. Heel abstract gezien vanuit bedrijfs-oogpunt...een lek kan misschien ooit geld kosten, nieuwe functionaliteit zal zeker weten geld opleveren.

Dat is nou precies één van de verschillen tussen een software engineer en een 'programmeur'. Programmeur is inderdaad MBO-mentaliteit/niveau.
Het SQL/XSS vulns verhaal is natuurlijk een aanname gebaseerd op statistiek; een groter probleem is dat in de grotere applicaties er misschien al jaren vulnerabilities (juist ook van de benoemde types) in zitten en er geen tijd/geld aan besteed wordt door de werkgever om dat aan te pakken. Iemand die software ontwikkelt van een beetje niveau, zorgt tegenwoordig wel dat hij XSS/SQL voorkomt met standaard oplossingen. Echt meer werk zit daar niet in.

Over aansprakelijkheid gesproken, daar worden de meeste van dat soort programmeurs ook niet naar betaald. Als je het vanuit een ander perspectief bekijkt; deze mensen worden in veel situaties aardig gebruikt om geld te genereren.

Nee het echte probleem zijn mensen zoals jij die security als een feature presenteren, iets wat je aan of uit zet of iets dat je wel of niet hebt. Bullshit!

Ben het met je eens dat veel security exploits die het nieuws halen in de categorie knullig of zelfs laakbaar vallen maar dat wil nog niet zeggen dat het altijd aan 'de MBO mentaliteit' ligt en dat als je echt leet bent je 100% veilig zit. Niets is minder waar, security audits en beveligingsmaatregels (meervoud!) hebben altijd zin. Denk dat je veiliger zit als je er vanuit gaat dat alles te kraken is en je niet alles kunt weten, dan dat je zo arrogant bent dat je denkt dat je alles al gezien hebt....

Welkom in de échte wereld.

Hier draait het niet om programmeurs, maar om het snelle geld.
Hier draait het niet om perfectie, maar om de volgende opdracht.
Hier worden keuzes gemaakt op basis van budget, niet op basis van niveau.

Natuurlijk is dat vervelend vanuit het oogpunt van een échte IT'er. Perspectief is het sleutelwoord. Zolang de achterban niet heel hard klaagt, waarom zou je dan veel geld steken in iets (lees: goed geschoolde programmeur inzetten) als je het tevredenheidsniveau er kennelijk niets mee verhoogd?

Ik denk niet dat "mindere" programmeurs de oorzaak zijn van hacks, laat staan dat ze hoofdelijk aansprakelijk gesteld zouden moeten worden.

Wat dan wel? Gewoon heldere eisen waar iets aan moet voldoen en daar niet de security in vergeten. Simpel requirements stellen.

Daar kun je niet altijd voor zorgen. Als hoster bv. kun je dit draaien om je klanten (die hun eigen code schrijven) te beschermen. Deze "beveiliging" kan een extra troef zijn waarmee je extra klanten binnenhaalt.

klanten die daarvoor gaan biedt ik liever een geisoleerde server aan, die niet gedeeld is met klanten met potentieel twijfelachtige code.

Desalnietemin zijn zaken als mod_security ook een extra laag (mits ze dat omzeilings verhaal fixen) om fouten af te vangen. De vuistregel is simpelweg: code kan en zal altijd fouten bevatten. Ook al spendeer je tig uur per week aan dergelijke fouten vinden en oplossen, dan nog zal er altijd wel wat door kunnen glippen.

[Reactie gewijzigd door arjankoole op 26 juli 2012 20:41]

Het voorkomen van SQL injection is vrij gemakkelijk als je prepared statements gebruikt. Er zijn natuurlijk nog genoeg andere attack vectors, maar SQL injection hoeft anno 2012 niet meer zo'n groot probleem te zijn.

Wanneer het op security aankomt dien je geen risico's te nemen en is het dus beter om op meerdere manieren vulnerabilities te voorkomen, als dat in ieder geval een betere veiligheids garantie biedt. Zowel het schrijven van code waar SQL-injecties niet in mogelijk zijn als het bovengenoemde firewall idee, lijkt mij dan dus de oplossing. Bij een grote applicatie ben je je bovendien niet altijd bewust van de vulnerabilities die er in zitten en er in zijn geslopen met de jaren.

Het is dan ook enkel een extra drempeltje en ook goed voor de performance.
Lekker 90% van de foute pogingen door zo'n "firewall" laten wegwerken, dan hoef je ook niet de relatief zware programmeercode uit te laten voeren.

Je maakt een grapje, hoop ik. In welke wereld is het draaien van een complex filter die een hoop CPU kracht vreet goed voor de performance? Hoeveel van de requests zullen legitiem zijn (en onnodig gecontroleerd?).
Het is een beetje als de TSA, in het wilde weg alles controleren, maakt niet uit wat het kost, en maar hopen dat je ooit iets vangt.

Het gaat hier dan ook om firewalls die HTTP-specifieke regels kunnen afdwingen. Het gaat dan niet om "poort 80 open of sluiten" maar om "Apache krijgt een verzoek aan met header X, voldoet die request aan onze regels?". Je kan zo bepaalde dingen blokkeren of toestaan die je in je firewall (die lager staat in het OSI model), in plaats van direct elke request te weigeren.

Dat die programma's worden gebruikt om programmeerfouten op te vangen is inderdaad not-done, maar het heeft wel degelijk nut.

[Reactie gewijzigd door Kosty op 26 juli 2012 17:06]

Ik denk toch dat het al een aanzienlijk verschil maakt al dan niet met of zonder mod security.

Bovendien heeft die kerel er zelf ook voordeel bij: het gratis alternatief afbreken, zodat het commercieel van Qualis verkocht zou raken ...

Dat is zeker waar, maar als hij 150 manieren presenteerd heeft hij toch al wel zijn best gedaan om het geloofwaardig te laten overkomen

Ik denk het ook, het is net als een captcha: het houd de meeste bots buiten de deur, maar niet al het gespuis kan worden tegen gehouden. Niks is ooit helemaal 100% veilig.

Sowieso, dit probleem bestaat al een hele tijd. De mentaliteit van programmeurs kun je niet zomaar veranderen, deze producten zouden op zich wel een goede uitkomst kunnen geven. Ik weet niet of het hosting bedrijf waar ik zit dit heeft, ik probeer dit soort dingen sowieso al via htaccess er uit te filteren, al weet ik niet hoe effectief dat precies is

wel nogal doorzichtig dat hij zich vooral richt op het product dat hij ooit zelf gestart is, maar nu van een concurrent is

Hij is niet de enige met kritiek op mod_security en andere WAFs. Ook Stefan Esser heeft al verschillende malen over het omzeilen van mod_security gesproken/geschreven.

Als de WAF anders omgaat met request parameters dan de doelapplicatie (bijvoorbeeld iets in PHP), dan is er al een probleem bij het filteren van gevaarlijke requests.

Zulke issues worden dan wel weer een voor een gefixt, maar de fundamentele 'impedance mismatch' blijft bestaan.

Dergelijke firewalls moeten mogelijk schadelijke http-requests voor webservers tegenhouden, zoals pogingen tot sql-injectie.

Leuk, erg handig, maar alsnog discutabel over het punt waarop het opgelost wordt.

Zeker als daar ook nog eens false positives op gaan komen.

Anderzijds neemt zo'n firewall wel wat junk requests voor zijn rekening, wat dan resulteerd in minder load op de webserver zelf.

Ik laat het nog even in het midden, markt is de laatste paar jaar explosief gegroeid met traffic shapers, hotbricks en dit soort routers.

Ik zit gelukkig ook nog achter een Cisco firewall waar ook alleen ftp en http doorheen komt.

Ik zit gelukkig ook nog achter een Cisco firewall waar ook alleen ftp en http doorheen komt.

die dus effectief niets voor je gaat doen in deze situatie.

Ik zit gelukkig ook nog achter een Cisco firewall waar ook alleen ftp en http doorheen komt.

LOL

Volgens mij zijn alle firewalls - indien je de juiste info hebt - makkelijk uit te schakelen.
Vroegah in mijn "actieve" dagen heb ik toch meerdere progjes via dos weten te vermommen zodat de firewall (zowel hardware als software matig) dacht dat het progje bij een al geaccepteerd programma / service hoorde.
Dan was je wel een hele dag bezig met kutten, maar had je ook wat !

Wij gebruiken varnish, om invalid url af te handelen.

Website maker, geeft aan ons door hoe de request er uit horen te zien en wij filteren het in varnish. De invalid request worden gelogd. Soms zijn deze logs wel grappig om te zien wat mensen uitproberen

Wij bieden dit als extra dienst naar onze klanten toe. Niet omdat we de code niet vertrouwen, maar een foutje is zo gemaakt.

Volgens de huidige ontwikkelaars van de opensource-firewall is daartoe besloten om dat nginx en IIS steeds meer marktaandeel van Apache afsnoepen.

NGINX snoept wel maar IIS al heel lang niet meer.


http://news.netcraft.com/...ver-survey.html#more-6111