Serveur HTTP Apache 2

Un serveur HTTP permet à un site web de communiquer avec un navigateur en utilisant le protocole HTTP(S) et ses extensions (WebDAV, etc.). Apache est probablement le serveur HTTP le plus populaire. C'est donc lui qui met à disposition la plupart des sites Web du WWW.
Il est produit par la Apache Software Foundation. C'est un logiciel libre fourni sous la licence spécifique Apache.

On utilise généralement Apache en conjonction avec d'autres logiciels, permettant d'interpréter du code et d'accéder à des bases de données. Le cas le plus courant est celui d'un serveur LAMP (Linux Apache MySQL PHP).

Pour installer Apache seul, installez simplement le paquet apache2.

Pour installer Apache avec PHP et MySQL ou MariaDB, reportez vous à l'installation de LAMP.

À la suite de cette installation votre serveur doit fonctionner et être accessible à l'adresse http://localhost (à partir de la même machine).

Un message It Works! devrait s'afficher dans votre navigateur. Il s'agit du contenu du fichier /var/www/html/index.html qui est affiché par défaut.

Apache2 se lance automatiquement dès son installation, et se relance automatiquement à chaque démarrage. C'est l'idéal pour un serveur qui doit continuellement fournir du contenu en ligne, mais pour un serveur de test (on dit de développement) on peut éventuellement désirer un comportement différent.

Pour empêcher cela :

sudo systemctl disable apache2

Pour de nouveau relancer Apache automatiquement au démarrage de la machine, c'est simple :

sudo systemctl enable apache2

• Pour arrêter apache2 : sudo systemctl stop apache2
• Pour lancer apache2 : sudo systemctl start apache2
• Pour relancer apache2 : sudo systemctl restart apache2
• Pour recharger la configuration d'apache2 : sudo systemctl reload apache2
• Pour voir la version d'Apache utilisée : sudo apache2ctl -v ou a2query -v
• Pour tester l'ensemble de la configuration d'Apache : sudo apache2ctl -t
• Pour lister les hôtes virtuels chargés : a2query -s
• Pour lister les hôtes virtuels chargés et leurs configurations : sudo apache2ctl -S
• Pour tester la configuration des hôtes virtuels : sudo apache2ctl -t -D DUMP_VHOSTS
• Pour voir les modules d'Apache chargés : sudo apache2ctl -M ou a2query -m

Lorsqu'il démarre, Apache charge les fichiers de configuration et se met en attente de requêtes sur les interfaces réseaux. On dit qu'il écoute (listen en anglais) certains ports.

Lorsqu'on utilise un navigateur web, que l'on clique sur un lien ou que l'on saisit directement une URL dans la barre d'adresse, on effectue une requête :

• le nom de domaine est résolu en adresse IP
• il envoie une requête à l'adresse IP du serveur sur le port 80 (HTTP) ou 443 (HTTPS) pour lui demander de retourner un contenu particulier
• le serveur HTTP reçoit la requête, et en fonction de divers paramètres (URL appelée, configuration du serveur, etc.), va chercher un contenu dans un fichier ou lance un script qui va générer un contenu
• le serveur renvoie ce contenu à l'adresse IP du navigateur
• le navigateur traite le contenu et le rend accessible à l'internaute (en l'affichant à l'écran par ex.).

Voilà comment fonctionne (grossièrement ) un serveur web.

Un seul serveur Apache permet de déployer simultanément plusieurs sites et services qu'il faut configurer individuellement.
Pour plus de clarté, la configuration d'Apache2 est morcelée. Toutefois, tous les fichiers de configuration se situent dans le répertoire /etc/apache2 :

• sites-available contient les fichiers de configuration des sites disponibles
• sites-enabled contient des liens symboliques vers les configurations, dans site-available, des sites activés

• conf-available contient les fichiers de configuration des autres services disponibles
• conf-enabled contient des liens symboliques vers les configurations, dans conf-available, des autres services activés

• mods-available contient les fichiers de configuration des modules d'Apache disponibles
• mods-enabled contient des liens symboliques vers les configurations, dans mods-available, des modules activés

Les diverses configurations sont activées (a2en pour Apache 2 enable) ou désactivées (a2dis pour Apache 2 disable) avec les commandes suivantes :

sudo a2ensite [configuration d'un site à activer]
sudo a2dissite [configuration d'un site à désactiver]

sudo a2enconf [configuration d'un service à activer]
sudo a2disconf [configuration d'un service à désactiver]

sudo a2enmod [configuration d'un module à activer]
sudo a2dismod [configuration d'un module à désactiver]

Cela aura pour effet de créer ou supprimer les liens symboliques correspondants dans les répertoires xxx-enabled.
Apache prendra alors en compte, ou pas, les fichiers de configuration concernés après rechargement :

sudo systemctl reload apache2

Un dernier fichier, /etc/apache2/ports.conf, permet de spécifier les ports à écouter.
Par défaut, il s'agit des ports 80 (port par défaut pour HTTP), et 443 (port par défaut pour HTTPS) si le module SSL est activé.

Sauf cas très particulier, il n'est pas nécessaire de toucher à cette configuration.

Avec Apache, chaque site ou application web correspond en principe à un hôte virtuel (VirtualHost en anglais).

Chaque hôte virtuel est défini par un fichier de configuration indépendant, qu'on trouve ou qu'on créé dans le répertoire /etc/apache2/sites-available/.

Par défaut, il existe 2 hôtes virtuels.

Le premier VirtualHost est défini dans le fichier /etc/apache2/sites-available/000-default.conf. Voici son contenu sans les commentaires :

000-default.conf

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>

ServerAdmin webmaster@localhost

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

Le second VirtualHost est défini dans le fichier /etc/apache2/sites-available/default-ssl.conf et contient une configuration par défaut pour HTTPS. Il écoute donc sur le port 443 et énonce des directives spécifiques à l'usage de SSL. La racine de l'hôte (directive DocumentRoot) correspond également à /var/www/html.

Apache recommande de créer un fichier de configuration dans lequel est défini un hôte virtuel pour chaque site ou application web dans le répertoire /etc/apache2/sites-available/.

Chaque hôte virtuel peut être appelé en fonction d'un nom de domaine ou sous-domaine, c'est la configuration la plus courante. Mais on peut également définir un numéro de port particulier, ou une adresse IP particulière (si le serveur en possède plusieurs) pour laquelle on affichera tel ou tel contenu web.

Chaque hôte virtuel ayant son fichier de configuration dédié, pour s'y repérer on peut le nommer par le nom de domaine auquel il correspond, suivi de l'extension .conf. Pour un nom de domaine example.com on créera donc un fichier /etc/apache2/sites-available/example.com.conf.

Voici un exemple de contenu pour ce fichier :

example.com.conf

<VirtualHost *:80>
	ServerName example.com
	ServerAlias www.example.com
	DocumentRoot "/var/www/example"
	<Directory "/var/www/example">
		Options +FollowSymLinks
		AllowOverride all
		Require all granted
	</Directory>
	ErrorLog /var/log/apache2/error.example.com.log
	CustomLog /var/log/apache2/access.example.com.log combined
</VirtualHost>

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

DocumentRoot "/var/www/example"

<Directory "/var/www/example">

Options +FollowSymLinks

AllowOverride all

Require all granted

ErrorLog /var/log/apache2/error.example.com.log
CustomLog /var/log/apache2/access.example.com.log combined

Après l'avoir créée, il faut activer cette configuration avec la commande sudo a2ensite [nom du fichier sans son extension]. Par exemple :

sudo a2ensite example.com

On recharge ensuite la configuration d'Apache :

sudo systemctl reload apache2

ping mon-ordi.local

HTTPS permet de chiffrer les communications entre le navigateur et le serveur web au moyen du protocole SSL/TLS, et de garantir l'authenticité de votre serveur au moyen d'un certificat. Cela empêche qui que ce soit de récupérer (« sniffer ») des informations sensibles, telles que des mots de passe, en particulier lorsqu'on se connecte depuis un réseau public, ou empêche un autre serveur de se faire passer pour le vôtre.

Il n'est pas nécessaire de mettre en place HTTPS avec un certificat valide sur un serveur de développement local.

Pour rendre disponible les sites de manière sécurisée via HTTPS avec des certificats valides, la solution la plus simple est d'utiliser l'outil Certbot de Let's Encrypt.

Pour que le protocole TLS (successeur du SSL) puisse fonctionner avec Apache2, il faut activer le module ssl avec la commande :

sudo a2enmod ssl

puis recharger la configuration d'Apache 2 :

sudo systemctl reload apache2

Prérequis :

• avoir un ou plusieurs noms de domaine enregistrés, pointant sur le serveur depuis plus de 48 heures.
• avoir un serveur web apache déjà configuré, fonctionnel et accessible publiquement.

Pour installer Certbot :

sudo apt install python3-certbot-apache

Certbot permet ensuite de générer tous les certificats et d'adapter les configurations d'Apache pour tous les noms de domaine associés aux hôtes virtuels au moyen d'une seule commande :

sudo certbot --apache

Lors de l'opération le script nous invite à cocher les domaines pour lesquels on souhaite obtenir les certificats et à choisir de forcer l'usage de HTTPS ou pas. Pour des raisons de sécurité, c'est généralement une très bonne idée de forcer HTTPS.

Après cette opération les sites devraient être accessibles en HTTPS de manière sécurisée, sans que les navigateurs affichent de message d'alerte.

Pour information c'est la commande certbot renew qui permet de renouveler les certificats très simplement, mais Certbot créé automatiquement une tâche cron à cet effet dans /etc/cron.d/certbot. Il est également créé un « timer » systemd qui fait la même chose (/lib/systemd/system/certbot.timer et certbot.service).

Le script est lancé automatiquement toutes les 12 heures, mais les certificats ne seront renouvelés que si nécessaire. En principe il n'y a donc rien à faire.

En plus des fichiers de configuration situés dans /etc/apache2, Apache nous permet de définir des configurations tierces pour certains répertoires en plaçant des fichiers nommés .htaccess directement avec les autres fichiers du contenu web. (Le point au début du nom du fichier en fait un fichier caché par défaut.)

Les directives de chaque fichier .htaccess s'appliquent au répertoire dans lequel il se trouve, ainsi que tous ses descendants (sous-repertoires, sous-sous-repertoires, etc.).

C'est la directive AllowOverride, spécifiée dans une section <Directory> de l'hôte virtuel qui définit si les fichiers .htaccess doivent être pris en compte, ou pas, pour ce répertoire et ses descendants. Elle peut prendre les valeurs All (on autorises toutes les directives de configuration à être modifiées) ou None (aucune directives), ou une liste détaillée des directives dont on autorise la modifications.

Exemple de protection d'un répertoire et d'un fichier dans ce répertoire :

.htaccess

# la ligne ci-dessous va interdire (forbidden) l'accès au répertoire, mais l'accès à un fichier à la fois du répertoire reste autorisé
RedirectMatch 403 ^/~images/?$
# la ligne ci-dessous va retourner (not found), on peut mettre aussi 403, mais il peut être intéressant que la personne qui tente l'accès (un robot de hacker par exemple) croit que le fichier n'existe pas !
RedirectMatch 404 ^/~images/fichier_à_protéger?$

L'index est le contenu affiché par défaut par Apache lorsqu'on appelle un répertoire sans spécifier de nom de page web particulière.

L'index est définit par la directive DirectoryIndex qui détermine quels fichiers Apache doit traiter par défaut. Chaque nom de fichier est séparé par un espace et listé par ordre de priorité.
Par défaut, DirectoryIndex a la valeur index.html index.cgi index.pl index.php index.xhtml index.htm.

Si Apache ne trouve aucun des fichiers mentionnés par DirectoryIndex, il essaie de récupérer une liste du contenu du répertoire, afin que le navigateur l'affiche de la même manière qu'un gestionnaire de fichier.
On peut activer ou désactiver ce listing avec respectivement les directives Options +Indexes ou Options -Indexes.
Pour des raisons de sécurité, il est généralement préférable de laisser cette option désactivée. Dans ce cas, et faute de fichier index, c'est une erreur 403 qui s'affiche, car l'utilisateur n'a pas la permission de lister le contenu du répertoire.

Il est possible d'ajouter des modules à Apache afin d'étendre les fonctionnalités du serveur web.
Les modules disponibles sont répertoriés ici : /etc/apache2/mods-available

PHP est un langage de programmation qui permet principalement de générer du contenu HTML. C'est donc une solution très largement utilisée pour créer des applications web ou des sites internet dynamiques.

Il est très couramment utilisé en conjonction d'Apache. Voir LAMP.

Le module mod_php fournit un intérpréteur (ou plus exactement une SAPI) PHP intégré à Apache. C'est la méthode la plus simple, mais aussi la moins perfomante, pour utiliser PHP avec Apache.

Une autre méthode consiste à utiliser PHP-FPM. C'est une solution plus performante, plus souple et plus sécurisée, mais plus complexe à mettre en œuvre. Nous ne traiterons pas de ce cas ici.

Pour installer et activer mod_php sous ubuntu, on utilise cette commande :

sudo apt install libapache2-mod-php

Mais encore une fois, mieux vaut vous reporter à la documentation de LAMP à ce sujet.

mod_rewrite permet de réécrire des URL.

Il s'agit généralement de remplacer le chemin, le nom de la page, et la chaîne de requête de l'URL par une chaîne de caractère en concordance avec la structure et le contenu du site.

De nombreux services ont recours à cette pratique afin d'augmenter leur référencement et de clarifier leur contenu.
Ces services utilisent parfois une terminologie exotique pour mentionner cette pratique : WordPress parle par ex. de permalinks.
On peut aussi s'en servir pour déployer une API web propre.
On utilise aussi parfois cette méthode afin de mettre en place des redirections web un peu complexes.

Pour activer ce module on utilisera la commande

sudo a2enmod rewrite

Un petit exemple :

RewriteEngine on

RewriteRule ^page-([0-9]+)$ /page.php?id=$1 [L]

# Lorsque l'on tape dans la barre d'adresse www.example.com/page-* c'est la page www.example.com/page.php?id=* qui s'affiche
# ^ et $ dans le bloc modèle signifient respectivement le début et la fin d'une ligne.
# $1 est une variable qui récupère la valeur entre les premières parenthèses du bloc modèle
# [L]=[last] signifie que si cette règle s'applique on n'en cherche pas d'autre

    <Directory /var/www/html>
            AllowOverride All
    </Directory>

Comme son nom l'indique, mod_proxy permet à apache de relayer des requêtes depuis ou vers un service tiers.

Ce module peut par exemple être utile lorsqu'on utilise d'autres serveurs HTTP en plus d'Apache sur un même serveur web, afin d'éviter d'avoir à accéder au contenu web sur d'autres ports que le port 80 ou 443.

Pour activer ce module :

sudo a2enmod proxy proxy_http proxy_wstunnel
sudo systemctl reload apache2

Voici un exemple de configuration qui permet d'accéder à un serveur emby à l'adresse http://example.com/emby plutôt que http://example.com:8096 :

<Location /emby>
	ProxyPass http://localhost:8096/
	ProxyPassReverse http://localhost:8096/
	Require all granted
	SetEnv proxy-nokeepalive 1
	SetEnv proxy-sendchunked 1
</Location>

Il peut être utile, et c'est prévu par Apache, que chaque utilisateur puisse mettre un contenu web à disposition depuis son espace personnel (dans le répertoire home).
Ce contenu sera accessible à l'adresse http://example.com/~nom_de_lutilisateur, ou dans la plupart des cas : http://localhost/~nom_de_lutilisateur.

Pour mettre cette configuration en place, on crée un répertoire public_html dans son espace personnel et on lui donne les droits de lecture et d'exécution :

mkdir ~/public_html
echo 'Mon site personnel' > ~/public_html/index.html
chmod -R 755 ~/public_html

On active ensuite le module mod_userdir :

sudo a2enmod userdir
sudo systemctl reload apache2

Le message Mon site personnel devrait alors être lisible à l'adresse http://localhost/~nom_de_lutilisateur

Le module headers permet de personnaliser les en-têtes HTTP. C'est à dire les informations envoyées par le serveur avant le document lui-même.

C'est utile notamment pour améliorer la sécurité des sites web. Voici quelques en-têtes qui peuvent être ajoutées à cette fin.

Pour appliquer globalement les directives proposées, ouvrez (ou créez s'il n’existe pas) le fichier /etc/apache2/mods_available/headers.conf et placez-y ceci :

headers.conf

# Cet en-tête empêche MSIE d'interpréter des fichiers comme quelque chose
# d'autre que ce qui est défini en dans que type de contenu dans les en-tes HTTP
#
Header set X-Content-Type-Options: "nosniff"

# Cet en-tête empêchera les autres sites d'intégrer les pages de ce site dans des frames.
# C'est une mesure de protection contre les attaques par détournement de clic (clickjacking)
# Attention cet en-tête est rendue obsolète par les CSP
#
Header set X-Frame-Options: "sameorigin"

# Cet en-tête est obsolète et doit être spécifiquement désactivée avec la valeur O
# Pour une protection XSS, utilisez des CSP empêchant l'exécution des scripts « en ligne »
Header set X-XSS-Protection "0"

# En-tête qui permet de masquer la technologie utilisée (par exemple PHP 7.0)
# Pas une sécurité, mais inutile de transmettre cette information aux clients
#
Header always unset "X-Powered-By"

Vous pouvez ensuite activer le module :

sudo a2enmod headers

et recharger la configuration d'Apache.

Les en-têtes peuvent également être définies au niveau de chaque site dans les fichiers d'hôte virtuels.

Si vous utilisez HTTPS, vous voudrez certainement définir l'en-tête Strict-Transport-Security, exemple :

<VirtualHost *:443>
	…
	Header always set Strict-Transport-Security: "max-age=31536000;includeSubDomains;preload"
</VirtualHost>

Enfin, toujours dans un objectif de sécurité, vous devez utiliser les en-têtes Content-Security-Policy, exemple :

Header always set Content-Security-Policy: "default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com"

Pour voir les en-têtes envoyées par votre serveur vous pouvez utiliser des outils en ligne de commande comme :

curl -I https://example.com

ou une extension du navigateur web qui permet d'afficher les en-têtes HTTP.

Il s'agit d'un pare-feu pour Apache.

Une page de la documentation est consacrée à ce module.

Par défaut sur Ubuntu, Apache est exécuté par l'utilisateur www-data, qui appartient au groupe www-data.
Quand Apache créé un fichier sur l'espace disque (via par exemple un script PHP), celui-ci appartient donc par défaut à l'utilisateur www-data et au groupe www-data. De la même manière, le serveur ne peut accéder qu'au contenu accessible par www-data.

Pour pouvoir facilement éditer les fichiers tout en conservant un bon niveau de sécurité il est recommandé de modifier le propriétaire des fichiers auxquels peut accéder Apache.
Le propriétaire devrait être l'utilisateur qui va maintenir le contenu localement, mais le groupe propriétaire devrait être www-data :²⁾

sudo chown -R $USER:www-data /var/www/example

On change ensuite les permissions du contenu de manière à ce que l'utilisateur puisse le lire et le modifier, mais qu'Apache (dans le groupe www-data) ne puisse que le lire.

On attribue donc les droits rwx r-x --- (750) pour les répertoires, et rw- r-- --- (640) pour les fichiers :

chmod -R a-rwx,u+rwX,g+rX /var/www/example

(pour rappel x concerne les répertoires et les fichiers tandis que X ne concerne que les répertoires - et autorise à les ouvrir)

Si Apache doit pouvoir modifier du contenu (pour un répertoire d'upload par exemple), on ne modifie que la permission concernant le groupe (le second numéro), donc rwx rwx --- (770) pour les répertoires et rw- rw- --- (660) pour les fichiers :

chmod -R g+w /var/www/example/upload

Pour limiter les attaques par force brute sur un système d'authentification d'une application web, il est parfois recommandé d'utiliser l'application Fail2ban.

Si vous utilisez PHP, une page blanche indique très probablement que l'affichage des retours d'erreur sur la page n'est pas activé.

Vous pouvez l'activer en suivant cette documentation.

Une erreur 403 indique un problème d'autorisation.

• Vérifiez les permissions concernant les fichiers du contenu web que vous souhaitez partager vis-à-vis de l'utilisateur et du groupe www-data.
• Vérifiez aussi la valeur de la directive Require : Require all granted pour toujours autoriser l'accès aux ressources.
• Il est aussi possible que cette erreur soit affichée faute de fichier index.

Cette erreur indique que le contenu demandé n'a pas été trouvé.

• En premier lieu vérifiez évidemment l'existence des contenus concernés.
• Le chemin vers ce contenu sur l'espace disque, relatif à la directive DocumentRoot, doit correspondre au chemin de l'URL appelée.
• L'erreur peut aussi être due à une mauvaise réécriture d'URL.

Il s'agit d'une erreur fatale du serveur, qui peut être par exemple liée à une erreur de syntaxe dans un fichier .htaccess.

Consultez le log d'erreur de votre hôte virtuel pour en savoir plus.

Cette erreur indique que le serveur HTTP est dans les choux. Le service existe mais prend apparemment un temps interminable à répondre.

• En premier lieu redémarrez Apache.
• Si le problème se pose toujours, cela peut par exemple être dû au fait qu'un script (par ex. PHP) entre dans une boucle infinie. En plus de surcharger le processeur, ce problème ne générera pas de message d'erreur ce qui en fait malheureusement un problème particulièrement compliqué à débugger. Si votre CMS ou application web utilise un système de cache, vous pouvez essayez de le vider et de le désactiver. Puis essayez de désinstaller les plugins installés récemment, défaire les modifications récentes ou restaurer une sauvegarde de votre application.

Juillet 2024 (sous Ubuntu 24.04) : une erreur de configuration du fichier etc/apache2/mods-enabled/php8.2.load empêche le démarrage d'apache2 et donc l'accès à localhost. Ouvrez ce fichier et lisez la 3e ligne qui renvoie sur le fichier /usr/lib/apache2/modules/libphp8.2.so En fait (chez moi), ce fichier s'appelle désormais libphp8.3.so. Il faut donc corriger la ligne de ce premier fichier avec les Droits de super utilisateur avec le nom correct. L'accès est rétabli.

Cela peut venir du fait que le paquet javascript-common créé un alias global de /javascript vers /usr/share/javascript :

/etc/apache2/conf-available/javascript-common.conf

Alias /javascript /usr/share/javascript/

<Directory "/usr/share/javascript/">
        Options FollowSymLinks MultiViews
</Directory>

La solution est soit de supprimer ce paquet, soit de renommer le répertoire javascript à la racine de l'hôte virtuel, par exemple en js.

• (en) Site officiel du projet Apache
• Documentation Apache officielle en français
• Sécuriser Apache 2 avec SSL
• installer un serveur LAMP
• Serveur LAMP - Créer un/des répertoires de travail
• installer un serveur LAMP avec Docker
• Plusieurs tutoriels sur la configuration d'Apache sur IT-Connect
• discussion au sujet de cette documentation sur le forum : https://forum.ubuntu-fr.org/viewtopic.php?pid=21886288

Contributeurs : — bruno, krodelabestiole, benje, Pepou06, Oxossi, Karting06, albanmartel.