Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Guide de reference - Fichiers de configuration de xinetd

17.4. Fichiers de configuration de xinetd

Ci-dessous figurent les fichiers de configuration de xinetd�:

  • /etc/xinetd.conf — Le fichier de configuration global de xinetd.

  • /etc/xinetd.d/ — Le r�pertoire contenant tous les fichiers sp�cifiques aux services.

17.4.1. Fichier /etc/xinetd.conf

Le fichier /etc/xinetd.conf contient des param�tres de configuration g�n�raux qui influencent tous les services plac�s sous le contr�le de xinetd. Ce fichier n'est lu que lors du lancement du service xinetd, par cons�quent, afin que des changements 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

Les lignes pr�sentes dans l'extrait ci-dessus contr�lent les aspects suivants de xinetd�:

  • instances — D�termine le nombre maximal de requ�tes qu'un service xinetd peut g�rer � un moment donn�.

  • log_type — Configure xinetd de sorte qu'il utilise la facility de journalisation authpriv qui enregistre des entr�es de journalisation dans le fichier /var/log/secure. L'ajout d'un directive telle que FILE /var/log/xinetdlog entra�nerait la cr�ation d'un fichier de journalisation personnalis� portant le nom xinetdlog dans le r�pertoire /var/log/.

  • log_on_success — Configure xinetd de fa�on � ce qu'il effectue la journalisation si la connexion est �tablie avec succ�s. Par d�faut sont enregistr�s aussi bien l'adresse IP de l'h�te distant que l'ID de processus serveur traitant la requ�te.

  • log_on_failure — Configure xinetd de fa�on � ce qu'il effectue la journalisation si la connexion �choue ou si elle n'est pas autoris�e.

  • cps — Configure xinetd de mani�re � n'autoriser que 25 connexions par seconde � un service donn�. Si cette limite est atteinte, le service est retir� pendant 30 secondes.

  • includedir /etc/xinetd.d/ — Inclut des options stipul�es dans les fichiers de configuration sp�cifiques aux services qui se trouvent dans le r�pertoire /etc/xinetd.d/. Reportez-vous � la Section 17.4.2 pour obtenir de plus amples informations.

NoteRemarque
 

Souvent, aussi bien les param�tres log_on_success que log_on_failure pr�sents dans /etc/xinetd.conf font l'objet de modifications plus avanc�es dans les fichiers journaux sp�cifiques � chaque service. C'est la raison pour laquelle figurent parfois dans le journal d'un service donn� plus d'informations que ne l'indique le fichier /etc/xinetd.conf. Reportez-vous � la Section 17.4.3.1 pour obtenir de plus amples informations.

17.4.2. 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 contenus dans le r�pertoire /etc/xinetd.d/ se base sur les m�mes conventions que /etc/xinetd.conf. Chaque service est stock� dans un fichier de configuration s�par� afin de faciliter la personnalisation et d'�viter qu'elle n'affecte d'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
}

Les lignes de l'extrait ci-dessous contr�lent diff�rents aspects du service telnet�:

  • service — D�finit le nom du service, g�n�ralement pour correspondre � un service mentionn� dans le fichier /etc/services.

  • flags — D�finit une vari�t� d'attributs pour la connexion. L'option REUSE donne l'instruction � xinetd de r�utiliser le socket pour une connexion Telnet.

  • socket_type — Sp�cifie le socket comme �tant de type stream.

  • wait — D�termine si le service est mono-fil (single-threaded, yes) ou multi-fils (multi-threaded, no).

  • user — D�termine l'ID d'utilisateur sous lequel le processus est ex�cut�.

  • server — D�finit le fichier binaire ex�cutable devant �tre lanc�.

  • log_on_failure — D�termine les param�tres de journalisation de log_on_failure en plus de ceux d�j� d�finis dans xinetd.conf.

  • disable — D�termine si le service est actif.

17.4.3. Modification des fichiers de configuration de xinetd

Il existe une vaste gamme de directives pour les services prot�g�s par xinetd. Cette section souligne certaines des options les plus couramment utilis�es.

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.

NoteRemarque
 

� 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.

ImportantImportant
 

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire