Product SiteDocumentation Site

11.2. Serveur web (HTTP)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Buster at version 2.4.38.

ALTERNATIVE Autres serveurs web

Apache n'est que le plus connu et le plus répandu des serveurs web, mais il en existe d'autres, qui peuvent offrir de meilleures performances dans certains cas d'usage, le plus souvent au détriment de la quantité de fonctions et modules disponibles. Lorsqu'il s'agit de servir des fichiers statiques, ou d'agir en serveur mandataire (proxy), il est judicieux de s'intéresser à ces alternatives, parmi lesquelles on peut citer Nginx et lighttpd.

11.2.1. Installation d'Apache

Installing the apache2 package is all that is needed. It contains all the modules, including the Multi-Processing Modules (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate apache2-mpm-* packages. It will also pull apache2-utils containing the command line utilities that we will discover later.
Le module MPM employé définit la manière dont Apache traite les requêtes entrantes. Avec le MPM worker il utilise des threads (processus légers), alors qu'avec le MPM prefork il utilise un ensemble de processus créés par avance. Avec le MPM event il utilise également des threads, mais les connexions inactives (notamment celle gardées ouvertes par la fonctionnalité keep-alive du protocole HTTP) sont rendues à un thread dédié à leur gestion.
The Falcot administrators also install libapache2-mod-php7.3 so as to include the PHP support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php7.3-fpm.

SÉCURITÉ Exécution sous l'utilisateur www-data

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.
Using the suexec modules, provided by apache2-suexec-* packages, allows bypassing this rule so that some CGI scripts are executed under the identity of another user. This is configured with a SuexecUserGroup usergroup directive in the Apache configuration.
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.

DÉCOUVERTE Liste des modules

The full list of Apache standard modules can be found online.
→ https://httpd.apache.org/docs/2.4/mod/index.html
Apache est un serveur modulaire et la plupart des fonctionnalités sont implémentées dans des modules externes que le programme charge pendant son initialisation. La configuration par défaut n'active que les modules les plus courants et les plus utiles. Mais la commande a2enmod module permet d'activer un nouveau module tandis que a2dismod module le désactive. Ces deux programmes ne font rien d'autre que créer ou supprimer des liens symboliques dans /etc/apache2/mods-enabled/ pointant vers des fichiers de /etc/apache2/mods-available/.

IN PRACTICE Checking the configuration

The mod_info module (a2enmod info) allows to access the comprehensive Apache server configuration and information via browser visiting http://localhost/server-info. Because it might contain sensitive information, access is only allowed from the local host by default.
→ https://httpd.apache.org/docs/2.4/mod/mod_info.html
Par défaut, le serveur web écoute sur le port 80 (configuré dans /etc/apache2/ports.conf) et renvoie les pages web depuis le répertoire /var/www/html/ (configuré dans /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Adding support for SSL

Apache 2.4 includes the SSL module (mod_ssl) required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with a2enmod ssl, then the required directives have to be added to the configuration files. A configuration example is provided in /etc/apache2/sites-available/default-ssl.conf.
→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html
If you want to generate trusted certificates, you can follow section Section 10.2.1, « Creating gratis trusted certificates » and then adjust the following variables: 
SSLCertificateFile      /etc/letsencrypt/live/DOMAIN/fullchain.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/DOMAIN/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem
SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt
Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromission of the server's secret key does not result in the compromission of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:
→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache
As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls.
→ https://mod.gnutls.org/

11.2.3. Configuration d'hôtes virtuels

Un hôte virtuel est une identité (supplémentaire) assumée par le serveur web.
Apache distingue deux types d'hôtes virtuels : ceux qui se basent sur l'adresse IP (ou le port) et ceux qui reposent sur le nom DNS du serveur web. La première méthode nécessite une adresse IP différente pour chaque site tandis que la seconde n'emploie qu'une adresse IP et différencie les sites par le nom d'hôte communiqué par le client HTTP (ce qui ne fonctionne qu'avec la version 1.1 du protocole HTTP, heureusement déjà employée par tous les navigateurs web).
La rareté (de plus en plus pressante) des adresses IPv4 fait en général privilégier cette deuxième méthode. Elle est cependant complexifiée si chacun des hôtes virtuels a besoin de HTTPS : le protocole SSL n'a pas toujours permis ce fonctionnement et l'extension SNI (Server Name Indication) qui le rend possible n'est pas connue de tous les navigateurs. Si plusieurs sites HTTPS doivent fonctionner sur un même serveur, on préférera donc les différencier soit par leur port, soit par leur adresse IP (en utilisant éventuellement IPv6).
La configuration par défaut d'Apache 2 exploite les hôtes virtuels basés sur le nom. De plus, un hôte virtuel par défaut a été défini dans le fichier /etc/apache2/sites-enabled/000-default.conf. Cet hôte virtuel sera employé si aucun autre hôte virtuel ne correspond à la requête du client.

ATTENTION Premier hôte virtuel

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.

DÉCOUVERTE Apache prend en charge SNI

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.
Chaque hôte virtuel supplémentaire est ensuite décrit par un fichier placé dans le répertoire /etc/apache2/sites-available/. Ainsi, la mise en place du domaine falcot.org se résume à créer le fichier ci-dessous, puis à l'activer avec a2ensite www.falcot.org.

Exemple 11.13. Fichier /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80>
ServerName   www.falcot.org
ServerAlias  falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>
Le serveur Apache est ici configuré pour n'utiliser qu'un seul fichier de log pour tous les hôtes virtuels (ce qu'on pourrait changer en intégrant des directives CustomLog dans les définitions des hôtes virtuels). Il est donc nécessaire de personnaliser le format de ce fichier pour y intégrer le nom de l'hôte virtuel. Pour cela, on ajoutera un fichier /etc/apache2/conf-available/customlog.conf définissant un nouveau format (directive LogFormat) et on l'activera avec a2enconf customlog. Il faut également supprimer (ou passer en commentaire) la ligne CustomLog du fichier /etc/apache2/sites-available/000-default.conf.

Exemple 11.14. The /etc/apache2/conf-available/customlog.conf file

# Nouveau format de log avec nom de l'hôte virtuel (vhost)
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# On emploie le format vhost en standard
CustomLog /var/log/apache2/access.log vhost

11.2.4. Directives courantes

Cette section passe brièvement en revue quelques-unes des directives de configuration d'Apache les plus usitées.
Le fichier de configuration principal contient habituellement plusieurs blocs Directory destinés à paramétrer le comportement du serveur en fonction de l'emplacement du fichier servi. À l'intérieur de ce bloc, on trouve généralement les directives Options et AllowOverride.

Exemple 11.15. Bloc Directory

<Directory /srv/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>
La directive DirectoryIndex précise la liste des fichiers à essayer pour répondre à une requête sur un répertoire. Le premier fichier existant est appelé pour générer la réponse.
La directive Options est suivie d'une liste d'options à activer. None désactive toutes les options. Inversement, All les active toutes sauf MultiViews. Voici les options existantes :
  • ExecCGI indicates that CGI scripts can be executed.
  • FollowSymlinks tells the server that symbolic links can be followed, and that the response should contain the contents of the target of such links.
  • SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and the its target have the same owner.
  • Includes enables Server Side Includes (SSI for short). These are directives embedded in HTML pages and executed on the fly for each request.
  • IncludesNOEXEC allows Server Side Includes (SSI) but disables the exec command and limits the include directive to text/markup files.
  • Indexes tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the DirectoryIndex directive exists in this directory).
  • MultiViews enables content negotiation; this can be used by the server to return a web page matching the preferred language as configured in the browser.

B.A.-BA Fichier .htaccess

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.
La directive AllowOverride donne toutes les options qu'on peut activer ou désactiver par l'intermédiaire d'un fichier .htaccess. Il est souvent important de contrôler l'option ExecCGI pour rester maître des utilisateurs autorisés à exécuter un programme au sein du serveur web (sous l'identifiant www-data).

11.2.4.1. Requérir une authentification

Il est parfois nécessaire de restreindre l'accès à une partie d'un site. Les utilisateurs légitimes doivent alors fournir un identifiant et un mot de passe pour accéder à son contenu.

Exemple 11.16. Fichier .htaccess requérant une authentification

Require valid-user
AuthName "Répertoire privé"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-prive

SÉCURITÉ Aucune sécurité

Ce système d'authentification (Basic) a une sécurité très faible puisque les mots de passe circulent sans protection (ils sont uniquement codés en base64 — un simple encodage et non pas un procédé de chiffrement). Il faut noter que les documents protégés par ce mécanisme circulent également de manière non chiffrée. Si la sécurité vous importe, faites appel à SSL pour chiffrer toute la connexion HTTP.
The /etc/apache2/authfiles/htpasswd-private file contains a list of users and passwords; it is commonly manipulated with the htpasswd command. For example, the following command is used to add a user or change their password: 
# htpasswd /etc/apache2/authfiles/htpasswd-prive utilisateur
New password:
Re-type new password:
Adding password for user utilisateur

11.2.4.2. Restrictions d'accès

The Require directive controls access restrictions for a directory (and its subdirectories, recursively).
→ https://httpd.apache.org/docs/2.4/howto/access.html
Cette directive peut être utilisée pour restreindre les accès suivant de nombreux critères. Les restrictions d'accès basées sur les adresses IP du client sont décrites plus loin mais cette directive est bien plus puissante, tout particulièrement lorsque plusieurs directives Require sont combinées dans un bloc RequireAll.

Exemple 11.17. Uniquement autoriser le réseau local

Require ip 192.168.0.0/16

ALTERNATIVE Ancienne syntaxe

The Require syntax is only available in Apache 2.4 (the version shipped since Jessie). For users of Wheezy, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the mod_access_compat module.
Les directives Allow from et Deny from contrôlent les restrictions d'accès à un répertoire (et ses sous-répertoires).
La directive Order indique dans quel ordre évaluer les directives Allow from et Deny from (et la dernière qui s'applique est retenue). Concrètement, Order deny,allow autorise l'accès si aucune des règles Deny from ne s'applique ou si une des règles Allow from s'applique. Inversement, Order allow,deny refuse l'accès si aucune directive Allow from ne l'autorise (ou si une directive Deny from s'applique).
Les directives Allow from et Deny from peuvent être suivies d'une adresse IP, d'un réseau (exemples : 192.168.0.0/255.255.255.0, 192.168.0.0/24 et même 192.168.0), d'un nom de machine ou de domaine, ou du mot-clé all désignant tout le monde.
Par exemple, pour interdire les connexions par défaut mais les autoriser depuis le réseau local, il est possible d'utiliser : 
Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.5. Analyseur de logs

L'analyseur de logs est un compagnon fréquent du serveur web puisqu'il permet aux administrateurs d'avoir une idée plus précise de l'usage fait de ce service.
Les administrateurs de Falcot SA ont retenu AWStats (Advanced Web Statistics, ou statistiques web avancées) pour analyser les fichiers de logs d'Apache.
La première étape de la configuration consiste à créer le fichier /etc/awstats/awstats.conf. Les administrateurs de Falcot n'ont modifié que les différents paramètres donnés ci-dessous : 
LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
SiteDomain="www.falcot.com"
HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"
DNSLookup=1
LoadPlugin="tooltips"
Tous ces paramètres sont documentés par commentaires dans le fichier modèle. LogFile et LogFormat indiquent l'emplacement du fichier de log et les informations qu'il contient. Les paramètres SiteDomain et HostAliases indiquent les différents noms associés au site web principal.
Pour les sites à fort trafic, il est déconseillé de positionner DNSLookup à 1 comme dans l'exemple précédent. En revanche, pour les petits sites, ce réglage permet d'avoir des rapports plus lisibles qui emploient les noms complets des machines plutôt que leurs adresses IP.

SÉCURITÉ Accès aux statistiques

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
On activera AWStats pour d'autres hôtes virtuels, en créant un fichier spécifique par hôte, par exemple /etc/awstats/awstats.www.falcot.org.conf.

Exemple 11.18. Fichier de configuration AWStats pour un hôte virtuel

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"
AWStats emploie de nombreuses icônes stockées dans le répertoire /usr/share/awstats/icon/. Pour les rendre disponibles sur le site web, il faut modifier la configuration d'Apache et y ajouter la directive suivante : 
Alias /awstats-icon/ /usr/share/awstats/icon/
Après quelques minutes (et les premières exécutions du script), le résultat est accessible en ligne :
→ http://www.falcot.com/cgi-bin/awstats.pl
→ http://www.falcot.org/cgi-bin/awstats.pl

ATTENTION Rotation de logs

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 invoke-rc.d apache2 status > /dev/null 2>&1; then \
      invoke-rc.d apache2 reload > /dev/null 2>&1; \
    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).