La mauvaise configuration des outils Internet

S'abonner :

Newsletters

Magazines

01men.

Le guide des mauvaises pratiques de sécurité (et leurs solutions)

[ LE GUIDE DES MAUVAISES PRATIQUES DE SÉCURITÉ ]
La mauvaise configuration des outils Internet
Faciles à installer, parfois même préinstallés, les serveurs Web, les caches et autres serveurs de noms sont rapidement opérationnels, mais fragilisés quand ils sont configurés par les entreprises elles-mêmes. Conseils pour un déploiement sécurisé.

Jérôme Saiz , Décision Informatique (n° 592), le 14/06/2004 à 07h00

Comment des serveurs web peuvent-ils être piratés quelques minutes après leur déploiement ? Comment des spammeurs peuvent-ils exploiter à distance la messagerie d'une entreprise pour envoyer plusieurs dizaines de milliers de courriers publicitaires par jour ? Simplement grâce à la mauvaise configuration de ces outils réseau, mis en ligne rapidement et parfois avec un manque de compétences.

Les scripts par défaut sont facilement piratés

Les serveurs web les plus populaires, Apache et IIS, sont livrés en série avec leur système d'exploitation, et ils peuvent être opérationnels quelques instants seulement après leur installation. Mais cette configuration par défaut est souvent loin d'être la plus sûre [lire précédemment, « La sécurité sortie de la boîte », NDLR].

« Pendant très longtemps, il était facile de pirater un serveur IIS en utilisant les failles de certains scripts installés par défaut », explique Aurélien Cabezon, d'iSecurelabs. Ces scripts, par exemple, ne servent à rien et ne sont là, dans le meilleur des cas, qu'à titre d'exemple de programmation (tel le fameux site Internet de démonstration de IIS). Mais peu d'administrateurs pensent à les effacer. Et la même chose existe avec Linux, lorsque des distributions installent par défaut Apache et des programmes CGI, tel le Webmail FormMail, dont certaines versions sont réputées pour leur insécurité chronique.

L'absence de contrôle d'accès est tentante

Plus grave : lorsque ces outils sont déployés au sein d'un intranet, ils n'offrent généralement aucune méthode de contrôle d'accès sérieuse (.htaccess ou une authentification LDAP), et sont rarement mis à jour. Les entreprises éprouvent un faux sentiment de sécurité vis-à-vis de ces serveurs situés sur leur LAN : tant que l'intranet fonctionne, pourquoi chercher à en limiter les accès ?

Cette situation est une aubaine pour les employés un peu curieux ou mécontents, capables d'obtenir très facilement le contrôle du serveur en exploitant une faille connue, une configuration trop permissive par défaut ou l'absence de contrôle d'accès.

Bien configurer les outils Internet Apache

Les risques d'une installation par défaut d'Apache concernent essentiellement les permissions des répertoires (suivi des liens symboliques, exécution de scripts et affichage de la liste des répertoires). Pour limiter ces risques, il convient de :

Restreindre totalement le site, et n'ouvrir ensuite que les répertoires dans lesquels le contenu Web doit être accessible. Cela se définit dans le fichier /etc./httpd.conf, grâce aux options FollowSymlinks et AllowOverride, aux alias de répertoires et, éventuellement, en définissant des hôtes virtuels. Très bien commenté, le fichier permet également de limiter l'accès du serveur Web à certaines adresses IP (utile pour un intranet, même si cela ne doit pas remplacer une vraie méthode de contrôle d'accès).

Contrôler les modules : Apache peut intégrer de nombreux modules (SSL, PHP...) qui disposent de leurs propres fichiers de configuration. Si l'administrateur oublie ces derniers, il laissera dans son serveur Web des modules inutiles (gestion du XML ou du PDF, par exemple), sources de failles potentielles. En outre, PHP se configure à l'aide d'un fichier externe (php.ini), et de nombreux réglages de sécurité doivent y être modifiés (notamment l'utilisation du « safe mode » , et la désactivation des variables globales).

IIS 5

À défaut d'utiliser la version 6 du serveur Web de Microsoft, plus sûre, les administrateurs de la version 5 peuvent sécuriser leur installation en quelques étapes simples :

Effacer tous les scripts et exemples fournis par défaut (\inetpub\isssamples et \inetpub\AdminScripts).

Retirer tous les protocoles autres que TCP/IP sur le serveur (notamment NetBios).

Retirer les accès aux répertoires de IIS aux groupes « Tout le monde » et « Invité » , ainsi qu'au compte utilisateur « Invité » .

Stopper les services qui ne sont pas nécessaires (souvent NNTP, SMTP et parfois FTP).

Ressources : L'agence de renseignement américaine NSA a publié un guide pour l'installation et la sécurisation de IIS, disponible à l'adresse suivante :

http://nsa2.www.conxion.com/win2k/guides/w2k-14.pdf

Microsoft propose un outil destiné à verrouiller une installation de IIS 5, en retirant les services et fichiers inutiles :

http://www.microsoft.com/technet/Security/tools/locktool.mspx

Bind

Le serveur de noms de domaine le plus répandu sur Internet demande une attention toute particulière, tant les failles sont nombreuses dans certaines versions. Il convient donc d'utiliser de préférence la toute dernière version (Bind9) et de s'assurer :

Que les transferts de zones ne soient autorisés qu'à partir des hôtes reconnus.

Que seules les machines esclaves (dédiées à la gestion de zones différentes) puissent accéder au serveur par le port TCP 53.

Que des listes de contrôle d'accès (ACL) soient définies, afin de contrôler l'accès au serveur (en bloquant par exemple l'accès aux clients qui prétendent venir de réseaux « impossibles » ,tels que 0.0.0/8 ; 1.0.0.0/8 ; 2.0.0.0/8 ; 192.0.2.0/24 ; 224.0.0.0/3 ; 10.0.0.0/8 ; 172.16.0.0/12 ; 192.168.0.0/16.

Que les mises à jour dynamiques (Dynamic Update) ne soient pas autorisées uniquement sur la foi d'une adresse IP (trop facile à usurper), mais exigent plutôt le recours aux transactions signées (TSIG).