• Assurez la sécurité des applications de la bonne manière! Détectez, protégez, surveillez, accélérez et plus encore…
  • Un guide pratique pour sécuriser et renforcer Apache HTTP Server.

    Le serveur Web est une partie cruciale des applications Web. Apache Web Server est souvent placé à la périphérie du réseau et devient donc l'un des services les plus vulnérables aux attaques.

    La configuration par défaut fournit des informations très sensibles qui peuvent aider le pirate à se préparer à une attaque des applications. La majorité des attaques d'applications Web sont des attaques XSS, Info Leakage, Session Management et SQL Injection qui sont dues à un code de programmation faible et à l'échec de la désinfection de l'infrastructure des applications Web.

    Recherche intéressante par Technologies positives révèle que 52% des applications analysées présentaient des vulnérabilités élevées.

    Dans cet article, je parlerai de certaines des meilleures pratiques pour sécuriser le serveur HTTP Apache sur la plate-forme Linux.

    Les éléments suivants sont testés sur la version Apache 2.4.x.

    • Cela suppose que vous avez installé Apache sur la plate-forme UNIX. Sinon, vous pouvez passer par le guide d'installation.
    • J'appellerai le répertoire d'installation Apache / opt / apache comme $ Web_Server tout au long de ce guide.
    • Il est conseillé de faire une sauvegarde du fichier de configuration existant avant toute modification.

    Audience

    Ceci est conçu pour l'administrateur middleware, le support d'application, l'analyste système ou toute personne travaillant ou désireuse d'apprendre les directives de renforcement et de sécurité.

    Une bonne connaissance du serveur Web Apache et de la commande UNIX est obligatoire.

    Notes

    Vous avez besoin d'un outil pour examiner les en-têtes HTTP pour une partie de la vérification de l'implémentation. Il y a deux façons de faire ça.

    1. Utilisez les outils de développement intégrés au navigateur pour inspecter les en-têtes HTTP. Habituellement, c'est sous l'onglet Réseau
    2. Utiliser en ligne Outil de vérification des en-têtes de réponse HTTP

    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 révéler la version du serveur Web que vous utilisez. L'exposition de la version signifie que vous aidez le pirate à accélérer le processus de reconnaissance.

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

    • Accédez au dossier $ Web_Server / conf
    • Modifiez httpd.conf à l'aide de l'éditeur vi
    • Ajoutez la directive suivante et enregistrez le 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 l'en-tête en production uniquement, c'est-à-dire Apache

    Comme vous pouvez le voir ci-dessous, les informations sur la version et le système d'exploitation ont disparu.

    Désactiver la liste du navigateur d'annuaire

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

    Testons à quoi cela ressemble dans les paramètres par défaut.

    • Accédez au 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 en http://localhost/test

    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 l'exposer.

    • Accédez au répertoire $ Web_Server / conf
    •  Open httpd.conf en utilisant vi
    •  Recherchez Directory et modifiez la directive Options sur Aucun ou –Indexes
    <Directory /opt/apache/htdocs>
    Options -Indexes
    </Directory>

    (ou)

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

    Notes: si vous avez plusieurs directives Directory dans votre environnement, vous devriez envisager de faire de même pour tous.

    Maintenant, essayons d'accéder à Apache en http://localhost/test

    Comme vous pouvez le voir, il affiche une erreur interdite au lieu d'afficher la liste des dossiers de test.

    Etag

    Il permet aux attaquants distants d'obtenir des informations sensibles telles que le numéro d'inode, la limite MIME en plusieurs parties et le processus enfant via l'en-tête Etag.

    Pour éviter cette vulnérabilité, implémentons-la comme ci-dessous. Ceci est nécessaire pour corriger la conformité PCI.

    • Accédez au répertoire $ Web_Server / conf
    • Ajoutez la directive suivante et enregistrez le 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 personne ou démon. Utiliser un utilisateur non privilégié distinct pour Apache est une bonne chose.

    L'idée ici 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
    • Changer la propriété du répertoire d'installation Apache en un utilisateur non privilégié nouvellement créé
    # chown –R apache:apache /opt/apache
    •  Allez dans $ Web_Server / conf
    •  Modifiez httpd.conf à l'aide de vi
    •  Recherchez la directive utilisateur et groupe et modifiez-la en tant que compte non privilégié Apache
    User apache 
    Group apache
    •  Enregistrez le httpd.conf
    •  Redémarrez Apache

    grep pour exécuter le processus http et s'assurer qu'il fonctionne avec l'utilisateur apache

    # ps –ef |grep http

    Vous devriez voir qu'un processus est en cours d'exécution avec root. C'est parce qu'Apache écoute sur le port 80 et qu'il doit être démarré avec root.

    Protéger les autorisations de répertoire binaire et de configuration

    Par défaut, l'autorisation pour le binaire et la configuration est 755, ce qui signifie que tout utilisateur d'un serveur peut afficher la configuration. Vous pouvez interdire à un autre utilisateur d'accéder au dossier conf et bin.

    • Accédez au répertoire $ Web_Server
    • Modifier l'autorisation du dossier bin et conf
    # chmod –R 750 bin conf

    Protection des paramètres système

    Dans une installation par défaut, les utilisateurs peuvent remplacer la configuration d'Apache à l'aide de .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.

    Cela doit être fait au niveau racine.

    • Accédez au répertoire $ Web_Server / conf
    •  Ouvrez httpd.conf en utilisant vi
    •  Rechercher un répertoire au niveau racine
    <Directory /> 
    Options -Indexes 
    AllowOverride None
    </Directory>
    •  Enregistrez le 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 requises et certaines d'entre elles 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 respective.

    Prise en charge de la configuration par défaut OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT méthode dans le protocole HTTP 1.1.

    •  Accédez au répertoire $ Web_Server / conf
    •  Ouvrez httpd.conf en utilisant vi
    • Recherchez Directory et ajoutez ce qui suit
    <LimitExcept GET POST HEAD>
    deny from all
    </LimitExcept>
    • Redémarrez Apache

    Désactiver la requête HTTP de trace

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

    L'activation de cette option peut permettre une attaque de Cross Site Tracing et potentiellement donner la possibilité à un pirate de voler des informations de cookie. Voyons à quoi cela ressemble dans la configuration par défaut.

    •  Faire une adresse IP de serveur Web telnet avec un port d'écoute
    •  Faites une demande TRACE comme indiqué ci-dessous
    #telnet localhost 80 
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    TRACE / HTTP/1.1 Host: test
    HTTP/1.1 200 OK
    Date: Sat, 31 Aug 2013 02:13:24 GMT
    Server: Apache
    Transfer-Encoding: chunked
    Content-Type: message/http 20
    TRACE / HTTP/1.1
    Host: test 
    0
    Connection closed by foreign host.
    #

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

    •  Accédez au répertoire $ Web_Server / conf
    • Ajoutez la directive suivante et enregistrez le httpd.conf
    TraceEnable off
    •  Redémarrez Apache

    Faites une adresse IP de serveur Web Telnet avec un port d'écoute et faites un TRACE demande comme indiqué ci-dessous

    #telnet localhost 80
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    TRACE / HTTP/1.1 Host: test
    HTTP/1.1 405 Method Not Allowed
    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 Method Not Allowed</title> </head><body> 
    <h1>Method Not Allowed</h1>
    <p>The requested method TRACE is not allowed for the URL /.</p> </body></html>
    Connection closed by foreign host.
    #

    Comme vous pouvez le voir dans la requête TRACE ci-dessus, elle a bloqué ma requête avec la méthode HTTP 405 non autorisée.

    Désormais, ce serveur Web n'autorise pas les requêtes TRACE et ne permet pas de bloquer les attaques de Cross Site Tracing.

    Définir le cookie avec HttpOnly et l'indicateur Secure

    Vous pouvez atténuer la plupart des attaques de type Cross Site Scripting courantes en utilisant HttpOnly et l'indicateur Secure dans un cookie. Sans avoir HttpOnly et Secure, il est possible de voler ou de manipuler la session d'application Web et les cookies, et c'est dangereux.

    •  Assurez-vous que mod_headers.so est activé dans votre httpd.conf
    •  Accédez au répertoire $ Web_Server / conf
    •  Ajoutez la directive suivante et enregistrez le httpd.conf
    Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
    •  Redémarrez Apache

    Attaque de détournement de clic

    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
    •  Accédez au répertoire $ Web_Server / conf
    •  Ajoutez la directive suivante et enregistrez le httpd.conf
    Header always append X-Frame-Options SAMEORIGIN
    •  Redémarrez Apache

    X-Frame-Options prend également en charge deux autres options que j'ai expliquées ici.

    Inclut côté serveur

    L'inclusion côté serveur (SSI) risque d'augmenter la charge sur le serveur. Si vous avez partagé l'environnement et les applications Web à fort trafic, vous devez envisager de désactiver SSI en ajoutant la directive Inclut dans Options.

    L'attaque SSI permet l'exploitation d'une application web en injectant des scripts dans des pages HTML ou en exécutant des codes à distance.

    • Accédez au répertoire $ Web_Server / conf
    •  Ouvrez httpd.conf en utilisant vi
    •  Rechercher un répertoire et ajouter des inclus dans la directive Options
    <Directory /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 de même pour tous.

    Protection X-XSS

    La protection XSS (Cross Site Scripting) peut être contournée dans de nombreux navigateurs. Vous pouvez appliquer cette protection à une application Web si elle a été désactivée par l'utilisateur. Ceci est utilisé par une majorité de sociétés Web géantes comme Facebook, Twitter, Google, etc.

    • Accédez au répertoire $ Web_Server / conf
    • Ouvrez httpd.conf en utilisant vi et ajoutez la directive Header suivante
    Header set X-XSS-Protection "1; mode=block"
    •  Redémarrez Apache

    Comme vous pouvez le voir, XSS-Protection est l'injecté dans l'en-tête de réponse.

    Désactiver le protocole HTTP 1.0

    Lorsque nous parlons de sécurité, nous devons protéger autant que nous le pouvons. Alors pourquoi utilisons-nous une ancienne version HTTP du protocole, désactivons-les également?

    HTTP 1.0 présente une faiblesse de sécurité liée au détournement de session. Nous pouvons désactiver cela 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 autoriser uniquement HTTP 1.1
    RewriteEngine On
    RewriteCond %{THE_REQUEST} !HTTP/1.1$
    RewriteRule .* - [F]

    Configuration de la valeur du délai d'expiration

    Par défaut, la valeur du délai d'attente d'Apache est de 300 secondes, ce qui peut être victime d'une attaque Slow Loris et d'un DoS. Pour atténuer cela, vous pouvez réduire la valeur du délai d'expiration à peut-être 60 secondes.

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

    SSL

    Avoir 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

    La violation de la clé SSL est difficile, mais pas impossible. 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 Rétroconcevoir une clé 512 bits.

    Ainsi, plus la longueur de clé est élevée, plus il devient compliqué de casser la clé SSL. La majorité des sociétés Web géantes 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 un CSR avec 2048 bits comme ci-dessous.

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

    Il générera un CSR que vous devrez envoyer à un autorité de certification pour le signer. Une fois que vous avez reçu le fichier de certificat signé, vous pouvez les ajouter dans le fichier httpd-ssl.conf

    SSLCertificateFile #Certificate signed by authority
    SSLCertificateChainFile #Certificate signer given by authority
    SSLCertificateKeyFile #Key file which you generated above
    • Redémarrez le serveur Web Apache et essayez d'accéder à l'URL avec https

    Chiffrement SSL

    SSL Cipher est un algorithme de cryptage, utilisé comme clé entre deux ordinateurs sur Internet. Le cryptage des données est le processus de conversion de texte brut en codes chiffrés secrets.

    C'est basé sur la configuration de chiffrement SSL de votre serveur Web que le cryptage des données aura lieu. Il est donc important de configurer le chiffrement SSL, qui est plus fort et non vulnérable.

    • Accédez au dossier $ Web_Server / conf / extra
    •  Modifiez la directive SSLCipherSuite dans httpd-ssl.conf comme ci-dessous pour n'accepter que des algorithmes de chiffrement supérieurs
    SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4
    •  Enregistrez le fichier de configuration et redémarrez le serveur Apache

    Remarque: si vous avez de nombreux chiffrements faibles dans votre rapport d'audit SSL, vous pouvez rapidement les rejeter en ajoutant! au début.

    Désactiver SSL v2 et v3

    SSL v2 et v3 présente de nombreuses failles de sécurité, et si vous travaillez à un test de pénétration ou à la conformité PCI, vous devez fermer la recherche de sécurité pour désactiver SSL v2 / v3.

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

    Implémentons le serveur Web Apache pour n'accepter que le dernier TLS et rejeter la demande de connexion SSL v2 / v3.

    • Accédez au dossier $ Web_Server / conf / extra
    • Modifiez la directive SSLProtocol dans httpd-ssl.conf comme ci-dessous pour n'accepter que TLS 1.2+
    SSLProtocol –ALL +TLSv1.2

    Une fois que vous avez terminé avec la configuration SSL, c'est une bonne idée de tester votre application Web avec outil de certificat SSL / TLS en ligne pour trouver une erreur de configuration.

    Mod Security

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

    Il s'agit d'un module que vous devez compiler et installer. Si vous ne pouvez pas vous permettre une publicité Firewall d'applications Web, ce serait un excellent choix pour y aller.

    Pour fournir une protection générique des applications Web, 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
    • Recherches de liste noire en temps réel - utilise la réputation IP tierce
    • Détection de logiciels malveillants basée sur le Web - identifie le contenu Web malveillant en comparant l'API de navigation sécurisée de Google.
    • Protections contre le déni 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é courantes des applications Web
    • Détection d'automatisation - Détection des bots, des robots d'exploration, des scanners et d'une autre activité de surface malveillante
    • Intégration avec AV Scanning pour les téléchargements de fichiers - identifie les fichiers malveillants téléchargés via l'application Web.
    • Suivi des données sensibles - Suit l'utilisation de la carte de crédit et bloque les fuites.
    • Protection des chevaux de Troie - Détecter l'accès aux chevaux de Troie.
    • Identification des défauts d'application - alertes sur les erreurs de configuration de l'application.
    • Détection et masquage des erreurs - Masquage 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 de ces éléments n'existe pas, la compilation de Mod Security échouera. Vous pouvez utiliser yum install sur Linux ou Centos pour installer ces packages.

    • apache 2.x ou supérieur
    • paquet libpcre
    •  paquet libxml2
    • paquet liblua
    • paquet libcurl
    •  paquet libapr et libapr-util
    •  module mod_unique_id fourni avec le serveur Web Apache

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

    • Transférer le fichier téléchargé vers / opt / apache
    • Extraire modsecurity-apache_2.7.5.tar.gz
    # gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –
    • Accédez au dossier extrait modsecurity-apache_2.7.5
    # cd modsecurity-apache_2.7.5
    • Exécutez le script de configuration, y compris le chemin apxs vers Apache existant
    # ./configure –with-apxs=/opt/apache/bin/apxs
    • Compiler et installer avec make script
    # make
    # make install
    • Une fois l'installation terminée, vous verrez mod_security2.so dans le dossier modules sous / opt / apache

    Maintenant que cela se termine, vous avez installé le module Mod Security sur le serveur Web Apache existant.

    configuration

    Pour utiliser la fonction de sécurité Mod avec Apache, nous devons charger le module de sécurité mod 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 en suivant une ligne pour charger le module pour Mod Security dans httpd.conf et enregistrez 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

    Mod Security est maintenant installé!

    La prochaine chose que vous devez faire est d'installer la règle principale de Mod Security pour profiter pleinement de ses fonctionnalités.

    La dernière règle de base peut être téléchargée en suivant un lien, 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 de règles de base
    • Vous souhaiterez peut-être renommer le dossier en quelque chose de court et facile à retenir. Dans cet exemple, je vais renommer en crs.
    • Accédez au dossier crs et renommez modsecurity_crs10_setup.conf.example en modsecurity_crs10_setup.conf

    Maintenant, activons ces règles pour le faire fonctionner 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_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!

    Bien joué. Désormais, le serveur Web Apache est protégé par le pare-feu d'application Web Mod Security.

    Commencer

    Commençons par certaines des configurations critiques de Mod Security pour renforcer et sécuriser les applications Web.

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

    Nous référencerons /opt/apache/conf/crs/modsecurity_crs_10_setup.conf comme setup.conf dans cette section à 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 inférieur.

    Règles expérimentales - ces règles sont à des fins expérimentales, et vous pouvez avoir une fausse alarme élevée. Il est important de configurer, tester et implémenter dans UAT avant de les utiliser dans un environnement de production.

    Règles facultatives - ces règles facultatives peuvent ne pas convenir à l'ensemble de l'environnement. En fonction de vos besoins, vous pouvez les utiliser.

    Si vous recherchez une protection CSRF, suivi des utilisateurs, piratage de session, etc., vous pouvez envisager d'utiliser des règles facultatives. Nous avons les règles de base, optionnelles et expérimentales après l'extraction du fichier zip crs téléchargé de la page de téléchargement OWASP.

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

    • modsecurity_crs_20_protocol_violations.conf: Cette règle protège des vulnérabilités du protocole telles que le fractionnement des réponses, la contrebande de demandes, en utilisant un protocole non autorisé (HTTP 1.0).
    • modsecurity_crs_21_protocol_anomalies.conf: il s'agit de se protéger d'une requête, qui est manquante avec Host, Accept, User-Agent dans l'en-tête.
    • modsecurity_crs_23_request_limits.conf: Cette règle dépend de l'application spécifique comme la taille de la demande, la taille du téléchargement, la longueur d'un paramètre, etc.
    • modsecurity_crs_30_http_policy.conf: Il s'agit de configurer et de protéger les méthodes autorisées ou non autorisées 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 protéger contre l'injection de commande du système d'exploitation, l'inclusion de fichier à distance, etc.
    • modsecurity_crs_41_sql_injection_attacks.conf: Cette règle pour protéger la requête d'injection SQL et SQL aveugle.
    • modsecurity_crs_41_xss_attacks.conf: protection contre la demande de script intersite.
    • modsecurity_crs_42_tight_security.conf: détection et protection de traversée de répertoire.
    • modsecurity_crs_45_trojans.conf: Cette règle pour détecter la sortie de gestion de fichiers générique, le téléchargement de la page de porte dérobée HTTP, la signature connue.
    • modsecurity_crs_47_common_exceptions.conf: Ceci est utilisé comme mécanisme d'exception pour supprimer les faux positifs courants qui peuvent être rencontrés comme une connexion factice interne Apache, un pinger SSL, etc.

    Journal

    La journalisation est l'une des premières choses à configurer afin que vous puissiez créer des journaux pour ce que fait Mod Security. Il existe deux types de journalisation disponibles; Journal de débogage et d'audit.

    Journal de débogage: il s'agit de dupliquer les messages d'erreur, d'avertissement et de notification Apache du journal d'erreurs.

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

    Par défaut, la configuration écrira les deux journaux. Cependant, vous pouvez changer en fonction de vos besoins. Le journal est contrôlé dans SecDefaultAction directif. Regardons la configuration de journalisation par défaut dans setup.conf

    SecDefaultAction “phase:1,deny,log”

    Pour consigner le débogage, le journal d'audit - utiliser «log» Pour consigner uniquement le journal d'audit - utiliser «nolog, auditlog» Pour consigner uniquement le journal de débogage - utiliser «log, noauditlog» Vous pouvez spécifier l'emplacement du journal d'audit à stocker, contrôlé par SecAuditLog directif.

    Écrivons le journal d'audit dans /opt/apache/logs/modsec_audit.log en ajoutant comme indiqué ci-dessous.

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

    Activer le moteur de règles

    Par défaut, la règle du moteur est désactivée, ce qui signifie que si vous n'activez pas le moteur de règles, vous n'utilisez pas tous les avantages de Mod Security.

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

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

    Il existe trois valeurs pour SecRuleEngine:

    • Activé - pour activer le moteur de règles
    • Désactivé - pour désactiver le moteur de règles
    • DetectionOnly - activer Rule Engine mais n'exécute jamais d'actions telles que bloquer, refuser, supprimer, autoriser, proxy ou rediriger

    Une fois le moteur de règles activé, Mod Security est prêt à se protéger avec certains des types d'attaques courants.

    Protection de type d'attaque commune

    Le serveur Web est désormais prêt à être protégé avec des types d'attaques courants tels que XSS, injection SQL, violation de protocole, etc., car nous avons installé Core Rule et activé Rule Engine. Testons-en quelques-uns.

    Attaque XSS

    •  Ouvrez Firefox et accédez à votre application et mettez tag at the end or URL
    •  Surveillez le modsec_audit.log dans le dossier apache / logs

    Vous remarquerez la demande de blocs de sécurité Mod car elle contient tag which is the root of XSS attack.

    Attaque de traversée de répertoire: - Les attaques de traversée de répertoire peuvent créer beaucoup de dégâts en tirant parti de ces vulnérabilités et accéder au fichier lié au système. Ex - / etc / passwd, .htaccess, etc.

    •  Ouvrez Firefox et accédez à votre application avec la traversée de répertoires
    •  Surveillez le modsec_audit.log dans le dossier apache / logs
    http://localhost/?../.../boot
    • Vous remarquerez la demande de blocs de sécurité Mod car elle contient une traversée de répertoire.

    Changer la bannière du serveur

    Plus tôt dans ce guide, vous avez appris à supprimer Apache et le type de système d'exploitation, aide de version de la directive ServerTokens.

    Allons un peu plus loin, que diriez-vous de conserver le nom du serveur comme vous le souhaitez? C'est possible avec SecServerSignature directive dans Mod Security. Vous voyez que c'est intéressant.

    Remarque: pour utiliser Mod Security pour manipuler la bannière du serveur à partir d'un en-tête, vous devez définir ServerTokesn sur Full dans httpd.conf du serveur Web Apache.

    • Ajoutez la directive SecServerSignature avec le nom de serveur souhaité dans setup.conf et redémarrez Apache Web Server
    SecServerSignature YourServerName

    Ex:

    [/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf
    SecServerSignature geekflare.com
    [/opt/apache/conf/crs] #

    General Configuration

    Voyons quelques-unes des configurations générales en tant que meilleures pratiques.

    Configurer l'écoute

    Lorsque vous avez plusieurs interfaces et adresses IP sur un seul serveur, il est recommandé de configurer la directive Listen avec une adresse IP et un numéro de port absolus.

    Lorsque vous laissez la configuration d'Apache sur Écouter sur toutes les adresses IP avec un certain numéro de port, cela peut créer le problème de transfert de la requête HTTP vers un autre serveur Web. C'est assez courant dans l'environnement partagé.

    • Configurez la directive Listen dans httpd.conf avec une adresse IP et un port absolus comme un exemple illustré ci-dessous
    Listen 10.10.10.1:80

    Journalisation des accès

    Il est essentiel de configurer correctement le journal d'accès sur votre serveur Web. Un des paramètres importants à capturer dans le journal serait le temps nécessaire pour traiter la demande, SESSION ID.

    Par défaut, Apache n'est pas configuré pour capturer ces données. Vous devez les configurer manuellement comme suit.

    • Pour capturer le temps nécessaire pour traiter la demande et l'ID de SESSION dans un journal d'accès
    •  Ajouter% T &% sessionID dans httpd.conf sous la directive LogFormat
    LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

    Vous pouvez vous référer http://httpd.apache.org/docs/2.2/mod/mod_log_config.html pour une liste complète des paramètres pris en charge dans la directive LogFormat dans Apache Web Server.

    Désactiver le chargement des modules indésirables

    Si vous avez compilé et installé tous les modules, il y a de fortes chances que de nombreux modules soient chargés dans Apache, ce qui peut ne pas être nécessaire.

    La meilleure pratique consiste à configurer Apache avec les modules requis dans vos applications Web. Les modules suivants ont des problèmes de sécurité, et vous pourriez être intéressé par la désactivation dans httpd.conf d'Apache Web Server.

    WebDAV (Web-based Distributed Authoring and Versioning) Ce module permet aux clients distants de manipuler des fichiers sur le serveur et de faire l'objet de diverses attaques par déni de service. Pour désactiver le suivi des commentaires dans httpd.conf

    #LoadModule dav_module modules/mod_dav.so
    #LoadModule dav_fs_module modules/mod_dav_fs.so
    #Include conf/extra/httpd-dav.conf

    Module Info Le module mod_info peut divulguer des informations sensibles en utilisant .htaccess une fois ce module chargé. Pour désactiver le suivi des commentaires dans httpd.conf

    #LoadModule info_module modules/mod_info.so

    Référence: Cela ne serait pas possible sans les conseils du lien suivant:

    Voilà donc quelques-unes des meilleures pratiques que vous pouvez utiliser pour sécuriser votre serveur Web Apache.

    Si vous êtes nouveau sur Apache HTTP, je vous recommande de prendre le cours d'administration HTTP Apache.