Cet article présente une technique de sécurité propre aux réseaux Unix : le wrapping ou emballage TCP.
Principe
Les systèmes d'exploitation de type Unix intègrent des mécanismes de protection limitant les risques de piratage. Citons l'authentification des utilisateurs, le contrôle des ressources, la tenue de journaux de bord ... Cependant, la forte croissance du traffic Internet nécessite la mise en oeuvre de véritables politiques de régulation. Dans cette optique, TcpWrapper restreint l'accès aux services disponibles en un point du réseau. Quelques précisions relatives au modèle IP et au démon Internet aideront à en comprendre le fonctionnement.
Le modèle IP
Modèle en couches
Les protocoles de communication de classe IP règlent les échanges de données Internet. Ils respectent un modèle dit "en couches". Cette expression désigne le découpage d'un logiciel complexe en couches coordonnées par un jeu d'interfaces. Le modèle OSI (Open System Interconnection) en compte 7 englobant une communication du niveau matériel au niveau des applications.
Couche application Couche transport Couche Internet Couche réseau
Commutation de paquets
La couche Internet ou IP assure la fragmentation des données en paquets et leur routage au fil des réseaux. La couche transport introduit les protocoles TCP (Transmission Control Protocol) et UDP (Universal Datagram Protocol). Messages d'acquittement et sommes de contrôle garantissent la réception correcte et ordonnée des paquets TCP. La communication entre deux machines implique l'allocation d'une paire de ports. Le fichier /etc/services associe numéros de port et services. Le port 21 est dédié au service FTP, le 23 à telnet ...
Démon Internet
Les exemples ont été testés sous Red Hat 6.0 et compte root. Votre Linux Box doit disposer d'un accès Internet opérationnel.
Principe
Des programmes tournant en arrière-plan, les démons, offrent certains services. Par exemple, lpd organise les tâches d'impression. Ces démons monopolisent des ressources système alors même qu'ils demeurent passifs la plupart du temps. Le démon Internet inetd apporte une solution élégante à ce problème. Il s'intercale entre clients et serveurs, invoquant ces derniers quand nécessaire.
Configuration
Le fichier /etc/inetd.conf établit les caractéristiques de chaque service. Une ligne suit le format :
service type protocole attente uid serveur arguments service Nom du service tel que déclaré dans /etc/services. type Stream pour un service TCP, dgram pour un service UDP. protocole Nom du protocole tel que déclaré dans /etc/protocols. attente Nowait pour un service TCP, wait pour un service UDP. uid UID du démon. Souvent root. serveur Chemin et nom du serveur, internal si service interne. arguments Nom et arguments éventuels du serveur.
Voici une entrée possible du fichier inetd.conf :
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
En clair, in.telnetd honore le service TCP telnet. Root est le propriétaire du processus lors de son exécution.
Activité du démon Internet
Vérifiez l'activité du démon Internet :
ps -A | grep inetd 200 ? 00:00:00 inetd
Linux active Inetd lors de la phase d'initialisation. Si tel n'est pas le cas sur votre système, entrez (Red Hat) :
chkconfig -add inet
Une session telnet illustre le fonctionnement d'inetd. Ouvrez deux fenêtres terminal. Dans la première, établissez la liaison :
telnet localhost
Dans la seconde, réclamez la liste des processus :
ps -A --forest
L'option --forest active l'affichage des liens de parenté entre processus. Nous obtenons :
PID TTY TIME CMD ... 388 ? 00:00:00 inetd 975 ? 00:00:00 \_ in.telnetd 976 pts/0 00:00:00 \_ login 977 pts/0 00:00:00 \_ bash
Inetd a détecté la demande de connexion telnet sur le port 23. Consultant la table de correspondance, il détermine que ce service est fourni par le serveur in.telnetd et l'exécute. in.telnetd cède ensuite la place à la procédure de login. Correctement identifié, l'utilisateur se retrouve sous interpréteur de commandes. Ici, Bourne Again Shell. Retournez dans la première fenêtre et quittez la session telnet avec exit. Réclamez à nouveau la liste des processus :
ps -A --forest ... 388 ? 00:00:00 inetd
Le serveur in.telnetd et sa descendance sont tués à la déconnexion.
TCP Wrapper
Principe
Certains serveurs gèrent leur propre sécurité. Ainsi, les Fournisseurs d'Accès Internet réservent leurs prestations à leurs abonnés : courrier, forums de discussion ... Ils analysent le traffic à la recherche d'anomalies.
Un wrapper TCP, littéralement emballeur TCP, est un outil générique qui facilite ces tâches. Il s'intercale entre le démon Internet et les serveurs, relayant ou non les requêtes sur la base de règles spécifiées par l'administrateur du réseau. Voici une variante du fichier inetd.conf exploitant TCP Wrapper :
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Désormais, tcpd intercepte les appels telnet, décidant du lancement du serveur in.telnetd. La distribution Red Hat lie dès l'origine les actions d'inetd et de tcpd. Ouvrez une nouvelle session telnet puis affichez la fin du fichier d'audit /var/log/secure (défaut) :
tail /var/log/secure ... Dec 19 17:49:13 robby in.telnetd[787]: connect from 127.0.0.1
La ligne précédente confirme l'action de tcpd.
Règles de filtrage
Le format des fichiers de configuration a évolué. Nous nous référons à la version 7.6 du paquetage tcp_wrappers.
Les fichiers /etc/hosts.allow et /etc/hosts.deny regroupent les règles appliquées aux requêtes. Les versions récentes de TCP Wrapper autorisent la déclaration de règles d'accès et de rejet dans les deux fichiers. Elles respectent la syntaxe :
serveurs : clients : option : option ... serveurs liste des serveurs surveillés clients liste des clients surveillés option action à appliquer
Espace et virgule font office de séparateurs.
Motifs
Les motifs suivants décrivent un ensemble de machines ou d'utilisateurs. La page man 5 hosts_access en fournit la liste complète :
.n Machine de nom *.n
a. Machine d'adresse a.*
r/m Machine du réseau r de masque m
ALL Machine ou utilisateur quelconque
LOCAL Machine locale (pas de notation pointée)
KNOWN Utilisateur de nom connu
Machine de nom et d'adresse connus
UNKNOWN Utilisateur de nom inconnu
Machine de nom ou d'adresse inconnus
PARANOID Machine dont nom et adresse ne correspondent pas
L'opérateur @ combine utilisateurs et machines sous la forme u@m.
Options
Les options suivantes déclenchent des actions. La page man hosts_options répertorie la liste complète.
ALLOW Autoriser la connexion DENY Refuser la connexion SPAWN Exécuter une commande shell
Variables d'environnement
Vous disposez des variables d'environnement suivantes
%a Adresse IP du client %A Adresse IP du serveur %c Informations disponibles sur l'utilisateur : u@m %d Nom sous lequel le serveur a été invoqué %h Nom ou à défaut adresse du client %H Non ou à défaut adresse du serveur %n Nom du client ou unknown, paranoid %N Nom du serveur %p Numéro de processus du démon %s Informations disponibles sur le serveur : s@m %u Nom de l'utilisateur ou unknown %% Caractère %
Audit
Le fichier /var/log/secure (défaut) (/var/log/auth.log sur certaines distributions) enregistre les appels tcpd, qu'ils aboutissent ou non. Conformément à l'usage, heure, date, service et adresse IP du client sont indiqués.
Exemple - Serveur FTP
Organisation
Illustrons notre propos. Les fichiers hosts.allow et hosts.deny sont initialement vides. Tous les services sont alors disponibles, quel que soit le client. Supposons que nous souhaitons sécuriser le serveur FTP krell d'adresse IP 192.168.0.3 appartenant au réseau privé altair.net. Il proposera cet unique service et un accès telnet à la machine monster d'adresse IP 192.168.0.128.
Serveur
Le serveur employé est WU-FTPD (Washington University FTP Server), fourni avec la distribution Red Hat. Voici l'entrée correspondante de /etc/inetd.conf :
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
hosts.allow
Nous centralisons les règles dans /etc/hosts.allow :
in.ftpd : 192.168.0. : ALLOW in.telnetd : 192.168.0.128 : ALLOW ALL : ALL : DENY
La dernière règle bloque l'accès à tous les services. Les deux premières autorisent des accès FTP et telnet limités. tcpd procède en séquence jusqu'à trouver la première règle applicable, puis interrompt son action.
Tests
Vérifions la syntaxe des règles :
tcpdchk -v
Finalement, forçons la relecture de la configuration :
killall -HUP inetd
Tout est prêt. Le comportement de tcpd peut être testé directement depuis les machines concernées. En complément, TCP Wrapper propose tcpdmatch, un utilitaire très complet. Le moyen de simuler l'action de TCP Wrapper sur une station isolée :
Session telnet depuis monster
tcpdmatch in.telnetd 192.168.0.128 client: adress 192.168.0.128 server: process in.telnetd matched: /etc/hosts.allow line 7 option: ALLOW access: granted
Session telnet non autorisée
tcpdmatch in.telnetd 192.168.0.1 client: adress 192.168.0.1 server: process in.telnetd matched: /etc/hosts.allow line 9 option: DENY access: denied
Session FTP
tcpdmatch in.ftpd 192.168.0.2 client: adress 192.168.0.2 server: process in.ftpd matched: /etc/hosts.allow line 8 option: ALLOW access: granted
Plus loin avec TCP Wrapper
Les limites de TCP Wrapper
TCP Wrapper améliore certes la sécurité des réseaux mais il faut être conscient de ses limites. Tout d'abord, un serveur mal configuré risque toujours d'ouvrir l'accès de votre réseau à un utilisateur mal intentionné. Mais surtout, TCP Wrapper ne saurait résoudre tous les problèmes liés à l'absence d'authentification satisfaisante dans IP version 4.
Détournement d'adresse IP
Schématiquement, cette attaque consiste à adresser des paquets possédant une adresse IP d'émission fictive à une machine cible. On la choisit dans le domaine du réseau visé. Morris a décrit le premier cette faille dans le protocole de négociation d'une liaison TCP.
Détournement de nom
Cette deuxième attaque suppose la corruption d'un serveur de noms de domaine. Ces serveurs fonctionnent de concert. Ils prennent en charge les conversions nom de machine <--> adresse IP. Malheureusement, certains services basent leur "authentification" sur le nom des machines clientes. TCP Wrapper contre ces attaques en procédant à des résolutions adresse -> nom et nom -> adresse puis en confrontant les résultats obtenus. En cas de différence, paranoid est retourné.
Serveur d'identité
Le serveur d'identité Ident retourne des informations sur l'utilisateur d'une connexion TCP/IP. Par ce moyen, et dans l'hypothèse où le service est installé sur la machine distante, on peut détecter une tentative de détournement d'adresse IP. Il est en effet plus difficile de forcer deux services simultanément. known est retourné si l'utilisateur est identifié, unknown sinon.
Commandes
L'administrateur système peut souhaiter déclencher des commandes particulières lors des connexions. L'option spawn lance une procédure shell exploitant les variables d'environnement précédemment citées. Dans notre exemple, nous informons le super utilisateur des tentatives de connexion interdites :
ALL : ALL : SPAWN echo "Service %d IP %a Utilisateur %c" | /bin/mail root -s "Alerte tcpd" : DENY
A chaque tentative infructueuse, un courrier d'alerte sera adressé au super utilisateur.
Conclusion
TCP Wrapper constitue un élément de sécurité intéressant. Mais il doit être considéré dans le cadre d'une politique globale combinant mesures de niveau hôte et réseau. Le site référencé en annexe compile des liens sur des sujets connexes : coupe feu, manuel de sécurité orange... Bonne lecture.
En ligne
Liens sécurité www.alw.nih.gov/Security/first-papers.html
Linux Magazine France n°14 - Février 2000