Mise à jour du 12/12/2021.
Le serveur Apache (2ème génération) est un serveur multi-thread résilient et extrêmement performant qui bénéficie aujourd'hui d'une longue expérience. Il s'exécute sur des milliers de sites UNIX, Linux ou Windows. Il est en source libre et il est donc accessible gratuitement.
L'installation du serveur web Apache est simple grâce au le gestionnaire de paquets Debian. Il suffit de taper la commande apt install apache2.
A l'issue de l'installation, le serveur Apache est opérationnel. Vous pouvez le vérifier via la commande curl http://localhost ou, si curl n'est pas installé en saisissant l'URL du site dans un navigateur distant : http://192.168.0.10/
La configuration fournie par défaut est satisfaisante. Nous allons cependant limiter l'information délivrée par le serveur dans l'en-tête de sa réponse HTTP et dans la signature qu'il affiche lors de la production de certaines pages comme les pages d'erreur. Pour cela, il nous faut ouvrir le fichier /etc/apache2/conf-enabled/security.conf et modifier les directives qui suivent pour leurs affecter les valeurs :
ServerTokens Prod
ServerSignature Off
Le "client" distant saura qu'il s'agit d'un serveur Apache mais sans connaitre ni sa version, ni le système d'exploitation qui le supporte (contrairement à ce que propose la configuration par défaut).
Nous avons besoin d'accéder au serveur web avec deux noms d'hôtes différent :
Pour parvenir à ces fins, nous devons déjà paramétrer correctement le DNS. La machine elle-même est repérée par un enregistrement de type A :
A poste 192.168.0.10 # remplacez l'adresse IP par celle d'accès à l'Internet
Nous créons ensuite un série d'alias :
CNAME mail poste.piapp.fr. CNAME smtp mail.piapp.fr. CNAME imap mail.piapp.fr. CNAME pop mail.piapp.fr. CNAME www poste.piapp.fr.
Nous créons ensuite l'enregistrement de type MX pour déclarer le serveur de messagerie du domaine :
MX @ 10 mail.piapp.fr
Notez que 10 fixe le niveau de priorité du serveur de messagerie. Plus ce nombre est faible, plus importante est la priorité du serveur. Cela est surtout utile lorsqu'il existe plusieurs serveurs pour assurer la tolérance aux pannes.
Avec ces enregistrements, www.piapp.fr et mail.piapp.frpointe sur la même machine d'adresse IP 192.168.0.10.
Grâce à la configuration du DNS, on dispose de deux hôtes qui référence la même machine : www.piapp.fr et mail.piapp.fr. Pour permettre au serveur Apache de s'orienter vers des sites différents, nous allons mettre en œuvre la technique dite des "hôtes virtuels". Cette technique permet d'attribuer un site à l'hôte www.piapp.fr et un autre à l'hôte mail.piapp.fr.
Cela se fait au moyen du fichier /etc/apache2/sites-enabled/000-default.conf. En voici le contenu :
<VirtualHost *:80>
ServerName www.piapp.fr
ServerAdmin admin@piapp.fr
DocumentRoot /var/www/html
LogLevel info
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# Redirect permanent / https://www.piapp.fr
</VirtualHost>
<VirtualHost *:80>
ServerName mail.piapp.fr
ServerAdmin admin@piapp.fr
DocumentRoot /var/www/mail
LogLevel info
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# Redirect permanent / https://mail.piapp.fr
</VirtualHost>Commencez par mettre sur /var/www/html et /var/www/maildes fichiers index.html différents. Ces modifications faites, relancez le serveur Apache et testez au moyen d'un navigateur l'accès à http://www.piapp.fr puis à http://mail.piapp.fr. Si vous avez déposé sur les répertoires de chaque hôte virtuels des fichiers index.html différents, vous devez effectivement afficher des pages différentes.
Avec la distribution Debian, le plus simple pour installer et renouveler automatiquement le certificat du serveur est l'emploi du client ACME (Automated Certicate Management Environment) certbot. Ce client existe dans le référentiel des paquets Debian.
Il faut auparavant installer le paquet cerbotet le plugin certbot-apache via le paquet python3-certbot-apache. Ceci peut être fait en une fois grâce à la commande :
apt install certbot python3-certbot-apache
Lancez alors la commande :
certbot --apache
et créez un certificat pour les domaines www.piapp.fr et mail.piapp.fr. Notez que ce certificat sera également utilisé pour lae serveur de messagerie postfix afin de chiffrer le transport.Le certificat installé a une durée de 90 jours.
La commande certbot --apache ne fait pas que créer le certificat, elle créé également un fichier de configuration pour les hôtes virtuels SSL correspondant à chacun des domaines ainsi qu'un déclencheur lancé par le planificateur cron en vue de renouveler si nécessaire le certificat. Ce déclencheur est placé dans le fichier /etc/cron.d/certbot.
Voici ce que présente la commande cerbot --apache lorsque le certificat pour les deux domaines www.piapp.fr et mail.piapp.fr ont déjà été demandés :
Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: mail.piapp.fr 2: www..piapp.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel): 1,2 Requesting a certificate for mail.piapp.fr and www.piapp.fr Performing the following challenges: http-01 challenge for www.piapp.fr Enabled Apache rewrite module Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache socache_shmcb module Enabled Apache ssl module Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache rewrite module Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://mail.piapp.fr and https://www.piapp.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/mail.piapp.fr/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/mail.piapp.fr/privkey.pem Your certificate will expire on 2022-03-14. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
La commande commence par identifier tous les alias IP locaux qui correspondent à l'adresse IP de la machine et ajoute celui nommé www. Elle propose ensuite de spécifier le ou les alias IP sur lesquels porteront le certificat. Ici nous avons choisi les deux alias IP listés. Elle produit alors un "challenge" pour chaque alias et vérifie via le DNS du domaine et le serveur Apache qu'il est possible d'accéder au challenge. Si tel est le cas, ce dernier est vérifié. A la moindre erreur, le processus s'interrompt et le certificat n'est pas créé.
La commande systemctl list-timers permet de vérifier les instants de déclenchement des commandes inscrites dans le planificateur dont celle liée au renouvellement du certificat lorsqu'il arrive à échéance.
Vous pouvez tester le renouvellement du certificat via la commande certbot renew --dry-run.
Les certificats, leur chaîne et la clef privée sont stockés sous /etc/letsencrypt/live/$domain. Il s'agit en fait de liens symboliques sur les derniers fichiers renouvelés que l'on trouve sous /etc/letsencrypt/archive/$domain.
L'utilisation du protocole HTTPS doit désormais être considérée comme obligatoire. Il faut forcer les navigateurs modernes pour qu'ils acceptent de prendre en compte le protocole HTTP non chiffré.
Pour activer le protocole HTTPS, il faut commencer par activer le module mod_ssl qui permet de gérer le protocole HTTPS. Cela se fait grâce à la commande :
a2enmod ssl
Ceci fait, le module HTTPS est activé mais il ne lui correspond aucun site virtuel. Comme pour le protocole HTTP, nous devons créer des hôtes virtuels pour chacune des adresses d'hôte. Nous commençons par renommer le fichier livré par la commande certbot(sur /etc/apache2/sites-enabled) en /etc/apache2/sites-enabled/000-ssl.conf. Ce ficher accueille les deux hôtes virtuels SSL
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName mail.piapp.fr
ServerAdmin admin@piapp.fr
DocumentRoot /var/www/mail
LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/letsencrypt/live/mail.piapp.fr-0001/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.piapp.fr-0001/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName www.piapp.fr
ServerAdmin admin@piapp.fr
DocumentRoot /var/www/html
LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/letsencrypt/live/mail.piapp.fr-0001/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.piapp.fr-0001/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>La vérification de la configuration du serveur Apache peut être effectuée au moyen de la commande apachectl configtest
Ces modifications faites, relancez le serveur Apache et testez au moyen d'un navigateur l'accès à https://www.piapp.fr puis à https://mail.piapp.fr. Si vous avez déposé sur les répertoires de chaque hôte virtuels des fichiers index.htmldifférents, vous devez effectivement afficher des pages différentes. Notez que le certificat est valide pour ces deux hôtes virtuels.
Le blocage du port 80 (HTTP) par le pare-feu pose deux types de problèmes :
Plutôt que de bloquer ce port, il est plus efficace de rediriger ses requêtes vers le port 443 (HTTPS). Pour cela, vous devez suivre la procédure :
Redirect permanent / https://{www|mail}.piapp.frCes lignes sont commentées dans la présentation ci-dessus des hôtes virtuels non chiffrés. Vous devez ensuite redémarrer le serveur Apache via la commande :
systemctl restart apache2
Testez ensuite que les URL http://www.piapp.fr:80/et http://mail.piapp.fr:80/ vous redirigent vers le port HTTPS de leur hôte respectif.
Un URL constitué des chemins d'un répertoire situé sous la racine du site provoque l'affichage du contenu de ce répertoire. En soi, cela n'est pas très grave mais cette capacité à lister les répertoires donne la structure de l'arborescence de la partie "statique" de votre serveur Apache et peut présenter un risque sérieux de sécurité. Cela peut faciliter le travail d'un éventuel pirate à la recherche de failles connues sur certains fichiers ou types de fichier. S'en prémunir en interdisant le parcours des répertoires est facile.
Ouvrez le fichier /etc/apache2/apache2.conf. Recherchez le jeu de balises :
<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory>
Supprimer alors dans la ligne Options Indexes FollowSymLinks le mot Indexes.
Un grand nombre d'URL demandés au serveur ne sont ne fait que des tests ou des attaques plus ou moins discrètes. Comme la plupart de ces attaques sont liées à des logiciels disponibles sur Internet, on retrouve à quelques variantes près, les mêms URL ou les mêmes signatures. Vous pouvez les filtrer de plusieurs manières :
Le module mod_rewrite> n'est pas activé par défaut et nous devons commencé par le faire :
sudo a2enmod rewrite sudo systemctl restart apache2
En fin de fichier /etc/apache2/apache2.conf ajouter les règles portant sur les URL à filtrer. Par exemple pour filtrer les URL qui commencent par a= :
<Location />
RewriteEngine On
RewriteCond "%{QUERY_STRING}" "^a="
RewriteRule ".*" - [F]
</Location>Vous pouvez tester la configuration d'Apache avant de le redémarrer : apachetl configtest. Si tout est correct, relancez Apache via la commande sudo systemctl restart apache2.
Si nous rencontrons d'autres URL "non conformes", il sera facile d'ajouter de nouvelles règles sur le même principe.
Le module mod-security peut être vu comme un pare-feu applicatif. L'installation de ce module se fait via la commande :
apt install libapache2-mod-security
L'installation par défaut active le module mais ce dernier est quasiment inactif. Commençons par renommer le fichier /etc/modsecurity/modsecurity.conf-recommended :
mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Par défaut le paramètre SecRuleEngine a la valeur DetectionOnlyNous recommendons de laisser ce mode dans un premier temps. Il permet de tracer les requêtes indésirables dans le fichier /var/log/apache2/modsec_audit.log sans effectuer d'autres actions. Cela permet de vérifier durant quelques temps que les "règles" ne filtrent pas des URL autorisés.
L'OWASP. L'Open Worldwide Application Security Project (OWASP) et une fondation à but non lucratif qui vise à améliorer la sécurité des logiciels dont celle du serveur Apache. Cet organisme recense les URL "agressives" et propose des jeux de règles pour les filtrer.
En fait le jeu de règles repose sur le module mod-security vu précédemment mais dans une version supérieure :
apt install libapache2-mod-security2
Il faut ensuite recopier le fichier du jeu de règles pour en fair la configuration active :
cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Par défaut le paramètre SecRuleEngine de ce fichier a la valeur DetectionOnly ; il fait le modifier pour on.
Une fois ces installations et configuration effectuées, il est facile de tester le filtrage via un URL du type /index.html?exec=/bin/bash. Cela doit retourner une erreur 403 :
root~# curl http://localhost/index.html?exec=/bin/bash <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN" > <html> <head> <title>403 Forbidden </title> </head> <body> <h1>Forbidden </h1> <p>You don't have permission to access this resource. </p> </body> </html>
Au cours de l'évolution d'un site, il pourra être nécessaire d'interdire l'accès à un répertoire du site sauf si l'utilisateur est en mesure de se connecter avec identificateur et mot de passe.
Apache propose depuis longtemps une solution de ce type. Comme nous imposons SSL, l'authentification pourra se faire de manière "basique", c'est à dire en envoyant le mot de passe en clair puisque ce dernier sera chiffré par SSL au cours de son transport. Nous partirons du principe que les modules standards de la version Debian son actifs (en particulier mod_auth_basic, mod_authz_user et mod_authn_file). Voici la procédure à suivre :
Création du fichier de stockage des identificateurs et mots de passe des utilisateurs : /etc/apache2/.htpasswd grâce à la commande :
htpasswd -c /etc/apache2/.htpasswd
Ajout d'un utilisateur (par exemple toto) :
htpasswd /etc/apache2/.htpasswd toto
Modification de la directive AllowOverride None par AllowOverride All dans la balise <Directory /var/www>dans le fichier /etc/apache2/apache2.conf :
<Directory /var/www /> Options FollowSymLinks AllowOverride All Require all granted </Directory>
Redémarrage du serveur Apache :
systemctl restart apche2
Créez un fichier .htaccess sur la racine du répertoire à protéger.
Ouvrez ce fichier et enregistrez :
AuthType Basic AuthName "Authentification requise" Require valid-user AuthUserFile /etc/apache2/.htpasswd
Refaites cette opération pour chaque répertoire à protéger. Si vous devez avoir des utilisateurs différents pour différents répertoires, dissociez les fichiers de mots de passe.
Rédaction par Jean-Marie Piatte (1983-2021)