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.

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.
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/.
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.
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:
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.

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.
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.
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
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).
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

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.
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 :