Formatage HowToApache.md avec fmt(1)

Il est de mon avis qu’il devrait y avoir une limite a la longueur
de la ligne similaire a nos pratiques de formatage de courriels.
fmt(1) doit être appliqué seulement sur des paragraphes. Puisque
il se débarrasse automatiquement d’espaces et retour a la ligne
superflues.
This commit is contained in:
Patrick Marchand 2018-10-25 16:33:25 -04:00
parent bce06827ae
commit 10691a8bbf

View file

@ -6,11 +6,16 @@ title: Howto Apache
* Documentation : <https://httpd.apache.org/docs/2.4/>
* Rôle Ansible : <https://forge.evolix.org/projects/ansible-roles/repository/show/apache>
[Apache](https://httpd.apache.org/) est le serveur [HTTP](HowtoHTTP) le plus utilisé sur le web depuis 1996.
[Apache](https://httpd.apache.org/) est le serveur [HTTP](HowtoHTTP)
le plus utilisé sur le web depuis 1996.
## Installation
Nous utilisons la version [Apache-ITK](http://mpm-itk.sesse.net/) depuis des années en production sur de nombreux serveurs critiques. Apache-ITK permet de préciser pour chaque VirtualHost un utilisateur, un groupe et une option *MaxClients* spécifiques, ce qui est utile pour la sécurité d'un serveur multi-sites.
Nous utilisons la version [Apache-ITK](http://mpm-itk.sesse.net/)
depuis des années en production sur de nombreux serveurs critiques.
Apache-ITK permet de préciser pour chaque VirtualHost un utilisateur,
un groupe et une option *MaxClients* spécifiques, ce qui est utile
pour la sécurité d'un serveur multi-sites.
~~~
# apt install apache2 libapache2-mpm-itk libapache2-mod-evasive apachetop libwww-perl
@ -95,7 +100,8 @@ Fichiers de configuration :
└── X.conf -> ../sites-available/X.conf
~~~
La configuration principale se trouve dans le fichier `/etc/apache2/apache2.conf` qui inclut de nombreux fichiers séparés.
La configuration principale se trouve dans le fichier
`/etc/apache2/apache2.conf` qui inclut de nombreux fichiers séparés.
Nous activons toujours au minimum les modules suivants :
@ -103,7 +109,8 @@ Nous activons toujours au minimum les modules suivants :
# a2enmod rewrite expires headers rewrite cgi
~~~
Le fichier `/etc/apache2/conf-available/z-evolinux-defaults.conf` contient nos optimisations basiques :
Le fichier `/etc/apache2/conf-available/z-evolinux-defaults.conf`
contient nos optimisations basiques :
~~~{.apache}
ServerTokens Prod
@ -135,7 +142,10 @@ que l'on active à l'installation via la commande :
# a2enconf z-evolinux-defaults.conf
~~~
Le fichier `/etc/apache2/ipaddr_whitelist.conf` centralise les adresses IP privilégiées, on peut ainsi utiliser `Include ipaddr_whitelist.conf` à différents endroits dans la configuration d'Apache sans dupliquer ces adresses :
Le fichier `/etc/apache2/ipaddr_whitelist.conf` centralise les
adresses IP privilégiées, on peut ainsi utiliser `Include
ipaddr_whitelist.conf` à différents endroits dans la configuration
d'Apache sans dupliquer ces adresses :
~~~{.apache}
Allow from 192.0.2.42
@ -149,20 +159,23 @@ umask 007
### Valider la configuration
Avant de redémarrer le serveur, vérifier que vous n'ayez pas introduit des erreurs de syntaxes dans la configuration :
Avant de redémarrer le serveur, vérifier que vous n'ayez pas introduit
des erreurs de syntaxes dans la configuration :
~~~
# apache2ctl configtest
Syntax OK
~~~
## VirtualHost
Le terme **VirtualHost** correspond à la séparation de plusieurs sites sur un même serveur HTTP.
Apache permet d'avoir des VirtualHost basés sur des noms de domaine différents (ou des adresses IP différentes).
Le terme **VirtualHost** correspond à la séparation de plusieurs
sites sur un même serveur HTTP. Apache permet d'avoir des VirtualHost
basés sur des noms de domaine différents (ou des adresses IP
différentes).
Exemple d'un VirtualHost basé sur un nom de domaine via `/etc/apache2/sites-available/example.conf` :
Exemple d'un VirtualHost basé sur un nom de domaine via
`/etc/apache2/sites-available/example.conf` :
~~~{.apache}
<VirtualHost *:80>
@ -214,14 +227,18 @@ Exemple d'un VirtualHost basé sur un nom de domaine via `/etc/apache2/sites-ava
# a2ensite example
~~~
En cas de gestion de multiples VirtualHost nous utilisons l'interface web <https://forge.evolix.org/projects/evoadmin-web>
En cas de gestion de multiples VirtualHost nous utilisons l'interface
web <https://forge.evolix.org/projects/evoadmin-web>
## Gestion des droits
### Séparation complète des VirtualHost
L'utilisation d'Apache-ITK nous permet d'utiliser des utilisateurs/groupes Unix distincts pour chaque VirtualHost.
Il est donc impossible pour un utilisateur d'accéder en lecture à des fichiers d'un autre site, même si un langage dynamique comme PHP est utilisé.
L'utilisation d'Apache-ITK nous permet d'utiliser des utilisateurs/groupes
Unix distincts pour chaque VirtualHost. Il est donc impossible
pour un utilisateur d'accéder en lecture à des fichiers d'un autre
site, même si un langage dynamique comme PHP est utilisé.
~~~
# chmod 750 /home/example
@ -229,8 +246,17 @@ Il est donc impossible pour un utilisateur d'accéder en lecture à des fichiers
### Restriction en écriture pour Apache
Par défaut on souhaite donner uniquement un droit de lecture à Apache, sauf sur certains répertoires du type *uploads/*, *cache/*, etc.
On utilise pour cela un utilisateur distinct pour Apache (`www-example`) et la gestion du code via FTP/SSH/SFTP/SCP/RSYNC (example), le groupe étant identique. Ainsi on donnera la permission **`g+w`** pour les répertoires nécessitant un droit en écriture pour Apache. Les fichiers uploadés via Apache auront des permissions adéquats (`g+rwX`) pour être lus/modifiés/effacés via FTP/SSH/SFTP/SCP/RSYNC (l'opération `chmod` est impossible mais n'est pas nécessaire car le umask d'Apache est forcé à 007).
Par défaut on souhaite donner uniquement un droit de lecture à
Apache, sauf sur certains répertoires du type *uploads/*, *cache/*,
etc. On utilise pour cela un utilisateur distinct pour Apache
(`www-example`) et la gestion du code via FTP/SSH/SFTP/SCP/RSYNC
(example), le groupe étant identique. Ainsi on donnera la permission
**`g+w`** pour les répertoires nécessitant un droit en écriture
pour Apache. Les fichiers uploadés via Apache auront des permissions
adéquats (`g+rwX`) pour être lus/modifiés/effacés via
FTP/SSH/SFTP/SCP/RSYNC (l'opération `chmod` est impossible mais
n'est pas nécessaire car le umask d'Apache est forcé à 007).
~~~
# echo "umask 027" >> /etc/profile
@ -238,7 +264,11 @@ On utilise pour cela un utilisateur distinct pour Apache (`www-example`) et la g
# find /home/example -type d -user www-example -exec chmod 770 {} \;
~~~
Attention, il ne faut jamais forcer les droits récursivement sur toute l'arborescence. Si la restriction en écriture pour Apache est impossible à gérer, on n'utilisera pas d'utilisateur distinct en indiquant `AssignUserID example example` ce qui éliminera 100% des problèmes de droits (mais pose des problèmes de sécurité).
Attention, il ne faut jamais forcer les droits récursivement sur
toute l'arborescence. Si la restriction en écriture pour Apache est
impossible à gérer, on n'utilisera pas d'utilisateur distinct en
indiquant `AssignUserID example example` ce qui éliminera 100% des
problèmes de droits (mais pose des problèmes de sécurité).
## SSL
@ -248,7 +278,8 @@ Apache peut gérer des connexions sécurisées via HTTPS.
# a2enmod ssl
~~~
Il faut alors générer une clé privée et un certificat auto-signé ou délivré par une autorité de certification.
Il faut alors générer une clé privée et un certificat auto-signé
ou délivré par une autorité de certification.
Voir [HowtoSSL]()
@ -281,16 +312,21 @@ La configuration d'un VirtualHost pour HTTPS pourra ainsi ressembler à :
</VirtualHost>
~~~
Pour une configuration avancée des paramètres SSL, voir [HowtoSSL#configuration-apache]()
Pour une configuration avancée des paramètres SSL, voir
[HowtoSSL#configuration-apache]()
> *Note* : la syntaxe `<VirtualHost *:80 *:443>` n'est possible
qu'à partir de Debian 8.
> *Note* : la syntaxe `<VirtualHost *:80 *:443>` n'est possible qu'à partir de Debian 8.
## Logs
<https://httpd.apache.org/docs/2.4/fr/logs.html>
La directive **CustomLog** permet de définir le journal des accès ; plusieurs formats existent : combined, common, vhost_combined, etc.
Cette directive peut être utilisée plusieurs fois, il y aura plusieurs fichiers de logs différents.
La directive **CustomLog** permet de définir le journal des accès
; plusieurs formats existent : combined, common, vhost_combined,
etc. Cette directive peut être utilisée plusieurs fois, il y aura
plusieurs fichiers de logs différents.
~~~{.apache}
CustomLog log/global_access.log vhost_combined
@ -312,7 +348,10 @@ ErrorLog log/error.log
### Logué la taille de la requête et le temps dexécution
Si l'on veut loguer, dans un log séparé, la taille de la requête et le temps dexécution par Apache de cette requête, on peut créer une configuration apache avec le LogFormat suivant, dans */etc/apache2/conf-available/access-log-time.conf* :
Si l'on veut loguer, dans un log séparé, la taille de la requête
et le temps dexécution par Apache de cette requête, on peut créer
une configuration apache avec le LogFormat suivant, dans
*/etc/apache2/conf-available/access-log-time.conf* :
~~~
LogFormat "%h %t \"%r\" %B %D" measure-time
@ -328,11 +367,15 @@ CustomLog /home/example/log/access_log_time.log measure-time
### mod_deflate
La compression des fichiers texte/Javascript/CSS/RSS en GZIP se fait désormais par défaut car le module **mod_deflate** est activé dès l'installation.
La compression des fichiers texte/Javascript/CSS/RSS en GZIP se
fait désormais par défaut car le module **mod_deflate** est activé
dès l'installation.
### mod_proxy_http
Le module [proxy](https://httpd.apache.org/docs/2.4/mod/mod_proxy.html) permet d'utiliser Apache en tant que proxy, notamment reverse-proxy HTTP :
Le module [proxy](https://httpd.apache.org/docs/2.4/mod/mod_proxy.html)
permet d'utiliser Apache en tant que proxy, notamment reverse-proxy
HTTP :
~~~
# a2enmod proxy_http
@ -349,7 +392,8 @@ ProxyPassReverse /foo/ http://127.0.0.1:8080/bar
</Proxy>
~~~
Exemple avec un service HTTP distant (pratique pour une migration immédiate d'un serveur vers un autre) :
Exemple avec un service HTTP distant (pratique pour une migration
immédiate d'un serveur vers un autre) :
~~~{.apache}
ProxyPreserveHost On
@ -362,9 +406,15 @@ ProxyPassReverse / http://192.0.2.17/
### mod_rpaf / mod_remoteip
Le module [mod_remoteip](https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html) (**mod_rpaf** en Wheezy) permet d'utiliser la 1ère adresse IP située dans un entête HTTP type *X-Forwarded-For* pour les logs Apache et directives **mod_access** (Allow/Deny From).
Le module
[mod_remoteip](https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html)(**mod_rpaf** en Wheezy)
permet d'utiliser la 1ère adresse IP située
dans un entête HTTP type *X-Forwarded-For* pour les logs Apache et
directives **mod_access** (Allow/Deny From).
Voici un exemple d'utilisation en Wheezy pour un reverse-proxy avec l'adresse IP 192.0.2.10 :
Voici un exemple d'utilisation en Wheezy pour un reverse-proxy avec
l'adresse IP 192.0.2.10 :
~~~
# apt install libapache2-mod-rpaf
@ -379,7 +429,8 @@ RPAFproxy_ips 127.0.0.1 192.0.2.10
*Note :* bien mettre l'IP du reverse-proxy dans `RPAFproxy_ips`
Voici un exemple d'utilisation en Stretch pour un reverse-proxy avec le réseau 172.131.0.0/16 :
Voici un exemple d'utilisation en Stretch pour un reverse-proxy
avec le réseau 172.131.0.0/16 :
~~~
# a2enmod remoteip
@ -390,7 +441,8 @@ RemoteIPInternalProxy 172.31.0.0/16
# systemctl reload apache2
~~~
Attention au niveau des logs cela ne suffit pas. L'astuce est de modifier le `LogFormat`, en remplaçant `%h` par `%a`.
Attention au niveau des logs cela ne suffit pas. L'astuce est de
modifier le `LogFormat`, en remplaçant `%h` par `%a`.
~~~
# cat /etc/apache2/conf-available/zzz-evolinux-custom.conf
@ -402,23 +454,33 @@ LogFormat "%a %l %u %t \"%r\" %>s %O" common
### mod_xsendfile
Le module [xsendfile](https://tn123.org/mod_xsendfile/) permet de rediriger l'envoi d'un fichier vers Apache via un Header HTTP, notamment utilisé pour servir des fichiers via Apache tout en permettant de gérer le contrôle d'accès via une application web.
Le module [xsendfile](https://tn123.org/mod_xsendfile/) permet de
rediriger l'envoi d'un fichier vers Apache via un Header HTTP,
notamment utilisé pour servir des fichiers via Apache tout en
permettant de gérer le contrôle d'accès via une application web.
~~~
# apt install libapache2-mod-xsendfile
~~~
Pour autoriser son utilisation via *.htaccess*, on ajoute `Options` à `AllowOverride`.
Pour autoriser son utilisation via *.htaccess*, on ajoute `Options`
à `AllowOverride`.
### mod_negotiation
Le module [negotiation](https://httpd.apache.org/docs/2.4/mod/mod_negotiation.html) permet de servir des documents en fonction de critère, notamment la langue acceptée par le client HTTP.
Le module
[negotiation](https://httpd.apache.org/docs/2.4/mod/mod_negotiation.html)
permet de servir des documents en fonction de critère, notamment
la langue acceptée par le client HTTP.
~~~
# a2enmod negotiation include alias
~~~
Vous pouvez éditer le fichier `/etc/apache2/conf-enabled/localized-error-pages.conf` qui permet d'afficher des pages d'erreur en différentes langues, et décommenter cette partie :
Vous pouvez éditer le fichier
`/etc/apache2/conf-enabled/localized-error-pages.conf` qui permet
d'afficher des pages d'erreur en différentes langues, et décommenter
cette partie :
Exemple avec un service HTTP local :
@ -463,15 +525,21 @@ Exemple avec un service HTTP local :
### mod_geoip
Ce module permet de pouvoir traiter différemment des visiteurs par rapport à leur pays d'origine directement depuis la configuration d'Apache. Il utilise pour cela la base GeoIP de [Maxmind](https://www.maxmind.com).
Ce module permet de pouvoir traiter différemment des visiteurs par
rapport à leur pays d'origine directement depuis la configuration
d'Apache. Il utilise pour cela la base GeoIP de
[Maxmind](https://www.maxmind.com).
~~~
# apt install geoip-database-contrib libapache2-mod-geoip
~~~
Note: geoip-database-contrib (dans les dépots contrib) va installer un cron qui va mettre à jour les fichiers de la base GeoIP. Ces fichiers de base se trouvent dans `/usr/share/GeoIP/`
Note: geoip-database-contrib (dans les dépots contrib) va installer
un cron qui va mettre à jour les fichiers de la base GeoIP. Ces
fichiers de base se trouvent dans `/usr/share/GeoIP/`
Quand on va avoir besoin de GeoIP, il faut penser à l'activer dans le(s) fichier(s) de confs
Quand on va avoir besoin de GeoIP, il faut penser à l'activer dans
le(s) fichier(s) de confs
~~~
<IfModule mod_geoip.c>
@ -480,9 +548,12 @@ Quand on va avoir besoin de GeoIP, il faut penser à l'activer dans le(s) fichie
</IfModule>
~~~
De là, le pays d'origine du visiteur, ainsi que d'autres informations sont placées dans des variables d'environnement utilisables dans le VHOST.
De là, le pays d'origine du visiteur, ainsi que d'autres informations
sont placées dans des variables d'environnement utilisables dans
le VHOST.
Exemple : Autoriser que les visiteurs venant de France pour un accéder à un dossier précis :
Exemple : Autoriser que les visiteurs venant de France pour un
accéder à un dossier précis :
~~~
<Directory /var/www/foo/bar>
@ -498,8 +569,9 @@ RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^FR$
RewriteRule ^(.*)$ https://www.example.fr$1 [R,L]
~~~
La documentation complète du module est là
Pour plus d'info, il y a la [documentation complète du module](https://dev.maxmind.com/geoip/legacy/mod_geoip2/)
La documentation complète du module est là Pour plus d'info, il y
a la [documentation complète du
module](https://dev.maxmind.com/geoip/legacy/mod_geoip2/)
### mod_davfs
@ -511,7 +583,8 @@ Pour l'activer :
# a2enmod davfs
~~~
Ensuite pour activer le module, il suffit de rajouter `Dav On` dans le virtualhost voulu.
Ensuite pour activer le module, il suffit de rajouter `Dav On` dans
le virtualhost voulu.
Exemple de vhost :
@ -543,7 +616,10 @@ Exemple de vhost :
### HTTP Basic Authentication (mod_auth_basic)
[Basic](http://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html) est la méthode d'authenfication HTTP la plus simple et la plus répandue. La configuration se fait via *VirtualHost* ou *.htaccess* :
[Basic](http://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html)
est la méthode d'authenfication HTTP la plus simple et la plus
répandue. La configuration se fait via *VirtualHost* ou *.htaccess*
:
~~~{.apache}
AuthType Basic
@ -566,7 +642,8 @@ Adding password for user user
### HTTP Digest Authentication (mod_auth_digest)
Il est possible d'utiliser la méthode d'authentification Digest plutôt que Basic en activant le module :
Il est possible d'utiliser la méthode d'authentification Digest
plutôt que Basic en activant le module :
~~~
# a2enmod auth_digest
@ -599,14 +676,17 @@ AuthLDAPURL ldaps://ldap.example.com/ou=people,dc=example,dc=com?uid?one?(filter
Require valid-user
~~~
Note : pour utiliser *ldaps* avec un certificat non reconnu par le système, il faut ajouter la directive suivante dans la configuration globale d'Apache `LDAPVerifyServerCert off`.
Note : pour utiliser *ldaps* avec un certificat non reconnu par le
système, il faut ajouter la directive suivante dans la configuration
globale d'Apache `LDAPVerifyServerCert off`.
## Rewrite Rules
* mod_rewrite : <http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html>
* drapeaux utilisables : <https://httpd.apache.org/docs/2.4/rewrite/flags.html>
Voici quelques motifs classiques de redirection vers un nouveau domaine (HTTP 302) … du plus simple au plus compliqué :
Voici quelques motifs classiques de redirection vers un nouveau
domaine (HTTP 302) … du plus simple au plus compliqué :
~~~
# rediriger la page d'accueil avec un code 301
@ -646,11 +726,16 @@ ErrorDocument 503 "Maintenance temporaire, veuillez patienter. Merci."
#Header Set Pragma "no-cache"
~~~
Pour supprimer un Query String avec une Rewrite Rule : <https://www.philipphoffmann.de/blog/2012/08/16/how-to-discard-the-query-string-in-a-rewriterule-apache-mod_rewrite/>
Pour supprimer un Query String avec une Rewrite Rule :
<https://www.philipphoffmann.de/blog/2012/08/16/how-to-discard-the-query-string-in-a-rewriterule-apache-mod_rewrite/>
### Redirection https
Dans le cas où le serveur n'écoute que sur le port 80, derrière un proxy qui fait la terminaison SSL mais ne gère pas les redirections (exemple Amazon ELB), on peut forcer la redirection directement dans Apache en utilisant la valeur de l'en-tête `X-Forwarded-Proto` :
Dans le cas où le serveur n'écoute que sur le port 80, derrière un
proxy qui fait la terminaison SSL mais ne gère pas les redirections
(exemple Amazon ELB), on peut forcer la redirection directement
dans Apache en utilisant la valeur de l'en-tête `X-Forwarded-Proto`
:
~~~
RewriteEngine On
@ -660,7 +745,9 @@ RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]
## Conditions
À partir de la version Apache 2.4, on peut utiliser des conditions pour l'application des directives (l'imbrication de multiples <If> n'est disponible que pour les versions >= 2.4.26).
À partir de la version Apache 2.4, on peut utiliser des conditions
pour l'application des directives (l'imbrication de multiples <If>
n'est disponible que pour les versions >= 2.4.26).
~~~{.bash}
<If "%{HTTP_HOST} == 'test.example.com'">
@ -677,7 +764,13 @@ Expressions possibles : [https://httpd.apache.org/docs/2.4/expr.html](https://ht
### mod_evasive
Le module **mod_evasive** permet de limiter certaines attaques DoS en limitant l'accès à une ou plusieurs pages par un temps de banissement d'une IP source. Par défaut, nous ajustons la configuration de façon à ce que si une adresse IP accède plus de 5 fois à la même page en 30s, ou à plus de 30 requêtes sur tout le site en 1s, il sera banni (erreur HTTP 403) pendant 60s. Une notification sera alors envoyée à syslog et par email.
Le module **mod_evasive** permet de limiter certaines attaques DoS
en limitant l'accès à une ou plusieurs pages par un temps de
banissement d'une IP source. Par défaut, nous ajustons la configuration
de façon à ce que si une adresse IP accède plus de 5 fois à la même
page en 30s, ou à plus de 30 requêtes sur tout le site en 1s, il
sera banni (erreur HTTP 403) pendant 60s. Une notification sera
alors envoyée à syslog et par email.
~~~{.apache}
<IfModule mod_evasive20.c>
@ -691,31 +784,45 @@ Le module **mod_evasive** permet de limiter certaines attaques DoS en limitant l
</IfModule>
~~~
Attention, pour certains sites avec de nombreuses ressources statiques sur le même serveur HTTP, il faut souvent désactiver **mod_evasive** pour éviter des faux-positifs et ne l'utiliser qu'en cas d'attaques récurrentes.
Attention, pour certains sites avec de nombreuses ressources statiques
sur le même serveur HTTP, il faut souvent désactiver **mod_evasive**
pour éviter des faux-positifs et ne l'utiliser qu'en cas d'attaques
récurrentes.
On peut mettre en liste blanche une ip ou une plage d'ip, pour que le mod_evasive ignore les requêtes venant de ceux-ci :
On peut mettre en liste blanche une ip ou une plage d'ip, pour que
le mod_evasive ignore les requêtes venant de ceux-ci :
~~~
DOSWhitelist 192.168.0.*
~~~
On peut aussi utiliser un wildcard * peut être autorisé sur les 3 derniers octets, si nécessaire.
On peut aussi utiliser un wildcard * peut être autorisé sur les 3
derniers octets, si nécessaire.
### Fail2Ban
[Fail2Ban](HowtoFail2Ban) est indépendant d'Apache, mais peut être utilisé pour de la détection plus précise que *mod_evasive* : il va lire en permanence les journaux générés par Apache (ce qui peut être coûteux en ressources) et il pourra bannir des adresses IP si cela répond à certaines règles comme trop de connexions à une page d'authentification par exemple.
[Fail2Ban](HowtoFail2Ban) est indépendant d'Apache, mais peut être
utilisé pour de la détection plus précise que *mod_evasive* : il
va lire en permanence les journaux générés par Apache (ce qui peut
être coûteux en ressources) et il pourra bannir des adresses IP si
cela répond à certaines règles comme trop de connexions à une page
d'authentification par exemple.
Voir <https://wiki.evolix.org/HowtoFail2Ban#apache-nginx>
### ModSecurity
L'utilisation de [ModSecurity](http://www.modsecurity.org) permet d'interdire certaines requêtes (attaques XSS connues, etc.) au niveau d'Apache. On l'installe généralement avec le [OWASP ModSecurity Core Rule Set](https://coreruleset.org/) (CRS)
L'utilisation de [ModSecurity](http://www.modsecurity.org) permet
d'interdire certaines requêtes (attaques XSS connues, etc.) au
niveau d'Apache. On l'installe généralement avec le [OWASP ModSecurity
Core Rule Set](https://coreruleset.org/) (CRS)
~~~
# apt install libapache2-mod-security2 modsecurity-crs
~~~
Nous faisons une configuration minimale via `/etc/apache2/conf-available/modsecurity.conf` :
Nous faisons une configuration minimale via
`/etc/apache2/conf-available/modsecurity.conf` :
~~~{.apache}
<IfModule security2_module>
@ -753,9 +860,14 @@ Nous faisons une configuration minimale via `/etc/apache2/conf-available/modsecu
</IfModule>
~~~
On peut aussi ajuster certains paramètres de ModSecurity Core Rule Set en ajustant le fichier `/etc/modsecurity/crs/crs-setup.conf`. C'est notamment ici qu'il faudra ajuster si on utilise d'autres méthodes HTTP (comme PATCH, DELETE) qui risque d'être bloquées
On peut aussi ajuster certains paramètres de ModSecurity Core Rule
Set en ajustant le fichier `/etc/modsecurity/crs/crs-setup.conf`.
C'est notamment ici qu'il faudra ajuster si on utilise d'autres
méthodes HTTP (comme PATCH, DELETE) qui risque d'être bloquées
On pourra désactiver modsecurity dans des vhosts ou sur des dossiers en particulier en jouant avec la directive `SecRuleEngine Off` Utile notamment sur l'administration de Wordpress ou PHPmyAdmin
On pourra désactiver modsecurity dans des vhosts ou sur des dossiers
en particulier en jouant avec la directive `SecRuleEngine Off` Utile
notamment sur l'administration de Wordpress ou PHPmyAdmin
~~~
<Directory "/home/monsite/www/wp-admin">
<IfModule security2_module>
@ -764,26 +876,33 @@ On pourra désactiver modsecurity dans des vhosts ou sur des dossiers en particu
</Directory>
~~~
On peut aussi désactiver des règles spécifiques en utilisant `SecRuleRemoveById XXXX`
On peut aussi désactiver des règles spécifiques en utilisant
`SecRuleRemoveById XXXX`
Le Wiki À propos de [ces directives](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual)
Pour une configuration avancée, on ajuste l'utilisation du jeu de règles *modsecurity-crs* et l'on gère nos propres règles personnalisées.
Pour une configuration avancée, on ajuste l'utilisation du jeu de
règles *modsecurity-crs* et l'on gère nos propres règles personnalisées.
## Awstats
[AWStats](http://www.awstats.org/) est un outil pour générer des statistiques en fonction d'un fichier de logs.
[AWStats](http://www.awstats.org/) est un outil pour générer des
statistiques en fonction d'un fichier de logs.
Voir <https://wiki.evolix.org/HowtoLAMP/AwStats>
*Note :* une configuration AWStats peut être forcée au sein d'un VirtualHost grâce à la directive `SetEnv AWSTATS_FORCE_CONFIG example`
*Note :* une configuration AWStats peut être forcée au sein d'un
VirtualHost grâce à la directive `SetEnv AWSTATS_FORCE_CONFIG
example`
## Monitoring
### log2mail
Pour être alerté en cas de *Segmentation fault*, on ajoute la configuration suivante au logiciel [log2mail](https://wiki.evolix.org/HowtoLog2mail) :
Pour être alerté en cas de *Segmentation fault*, on ajoute la
configuration suivante au logiciel
[log2mail](https://wiki.evolix.org/HowtoLog2mail) :
~~~
file = /var/log/apache2/error.log
@ -798,13 +917,18 @@ file = /var/log/apache2/error.log
### apachetop
L'indispensable **apachetop** permet de surveiller en direct l'activité d'Apache via un fichier d'access_log (format *combined*) :
L'indispensable **apachetop** permet de surveiller en direct
l'activité d'Apache via un fichier d'access_log (format *combined*)
:
~~~
$ apachetop -f access.log -T 3600 -q
~~~
On peut alors visualiser les URLs les plus sollicitées (querystrings inclus grâce à l'option *-q*), et switcher à l'aide de la touche **d** pour voir les adresses IP source ; à l'aide de la touche **n** pour voir la répartition en codes HTTP 2xx/3xx/4xx/5xx.
On peut alors visualiser les URLs les plus sollicitées (querystrings
inclus grâce à l'option *-q*), et switcher à l'aide de la touche
**d** pour voir les adresses IP source ; à l'aide de la touche
**n** pour voir la répartition en codes HTTP 2xx/3xx/4xx/5xx.
Voici l'ensemble des commandes disponibles :
@ -834,7 +958,8 @@ f: FILTRES:
### server-status
L'activation du *server-status* est utile pour une observation manuelle ou automatique.
L'activation du *server-status* est utile pour une observation
manuelle ou automatique.
~~~{.apache}
<IfModule mod_status.c>
@ -860,7 +985,8 @@ Pour activer les plugins Munin pour Apache :
# ln -s /usr/share/munin/plugins/apache_volume
~~~
Les plugins Apache pour Munin se base *server-status*, on configure ainsi via le fichier `/etc/munin/plugin-conf.d/munin-node` :
Les plugins Apache pour Munin se base *server-status*, on configure
ainsi via le fichier `/etc/munin/plugin-conf.d/munin-node` :
~~~
[apache_*]
@ -874,7 +1000,10 @@ Pour tester le bon fonctionnement des plugins Apache pour Munin :
# sudo -u munin munin-run apache_accesses
~~~
Ceci doit vous renvoyer une valeur du type accesses80.value 19372070. Si la commande vous renvoie U, vous avez un soucis d'accès à la page *server-status*, à vérifier via `GET http://127.0.0.1:%d/server-status-XXXX?auto`.
Ceci doit vous renvoyer une valeur du type accesses80.value 19372070.
Si la commande vous renvoie U, vous avez un soucis d'accès à la
page *server-status*, à vérifier via
`GET http://127.0.0.1:%d/server-status-XXXX?auto`.
## FAQ
@ -888,11 +1017,13 @@ Ajouter `Indexes` dans `AllowOverride`.
### Autorisation de rewrite rules (mod_rewrite) via .htaccess ?
Ajouter `FileInfo` dans `AllowOverride` et `+SymLinksIfOwnerMatch` ou `+FollowSymLinks` dans `Options`.
Ajouter `FileInfo` dans `AllowOverride` et `+SymLinksIfOwnerMatch`
ou `+FollowSymLinks` dans `Options`.
### Autorisation Options via .htaccess ?
Si l'on modifie l'option `php_admin_value memory_limit` : un _reload_/_graceful_ suffit pour prendre en compte la modification.
Si l'on modifie l'option `php_admin_value memory_limit` : un
_reload_/_graceful_ suffit pour prendre en compte la modification.
Exemple pour le AllowOverride :
@ -902,9 +1033,13 @@ AllowOverride Options=All,MultiViews Indexes AuthConfig Limit FileInfo
### Authentification LDAP avec serveur LDAP en local
Quand on utilise l'authentification LDAP avec un serveur en local, il faut démarrer **slapd** avant de démarrer Apache, sinon celui-ci se plaint qu'il ne peut pas contacter le serveur LDAP, et bloque l'accès aux pages … (erreur 500).
Quand on utilise l'authentification LDAP avec un serveur en local,
il faut démarrer **slapd** avant de démarrer Apache, sinon celui-ci
se plaint qu'il ne peut pas contacter le serveur LDAP, et bloque
l'accès aux pages … (erreur 500).
Pour cela, dans le script d'init d'apache2 ajouter slapd dans la directive `Required-Start:`
Pour cela, dans le script d'init d'apache2 ajouter slapd dans la
directive `Required-Start:`
~~~
# Required-Start: $local_fs $remote_fs $network $syslog $named slapd
@ -919,9 +1054,12 @@ Supprimer les liens logiques et ré-générer les.
### Page personnalisée lors code erreur HTTP
On peut ajouter une configuration générale à tous les vhosts afin de faire apparaître le contenu d'une page personnalisée selon le code de retour HTTP.
On peut ajouter une configuration générale à tous les vhosts afin
de faire apparaître le contenu d'une page personnalisée selon le
code de retour HTTP.
Pour cela on ajoute un nouveau fichier de configuration à l'intérieur de la racine apache, car cela concernera tout les vhosts.
Pour cela on ajoute un nouveau fichier de configuration à l'intérieur
de la racine apache, car cela concernera tout les vhosts.
`/etc/apache2/error.conf` :
@ -935,9 +1073,12 @@ Alias /YYYYYY /var/www/
</Directory>
~~~
*Remplacer XXX par le code erreur HTTP souhaité et YYYYY par le nom de Location souhaité (URL) - vu que global à tous les vhosts, prendre une chaîne aléatoire.*
*Remplacer XXX par le code erreur HTTP souhaité et YYYYY par le nom
de Location souhaité (URL) - vu que global à tous les vhosts, prendre
une chaîne aléatoire.*
Ensuite, il suffit simplement d'ajouter le fichier dans la configuration générale d'Apache :
Ensuite, il suffit simplement d'ajouter le fichier dans la configuration
générale d'Apache :
`/etc/apache2/apache2.conf` :
@ -947,13 +1088,16 @@ Include error.conf
### Site web cassé en https avec un reverse proxy
Il est possible que l'application (joomla par exemple) pense qu'elle est accédée en HTTP à tort parce qu'en réalité c'est un reverse proxy qui fait la terminaison ssl. On peut indiquer dans le vhost
Il est possible que l'application (joomla par exemple) pense qu'elle
est accédée en HTTP à tort parce qu'en réalité c'est un reverse
proxy qui fait la terminaison ssl. On peut indiquer dans le vhost
~~~{.apache}
SetEnvIfNoCase X-Forwarded-Proto https HTTPS=on
~~~
Ainsi l'application saura qu'elle est accédée en HTTPS à condition que le reverse proxy soit bien configuré et envoie X-Forwarded-Proto.
Ainsi l'application saura qu'elle est accédée en HTTPS à condition
que le reverse proxy soit bien configuré et envoie X-Forwarded-Proto.
### Interdire en fonction du User-Agent
@ -967,15 +1111,21 @@ SetEnvIf User-Agent "Nutch" GoAway=1
### Site avec accents cassés
Si vous avez des vieux fichiers sources (TXT, HTML), il est probable qu'ils utilisent l'encodage ISO-8859 au lieu d'Unicode.
On peut alors forcer la reconnaissance de cet encodage (ajout de charset= dans l'entête HTTP Content-Type) via l'option
`AddDefaultCharset` utilisable globalement, dans un VirtualHost, dans un Directory ou même un .htaccess si autorisé :
Si vous avez des vieux fichiers sources (TXT, HTML), il est probable
qu'ils utilisent l'encodage ISO-8859 au lieu d'Unicode. On peut
alors forcer la reconnaissance de cet encodage (ajout de charset=
dans l'entête HTTP Content-Type) via l'option `AddDefaultCharset`
utilisable globalement, dans un VirtualHost, dans un Directory ou
même un .htaccess si autorisé :
~~~
AddDefaultCharset ISO-8859-15
~~~
> *Note* : si vous avez des fichiers PHP en ISO-8859, vous devrez forcer l'option `default_charset` de PHP :
> *Note* : si vous avez des fichiers PHP en ISO-8859, vous devrez
> forcer l'option `default_charset` de PHP :
>
>
> ~~~
> php_value default_charset ISO-8859-15
@ -983,10 +1133,13 @@ AddDefaultCharset ISO-8859-15
### php_value error_reporting
Pour régler la valeur PHP `error_reporting` par vhost, il ne faut pas utiliser les constantes PHP mais le masque binaire.
Pour régler la valeur PHP `error_reporting` par vhost, il ne faut
pas utiliser les constantes PHP mais le masque binaire.
Extrait de <http://php.net/manual/fr/errorfunc.constants.php> : « Note: Vous pouvez utiliser ces constantes dans le fichier `php.ini`
mais pas hors de PHP, comme dans le fichier `httpd.conf`, où vous devez utiliser les valeurs des champs de bits. »
Extrait de <http://php.net/manual/fr/errorfunc.constants.php> : «
Note: Vous pouvez utiliser ces constantes dans le fichier `php.ini`
mais pas hors de PHP, comme dans le fichier `httpd.conf`, où vous
devez utiliser les valeurs des champs de bits. »
Exemple :
@ -998,7 +1151,8 @@ Vous pouvez le calculer à la main ou avec un outil comme celui-ci :
### Ne pas logguer le query-string dans le access.log
On peut ajouter un nouveau format de log dans `/etc/apache2/apache.conf` et l'utiliser après dans les définitions de fichier de logs :
On peut ajouter un nouveau format de log dans `/etc/apache2/apache.conf`
et l'utiliser après dans les définitions de fichier de logs :
~~~
LogFormat "%h %l %u %t \"%m %U %H\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combinednoqtring