WEB APPLICATION FIREWALL AVEC APACHE ET MOD_SECURITY version 1.00 Objectifs Cette fiche pratique permet d atteindre deux objectifs distincts et potentiellement complémentaires. Configuration d Apache en reverse-proxy Installation et configuration d un firewall applicatif avec mod_security Si ces deux fonctions sont activées sur la même machine, il est ainsi possible de protéger un serveur Web non Apache (Internet Information Server par exemple) Organisation des travaux pratiques Dans les travaux pratiques, le reverse-proxy Apache et le navigateur de l utilisateur sont installés sur une machine unique. Le site form.demonstrations.org à protéger est quant à lui disponible sur le poste de l intervenant. Dans cette fiche, le serveur form.demonstrations.org dispose de l adresse 192.168.0.102 alors que le reverse-proxy est installé sur la machine 192.168.0.221 Etapes des travaux pratiques Vérification de la connectivité entre le futur reverse-proxy et le serveur form.demonstrations.org : Le reverse-proxy, lorsqu il reçoit une requête d un utilisateur doit se connecter au serveur web. Si cette connexion n est pas possible, le reverse-proxy ne peut assurer son rôle Configuration du reverse-proxy : Présentation des directives (basiques) de mise en place d un reverse-proxy avec Apache et test du bon fonctionnement. Test de la faisabilité de l attaque SQL Injection. Mise en place du firewall applicatif : En quelques directives mod_security, nous éliminerons la faisabilité de l attaque SQL Injection testée cidessus. Web Application Firewall avec Apache et Mod_Security v. 1.00 page 1
Détails de mise en oeuvre Vérification de la connectivité entre le futur reverse-proxy et le serveur form.demonstrations.org : Pour s assurer que le serveur destiné à devenir reverse-proxy peut se connecter au site de démonstrations, il convient de vérifier l adresse IP de la machine la route par défaut utilisée le fichier hosts cette vérification est nécessaire car l adresse du site form.demonstrations.org n est pas déclarée dans les DNS Depuis le navigateur du reverse-proxy (si le serveur X est installé), tester maintenant la connexion. Si X n est pas installé, il est possible d utiliser lynx ou un telnet sur le port 80. Web Application Firewall avec Apache et Mod_Security v. 1.00 page 2
Configuration du reverse-proxy : Commençons par tester le serveur Apache sur la machine reverse-proxy. Si nécessaire, démarrer le démon Apache avec la commande «/etc/init.d/httpd start». Comme ne le voyons ci-dessus, avant la configuration d Apache en reverse-proxy, les demandes sont traitées avec les fichiers locaux. Ici, la page d accueil par défaut d Apache sous Fedora. Les directives Apache doivent être placées dans le fichier httpd.conf situé dans le répertoire /etc/httpd/conf. Toutefois, celui contient la directive «Include conf.d/*.conf» qui permet de placer des directives dans des fichiers dont l extension est «.conf» et qui se trouvent dans le répertoire /etc/httpd/conf.d. Pour définir les directives de reverse-proxy, nous allons donc créer le fichier /etc/httpd/conf.d/reverse.conf. En utilisant le module proxy, une unique directive est nécessaire. Toutefois, pour empêcher qu Apache ne fasse également office de proxy, nous ajouterons la directive «ProxyRequests Off». La directive obligatoire est la directive «ProxyPass / http://form.demonstrations.org/». Ceci indique à apache que pour toute requête à partir de «/», il devra se connecter à «http://form.demonstrations.org/». Attention, le / en fin d Url de redirection est très important. Si celui-ci est oublié, toute requête vers une URI différente de «/» échouera. Une fois le fichier «reverse.conf» correctement renseigné, il est nécessaire de redémarrer le serveur Apache pour que celui-ci prenne la nouvelle configuration en compte : «/etc/init.d/httpd restart» Si l on réalise une nouvelle connexion au Apache du reverse-proxy, le résultat est tout autre : Pour information, le module mod_rewrite peut également permettre de configurer Apache en reverseproxy. Le fichier ci-dessous donne le même résultat que le précédent. Web Application Firewall avec Apache et Mod_Security v. 1.00 page 3
Notre reverse-proxy est maintenant opérationnel mais comme le montre la figure ci-dessous, les attaques applicatives restent parfaitement possibles Mise en place du firewall applicatif : Pour que ce reverse-proxy apporte un plus en sécurité, nous allons maintenant configurer mod_security. Les sources de celui-ci pourraient être téléchargées sur http://www.modsecurity.org puis compilées avec la commande «apxs» du package http_devel. Toutefois, nous allons utiliser la version rpm Dans le répertoire contenant le rpm, il suffit de taper la commande «rpm ivh mod_security*» En conséquence de cette installation, le répertoire /etc/httpd/modsecurity.d a été créé. Il contient les règles de sécurité par défaut de mod_security 2.x. Le fichier /etc/httpd/conf.d/mod_security.conf est également créé lors de l installation pour activer mod_security et les règles par défaut. Les règles fournies dans le package sont difficiles à comprendre tant les expressions régulières utilisées sont incompréhensibles pour le néophyte. Nous allons donc épurer le fichier «/etc/httpd/conf.d/mod_security.conf» pour réaliser une configuration simple permettant de bloquer l attaque SQL Injection précédente Web Application Firewall avec Apache et Mod_Security v. 1.00 page 4
Les directives «SecRuleEngine On» et «SecRequestBodyAccess On» activent le module mod_security et permet l inspection du corps de requête. Le format de la directive SecRule est «SecRule objets_analysés information_recherchée action». Dans notre exemple, nous recherchons dans une variable «inlogin» (champ login du formulaire du site de démonstration). L expression régulière «[a-z]{4}[0-9]$» permet de tester si le contenu de la variable commence (^) par 4 minuscules ([a-z]{4}) suivi d un chiffre ([0-9]) puis se termine ($). Comme nous allons bloquer les requêtes et que nous souhaitons interdire tout login qui ne respecte pas le format présenté, il convient d ajouter une négation (!). L expression régulière de la règle proposée permet donc de tester tout login qui n est pas composé de 4 minuscules et un chiffre L action consiste à interdire la demande en revoyant un code 406 au demandeur. Cette interdiction sera enregistrée dans les logs. En mod_security 2.x la phase Apache de traitement de la directive mod_security doit être précisée. Utiliser «phase:2» pour un fonctionnement comparable à mod_security 1.x. Pour de plus amples informations, consulter le site mod_security. Testons maintenant l attaque en passant par le reverse-proxy Comme prévu, l attaque est maintenant arrêtée Voici quelques possibilités complémentaires mod_security - action proxy Web Application Firewall avec Apache et Mod_Security v. 1.00 page 5
- action redirect - deux tests avec chain (équivalent d un AND) Pour la démonstration, nous allons tester que le login est «user1» et le mot de passe différent de «pwd1». Cet exemple n a comme seul objectif celui de présenter «chain» Web Application Firewall avec Apache et Mod_Security v. 1.00 page 6