Configurations complémentaires d'Apache

Redirection automatique

Pour l'ergonomie et la sécurité, il vaut mieux exposer un minimum de chose sur votre serveur.

Si vous n'avez qu'une seule application web, autant faire en sorte de n'avoir qu'un seul point d'accés sur votre serveur Apache et qu'il soit bridé au maximum.

Pour nos applications, cela se gère à plusieurs niveaux dans la configuration Apache.

Redirection du protocole HTTP vers HTTPS

Il faut éditer le fichier de configuration principal d'Apache et ajouter ou mettre à jour la balise virtualhost comme dans cet exemple :

#[MON-IP|DNS] est à remplacer par votre nom de domaine, ip ou nom de la machine
<VirtualHost *:80>
  ServerName [MON-IP|DNS]
  Redirect / https://[MON-IP|DNS]:443/
</VirtualHost>
# OU Plus génériquement
<VirtualHost *:80>
  RewriteEngine On
  RewriteCond %{HTTPS} off 
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>

La balise [MON-IP|DNS] est à remplacer par l'adresse IP ou le nom de dommaine de votre machine (et à mettre à jour en cas de changement de nom de domaine).

Note

Le header Strict-Transport-Security forcera l'utilisation de l'HTTPS aprés la première utilisation de l'interface.

Redirection de la racine

Le plus simple reste de déplacer le DocumentRoot vers une page HTML contenant le code suivant :

<script>
 /* Remplacement de la balise à effectuer comme précédemment*/ 
 window.location = 'https://[MON-IP|DNS\]/gtf';
</script>

Le DocumentRoot est défini dans le virtualHost du port 443 (qui doit se trouver dans la configuration SSL de votre serveur Apache)

Tous les utilisateurs arrivant sur la page racine seront automatiquement redirigés vers l'alias de l'application.

Vous pouvez aussi changer le DocumentRoot pour pointer directement sur l'index.html de l'application, cependant il est probable qu'il faudra faire certaines modifications dans la configuration, ainsi que dans l'index.html lui même.

Il est aussi possible de le faire directement via la configuration Apache avec une configuration de ce type dans le virtualhost du port 443 :

RewriteEngine On
RewriteRule ^/$ /gtf [R=301,L]

Elimination des informations sensibles des headers de réponse

Par défaut Apache retourne beaucoup d'informations qui peuvent être utilisées par des hackers pour attaquer votre application.

Un bonne pratique en production est de limiter ces retours.

Voici un exemple de retour de requête HTTP donnant trop d'informations : Request Full

Vous pouvez remédier à ça en ajoutant de la configuration à la fin de votre fichier de configuration apache ou directement dans virtualhost du port 443 :

# Réduction des headers de réponse apache
ServerSignature Off
ServerTokens Prod

Pour finaliser la configuration il faut redémarrer le service Apache.

Request Clear

Note

Le header X-Powered-By est aussi une source d'information importante pour un hacker il sera supprimé dans une future version du produit. En attendant si vous voulait le retirer de vos applications il faut éditer le fichier php.ini (sous Windows à l'emplacement vas/bin/php/php.ini, sous linux à l'emplacement vas/bin/php/bin/php.ini), et passer la valeur de expose_php à Off

Accés aux logs d'apache depuis l'application

Ce n'est pas forcément conseillé, cependant il est souvent plus pratique pour vous d'accéder aux logs du serveur Apache à travers l'application.

Ces chemins sont définis dans le virtualHost du port 443 (qui doit se trouver dans la configuration SSL de votre serveur Apache)

# Réduction des headers de réponse apache
ErrorLog "/chemin/root/app/vas/var/log/apache2_error.log"
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog "/chemin/root/app/vas/var/log/apache2_access.log"

Avertissement

Le dossier dans lequel Apache doit écrire ses logs doit exister. Si vous ajoutez un sous dossier, pensez à le créer sur le disque et attention de ne pas l'effacer par inadvertance.

Request Full

En-Tête supplémentaires

  • X-Frame-Options : Cette configuration permet au site d'être intégré dans une balise <frame> ou <iframe> uniquement s'il provient du même domaine (SAMEORIGIN). Cela protège contre le clickjacking en empêchant l'inclusion du site dans des cadres provenant d'autres domaines. Cependant si vous souhaitez utiliser un widget pour intégrer une formulaire de demande à un de vos site ce header bloquera l'utilisation via votre site.

  • Content-Security-Policy : Cette configuration définit une politique de sécurité du contenu de base qui permet uniquement de charger des ressources à partir du même domaine ('self').

  • Referrer-Policy : Avec cette configuration, le navigateur envoie le referrer uniquement pour les requêtes provenant du même domaine (same-origin).

  • Permissions-Policy : Cette configuration désactive l'accès à la géolocalisation, au microphone et à la caméra par défaut. Vous pouvez personnaliser cette directive en fonction des fonctionnalités spécifiques de votre site.

  • Cross-Origin-Embedder-Policy : Cette configuration exige que les ressources chargées par le navigateur aient également défini la directive Cross-Origin-Opener-Policy pour bénéficier d'une isolation appropriée. Cela renforce la sécurité en limitant les interactions entre les ressources provenant de différents origines (cross-origin).

  • Cross-Origin-Resource-Policy : Cette configuration spécifie que les ressources chargées par le navigateur doivent provenir du même domaine (same-origin). Cela restreint les requêtes cross-origin pour les ressources telles que les fichiers JavaScript, les images, les polices, etc.

  • Cross-Origin-Opener-Policy : Avec cette configuration, le navigateur restreint l'ouverture de nouvelles fenêtres ou onglets à partir de votre site web afin qu'ils soient limités au même domaine (same-origin). Cela aide à prévenir les attaques de type "tabnabbing" où une nouvelle fenêtre ou un nouvel onglet peut être utilisé pour tromper l'utilisateur.

Il est important de noter que ces headers peuvent avoir des valeurs plus complexes selon vos besoins spécifiques. Vous pouvez consulter la documentation officielle pour en savoir plus sur les options et directives disponibles pour ces headers et les personnaliser en fonction des ressources et des politiques de votre site web.

Veuillez noter que la configuration de ces headers peut varier en fonction de votre serveur web et de la version spécifique que vous utilisez. Assurez-vous de consulter la documentation de votre serveur web pour des instructions précises sur la configuration de ces headers.

exemple d'utilisation :

Header always set X-Frame-Options SAMEORIGIN
Header always set Content-Security-Policy "default-src 'self';"
Header always set Referrer-Policy same-origin
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header always set Cross-Origin-Embedder-Policy require-corp
Header always set Cross-Origin-Resource-Policy same-origin
Header always set Cross-Origin-Opener-Policy same-origin

Utilisation de ModSecurity2

Pour renforcer la sécurité de vos applications, il est préférable d'ajouter un WAF (Web Application Firewall). Vous pouvez installer celui que vous souhaitez en amond de l'application.

Nous allons voir ici comment rajouter OWASP ModSecurity v2 directement sur votres instance Apache2 sur un serveur Linux uniquement.

Premièrement on va simplement vérifier la présence d'un WAF existant avec un outil adapté comme par exemple la commande wafw00f :

wafw00f https://gtf-test.veremes.net/gtf
                ______
               /      \
              (  W00f! )
               \  ____/
               ,,    __            404 Hack Not Found
           |`-.__   / /                      __     __
           /"  _/  /_/                       \ \   / /
          *===*    /                          \ \_/ /  405 Not Allowed
         /     )__//                           \   /
    /|  /     /---`                        403 Forbidden
    \\/`   \ |                                 / _ \
    `\    /_\\_              502 Bad Gateway  / / \ \  500 Internal Error
      `_____``-`                             /_/   \_\

                        ~ WAFW00F : v2.2.0 ~
        The Web Application Firewall Fingerprinting Toolkit
    
[*] Checking https://gtf-test.veremes.net/gtf
[+] Generic Detection results:
[-] No WAF detected by the generic detection
[~] Number of requests: 7

Si aucun WAF n'est configuré entre votre poste et le serveur, il est possible d'en ajouter un directement sur le serveur Apache2.

Pour commencer il faut mettre à jour le serveur de préférence pour avoir les dernières versions d'apache et openssl.

sudo apt update
sudo apt upgrade

Pour installer et activer le module

sudo apt install libapache2-mod-security2
sudo a2enmod security2
sudo systemctl restart apache2

cd /etc/modsecurity/
sudo mv modsecurity.conf-recommended modsecurity.conf

Il faut ensuite éditer /etc/modsecurity/modsecurity.conf pour changer quelques paramètres.

SecRuleEngine DetectionOnly
# A remplacer par 
SecRuleEngine On

SecAuditLogParts ABDEFHIJZ
# A remplacer par la valeur ci-dessous ou une autre valeur en fonction de vos besoins
SecAuditLogParts ABCEFHJKZ

  • A : Ajoute le nom du client (par exemple, l'adresse IP ou le nom d'hôte) dans le journal d'audit.

  • B : Ajoute le corps de la requête HTTP dans le journal d'audit.

  • C : Ajoute les cookies de la requête HTTP dans le journal d'audit.

  • D : Ajoute les en-têtes de détection de bots dans le journal d'audit.

  • E : Ajoute les en-têtes de la réponse HTTP dans le journal d'audit.

  • F : Ajoute les en-têtes de la requête HTTP dans le journal d'audit.

  • G : Ajoute des informations sur la géolocalisation du client dans le journal d'audit (nécessite un module tiers).

  • H : Ajoute les en-têtes HTTP personnalisés dans le journal d'audit.

  • I : Ajoute des informations sur les identités d'utilisateur dans le journal d'audit.

  • J : Ajoute les en-têtes de sécurité HTTP dans le journal d'audit.

  • K : Ajoute les informations sur les clés publiques des certificats SSL dans le journal d'audit.

  • L : Ajoute des informations sur les limites de vitesse (rate limits) dans le journal d'audit.

  • M : Ajoute les métadonnées ModSecurity spécifiques dans le journal d'audit.

  • N : Ajoute le nom du serveur dans le journal d'audit.

  • O : Ajoute les options de configuration ModSecurity dans le journal d'audit.

  • P : Ajoute les paramètres de la requête HTTP dans le journal d'audit.

  • Q : Ajoute les informations sur les processus ModSecurity dans le journal d'audit.

  • R : Ajoute les informations sur la règle ModSecurity déclenchée dans le journal d'audit.

  • S : Ajoute le statut de la réponse HTTP dans le journal d'audit.

  • T : Ajoute le temps de traitement de la requête HTTP dans le journal d'audit.

  • U : Ajoute les informations sur les utilisateurs dans le journal d'audit.

  • V : Ajoute des informations sur les vulnérabilités dans le journal d'audit.

  • W : Ajoute les informations sur les fichiers journalisés dans le journal d'audit.

  • X : Ajoute les informations sur les transactions HTTP dans le journal d'audit.

  • Y : Ajoute les informations sur les fichiers journalisés de manière persistante dans le journal d'audit.

  • Z : Ajoute les informations sur la compression HTTP dans le journal d'audit.

Avertissement

Attention la récupération de certains éléments nécessitera potentiellement d'autres paramétrages ou l'activation d'autres modules.

Il faut ensuite redémarrer le service apache avec la commande sudo systemctl restart apache2

OWASP ModSecurity v2 est maintenant opérationnel, mais il faut le configurer avec des règles de fonctionnement. Par défaut le plus simple est d'utiliser les préconisations de l'OWASP en intégrant ModSecurity CRS (Core Rule Set). Les archives contenant les règles se trouvent sur le dépot Github d'OWASP ModSecurity CRS.

Vous pouvez récupérer la version installée de votre ModSecurity avec la commande apt-cache show libapache2-mod-security2.

Les dernières versions du CRS requiert une version 2.9.6 de ModSecurity. Si votre version est inférieur, je vous conseille d'utiliser la version 3.0.0 de la CRS dans un premier temps.

wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz
tar xvf v3.3.0.tar.gz
sudo mkdir /etc/apache2/modsecurity-crs/
sudo mv coreruleset-3.3.0/ /etc/apache2/modsecurity-crs/
cd /etc/apache2/modsecurity-crs/coreruleset-3.3.0/
sudo mv crs-setup.conf.example crs-setup.conf

Il faut ensuite éditer le fichier /etc/apache2/mods-enabled/security2.conf pour ajouter la CRS.

IncludeOptional /usr/share/modsecurity-crs/*.load
# A remplacer par 
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/*.conf

Testez ensuite la configuration avec la commande sudo apache2ctl -t et si la configuration est conforme lancez sudo systemctl restart apache2.

Il faut ensuite ajouter quelques options pour que l'application soit pleinement fonctionnel dans /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf :

# Décommenter et modifier la liste de méthodes autorisées 
SecAction \
 "id:900200,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT DELETE'"

Testez ensuite la configuration avec la commande sudo apache2ctl -t et si la configuration est conforme lancez sudo systemctl restart apache2.

En relançant la commande wafw00f sur le serveur le retour devrait maintenant être de ce type :

wafw00f https://gtf-test.veremes.net/gtf

                   ______
                  /      \
                 (  Woof! )
                  \  ____/                      )
                  ,,                           ) (_
             .-. -    _______                 ( |__|
            ()``; |==|_______)                .)|__|
            / ('        /|\                  (  |__|
        (  /  )        / | \                  . |__|
         \(_)_))      /  |  \                   |__|

                    ~ WAFW00F : v2.2.0 ~
    The Web Application Firewall Fingerprinting Toolkit
    
[*] Checking https://gtf-test.veremes.net/gtf
[+] Generic Detection results:
[*] The site https://gtf-test.veremes.net/gtf seems to be behind a WAF or some sort of security solution
[~] Reason: The server returns a different response code when an attack string is used.
Normal response code is "200", while the response code to cross-site scripting attack is "403"
[~] Number of requests: 5

Vous pouvez personnaliser les règles, en ajouter ou en supprimer si vous le souhaitez. La documentation officielle de OWASP ModSecurity CRS est disponible via ce lien