Sécuriser un serveur web Apache© avec mod_security

mod_security a plusieurs groupes d'option. Voici quelques-unes des directives de configuration de base.

SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On

La première ligne modifie la requête d'examen à on ou off. Les deux autres lignes contrôlent si les requêtes et les données du corps de la réponse seront examinées par le module. N'oubliez pas que les données doivent être bufférisées. Cela signifie que cela est requis pour l'examen des requêtes HTTP POST, mais on doit les buffériser et de ce fait cela demande de la mémoire. Vous pouvez réduire la quantité de mémoire utilisée par cette directive.

SecRequestBodyInMemoryLimit 131072

Vous pouvez également limiter la taille des données du corps de la requête HTTP. C'est très pratique pour désactiver des données importantes dans les requêtes HTTP POST.

SecRequestBodyLimit 10485760

Chaque requête supérieure à 10485760 octets verra s'afficher le message d'erreur 413 Request Entity Too Large. Le nombre par défaut est 134217728 octets (131072 KO).

Les serveurs Web incluent typiquement le type MIME (Multipurpose Internet Mail Extensions) des données qu'ils mettent dans les réponses. Vous pouvez contrôler les types que vous voulez examiner. Habituellement, vous ne voudrez pas analyser des données de type JPEG ou PDF (Portable Document Format).

SecResponseBodyMimeTypesClear
SecResponseBodyMimeType (null) text/plain text/html text/css text/xml

La première directive affiche la liste des types à vérifier. La seconde ligne définit les types qui nous intéressent. Le téléversement de fichiers peut être une chose que vous souhaitez contrôler. Vous pouvez transférer chaque fichier téléversé dans un répertoire distinct. En outre, vous pouvez rassembler tous les fichiers téléversés de votre serveur à condition que vous ayez de l'espace disque. Ceci peut être utile lors d'activités légales après que quelque chose se soit mal passé.

SecUploadDir /var/spool/apache/private
SecUploadKeepFiles Off

Il est de bon ton de ne pas utiliser le répertoire habituel dévolu aux fichiers temporaires pour stocker les téléversements. Créez un répertoire à cet effet et définissez les permissions adéquates. Seul Apache© doit accéder à cet emplacement.

Vous pouvez permettre l'audit de journalisation, qui peut vous aider fortement pendant le déboguage ou lors de pires situations. Vous avez le choix de tout journaliser ou seulement les évènements qui ont déclenché une des vérifications internes de mod_security. Ceci inclut les groupes de règles.

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^[45]"

Nous voulons seulement noter les évènements appropriés et nous concentrer sur les réponses qui génèrent des codes de statut 4xx ou 5xx. C'est le rôle des expressions régulières. Vous pouvez tout journaliser si vous en avez besoin. La journalisation peut être notée dans un simple fichier ou dans un répertoire avec un fichier par évènement noté. Le dernier est habituellement réservé aux sites à gros volume.

SecAuditLogType Serial
SecAuditLog /var/log/www/modsec_audit.log
# SecAuditLogStorageDir /var/log/www/modsec_audit

Ainsi qu'il est noté ci-dessus, le contenu qui peut être journalisé est étendu. Vous pouvez journaliser des parties de la requête HTTP originale avec la réponse.

SecAuditLogParts "ABEIFHZ"

Cela signifie qu'on veut noter la vérification d'en-tête et de bas de page (options A et H), la requête originale (option B), la réponse intermédiaire du corps (option E), la requête modifiée du corps (option I), la réponse finale de l'en-tête (option F) et l'extrémité finale de l'évènement journalisé (option Z, qui est obligatoire). La réponse intermédiaire du corps est soit la réponse originale, soit la réponse modifiée par mod_security. La requête modifiée du corps est soit la requête originale du corps, soit une variante abrégée quand l'encodage multipart/form-data est employé. Les options par défaut sont ABIFHZ.

Le module de sécurité emploie cinq phases distinctes pour le traitement des requêtes et des réponses depuis le serveur web.

Il est important de penser à ceci quand vous concevez vos groupes de règles, presque comme quand vous concevez les filtres de paquets. La directive SecRule décrit une règle.

SecRule VARIABLES [OPERATOR] ACTIONS

Une fois écrit sous cette forme, mod_security

Souvenez-vous de la règle d'essai avec la chaîne « attack ». Nous avons indiqué au module d'examiner la variable REQUEST_URI de la requête HTTP et d'appliquer l'opérateur d'expression régulière visant à rechercher la chaîne désirée. Nous n'avons fait aucune action, ainsi l'action par défaut prévaut. Vous pouvez combiner des variables en employant des opérateurs logiques.

SecRule "REQUEST_URI|QUERY_STRING" attack

Ceci fait la même chose mais avec deux variables différentes. L'action sera déclenchée si le fragment de chaîne est trouvé dans l'une ou l'autre variable. Vous pouvez employer des opérateurs bien connus à l'intérieur des règles. L'assortiment des expressions régulières se fait grâce à la bibliothèque PCRE, ainsi vous pouvez utiliser toutes les constructions que PCRE comprend (ce qui est fondamentalement tout ce que vous pouvez faire avec la concordance des modèles de Perl). Les longues lignes peuvent être séparées en utilisant \ juste comme avec des scripts shell Bash.

N'oubliez pas que la section VARIABLES contient des variables. Leur contenu varie. Si la variable est vide ou non présente, la règle ne correspond pas. Ceci est important et la vérification des paramètres le demande. Les variables peuvent être ARGS, FILES, FILES_TMPNAMES, ENV, REMOTE_PORT, QUERY_STRING, SCRIPT_BASENAME,AUTH_TYPE, REQUEST_COOKIES, SESSIONID, TIME et beaucoup d'autres. La référence comporte une liste complète.

Les règles mod_security peuvent contenir des opérateurs. Ils sont utilisés pour valider la requête ou pour chercher des anomalies particulières. Le @ indique qu'un opérateur suit.

SecRule ARGS "@validateUtf8Encoding"
SecRule ARGS "@validateByteRange" 10,13,32-126

La première règle examine la requête pour s'assurer que l'encodage UTF-8 (Unicode Transformation Format) est valide. Le second exemple examine une plage spécifique de caractères dans la requête. Si la requête contient d'autres caractères que le saut de ligne, le retour chariot ou les caractères US ASCII (American Standard Code for Information Interchange, alors l'action se déclenche. Vous pouvez également faire appel à des scripts additionnels.

SecRule FILES_TMPNAMES "@inspectFile /usr/local/bin/check_file.pl" 

Ceci redirige tous les fichiers téléversés vers le script Perl afin de procéder à d'autres contrôle. Le code de sortie du script indique à mod_security s'il doit agir ou non. Vous pouvez même utiliser des listes noires en temps réel pour vos règles.

SecRule REMOTE_ADDR "@rbl bad.guys.and.girls.example.net"

Il y a cinq types généraux d'actions.

L'action par défaut peut être définie avec la directive SecDefaultAction. Elle peut être modifiée chaque fois que vous en avez besoin, ainsi vous pouvez définir des blocs de règles avec différentes actions par défaut. Les actions sont très semblables à celles utilisées par le logiciel de détection et de prévention d'intrusions Snort. Elles vous procurent beaucoup de flexibilité et elles autorisent une sélection tout à fait complexe d'essais. Voici un exemple de règle du noyau qui recherchent des tentatives d'injecter un message électronique dans une requête.

SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/* "[\n\r]\s*(?:to|bcc|cc)\s*:.*?\@" \
  "t:none,t:lowercase,t:urlDecode,capture,ctl:auditLogParts=+E,log,auditlog,msg:'Email Injection Attack.
  Matched signature <%{TX.0}>',,id:'950019',severity:'2'"</%{TX.0}>

Notez que j'ai inséré un saut de ligne pour une meilleure lisibilité. Le paramètre d'action est une simple chaîne qui indique au module de consigner chaque correspondance dans le fichier courant log et dans auditlog avec un message texte Email Injection Attack accompagné de plusieurs paramètres de la requête. Les règles du noyau ont d'autres exemples pour d'autres attaques comme le cross-site scripting, les injections SQL (structured query language, Langage structuré de requête), les anomalies HTTP et similaires.