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.
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 :
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).
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é).
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 [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.
[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
AuthName "Restricted"
AuthUserFile /foo/.htpasswd
AuthGroupFile /dev/null
require valid-user
~~~
La gestion du fichier *.htpasswd* se gère via la commande `htpasswd`.
### 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 :
~~~
# a2enmod auth_digest
~~~
La configuration est quasi-identique au type Basic :
~~~{.apache}
AuthType Digest
AuthName "Restricted"
AuthUserFile /foo/.htpasswd
Require valid-user
~~~
La gestion du fichier *.htpasswd* se gère alors via la commande `htdigest`.
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`.
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/>
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.
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.
[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.
Pour être alerté en cas de *Segmentation fault*, on ajoute la configuration suivante au logiciel [log2mail](http://trac.evolix.net/infogerance/wiki/HowtoLog2mail) :
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 :
~~~
d : switch l'affichage entre URLs/IPs source/Referrers
n : switch l'affichage entre le nombre de requêtes et la répartition en codes HTTP 2xx/3xx/4xx/5xx
h or ? : afficher l'aide
p : (un)freeze l'affichage
q : quitter
up/down : sélectionner une ligne (affichage d'une '*' sur la ligne)
right/left : entrer/sortir dans les détails pour la ligne sélectionnées
DÉTAILS:
s: TRI PAR:
r) requêtes R) reqs/sec b) bytes B) bytes/sec
2) 2xx 3) 3xx 4) 4xx 5) 5xx
t: AFFICHEDANSLE SOUS-MENU:
u) urls r) referrers h) adresses IP source
f: FILTRES:
a) ajout d'un filtre c) suppression des filtres s) montrer les filtres actifs
a: AJOUT D'UN FILTRE TYPE REGEX
u) appliqué à l'URL r) appliqué au Refferer h) appliqué à l'adresse IP source
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`.
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).
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.
*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.*
