16.4. Fichiers de configuration de xinetd

Les fichiers de configuration de xinetd sont les suivants :

16.4.1. Le fichier /etc/xinetd.conf

Le fichier /etc/xinetd.conf contient des paramètres de configuration généraux ayant une influence sur tous les services placés sous le contrôle de xinetd. Il n'est lu que lors du lancement du service xinetd, par conséquent, afin que des changement apportés à la configuration puissent prendre effet, l'administrateur doit redémarrer le service xinetd. Ci-après figure 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 :

NoteRemarque
 

Les paramètres de log_on_success et log_on_failure dans /etc/xinetd.conf sont souvent encore modifiés dans les fichiers de journalisation spécifique à chaque service. Pour cette raison, plus d'informations peuvent parfois apparaître dans le journal d'un service donné que ce qui est en fait spécifié dans le fichier /etc/xinetd.conf. Reportez-vous à la Section 16.4.3.1 pour de plus amples informations sur les options de journalisation.

16.4.2. Le répertoire /etc/xinetd.d/

Le répertoire /etc/xinetd.d/ contient les fichiers de configuration relatifs à chaque service géré par xinetd ; ces derniers portent un nom faisant référence au service. De même que pour xinetd.conf, ce fichier est lu seulement lorsque le service xinetd est lancé. Ainsi, afin que tout changement puisse prendre effet, l'administrateur doit relancer le service xinetd.

Le format des fichiers dans le répertoire /etc/xinetd.d/ se base sur les même conventions que /etc/xinetd.conf. La raison essentielle de leur stockage dans des fichiers de configuration séparés est de faciliter la personnalisation et d'éviter qu'elle n'affecte les autres services.

Pour comprendre comment ces fichiers sont structurés, examinons le fichier /etc/xinetd.d/telnet :

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

Ces lignes contrôlent différents aspects du service telnet:

16.4.3. Modification des fichiers de configuration de xinetd

De nombreuses directives existent pour les services protégés de xinetd. Cette section souligne certaines des options les plus couramment utilisées.

16.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 de fin 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 de processus du serveur recevant la requête (log_on_success).

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

Pour une liste complètes des options de journalisation, consultez les pages de manuel relatives à xinetd.conf.

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

Les utilisateurs des services xinetd peuvent choisir d'utiliser les règles de contrôle d'accès des enveloppeurs TCP, de fournir 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 par l'hôte des enveloppeurs TCP se trouvent dans la Section 16.2.

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

NoteRemarque
 

À la différence des enveloppeurs TCP, les changements des contrôles d'accès ne prennent effet que si l'administrateur de xinetd relance le service xinetd.

De plus, à la différence des enveloppeurs TCP, le contrôle d'accès par xinetd affecte uniquement les services contrôlés par xinetd.

Le contrôle d'accès des hôtes à 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, soit /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 à l'intérieur du répertoire /etc/xinetd.d.

Les options suivantes d'accès des hôtes 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 une notation sur 24 heures et selon le format HH :MM-HH:MM.

Les options only_from et no_access peuvent utiliser une liste d'adresses IP ou de noms d'hôte, ou peuvent spécifier un réseau entier. Comme le font les enveloppeurs TCP, la combinaison du contrôle d'accès xinetd avec une configuration de journalisation améliorée permet d'accroître la sécurité non seulement en empêchant les requêtes provenant d'hôtes bannis mais en enregistrant également des informations détaillées sut chaque tentative de connexion.

Par exemple, le fichier suivant /etc/xinetd.d/telnet peut être utilisé pour non seulement bloquer l'accès à Telnet partir d'un groupe de réseau spécifique mais également limiter la fourchette de temps générale 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 recevra un message au contenu suivant :

Connection closed by foreign host.

De plus, les tentatives de connexions 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

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

Les informations suivantes montrent l'ordre des opérations suivi par xinetd lorsqu'un client demande à établir une connexion :

  1. Le démon xinetd accède aux règles d'accès par hôte des enveloppeurs TCP et ce par le biais d'un appel à la bibliothèque libwrap.a. Si une règle de refus s'applique à l'hôte client, la connexion est abandonnée. Si une règle d'autorisation 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 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.

ImportantImportant
 

Il est important de bien faire attention lors de l'utilisation des contrôles d'accès des enveloppeurs TCP en concert avec les contrôles d'accès de xinetd. En effet, une mauvaise configuration peut entraîner des effets indésirables.

16.4.3.3. Options de liaison et redirection

Les fichiers de configuration de service 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, nom d'hôte, ou port.

La liaison est contrôlée par l'option bind dans les fichiers de configuration d'un service spécifique 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 pour accéder au service. De cette manière, différents services peuvent se trouver liés à différentes interfaces réseau selon les besoins.

Cela 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 l'interface connectée à l'Internet.

L'option redirect accepte une adresse IP ou 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é. Cette fonction peut être employée pour diriger 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, rediriger la requête vers un système et numéro de port totalement différents, ou pour toute combinaison de ces options. 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 xinetdpeut accomplir cette redirection en produisant 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 réellement le service, transférant les données entre les deux systèmes.

Les avantages des options bind et redirect sont les plus évidents 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-sites à 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 cette configuration 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 dans ce fichier garantissent que le service Telnet sur cette machine est 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 de 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'en fait il est connecté à une machine différente.

Cette fonction est particulièrement utile pour les utilisateurs avec connexion à large bande et avec seulement une adresse IP fixe. Lors de l'utilisation de la traduction d'adresse 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 de 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 configurée pour fournir le service en question. De plus, les diverses options de contrôle d'accès xinetd et de journalisation peuvent servir à une protection supplémentaire.

16.4.3.4. Options de gestion de 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 maximum d'instances d'un service spécifique pour une adresse IP d'origine particulière. Elle n'accepte que comme argument que des chiffres entiers et peut être utilisée aussi bien dans xinetd.conf que dans des fichiers de configuration spécifiques à un service stockés dans le répertoire xinetd.d/.

  • cps — Détermine le nombre maximum de connexions par seconde. Cette directive accepte deux arguments avec des valeurs entières, séparés par un espace blanc. Le premier représente le nombre maximum 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 du 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.

Il existe encore d'autres options de gestion de ressources utilisables avec xinetd. Reportez-vous au chapitre intitulé Sécurité du serveur (Server Security) du Guide de sécurité de Red Hat Enterprise Linux pour obtenir de plus amples informations. Consultez également la page de manuel relative à xinetd.conf.