Configurer un serveur Web pour securiser des sites web sous jahia DX

Dans le monde d'aujourd'hui, où les criminels essaient de détourner des sites Web et des sessions, de créer des dommages à l'aide de scripts nuisibles ou même avoir accès à des données sensibles, il est très important de réduire les risques en mettant en œuvre les contre-mesures disponibles.

Le projet Open Web Application Security (OWASP) fournit de la documentation et des outils pour aider à sécuriser les sites Web ou à détecter les vulnérabilités. Chez Jahia, nous intégrons le Proxy OWASP Zed Attack dans notre process assurance qualité (QA) pour des tests de pénétration afin de détecter les vulnérabilités dans notre code ou des bibliothèques logicielles tierces et ainsi aider l'équipe de développement à trouver des brêches de sécurité. Certains clients emploient également des agences et des consultants afin d'évaluer la sécurité de leurs sites bâtis avec Jahia DX, ce qui entraîne parfois des remontées de bugs vers nous. Ces tickets Jira nous sont utiles, ils contribuent à rendre nos produits plus sûrs.

Pour certaines des vulnérabilités rapportées par des consultants ou des outils automatisés, nous ne fournissons cependant pas une solution prête à l'emploi dans Jahia DX, car un serveur Web en frontal devant Jahia DX peut déjà les prendre en charge. Dans ce document, nous décrivons les configurations relatives à la sécurité pour le serveur web Apache. D'autres serveurs Web tels que nginx ou IIS acceptent des paramètres similaires.

regles de base ModSecurity (CRS)

OWASP fournit un ensemble de règles de base très puissant et facilement pluggable pour le pare-feu ModSecurity, que nous recommandons d'utiliser sur vos serveurs Web Apache / IIS / nginx. Il fournit une protection contre les Cross Site Scripting (XSS), les fixation session, les violations des protocoles HTTP, les remote execution code, Path Traversal et de nombreuses autres attaques. Il détecte les formes connues d'attaques et les bloque.

Vous trouverez plus d'informations sur la protection et les rules ainsi que la façon de les installer sur https://modsecurity.org/crs/. Soyez conscient qu'un pare-feu d'application Web (WAF) peut affecter les performances de votre application Web. Vous devriez donc effectuer des tests de performances avant de passer en production.

De plus, comme ModSecurity CRS peut détecter de faux positifs, nous recommandons fortement de procéder à des vérifications avec des tests approfondis afin de vous assurer qu'aucune erreur n'est créée avant de passer en production. Le paramètre SecRuleEngine dans le fichier /etc/modsecurity/modsecurity.conf peut être configuré sur DetectionOnly pour simplement enregistrer les erreurs sans bloquer les requêtes. Pour éviter les faux positifs, vous devez soit exclure soit adapter la configuration des règles connexes. Vous pouvez également ajouter vos règles personnalisées si cela s'avère nécessaire.

Par exemple, si votre site Web peut être consulté par des appareils mobiles utilisant une connexion 3G, ils peuvent changer soudainement leur adresse IP en cours de déplacement. Pour éviter que cela soit considéré comme une attaque, vous devez désactiver la règle 981059 qui détecte les changements dans les adresses IP au cours d'une session.

SecRuleRemoveById 981059

Voir aussi: Handling False Positives with the OWASP ModSecurity Core Rule Set

Définir la sécurité liée aux en-têtes HTTP

Pour définir des en-têtes HTTP sécurisés, il existe également un projet OWASP avec des recommandations accessible via ce lien: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers

Voici quelques-uns des en-têtes les plus couramment utilisés et recommandés:

X-Content-Type-Options

Certains navigateurs / clients peuvent faire un MIME-sniffing dans les cas où un type MIME est manquant ou le client croit que le type MIME n'est pas défini correctement. Comme certains types MIME représentent un contenu exécutable, il existe un problème de sécurité autour de cette pratique. C'est pourquoi il est généralement recommandé de se défendre contre le MIME-sniffing en utilisant le X-Content-Type-Options HTTP response header. Avec Apache2 on peut configurer ceci en ajoutant les en-têtes des modules et la configuration suivante:

Header set X-Content-Type-Options nosniff

X-XSS-Protection / Content-Security-Policy

Il s'agit d'un en-tête de réponse HTTP qui n'est pas pris en charge par Firefox, mais d'autres navigateurs semblent le supporter. L'en-tête peut empêcher le rendu de la page si une attaque XSS est détectée. Avec Apache2, l'en-tête peut être défini en utilisant les en-têtes et les réglages du module avec la configuration suivante:

Header set X-XSS-Protection "1; mode=block"

Aujourd'hui, la meilleure option est d'utiliser l'en-tête Content-Security-Policy, qui est pris en charge par tous les navigateurs du moment. Cependant, comme Jahia DX utilise GWT, nous ne pouvons actuellement pas nous débarrasser du javascript en ligne, de sorte que Content-Security-Policy pour l'instant ne peut être totalement employé que dans une navigation live, lorsque les modèles n'utilisent aucun Javascript en ligne. Alternativement, il faut définir l'option 'unsafe-inline, qui permet l'exécution de scripts en ligne.
Pour le moment, nous continuons à travailler afin que Jahia DX supporte Content-Security-Policy.

X-Frame-Options

Avec l'en-tête de réponse HTTP X-Frame-Options, on peut empêcher que quelqu'un affiche vos pages dans une <frame>, un <iframe> ou un <object>, qui ouvrirait le site pour les attaques de type clickjacking. Comme défense, vous devez configurer la configuration suivante dans un serveur Web Apache2 avec un module d'en-têtes activé :

Header set X-Frame-Options: "sameorigin"

Strict-Transport-Security

L'en-tête HSTS (HTTP Strict Transport Security), qui est pris en charge par les principaux navigateurs, garantira que toutes les communications d'un navigateur sont transmises via le protocole HTTPS (HTTP Secure). Cela redirige les requêtes HTTP vers HTTPS et empêche les clicks HTTPS via des prompts dansdes attaques de type "man-in-the-middle".

En utilisant le module d'en-têtes dans Apache2 et en configurant la configuration suivante, vous indiquez aux navigateurs que les requêtes pour votre domaine et ses sous-domaines ne sont disponibles via HTTPS que pendant un an.

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains;"

Blocage des tentatives de connexion par force brute ou les attaques par déni de service (DDoS / DoS)

Les attaquants peuvent essayer de vous connecter à un compte en essayant différents mots de passe dans un court délai, ce qui s'appelle "tentative de connexion par force brute", ou ils peuvent essayer de faire tomber un site en envoyant un nombre énorme de demandes que les serveurs ne peuvent traiter, appelées attaques de déni de service DoS ou attaques de déni de service distribuées (DDoS) si les demandes proviennent d'IP différentes.

OWASP (voir Denial of Service Cheat Sheet) et la documentation du serveur web Apache ont des recommandations sur la façon de protéger contre les attaques DoS. Il existe également des modules tiers tels que mod_evasive ou fail2ban. Ils ne fonctionneront que si le serveur HTTP n'est pas derrière un répartisseur de charge ou un proxy, à moins que ces derniers ne disposent d'un moyen de savoir quelle IP doit être bloquée.

Les attaques DDoS sont difficiles à résoudre avec des solutions d'hébergement sur site. Vous devrez probablement trouver un fournisseur tiers pour vous protéger, par exemple en souscrivant aux services d'un CDN (Content Delivery Network), qui offre une protection avancée contre les DDoS.

Le problème avec le verrouillage des adresses IP vient du fait que cela peut bloquer par inadvertance une quantité importante d'utilisateurs en bloquant un serveur proxy utilisé par un FAI ou une grande entreprise. Par conséquent, une meilleure solution pour bloquer les attaques de connexion de la force brute serait par exemple, de définir un champ CAPTCHA après la deuxième tentative de connexion incorrecte d'un client.

Empêcher les fuites d'informations d'un serveur

Si un attaquant peut identifier le fournisseur et la version du serveur Web, il peut exploiter les vulnérabilités connues pour ce serveur. Par conséquent, pour le serveur web Apache, vous devez définir les paramètres suivants pour désactiver l'envoi d'informations trop importantes sur le logiciel utilisé:

ServerSignature Off
ServerTokens Prod

Vous devez également désactiver tous les modules inutiles et vérifier que vous utilisez les ports hôtes virtuels par défaut (80 et 443).

Configuration SSL

Une configuration SSL sécurisée de votre serveur Web vous protégera des failles connues et exploitées. Les deux URL suivantes sont très utiles pour configurer et vérifier votre configuration SSL: https://cipherli.st/ et https://www.ssllabs.com/ssltest/