La plupart des daemons actuels ont leur propres mécanismes de sécurité (tels httpd, smbd ou squid) ; jadis il était très courants qu'un deamon utilise une couche de sécurité : tcp_wrappers ou xinetd pour assurer un contrôle d'accès à sa place. Ceux-ci sont basés sur la libwrap.so et utilisent des fichiers de configuration communs, ce qui permet la centralisation de la politique de sécurité d'accès aux différents services réseau.

Lorsque le système reçoit une connexion entrante, il consulte les fichiers /etc/hosts.allow et /etc/hosts.deny pour déterminer les droits d'accès au service demandé. tcp_wrappers vérifie par service (en regardant l'association service/port listé dans le fichier /etc/services) et par client réseau. L'ordre d'application des règles est la suivante :

• l'accès est-il explicitement autorisé dans /etc/hosts.allow ?
• sinon, l'accès est-il explicitement interdit dans /etc/hosts.deny ?
• sinon, l'accès est autorisé par défaut

Pour savoir si un programme utilise la libwrap :

ldd /usr/sbin/sshd | grep wrap
        libwrap.so.0 => /lib/libwrap.so.0 (0x0074e000)

Certains programmes n'utilisent pas la dépendance de la librairie partagée, mais sont pourtant compatibles ; par exemple portmap qui linke en dur la librairie dans le binaire. Dans ce cas on peut utiliser strings pour rechercher une occurrence à la librairie :

strings /sbin/portmap | grep wrap

Effectivement, là ça ne matche pas non plus ; donc en conclusion c'est par expérience qu'on peut savoir si un programme utilise ou non la librairie libwrap.so. Ou en ratissant la doc !

NB : Si un service est compatible xinetd, alors il est utilise forcément TCP_Wrappers : par exemple in.telnetd ou ntpd ou encore tftpd. L'inverse n'est pas forcément vrai, c'est le cas par exemple de sshd.

La syntaxe est de la forme : nom_de_l'exécutable1: client. Il existe des macros qui simplifient l'écriture des règles ; les plus utilisées sont :

• ALL (tous, que cela soit des services ou des clients)
• LOCAL : cible les clients provenant du même LAN de l'interface réseau de la machine
• KNOWN, UNKNOWN et PARANOID : peu/plus usités car ils provoquent des requêtes DNS

Exemple de syntaxe commentée du fichier /etc/hosts.allow (bien entendu la syntaxe est la même pour /etc/hosts.deny, avec le sens opposé !) :

# tous les services sont autorisés et pour tout le monde (open-bar, en somme)
ALL: ALL
 
# tout est autorisé à l'exception les machines du domaine .test.com
# attention cela provoque une requête DNS à chaque nouvelle connexion ;
#de plus cela implique que la sécurité du système est tributaire de celle du DNS)
ALL: ALL EXEPT .test.com
 
# autorisation de ssh et telnet pour le LAN 192.168.0.0/24 ainsi que 10.0.0.0/24
sshd, in.telnetd: 192.168.0.0/255.255.255.0 10.0.0.
 
# autorisation du telnet pour tous + lancement d'une commande personnalisée
#à chaque ouverture de connexion (ici envoi d'un mail à root) ;
#spawn est une option donc précédée par un second délimiteur ":"
in.telnetd: ALL : spawn echo "login attempt from %c to %s" | mail -s warning root
 
# si le serveur dispose de plusieurs cartes réseau, on peut appliquer des politiques différentes :
# - le démon sshd qui écoute sur l'interface locale 192.168.0.2 est ouvert à tous
# - celui sur 192.168.1.2 en revanche est bloqué.
# En effet, DENY peut être utilisé comme option dans hosts.allow mais c'est déconseillé
#car peu cohérent avec la sémantique du fichier...
sshd@192.168.0.2: ALL
sshd@192.168.1.2: ALL: DENY

Les varibales utilisables (comme ci-dessus dans la commande spawn) sont les suivantes :

• %c : informations du client
• %s : informations du service
• %h : nom d'hôte ou IP du client
• %p : le PID du service

TCP_Wrappers peut utiliser IPv6 ; ex : [::1] ou [fe80::]/64.