17.4. Fichiers de configuration de xinetd

17.4.3.1. Options de journalisation

Les options de journalisation suivantes sont disponibles aussi bien pour /etc/xinetd.conf que pour les fichiers de configuration spécifiques à certains services stockés dans le répertoire /etc/xinetd.d/.

Ci-dessous figure une liste des options de journalisation les plus couramment utilisées :

• ATTEMPT — Enregistre une tentative qui a échoué (log_on_failure).

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

• EXIT — Enregistre le statut de sortie ou le signal d'arrêt d'un 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 du processus serveur recevant la requête (log_on_success).

• USERID — Enregistre l'utilisateur distant selon la méthode définie dans le document RFC 1413 pour tous les services en flux continu multi-fils (multi-threaded) (log_on_failure et log_on_success).

Pour obtenir une liste complète des options de journalisation, consultez la page de manuel de xinetd.conf.

17.4.3.2. Options de contrôle d'accès

Les utilisateurs de services xinetd peuvent choisir d'utiliser les règles de contrôle d'accès des enveloppeurs TCP, d'effectuer le contrôle d'accès par le biais des fichiers de configuration de xinetd ou de recourir à un mélange des deux. Des informations sur l'utilisation des fichiers de contrôle d'accès d'hôtes des enveloppeurs TCP se trouvent dans la Section 17.2.

Cette section examine l'utilisation de xinetd pour contrôler l'accès aux services.

	Remarque
	À la différence des enveloppeurs TCP, les modifications du contrôle d'accès ne prennent effet que si l'administrateur de xinetd redémarre le service xinetd. De plus, contrairement aux enveloppeurs TCP, le contrôle d'accès par xinetd concerne uniquement les services contrôlés par xinetd.

Le contrôle de l'accès des hôtes avec xinetd est différent de la méthode utilisée par les enveloppeurs TCP. Alors que ces derniers placent toutes les configurations d'accès dans deux fichiers, à savoir /etc/hosts.allow et /etc/hosts.deny, le contrôle d'accès avec xinetd se trouve dans le fichier de configuration de chaque service au sein du répertoire /etc/xinetd.d.

Les options d'accès des hôtes figurant ci-après sont prises en charge par xinetd :

• only_from — Permet seulement aux hôtes spécifiés d'utiliser le service.

• no_access — Empêche les hôtes spécifiés d'utiliser le service.

• access_times — Spécifie la fourchette de temps pendant laquelle un service particulier peut être utilisé. Cette durée doit être stipulée dans un format de notation sur 24 heures de type 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 également spécifier un réseau entier. Comme avec les enveloppeurs TCP, la combinaison du contrôle d'accès de xinetd avec une configuration de journalisation améliorée permet d'accroître la sécurité en empêchant les requêtes provenant d'hôtes bannis tout en enregistrant des informations détaillées sur chaque tentative de connexion.

Par exemple, le fichier suivant /etc/xinetd.d/telnet peut être utilisé non seulement pour bloquer l'accès à Telnet à partir d'un groupe de réseaux spécifiques mais également pour limiter la fourchette 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/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, lorsque tout système client provenant 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 reproduit ci-dessous, indiquant que la connexion a été fermée par un hôte étranger :

Connection closed by foreign host.

De plus, leurs tentatives de connexion sont enregistrées dans /var/log/secure de la manière suivante :

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 boo xinetd[16252]: EXIT: telnet status=0 pid=16256

Lorsque des enveloppeurs TCP sont utilisés de concert avec les accès de contrôle de xinetd, il est important de bien comprendre la relation existant entre les deux mécanismes de contrôle d'accès.

Ci-dessous figure l'ordre des opérations que xinetd suit lorsqu'un client demande à établir une connexion :

1. Le démon xinetd accède aux règles d'accès d'hôtes des enveloppeurs TCP par le biais d'un appel à la bibliothèque libwrap.a. Si une règle de refus (deny) s'applique à l'hôte client, la connexion est abandonnée. Si une règle d'autorisation (allow) s'applique à l'hôte client, la connexion est passée à xinetd.

2. Le démon xinetd vérifie ses propres règles de contrôle d'accès aussi bien pour le service xinetd que pour le service demandé. Si une règle de refus (deny) s'applique à l'hôte client, la connexion est abandonnée. Sinon, xinetd démarre une instance du service demandé et lui cède le contrôle de la connexion.

	Important
	Il convient d'être très prudent lors de l'utilisation des contrôles d'accès des enveloppeurs TCP conjointement avec les contrôles d'accès de xinetd. En effet, une mauvaise configuration peut entraîner des effets indésirables.

17.4.3.3. Options de liaison et redirection

Les fichiers de configuration de services pour xinetd prennent en charge la liaison du service à une adresse IP et la redirection de requêtes 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 bind dans les fichiers de configuration spécifiques à chaque service et lie le service à une adresse IP dans le système. Une fois configurée, l'option bind autorise seulement des requêtes pour l'adresse IP adéquate à se connecter au service. De cette manière, différents services peuvent se trouver liés à différentes interfaces réseau selon les besoins.

Cet aspect est particulièrement utile pour les systèmes à adaptateurs de réseaux multiples ou ayant de multiples adresses IP configurées. Sur un tel système, des services non-sécurisés, comme Telnet, peuvent être configurés de manière à recevoir des requêtes seulement sur l'interface connectée à un réseau privé et pas sur l'interface connectée à l'Internet.

L'option redirect accepte une adresse IP ou un nom d'hôte suivi par un numéro de port. Elle permet de configurer le service de manière à ce qu'il redirige toute requête pour ce service vers l'hôte et le numéro de port spécifiés. Cette fonction peut être employée pour pointer vers un autre numéro de port sur le même système, rediriger la requête vers une autre adresse IP sur la même machine, déplacer la requête vers un système et numéro de port totalement différents ou pour utiliser toute combinaison des options mentionnées. De cette façon, un utilisateur se connectant à un certain service sur un système peut être rerouté vers un autre système sans interruption.

Le démon xinetd peut accomplir cette redirection en créant un processus qui reste actif pour la durée de la connexion entre l'ordinateur du client effectuant la requête et l'hôte fournissant le service proprement dit, en transférant les données entre les deux systèmes.

Les avantages des options bind et redirect se remarquent le plus lorsque ces options sont utilisées ensemble. En liant un service à une adresse IP particulière sur un système puis en redirigeant les requêtes pour ce service vers une seconde machine que seule la première peut percevoir, il est possible d'utiliser un système interne pour fournir des services à un réseau totalement différent. Ces options peuvent également être utilisées pour non seulement limiter l'exposition d'un service particulier sur un ordinateur multi-site à une adresse IP connue mais aussi pour rediriger toute requête pour ce service vers une autre machine spécialement configurée à cet effet.

Examinons par exemple le cas d'un système utilisé comme pare-feu avec ce paramétrage pour son service Telnet :

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 23
}

Les options bind et redirect présentes dans ce fichier garantissent que le service Telnet sur cette machine soit lié à l'adresse IP externe (123.123.123.123), celle qui prend en charge l'Internet. De plus, toute requête de service Telnet envoyée vers 123.123.123.123 est redirigée via un second 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 se connectant pense qu'il est connecté à 123.123.123.123 alors qu'il est en fait connecté à une machine différente.

Cette fonction est particulièrement utile pour les utilisateurs avec des connexion à large bande et avec seulement une adresse IP fixe. Lors de l'utilisation de la traduction d'adresses de réseau (ou NAT de l'anglais Network Address Translation), les systèmes situés derrière la machine passerelle, qui utilisent des adresses IP exclusivement internes, ne sont pas disponibles depuis l'extérieur du système passerelle. Toutefois, avec certains services contrôlés par xinetd et configurés avec les options bind et redirect, la machine passerelle peut servir de proxy entre les systèmes externes et une machine interne particulière qui est configurée pour fournir le service en question. De plus, les diverses options de contrôle d'accès et de journalisation de xinetd peuvent également servir comme protections supplémentaires.

17.4.3.4. Options de gestion des ressources

Le démon xinetd permet d'ajouter un niveau élémentaire de protection contre des attaques de Refus de service (ou DoS, de l'anglais Denial of Service). Ci-dessous figure une liste des directives pouvant aider à limiter l'efficacité de telles attaques :

• per_source — Détermine le nombre maximal d'instances d'un service spécifique en fonction de l'adresse IP d'origine. Elle n'accepte comme argument que des chiffres entiers et peut être utilisée aussi bien dans xinetd.conf que dans des fichiers de configuration spécifiques aux services stockés dans le répertoire xinetd.d/.

• cps — Détermine le nombre maximal de connexions par seconde. Cette directive accepte deux arguments sous forme de valeurs entières séparés par un espace blanc. Le premier représente le nombre maximal de connexions autorisées à un service par seconde. Le deuxième correspond au nombre de secondes pendant lequel xinetd doit attendre avant de réactiver le service. Il n'accepte que des nombres entiers comme argument et peut être utilisé aussi bien dans xinetd.conf que dans les fichiers de configuration spécifiques au service contenus dans le répertoire xinetd.d/.

• max_load — Définit le seuil d'utilisation d'un processeur (CPU) pour un service. Cette directive accepte un argument avec une valeur flottante.

D'autres options peuvent être utilisées pour la gestion des ressources avec xinetd. Reportez-vous au chapitre intitulé Sécurité du serveur du Guide de sécurité de Red Hat Enterprise Linux pour obtenir de plus amples informations. Consultez également la page de manuel de xinetd.conf.