Nous utilisons [Apache-ITK](http://mpm-itk.sesse.net/) depuis des années en production sur de nombreux serveurs critiques. Apache-ITKpermet de préciser pour chaque VirtualHost un utilisateur/groupe/*MaxClients* spécifique, ce qui est utile pour la sécurité d'un serveur multi-sites.
# vim: set filetype=apache expandtab shiftwidth=4 softtabstop=4 tabstop=4 :
~~~
~~~
# adduser example
# adduser --ingroup example www-example
# a2ensite example
~~~
## Gestion des droits
### Séparation complèe des différents VirtualHosts
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
~~~
### 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 écrite 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é).
Pour une configuration avancées des paramètres SSL : <http://trac.evolix.net/infogerance/wiki/HowtoSSL#AvecApache>
## Configuration avancée
### mod_deflate
La compression des fichiers texte/Javascript/CSS/RSS en GZIP se fait désormais par défault car le module mod_deflate est activé dès l'installation.
### mod_xsendfile
Le module 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.
~~~
# aptitude install libapache2-mod-xsendfile
# a2enmod xsendfile
~~~
Pour autoriser son utilisation via .htaccess, on ajoute *Options* à `AllowOverride`.
## mod_spdy (deprecated)
C'est un module qui permet d'activer le protocole SPDY (de Google).
Pour désactiver globalement mod_spdy, on peut utiliser la directive `SpdyEnabled off`.
Pour vérifier que le protocole SPDY est bien en place : <https://developers.google.com/speed/spdy/mod_spdy/>
## Authentification HTTP
### 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* :
~~~{.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`.
## Rewrite Rules
## Attaques DOS (Denial Of Service) ou XSS
### 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.
~~~{.apache}
<IfModulemod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 30
DOSPageInterval 3
DOSSiteInterval 1
DOSBlockingPeriod 60
DOSEmailNotify security@example.com
</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.
### 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.
