Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:apache [2025/02/09 17:01] – [Cacher la version d'apache] zatalyz
+++ fr:apache [2025/06/26 20:41] (Version actuelle) – [Faire des pages d'erreurs personnalisées] zatalyz
@@ Ligne 158: / Ligne 158: @@
 En principe nos serveurs sont à jours, hein. Mais en cas d'oubli, ne facilitons pas la tâche des observateurs :
-  nano /etc/apache2/conf-available/security.conf
+<code bash /etc/apache2/conf-available/security.conf>
+# Cacher la version d'Apache2
-<code># Cacher la version d'Apache2
 ServerTokens Prod
+# Cache la signature de "Apache" dans les pages d'erreurs et répertoires
 ServerSignature Off
+# Désactive la méthode HTTP TRACE utilisée dans des attaques XST
 TraceEnable Off
 </code>
@@ Ligne 168: / Ligne 169: @@
   sudo apachectl a2enconf security
-À refaire sur chacun de ses serveurs !
-<WRAP center round tip 60%>
-On peut aussi paramétrer (et modifier) ces options dans ''/etc/apache2/apache2.conf'' mais c'est moins élégant.
-</WRAP>
-<WRAP center round help 60%>
-Il faut activer le fichier, non ? Cette partie du tuto demande à être vérifiée.
-</WRAP>
 ==== Vhost avec variables ====
@@ Ligne 221: / Ligne 216: @@
 <VirtualHost *:80>
 	# Déclare la macro, son appel et la variable pour le nom de domaine
-	Use macro_common_config_80 exemple.org
+	Use common_config_80 exemple.org
 	# Déclare les sous-domaines qui sont en réalité le même site
 	ServerAlias www.exemple.org
@@ Ligne 227: / Ligne 222: @@
 <VirtualHost *:443>
-	Use macro_common_config_443 exemple.org
+	Use common_config_443 exemple.org
 	ServerAlias www.exemple.org
 	# Si besoin d'alias
@@ Ligne 276: / Ligne 271: @@
   * Le dernier morceau concerne OCSP qui accélère un peu les échanges en https, voir aussi [[https://www.octopuce.fr/accelerer-votre-ssl-tls-avec-ocsp-stapling/|Accélérer votre réponse SSL/TLS avec l’OCSP Stapling]]
-<code>
+<code bash /etc/apache2/mods-available/ssl.conf>
 SSLProtocol +TLSv1.2
 SSLCompression off
@@ Ligne 287: / Ligne 282: @@
 SSLStaplingReturnResponderErrors off
 SSLStaplingCache        shmcb:/var/run/ocsp(128000)
+#À partir de la version 2.4.11 d'apache
+SSLSessionTickets Off
 </code>
 Pour la liste ''SSLCipherSuite'', consulter les préconisations de [[https://mozilla.github.io/server-side-tls/ssl-config-generator/|Mozilla SSL Configuration Generator]] et lire tranquillement l'explication si dessous avant de modifier la proposition <wrap hi>mise à jour le 29 novembre 2017.</wrap>
-À partir de la version 2.4.11 d'apache, vous pouvez ajouter dans le fichier ''/etc/apache2/mods-available/ssl.conf'' :
-<code>
-SSLSessionTickets Off
-</code>
@@ Ligne 365: / Ligne 356: @@
 Puis modifiez le fichier ''/etc/apache2/mods-available/headers.conf'' :
-<code>
+<code bash /etc/apache2/mods-available/headers.conf>
 # Ce qui suit vient de
 # https://blog.adminrezo.fr/2016/12/securiser-serveur-apache-https-headers/
 # Contrôler l’accès des bots de facon plus fine qu'avec robots.txt :
-Header set X-Robots-Tag "index,follow,noarchive"
+Header set X-Robots-Tag "index,follow,noarchive,notranslate"
 # Évite que le contenu soit interprété différemment que définit dans le mime Type
 Header set X-Content-Type-Options nosniff
@@ Ligne 378: / Ligne 369: @@
 # Faille spécifique IE8, on espère que plus personne ne l'utilise, mais...
 Header set X-Download-Options noopen;
-# Interdire l'embarquement de tout ou partie de votre site dans un site ou logiciel tiers
+# Interdire l'embarquement de tout ou partie du site dans un site ou logiciel tiers
 Header set X-Permitted-Cross-Domain-Policies none
+# Protège la vie privée en évitant de transmettre trop d'infos lorsqu'on naviguer vers une autre page.
+Header set Referrer-Policy "strict-origin-when-cross-origin"
 # X-Clacks, ça sert à rien, c'est donc vital.
 header set X-Clacks-Overhead "GNU Terry Pratchett"
-# Enfin, les CSP permettent de vérifier l'origine des éléments du site
-# CSP, pour éviter de charger des scripts d'ailleurs. /!\ partie complexe à gérer suivant vos CMS
-Header set Content-Security-Policy "default-src 'self' *.monsite.org 'unsafe-eval' 'unsafe-inline' "
 </code>
@@ Ligne 390: / Ligne 380: @@
   * Header set X-Robots-Tag : http://robots-txt.com/x-robots-tag/
   * CSP : https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html
 === Content Security Policy (CSP) ===
@@ Ligne 396: / Ligne 387: @@
 Mais il est difficile de faire marcher les CMS tout en ayant une politique sécurisée sur les CSP.
+Je conseille de faire des règles CSP différentes suivant les CMS...
 Le site de référence est [[https://content-security-policy.com/]]. En anglais, mais il contient toute la documentation officielle sur le sujet.
@@ Ligne 417: / Ligne 410: @@
   add_header Content-Security-Policy "default-src 'self' *.monsite.org 'unsafe-eval' 'unsafe-inline'; ";
-Et voici une autre façon d'écrire les Content-Security-Policy, un peu plus "lisible" (et commentée((En vrai je pense qu'il faut enlever les commentaires entre les guillemets.)) !). Cela couvre des besoins normaux de façon relativement sécurisée, mais comme on l'a vu, il faudra adapter aux pads, à OnlyOffice...
+Et voici une autre façon d'écrire les Content-Security-Policy, un peu plus "lisible". Cela couvre des besoins normaux de façon relativement sécurisée, mais comme on l'a vu, il faudra adapter aux pads, à OnlyOffice...
 <code>
 Header set Content-Security-Policy "
-  # Tout provient du même domaine sauf mention contraire.
   default-src 'self';
-  ## Les scripts
+  script-src 'self';
-    # Permet les scripts inline et eval(), nécessaires pour certaines applications.
+  style-src 'self';
-    # script-src 'self' 'unsafe-inline' 'unsafe-eval';
-    # Cette version est sécurisée mais... ben potentiellement certaines applis ne fonctionneront pas
-    # Celles avec des potentielles failles :P
-    script-src 'self';
-    # L'usage de Hashes et Nonces serait idéale mais avec les cms, c'est compliqué.
-  # Permet les styles inline.
-    # Pour faire marcher les sites mal branlés (style dans le html)
-    #style-src 'self' 'unsafe-inline';
-    # Sinon :
-    style-src 'self';
-  # Autorise les images venant du même domaine et de certaines sources externes via https.
   img-src 'self' https: ;
-  # Autorise les polices venant du même domaine.
   font-src 'self';
-  # Permet les connexions vers des ressources externes suivantes
   connect-src 'self' https://bosh.jabberfr.org/ *.numenaute.org;
-  # Autorise l'encadrement (frames) par certains domaines
   frame-src https://chat.jabberfr.org/ *.numenaute.org/;
-  # Limite l'utilisation des éléments <object>, <embed>, et <applet> dans les pages à notre domaine.
   object-src 'self';
-  # Interdit les soumissions de formulaire et le changement de base URL depuis un autre domaine.
   base-uri 'self';
   form-action 'self';
-  # Empêche le site d'être chargé dans un iframe
   frame-ancestors 'none';
 "
 </code>
+Ces règles sont un compromis entre "fonctionnel" et "sécurisé" (avec quelques suggestions de "quoi mettre d'autre") :
+  * ''default-src 'self';''Tout provient du même domaine sauf mention contraire.
+  * Les scripts, au choix...
+    * ''script-src 'self' 'unsafe-inline' 'unsafe-eval';'' Permet les scripts inline et eval(), nécessaires pour certaines applications.
+    * ''script-src 'self';'' Cette version est sécurisée mais... ben potentiellement certaines applis ne fonctionneront pas. Celles avec des potentielles failles :P
+    * L'usage de Hashes et Nonces serait idéale mais avec les cms, c'est compliqué.
+  * ''style-src 'self';'' Permet les styles inline.
+    * ''style-src 'self' 'unsafe-inline';'' Pour faire marcher les sites mal branlés (style dans le html)
+  * ''img-src 'self' https: ;'' Autorise les images venant du même domaine et de certaines sources externes via https.
+  * ''font-src 'self';'' Autorise les polices venant du même domaine.
+  * ''connect-src 'self' https://bosh.jabberfr.org/ *.numenaute.org;'' Permet les connexions vers des ressources externes indiquées
+  * ''frame-src https://chat.jabberfr.org/ *.numenaute.org/;'' Autorise l'encadrement (frames) par certains domaines
+  * ''object-src 'self';'' Limite l'utilisation des éléments <object>, <embed>, et <applet> dans les pages à notre domaine.
+  * ''base-uri 'self';'' et ''form-action 'self';'' Interdit les soumissions de formulaire et le changement de base URL depuis un autre domaine.
+  * ''frame-ancestors 'none';'' Empêche le site d'être chargé dans un iframe
 ==== Activer la réécriture des URLs ====
@@ Ligne 654: / Ligne 644: @@
 On peut se faire un fichier de configuration appelant diverses modifs sur tous les sites, par exemple dans ''/etc/apache2/conf-available/bidouilles.conf''.
-Ensuite on peut l'appeler dans chaque config de site en ajoutant la ligne suivante (dans ''/etc/apache2/sites-enabled/monsite-ssl.conf'', entre les balises ''VirtualHost'') :
+Ensuite on peut l'appeler partout de cette façon :
+  sudo a2enconf bidouilles
+  sudo systemctl reload apache2
+Cela évite de réécrire les mêmes règles partout.
+On peut aussi l'inclure dans chaque vhost en ajoutant la ligne suivante (dans ''/etc/apache2/sites-enabled/monsite-ssl.conf'', entre les balises ''VirtualHost'') :
   Include /etc/apache2/conf-available/bidouilles.conf
+Mais attention, suivant ce qu'on met dedans, cela peut mettre un peu de bazar (genre, la partie sur les logs plus bas, je ne sais pas trop comment les logs seront écrits avec l'include, si un vhost va écraser les logs du copain d'à côté ou si ça se combinera).
-Cela évite de réécrire les mêmes règles partout.
 ==== Virer le tracker de Facebook ====
@@ Ligne 742: / Ligne 737: @@
 Doc : https://httpd.apache.org/docs/2.4/fr/custom-error.html
+=== Partager les pages entre serveurs ===
+Là, je ne sais pas si c'est la bonne idée. Mais le plus efficace serait de monter le dossier des pages d'erreurs via un partage réseau (genre NFS), ainsi apache peut pointer localement vers un truc qui est en réalité ailleurs. Cependant, avant de mettre ça en place, on va vérifier avec les pros de la sécurité : on brise un peu l'isolement entre les serveurs en faisant ça. Vu qu'on a juste des pages html pur, les exploits me semblent complexes, mais j'ai un doute.
+Une autre solution est de faire un rsync, un truc Ansible... C'est sans doute aussi bien.
+==== Personnaliser les logs d'erreur et d'accès ====
+Par défaut sur Debian (et sans doute d'autres), Apache stockera les logs dans /var/log/apache2 avec deux fichiers : error.log et access.log.
+Cela peut se personnaliser au niveau du vhost en mettant par exemple ces deux lignes :
+<code>ErrorLog ${APACHE_LOG_DIR}/site_error.log
+CustomLog ${APACHE_LOG_DIR}/site_access.log combined</code>
+En effet, un fichier de log par "site", ça semble sympa... a priori. Mais la [[https://httpd.apache.org/docs/2.4/logs.html#virtualhost|doc officielle]] en pointe bien les limites : on se retrouve vite avec énormément de fichiers, encore plus avec les logs tournants, il faut avoir un peu de cohérence dans le nommage, et ces fichiers sont difficiles à analyser (par exemple comme base pour bannir des bots).
+Finalement, tout laisser dans un seul fichier générique est aussi bien. On va donc laisser le fonctionnement par défaut. D'autant qu'il existe la possibilité de préciser dans les lignes de log quel vhost est impacté ; ensuite, ''grep'' (ou autre outil) pourra permettre de surveiller plus finement les problèmes lié à un site particulier.
+=== Un peu de théorie ===
+<WRAP center round todo 60%>
+En cours de rédaction, mais je fais une pause.
+</WRAP>
+Avant tout : à quoi correspond les deux formats de fichiers ?
+  * error.log (lié à la directive [[https://httpd.apache.org/docs/2.4/mod/core.html#errorlog|ErrorLog]]) liste les erreurs ; c'est un fichier surtout utile quand on développe ou qu'on veut plus d'infos sur des soucis sur le site. Non, malgré son nom, il ne liste pas les codes d'erreur http, ça c'est plutôt réservé au second...
+    * Si j'ai bien compris, ce qui s'affiche dans ce fichier est lié au paramètre ''LogLevel''. On n'a pas un contrôle énorme dessus, ce sera juste plus ou moins verbeux suivant ce qu'on déclare.
+  * access.log (lié à la directive [[https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog|CustomLog]]) liste les "accès". En fait, il va surtout permettre de pister vos visiteuses et ce qu'elles font. Ce qui est utile pour repérer les comportements abusifs. Quand aux abus de sysadmin, ils sont possibles mais on ne documentera pas ça ici : de base on sait surtout quelle ip visite quelle page, et avec quel navigateur. C'est beaucoup, mais on n'est pas obligé de tout loguer ou d'exploiter ces données... C'est aussi là qu'on voit les codes http (404 etc).
+    * Ici on peut utiliser ''LogFormat'' qui va permettre de personnaliser assez finement les informations qu'on récupère de nos visiteuses. Et ça va être très intéressant de le faire.
+Dans ''apache2.conf'', il y a des formats par défaut qui sont déjà déclarés :
+<code>
+LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
+LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
+LogFormat "%h %l %u %t \"%r\" %>s %O" common
+LogFormat "%{Referer}i -> %U" referer
+LogFormat "%{User-agent}i" agent
+</code>
+Le format est :
+  LogFormat "Arguments" Nom_du_Format
+Pour les arguments, ce n'est pas évident à déchiffrer ; la syntaxe détaillée est expliquée sur [[https://httpd.apache.org/docs/2.4/mod/mod_log_config.html]]. Le nom du format (''vhost_combined'', ''combined'', ''common'') sera utilisé par la directive CustomLog pour savoir quel format suivre.
+Ainsi par exemple, pour ''vhost_combined'', les arguments seront :
+  * ''%v'' : Le nom déclaré par ServerName (donc le domaine visité)
+  * ''%p'' : Le port
+  * ''%h'' : L'ip de la visiteuse
+  * ''%l'' : "Identité de l'utilisateur selon identd" (un vieux protocole réseau que plus personne n'utilise). Presque toujours ''-'' donc assez inutile.
+  * ''%u'' : Nom d'utilisateur si connecté via HTTP (sinon ''-''), généralement inutile puisqu'on identifie côté applicatif.
+  * ''%t'' : l'heure et la date
+  * ''%r'' : la requête (GET/POST etc)
+  * ''%>s'' : Code de statut HTTP final, après d'éventuelles redirections
+  * ''%O'' : Taille de la réponse envoyée (en octets)
+  * ''%{Referer}i'' : En-tête Referer envoyé par le client (URL de la page d’origine, parfois vide)
+  * ''%{User-Agent}i'' : En-tête User-Agent du client (navigateur, bot, rien...)
+La proposition pratique sera épurée par rapport à ce modèle.
+=== Et un exemple pratique ===
+Alors, on met quoi, dans nos logs ?
+Oublions les logs déclarés dans les vhosts, on va faire ça de façon générale, dans notre ''bidouilles.conf''.
+<code>
+# Logs au format comme on veut
+LogFormat "%h ☆ %v ☆ %t ☆ %>s ☆ %O ☆ \"%r\" ☆ \"%{User-Agent}i\" ☆ \"%{Referer}i\" " vhost_maison
+CustomLog ${APACHE_LOG_DIR}/access.log vhost_maison
+</code>
+  * l'ip en premier, c'est ainsi super facile d'écrire les regex et de la cibler en variant les motifs derrière. Puis Servername, la date, le code http, le poids de la requête.
+  * ☆ pour séparer les arguments (ou tout autre caractère unicode). Aucun risque que ce soit utilisé dans les logs, sauf à la limite le Referer ou l'User-Agent (si le bot est vraiment chelou). Et c'est ainsi une base assez simple à détecter dans les regex. Attention ça n'empêche pas de devoir déclarer finement le reste, justement pour le cas où on tomberait sur un bot chelou. Mais techniquement les premiers sont forcément ceux qu'on attends.
+  * Je garde la requête en format long. Une alternative serait :
+    * ''%m %U%q'' (méthode de la requête type GET/POST/etc, chemin sans les arguments, les arguments). Ça ne me semble pas forcément utile actuellement de détailler de cette façon, le résultat sera assez similaire.
+  * Je garde l'User-Agent, qui permet de bannir facilement des bots de GAFAM ou des bots vraiment mal fichus. Mais attention, ça piste aussi assez bien les utilisatrices légitimes.
+  * Le Referer n'a pas forcément d'utilité dans la lutte anti-bot, mais peut en avoir quand on débugue les sites.
+Attention, ce format de log n'a rien de classique ; il ne sera pas facilement interprété par les logiciels à moins d'indiquer les bonnes regex. Justement dans mon cas j'ai besoin de les créer pour Reaction, mais suivant les outils, c'est peut-être un plan foireux !
 ==== Could not reliably determine the server's fully qualified domain name ====
 À chaque modif du serveur, vous avez sans doute droit à ce message d'erreur :