--[ Présentation de ModSecurity ]--------------------------------------- --[ 1. Introduction ]--------------------------------------------------- Cette brève présente le module ModSecurity de Apache. mod_security est un moteur de détection et de prévention d'intrusion Open Source pour les applications Web. Le terme plus générique de pare-feu applicatif peut être utilisé. --[ 2. Dispositifs ]---------------------------------------------------- mod_security intègre plusieurs dispositifs permettant d'augmenter la puissance de protection contre des attaques web. Ces dispositifs sont le filtrage de requêtes, les techniques anti- évasion, l'analyse du contenu lors de l'utilisation de la méthode POST, la journalisation des requêtes, le filtrage HTTPS, le filtrage des données compressées. A titre informatif, il est intéressant de voir également comment peut être mis en place le filtrage d'URL avec un Apache installé en relais inverse avec mod_rewrite: http://www.hsc.fr/ressources/breves/filtre-relais-inverse.html.fr http://www.hsc.fr/ressources/breves/pourquoi-relais-inverse.html.fr --[ 3. Exemple d'architecture ]----------------------------------------- mod_security peut être utilisé en tant que relais inverse plutôt que intégré à chaque serveur à protéger. Ceci permet ainsi de protéger plusieurs serveurs Web même si ces derniers ne sont pas des Apache. Ceci peut être fait en couplant un ensemble de modules tels que mod_security, mod_proxy, mod_rewrite, mod_dosevasive ou mod_headers. Dans le cas de l'utilisation de mod_security en relais inverse, l'architecture ci-dessous peut très bien être envisageable: mod_security Serveur Web + (IIS, Apache, Iplanet) Pare-feu mod_proxy _____ ____ __ 443 | | | | | | Client <--------->| |<-------->| |<---------->| | Web 80 |_____| |____| |__| --[ 4. Configuration de base ]------------------------------------------ La configuration de mod_security peut s'effectuer par l'intermédiaire du fichier modsecurity.conf. Une directive doit alors être rajoutée dans le fichier de configuration httpd.conf de Apache: Include conf/modsecurity.conf L'activation de mod_security afin de normaliser les requêtes effectuées sur le serveur Web se fait grâce à la variable SecFilterEngine dans le fichier modsecurity.conf: SecFilterEngine On L'activation des fonctionnalités de mod_security peut également être faite uniquement pour le contenu dynamique: SecFilterEngine DynamicOnly Une fois activé, mod_security interceptera et vérifira toutes les requêtes entrantes sur le serveur Web. Les requêtes seront ensuite passées aux filtres définis par l'utilisateur et seront soit acceptées, soit refusées. Les lignes suivantes sont à rajouter dans le fichier modsecurity.conf afin d'effectuer certaines actions: - Interception des requêtes POST: SecFilterScanPOST On - Changer l'identité du serveur Web Apache: SecServerSignature "Apache/1.3.33 (Darwin)" - Pour les applications web, seuls les encodages application/x-www-form-urlencoded et multipart/form-data sont utilisés. Il est possible de spécifier que seules les requêtes avec ces deux encodages soient acceptées: SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)" - Prévention contre le chunked transfer encoding: SecFilterSelective HTTP_Transfer-Encoding "!^$" - Prévention contre les URL mal encodées (typiquement pour ne pas violer le système de numérotation hexadécimale, ou pour vérifier qu'une chaîne Unicode est valide): SecFilterCheckURLEncoding On SecFilterCheckUnicodeEncoding On - Prévention contre les attaques par débordement de tampon en limitant la quantité d'octets autorisés dans les chaînes de requêtes (par exemple, si le langage utilisé dans les applications est l'anglais, limiter le byte range à 32-126): SecFilterForceByteRange 32 126 - Interdire les requêtes invalides avec un statut erreur 400 et journaliser cette action: SecFilterDefaultAction "deny,log,status:400" - Journaliser les actions et les requêtes suspectes: SecAuditEngine RelevantOnly SecAuditLog /var/www/logs/audit_log --[ 5. Règles de filtrage ]--------------------------------------------- mod_security utilise des règles de filtrage formées d'expressions régulières afin d'analyser les en-têtes, les variables d'environnement, les variables de serveur, les cookies utilisateur ou le payload des méthodes POST. - Les règles s'écrivent, d'une manière générale, à l'aide de la directive SecFilter. Celle-ci permettra d'appliquer une règle à l'ensemble des informations envoyées par le navigateur: SecFilter MOT_RECHERCHE - Par exemple, la règle pour bloquer l'accès à l'URL http://www.hsc.fr/tmp/essai.sh peut être la suivante: SecFilter /tmp/ - Bloquer l'accès au fichier passwd: SecFilter /etc/passwd - Interdire la commande ls: SecFilter /bin/ls - Provoquer une redirection: SecFilter /etc/passwd redirect:http://www.hsc.fr/mauvaise/requete.html - Il est également possible de n'écrire des règles que pour certaines parties des requêtes HTTP (REMOTE_ADDR, QUERY_STRING, COOKIES_VALUES, etc...): SecFilterSelective QUERY_STRING MOT_RECHERCHE Les exemples suivants sont intéressants pour se faire une idée sur l'écriture des règles: - Accepter seulement les versions de protocole valides: SecFilterSelective SERVER_PROTOCOL !^HTTP/(0\.9|1\.0|1\.1)$ - Permettre seulement les méthodes indispensables: SecFilterSelective REQUEST_METHOD !^(GET|HEAD|POST)$ - Interdire la méthode TRACE: SecFilterSelective REQUEST_METHOD "TRACE" - Exiger HTTP_USER_AGENT et HTTP_HOST dans chaque requête: SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$" - Exiger une longueur exacte du corps du message pour chaque requête POST: SecFilterSelective REQUEST_METHOD ^POST$ chain SecFilterSelective HTTP_Content-Length ^$ - Empêcher l'accès au fichier /etc/shadow: SecFilterSelective THE_REQUEST "/etc/shadow" - Empêcher la commande /bin/ps: SecFilterSelective THE_REQUEST "/bin/ps" - Empêcher une attaque transversale de répertoire: SecFilter "\.\./" - Empêcher le téléchargement de fichiers avec wget: SecFilterSelective THE_REQUEST "wget " - Bloquer le bot DTS Agent: SecFilterSelective HTTP_USER_AGENT "DTS Agent" - Bloquer le proxy ouvert ayant comme adresse 12.148.163.152: SecFilterSelective REMOTE_ADDR 12\.148\.163\.152 --[ 6. Détection des attaques de type injection SQL ]------------------- mod_security permet la détection des attaques de type injection SQL. Pour rappel, une injection SQL consiste à modifier une variable utilisée par une requête SQL de manière à ce que des commandes arbitraires soient exécutées. La requête SQL modifiée pourrait alors avoir la forme suivante: SELECT * FROM users WHERE username = 'hsc' and password = 'xxx' OR 1=1--' La règle à appliquer pour contrer cette attaque serait: SecFilter "or.+1[[:space:]]*= [[:space:]]1" Les règles suivantes sont utiles pour contrer certaines requêtes: SecFilter "delete[[:space:]]+from" SecFilter "create[[::space:]]+table" SecFilter "update.+set.+=" SecFilter "insert[[:space:]]+into" SecFilter "select.+from" SecFilterSelective ARGS "drop[[:space:]]+database" SecFilterSelective ARGS "drop[[:space:]]+table" Pour les attaques sur les bases de données MS-SQL, la commande xp_cmdshell est couramment utilisée. Les règles suivantes sont intéressantes dans ce cas: SecFilter "exec.+xp_" SecFilter "@@[[:alnum:]]+" SecFilter "exec.+sp_" SecFilter "load[[:space:]]+data" --[ 7. Détection des attaques XSS ]------------------------------------- Les attaques par Cross-Site-Scripting (XSS) sont multiples et variées sur les applications Web. De ce fait, définir des règles pour mod_security n'est pas trivial et les règles doivent être adaptées aux besoins propres des applications. Cependant, une base de départ peut être la suivante afin d'interdire le HTML et le JavaScript dans les requêtes: SecFilter "" SecFilter "<(.|\n)+>" SecFilter "<( |\n)*script" SecFilter "<[[:space:]]*script" Toutes les règles sont à adapter en fonction des applications de manière à éviter les faux positifs qui peuvent être nombreux. --[ 8. Conclusion ]----------------------------------------------------- Avec la multiplication des attaques sur les applications Web, le simple filtrage IP n'est plus suffisant pour se protéger des attaques et les fonctionnalités de mod_security deviennent indispensables. Configuré en relais inverse filtrant, mod_security permet d'augmenter sa sécurité et de se protéger efficacement contre des attaques de type injection SQL ou XSS et ceci sans ré-écrire les applications Web. La configuration des règles de filtrage peut nécessiter un travail poussé mais nécessaire pour trouver le bon compromis entre sécurité et bon fonctionnement des applications. -- Stéphane Milani --[ 9. Références ]----------------------------------------------------- - Le site Web de mod_security http://www.modsecurity.org - Présentation de mod_security (Apache) Frédéric Laplagne - OSSIR http://www.ossir.org/resist/supports/cr/20050627/mod_security.pdf - Apache en relais inverse Denis Ducamp http://www.hsc.fr/ressources/breves/relais-inverse.html.fr - Pourquoi un relais inverse Denis Ducamp http://www.hsc.fr/ressources/breves/pourquoi-relais-inverse.html.fr - Filtrer des URLs dans un relais inverse Denis Ducamp http://www.hsc.fr/ressources/breves/filtre-relais-inverse.html.fr - Mise en oeuvre de filtrage avec mod_eaccess sur un relais HTTP inverse Christophe Premel http://hsc.fr/ressources/breves/filtrage-url.html.fr - Aspects de HTTP/1.1 pour la réalisation d'un relais de sécurité Marc Baudoin http://www.hsc.fr/ressources/presentations/http-1.1/index.html.fr - Présentation sur les attaques XSS Alain Thivillon http://www.hsc.fr/~thivillon/04_failles_xss.pdf - Présentation Sécurité des bases de données et des ERP Alain Thivillon et Nicolas Jombart http://www.hsc.fr/ressources/presentations/csm05-bderp/index.html.fr - PCRE - Perl-compatible regular expressions http://www.pcre.org/pcre.txt - perlre - Perl regular expressions http://perldoc.perl.org/perlre.html