Il est tres facile de decouvrir quel serveur tourne sur un ordinateur comme le montre l'exemple suivant :
Un pirate apprend que le serveur Apache tourne sous une distribution Debian et que le langage PHP est actif.On limite la divulgation d'information en inserant dans le fichier de configuration, //httpd.conf, la ligne "ServerTokens Prod". Ainsi, la banniere
Cela ne suffit toujours pas a masquer la version d'Apache : si on demande une page inexistante, Apache renvoie une page d'erreur 404 avec en bas de la page, le message
qui revele la version du serveur d'Apache. Pour empecher cela, il faut qu'on desactive l'insertion de la signature du serveur avec la commande
Utiliser ErrorDocument
pour definir notre propre page d'erreur 404.
De facon a limiter la portee des attaques de type Denial of Service, il est conseille de limiter le nombre de connexions simultanees "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 requetes successives lors de la meme connexion, ce qui augmente les performances du serveur. L'utilisation d'un timeout empeche les connexions sans fin.
Apache permet la definition de Virtual Host, c'est-a-dire que le meme serveur peut heberger, y compris sur une meme adresse IP, plusieurs sites differencies par leur nom. Pour limiter les risques lies a une panne des serveurs DNS ou a des manipulations frauduleuses, il convient de definir le VirtualHost par une adresse IP puis de preciser son nom.
Apache permet de definir ses propres formats "LogFormat" pour les enregistrements dans les
fichiers de log.
Ensuite, on enregistre les informations de log precisees par le format dans le fichier de son choix
active la resolution inverse.
Nous presenterons ici les mesures preventives liees aux fichiers contenus dans l'arborescence
du serveur web.Directory, Files, Location.
La gestion des acces est effectuee par le module mod_access. On manipule principalement trois
categories d'objets :
* Directory designe un repertoire du serveur ;
* Location une arborescence du serveur web ;
* Files un fichier.
Il est fortement conseille de tout interdire par defaut, ce qu'on fait :
Ensuite, il ne reste qu'a valider l'acces aux repertoires correspondant aux sites
"Order" indique dans quel ordre les directives "deny" et "allow" sont evaluees.
"Deny from all" interdit l'acces depuis partout. On aurait pu indiquer un nom de machine,
un nom de domaine, une adresse IP, un couple IP/masque de reseau.
Options, "AllowOverride"
"All" regroupe les differentes options sauf MultiViews,
"None" supprime les options.
"MultiViews" redirige une demande pour index.html vers index.html.en ou index.html.fr selon la
preference signalee par le navigateur au serveur web.
Il est important d'etre le plus restrictif possible par defaut, je conseille de n'autoriser que
le suivi des liens symboliques ou liens et destinations ont le meme proprietaire :
Un pirate pouvant ecrire dans un repertoire du serveur web, par exemple via un partage NFS, peut en profiter pour acceder au fichier /etc/passwd via un lien symbolique si l'option FollowSymLinks est presente, Includes ou ExecCGI permet d'executer des programmes... En un mot, soyons prudent.
La directive AllowOverride peut prendre n'importe quel parametre qu'aurait pris Options. Protection par mot de passe
Le module mod_auth permet de proteger l'acces a un repertoire par mot de passe. En pratique, c'est souvent utiliser pour filtrer les acces a un sous-repertoires d'une page personnelle.
ou pour bloquer l'acces a un repertoire determine
Dans le cas des pages personnelles /home/*/public_html des utilisateurs, l'acces est determine
par un fichier .htaccess que peut utiliser ou non un utilisateur, le nom du fichier meme est
defini dans la section generale de la configuration du serveur. Ce fichier protege l'acces au
repertoire dans lequel il est place ainsi que l'acces aux sous-repertoires.
AllowOverride AuthConfig permet a ce fichier d'etre pris en compte. Par precaution,
il faut empecher un utilisateur de les recuperer via le web :
Si on veut pouvoir definir explicitement des exceptions pour les fichiers .htpipo par exemple,
il faut specifier l'ordre allow puis deny pour que l'autorisation prime sur l'interdiction.
Le fichier .htaccess contient les memes champs que pour le repertoire /private de l'exemple,
c'est-a-dire un nom qui apparaitra sur la fenetre de demande d'identification (AuthName),
la methode d'identification (AuthType), le fichier de mot de passe (AuthUserFile) et enfin
require valid-user :
Le serveur Apache s'articule sur un ensemble de modules qu'il convient de restreindre au strict necessaire.
Les SSI sont un vestige de l'epoque ou les Perl et PHP n'avaient pas encore fait leurs apparitions. Il est fortement conseille de le supprimer ou de ne l'activer qu'avec prudence
Le module mod_perl a ete le resultat d'une integration plus poussee des scripts CGI ecrits en Perl. Il permet de meilleures performances qu'un script CGI classique. En terme de securite, il presente des risques identiques.
PHP a ete concu specifiquement pour la programmation web en tenant compte d'imperatif de securite. Il est grandement parametrable. Il est conseille de definir les options suivantes dans son fichier de configuration /etc/php.ini. safe_mode surveille les fichiers accedes et interdit l'usage de commande a risque, expose_php controle l'affichage de sa banner, max_execution_time et memory_limit limite les risques de DoS, magic_quotes_gpc ajoute des quotes pour les donnees recues des GET/POST et des cookies. Enfin, souvent oublie en production, il faut eviter l'affichage des lignes fautives lorsque les scripts PHP plantent.
Il faut limiter leur presence a des repertoires bien determines, ils sont alors autorises par une Options +ExecCGI sur la base d'un repertoire particulier.
Les utilisateurs du serveur peuvent bien souvent publier leurs pages dans leur repertoire public_html, configure via le parametre UserDir public_html. De facon a eviter une mauvaise surprise, root n'est pas autorise a faire de meme : UserDir disabled root. Directory listing : mod_dir, mod_autoindex
La directive DirectoryIndex definit les pages d'index souvent index.html ou index.php3 et en l'absence de celle-ci, le module mod_autoindex en genere une si l'option Indexes est presente. Les index peuvent aider un pirate a decouvrir d'anciennes versions de script, un backup du site ou d'autres documents sensibles.
Le serveur web est lance par l'utilisateur root ce qui lui permet d'utiliser le port privilegie 80, ensuite il prend l'identite d'un utilisateur sans pouvoir apache ou nobody.
Le probleme est que les scripts s'executent tous avec le meme id (i.e. le meme proprietaire).
En consequence, ils peuvent interferer entre eux. Le programme suexec permet d'utiliser des
User/Group differents pour chaque virtual host de facon a separer 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 defaut.
Pour le rendre actif, il suffit alors d'un: