1 / 37

Sécurité et Firewall Applicatifs 09/05/2011

Sécurité et Firewall Applicatifs 09/05/2011. 1. Sommaire. L e web, la bête noire de la sécurité ? C omme si la situation n’était pas déjà assez compliquée comme ça … Q uelle contre mesures ? F irewalls applicatifs U ne approche différente du firewall applicatif ! O ui mais ….

dwayne
Download Presentation

Sécurité et Firewall Applicatifs 09/05/2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sécurité et Firewall Applicatifs 09/05/2011 1

  2. Sommaire • Le web, la bête noire de la sécurité ? • Comme si la situation n’était pas déjà assez compliquée comme ça … • Quelle contre mesures ? • Firewalls applicatifs • Une approche différente du firewall applicatif ! • Oui mais …

  3. Le web, la bête noire de la sécurité ? 3

  4. Le Web, la bête noire de la sécurité ? • Pour une fois, l’actualité (juste des deux derniers mois, question de place) me donne raison, je ne vais pas me priver ! • MySQL.com • RSA • Sony PSN • HBGarry • Lisamoon • Tous ceux que j’ai oublié • Tous ceux qui ne l’ont pas avoué • Tous ceux qui n’en ont même pas conscience • … Pas d’inquiétude vis-à-vis de la sécurité web ?

  5. Le Web, la bête noire de la sécurité ? • MySQL.com : (28 Mars 2011) Base de donnée compromise via une injection SQL en aveugle, hash de mots de passe déposés sur internet. • RSA : (15 mars 2011) Même si des schémas d’attaque avancés ont étés utilisés, le point d’entrée reste une vulnérabilité web. • Sony PSN : (Mai 2011) On ne sait pas (encore) s’il s’agit d’une vulnérabilité applicative, mais le point d’entrée reste un forum (web) • Lisamoon : (Mai 2011) Vers abusant d’injections SQL pour compromettre des sites web, plus d’UN MILLION de sites infectés • HBGarry : (Avril 2011) Outre le caractère trollifère de cette histoire, le point d’entrée est ?

  6. Le web, la bête noire de la sécurité ? • L’actualité ne fait que confirmer ce que les pentesteurs voient tous les jours. • ADMIN’ OR ‘1’=‘1 • La sécurité web est aujourd’hui le point faible de la plupart des systèmes informatiques : • Applicatifs et sites web « historiques » • Développeurs mal sensibilisés • Coût prohibitif de la mise en place d’un pare-feu applicatif • Les sites développés en 2011 continuent d’être vulnérables ! (il ne sert à rien de se mentir) Pensez vous que vos sites web soient exempts de failles ? Sont-ils correctement isolés ?

  7. Comme si la situation n’était pas déjà assez compliquée comme ça … 8

  8. Comme si la situation n’était pas assez compliquée comme ça … • Les techniques d’obfuscation des attaques ne cessent d’évoluer, et rendent de plus en plus complexes les méthodes de détection : • Encoding complexes, abus des formats et syntaxes exotiques supportées • Des navigateurs toujours aussi (voir même de plus en plus ?) laxistes • Le tout combiné avec des sites de plus en plus complexes/interactifs, utilisant de plus en plus d’entrées utilisateurs dans des endroits dangereux (javascript ou autre) • Il devient de plus en plus complexe d’assurer une couverture des risques à 100%

  9. Comme si la situation n’était pas assez compliquée comme ça … Patterns d’attaques ou bluff ? 1°) $=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$__:++$,$_$:++$,$$__:({}+"")[$],$$_:++$,$$$:++$,$__:++$,$__$:++$};$.$_=($.$_=$+"")[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+"")[$.__$])+((!$)+"")[$._$$]+($.__=$.$_[$.$$_])+($.$=(!""+"")[$.__$])+($._=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+(!""+"")[$._$$]+$.__+$._+$.$+$.$$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$$+"\""+$.$_$_+(![]+"")[$._$_]+$.$$$_+"\\"+$.__$+$.$$_+$._$_+$.__+"("+$.__$+")"+"\"")())(); 2°) (+[])[([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+….+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!+[]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!+[]+[])[+[]]+(!+[]+[])[!+[]+!+[]+!+[]]+(!+[]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[[+!+[]]+[!+[]+!+[]+!+[]+!+[]+!+[]]])() 3°) ﾟωﾟﾉ= /｀ｍ´）ﾉ ~┻━┻ //*´∇｀*/ ['_']; o=(ﾟｰﾟ) =_=3; c=(ﾟΘﾟ) =(ﾟｰﾟ)-(ﾟｰﾟ); (ﾟДﾟ) =(ﾟΘﾟ)= (o^_^o)/ (o^_^o);(ﾟДﾟ)={ﾟΘﾟ: '_' ,ﾟωﾟﾉ : ((ﾟωﾟﾉ==3) +'_') [ﾟΘﾟ] ,ﾟｰﾟﾉ :(ﾟωﾟﾉ+ '_')[o^_^o -(ﾟΘﾟ)] ,ﾟДﾟﾉ:((ﾟｰﾟ==3) +'_')[ﾟｰﾟ] }; (ﾟДﾟ) [ﾟΘﾟ] =((ﾟωﾟﾉ==3) +'_') [c^_^o];(ﾟДﾟ) ['c'] = ((ﾟДﾟ)+'_') [ (ﾟｰﾟ)+(ﾟｰﾟ)-(ﾟΘﾟ) ];(ﾟДﾟ) ['o'] = ((ﾟДﾟ)+'_') 4°) javascript:alert('XSS') 5°) setter=alert,a=/XSS/.source

  10. Comme si la situation n’était pas assez compliquée comme ça … • Les technologies – et les navigateurs - continuent d’évoluer, et ce n’est pas pour arranger les choses : • HTML5 • Javascript offrant le support du multi-threading • Javascript offrant la possibilité de réaliser des communications autres que HTTP • L’impact potentiel d’un cross-site-scripting ne sera plus jamais le même ! • Apparition des IDN (noms de domaine accentués) Il devient de plus en plus complexe d’assurer une couverture des risques à 100%

  11. Quelles contre mesures ? 12

  12. Quelles contre-mesures ? • Des bons développeurs, sensibilisés aux problématiques de sécurité ? • Le pentesteur : Vu ce que l’on voit au quotidien, cela va être long • Le RSSI : Les développeurs sont coûteux à former dans un domaine qui n’est pas leur cœur de métier • Ce n’est pas pour tout de suite malheureusement, l’histoire se répète, et le suivi des vulnérabilités parle de lui-même : • Le 9 Mai 2011 : Onze exploits pour des vulnérabilités web publiées depuis le début du mois • Le 9 Mai 2011 : Trois exploits pour des vulnérabilités « autres » (BOF en tout genres) publiés depuis le début du mois

  13. Quelles contre-mesures ? • De plus, le niveau technique requis pour exploiter une vulnérabilité web est, dans 95% des cas très faible: • L’exploitation (et donc l’écriture d’un exploit) d’une vulnérabilité type heap/stackoverflow est bien plus complexe. • Concernant l’exploitation d’une vulnérabilité web, bien souvent, Google combiné à un copier/coller peut faire l’affaire ! • On ne compte plus le nombre de « defacement », souvent révélateurs de la mentalité et du niveau technique de l’attaquant. Et pour les « anciens » sites ?

  14. Firewalls applicatifs 15

  15. Firewalls applicatifs • Un WAF est un mécanisme placé en amont de l’applicatif à protéger • Son but est de détecter les motifs dangereux et de les bloquer • Il existe (beaucoup) d’implémentations propriétaires, vendues sous formes d’appliances, et effectuant (plus) ou moins bien leur travail • Il existe aussi une option open-source : mod_security, module de la fameuse fondation Apache

  16. Firewalls applicatifs • Mod_security est un très beau/bon produit, bénéficiant déjà d’une bonne maturité, MAIS : • S’il s’agit de protéger autre chose que du Apache, il faut l’utiliser en reverse-proxy, avec mod_proxy, qui, lui, n’a pas très bonne réputation • Il repose sur des règles complexes, qu’il faut mettre à jour régulièrement • Ou alors payer un « feed » pour des règles plus fines, mais qu’il faut quand même mettre à jour régulièrement

  17. Firewalls applicatifs • De manière plus générale, les WAFs posent certains problèmes : • Configuration souvent complexe • Maintenance des règles de sécurité • Reporting • Réponse en profondeur aux problèmes • S’il ne s’agit pas d’un produit open-source, cout d’entrée & de licence important, et cout augmentant en fonction du trafic ! Probablement la raison du très faible taux d’adoption des WAFs !

  18. Une approche différente du firewall applicatif ! 19

  19. Introducing NAXSI Nginx Anti Xss Sql Injection Un module (open-source bien sur !) de firewall applicatif pour NGINX

  20. Introducing NAXSI d • Ce module a été conçu, avant tout, pour nos besoins et pour les besoins de nos clients (L’hébergement infogéré est le deuxième métier de NBS System !) • Celui-ci adopte une philosophie simple : • Des patterns extrêmement simples • Une configuration accessibles aux non experts, avec un auto apprentissage • Pas de mise à jour des règles • Un logiciel ayant pour objectif de rester SIMPLE • Un logiciel utilisable par des techniciens faisant de l’exploitation et non seulement par un expert en sécurité

  21. Introducing NAXSI • NAXSI repose sur NGINX, le reverse-proxy/serveur web venu du froid • NGINX est orienté hautes performances, capable de gérer 10K de connexions simultanées avec moins 10Mo de mémoire • Il s’agit d’un projet très actif, et que nous utilisons notamment en tant que reverse proxy en environnement de production : • 1000 sites web, dont 600 de e-commerce • 1 To de trafic total par jour (web uniquement) • Plus de 300 serveurs physiques • 4 Nginx actifs pour gérer la quasi-totalité du trafic

  22. Introducing NAXSI • Le concept de NAXSI est de rester simple : • Interdire les caractères qui n’ont rien à faire dans une requête normale : • < > ‘ ; …. • Et appliquer de la liste blanche sur les pages nécessitant des caractères anormaux • Pas de base de signature à maintenir, et les règles sont extrêmement simples et claires ! • Le module se voulant simple au possible, toute l’intelligence associée à ce genre de mécanisme est externalisée, dans l’objectif d’être fortement interopérable !

  23. Mode de fonctionnement 24

  24. Mode de fonctionnement • Un set de règles communes, peu nombreuses (moins de 50) • Avec une syntaxe simple, et faciles à comprendre : • MainRule "str:/*" "msg:mysql comment (/*)" "mz:BODY|URL|ARGS" "s:$SQL:8" id:1003; • MainRule "rx:http://|https://" "msg:protocolscheme" "mz:BODY|ARGS" "s:$RFI:4" id:1007; • Qui ne devraient donc pas demander d’être maintenues, car reposant sur des primitives très simples !

  25. Mode de fonctionnement • Combinée avec une configuration « par site » pour gérer les listes blanches : • BasicRule wl:1304 "mz:$URL:/site/v1.2/images/interne/home_inscription_news.jpg|URL" id:0; • Et de manière plus générale, le comportement : • CheckRule "$SQL >= 8" BLOCK; • CheckRule "$RFI >= 4" BLOCK; • CheckRule "$TRAVERSAL >= 4" BLOCK; • CheckRule "$XSS >= 2" LOG; • CheckRule "$XSS >= 8" BLOCK; • Pouvoir apporter une réponse « par site » : • DeniedUrl "http://myvulnerablesite/denied_page.php";

  26. Mode de fonctionnement • Toutes les informations sur le pourquoi et le comment d’une requête bloquée sont transmises à la page dite de « blocage ». • Lorsqu’une requête est considérée illégitime, le module retournera un « 302 redirect » vers la page spécifiée en configuration. • Permet d’externaliser l’intelligence du module : • Statistiques • Détection des faux positifs • Réponse en deux temps (blocage de l’attaquant ?) • Permet un bon suivi ‘en temps réel’ des attaques et/ou faux positifs !

  27. Oui mais … 28

  28. Oui mais … la configuration ? • NGINX peut aussi être utilisé en proxy sortant, et le module transmet toutes les informations du blocage à la page web associée. • Ce qui permet la mise en place d’un mode d’auto-apprentissage !

  29. Oui mais … la configuration ? • La page de blocage reçoit toutes les informations associées à la requête bloquée : • Permet de générer les listes blanches directement, et de les écrire dans un fichier : • BasicRulewl:1304 "mz:$URL:/site/v1.2/images/interne/home_inscription_news.jpg|URL" id:0; • BasicRulewl:1305 "mz:$URL:/boutique/liste_produits.cfm|$ARGS_VAR:vente" id:0; • L’objectif ici est que les développeurs, pendant leurs phases de développement et test, puissent générer eux même leur listes blanches, simplement en effectuant des scénarios de navigation. • Comme vous le voyez ci-dessus, la syntaxe des règles est simple, et celles-ci peuvent être revues par un non-expert en sécurité.

  30. Oui mais … le reporting? • La page de blocage reçoit toutes les informations associées à la requête bloquée : • Permet un traitement « sur mesure » des alertes etc., via du développement web (technologie libre) • Génération de statistiques • Réponse en profondeur (communication avec un script iptables ?) • Je ne suis (mal)heureusement pas développeur web, cette partie est donc encore à l’étude. • Nous espérons pouvoir fournir, lors de la release du module, une interface simple et modulaire.

  31. Oui mais … les performances ? • NAXSI repose sur NGINX, connu pour ses hautes performances. • Grâce à une architecture logicielle simple, les performances ne s’en feront que très peu ressentir. • Les premiers tests de charge réalisés : • B1 = Nginx avec le module • B2 = Nginx sans le module

  32. Oui mais … les performances ? • La ou le module aura les plus mauvaises performances est le cas suivant : • Des requêtes légitimes, mais volumineuses. • Dans un tel cas, le module devra parser l’intégralité des données ! • Dans un tel cas, on relève une baisse de 5% des performances maximales de NGINX

  33. Oui mais … l’exploitation ? • Il est ainsi possible de désactiver temporairement tout ou partie des règles du module sur un site (ou une page particulière). • L’objectif est ici de pouvoir amener une réponse technique rapide et adapté à toute problématique de production. • Pouvoir, à tout moment, et avec UNE ligne de configuration, désactiver partiellement le module ! • Désactiver une règle sur un site : • BasicRulewl:1003; • Désactiver le WAF sur une page d’un site : • BasicRulewl:1305 "mz:$URL:/boutique/*" id:0; • BasicRulewl:ALL "mz:$URL:/boutique/*" id:0;

  34. Road Map ! 35 Document confidentiel

  35. RoadMap • Le développement initial du module est (presque !) fini, toutes les fonctionnalités présentées ici sont fonctionnelles. • Mais, avant de distribuer NAXIS, il nous reste a : • Continuer les tests de performances dans différentes situation • Faire tester notre module par des confrères en sécurité pour avoir des points de vue extérieurs et techniques (nul n’est infaillible !) • Nous sommes en train de nous préparer à mettre le module en production sur certains de nos clients en hébergement : l’épreuve du feu ! • Nous avons besoin de votre aide ! • Pentesteurs (Audit du code source et test « live » de la sécurité du produit) • Utilisateurs / RSSI (Donnez nous des idées pour l’interface web !)

  36. Q&A 37

More Related