Contrôle d'accès à l'aide de xinetd

/etc/xinetd.conf

Le fichier xinetd.conf est le parent de tous les fichiers de configuration de services contrôlés par xinetd, étant donné que chaque fichier spécifique à un service se voit analyser à chaque lancement de xinetd. Par défaut, xinetd.conf contient des paramètres de configuration de base qui s'appliquent à tous les services :

defaults
{
	instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success		= HOST PID
        log_on_failure		= HOST
}

includedir /etc/xinetd.d

Ces lignes contrôlent les différentes modalités d'application de xinetd :

• instances — Définit le nombre maximum de demandes d'accès qu'un service peut traiter à la fois.

• log_type — Invite xinetd à utiliser le journal authpriv, spécifié dans /etc/syslog.conf et configuré par défaut sur /var/log/secure, plutôt que d'utiliser un autre fichier spécifique. Si on utilisait FILE /var/log/xinetdlog à la place, xinetd effectuerait la journalisation dans un fichier /var/log/xinetdlog séparé.

• log_on_success — Définit ce que xinetd doit journaliser lorsque la connexion est établie avec succès. L'adresse IP de l'hôte distant et l'identifiant de processus du serveur traitant la demande d'accès sont enregistrés par défaut.

• log_on_failure — Définit ce que xinetd doit journaliser lorsque la connexion n'est pas établie ou est refusée. Les paramètres log_on_success et log_on_failure du fichier /etc/xinetd.conf sont souvent rajoutés par chacun des différents services, ce qui signifie que les connexions réussies et refusées à chacun des services journalisent généralement plus d'informations que ce qui est indiqué ici.

/etc/xinetd.conf et les fichiers de configuration xinetd spécifiques à des services offrent de multiples options de journalisation :

• ATTEMPT — Journalise le fait qu'une connexion manquée a eu lieu (log_on_failure).

• DURATION — Journalise la durée d'utilisation d'un service par un système distant (log_on_success).

• EXIT — Journalise l'état ou le signal de fin du service (log_on_success).

• HOST — Journalise l'adresse IP de l'hôte distant (log_on_failure et log_on_success).

• PID — Journalise l'identifiant de processus du serveur qui reçoit la demande d'accès (log_on_success).

• RECORD — Journalise les informations relatives au système distant dans le cas où le service n'aurait pu être lancé. Seuls des services spéciaux, tels que login et finger, peuvent utiliser cette option (log_on_failure).

• USERID — Journalise les données concernant l'utilisateur distant selon les directives définies dans RFC 1413 pour tous les services de type multi-thread (log_on_failure et log_on_success).

D'autres options sont disponibles pour /etc/xinetd.conf, telles que per_source, qui limite le nombre maximum de connexions depuis une adresse IP donnée à un service spécifique.

Fichiers du répertoire /etc/xinetd.d

Les différents fichiers qui se trouvent dans le répertoire /etc/xinetd.d sont lus à chaque démarrage de xinetd, grâce à l'instruction includedir /etc/xinetd.d insérée à la fin de /etc/xinetd.conf. Ces fichiers, appelés notamment finger, ipop3 et rlogin, se réfèrent aux différents services contrôlés par xinetd.

Les fichiers présents dans /etc/xinetd.d utilisent les mêmes règles et options que celles employées dans /etc/xinetd.conf. La raison première de leur séparation dans des fichiers de configuration, un pour chaque service, est de simplifier l'ajout ou la suppression de services du domaine de xinetd sans affecter ses autres services.

Pour se familiariser avec la structure de ces fichiers, prenons l'exemple du fichier wu-ftp :

service ftp
{
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/in.ftpd
        server_args             = -l -a
        log_on_success          += DURATION USERID
        log_on_failure          += USERID
        nice                    = 10
        disable                 = yes
}

La première ligne définit le nom du service en cours de configuration. Ensuite, les lignes entre accolades renferment des paramètres de démarrage et d'utilisation de ce service. Le fichier wu-ftp indique que le service FTP utilise un type de socket stream (plutôt que dgram), le type de fichier binaire exécutable à utiliser, les arguments à passer au binaire, l'information à journaliser en plus des paramètres de réglage de /etc/xinetd.conf, l'ordre de priorité d'exécution du service, etc.

L'utilisation de xinetd avec un certain service peut aussi servir comme degré de protection de base contre les attaques du type refus de service (DoS). L'option max_load utilise une valeur de point flottant pour déterminer le seuil d'utilisation du processeur limitant ainsi le nombre de connexions possibles pour un service spécifique et évitant toute surcharge du système. L'option cps permet d'utiliser une valeur entière pour définir de façon numérique le nombre maximum de connexions disponibles par seconde. En imposant une valeur basse, 3 par exemple, on empêche toute attaque inondant le système de demandes d'accès simultanées à un service donné.

Contrôle d'accès dans xinetd

Les utilisateurs de xinetd ont le choix entre le recours aux fichiers de contrôle d'accès aux hôtes TCP wrappers (hosts.allow et hosts.deny), l'autorisation d'accès par le biais de fichiers de configuration xinetd ou un mélange des deux. Les informations concernant l'utilisation des fichiers de contrôle d'accès aux hôtes TCP wrappers se trouvent dans la la section intitulée Listes de contrôle d'accès basé sur l'hôte. La prochaine section traite de l'utilisation de xinetd pour contrôler l'accès aux services qu'il est censé surveiller.

	Remarque
	A la différence des fichiers de contrôle d'accès aux hôtes TCP wrappers, toute modification aux fichiers de configuration xinetd requiert un redémarrage d'un service xinetd, de même qu'un redémarrage de tout service affecté par la modification, pour que celle-ci soit appliquée.

Le contrôle d'accès aux hôtes xinetd, disponible par le biais de ses multiples fichiers de configuration, est différent de celui employé par TCP wrappers. Alors que TCP wrappers regroupe toutes les configurations d'accès dans deux fichiers, /etc/hosts.allow et /etc/hosts.deny, chaque fichier de service contenu dans /etc/xinetd.d peut contenir des règles d'accès basées sur les hôtes qui seront autorisés à utiliser ce service.

Les options suivantes sont acceptées dans les fichiers xinetd pour contrôler l'accès des hôtes :

• only_from — Autorise les hôtes spécifiés à accéder au service.

• no_access — Empêche les hôtes spécifiés de se servir du service.

• access_times — Définit les heures de disponibilité du service. Cette plage horaire doit être spécifiée comme suit : HH:MM-HH:MM, en utilisant la forme 24 heures.

Les options only_from et no_access peuvent utiliser une liste préétablie d'adresses IP ou de noms d'hôte ou encore un réseau entier. Tout comme avec TCP wrappers, il est possible de mettre en commun les contrôles d'accès xinetd avec les configurations de journalisation dans le but non seulement d'empêcher les connexions, mais aussi d'enregistrer toute tentative d'accès aux services.

Par exemple, le fichier /etc/xinetd.d/telnet suivant peut être utilisé pour interdire l'accès via telnet à un groupe précis d'utilisateurs et limiter la plage horaire disponible aux utilisateurs autorisés :

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

Dans cet exemple, lorsqu'un ordinateur du sous-réseau 10.0.1.0/24, tel que 10.0.1.2, cherche à établir une connexion telnet avec l'hôte boo, le message Connection closed by foreign host. (connexion fermée par l'hôte étranger) lui est envoyé. De plus, cette tentative d'accès est journalisée dans le fichier /var/log/secure :

May 15 17:35:47 boo xinetd[16188]: START: telnet pid=16191 from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2
May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2
May 15 17:38:49 booxinetd[16252]: EXIT: telnet status=0 pid=16256

Liaison et réacheminement de port

Les fichiers de configuration de service xinetd prennent également en charge les liaisons de services vers une adresse IP spécifique et le réacheminement des demandes d'accès au service vers une autre adresse IP, un autre nom d'hôte ou un autre port.

Les liaisons, telles que définies par l'option bind dans les fichiers de configuration de service, relient explicitement les services vers une autre adresse IP utilisée par le système, autorisant ainsi l'accès au service uniquement lorsqu'il arrive par cette adresse IP. Ceci se révèle tout particulièrement utile lorsque la configuration du système comprend plusieurs cartes réseau et utilise des adresses IP multiples, tels que sur des ordinateurs employés comme pare-feu, avec une carte en contact avec Internet et l'autre reliée au réseau local. Aussi est-il possible d'empêcher des pirates essayant de se connecter à un service donné, tel que Telnet ou FTP, via Internet de se connecter au service alors que les utilisateurs internes peuvent se connecter au service via le NIC branché au réseau local.

L'option redirect, qui accepte une adresse IP ou un nom d'hôte suivi d'un numéro de port, indique au service de réacheminer toute demande pour ce service vers l'emplacement spécifié. Cette fonction peut être utilisée pour pointer vers un autre numéro de port sur le même système, réacheminer la demande vers une adresse IP différente sur le même ordinateur, passer la demande à un système et un numéro de port totalement différents ou mélanger ces diverses possibilités. De cette façon, il est possible de dérouter la connexion d'un utilisateur à un service donné d'un système sur un autre système sans aucune perturbation.

Le démon xinetd est en mesure d'effectuer cette redirection en générant un processus qui demeure actif pendant toute la durée de la connexion entre l'ordinateur client effectuant la demande et l'hôte qui fournit le service, transférant les données entre les deux systèmes.

Tout l'intérêt des options bind et redirect se concrétisent lorsqu'elles sont utilisées simultanément. En reliant un service à une adresse IP spécifique sur un ordinateur donné et en redirigeant les demandes d'accès à ce service vers un autre ordinateur reconnu uniquement par le premier, vous pouvez utiliser un système interne pour offrir des services à un réseau complètement différent. Autrement, ces options peuvent être utilisées pour limiter le risque d'exposition d'un service particulier résidant sur un ordinateur "multihomed" à une adresse IP connue et pour réacheminer toute demande d'accès à ce service vers un autre ordinateur spécialement configuré à cet effet.

Prenons par exemple un système utilisé comme pare-feu avec les réglages suivants pour son service FTP :

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

Les options bind et redirect de ce fichier s'assurent que le service FTP sur cet ordinateur est lié à l'adresse IP externe (123.123.123.123), celle qui est en contact direct avec le monde Internet. En outre, toute demande d'accès FTP envoyée à l'adresse 123.123.123.123 est réacheminée à l'aide d'une deuxième carte interface de réseau vers une adresse IP interne (10.0.1.13), accessible uniquement par le pare-feu et les systèmes internes. Ce même pare-feu établit ensuite les communications entre les deux systèmes et le système qui se connecte pensera s'être connecté à l'adresse 123.123.123.123 alors qu'il est en fait connecté à un tout autre ordinateur.

Cette caractéristique est particulièrement utile aux utilisateurs ayant des connexions à bande large et une seule adresse IP fixe. Lorsque l'on utilise le NAT (traducteur des adresses réseau), les systèmes en amont de l'ordinateur passerelle, qui utilisent des adresses IP uniquement internes, ne sont pas disponibles à à l'extérieur de la passerelle. Cependant, lorsque certains services contrôlés par xinetd sont configurés avec les options bind et redirect, l'ordinateur passerelle peut se comporter en serveur proxy entre les systèmes extérieurs et un ordinateur interne spécifique configuré pour garantir un service. De plus, les différentes options d'accès et de contrôle d'accès de xinetd peuvent être utilisées pour augmenter la sécurité en limitant le nombre d'accès simultanés vers le service réacheminé.