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.