Le contrôle de l'accès aux services du réseau est l'une des tâches de sécurité les plus importantes auxquelles est confronté un administrateur de serveur. Linux fournit plusieurs outils à cette fin.

Par exemple, un pare-feu basé sur iptables filtre les paquets réseau indésirables dans la pile réseau du noyau. Pour les services réseau qui l'utilisent, les TCP Wrappers ajoutent une couche de protection supplémentaire en définissant quels hôtes sont ou ne sont pas autorisés à se connecter aux services réseau “enveloppés”.

Un de ces services réseau enveloppés est le super serveur xinetd. Ce service est appelé “super serveur” parce qu'il contrôle les connexions à un sous-ensemble de services réseau et affine encore le contrôle d'accès.

La figure qui suit est une illustration de base de la manière dont ces outils fonctionnent ensemble pour protéger les services de réseau.

Ce chapitre se concentre sur le rôle des TCP Wrappers et de xinetd dans le contrôle de l'accès aux services réseau et examine comment ces outils peuvent être utilisés pour améliorer à la fois la journalisation et la gestion.

Le paquet TCP Wrappers (tcp_wrappers) est installé par défaut et fournit un contrôle d'accès aux services du réseau basé sur l'hôte. Le composant le plus important de ce paquet est la bibliothèque /usr/lib/libwrap.a. En termes généraux, un service TCP-wrapped est un service qui a été compilé avec la bibliothèque libwrap.a.

Lorsqu'une tentative de connexion est faite à un service TCP-wrapped, le service fait d'abord référence aux fichiers d'accès de l'hôte (/etc/hosts.allow et /etc/hosts.deny) pour déterminer si le client est autorisé à se connecter ou non. Dans la plupart des cas, il utilise ensuite le démon syslog (syslogd) pour écrire le nom du client demandeur et le service demandé dans /var/log/secure ou /var/log/messages.

Si un client est autorisé à se connecter, TCP Wrappers libèrent le contrôle de la connexion au service demandé et ne prend plus part à la communication entre le client et le serveur.

En plus du contrôle d'accès et de la journalisation, TCP Wrappers peut exécuter des commandes pour interagir avec le client avant de refuser ou de libérer le contrôle de la connexion au service réseau demandé.

Comme TCP Wrappers est un ajout précieux à l'arsenal d'outils de sécurité de tout administrateur de serveur, la plupart des services réseau de Linux sont liés à la bibliothèque libwrap.a. Parmi ces applications, citons /usr/sbin/sshd, /usr/sbin/sendmail et /usr/sbin/xinetd.

ldd <binary-name> | grep libwrap

[root@myserver ~]# ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00655000)

TCP Wrappers offrent les avantages suivants par rapport aux autres techniques de contrôle des services de réseau :

• Transparence pour le client et le service de réseau enveloppé - Le client qui se connecte et le service de réseau enveloppé ne savent pas que les enveloppeurs TCP sont utilisés. Les utilisateurs légitimes sont enregistrés et connectés au service demandé alors que les connexions des clients bannis échouent.
• Gestion centralisée de plusieurs protocoles - Les TCP Wrappers fonctionnent séparément des services réseau qu'ils protègent, ce qui permet à de nombreuses applications serveur de partager un ensemble commun de fichiers de configuration de contrôle d'accès, ce qui simplifie la gestion.

Pour déterminer si un client est autorisé à se connecter à un service, TCP Wrappers fait référence aux deux fichiers suivants, communément appelés fichiers d'accès aux hôtes :

• /etc/hosts.allow
• /etc/hosts.deny

Lorsqu'un service enveloppé dans le TCP reçoit une demande d'un client, il effectue les étapes suivantes :

• Il fait référence à /etc/hosts.allow - Le service enveloppé dans le protocole TCP analyse séquentiellement le fichier /etc/hosts.allow et applique la première règle spécifiée pour ce service. S'il trouve une règle correspondante, il autorise la connexion. Sinon, il passe à l'étape suivante.
• Il fait référence au fichier /etc/hosts.deny - Le service enveloppé dans le TCP analyse séquentiellement le fichier /etc/hosts.deny. S'il trouve une règle correspondante, il refuse la connexion. Sinon, il accorde l'accès au service.

Les points suivants sont importants à prendre en compte lors de l'utilisation de TCP Wrappers pour protéger les services réseau :

• Comme les règles d'accès dans le fichier hosts.allow sont appliquées en premier, elles ont la priorité sur les règles spécifiées dans le fichier hosts.deny. Par conséquent, si l'accès à un service est autorisé dans le fichier hosts.allow, une règle refusant l'accès à ce même service dans le fichier hosts.deny est ignorée.
• Les règles de chaque fichier sont lues de haut en bas et la première règle correspondante pour un service donné est la seule appliquée. L'ordre des règles est extrêmement important.
• Si aucune règle pour le service n'est trouvée dans l'un ou l'autre des fichiers, ou si aucun fichier n'existe, l'accès au service est accordé.
• Les services enveloppés dans le protocole TCP ne mettent pas en cache les règles des fichiers d'accès aux hôtes, de sorte que toute modification de hosts.allow ou hosts.deny prend effet immédiatement, sans redémarrer les services du réseau.

warning: /etc/hosts.allow, line 20: missing newline or line too long

Le format pour /etc/hosts.allow et /etc/hosts.deny est identique. Chaque règle doit être sur sa propre ligne. Les lignes vides ou les lignes qui commencent par un dièse (#) sont ignorées.

Chaque règle utilise le format de base suivant pour contrôler l'accès aux services du réseau :

<daemon list>: <client list> [: <option>: <option>: ...]

• <daemon list> - Une liste de noms de processus (pas de noms de services) séparés par des virgules ou le joker ALL. La liste des démons accepte également les opérateurs pour permettre une plus grande flexibilité.
• <client list> - Une liste séparée par des virgules de noms d'hôtes, d'adresses IP d'hôtes, de modèles spéciaux ou de jokers qui identifient les hôtes concernés par la règle. La liste des clients accepte également les opérateurs pour permettre une plus grande flexibilité.
• <option> - Une action optionnelle ou une liste d'actions séparées par des deux-points effectuées lorsque la règle est déclenchée. Les champs d'option prennent en charge les extensions, lancent des commandes shell, autorisent ou refusent l'accès et modifient le comportement de journalisation.

Voici un exemple de règle de base pour l'accès aux hôtes :

vsftpd : .example.com

Cette règle demande à TCP Wrappers de surveiller les connexions au démon FTP (vsftpd) depuis n'importe quel hôte du domaine exemple.com. Si cette règle apparaît dans hosts.allow, la connexion est acceptée. Si cette règle apparaît dans le fichier hosts.deny, la connexion est rejetée.

Le prochain exemple de règle d'accès aux hôtes est plus complexe et utilise deux champs d'option :

sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny

Notez que chaque champ d'option est précédé d'une barre oblique inversée (\). L'utilisation de la barre oblique inversée permet d'éviter l'échec de la règle en raison de sa longueur.

Cet exemple de règle indique que si une connexion au démon SSH (sshd) est tentée à partir d'un hôte du domaine example.com, il faut exécuter la commande echo pour ajouter la tentative à un fichier journal spécial, et refuser la connexion. Comme la directive optionnelle deny est utilisée, cette ligne refuse l'accès même si elle apparaît dans le fichier hosts.allow.

Les Wildcards permettent à TCP Wrappers de faire correspondre plus facilement des groupes de démons ou d'hôtes. Ils sont utilisés le plus souvent dans le domaine des règles d'accès aux listes de clients.

Les Wildcards suivants sont disponibles :

• ALL - Correspond à tout. Ils peuvent être utilisés à la fois pour la liste des démons et la liste des clients.
• LOCAL - Correspond à tout hôte qui ne contient pas de point (.), tel que localhost.
• KNOWN - Correspond à tout hôte dont le nom et l'adresse sont connus ou dont l'utilisateur est connu.
• UKNOWN - Correspond à tout hôte dont le nom d'hôte ou l'adresse d'hôte est inconnu ou dont l'utilisateur est inconnu.
• PARANOID - Correspond à tout hôte dont le nom d'hôte ne correspond pas à l'adresse de l'hôte.

Les Patterns peuvent être utilisés dans le domaine des règles d'accès des clients pour spécifier plus précisément les groupes d'hôtes clients.

Voici une liste de modèles courants pour les entrées dans le champ client :

• Nom d'hôte commençant par un point (.) - Le fait de placer un point au début d'un nom d'hôte correspond à tous les hôtes partageant les éléments énumérés du nom. L'exemple suivant s'applique à tout hôte dans le domaine exemple.com :

All : .exemple.com

• Adresse IP se terminant par un point (.) - Le fait de placer un point à la fin d'une adresse IP correspond à tous les hôtes partageant les groupes numériques initiaux d'une adresse IP. L'exemple suivant s'applique à tout hôte du réseau 192.168.x.x :

ALL : 192.168.

• Couple adresse IP/masque réseau - Les expressions de masque réseau peuvent également être utilisées comme modèle pour contrôler l'accès à un groupe particulier d'adresses IP. L'exemple suivant s'applique à tout hôte ayant une plage d'adresses allant de 192.168.0.0 à 192.168.1.255 :

ALL : 192.168.0.0/255.255.254.0

• L'astérisque (*) - Les astérisques peuvent être utilisés pour faire correspondre des groupes entiers de noms d'hôtes ou d'adresses IP, à condition qu'ils ne soient pas mélangés dans une liste de clients contenant d'autres types de modèles. L'exemple suivant s'applique à tout hôte du domaine exemple.com :

ALL : *.exemple.com

• La barre oblique (/) - Si une liste de clients commence par une barre oblique, elle est traitée comme un nom de fichier. Cela est utile si des règles spécifiant un grand nombre d'hôtes sont nécessaires. L'exemple suivant renvoie vers le fichier /etc/telnet.hosts pour toutes les connexions Telnet :

in.telnetd : /etc/telnet.hosts

À l'heure actuelle, les règles de contrôle d'accès acceptent un seul opérateur, EXCEPT. Il peut être utilisé à la fois dans la liste des démons et dans la liste des clients d'une règle.

L'opérateur EXCEPT permet des exceptions spécifiques à des correspondances plus larges au sein d'une même règle.

Dans l'exemple suivant, tiré d'un fichier hosts.allow, tous les hôtes du site example.com sont autorisés à se connecter à tous les services, à l'exception de cracker.example.com :

ALL : .example.com EXCEPT cracker.example.com

Dans un autre exemple tiré d'un fichier hosts.allow, les clients du réseau 192.168.0.x peuvent utiliser tous les services sauf le FTP :

ALL EXCEPT vsftpd : 192.168.0.

En plus des règles de base qui autorisent et refusent l'accès, l'implémentation de TCP Wrappers dans Linux prend en charge des extensions du langage de contrôle d'accès par le biais de champs d'options. En utilisant des champs d'option dans les règles d'accès aux hôtes, les administrateurs peuvent accomplir une variété de tâches telles que la modification du comportement des journaux, la consolidation du contrôle d'accès et le lancement de commandes shell.

Les champs d'option permettent aux administrateurs de modifier facilement le niveau de journalisation et le niveau de priorité d'une règle en utilisant la directive de severity.

Dans l'exemple suivant, les connexions au démon SSH depuis n'importe quel hôte du domaine example.com sont enregistrées dans la fonction syslog authpriv par défaut (car aucune valeur de fonction n'est spécifiée) avec une priorité d'urgence :

sshd : .example.com : severity emerg

Il est également possible de spécifier une facility en utilisant l'option severity. L'exemple suivant consigne toutes les tentatives de connexion SSH des hôtes du domaine example.com à la facility : local0 avec la priorité alert :

sshd : .exemple.com : severity local0.alert

Les champs d'option permettent également aux administrateurs d'autoriser ou de refuser explicitement des hôtes dans une règle unique en ajoutant la directive d'autorisation ou de refus comme option finale.

Par exemple, les deux règles suivantes autorisent les connexions SSH à partir du site client-1.exemple.com, mais refusent les connexions à partir du site client-2.exemple.com :

sshd : client-1.exemple.com : allow
sshd : client-2.example.com : deny

En permettant le contrôle d'accès par règle, le champ d'option permet aux administrateurs de consolider toutes les règles d'accès dans un seul fichier : soit hosts.allow, soit hosts.deny. Certains administrateurs considèrent qu'il s'agit là d'une manière plus simple d'organiser les règles d'accès.

Les champs d'option permettent aux règles d'accès de lancer des commandes shell par le biais des deux directives suivantes :

• spawn - Lance une commande shell comme un processus enfant. Cette directive peut effectuer des tâches comme l'utilisation de /usr/sbin/safe_finger pour obtenir plus d'informations sur le client demandeur ou créer des fichiers journaux spéciaux en utilisant la commande echo.

Dans l'exemple suivant, les clients qui tentent d'accéder aux services Telnet à partir du domaine example.com sont discrètement enregistrés dans un fichier spécial :

in.telnetd : .example.com \
	: spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
	: allow

• twist - Remplace le service demandé par la commande spécifiée. Cette directive est souvent utilisée pour mettre en place des pièges à intrusion (également appelés “pots de miel”). Elle peut également être utilisée pour envoyer des messages aux clients qui se connectent. La directive twist doit se trouver à la fin de la ligne de règle.

Dans l'exemple suivant, les clients qui tentent d'accéder aux services FTP à partir du domaine example.com reçoivent un message à l'aide de la commande echo :

vsftpd : .example.com \
	: twist /bin/echo "421 Ce domaine a été mis sur liste noire. Accès refusé".

Les extensions, lorsqu'elles sont utilisées en conjonction avec les directives spawn et twist, fournissent des informations sur le client, le serveur et les processus impliqués.

Voici une liste des extensions prises en charge :

• %a - Renvoie l'adresse IP du client.
• %A - Retourne l'adresse IP du serveur.
• %c - Renvoie diverses informations sur le client, telles que le nom d'utilisateur et le nom d'hôte, ou le nom d'utilisateur et l'adresse IP.
• %d - Renvoie le nom du processus du démon.
• %h - Retourne le nom d'hôte du client (ou l'adresse IP, si le nom d'hôte n'est pas disponible).
• %H - Retourne le nom d'hôte du serveur (ou l'adresse IP, si le nom d'hôte n'est pas disponible).
• %n - Retourne le nom d'hôte du client. Si le nom d'hôte n'est pas disponible, unknown est imprimé. Si le nom d'hôte du client et l'adresse de l'hôte ne correspondent pas, le message paranoid s'affiche.
• %N - Renvoie le nom d'hôte du serveur. En cas d'indisponibilité, unknown s'affiche. Si le nom d'hôte du serveur et l'adresse de l'hôte ne correspondent pas, le message paranoid s'affiche.
• %p - Renvoie l'ID de processus du démon.
• %s - Renvoie divers types d'informations sur le serveur, comme le processus du démon et l'hôte ou l'adresse IP du serveur.
• %u - Renvoie le nom d'utilisateur du client. S'il n'est pas disponible, unknown est imprimé.

L'exemple de règle suivant utilise une extension en conjonction avec la commande spawn pour identifier l'hôte du client dans un fichier journal personnalisé.

Lorsque des connexions au démon SSH (sshd) sont tentées à partir d'un hôte du domaine example.com, exécutez la commande echo pour enregistrer la tentative, y compris le nom d'hôte du client (en utilisant l'extension %h), dans un fichier spécial :

sshd : .example.com  \
	: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
	: deny

De même, les extensions peuvent être utilisées pour personnaliser les messages renvoyés au client. Dans l'exemple suivant, les clients qui tentent d'accéder aux services FTP à partir du domaine example.com sont informés qu'ils ont été bannis du serveur :

vsftpd : .example.com \
        : twist /bin/echo "421 %h has been banned from this server!"

Le démon xinetd est un super service TCP-Wrapped qui contrôle l'accès à un sous-ensemble de services réseau populaires, y compris FTP, IMAP et Telnet. Il fournit également des options de configuration spécifiques au service pour le contrôle d'accès, la journalisation améliorée, la liaison, la redirection et le contrôle de l'utilisation des ressources.

Lorsqu'un client tente de se connecter à un service réseau contrôlé par xinetd, le super service reçoit la demande et vérifie s'il existe des règles de contrôle d'accès TCP Wrappers.

Si l'accès est autorisé, xinetd vérifie que la connexion est autorisée en vertu de ses propres règles d'accès pour ce service. Il vérifie également que le service peut disposer de plus de ressources et qu'il n'enfreint aucune règle définie.

Si toutes ces conditions sont remplies (c'est-à-dire que l'accès au service est autorisé, que le service n'a pas atteint sa limite de ressources et qu'il ne viole aucune règle définie), xinetd lance alors une instance du service demandé et lui transmet le contrôle de la connexion. Une fois la connexion établie, xinetd ne prend plus part à la communication entre le client et le serveur.

Les fichiers de configuration pour xinetd sont les suivants :

• /etc/xinetd.conf - Le fichier de configuration global de xinetd.
• /etc/xinetd.d/ - Le répertoire contenant tous les fichiers spécifiques au service.

Le fichier /etc/xinetd.conf contient des paramètres de configuration généraux qui affectent chaque service sous le contrôle de xinetd. Il est lu lors du premier démarrage du service xinetd, donc pour que les changements de configuration prennent effet, vous devez redémarrer le service xinetd.

Voici un exemple de fichier /etc/xinetd.conf :

defaults
{
         instances               = 60        
	 log_type                = SYSLOG	authpriv
	 log_on_success          = HOST PID
	 log_on_failure          = HOST
	 cps                     = 25 30
}
includedir /etc/xinetd.d

Ces lignes contrôlent les aspects suivants de xinetd :

• instances - Spécifie le nombre maximum de demandes simultanées que xinetd peut traiter.
• log_type - Configure xinetd pour qu'il utilise la fonction authpriv, qui écrit les entrées du journal dans le fichier /var/log/secure. L'ajout d'une directive telle que FILE /var/log/xinetdlog créerait un fichier journal personnalisé appelé xinetdlog dans le répertoire /var/log/.
• log_on_success - Configure xinetd pour enregistrer les tentatives de connexion réussies. Par défaut, l'adresse IP de l'hôte distant et l'ID de processus du serveur qui traite la demande sont enregistrés.
• log_on_failure - Configure xinetd pour enregistrer les tentatives de connexion échouées ou si la connexion a été refusée.
• cps - Configure xinetd pour autoriser un maximum de 25 connexions par seconde à un service donné. Si cette limite est dépassée, le service est mis hors service pendant 30 secondes.
• includedir /etc/xinetd.d/ - Inclut les options déclarées dans les fichiers de configuration spécifiques au service situés dans le répertoire /etc/xinetd.d/.

Le répertoire /etc/xinetd.d/ contient les fichiers de configuration de chaque service géré par xinetd et les noms des fichiers sont en corrélation avec le service. Comme pour xinetd.conf, ce répertoire n'est lu que lorsque le service xinetd est lancé. Pour que les changements prennent effet, l'administrateur doit redémarrer le service xinetd.

Le format des fichiers dans le répertoire /etc/xinetd.d/ utilise les mêmes conventions que le répertoire /etc/xinetd.conf. La raison principale pour laquelle la configuration de chaque service est stockée dans un fichier séparé est de rendre la personnalisation plus facile et moins susceptible d'affecter les autres services.

Pour comprendre comment ces fichiers sont structurés, considérez le fichier /etc/xinetd.d/krb5-telnet :

service telnet
{
         flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 disable         = yes
}

Ces lignes contrôlent divers aspects du service telnet :

• service - Spécifie le nom du service, généralement l'un de ceux qui figurent dans le fichier /etc/services.
• flags - Définit un certain nombre d'attributs pour la connexion. REUSE indique à xinetd de réutiliser la prise pour une connexion Telnet.
• socket_type - Définit le type de socket réseau pour le streaming.
• wait - Spécifie si le service est single-threaded (oui) ou multi-threaded (non).
• user - Spécifie l'identifiant de l'utilisateur sous lequel le processus s'exécute.
• server - Spécifie l'exécutable binaire à lancer.
• log_on_failure - Spécifie les paramètres de connexion pour log_on_failure en plus de ceux déjà définis dans xinetd.conf.
• disable - Spécifie si le service est désactivé (oui) ou activé (non).

Une série de directives est disponible pour les services protégés par xinetd. Cette section met en évidence certaines des options les plus couramment utilisées.

Les options de journalisation suivantes sont disponibles à la fois pour le fichier /etc/xinetd.conf et les fichiers de configuration spécifiques au service dans le répertoire /etc/xinetd.d/.

Voici une liste de quelques-unes des options de journalisation les plus couramment utilisées :

• ATTEMPT - Enregistre le fait qu'une tentative a échoué (log_on_failure).
• DURATION - Enregistre la durée d'utilisation du service par un système distant (log_on_success).
• EXIT - Enregistre l'état de sortie ou le signal de fin du service (log_on_success).
• HOST - Enregistre l'adresse IP de l'hôte distant (log_on_failure et log_on_success).
• PID - Enregistre l'ID de processus du serveur qui reçoit la demande (log_on_success).
• USERID - Connecte l'utilisateur distant en utilisant la méthode définie dans la RFC 1413 pour tous les services de flux multi-threads (log_on_failure et log_on_success).

Les utilisateurs des services xinetd peuvent choisir d'utiliser les règles d'accès aux hôtes TCP Wrappers, de fournir un contrôle d'accès via les fichiers de configuration xinetd, ou un mélange des deux.

Le contrôle d'accès aux hôtes xinetd diffère de la méthode utilisée par les TCP Wrappers. Alors que le TCP Wrappers place toute la configuration d'accès dans deux fichiers, /etc/hosts.allow et /etc/hosts.deny, le contrôle d'accès de xinetd se trouve dans le fichier de configuration de chaque service dans le répertoire /etc/xinetd.d/.

Les options d'accès aux hôtes suivantes sont prises en charge par xinetd :

• only_from - Ne permet qu'aux hôtes spécifiés d'utiliser le service.
• no_access - Bloque les hôtes listés pour qu'ils n'utilisent pas le service.
• access_times - Spécifie la plage de temps pendant laquelle un service particulier peut être utilisé. L'intervalle de temps doit être indiqué en notation de format 24 heures, HH:MM-HH:MM.

Les options only_from et no_access peuvent utiliser une liste d'adresses IP ou de noms d'hôtes, ou peuvent spécifier un réseau entier. Comme TCP Wrappers, la combinaison du contrôle d'accès xinetd avec la configuration de journalisation améliorée peut accroître la sécurité en bloquant les demandes provenant d'hôtes bannis tout en enregistrant verbalement chaque tentative de connexion.

Par exemple, le fichier /etc/xinetd.d/telnet suivant peut être utilisé pour bloquer l'accès Telnet d'un groupe de réseau particulier et restreindre la plage de temps globale pendant laquelle même les utilisateurs autorisés peuvent se connecter :

service telnet
{
         disable         = no
	 flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 no_access       = 172.16.45.0/24
	 log_on_success  += PID HOST EXIT
	 access_times    = 09:45-16:15
}

Dans cet exemple, lorsqu'un système client du réseau 10.0.1.0/24, tel que 10.0.1.2, essaie d'accéder au service Telnet, il reçoit le message suivant :

Connection closed by foreign host.

En outre, leurs tentatives de connexion sont enregistrées dans /var/log/messages comme suit :

Sep  7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)

Lorsque l'on utilise TCP Wrappers avec les contrôles d'accès xinetd, il est important de comprendre la relation entre les deux mécanismes de contrôle d'accès.

Voici la séquence d'événements suivie par xinetd lorsqu'un client demande une connexion :

1. Le démon xinetd accède aux règles d'accès des hôtes TCP Wrappers en utilisant un appel de bibliothèque libwrap.a. Si une règle de refus correspond au client, la connexion est interrompue. Si une règle d'autorisation correspond au client, la connexion est passée à xinetd.
2. Le démon xinetd vérifie ses propres règles de contrôle d'accès à la fois pour le service xinetd et le service demandé. Si une règle de refus correspond au client, la connexion est interrompue. Sinon, xinetd lance une instance du service demandé et passe le contrôle de la connexion à ce service.

Les fichiers de configuration du service pour le support xinetd lient le service à une adresse IP et redirigent les demandes entrantes pour ce service vers une autre adresse IP, un autre nom d'hôte ou un autre port.

La liaison est contrôlée par l'option de liaison dans les fichiers de configuration spécifiques au service et relie le service à une adresse IP du système. Lorsque cette option est configurée, elle permet uniquement aux demandes adressées à la bonne adresse IP d'accéder au service. Vous pouvez utiliser cette méthode pour lier différents services à différentes interfaces réseau en fonction des besoins.

Cette méthode est particulièrement utile pour les systèmes comportant plusieurs adaptateurs réseau ou plusieurs adresses IP. Sur un tel système, les services non sécurisés (par exemple, Telnet), peuvent être configurés pour écouter uniquement sur l'interface connectée à un réseau privé et non sur l'interface connectée à Internet.

L'option de redirection accepte une adresse IP ou un nom d'hôte suivi d'un numéro de port. Elle configure le service pour rediriger toute demande de ce service vers l'hôte et le numéro de port spécifiés. Cette fonction peut être utilisée pour pointer vers un autre numéro de port sur le même système, rediriger la demande vers une adresse IP différente sur la même machine, déplacer la demande vers un système et un numéro de port totalement différents, ou toute combinaison de ces options. Un utilisateur se connectant à un certain service sur un système peut donc être redirigé vers un autre système sans interruption.

Le démon xinetd est capable d'accomplir cette redirection en créant un processus qui reste en vie pendant toute la durée de la connexion entre la machine cliente demandeuse et l'hôte qui fournit effectivement le service, en transférant les données entre les deux systèmes.

Les avantages des options de liaison et de redirection sont les plus évidents lorsqu'elles sont utilisées ensemble. En liant un service à une adresse IP particulière sur un système et en redirigeant ensuite les demandes de ce service vers une deuxième machine que seule la première peut voir, un système interne peut être utilisé pour fournir des services à un réseau totalement différent.

Prenons par exemple un système qui est utilisé comme pare-feu avec ce paramètre pour son service Telnet :

service telnet
{
         socket_type		= stream
	 wait			= no
	 server			= /usr/kerberos/sbin/telnetd
	 log_on_success		+= DURATION USERID
	 log_on_failure		+= USERID
	 bind                    = 123.123.123.123
	 redirect                = 10.0.1.13 23
}

Les options de liaison et de redirection de ce fichier garantissent que le service Telnet sur la machine est lié à l'adresse IP externe (123.123.123.123), celle qui est tournée vers l'Internet. En outre, toute demande de service Telnet envoyée à 123.123.123.123 est redirigée via un deuxième adaptateur réseau vers une adresse IP interne (10.0.1.13) à laquelle seuls le pare-feu et les systèmes internes peuvent accéder. Le pare-feu envoie alors la communication entre les deux systèmes, et le système de connexion pense être connecté à 123.123.123.123 alors qu'il est en fait connecté à une autre machine.

Cette fonction est particulièrement utile pour les utilisateurs disposant d'une connexion à large bande et d'une seule adresse IP fixe. Lorsque l'on utilise la traduction d'adresse réseau (NAT), les systèmes situés derrière la machine passerelle, qui utilisent des adresses IP internes uniquement, ne sont pas disponibles depuis l'extérieur du système passerelle.

Cependant, lorsque certains services contrôlés par xinetd sont configurés avec les options de liaison et de redirection, la machine passerelle peut servir de proxy entre les systèmes externes et une machine interne particulière configurée pour fournir le service. En outre, les diverses options de contrôle d'accès et de journalisation de xinetd sont également disponibles pour une protection supplémentaire.

Le démon xinetd peut ajouter un niveau de protection de base contre les attaques par déni de service (DoS). Voici une liste de directives qui peuvent contribuer à limiter l'efficacité de ces attaques :

• per_source - Définit le nombre maximum d'instances pour un service par adresse IP source. Elle n'accepte que des entiers comme argument et peut être utilisée à la fois dans xinetd.conf et dans les fichiers de configuration spécifiques au service dans le répertoire xinetd.d/.
• cps - Définit le nombre maximum de connexions par seconde. Cette directive prend deux arguments entiers séparés par des espaces. Le premier argument est le nombre maximum de connexions autorisées au service par seconde. Le second argument est le nombre de secondes que xinetd doit attendre avant de réactiver le service. Elle n'accepte que des entiers comme arguments et peut être utilisée soit dans le fichier xinetd.conf, soit dans les fichiers de configuration spécifiques au service dans le répertoire xinetd.d/.
• max_load - Définit le seuil d'utilisation du CPU ou de la charge moyenne pour un service. Il accepte un argument en nombre à virgule flottante.

La moyenne de charge est une mesure approximative du nombre de processus actifs à un moment donné. Voir les commandes uptime, who et procinfo pour plus d'informations sur la moyenne de charge.