Tcp_wrapper, ou cachez cet ordinateur que je ne saurais voir

Table des matières

• TCP_WRAPPER, un filtre pour les démons sous le contrôle d'inetd
• Contrôle d'accès pour X Window
• Démon HTTP

Même si vous avez appliqué les recommandations concernant le choix de votre mot de passe et la protection des données transitant sur le réseau ­ cf. le dernier FI,

il reste encore une grande classe de risques de piratage informatique à craindre. Il s'agit des failles dans les contrôles d'accès de l'un des démons offrant des services réseau sur votre machine (sendmail pour le courrier électronique, ftpd, telnetd ou rshd pour l'exécution de commandes interactives à distance, httpd pour les requêtes d'information WWW, etc). Ces démons sont souvent d'une telle complexité qu'il n'est pas étonnant qu'on trouve de temps à autre un bug ou un défaut de conception exploité ou exploitable par les pirates informatiques pour pénétrer sur les ordinateurs exécutant les programmes en question.

Malheureusement, ce risque de piratage est multiplié parce que, par défaut, ces démons sont disposés à accepter des requêtes provenant de n'importe où sur Internet, d'Anchorage à Zanzibar. Dans certains cas, ceci est tout à fait naturel: l'ouverture de WWW et des sites FTP anonymes sont les éléments essentiels du charme d'Internet. Mais par ailleurs, le principe de sécurité informatique du besoin d'usage (need to use en anglais) met en question une telle ouverture du service telnetd, par exemple. L'idéal serait bien sûr de pouvoir contrôler les accès, plus ou moins ouverts, individuellement pour chaque type de service. Le bon endroit où installer un tel filtre se trouve naturellement dans les couches les plus basses du kernel qui traitent les paquets arrivant de l'interface réseau. C'est ce que peut faire par exemple Linux: l'option CONFIG_IP_FIREWALL du kernel configurant une machine comme coupe-feu (firewall en anglais) entre deux réseaux peut servir également, dans le cas d'un ordinateur courant ne disposant que d'une interface réseau, à faire de cette machine son propre coupe-feu: elle peut décider quels paquets son kernel transmettra aux applications, et ainsi, quels services réseau elle est prête à rendre à quels clients.

Malheureusement, cette possibilité n'est pas généralement disponible sur les stations de travail les plus courantes à l'EPFL, et il incombe à l'administrateur de vérifier pour chaque démon particulier quelles en sont les possibilités de contrôle d'accès, de les mettre en vigueur et d'espérer qu'elles sont dépourvues de failles. Avant de donner des pointeurs vers l'information nécessaire pour effectuer ce travail pour deux services particulièrement importants (X Window et les démons HTTP), je vais parler d'un logiciel permettant le contrôle d'accès pour les démons TCP démarrés par inetd.

TCP_WRAPPER, un filtre pour les démons sous le contrôle d'inetd

Mon compatriote Wietse Venema

de l'Université d'Eindhoven, a mis au point une solution partielle, applicable aux démons TCP lancés par inetd. Rappelons qu'inetd (l'internet daemon) centralise la distribution du travail entre les démons offrant les services réseaux les plus courants (ftp, telnet, rlogin, rsh). Il écoute aux ports correspondants à ces démons (et aux autres définis dans son fichier de configuration, inetd.conf) et les active dès qu'une machine sur le réseau requiert leurs services. Le principe de tcp_wrapper est d'intercepter cette activation pour effectuer un contrôle d'accès basé sur l'adresse IP de la machine effectuant la requête. tcp_wrapper vérifie si les règles d'accès énoncées par l'administrateur de la machine et stockées dans un fichier de configuration permettent que cette requête soit traitée. Si c'est le cas, tcp_wrapper active le démon concerné comme inetd l'aurait fait. L'avantage de ce système réside dans sa grande souplesse et dans le fait qu'il n'y a pas besoin de changer quoi que ce soit aux démons pour implémenter cette procédure de filtrage.

Je recommande donc d'installer tcp_wrapper sur votre ordinateur

Vous pouvez également profiter de cette installation pour vérifier si vous utilisez effectivement tous les démons listés dans le fichier de configuration /etc/inetd.conf et de retirer ceux qui sont inutiles: si vous n'en avez pas besoin, les seuls qui pourraient en profiter sont les pirates.

Pour conclure, je rappelle qu'à l'EPFL, les procédures d'installation du système d'exploitation des stations de travail SUN incluent d'office tcp_wrapper. Le format des fichiers de configuration est alors légèrement différent de celui utilisé par la version du logiciel distribué sur Nestor (pour SUN, voir les pages du manuel host_access(5) décrivant les fichiers de configuration /etc/inet/hosts.allow et /etc/inet/hosts.deny; la version de Nestor utilise le fichier /usr/local/etc/hosts.allow décrit sous hosts_options (5)). De même, les machines HP offrent un service analogue décrit dans les pages du manuel inetd.sec(4).

Contrôle d'accès pour X Window

Dans ce cas, il faut préférer le système basé sur les fichiers .Xauthority à celui offert par la commande xhost. Deux bons pointeurs discutant de l'utilisation de ces fichiers et de la sécurisation de votre serveur X:

Rappelons brièvement qu'un serveur X mal protégé peut permettre aux personnes mal intentionnées d'espionner tout ce que vous tapez au clavier (en particulier les mots de passe) et d'obtenir une copie des fenêtres affichées sur votre écran.

Démon HTTP

Avant toute chose, il faut s'assurer que ce démon ne tourne sous l'identité de root que si cela est vraiment nécessaire, pour limiter les dégâts en cas d'intrusion. Ceci s'obtient en spécifiant les variables User et Group dans fichier httpd.conf (on peut leur attribuer par exemple les valeurs cognac et logiciel). Les possibilités d'intrusion du démon proviennent essentiellement des scripts CGI (Common Gateway Interface) dont l'exécution est déclenchée à distance par un utilisateur remplissant un formulaire que vous avez mis à sa disposition. Rien ne l'empêche de placer dans les champs de votre formulaire des valeurs contenant des caractères spéciaux, ayant une signification particulière pour le langage utilisé dans les scripts traitant le formulaire rempli, dans l'espoir de détourner en sa faveur la logique de ces scripts. Pour prendre un exemple simple, si votre formulaire lui demande son nom, il peut prétendre s'appeler toto;rm -rf /; s'il s'attend à ce que ce nom soit placé dans une variable d'un script Shell, toute invocation ultérieure de cette variable ayant des conséquences inattendues. Ainsi, l'écriture de scripts CGI est un art subtil, puisqu'il faut penser à vérifier le format de toutes les valeurs des champs reçues par le script pour détecter ce genre de facéties. Les quelques pointeurs suivant donnent de bons conseils à ce sujet:

Une autre mesure de prudence est de ne placer dans le répertoire cgi-bin que les scripts vraiment nécessaires: par le passé, certaines procédures d'installation du démon HTTP y plaçaient des scripts d'exemple qui n'étaient pas aussi sûrs qu'on le croyait.