8.3 Sécuriser le serveur Web
8.3.2 Sécuriser le serveur IIS
8.3.3.3 Modification des droits par les rédacteurs : le fichier .htaccess
Le serveur Apache permet au rédacteur de redéfinir la configuration, sans redémarrer le serveur, à l’aide d’un fichier situé dans le répertoire dont le rédacteur veut modifier les possibilités. Ce fichier est fréquemment utilisé pour positionner une limitation d’accès par utilisateur. Avec des droits mal positionnés dans lehttpd.conf il permettrait par exemple à un rédacteur (ou un pirate parvenant à déposer un fichier) de changer le fichier de mot de passe utilisé par le serveur ou d’autoriser l’utilisation de lien symbolique vers d’autres fichiers du disque.
21Par défaut les navigateurs envoient, lorsqu’un lien est cliqué, non seulemement la demande de la page mais aussi, la totalité de la requête précédente qui peut, par exemple, contenir l’identifiant mail d’un visiteur en provenance de sa boite aux lettres
8.3.3.3.1 La directive AllowOverride
La directiveAllowOverridefait partie d’Apache. Cette capacité ne peut donc pas être désactivée.
Il est important d’avoir bien compris la portée des directives selon leur placement par rapport aux différents blocs22 du fichier de configuration.
Elle peut avoir comme valeur :
All : Avec cette valeur presque toute la configuration peut être modifiée (suivis des liens symbo-liques...). Dangereuse pour la sécurité, elle ne devrait pas être utilisée ;
None : L’utilisation de cette valeur devrait être systématiquement utilisée à la racine du serveur Web. Elle interdis toute modification utilisant.htaccess;
AuthConfig : Cette valeur permet la modification des autorisations. Elle ne devrait être position-née qu’à la demande des rédacteurs, dans les blocs définissant les répertoires ou un contrôle d’accès sera nécessaire ;
FileInfo : Cette valeur permet de modifier les différents types de fichiers utiliser par le serveur (ex :ErrorDocument). Elle ne devrait être utilisée qu’avec un grand contrôle ;
Indexes : Cette valeur permet de piloter l’indexation des répertoires mais aussi de changer le nom du fichier recherché par défaut (index.html). Elle ne devrait être positionnée, qu’à la demande des rédacteurs, dans les blocs où l’affichage du contenu du répertoire sera nécessaire et contrôlé ;
Limit : Cette valeur est nécessaire pour gérer les droits afférant aux autorisations. Elle devrait être positionnée à la demande des rédacteurs.
Options :Cette valeur permettrait de positionner n’importe quelle option du serveur comme active comme par exemple : l’exécution de CGI et l’utilisation de liens symboliques. Dangereuse pour la sécurité, elle ne devrait pas être utilisée.
8.3.3.3.2 Le fichier .htaccess
Le nom, par défaut, de ce fichier est.htaccess. Il est défini par la directive : AccessFileName .htaccess
Il est très important que l’accès en soit interdit pour les utilisateurs du serveur Web. D’autre part, l’adresse (http ://servername/RepertoireProtégé/.htaccess) ne doit pas retourner le fichier. Pour cela on utilise la directiveFiles tel que le montre l’exemple. Une modification du nom de fichier par défaut.htaccess pour accroître la sécurité devrait s’accompagner d’une adaptation de la directive Files si son nouveau nom le requière (cf. figure 13).
Remarque : Cet exemple protège aussi contre la divulgation d’un fichier.htpasswd
<Files ~ "^\.ht">
Order allow,deny Deny from all
</Files>
Fig.13 – Protection des fichiers en.ht 8.3.3.4 Démarrer le service
Le serveur Apache peut être démarré en «stand-alone», c’est à dire qu’il est lancé systémati-quement et reste à l’écoute en permanence. Il peut également être lancé par le biais du démon inetd ce qui correspond à un lancement «à la demande du client» du serveur. Pour des raisons de sécurité et de performance un serveur Apache dédié devrait toujours être lancé en «stand-alone».
Ce mode est utilisé en général par défaut. On le vérifie danshttpd.conf (cf. figure 14). :
22exemple : <Directory /> </Directory>
constitue le bloc contenant les commandes valides, sauf redéfinition, pour l’arborescence du site Web depuis la racine
#
# ServerType is either inetd, or standalone.
# Inetd mode is only supported on Unix platforms.
#
ServerType standalone
Fig.14 – définition du type de serveur
8.3.3.5 Suppression des traces permettant d’identifier le serveur Apache
Lors de la création d’une page d’erreur le serveur Apache décline généralement son identité et sa version installée (cf. figure 15).
Fig.15 – Message d’erreur par défaut d’un serveur Apache
La suppression de cette trace présente par défaut se fait par modification, danshttpd.conf (cf.
figure 16).
# Set to one of: On | Off | EMail
#
ServerSignature Off
Fig.16 – Modification des traces
Cette modification ne suffit pas, on peut aussi obtenir des informations en utilisant un telnet sur le port 80 (ou le port utilisé par le serveur Web) (cf. figure 17).
telnet nicolasaudit.internet 80 Trying nicolasaudit.internet...
Connected to adr.ip.server.web Escape character is ’^]’.
HEAD / HTTP/1.0
HTTP/1.1 400 Bad Request
Date: Tue, 22 Oct 2002 12:26:48 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux Connection: close
Fig.17 – Traces obtenues par telnet
La figure 17 laisse clairement apparaître que le serveur Web est un Server : Apache/1.3.26 (Unix) Debian GNU/Linux. La suppression partielle de cette trace, présente par défaut, se fait, par modification, danshttpd.conf.
ServerTokens Prod ATTENTION
– Cette ligne n’existe, en général, pas dans le httpd.conf par défaut, il faut la créer ;
– Cette directive ne fonctionne que sur les serveurs Apache de version supérieure au 1.3.12 (ServerTokens existe depuis la 1.3 mais sans l’option Prod) ;
– Cette directive retire la version du produit mais il reste le nom : Apache.
La seule possibilité d’enlever complètement cette trace est la recompilation du serveur à partir des sources en enlevant les signatures dans include/httpd.h.
#define SERVER_BASEVENDOR " "
#define SERVER_BASEPRODUCT " "
#define SERVER_BASEREVISION " "
8.3.3.6 Les modules
Le fichier httpd.conf est souvent livré avec un grand nombre de modules actifs par défaut.
Mettre un «#» devant la commande LoadModule permet de désactiver les fonctionnalités non nécessaires.
Les modules présentés ci-après nécessitent une attention toute particulière.
autoindex_module crée automatiquement la liste des fichiers présents dans un répertoire en l’absence d’un des fichiers par défaut, tel que index.html.
Fig.18 – Exemple d’index créé automatiquement par Apache
Comme évoqué au 8.3.3.3.1 l’indexation automatique pourrait permettre à un attaquant potentiel de récupérer des informations auxquelles il n’aurait pas dû avoir accès ;
status_module permet d’afficher des informations sur le serveur. Le module est actif par défaut.
Les lignes mettant en place le lien http ://servername/server-status sont, en général, com-mentées ou inexistantes. Laisser le module actif, s’il est inutilisé ne présente aucun intérêt (cf. figure 19).
Apache Server Status for nicolasaudit.internet Server Version: Apache/1.3.26 (Unix) Debian GNU/Linux Server Built: Aug 13 2002 04:37:24
Current Time: Tuesday, 22-Oct-2002 15:22:53 CEST Restart Time: Tuesday, 22-Oct-2002 15:22:51 CEST Parent Server Generation: 0
Server uptime: 2 seconds
Total accesses: 0 - Total Traffic: 0 kB CPU Usage: u0 s0 cu0 cs0
0 requests/sec 0 B/second
-1 requests currently being processed, 4 idle servers Scoreboard Key: http://127.0.0.1/server-status
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"L" Logging, "G" Gracefully finishing, "."
Open slot with no current process
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request 0-0 1120 0/0/0 W 0.00 1 0 0.0 0.00 0.00 127.0.0.1
nicolasaudit.internet GET /server-status HTTP/1.1 Srv Child Server number - generation
PID OS process ID
Acc Number of accesses this connection / this child / this slot M Mode of operation
CPU CPU usage, number of seconds
SS Seconds since beginning of most recent request
Req Milliseconds required to process most recent request Conn Kilobytes transferred this connection
Child Megabytes transferred this child Slot Total megabytes transferred this slot
Apache/1.3.26 Server at nicolasaudit.internet Port 80
Fig.19 – résultat de la requête http ://127.0.0.1/server-status
Les informations présentées dans la figure 19 faciliteraient grandement l’attaque d’un pirate.
userdir_module permet à chaque utilisateur de la machine d’avoir accès à tout ou partie de son répertoire personnel (UserDir public_html par défaut) au travers du serveur Web en utilisant une adresse du type(cf fig. 20) http ://servername/˜user. Le nombre d’utilisateurs devant être réduit au minimum, sur un serveur Web dédié, ce module ne devrait pas rester actif ;
Fig.20 – Exemple d’accès à un répertoire partagé
cgi_module permet l’exécution de scripts sur le serveur. Un paragraphe traite des CGI ultérieu-rement dans ce document (8.3.3.7) ;
auth_module fournit le système d’authentification de base d’Apache. Lorsque ce module est utilisé les identifiants et mots de passe sont stockés et circule en clair. Il est préférable d’utiliser mod_auth_digest.
8.3.3.7 Les CGI
Les CGI sont des programmes exécutés par le serveur. A ce titre ils doivent être l’objet de toutes les attentions. Si l’on ne peut s’en passer il faudrait
– Retirer tous les CGI livrés en exemple ;
– Les stocker hors de l’arborescence des fichiers Web ;
– N’autoriser l’exécution de programme que dans ce répertoire ; – Interdire toute modification de droit Apache dans ce répertoire ;
– Interdire toute modification de droit correspondant à l’exécution de cgi sur la totalité de l’arborescence ;
– Mettre en place une procédure de contrôle et validation de CGI avant leur mise en place sur le serveur Web (plus particulierement sur le filtrage des paramètres transmis par les utilisateurs du site).
La figure 21 présente le chargement du module cgi, son répertoire d’exploitation, les contraintes et restrictions mises sur ce répertoire ainsi que la suppression (par mise en commentaire) des associations23dangereuses.
23handler
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory /usr/lib/cgi-bin/>
AllowOverride None Options ExecCGI Order allow,deny Allow from all
</Directory>
#AddHandler cgi-script .cgi .sh .pl
Fig.21 – Exemple de configuration de CGI
8.3.3.8 Les liens symboliques
Les liens symboliques permettent de rendre visible depuis le serveur Web des fichiers n’en faisant normalement pas partie. Cette fonctionnalité fait partie intégrante d’Apache et n’est donc pas dépendante du chargement d’un module. Il est recommandé de la désactiver :
Options None
L’option "None", désactivant d’autres fonctionnalités en même temps, est en général conseillée pour la configuration globale. Il est possible de ne désactiver que les liens symboliques par : Options -FollowSymbLinks
9 Maintenir le niveau de sécurité : mesures générales
9.1 Règles d’exploitation
Les règles d’exploitation présentées ci-dessous doivent être mises en œuvre pour le serveur Web et étendues à tous les systèmes et composants faisant partie de l’environnement du serveur Web
9.1.1 Gestion des correctifs de sécurité (serveurs et clients)
Quand une mise à jour de sécurité concernant le serveur Web est publiée, les correctifs devraient être identifiés, testés dans un environnement adéquat puis installés sur le système de production si les résultats des tests sont satisfaisants. Un composant devrait toujours être à la dernière version stable de son système d’exploitation et de ses logiciels.
Cependant, l’installation des derniers correctifs nécessite souvent l’utilisation de la dernière version de logiciel ou de système d’exploitation. Cette version n’étant pas forcément compatible avec les logiciels utilisés sur les composants, la recherche d’une solution stable et sécurisée est donc parfois complexe. Il est parfois plus sûr, mais aussi plus long, d’installer la dernière version stable d’un logiciel que d’essayer d’appliquer un correctif sur l’ancienne version existant.
9.1.2 Réalisation de fiches réflexes pour gérer les alertes
Ces fiches réflexes devraient préciser, pour chaque incident possible, les tâches devant être réalisées. Elles permettent une réaction rapide et pertinente des administrateurs à une situation d’urgence. Chacune des tâches unitaires doit être décrite et son déroulement précisé. Du personnel, entraîné à leur utilisation, doit être en astreinte pour permettre une réaction rapide en cas d’alerte.
Ces fiches doivent préciser :
– les modalités de déclenchement d’une alerte ;
– les gestes d’urgence à faire ou ne pas faire (ex : en cas de compromission, il faut débrancher la machine incriminée du réseau mais nepasl’éteindre ) ;
– les personnes à contacter avec une liste de numéro de téléphonetenue à jour;
– la graduation éventuelle des alertes (alarme interne, alerte du FSSI et du HFD, alerte des forces de l’ordre, etc. . .) ;
– quelles informations doivent être fournies dans une alarme pour sa prise en compte (date, heure, constat, adresse IP, modalité de l’attaque, résultat constaté, etc. . .) ;
– une éventuelle chaîne d’escalade en cas de décision importante.
De plus amples informations sont disponibles dans l’avis du CERTA CERTA-2002-INF-002.
9.1.3 Formation
Le personnel devrait être formé à l’administration de son serveur et/ou des applications à sa charge. De plus, un éclairage particulier devrait être apporté sur la sécurité, au niveau du réseau comme au niveau système. En effet, chaque système ou application a ses propres fonctionnalités de sécurité. Une mauvaise configuration d’une de ces fonctionnalités peut compromettre la sécurité de tout le système et par extension du réseau. Une évolution des produits utilisés nécessite une nouvelle formation des administrateurs. Plusieurs personnes doivent être formées pour garantir une disponibilité adéquate.
9.1.4 Gestion des comptes et des mots de passe Des procédures claires devraient exister concernant : – la création de nouveaux comptes ;
– la suppression ou la désactivation de ceux rendus inutiles par le départ d’un utilisateur ; – la modification de tous les mots de passe connus par un administrateur lors de son départ,
d’un changement de fonction, . . .
– la vérification régulière des comptes présents sur le système, et de leur privilèges.
À intervalles réguliers, l’administrateur devrait vérifier la qualité des mots de passe utilisés, s’il y est autorisé par la politique de sécurité du SI, grâce à des outils spécialisés (John The Ripper par exemple).
9.1.5 Serveur de secours et de test
En cas de dysfonctionnement du serveur de production, une solution de secours devrait exister en fonction des besoins de disponibilité du système. Pour un serveur, la solution la plus classique consiste à disposer de matériel de remplacement. Ce matériel doit évoluer de la même manière que le composant qu’il est censé remplacer (même version de système d’exploitation, composants internes cohérents comme mémoire, carte vidéo, capacité disque, logiciels, etc. . .). Une pièce modifiée sur le serveur doit également être changée au plus vite sur le secours. Cette machine de secours doit disposer des mêmes contrats de maintenance que celle de production et être testée périodiquement.
9.1.6 Gestion des sauvegardes
Des procédures de sauvegarde et de récupération des données devraient être formalisées.
Les configurations des serveurs devraient être sauvegardées et les sauvegardes être stockées dans un coffre ignifugé, placé dans des locaux différents de ceux accueillant les serveurs afin d’éviter une destruction de tous les jeux de sauvegarde et du serveur de production en cas d’incendie. Elles doivent bien entendu être mises à jour à chaque modification du serveur. Elles doivent également être périodiquement vérifiées et des restaurations réalisées pour s’assurer du bon fonctionnement des médias de stockage. Elles doivent comporter des sauvegardes des éléments de configuration comme la base de registre.
9.1.7 Gestion des éléments temporaires
Des informations sensibles peuvent avoir été écrites par différents processus dans un réper-toire temporaire. Après utilisation, ces informations ne devraient pas pouvoir être exploitées par d’autres processus, et devraient être supprimées. Les répertoires temporaires doivent donc être apurés périodiquement. Cette opération peut être réalisée au moyen d’un outil comme " at ".
9.2 Mise à jour de la PSSI
La politique de sécurité décrivant les mesures de sécurité et d’administration du serveur doit être maintenue à jour.
L’installation d’un nouveau service doit être précédée d’une mise à jour de la PSSI et la création de fiches réflexes pour tous les incidents pouvant en découler.
9.3 Audits de sécurité
La réalisation d’audits réguliers de la sécurité permet de vérifier l’adéquation entre le niveau de sécurité attendu et celui effectivement réalisé. Ces audits permettent également l’analyse des vulnérabilités résiduelles d’un système d’information, car la configuration des équipements évolue, et des failles apparaissent. Même si la maintenance du réseau est réalisée, elle peut laisser passer un paramètre dangereux, une faille qui ne paraissait pas dangereuse car trop complexe, ou encore une réinstallation de logiciel sans réinstaller les correctifs. . .
Un audit périodique permet donc de prendre du recul et de contrôler le maintien du niveau de sécurité :
– audits réguliers du système via une entité interne ou externe (Bureau Audits en SSI de la DCSSI par exemple) ;
– audits réguliers du système via des scanners de vulnérabilités (exemple : Nessus, ISS. . .) ; – mise en place d’un système de contrôle d’intégrité (exemple : tripwire, . . .).
10 Maintenir la sécurité : mesures spécifiques
10.1 Exploitation des journaux
Une procédure doit expliciter les tâches devant être réalisées en terme d’exploitation des jour-naux. Chacune des tâches unitaires doit être décrite et son déroulement précisé. Cette procédure doit préciser, pour chaque système et application :
– la périodicité de l’analyse des journaux et ses modalités (qui fait quoi, quand, etc. . .) ; – où trouver les journaux à analyser (serveur, station de travail etc. . .) ;
– quelles informations doivent être recherchées (accès successifs refusés, utilisation inhabituelle d’un serveur, journaux des antivirus, des caches HTTP, FTP, etc. . .). À noter qu’il existe des produits permettant une analyse semi-automatisée de tels journaux simplifiant grandement leur dépouillement ;
L’usage de fichiers journaux tournants24est d’un grand intérêt pour la disponibilité du serveur. Il n’est, en effet, pas nécessaire dans ce cas de gérer la saturation du disque où sont stockés les journaux, disque dédié de préférence, et les exceptions qui en découlent. Ce dispositif est par contre attaquable par saturation : les traces réelles de l’attaque pourront être masquées par des messages sans valeur. Il convient donc de sauvegarder les journaux avant de les ré-écraser.
10.2 Réaliser une veille technologique sur les éléments du réseau
Tous les composants techniques ont eu, parfois ont encore, et auront des failles. Il importe donc d’être à l’écoute d’organismes comme le CERTA qui alertent lors de l’apparition de nouvelles failles25:
– www.certa.ssi.gouv.fr;
– www.cert.orget www.cert.org/current/current_activity.html.
Il est bon de rappeler que le maintien du niveau de sécurité du serveur Web est dépendant du maintien de niveau de sécurité de son contenu. La correction rapide des failles des applications et un contrôle constant du contenu du serveur est nécessaire mais non suffisant à la sécurité du serveur.
Microsoft propose deux utilitaires permettant de vérifier qu’une ou un ensemble de machines possèdent bien les dernières mises à jour :
– HFNetCheck (ligne de commande) :
(http ://www.microsoft.com/downloads/release.asp ?release=31154) ; – Microsoft Baseline Security Analyser (interface graphique)
De plus, un autre outil (QFEcheck) permet de déterminer les correctifs effectivement appliqués à une machine.
Le CERTA(http ://www.certa.ssi.gouv.fr/index.html) propose ses avis sur les vulnérabilités Apache (en Français) ainsi que le lien sur l’avis de sécurité Apache (en Anglais).
Le site Web d’Apache (http ://httpd.apache.org) propose un suivit des vulnérabilités (en An-glais) :http ://httpd.apache.org/security_report.htmlLe lien «download» depuis l’accueil du site permet d’accéder aux patchs (http ://www.apache.org/dist/httpd/patches/) (utilisés seulement pour les bugs mineursAttention ces patchs ne sont que des patchs à appliquer aux sources et né-cessitent donc une recompilation du serveur) et à la dernière version stable sous forme exécutable.
10.3 Autres paragraphes . . .
24Le fichier journal a toujours la même taille et s’auto-écrase si nécessaire.
25Il serait souhaitable d’aviser préalablement le CERTA des choix de configuration qui ont été faits en terme de système d’exploitation, logiciels, etc., pour que le CERTA puisse cibler sa veille en fonction des produits les plus représentatifs.
Glossaire
CERTA : Centre d’Expertise gouvernemental de Réponse et de Traitement des Attaques informa-tiques
DCSSI : Direction Centrale de la Sécurité des Systèmes d’Information FSSI : Fonctionnaire de la Sécurité des Systèmes d’Information FTP : File Transfer Protocol
HFD : Haut Fonctionnaire de Défense HTTP : HyperText Transfer Protocol
PSSI : Politique de Sécurité des Systèmes d’Information SGDN : Secrétariat Général de la Défense Nationale SI :Système d’Information ,
access.log, 34 administration, 41 alerte, 41
applicatif téléchargé, 16 applications, 13
Arrêt ou dysfonctionnement du service Web, 8
maintenir le niveau de sécurité : mesures gé-nérales, 41
maintenir le niveau de sécurité : mesures spé-cifiques, 43