Red Hat Linux 9: Guide de référence de Red Hat Linux | ||
---|---|---|
Prev | Chapter 15. Les enveloppeurs TCP et xinetd | Next |
Les fichiers de configuration de xinetd sont les suivants:
le fichier /etc/xinetd.conf — le fichier de configuration général de xinetd configuration file;
le répertoire /etc/xinetd.d/ — le répertoire contenant tous les fichiers spécifiques aux services.
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 divers aspects de xinetd:
instances — détermine le nombre maximum de requêtes qu'un service xinetd peut gérer à un moment donné.
log_type — indique à xinetd d'utiliser le journal authpriv qui enregistre des entrées de journalisation dans le fichier /var/log/secure. En ajoutant ici une directive comme FILE /var/log/xinetdlog un fichier de journalisation personnalisé portant le nom xinetdlog sera créé dans le répertoire /var/log/.
log_on_success — Configure xinetd de façon à ce qu'il journalise 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 du serveur traitant la requête.
log_on_failure — Configure xinetd de façon à ce qu'il journalise 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 à Section 15.4.2 Le répertoire /etc/xinetd.d/ pour plus d'informations sur ce répertoire.
![]() | Remarque |
---|---|
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 sont pafois enregistrées pour un service donné que ce qui est en fait spécifié dans le fichier-même. Reportez-vous à Section 15.4.3.1 Options de journalisation pour de plus amples informations sur les options de journalisation. |
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 trop 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:
service — Définit le nom du service, généralement pour correspondre à un service énuméré dans le fichier /etc/services.
flags — Définit tout attribut pour la connexion, parmi la variété disponible. REUSE donne l'instruction à xinetd de réutiliser le support pour une connexion Telnet.
socket_type — Spécifie le connecteur réseau 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 sera exécuté.
server — Définit le fichier binaire exécutable à lancer.
log_on_success — Détermine les paramètres de journalisation de log_on_success, en plus de ceux déjà définis dans xinetd.conf.
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.
nice — Détermine le niveau de priorité du serveur.
disable — Détermine si le service est actif ou non.
De nombreuses directives existent pour les services protégés de xinetd. Cette section souligne certaines des options les plus couramment utilisées.
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).
RECORD — Enregistre des informations sur le système distant dans le cas où le service ne peut pas être démarré. Seuls les services particuliers, comme login et finger peuvent utiliser cette option (log_on_failure).
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.
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 Section 15.2 Fichiers de configuration des enveloppeurs TCP. Cette section examine l'utilisation de xinetd pour contrôler l'accès aux services.
![]() | Remarque |
---|---|
À la différence des enveloppeurs TCP, les changements des contrôles d'accès ne prennent effet que si l'administrateur de xinetd administrator relance le service 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 fichier de chaque service dans /etc/xinetd.d peut contenir ses propres règles de contrôle d'accès.
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 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, la tentative de connexion est enregistrée 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:
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.
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.
![]() | Important |
---|---|
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. |
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 21 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, comme pour limiter le nombre de connexions simultanées pour ce service redirigé.
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 Linux pour obtenir de plus amples informations. Consultez également la page de manuel relative à xinetd.conf.