Par défaut, Apache traite les requêtes entrantes en tant qu'utilisateur www-data. Ainsi, une faille de sécurité dans un script CGI exécuté par Apache (pour une page dynamique) ne compromet pas tout le système, mais seulement les données possédées par cet utilisateur.

L'usage du module suexec permet de changer cette règle afin que certains CGI soient exécutés avec les droits d'un autre utilisateur. Cela se paramètre avec la directive SuexecUserGroup utilisateur groupe dans la configuration de Apache.

Il est également possible d'utiliser un MPM dédié, comme celui fourni par libapache2-mpm-itk. Celui-ci a un fonctionnement différent, en ce qu'il permet d'« isoler » les hôtes virtuels (en réalité des ensembles de pages) de manière à ce qu'ils tournent chacun sous un utilisateur différent. Ainsi, une faille dans un site web dynamique ne compromettra pas les fichiers appartenant à l'utilisateur d'un autre site web.

La liste complète des modules standards d'Apache se trouve en ligne.

Apache 2.4 intègre en standard le module SSL nécessaire au HTTP sécurisé (HTTPS). Il faut juste l'activer avec a2enmod ssl puis placer les directives nécessaires dans la configuration. Un exemple est fourni dans /etc/apache2/sites-available/default-ssl.conf.

Il faudra prendre quelques précautions si l'on souhaite favoriser les connexions SSL avec confidentialité persistante (Perfect Forward Secrecy — ces sessions utilisent des clés de session éphémères, ce qui assure que la compromission de la clé secrète du serveur ne mène pas à celle de messages chiffrés qui auraient été préalablement interceptés sur le réseau). Pour plus de détails, et notamment pour les recommandations de Mozilla :

Le premier hôte virtuel défini répondra systématiquement aux requêtes concernant des hôtes virtuels inconnus. C'est pourquoi nous avons d'abord défini ici www.falcot.com.

Apache prend en charge une extension du protocole SSL appelée Server Name Indication (SNI). Elle permet au navigateur web d'envoyer le nom d'hôte du serveur web dès l'établissement de la connexion SSL, donc bien avant l'envoi de la requête HTTP qui sert habituellement à identifier le bon site web parmi tous les hôtes virtuels hébergés sur le même serveur (et la même adresse IP). Ainsi, Apache peut sélectionner le certificat SSL adéquat pour la communication.

Avant l'introduction de SNI, Apache employait systématiquement le certificat de l'hôte virtuel par défaut. Lorsque le certificat ne correspondait pas au site web demandé, les navigateurs affichaient donc des avertissements. Notons que ce comportement persiste lorsque l'utilisateur dispose d'un navigateur n'acceptant pas SNI. Fort heureusement la plupart des navigateurs l'exploitent désormais ; c'est le cas de Microsoft Internet Explorer depuis sa version 7.0 (sur Vista seulement, pas XP), de Mozilla Firefox depuis sa version 2.0, de Apple Safari depuis sa version 3.2.1 et de toutes les versions de Google Chrome.

Le paquet Apache fournit par Debian est compilé avec le support SNI. Aucune configuration particulière n'est donc nécessaire.

On veillera également à ce que le premier hôte virtuel (celui par défaut) dispose bien d'une configuration autorisant TLSv1 (et donc SSL). En effet, c'est toujours les paramètres du premier hôte virtuel qui sont utilisés pour établir la connexion et il faut qu'ils la permettent !

Le fichier .htaccess contient des directives de configuration d'Apache, prises en compte à chaque fois qu'une requête concerne un élément du répertoire où il est stocké. Sa portée embrasse également les fichiers de toute l'arborescence qui en est issue.

La plupart des directives qu'on peut placer dans un bloc Directory peut également se trouver dans un fichier .htaccess.

Les statistiques d'AWStats sont disponibles sur le site web sans restrictions. On pourra le protéger de manière à ce que seules quelques adresses IP (internes probablement) puissent y accéder. Cela s'effectue en donnant la liste des adresses IP autorisées dans le paramètre AllowAccessFromWebToFollowingIPAddresses

Pour que les statistiques prennent en compte tous les logs, il est impératif qu'AWStats soit invoqué juste avant la rotation des fichiers de logs d'Apache. Si l'on regarde la directive prerotate du fichier /etc/logrotate.d/apache2, on s'aperçoit qu'il suffit pour cela d'ajouter un lien symbolique vers /usr/share/awstats/tools/update.sh dans le répertoire /etc/logrotate.d/httpd-prerotate :

$ cat /etc/logrotate.d/apache2
/var/log/apache2/*.log {
  daily
  missingok
  rotate 14
  compress
  delaycompress
  notifempty
  create 644 root adm
  sharedscripts
  postrotate
    if /etc/init.d/apache2 status > /dev/null  ; then \
      /etc/init.d/apache2 reload > /dev/null ; \
    fi ;
  endscript
  prerotate
    if [ -d /etc/logrotate.d/httpd-prerotate ] ; then \
      run-parts /etc/logrotate.d/httpd-prerotate ; \
    fi ; \
  endscript
}
$ sudo mkdir -p /etc/logrotate.d/httpd-prerotate
$ sudo ln -sf /usr/share/awstats/tools/update.sh \
  /etc/logrotate.d/httpd-prerotate/awstats

Au passage, il est bon de s'assurer que les fichiers de logs mis en place par logrotate soient lisibles par tout le monde (et notamment AWStats). Dans l'exemple ci-dessus, c'est effectivement le cas (voir la ligne create 644 root adm, qui diffère de la valeur 640 utilisée par défaut).