Sécuriser Apache    

Modules d’Apache

Le choix des modules est une des plus importantes étapes de la sécurisation d’Apache. Règle d’or : le moins possible sera le mieux. Pour mettre en place la fonctionnalité et nos hypothèses de sécurité, les modules suivants doivent être activés :

httpd_core
Noyau de base d’Apache. Indispensable à toutes les installations.

mod_access
Contrôle d’accès sur une base d’hôte, IP, ou d’autres caractéristiques que le client demande. Parce que ce module est nécessaire pour utiliser les options "order", "allow" et "deny", il devrait rester activer.

mod_auth
Il permet une authentification des utilisateurs sur la base de fichiers texte (HTTP Basic Authentication).

mod_dir
Permet de choisir "l’index" prioritaire du serveur : index.html, default.html, etc...

mod_log_config
Permet de loguer les requêtes envoyées au serveur.

mod_mime
Ce module permet à Apache de déterminer le type de contenu des fichiers à partir de leur extension.

Tous les autres modules d’Apache doivent être désactivés. Nous pouvons les désactiver sans risque, car nous n’avons pas besoin d’eux. En désactivant les modules inutiles, nous évitons les intrusions potentielles lorsque de nouvelles vulnérabilités sont découvertes dans l’un d’entre eux.

Notons que 2 des modules d’Apache peuvent être plus dangereux que d’autres : "mod_autoindex" et "mod_info". Le premier contient le listage de répertoires automatique, et est activé par défaut. Il est très facile d’utiliser ce module dans le but de vérifier sur quel type de serveur tourne Apache (exemple : http://server_name/icons/) et d’obtenir le contenu du répertoire, quand aucun fichier index n’existe. Le second module, mod_info, ne devrait jamais être accessible depuis l’Internet, essentiellement car il donne des informations sur la configuration du serveur Apache.

Comment compiler les modules ? La méthode statique semble être le meilleur choix. Si de nouvelles vulnérabilités sont découvertes, nous recompilerons probablement, non pas juste les modules vulnérables ; mais le logiciel en entier. En choisissant le mode statique, nous éliminons le besoin d’un nouveau module.

Compilation du logiciel

Avant toutes choses, vérifiez s’il existe des patchs à appliquer. Ensuite, le serveur devrait être compilé et installé comme suit :

La prochaine étape va servir à limiter l’accès aux process d’Apache des fichiers systèmes. Nous pouvons faire ça en chrootant le service principal (httpd). Généralement, la technique du "chrooting" veut dire qu’il faut créer un nouveau répertoire avec les accès root, déplacer tous les fichiers des services dans ce dossier, et faire tourner le propre service dans ce nouvel emplacement. Grâce à ça, le service (et ses process) aura seulement accès à la nouvelle structure du répertoire racine.

Nous commencerons ce process en créant un nouveau répertoire avec les accès root par le chemin /chroot/httpd :

Le possesseur de tous ces dossiers doit être le root, et les droits d’accès doivent être de 0755. Créons le fichier dispositif spécial : /dev/null/

Une méthode différente doit être utilisée pour créer un dispositif /chroot/httpd/dev/log, qui est aussi nécessaire pour que le serveur travaille correctement. Dans le cas de l’OS FreeBSD, la ligne suivante doit être ajoutée à /etc/rc.conf :

Nous devons relancer le systeme ou le service syslogd afin que les changements prennent effet. Pour creer un autre dispositif chroot/httpd/dev/log sur d’autres systèmes d’exploitation, nous devrions jeter un coup d’oeil aux manuels (man syslogd).

La prochaine étape va être de copier le programme principal httpd dans le nouveau chemin avec tous les fichiers binaires et les librairies nécessaires. Pour cela, nous devons faire une liste de tous les fichiers requis. Nous pouvons faire cette liste en utilisant les commandes suivantes (leur existence dépend du système d’exploitation) :

ldd - Tous les OS Listes des dépendances dynamique des fichiers exécutables ou des bibliothèques partagées.
ktrace/ktruss/kdump BSD - Active le traçage par le kernel des process, affiche le traçage des données par le kernel.
sotruss Solaris - Les traces d’appels de procédures de libraires partagées
strace/ltrace Linux - Trace les appels systèmes et les signaux.
strings Tous les OS - Trouve les chaînes imprimables dans les fichiers binaires.
trace AIX - Enregistre les évènements system sélectionnés
trace (gratuit) HP-UX <10.20> 11 - Trace les appels systèmes que le process invoque dans HP-UX 11.

Exemples de l’utilisation de "ldd", les commandes "strings" et "truss" sont ci-dessous :

Les commandes ci-dessus ne devraient pas être appliquées qu’au programme httpd, mais aussi à toutes les librairies et les fichiers binaires requis (les librairies requièrent souvent d’autres librairies). Dans le cas de FreeBSD, les fichiers suivants sont à copier dans la nouvelle structure du répertoire racine :

En utilisant la commande "truss" nous pouvons aussi découvrir que la configuration des fichiers suivants doit être présente dans l’environnement chrooté :

Notez que dans /chroot/httpd/etc/passwords nous avons enlevé toutes les lignes exceptées "nobody" et "apache". De la même façon, nous devons enlever toutes les lignes sauf "apache" et "nogroup" dans /chroot/httpd/etc/group. Ensuite, nous allons créer le mot de passe de la base de données :

La prochaine étape est de tester si le serveur httpd tourne correctement dans le nouvel environnement chrooté. Pour cela, nous allons copier les fichiers de configuration d’Apache par défaut et copier index.html :

Après la copie des fichiers mentionnés ci-dessus, nous devons changer le DocumentRoot comme suit (dans /chroot/httpd/usr/local/apache/conf/httpd.conf)

Ensuite, essayons de lancer le serveur :

Si un problème se produit, je vous recommande d’analyser les fichiers log d’Apache (chroot/httpd/usr/local/apache/logs). Alternativement, les commandes suivantes peuvent être utilisées :

truss chroot /chroot/httpd /usr/local/apache/bin/httpd
Le programme truss devrait montrer la cause du problème. Après avoir éliminer les éventuelles erreurs, nous pouvons configurer le serveur Apache.

Configuration d’Apache

La première étape est de retirer le fichier /chroot/httpd/usr/local/apache/conf/httpd.conf et d’en créer un nouveau à sa place, avec un contenu similaire à celui-ci :

La configuration ci-dessus inclues seulement les commandes qui sont nécessaires aux "fonctionnalités" et aux "hypothèses de sécurité". Dans la configuration présentée, il y a 2 hôtes virtuels supportés par le serveur Web :

– www.ebank.lab (www.e-bank.lab)
– www.test.lab

Le contenu de ces sites est physiquement présent dans les répertoires suivants :

Chaque site web a son propre système de fichiers logs, présents dans les répertoires suivants :

Ces répertoires doivent être créé avant le premier lancement du serveur Apache - autrement Apache ne tournera pas correctement. Le possesseur de ces répertoires devra être le root:sys, et les droits initialisé à 0755.

Comparé avec les fichiers de configuration par défaut de Apache, les changements suivant sont à constatés :

– Le nombre de modules actif a considérablement baissé.
– Apache ne doit pas révéler quelle version est utilisée.
– Les process d’Apache (sauf le process root) sont fait pour être exécutés juste avec les privilèges user/group.
– Apache permettra l’accès seulement aux répertoires, sous-répertoires et fichiers qui sont explicitement spécifiés dans le fichier de configuration (Directory, Allow) ; toutes les autres requêtes doivent être rejetées.
– Apache logue plus d’informations sur les requêtes HTTP qu’auparavant.

Dernière étape

Créons un script de lancement "apache.sh", le contenu doit ressembler à celui-ci :

Ce script devrait être copié dans le répertoire de démarrage (tout dépend du système UNIX utilisé), où par défaut les scripts de lancement sont placés. Dans le cas de FreeBSD, c’est le répertoire /usr/local/etc/rc.d
En résumé

La méthode présentée permet d’arriver à un certain niveau de sécurité du serveur Apache que la configuration par défaut n’offre pas.

Merci d’activer simplement les modules nécessaires d’Apache. La découverte d’une vulnérabilité dans les serveurs Apache ne veut pas forcément dire que notre serveur est vulnérable. Cacher la version du serveur utilisé, désactiver l’auto-indexation, chrooter et restreindre la configuration, fera de votre Apache un serveur difficile à pénétrer. Un environnement chrooté a aussi encore un avantage important : l’immunité face à un grand nombre d’exploits, principalement à cause de la non-présence de shells (bin/sh, /bin/csh etc...). Même si un intrus arrivait à exécuter des commandes systèmes, quitter l’environnement chroot peut résoudre le problème.

Le serveur...
Vivons heureux, vivons caché !

Il est très facile de découvrir quel serveur tourne sur un site web comme le montre l’exemple suivant :

Un pirate apprend que le serveur Apache tourne sous une distribution RedHat et que les langages Perl et PHP sont actifs. On limite la divulgation d’information en insérant dans le fichier de configuration, /etc/httpd/conf/httpd.conf pour une RedHat, la ligne ServerTokens Prod. Ainsi, la bannière Server : Apache/1.3.14 (Unix) (Red-Hat/Linux) PHP/4.0.3pl1 mod_perl/1.24 se limite à Server : Apache. Cette option n’apparaît pas toujours dans le fichier de configuration (enfin, c’est le cas pour ma RedHat et ma Mandrake...), alors ajoutez-la rapidement.

Cela ne suffit toujours pas à masquer la version d’Apache : si vous demandez une page inexistante, Apache renvoie une page d’erreur 404 avec en bas de la page, le message Apache/1.3.14 Server at www.mon-serveur.org Port 80 qui révèle la version du serveur d’Apache. Pour empêcher cela, il faut désactiver l’insertion de la signature du serveur avec la commande ServerSignature Off. Utiliser ErrorDocument 404 /missing.html pour définir votre propre page d’erreur 404.
Limitations contre les DoS

De façon à limiter la portée des attaques de type Denial of Service, il est conseillé de limiter le nombre de connexions simultanées MaxClients et en particulier le nombre de connexions persistantes MaxKeepAliveRequests. Celles-ci sont apparues avec la norme HTTP 1.1. Elles permettent d’effectuer des requêtes successives lors de la même connexion, ce qui augmente les performances du serveur. L’utilisation d’un timeout empêche les connexions sans fin.

Exemple pour un petit serveur :

Bien définir un virtual host

Apache permet la définition de Virtual Host, c’est-à-dire que le même serveur peut héberger, y compris sur une même adresse IP, plusieurs sites différenciés par leur nom. Pour limiter les risques liés à une panne des serveurs DNS ou à des manipulations frauduleuses, il convient de définir le VirtualHost par une adresse IP puis de préciser son nom.

Gérer ses fichiers de log

Apache permet de définir ses propres formats LogFormat pour les enregistrements dans les fichiers de log.

Ensuite, on enregistre les informations de log précisées par le format dans le fichier de son choix
CustomLog /var/log/httpd/access_log common.

Suivant l’utilisation de ces fichiers de logs (reporting,...), il peut être intéressant de faire apparaître le nom des machines se connectant au serveur web au lieu de leur adresse IP : HostnameLookups On active la résolution inverse.

Gestion des droits

Nous présenterons ici les mesures préventives liées aux fichiers contenus dans l’arborescence du serveur web.
Directory, Files, Location

La gestion des accès est effectuée par le module mod_access. On manipule principalement trois catégories d’objets :

Directory désigne un répertoire du serveur ;
Location une arborescence du serveur web ;
Files un fichier.

.

Voici un exemple un peu farfelu extrait du manuel d’Apache, qui autorise la consultation du répertoire /docroot aux personnes utilisant le brower KnockKnock/2.0. Si vous voulez restreindre la consultation d’une partie de votre site aux personnes n’utilisant pas I.E., vous n’aurez pas trop de difficultés = :-)

Mesure défensive

Plus sérieusement, il est fortement conseillé de tout interdire par défaut :

Ensuite, il ne reste qu’à valider l’accès aux répertoires correspondant aux sites

Order indique dans quel ordre les directives deny et allow sont évaluées. Deny from all interdit l’accès depuis partout. On aurait pu indiquer un nom de machine, un nom de domaine, une adresse IP, un couple IP/masque de réseau.

Options, AllowOverride

Options contrôle

le suivi des liens symboliques FollowSymLinks/SymLinksIfOwnerMatch ;
l’exécution des scripts CGI ExecCGI ;
les Server Side Includes Includes et IncludesNOEXEC ;
la génération de pages d’index Indexes en l’absence de celles-ci ;
ainsi que l’orientation multilingue MultiViews.

All regroupe les différentes options sauf MultiViews, None supprime les options.

MultiViews redirige une demande pour index.html vers index.html.en ou index.html.fr selon la préférence signalée par le navigateur au serveur web.

Il est important d’être le plus restrictif possible par défaut, je conseille de n’autoriser que le suivi des liens symboliques où liens et destinations ont le même propriétaire :

Un pirate pouvant écrire dans un répertoire du serveur web, par exemple via un partage NFS, peut en profiter pour accéder au fichier /etc/passwd via un lien symbolique si l’option FollowSymLinks est présente, Includes ou ExecCGI permet d’exécuter des programmes... En un mot, soyez prudent.

La directive AllowOverride peut prendre n’importe quel paramètre qu’aurait pris Options.

Protection par mot de passe

Le module mod_auth permet de protéger l’accès à un répertoire par mot de passe. En pratique, c’est souvent utiliser pour filtrer les accès à un sous-répertoires d’une page personnelle.

ou pour bloquer l’accès à un répertoire déterminé

Dans le cas des pages personnelles /home/*/public_html des utilisateurs, l’accès est déterminé par un fichier .htaccess que peut utiliser ou non un utilisateur, le nom du fichier même est défini dans la section générale de la configuration du serveur. Ce fichier protége l’accès au répertoire dans lequel il est placé ainsi que l’accès aux sous-répertoires. AllowOverride AuthConfig permet à ce fichier d’être pris en compte. Par précaution, il faut empêcher un utilisateur de les récupérer via le web :

AccessFileName .htaccess

Order deny,allow
Deny from all

Si on veut pouvoir définir explicitement des exceptions pour les fichiers .htpipo par exemple, il faut spécifier l’ordre allow puis deny pour que l’autorisation prime sur l’interdiction.

Le fichier .htaccess contient les mêmes champs que pour le répertoire /private de l’exemple, c’est-à-dire un nom qui apparaîtra sur la fenêtre de demande d’identification (AuthName), la méthode d’identification (AuthType), le fichier de mot de passe (AuthUserFile) et enfin require valid-user :

AuthName "my restricted stuff"
AuthType Basic
AuthUserFile "/home/titi/.htpasswd"
require valid-user

... et ses modules

Le serveur Apache s’articule sur un ensemble de modules qu’il convient de restreindre au strict nécessaire.

Server Side Includes : mod_include

Les SSI ont déjà été présentés lors du sixième article sur la programmation sécurisée. Il s’agit d’un vestige de l’époque où les Perl et PHP n’avaient pas encore fait leurs apparitions. Il est fortement conseillé de le supprimé ou de ne l’activé qu’avec prudence Options +IncludesNOEXEC ou Options +Includes.

Perl : mod_perl

Le module mod_perl a été le résultat d’une intégration plus poussée des scripts CGI écrits en Perl. Il permet de meilleures performances qu’un script CGI classique. En terme de sécurité, il présente des risques identiques.

PHP : mod_php

PHP a été conçu spécifiquement pour la programmation web en tenant compte d’impératif de sécurité. Il est grandement paramétrable. Il est conseillé de définir les options suivantes dans son fichier de configuration /etc/php.ini. safe_mode surveille les fichiers accédés et interdit l’usage de commande à risque, expose_php contrôle l’affichage de sa banner, max_execution_time et memory_limit limite les risques de DoS, magic_quotes_gpc ajoute des quotes pour les données reçues des GET/POST et des cookies. Enfin, souvent oublié en production, il faut éviter l’affichage des lignes fautives lorsque les scripts PHP plantent.

CGI

Il faut limiter leur présence à des répertoires bien déterminés, ils sont alors autorisés par un Options +ExecCGI sur la base d’un répertoire particulier.

Répertoires des utilisateurs : mod_userdir

Les utilisateurs du serveur peuvent bien souvent publier leurs pages dans leur répertoire public_html, configuré via le paramètre UserDir public_html. De façon à éviter une mauvaise surprise, root n’est pas autorisé à faire de même : UserDir disabled root.

Directory listing : mod_dir, mod_autoindex

La directive DirectoryIndex définit les pages d’index souvent index.html ou index.php3 et en l’absence de celle-ci, le module mod_autoindex en génère une si l’option Indexes est présente. Les index peuvent aider un pirate à découvrir d’anciennes versions de script, un backup du site ou d’autres documents sensibles.

Users et users

Le serveur web est lancé par l’utilisateur root ce qui lui permet d’utiliser le port privilégié 80, ensuite il prend l’identité d’un utilisateur sans pouvoir apache ou nobody.

Le problème est que les scripts s’exécutent tous avec le même id (i.e. le même propriétaire). En conséquence, ils peuvent interférer entre eux. Le programme suexec permet d’utiliser des User/Group différents pour chaque virtual host de façon à séparer les utilisateurs. En contrepartie, un pirate disposant du compte apache est capable d’utiliser ce programme pour corrompre d’autres comptes, c’est pour cela qu’il n’est pas actif par défaut. Il faut lire très attentivement la documentation.

Il est déjà compilé sur une RedHat mais pas forcément activé, il suffit alors d’un chmod u+s /usr/sbin/suexec pour le rendre actif.

ls -l /usr/sbin/suexec
– r-s—x--- 1 root apache 10976 Mar 29 19:52 /usr/sbin/suexec

# httpd -l
Compiled-in modules :
http_core.c
mod_so.c
suexec : enabled ; valid wrapper /usr/sbin/suexec

Conclusion

J’espère vous avoir donné suffisamment d’éléments pour sécuriser votre serveur Apache, sinon n’hésitez pas à consulter le manuel : si vous avez des difficultés à vous y retrouver, un grep peut vous aider.