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 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.

rapport de vulnérabilité

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.

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
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.

apache-server-banner-masqué

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

apache-répertoire-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 l'exposer.

Accédez au répertoire $ Web_Server / conf
Ouvert 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

liste des répertoires désactivée

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

étiqueter

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 une source ouverte Pare-feu d'applications Web, 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.

Mise en marche

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.

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

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