Entrez les termes que vous recherchez. Envoyer un formulaire de recherche

Sécuriser son serveur Apache avec mod_security

Introduction

Installation

Configuration

Introduction:

Même avec un bon firewall , votre réseau ne sera pas entièrement sécurisé tant que vos applications web resteront vulnérables Le module mod_security vous aidera à stopper les injections de type SQL, le cross-site scripting et d'autres attaques web par l'intermédiaire de données corrompues.
Grâce à ce module, vous pourrez examiner les validations de vos clients sur internet,avant même qu'elles soient traitées par vos scripts.Les évènements et sessions seront journalisées , même ceux dont votre serveur ne tient pas compte habituellement. Vous pourrez non seulement examiner les tentatives de vos attaquants ,mais aussi moduler vos règles de filtrage Mod_security prend aussi en charge le trafic encrypté : il agit avant et après les transactions de données via SSL

Installation

Le module mod_security module fonctionne à la fois avec Apache 1.3 et Apache 2.0. Mandriva a son propre paquetage disponible ,et donc le module s'installe le plus simplement du monde sur un serveur existant et en état de fonctionnement grâce à la commande en root et en console : apache-mod_security

Configuration

La configuration de ce module se passe comme tous les autres modules dans le fichier httpd.conf Les règles sont variables et dépendent hautement de la configuration de votre serveur web
Voici quelques exemples de règles applicables à votre serveur:

        SecFilterEngine On
        SecFilterDefaultAction "deny,log,status:403"
        SecFilterScanPOST On
        SecFilterCheckURLEncoding On
        SecFilterCheckUnicodeEncoding Off
        SecFilterForceByteRange 1 255

La première ligne vérifie que le module mod_security est bien activé pour votre serveur
SecFilterDefaultAction indique le comportement du serveur en cas d'intrusion captée par les filtres : la tentative ici sera loguée , et l'accès sera refusé avec un code 403 message.
SecFilterScanPOST inspectera les requêtes via GET mais aussi par POST.
Setting SecFilterCheckURLEncoding permettra aux valeurs encodées hexadécimales dans les URL d'être examinées.
SecFilterCheckUnicodeEncoding ne sert qu'en cas de valeurs unicode.
SecFilterForceByteRange indique l'écart des valeurs ASCII disponibles dans les requêtes GET et dans les formulaires avec POST.

SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log
SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0

SecAuditEngine peut être fixé à On RelevantOnly ou DynamicOrRelevant pour permettre à mod_security's de journaliser beaucoup plus d'informations que ne le fait Apache par défaut. Avec On toutes les requêtes sont captées, RelevantOnly capte seulement les requêtes correspondant aux filtres mis en place et DynamicOrRelevant journalise à la fois les requêtes appropriées ou les requêtes des gestionnaires non-nul. SecAuditLog indique ou mod_security écrit ses logs.
SecFilterDebugLog, indique ou mod_security journalise les informations de debogage. PLacé à 0, rien n'est journalisé .Les niveaux 1,2,3 affinent les informations de debogage

    SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
    SecFilterSelective HTTP_Content-Type
     "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"
    SecFilterSelective REQUEST_METHOD "^POST$" chain
    SecFilterSelective HTTP_Content-Length "^$"
    SecFilterSelective HTTP_Transfer-Encoding "!^$"

Le premier filtre vérifie si la requête n'est pas de type GET ou HEAD; Ensuite ,il vérifie si elle contient autre chose que des données de type formulaire (content-type "application/x-www-form-urlencoded") ou bien des fichiers uploadés (encoding-type "multipart/form-data"),. Si les deux filtres fonctionnent , si la requête n'est pas de type formulaire ou fichier, cette requête n'est pas autorisée.
Le second filtre vérifie si la requête est de type POST. Si c'est le cas, la vérification se fait pour savoir si le paramètre Content-Length a une valeur nulle; Si c'est le cas, la requête est rejetée.
Notre dernier exemple nous protège contre les valeurs non-nulles pour le paramètre Transfer-Encoding.

D'autres règles intéressantes

- Bloquer l'accès au fichier passwd:
SecFilter /etc/passwd
- Interdire la commande ls:
SecFilter /bin/ls
- Interdire la méthode TRACE:
SecFilterSelective REQUEST_METHOD "TRACE"
- 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
mod_security permet la détection des attaques de type injection SQL. 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 interdire le HTML et le JavaScript dans les requêtes:

  SecFilter ""
  SecFilter "<(.|\n)+>"
  SecFilter "<( |\n)*script"
  SecFilter "<[[:space:]]*script"

Sources de l'article