Différences

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

--- fr:apache [2025/02/09 17:34] – [Content Security Policy (CSP)] Encore mieux zatalyz
+++ fr:apache [2025/06/26 20:41] (Version actuelle) – [Faire des pages d'erreurs personnalisées] zatalyz
@@ Ligne 644: / 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 732: / 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 :