Un guide pratique pour sécuriser et durcir le serveur HTTP Apache.

Le serveur web est un élément essentiel des applications basées sur le web. Le serveur Web Apache est souvent placé à la périphérie du réseau ; il devient donc l’un des services les plus vulnérables aux attaques.

La configuration par défaut fournit de nombreuses informations sensibles qui peuvent aider les pirates à préparer une attaque contre les applications. La majorité des attaques contre les applications web sont des attaques par XSS, fuite d’informations, gestion de session et injection SQL, qui sont dues à un code de programmation faible et à l’absence d’assainissement de l’infrastructure de l’application web.

Une étude intéressante menée par Positive Technologies révèle que 52 % des applications analysées présentaient des vulnérabilités importantes.

vulnerability-report

Dans cet article, je vais vous présenter quelques-unes des meilleures pratiques pour sécuriser le serveur HTTP Apache sur la plateforme Linux.

Les pratiques suivantes ont été testées sur la version 2.4.x d’Apache.

  • Cela suppose que vous avez installé Apache sur une plate-forme UNIX. Si ce n’est pas le cas, vous pouvez consulter le guide d’installation d’Apache.
  • Tout au long de ce guide, j’appellerai le répertoire d’installation d’Apache /opt/apache $Web_Server.
  • Nous vous conseillons de faire une sauvegarde du fichier de configuration existant avant toute modification.

Public

Ce guide s’adresse à l’administrateur Middleware, au support applicatif, à l’analyste système, ou à toute personne travaillant ou désireuse d’apprendre les directives de durcissement et de sécurité.

Une bonne connaissance du serveur Web Apache et des commandes UNIX est obligatoire.

Remarques

Vous avez besoin d’un outil pour examiner les en-têtes HTTP pour certaines vérifications de l’implémentation. Il y a deux façons de le faire.

  1. Utilisez les outils de développement intégrés au navigateur pour inspecter les en-têtes HTTP. En général, ils se trouvent sous l’onglet Réseau
  2. Utilisez l’outil de vérification des en-têtes de réponse HTTP en ligne

Supprimer la bannière de version du serveur

Je dirais que c’est l’une des premières choses à considérer, car vous ne voulez pas exposer la version du serveur web que vous utilisez. Exposer la version signifie que vous aidez les pirates à accélérer le processus de reconnaissance.

La configuration par défaut expose la version d’Apache et le type de système d’exploitation, comme indiqué ci-dessous.

apache-server-banner
  • Allez dans le dossier $Web_Server/conf
  • Modifiez httpd.conf à l’aide de l’éditeur vi
  • Ajoutez la directive suivante et sauvegardez le fichier httpd.conf
ServerTokens Prod
ServerSignature Off
  • Redémarrez apache

ServerSignature supprimera les informations de version de la page générée par Apache.

ServerTokens changera Header en production uniquement, c’est-à-dire Apache

Comme vous pouvez le voir ci-dessous, les informations relatives à la version et au système d’exploitation ont disparu.

apache-server-banner-masked

Désactiver l’affichage des répertoires dans le navigateur

Désactiver la liste des répertoires dans un navigateur, de sorte que le visiteur ne puisse pas voir tous les fichiers et dossiers que vous avez à la racine ou dans un sous-répertoire.

Essayons de voir ce que cela donne avec les paramètres par défaut.

  • Allez dans le répertoire $Web_Server/htdocs
  • Créez un dossier et quelques fichiers à l’intérieur
# mkdir test
# touch hi
# touch hello

Maintenant, essayons d’accéder à Apache par http://localhost/test

apache-directory-listing

Comme vous pouvez le voir, cela révèle tous les fichiers/dossiers que vous avez et je suis sûr que vous ne voulez pas exposer cela.

  • Allez dans le répertoire $Web_Server/conf
  • Ouvrez httpd.conf en utilisant vi
  • Cherchez Directory et changez la directive Options en None ou -Indexes
<Répertoire /opt/apache/htdocs>
Options -Indexes
</Directory>

(ou)

<Répertoire /opt/apache/htdocs>
Options None
</Directory>
  • Redémarrez Apache

Note: si vous avez plusieurs directives Directory dans votre environnement, vous devriez envisager de faire la même chose pour toutes.

Maintenant, essayons d’accéder à Apache par http://localhost/test

disabled-directory-listing

Comme vous pouvez le constater, une erreur interdite s’affiche au lieu de la liste des dossiers de test.

Etag

Cette vulnérabilité permet à des attaquants distants d’obtenir des informations sensibles telles que le numéro d’inode, la frontière MIME multipartite et le processus enfant par le biais de l’en-tête Etag.

Pour éviter cette vulnérabilité, implémentez-la comme suit. Ceci est nécessaire pour la conformité PCI.

  • Allez dans le répertoire $Web_Server/conf
  • Ajoutez la directive suivante et sauvegardez le fichier httpd.conf
FileETag None
  • Redémarrez Apache

Exécutez Apache à partir d’un compte non privilégié

Une installation par défaut s’exécute en tant que nobody ou daemon. Il est bon d’utiliser un utilisateur non privilégié distinct pour Apache.

L’idée est de protéger les autres services en cours d’exécution en cas de faille de sécurité.

  • Créez un utilisateur et un groupe appelés apache
# groupadd apache
# useradd -G apache apache
  • Changez la propriété du répertoire d’installation d’apache en faveur d’un utilisateur non privilégié nouvellement créé
# chown -R apache:apache /opt/apache
  • Allez dans $Web_Server/conf
  • Modifiez httpd.conf en utilisant vi
  • Recherchez la directive User & Group et modifiez-la en tant que compte non privilégié apache
Utilisateur apache 
Groupe apache
  • Sauvegardez le fichier httpd.conf
  • Redémarrez Apache

grep pour le processus http en cours d’exécution et assurez-vous qu’il est exécuté avec l’utilisateur apache

# ps -ef |grep http

Vous devriez voir qu’un processus s’exécute avec l’utilisateur root. C’est parce qu’Apache écoute sur le port 80 et qu’il doit être démarré avec l’utilisateur root.

Protéger les droits d’accès aux répertoires binaires et de configuration

Par défaut, les permissions pour les répertoires binaires et de configuration sont de 755, ce qui signifie que n’importe quel utilisateur sur un serveur peut voir la configuration. Vous pouvez interdire à un autre utilisateur d’accéder aux répertoires conf et bin.

  • Allez dans le répertoire $Web_Server
  • Modifiez les permissions des dossiers bin et conf
# chmod -R 750 bin conf

Protection des paramètres du système

Dans une installation par défaut, les utilisateurs peuvent modifier la configuration d’apache en utilisant .htaccess. Si vous souhaitez empêcher les utilisateurs de modifier les paramètres de votre serveur apache, vous pouvez ajouter AllowOverride à None comme indiqué ci-dessous.

Cette opération doit être effectuée au niveau de la racine.

  • Allez dans le répertoire $Web_Server/conf
  • Ouvrez httpd.conf en utilisant vi
  • Recherchez le répertoire au niveau de la racine
<Répertoire /> 
Options -Index 
AllowOverride Aucun
</Directory>
  • Sauvegardez le fichier httpd.conf
  • Redémarrez Apache

Méthodes de requête HTTP

Le protocole HTTP 1.1 prend en charge de nombreuses méthodes de requête qui peuvent ne pas être nécessaires et dont certaines présentent un risque potentiel.

En règle générale, vous pouvez avoir besoin des méthodes de requête GET, HEAD, POST dans une application web, qui peuvent être configurées dans la directive Directory correspondante.

La configuration par défaut prend en charge les méthodes OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT dans le protocole HTTP 1.1.

  • Allez dans le répertoire $Web_Server/conf
  • Ouvrez httpd.conf en utilisant vi
  • Recherchez Directory et ajoutez ce qui suit
<LimitExcept GET POST HEAD>
refuser à tous
</LimitExcept>
  • Redémarrez Apache

Désactiver la méthode de traçage des requêtes HTTP

Par défaut, la méthode Trace est activée dans le serveur web Apache.

L’activation de cette méthode peut permettre une attaque de type Cross Site Tracing et donner la possibilité à un pirate de voler des informations sur les cookies. Voyons à quoi cela ressemble dans la configuration par défaut.

  • Faites un telnet de l’IP du serveur web avec le port d’écoute
  • Effectuez une requête TRACE comme indiqué ci-dessous
#telnet localhost 80 
Essai sur 127.0.0.1...
Connecté à localhost.
Le caractère d'échappement est '^]'.
TRACE / HTTP/1.1 Hôte : test
HTTP/1.1 200 OK
Date : Sat, 31 Aug 2013 02:13:24 GMT
Serveur : Apache
Transfer-Encoding : chunked
Content-Type : message/http 20
TRACE / HTTP/1.1
Hôte : test 
0
Connexion fermée par l'hôte étranger.
#

Comme vous pouvez le voir dans la requête TRACE ci-dessus, il a répondu à ma demande. Désactivons-le et testons-le.

  • Allez dans le répertoire $Web_Server/conf
  • Ajoutez la directive suivante et sauvegardez le fichier httpd.conf
TraceEnable off
  • Redémarrez apache

Faites un telnet de l’IP du serveur web avec le port d’écoute et faites une requête TRACE comme indiqué ci-dessous

#telnet localhost 80
Essayez 127.0.0.1...
Connecté à localhost.
Le caractère d'échappement est '^]'.
TRACE / HTTP/1.1 Hôte : test
HTTP/1.1 405 Méthode non autorisée
Date : Sat, 31 Aug 2013 02:18:27 GMT
Server : Apache Allow:Content-Length : 223Content-Type : text/html ; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> 
<title>405 Méthode non autorisée</title> </head><body> 
<h1>Méthode non autorisée</h1>
<p>La méthode TRACE demandée n'est pas autorisée pour l'URL /.</p> </body></html>
Connexion fermée par l'hôte étranger.
#

Comme vous pouvez le voir dans la requête TRACE ci-dessus, il a bloqué ma requête avec HTTP 405 Method Not Allowed.

Maintenant, ce serveur web n’autorise pas les requêtes TRACE et aide à bloquer l’attaque Cross Site Tracing.

Vous pouvez atténuer la plupart des attaques courantes de Cross Site Scripting en utilisant les drapeaux HttpOnly et Secure dans un cookie. Sans HttpOnly et Secure, il est possible de voler ou de manipuler la session et les cookies d’une application web, et c’est dangereux.

  • Assurez-vous que mod_headers.so est activé dans votre httpd.conf
  • Allez dans le répertoire $Web_Server/conf
  • Ajoutez la directive suivante et sauvegardez le fichier httpd.conf
Editer l'en-tête Set-Cookie ^(.*)$ $1;HttpOnly;Secure
  • Redémarrez apache

Attaque par détournement de clics

Le détournement de clic est une vulnérabilité bien connue des applications web.

  • Assurez-vous que mod_headers.so est activé dans votre httpd.conf
  • Allez dans le répertoire $Web_Server/conf
  • Ajoutez la directive suivante et sauvegardez le fichier httpd.conf
L'en-tête ajoute toujours X-Frame-Options SAMEORIGIN
  • Redémarrez apache
apache-x-frame-options

X-Frame-Options supporte deux options supplémentaires, que j’explique ici.

Server Side Include (inclusion côté serveur)

Server Side Include (SSI) risque d’augmenter la charge du serveur. Si vous avez un environnement partagé et des applications web à fort trafic, vous devriez envisager de désactiver SSI en ajoutant Includes dans la directive Options.

L’attaque SSI permet d’exploiter une application web en injectant des scripts dans les pages HTML ou en exécutant des codes à distance.

  • Allez dans le répertoire $Web_Server/conf
  • Ouvrez httpd.conf en utilisant vi
  • Recherchez Directory et ajoutez Includes dans la directive Options
<Répertoire /opt/apache/htdocs>
Options -Indexes -Includes
Order allow,denyAllow from all
</Directory>
  • Redémarrez Apache

Remarque : si vous avez plusieurs directives Directory dans votre environnement, vous devriez envisager de faire la même chose pour toutes.

Protection contre les X-XSS

La protection contre les scripts intersites (XSS) peut être contournée dans de nombreux navigateurs. Vous pourriez appliquer cette protection à une application web si elle était désactivée par l’utilisateur. Cette protection est utilisée par la majorité des entreprises géantes du web comme Facebook, Twitter, Google, etc.

  • Allez dans le répertoire $Web_Server/conf
  • Ouvrez httpd.conf à l’aide de vi et ajoutez la directive Header suivante
Header set X-XSS-Protection "1 ; mode=block"
  • Redémarrez Apache

Comme vous pouvez le constater, la protection XSS est injectée dans l’en-tête de la réponse.

apache-xss

Désactivez le protocole HTTP 1.0

Lorsque nous parlons de sécurité, nous devrions protéger autant que possible. Alors pourquoi utiliser les anciennes versions du protocole HTTP, désactivons-les également ?

HTTP 1.0 présente des faiblesses de sécurité liées au détournement de session. Nous pouvons la désactiver en utilisant le module mod_rewrite.

  • Assurez-vous de charger le module mod_rewrite dans le fichier httpd.conf
  • Activez la directive RewriteEngine comme suit et ajoutez une condition de réécriture pour n’autoriser que HTTP 1.1
RewriteEngine On
RewriteCond %{THE_REQUEST} !HTTP/1.1$
RewriteRule .* - [F]

Configuration de la valeur du délai d’attente

Par défaut, le délai d’attente d’Apache est de 300 secondes, ce qui peut entraîner une attaque Slow Loris et un déni de service. Pour atténuer ce problème, vous pouvez réduire la valeur du délai d’attente à 60 secondes.

  • Allez dans le répertoire $Web_Server/conf
  • Ouvrez httpd.conf en utilisant vi
  • Ajoutez ce qui suit dans httpd.conf
Timeout 60

SSL

Le SSL est une couche de sécurité supplémentaire que vous ajoutez à l’application Web. Cependant, la configuration SSL par défaut entraîne certaines vulnérabilités, et vous devriez envisager de modifier ces configurations.

Clé SSL

Il est difficile, mais pas impossible, de violer la clé SSL. C’est juste une question de puissance de calcul et de temps.

Comme vous le savez peut-être, en utilisant un PC de l’ère 2009 qui craque pendant environ 73 jours, vous pouvez désosser une clé de 512 bits.

Ainsi, plus la longueur de la clé est élevée, plus il est difficile de casser la clé SSL. La majorité des grandes entreprises du web utilisent une clé de 2048 bits, comme ci-dessous, alors pourquoi pas nous ?

  • Outlook.com
  • Microsoft.com
  • Live.com
  • Skype.com
  • Apple.com
  • Yahoo.com
  • Bing.com
  • Hotmail.com
  • Twitter.com

Vous pouvez utiliser OpenSSL pour générer une CSR avec 2048 bits comme ci-dessous.

openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

Cela générera un CSR que vous devrez envoyer à une autorité de certification pour qu’elle le signe. Une fois que vous avez reçu le fichier de certificat signé, vous pouvez l’ajouter dans le fichier httpd-ssl.conf

SSLCertificateFile #Certificat signé par l'autorité
SSLCertificateChainFile #Signataire du certificat donné par l'autorité
SSLCertificateKeyFile #Fichier de clé que vous avez généré ci-dessus
  • Redémarrez le serveur web Apache et essayez d’accéder à l’URL avec https

Chiffre SSL

Le chiffrement SSL est un algorithme de cryptage utilisé comme clé entre deux ordinateurs sur l’internet. Le cryptage des données est le processus de conversion d’un texte en clair en codes cryptés secrets.

C’est en fonction de la configuration du chiffrement SSL de votre serveur web que le chiffrement des données aura lieu. Il est donc important de configurer un chiffrement SSL plus fort et moins vulnérable.

  • Allez dans le dossier $Web_Server/conf/extra
  • Modifiez la directive SSLCipherSuite dans httpd-ssl.conf comme suit pour n’accepter que les algorithmes de cryptage plus puissants
SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4
  • Enregistrez le fichier de configuration et redémarrez le serveur Apache

Note : si vous avez beaucoup d’algorithmes de chiffrement faibles dans votre rapport d’audit SSL, vous pouvez rapidement les rejeter en ajoutant ! au début.

Désactiver SSL v2 & v3

SSL v2 & v3 présente de nombreuses failles de sécurité, et si vous travaillez en vue d’un test de pénétration ou d’une mise en conformité PCI, vous êtes censé fermer la découverte de sécurité pour désactiver SSL v2/v3.

Toute communication SSL v2/v3 peut être vulnérable à une attaque de type Man-in-The-Middle qui pourrait permettre la falsification ou la divulgation de données.

Implémentons le serveur web Apache pour qu’il n’accepte que la dernière version de TLS et rejette les demandes de connexion SSL v2/v3.

  • Allez dans le dossier $Web_Server/conf/extra
  • Modifiez la directive SSLProtocol dans httpd-ssl.conf comme suit pour n’accepter que TLS 1.2 
SSLProtocol -ALL TLSv1.2

Une fois que vous avez terminé la configuration de SSL, il est conseillé de tester votre application web avec l’outil de certificat SSL/TLS en ligne afin de détecter toute erreur de configuration.

Mod Security

Mod Security est un pare-feu d’application web open-source, que vous pouvez utiliser avec Apache.

Il se présente sous la forme d’un module que vous devez compiler et installer. Si vous n’avez pas les moyens d’acheter un pare-feu commercial pour applications web, ce serait un excellent choix.

Pour assurer la protection des applications web génériques, les règles de base utilisent les techniques suivantes :

  • Protection HTTP – détection des violations du protocole HTTP et d’une politique d’utilisation définie localement
  • Consultation de listes noires en temps réel – utilisation de la réputation IP de tiers
  • Détection des logiciels malveillants sur le web – identifie les contenus web malveillants en vérifiant l’API Google Safe Browsing.
  • Protections contre les dénis de service HTTP – défense contre l’inondation HTTP et les attaques DoS HTTP lentes.
  • Protection contre les attaques Web courantes – détection des attaques de sécurité des applications Web courantes
  • Détection de l’automatisation – détection des bots, des crawlers, des scanners et d’autres activités de surface malveillantes
  • Intégration avec AV Scanning for File Uploads – identifie les fichiers malveillants téléchargés par l’intermédiaire de l’application web.
  • Suivi des données sensibles – Suivi de l’utilisation des cartes de crédit et blocage des fuites.
  • Protection contre les chevaux de Troie – Détection de l’accès aux chevaux de Troie.
  • Identification des défauts de l’application – alerte sur les mauvaises configurations de l’application.
  • Détection et masquage des erreurs – dissimulation des messages d’erreur envoyés par le serveur.

Téléchargement et installation

Les prérequis suivants doivent être installés sur le serveur sur lequel vous souhaitez utiliser Mod Security avec Apache. Si l’un d’entre eux n’existe pas, la compilation de Mod Security échouera. Vous pouvez utiliser yum install sur Linux ou Centos pour installer ces paquets.

  • apache 2.x ou plus
  • paquet libpcre
  • paquet libxml2
  • paquet liblua
  • paquet libcurl
  • paquets libapr et libapr-util
  • module mod_unique_id intégré au serveur web Apache

Maintenant, téléchargez la dernière version stable de Mod Security 2.7.5 à partir d’ici

  • Transférez le fichier téléchargé dans /opt/apache
  • Extrayez modsecurity-apache_2.7.5.tar.gz
# gunzip -c modsecurity-apache_2.7.5.tar.gz | tar xvf -
  • Allez dans le dossier extrait modsecurity-apache_2.7.5
# cd modsecurity-apache_2.7.5
  • Exécutez le script de configuration en incluant le chemin apxs vers l’Apache existant
# ./configure -with-apxs=/opt/apache/bin/apxs
  • Compilez et installez avec le script make
# make
# make install
  • Une fois l’installation terminée, vous verrez mod_security2.so dans le dossier modules sous /opt/apache

En conclusion, vous avez installé le module Mod Security dans le serveur web Apache existant.

Configuration

Pour utiliser la fonctionnalité Mod security avec Apache, nous devons charger le module mod security dans httpd.conf. Le module mod_unique_id est un pré-requis pour Mod Security.

Ce module fournit une variable d’environnement avec un identifiant unique pour chaque requête, qui est suivi et utilisé par Mod Security.

  • Ajoutez la ligne suivante pour charger le module pour Mod Security dans httpd.conf et sauvegardez le fichier de configuration
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so
  • Redémarrez le serveur web apache

Le module Security est maintenant installé !

La prochaine chose à faire est d’installer la règle de base de Mod Security pour profiter pleinement de ses fonctionnalités.

La dernière règle de base peut être téléchargée à partir du lien suivant, qui est gratuit. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • Copiez le fichier zip de la règle de base téléchargé dans le dossier /opt/apache/conf
  • Décompressez le fichier core rule
  • Vous pouvez renommer le dossier en quelque chose de court et facile à retenir. Dans cet exemple, je le renommerai crs.
  • Allez dans le dossier crs et renommez modsecurity_crs10_setup.conf.example en modsecurity_crs10_setup.conf

Maintenant, activons ces règles pour qu’elles fonctionnent avec le serveur web Apache.

  • Ajoutez ce qui suit dans httpd.conf
<IfModule security2_module>
Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf
</IfModule>

Dans la configuration ci-dessus, nous chargeons le fichier de configuration principal de Mod Security modsecurity_crs_10_setup.conf et les règles de base base base_rules/*.conf fournies par Mod Security Core Rules pour protéger les applications web.

  • Redémarrez le serveur web Apache

Vous avez configuré avec succès Mod Security avec Apache !

C’est très bien. Maintenant, le serveur Web Apache est protégé par le pare-feu d’application Web de Mod Security.

Commencer

Commençons par quelques configurations critiques dans Mod Security pour durcir et sécuriser les applications web.

Dans cette section, nous ferons toutes les modifications de configuration dans /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

Dans cette section, nous ferons référence à /opt/apache/conf/crs/modsecurity_crs_10_setup.conf en tant que setup.conf à titre d’exemple.

Il est important de comprendre quelles sont les règles OWASP fournies gratuitement. Il existe deux types de règles fournies par l’OWASP.

Règles de base – ces règles sont fortement testées, et le taux de fausses alarmes est probablement plus faible.

Règles expérimentales – ces règles ont un but expérimental, et vous pouvez avoir un taux de fausses alarmes élevé. Il est important de les configurer, de les tester et de les mettre en œuvre dans le cadre de l’expérimentation avant de les utiliser dans un environnement de production.

Règles optionnelles – ces règles optionnelles peuvent ne pas convenir à l’ensemble de l’environnement. Vous pouvez les utiliser en fonction de vos besoins.

Si vous recherchez une protection contre le CSRF, le suivi des utilisateurs, le détournement de session, etc., vous pouvez envisager d’utiliser des règles optionnelles. Nous disposons des règles de base, optionnelles et expérimentales après avoir extrait le fichier zip crs téléchargé depuis la page de téléchargement de l’OWASP.

Le fichier de configuration de ces règles est disponible dans les dossiers crs/base_rules, crs/optional_rules et crs/experimental_rules. Familiarisons-nous avec quelques-unes des règles de base.

  • modsecurity_crs_20_protocol_violations.conf : Cette règle protège des vulnérabilités protocolaires telles que le fractionnement des réponses, la contrebande de requêtes, l’utilisation d’un protocole non autorisé (HTTP 1.0).
  • modsecurity_crs_21_protocol_anomalies.conf : Il s’agit de se protéger d’une requête dont l’en-tête ne contient pas les champs Host, Accept et User-Agent.
  • modsecurity_crs_23_request_limits.conf : Cette règle dépend d’applications spécifiques telles que la taille de la requête, la taille du téléchargement, la longueur d’un paramètre, etc.
  • modsecurity_crs_30_http_policy.conf:Cette règle permet de configurer et de protéger les méthodes autorisées ou interdites telles que CONNECT, TRACE, PUT, DELETE, etc.
  • modsecurity_crs_35_bad_robots.conf:Détecter les robots malveillants
  • modsecurity_crs_40_generic_attacks.conf:Il s’agit de se protéger contre l’injection de commandes OS, l’inclusion de fichiers à distance, etc.
  • modsecurity_crs_41_sql_injection_attacks.conf:Cette règle protège les demandes d’injection SQL et SQL aveugle.
  • modsecurity_crs_41_xss_attacks.conf:Protection contre les requêtes de type Cross-Site Scripting.
  • modsecurity_crs_42_tight_security.conf:Détection et protection contre la traversée de répertoire.
  • modsecurity_crs_45_trojans.conf:Cette règle permet de détecter les sorties génériques de gestion de fichiers, le téléchargement d’une page de porte dérobée HTTP, une signature connue.
  • modsecurity_crs_47_common_exceptions.conf:Cette règle est utilisée comme mécanisme d’exception pour supprimer les faux positifs courants qui peuvent être rencontrés, tels que la connexion factice interne d’Apache, l’avertissement SSL, etc.

Journalisation

La journalisation est l’une des premières choses à configurer pour que vous puissiez créer des journaux sur ce que fait Mod Security. Il y a deux types de logs disponibles ; Debug & Audit log.

Debug Log : il s’agit de dupliquer les messages d’erreur, d’avertissement et de notification d’Apache à partir du journal des erreurs.

Journal d’audit : il s’agit d’écrire les journaux de transactions qui sont marqués par la règle de Mod Security. Mod Security vous donne la possibilité de configurer l’audit, le débogage ou les deux types de journalisation.

La configuration par défaut permet d’écrire les deux journaux. Toutefois, vous pouvez modifier cette configuration en fonction de vos besoins. Le journal est contrôlé par la directive SecDefaultAction. Examinons la configuration par défaut de la journalisation dans le fichier setup.conf

SecDefaultAction "phase:1,deny,log"

Pour enregistrer les journaux de débogage et d’audit, utilisez “log” Pour enregistrer uniquement les journaux d’audit, utilisez “nolog,auditlog” Pour enregistrer uniquement les journaux de débogage, utilisez “log,noauditlog” Vous pouvez spécifier l’emplacement de stockage des journaux d’audit, qui est contrôlé par la directive SecAuditLog.

Écrivons le journal d’audit dans /opt/apache/logs/modsec_audit.log en ajoutant ce qui suit.

  • Ajoutez la directive SecAuditLog dans le fichier setup.conf et redémarrez le serveur Web Apache
SecAuditLog /opt/apache/logs/modsec_audit.log
  • Après le redémarrage, vous devriez voir le fichier modsec_audit.log se générer

Activez le moteur de règles

Par défaut, le moteur de règles est désactivé, ce qui signifie que si vous n’activez pas le moteur de règles, vous n’utiliserez pas tous les avantages de Mod Security.

L’activation ou la désactivation du moteur de règles est contrôlée par la directive SecRuleEngine.

  • Ajoutez la directive SecRuleEngine dans le fichier setup.conf et redémarrez le serveur Web Apache
SecRuleEngine On

Il existe trois valeurs pour SecRuleEngine :

  • On – pour activer le moteur de règles
  • Off – pour désactiver le moteur de règles
  • DetectionOnly – active le moteur de règles mais n’exécute jamais d’actions telles que le blocage, le refus, l’abandon, l’autorisation, le proxy ou la redirection

Une fois que le moteur de règles est activé, Mod Security est prêt à vous protéger contre certains types d’attaques courantes.

Protection contre les types d’attaques courantes

Maintenant, le serveur web est prêt à protéger contre les types d’attaques courantes comme XSS, SQL Injection, Protocol Violation, etc. puisque nous avons installé Core Rule et activé Rule Engine. Testons-en quelques-uns.

Attaque XSS

  • Ouvrez Firefox et accédez à votre application en plaçant la balise