Guide de renforcement et de sécurité du serveur Web Apache

Un guide pratique pour sécuriser et renforcer Apache HTTP Server.

Le serveur Web est un élément crucial 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.

Avoir une configuration par défaut fournit beaucoup d'informations sensibles qui peuvent aider le pirate à se préparer à une attaque des applications. La majorité des attaques d'applications Web se font par le biais d'attaques XSS, de fuite d'informations, de gestion de session et d'injection SQL, qui sont dues à un code de programmation faible et à l'incapacité de nettoyer l'infrastructure des applications Web.

Des recherches intéressantes de Positive Technologies révèlent 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 consulter le guide d'installation.
• J'appellerai le répertoire d'installation d'Apache /opt/apache en tant que $Web_Server tout au long de ce guide.
• Il est conseillé de faire une sauvegarde du fichier de configuration existant avant toute modification.

Spectateurs

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 des commandes Apache Web Server et UNIX est obligatoire.

Remarques

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 l'outil de vérification d'en-tête de réponse HTTP en ligne

Supprimer la bannière de la 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 le pirate informatique à 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.

• Allez dans le dossier $Web_Server/conf
• Modifier httpd.conf en utilisant 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, afin que le visiteur ne voie 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.

• Allez dans le répertoire $Web_Server/htdocs
• Créez un dossier et quelques fichiers à l'intérieur

 # mkdir test # touch hi # touch hello

Essayons maintenant d'accéder à Apache par 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 les exposer.

• Allez dans le répertoire $Web_Server/conf
• Ouvrez httpd.conf en utilisant vi
• Recherchez Directory et changez la directive Options en None ou –Indexes

 <Directory /opt/apache/htdocs> Options -Indexes </Directory>

(ou)

 <Directory /opt/apache/htdocs> Options None </Directory>

• Redémarrez Apache

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

Essayons maintenant d'accéder à Apache par 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.

• Allez dans le 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 distinct non privilégié 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é apache

 # groupadd apache # useradd –G apache apache

• Changer la propriété du répertoire d'installation apache en un utilisateur nouvellement créé sans privilèges

 # chown –R apache:apache /opt/apache

• Allez dans $Web_Server/conf
• Modifier httpd.conf en utilisant vi
• Recherchez la directive utilisateur et groupe et modifiez-la en tant que compte apache non privilégié

 User apache Group apache

• Enregistrez le httpd.conf
• Redémarrez Apache

grep pour exécuter le processus http et s'assurer qu'il s'exécute 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 l'autorisation du répertoire binaire et de configuration

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

• Allez dans le 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 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.

• Allez dans le 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 nécessaires et certaines d'entre elles présentent un risque potentiel.

Généralement, 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.

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 les éléments suivants

 <LimitExcept GET POST HEAD> deny from all </LimitExcept>

• Redémarrez Apache

Désactiver la requête HTTP de suivi

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 traçage intersite et potentiellement donner la possibilité à un pirate de voler des informations sur les cookies. 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 requête TRACE ci-dessus, il a répondu à ma requête. Désactivons-le et testons-le.

• Allez dans le 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 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 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, ma requête a été bloquée avec la méthode HTTP 405 non autorisée.

Maintenant, ce serveur Web n'autorise pas la demande TRACE et aide à bloquer l'attaque Cross Site Tracing.

Définir le cookie avec le drapeau HttpOnly et Secure

Vous pouvez atténuer la plupart des attaques courantes de type Cross Site Scripting à l'aide de l'indicateur HttpOnly et Secure dans un cookie. Sans avoir HttpOnly et Secure, il est possible de voler ou de manipuler des sessions d'application Web et des cookies, 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 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
• Allez dans le 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.

Inclure côté serveur

Server Side Include (SSI) risque d'augmenter la charge sur le serveur. Si vous avez partagé l'environnement et les applications Web à fort trafic, vous devriez envisager de désactiver SSI en ajoutant la directive Inclut dans les 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.

• Allez dans le répertoire $Web_Server/conf
• Ouvrez httpd.conf en utilisant vi
• Recherchez Directory et ajoutez Inclut 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 la même chose pour toutes.

Protection X-XSS

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

• Allez dans le 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 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 possible. Alors pourquoi utilisons-nous l'ancienne version HTTP du protocole, désactivons-les également ?

HTTP 1.0 présente une faiblesse de sécurité liée au piratage 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 la 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'attente

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'attente à peut-être 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

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 peaufiner ces configurations.

Clé SSL

Briser 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 désosser une clé de 512 bits.

Ainsi, plus la longueur de la 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 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 à une 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 du texte brut en codes chiffrés secrets.

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

• Allez dans le dossier $Web_Server/conf/extra
• Modifiez la directive SSLCipherSuite dans httpd-ssl.conf comme ci-dessous pour n'accepter que les 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 & v3

SSL v2 & v3 présente de nombreuses failles de sécurité, et si vous travaillez sur un test de pénétration ou une 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 accepter uniquement le dernier TLS et rejeter la demande de connexion SSL v2/v3.

• Allez dans le dossier $Web_Server/conf/extra
• Modifiez la directive SSLProtocol dans httpd-ssl.conf comme ci-dessous pour accepter uniquement TLS 1.2+

 SSLProtocol –ALL +TLSv1.2

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

Sécurité des modules

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 un pare-feu d'application Web commercial, ce serait un excellent choix.

Pour assurer la protection des applications Web génériques, les règles principales 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 de tiers
• Détection de logiciels malveillants basée sur le Web - identifie le contenu Web malveillant en le comparant à l'API Google Safe Browsing.
• Protections contre le déni de service HTTP - défense contre les inondations HTTP et les attaques HTTP DoS lentes.
• Protection contre les attaques Web courantes - détection des attaques courantes de sécurité des applications Web
• Détection d'automatisation - Détecter les bots, les robots d'exploration, les scanners et une autre activité de surface malveillante
• Intégration avec l'analyse AV 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 contre les chevaux de Troie - Détection de l'accès aux chevaux de Troie.
• Identification des défauts d'application - alertes sur les mauvaises configurations d'application.
• Détection et masquage des erreurs - Masquer les 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 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 d'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 –

• Allez dans le 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 le script make

 # 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 pré-requis pour Mod Security.

Ce module fournit une variable d'environnement avec un identifiant unique pour chaque demande, qui est suivie et utilisée par Mod Security.

• Ajouter après une ligne pour charger le module pour Mod Security dans httpd.conf et enregistrer 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 tirer pleinement parti de sa fonctionnalité.

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 zip de la règle principale téléchargé dans le dossier /opt/apache/conf
• Décompressez le fichier de règles de base
• Vous voudrez peut-être renommer le dossier en quelque chose de court et facile à retenir. Dans cet exemple, je vais renommer crs.
• Allez dans le 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 fait. 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 ferons référence à /opt/apache/conf/crs/modsecurity_crs_10_setup.conf en tant que 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. Selon vos besoins, vous pouvez les utiliser.

Si vous recherchez une protection CSRF, suivi des utilisateurs, détournement de session, etc., vous pouvez envisager d'utiliser des règles facultatives. Nous avons les règles de base, facultatives et expérimentales après avoir extrait le fichier zip crs téléchargé à partir 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, 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, qui manque 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 telles que CONNECT, TRACE, PUT, DELETE, etc.
• modsecurity_crs_35_bad_robots.conf :Détecter les robots malveillants
• modsecurity_crs_40_generic_attacks.conf : Ceci est pour protéger contre l'injection de commandes du système d'exploitation, l'inclusion de fichiers distants, etc.
• modsecurity_crs_41_sql_injection_attacks.conf : cette règle pour protéger SQL et aveugler la requête d'injection SQL.
• 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 de la traversée de répertoires.
• modsecurity_crs_45_trojans.conf : cette règle permet de détecter la sortie générique de la gestion des fichiers, 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 fictive interne Apache, un pinger SSL, etc.

Enregistrement

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 d'Apache à partir 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 possibilité de configurer la journalisation d'audit, de débogage ou les deux.

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

 SecDefaultAction “phase:1,deny,log”

Pour enregistrer le débogage, le journal d'audit - utilisez "log" Pour enregistrer uniquement le journal d'audit - utilisez "nolog, auditlog" Pour enregistrer uniquement le journal de débogage - utilisez "log, noauditlog" Vous pouvez spécifier l'emplacement du journal d'audit à stocker qui est 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 le serveur Web Apache

 SecAuditLog /opt/apache/logs/modsec_audit.log

• Après le redémarrage, vous devriez voir modsec_audit.log généré

Activer le moteur de règles

Par défaut, Engine Rule est désactivé, ce qui signifie que si vous n'activez pas Rule Engine, 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 la directive SecRuleEngine .

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

 SecRuleEngine On

Il existe trois valeurs pour SecRuleEngine :

• Activé - 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 bloquer, refuser, abandonner, autoriser, proxy ou rediriger

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

Protection de type d'attaque commune

Maintenant, le serveur Web est prêt à être protégé avec des types d'attaques courants tels que XSS, SQL Injection, Protocol Violation, etc., car nous avons installé Core Rule et activé Rule Engine. Testons-en quelques-unes.

Attaque XSS

• Ouvrez Firefox et accédez à votre application et mettez la balise <script> à la fin ou à l'URL
• Surveillez le modsec_audit.log dans le dossier apache/logs

Vous remarquerez que Mod Security bloque la requête car elle contient la balise <script> qui est la racine de l'attaque XSS.

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 en accédant au fichier lié au système. Ex - /etc/passwd, .htaccess, etc.

• Ouvrez Firefox et accédez à votre application avec la traversée de répertoire
• Surveillez le modsec_audit.log dans le dossier apache/logs

 http://localhost/?../.../boot

• Vous remarquerez que Mod Security bloque la demande car elle contient la traversée de répertoires.

Changer la bannière du serveur

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

Allons un pas en avant, que diriez-vous de garder le nom du serveur comme bon vous semble ? C'est possible avec la directive SecServerSignature dans Mod Security. Tu vois c'est intéressant.

Remarque : pour utiliser Mod Security afin de 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 votre 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] #

Paramétrage général

Examinons 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é d'avoir la directive Listen configurée 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 un problème lors du transfert de la requête HTTP vers un autre serveur Web. Ceci est assez courant dans l'environnement partagé.

• Configurez la directive Listen dans httpd.conf avec une adresse IP et un port absolus comme dans l'exemple 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. Certains des paramètres importants à capturer dans le journal seraient le temps nécessaire pour répondre à 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 répondre à 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 consulter 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 vous ayez de nombreux modules chargés dans Apache, ce qui n'est peut-être pas 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 du serveur Web Apache.

WebDAV (Web-based Distributed Authoring and Versioning) Ce module permet aux clients distants de manipuler des fichiers sur le serveur et soumis à 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 :

• http://httpd.apache.org/docs/2.4/
• http://www.modsecurity.org/documentation/
• https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

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

Vérifiez ce lien si vous souhaitez implémenter une page d'erreur personnalisée dans Apache.

Si vous débutez avec Apache HTTP, je vous recommande de suivre le cours d'administration d'Apache HTTP.