xinetd.conf − Fichier de configuration du démon amélioré des services Internet

xinetd.conf est le fichier de configuration qui définit les services fournis par xinetd. Toutes les lignes dont le premier caractère est un « # » sont considérées comme des lignes de commentaires. Les lignes vides sont ignorées.

Le fichier contient des entrées de la forme :

service <nom_du_service>
{
       <attribut> <assign_op> <valeur> <valeur> ...
       ...
}

L’opérateur d’assignation, assign_op, peut être l’un des suivants « = », « += », « -= ». La majorité des attributs ne supporte que l’opérateur d’assignation simple, « = ». Les attributs dont la valeur est un ensemble de valeurs supportent tous les opérateurs d’assignation. Pour de tels attributs, « += » signifie ajouter une valeur à l’ensemble des valeurs et « -= » signifie supprimer une valeur de l’ensemble des valeurs. Une liste de ces attributs sera donnée après que tous ces attributs aient été décrits.

Chaque entrée définit un service identifié par nom_du_service. Voici une liste des attributs disponibles :

id

Cet attribut est utilisé pour identifier de façon exclusive un service. Ceci est important, car il y a des services qui peuvent utiliser plusieurs protocoles et qui doivent être décrit avec des entrées différentes dans le fichier de configuration. Par défaut, l’identificateur du service porte le nom du service.

type

N’importe quelle combinaison des valeurs suivantes peut être utilisée :

RPC

si c’est un service RPC

INTERNAL

si c’est un service fourni par xinetd.

UNLISTED

pour un service qui n’est pas listé dans un fichier système standard (comme /etc/rpc pour les services RPC, ou /etc/services Pour les services non-RPC).

flags

N’importe quelle combinaison des flags

suivants peut être utilisée :

REUSE

Positionne le flag SO_REUSEADDR sur la socket du service (voir setsockopt(2) pour plus d’information).

INTERCEPT

Intercepte les paquets ou les connexions acceptées afin de vérifier qu’elles proviennent d’une adresse autorisée (les services internes ou multi-threadés ne peuvent pas être interceptés).

NORETRY

Empêche les tentatives d’essayer à nouveau dans le cas d’une impossibilité de forker.

IDONLY

Accepte les connexions seulement si l’utilisateur distant est identifié par la machine distante (i.e. la machine distante doit utiliser un serveur d’identification). Ce flag ne s’applique qu’aux services orientés-connexion. Ce flag est sans effet si l’option de logging USERID n’est pas utilisée.

NAMEINARGS

Ceci va forcer le premier argument de « server_args » à prendre la valeur de argv[0] quand le serveur est démarré, comme cela est spécifié dans « server ». Ceci vous permet d’utiliser tcpd en mettant tcpd comme valeur pour « server » et le nom du serveur comme valeur pour « server_args », comme pour la configuration de inetd.

NODELAY

Si le service est un service TCP et que le flag NODELAY est positionné, alors le flag TCP_NODELAY sera positionné sur la socket. Si ce service n’est pas un service TCP, cette option n’a aucun effet.

DISABLE

Le flag DISABLE indique que ce service doit être désactivé. Ce flag prend le pas sur la directive « enabled » positionnée par défaut. Par exemple si vous mettez « enabled = foo », et que foo a le flag DISABLE, foo ne sera pas démarré. L’utilisation de ce flag avec la directive « disable » n’est pas recommandée, les résultats étant imprévisibles.

KEEPALIVE

Si le service est un service TCP et que le flag KEEPALIVE est positionné, alors le flag SO_KEEPALIVE sera positionné sur la socket. Si ce service n’est pas un service TCP, cette option n’a aucun effet.

NOLIBWRAP

Ceci désactive l’appel interne à la librairie tcpwrap qui détermine l’accès au service. Ceci peut être nécessaire si l’on désire utiliser les fonctionnalités de la librairie libwrap qui ne sont pas disponibles pour les processus de longue durée comme xinetd ; dans ce cas, le programme tcpd peut être explicitement appelé (voir aussi le flag NAMEINARGS).

SENSOR

Ce flag remplace le service avec un détecteur qui détecte les accès au port spécifié. NOTE : Les scans furtifs ne seront PAS détectés. Ce flag doit être utilisé seulement pour les services dont vous êtes sûr de ne pas avoir besoin. Quand un accès est fait sur le port de ce service, l’adresse IP est ajoutée à une liste d’adresses interdites. Cela implique que tous les accès en provenance de cette adresse IP seront interdits jusqu’à l’expiration du délai indiqué dans deny_time. Le temps passé sur cette liste est paramétrable par l’attribut deny_time. Le flag SENSOR va aussi obliger xinetd à considérer l’attribut du serveur comme un attribut INTERNE sans se soucier de ce qu’il y a sur la même ligne. Autre chose importante, il ne faut pas oublier que si socket_type est de type stream, alors l’attribut wait doit être positionné à no.

disable

ce flag est de type booléen « yes » ou

« no ». Ceci indique si le service est désactivé et ne doit pas démarrer ou non. Voir la description du flag DISABLE.

socket_type

les valeurs possibles pour cet attribut sont :

stream

service de type stream

dgram

service de type datagramme

raw

service qui demande un accès direct à IP

seqpacket

service qui demande une transmission de type datagramme séquentielle et fiable

protocol

détermine quel est le protocole employé

par le service. Le protocole doit être présent dans le fichier /etc/protocols. Si cet attribut n’est pas défini, le protocole par défaut utilisé par le service sera utilisé.

wait

Cet attribut détermine si le service est de type mono-thread ou multi-thread. Si la valeur est yes le service est de type mono-thread ; cela signifie que xinetd démarrera le serveur et ne prendra plus en charge aucune requêtes pour ce service jusqu’à l’arrêt du serveur. Si la valeur de l’attribut est no, le service est de type multi-thread et xinetd continuera à prendre en charge les requêtes pour ce service.

user

détermine l’uid pour le processus serveur. L’utilisateur doit exister dans le fichier /etc/passwd. Cet attribut est sans effet si xinetd n’a pas été démarré sous l’uid du super-utilisateur.

group

détermine le gid pour le processus serveur. Le groupe doit exister dans le fichier /etc/group. Si le groupe n’est pas spécifié, le groupe de l’utilisateur user sera utilisé (récupéré dans le fichier /etc/passwd). Cet attribut est sans effet si xinetd n’a pas été démarré sous l’uid du super-utilisateur.

instances

détermine le nombre de serveurs qui peuvent être actifs simultanément pour un service (par défaut il n’y a pas de limite). La valeur de cet attribut peut être soit un nombre, soit UNLIMITED ce qui signifie qu’il n’y a aucune limite.

nice

détermine la priorité du serveur. La valeur est un nombre (qui peut être négatif) ; voyez le man de nice(3) pour plus d’information.

server

détermine le programme à exécuter pour ce service.

server_args

détermine les arguments passés au serveur. Contrairement à inetd, le nom du serveur ne doit pas se trouver dans l’attribut server_args.

only_from

détermine quels sont les hôtes autorisés à accéder au service. Sa valeur est une liste d’adresses IP qui peuvent être spécifiées par n’importe laquelle des combinaisons suivantes :

a)

une adresse numérique de la forme %d.%d.%d.%d. si les champs de droite sont des zéros ils ont traités comme des wildcards (par exemple, 128.138.12.0 représente tous les hôtes du réseau 128.138.12). 0.0.0.0 représente toutes les adresses du réseau Internet.

b)

une adresse factorisée de la forme %d.%d.%d.{%d,%d,...}. Il n’est pas nécessaire que les 4 octets soient représentés (par exemple %d.%d.{%d,%d,...%d} est correct). Cependant la partie factorisée doit être la dernière.

c)

un nom de réseau (présent dans le fichier /etc/networks)

d)

un nom d’hôte. Quand une connexion est faite vers xinetd, une résolution inverse est effectuée, et le nom canonique renvoyé est comparé au nom d’hôte spécifié. Vous pouvez aussi utiliser les noms de domaines sous la forme de .domain.com. Si la résolution inverse de l’IP du client appartient au domaine .domain.com, alors la règle est vérifiée.

e)

un couple ip addresse/netmask de la forme 1.2.3.4/32.

Spécifier cet attribut sans une valeur, rend le

service indisponible pour tous

no_access

détermine quels ont les hôtes pour lesquels un service particulier n’est pas disponible. Sa valeur peut être spécifiée de la même façon que pour l’attribut only_from. Ces deux attributs déterminent le contrôle d’accès des hôtes effectué par xinetd. Si aucun des deux attributs n’est spécifié pour un service, le service est disponible pour n’importe quel hôte. Si les deux sont spécifiés pour un service celui qui a la meilleure correspondance pour l’hôte distant, détermine si le service est disponible pour cet hôte. (par exemple, si only_from contient 128.138.209.0 et que no_access contient 128.138.209.10 alors l’hôte avec l’adresse 128.138.209.10 ne peut pas accéder au service).

access_times

détermine l’intervalle de temps pendant lequel le service est disponible. Un intervalle de temps est de la forme heure:minute-heure:minute (les connexions seront acceptées durant un intervalle de temps). Les heures vont de 0 à 23 et les minutes de 0 à 59.

log_type

détermine où seront envoyés les logs de sortie. Il y a deux formats :

SYSLOG syslog_facility [syslog_level]

Les logs sont envoyés à syslog avec l’option spécifiée. Les différentes options sont pour les noms : daemon, auth, authpriv, user, local0-7. pour les niveaux d’alerte : emerg, alert, crit, err, warning, notice, info, debug. Si le niveau d’alerte n’est pas précisé, les messages seront traités avec le niveau info.

FICHIER fichier [soft_limit [hard_limit]]

Les logs sont ajoutés au fichier qui sera créé si il n’existe pas. Deux limites peuvent être spécifiées pour la taille du fichier de log. La première limite est de type soft (souple) ; xinetd va envoyer un message dès que cette limite est dépassée (si xinetd envoie ses messages à syslog, le message sera envoyé avec un niveau de priorité alert ). La deuxième limite est de type hard (rigide) ; xinetd va arrêter le logging pour le service concerné (si le fichier de log est commun à plusieurs services, plusieurs services peuvent être affectés) et généreront un message à ce sujet (si xinetd envoie ses logs à syslog, le message sera envoyé avec le niveau de priorité alert ). Si la limite hard n’est pas spécifiée, elle sera par défaut égale à la limite souple augmentée de 1%, mais la taille supplémentaire doit être située entre les 2 valeurs suivantes : LOG_EXTRA_MIN et LOG_EXTRA_MAX qui ont pour valeur par défaut respectivement 5K et 20K (ces constantes sont définies dans le fichier config.h).

log_on_success

détermine quelles sont les informations logguées quand le serveur est démarré et quand il est arrêté (l’identificateur du service est toujours présent dans la ligne de log). N’importe quelle combinaison des valeurs suivantes peut être spécifiée :

PID

loggue l’identificateur du processus serveur (si le service est implémenté par xinetd sans forker un nouveau processus, l’identificateur du processus loggué sera 0)

HOST

loggue l’adresse de l’hôte distant

USERID

loggue l’id utilisateur de l’utilisateur distant en utilisant le protocole d’identification suivant la RFC 1413. Cette option est disponible seulement pour les services muti thread de type stream.

EXIT

loggue l’état de sortie du serveur, qui peut être l’état exit ou le signal de terminaison (l’identificateur de processus est aussi loggué si l’option PID est utilisée)

DURATION

loggue la durée d’une session pour le service concerné

log_on_failure

détermine quelles sont les

informations logguées quand un serveur ne peut démarrer (soit par un manque de ressources système, soit à cause des restrictions d’accès). L’identificateur du service est toujours loggué ainsi que que la raison de la panne. N’importe quelle combinaison des valeurs suivantes peut être spécifiée :

HOST

loggue l’adresse de l’hôte distant.

USERID

loggue l’id utilisateur de l’utilisateur distant en utilisant le protocole d’identification suivant la RFC 1413. Cette option est disponible seulement pour les services muti thread de type stream.

ATTEMPT

loggue le fait qu’une tentative a été faite et a échoué (cette option est impliquée par toute les autres).

RECORD

enregistre des informations venant du client distant au cas ou le serveur ne puisse être démarré. Ceci permet de logguer les tentatives de connexion au service. Par exemple, le service login loggue l’utilisateur local, l’utilisateur distant et le type de terminal. Actuellement, les services qui supportent cette option sont : login, shell, exec, finger.

rpc_version

détermine la version RPC pour un

service RPC. La version peut être un nombre simple ou une plage de la forme chiffre-chiffre.

rpc_number

détermine le numéro pour un service RPC NON LISTà (cet attribut est ignoré si le service est connu).

env

La valeur de cet attribut est une liste de chaînes de caractères de la forme « nom=valeur ». Ces chaînes seront ajoutées aux variables d’environnement avant de démarrer un serveur (par conséquent l’environnement du serveur sera constitué de l’environnement de xinetd plus les chaînes spécifiées).

passenv

La valeur de cet attribut est une liste de variables d’environnement de l’environnement de xinetd qui sera passée au serveur. Si la liste est vide cela signifie qu’aucune variable n’est passée au serveur, excepté celles passées avec l’attribut env. (notez que vous pouvez utiliser cet attribut en même temps que l’attribut env pour spécifier précisément quels attributs seront passés au serveur).

port

détermine le port du service. Si cet attribut est spécifié pour un service déjà listé dans le fichier /etc/services, il doit avoir le même numéro de port que celui listé dans ce fichier.

redirect

Autorise un service tcp à être redirigé vers une autre machine. Quand xinetd reçoit une connexion tcp sur ce port, il lance un processus qui établit une connexion vers l’hôte et le numéro de port spécifié, et transmet toute les données entre les deux machines. Cette option est très utile quand votre réseau interne n’est pas visible depuis l’extérieur. La syntaxe est : redirect = (adresse ip) (port). Vous pouvez aussi utiliser un nom de machine à la place de l’adresse IP dans ce champ. La résolution du nom n’est effectuée qu’une seule fois, lorsque xinetd est lancé, et la première adresse IP renvoyée est celle qui sera utilisée, jusqu’à ce que xinetd soit redémarré. L’attribut « server » n’est pas requis lorsque cette option est spécifiée. Si l’attribut « server » est spécifié, il est est prioritaire.

bind

Autorise un service à être limité à une interface réseau spécifique sur la machine. Cela signifie que vous pouvez avoir un serveur telnet à l’écoute sur une interface sécurisée du réseau local, mais pas sur l’interface du réseau externe. Ou bien un port sur une interface peut effectuer une action, tandis que le même port sur une autre interface peut faire quelque chose de complètement différent. La syntaxe est : bind = (adresse ip de l’interface).

interface

Synonyme de bind.

banner

Prend le nom du fichier dont le contenu sera affiché sur l’hôte distant lorsque la connexion à ce service sera établie. Cette bannière est affichée sans tenir compte du contrôle d’accès. Elle doit toujours être affichée lorsqu’une connexion est faite.

banner_success

Prend le nom du fichier dont le contenu sera affiché sur l’hôte distant lorsque une connexion à ce service est autorisé. Cette bannière est affichée dès que l’accès au service est permis.

banner_fail

Prend le nom du fichier dont le contenu sera affiché sur l’hôte distant lorsque une connexion à ce service est refusée. Cette bannière est affichée dès que l’accès au service est refusé. Cela est utile pour informer les utilisateurs qu’ils sont en train de faire quelque chose qui n’est pas autorisé, et qu’il ne doivent pas continuer.

per_source

Prend un entier ou un « UNLIMITED » comme argument. Ce paramètre spécifie le nombre maximum d’instances autorisées pour ce service par adresse IP source. Cela peut aussi être spécifié dans la section defaults.

cps

Limite le taux de connexions entrantes. Prends deux arguments. Le premier argument est le nombre de connexions par seconde à prendre en charge. Si le taux de connexions est plus élevé que celui précisé, le service sera désactivé temporairement. Le deuxième argument est le nombre de secondes qu’il faut attendre pour rétablir le service après sa désactivation.

max_load

Reçoit un nombre décimal qui représente la charge maximale que le service peut accepter, une fois ce chiffre atteint, aucune nouvelle connexion ne sera acceptée. Par exemple : 2 ou 2.5. Le service n’acceptera plus de connexions lorsque cette charge sera atteinte. Il représente la charge moyenne durant une minute. Cette caractéristique est dépendante du système d’exploitation, et n’est pour l’instant supportée que par Linux et Solaris.

groups

Cette option peut être définie à « yes » ou « no ». Si l’attribut de groupe est positionné à « yes », alors le serveur est lancé avec l’accès aux groupes dont l’UID effectif du serveur à accès. Si l’attribut de groupe est positionné à « no », alors le serveur fonctionnera sans groupe supplémentaire. Cet attribut doit être positionné à « yes » pour beaucoup de systèmes BSD. Cet attribut peut aussi être activé dans la section defaults.

umask

Positionne le umask pour le service. Une valeur octale est attendue. Cette option peut être activée dans la section « defaults » pour choisir un umask pour l’ensemble des services. xinetd positionne son propre umask avec la valeur précédente de l’umask et un OU logique avec 022. C’est cette valeur de umask sera transmise à tous les processus enfants si l’option umask n’est pas utilisée.

enabled

Prend une liste des noms des services à activer. Cela activera seulement les services qui seront dans la liste d’arguments de cet attribut ; les autres seront désactivés. Remarquez que l’attribut « disable » et le flag « DISABLE » peuvent empêcher un service d’être activé, même si il est listé dans les arguments de cet attribut.

include

Prends un fichier de la forme « include /etc/xinetd/service ». Le fichier est alors parcouru comme un nouveau fichier de configuration. Ce n’est pas la même chose que si le contenu du fichier était inclus dans xinetd.conf à l’emplacement de la directive include. Le fichier inclus doit être au même format que xinetd.conf. Cela ne doit pas être spécifié à l’intérieur d’un service. Ce doit être spécifié en dehors de la déclaration d’un service.

includedir

Prends un nom de répertoire de la forme « includedir /etc/xinetd.d ». Chaque fichier à l’intérieur de ce répertoire, mis à part les fichiers contenant un point (« . ») ou se terminant par un tilde (« ~ »), seront parcourus comme des fichiers de configuration de xinetd. Les fichiers seront parcourus par ordre alphabétique en se référant à la variable d’environnement C locale. Cela vous permet de spécifier un services par fichier à l’intérieur de ce répertoire. La directive includedir ne doit pas être spécifiée à l’intérieur d’une déclaration de service.

rlimit_as

Positionne la limite des ressources de l’espace d’adressage pour le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d’octets de cette limite (K ou M peuvent être utilisés pour spécifier des kilooctets/megaoctets) soit « UNLIMITED ». à cause de la manière dont la fonction malloc de la libc de Linux est implémentée, il est plus efficace d’utiliser cette limite que celles de rlimit_data, rlimit_rss et rlimit_stack. Cette limite des ressources n’est implémentée que sur les systèmes Linux.

rlimit_cpu

Positionne le nombre maximum de secondes utilisées par le CPU pour le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre de secondes utilisées par le CPU, soit « UNLIMITED ».

rlimit_data

Positionne la limite maximale pour la taille de données utilisées par le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d’octets, soit « UNLIMITED ».

rlimit_rss

Positionne la limite de la taille mémoire résidante pour le service. Si cette limite est basse, le processus aura tendance à swapper sur le disque dur si la mémoire libre est faible. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d’octets, soit « UNLIMITED ».

rlimit_stack

Positionne la taille maximale de la pile pour le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d’octets, soit « UNLIMITED ».

deny_time

Paramètre l’intervalle de temps durant lequel l’accès à tous les services pour toutes les adresses IP est refusé à quelqu’un dont la variable SENSOR à été positionnée à off. L’unité de temps est la minute. Les options valides sont : FOREVER, NEVER, ou une valeur numérique. FOREVER fait que l’adresse IP concernée n’est pas purgée tant que xinetd n’est pas redémarré. NEVER fait que l’adresse IP est juste logguée. Un valeur de temps typique est 60 minutes. Cela doit arrêter la plupart des attaques par déni de service (DOS attacks ) et autorise les adresses IP venant d’un pool d’adresses à être recyclées pour des besoins légitimes. Cette option doit être utilisée avec le flag SENSOR.

Il n’est pas nécessaire de spécifier tous les attributs précités pour chaque service. Les attributs nécessaires pour un service sont :

socket_type

user

(seulement pour les services non-internes)

server

(seulement pour les services non-internes)

wait

protocol

(seulement pour le service RPC et pour les services non-listés )

rpc_version

(seulement pour le service RPC )

rpc_number

(seulement pour les services RPC non-listés )

port

(seulement pour les services non-RPC et non-listés )

Les attributs suivants supportent tous les opérateurs d’assignation :

only_from

no_access

log_on_success

log_on_failure

passenv

env

(ne supporte pas l’opérateur « -= » )

Ces attributs peuvent apparaître plus d’un fois pour un même service. Les attributs restants ne supportent que l’opérateur « = » et ne peuvent apparaître plus d’une fois pour un service.

Le fichier de configuration peut aussi contenir une seule entrée par défaut qui a la forme

defaults
{
       <attribut> = <valeur> <valeur> ...
       ...
}

Cette entrée fournit des valeurs d’attribut par défaut pour les service qui ne spécifient pas ces attributs. Les attribut par défaut possibles sont :

log_type

log_on_success

(effet cumulatif)

log_on_failure

(effet cumulatif)

only_from

(effet cumulatif)

no_access

(effet cumulatif)

passenv

(effet cumulatif)

instances

disabled

(effet cumulatif)

enabled

(effet cumulatif)

Les attributs avec un effet cumulatif peuvent être spécifiés plusieurs fois avec les valeurs spécifiées qui s’accumulent à chaque fois (par exemple « = » fait la même chose que « += »). à l’exception de disabled ils ont tous la même signification que si ils étaient spécifiés pour un service. disabled détermine les services qui sont désactivés même si ils sont appelés dans le fichier de configuration. Cela permet une reconfiguration rapide en spécifiant les services désactivés avec l’attribut disabled au lieu de tous les commenter. La valeur de cet attribut est une liste d’identificateurs séparés par des espaces. enabled a les mêmes propriétés que l’attribut disabled. La différence étant que enabled est une liste de services qu’il faut activer. Si enabled est spécifié, il n’y a que les services spécifiés qui sont disponibles. Si enabled n’est pas spécifié, tous les services sont supposés être activés, excepté ceux qui sont listé par l’attribut disabled.

xinetd fournit en interne les services suivants (à la fois ceux de type stream et ceux de type datagramme) : echo, time, daytime, chargen, et discard. Ces services ont les mêmes règles d’accès que les autres services, sauf pour ceux qui ne demandent pas à xinetd de forker un nouveau processus pour eux. Ceux-ci (time, daytime, et le echo de type datagram, chargen, et discard) n’ont aucune limitations de leur nombre d’ instances.

xinetd fournit aussi deux services internes NON-LISTÃS de type stream : servers et services. Le premier liste les informations concernant les serveurs qui tournent, alors que le dernier fournit une liste des services actuellement actifs. Il y a un service par ligne et chaque ligne contient le nom du service, le protocole (par exemple « tcp ») et le numéro de port.

Il existe maintenant une interface d’administration qui est un service interne. Le nom du service « xadmin » est réservé, et sera toujours un service interne. Vous devez spécifier un numéro de port pour ce service, et probablement un contrôle d’accès basé sur l’adresse IP, car à l’heure ou nous écrivons ces lignes, il n’y a aucune protection par mot de passe. Vous pouvez faire un telnet sur ce port et demander des informations à xinetd.

1.

Les attributs des services suivants ne peuvent être changés lors d’une reconfiguration : socket_type, wait, protocol, type.

2.

Lorsque les attributs only_from et no_access ne sont pas spécifiés pour un service (que ce soit directement ou par l’option defaults) la vérification d’adresse est considérée comme bonne (c’est à dire que l’accès ne sera pas refusé).

3.

La vérification d’adresse est basée sur l’adresse IP de la machine distante et non pas sur son nom de domaine. Cela est fait pour éviter la résolution de nom de la machine distante, qui peut prendre beaucoup de temps (comme xinetd est single-threaded, pendant la résolution de nom le démon ne pourrait pas accepter d’autres requêtes, jusqu’à ce que la résolution de nom soit terminée). Le mauvais coté de cette approche est que si l’adresse IP d’une machine distante change, alors il est possible que l’accès à cette machine soit refusé jusqu’à ce que xinetd soit reconfiguré. L’accès sera refusé ou non, suivant que la nouvelle adresse IP sera parmi celle autorisées ou non. Par exemple si l’adresse IP d’un hôte passe de 1.2.3.4 à 1.2.3.5 et que only_from spécifie 1.2.3.0 alors l’accès ne sera pas refusé.

4.

Si l’option de log USERID est spécifiée et que la machine distante, soit ne fait pas tourner un serveur d’identification, soit renvoie une réponse incorrecte, l’accès ne sera pas refusé à moins que le flag de service IDONLY soit utilisé.

5.

L’interception fonctionne en clonant un processus qui fait office de filtre entre la ou les machine(s) distante(s) et le serveur local. Cela a évidemment un impact sur les performances, il est donc de votre ressort d’établir un bon compromis entre la sécurité et les performances pour chacun des services. La table suivante montre le coût lié à l’interception. Le premier tableau montre le cout-par-datagramme en terme de temps pour un service de type UDP, utilisant diverses tailles de datagrammes. Pour les services de type TCP, nous avons mesuré la diminution de bande passante due à l’interception, pendant que nous envoyons une certaine quantité de données depuis le client vers le serveur (la perte de temps est la même que pour les services de type UDP, mais elle est « payée » seulement lors de la transmission du premier paquet de données ). Le montant de données est donné dans le tableau par appels_systèmexdata_envoyé_par_appel, c’est à dire chaque appel système envoyé(2) à transféré tant d’octets de données. La réduction de bande passante est donnée en terme d’octets par secondes et comme un pourcentage de bande passante lorsque l’interception n’est pas effectuée. Toute les mesures ont été effectuées sur une SparcStation IPC sous SunOS 4.1.

Taille du datagramme (octets)

Latence (msec)

---------------------

--------------

64

1.19

256

1.51

1024

1.51

4096

3.58

Octets envoyés

Réduction de bande passante

----------

-------------------

10000x64

941 (1.2%)

10000x256

4,231 (1.8%)

10000x1024

319,300 (39.5%)

10000x4096

824,461 (62.1%)

#
# Exemple de fichier de configuration pour xinetd
#

defaults
{

log_type

= FILE /var/log/servicelog

log_on_success

= PID

log_on_failure

= HOST RECORD

only_from

= 128.138.193.0 128.138.204.0 128.138.209.0

only_from

= 128.138.252.1

instances

= 10

disabled

= rstatd

}

#
# Note 1 : l’attribut du protocole n’est pas requis
# Note 2 : l’attribut d’instances écrase l’attribut par défaut
#
service login
{

socket_type

= stream

protocol

= tcp

wait

= no

user

= root

server

= /usr/etc/in.rlogind

instances

= UNLIMITED

}

#
# Note 1 : l’attribut d’instances écrase l’attribut par défaut
# Note 2 : les flags log_on_success sont incrémentés
#
service shell
{

socket_type

= stream

wait

= no

user

= root

instances

= UNLIMITED

server

= /usr/etc/in.rshd

log_on_success

+= HOST RECORD

}

service ftp
{

socket_type

= stream

wait

= no

nice

= 10

user

= root

server

= /usr/etc/in.ftpd

server_args

= -l

instances

= 4

log_on_success

+= DURATION HOST USERID

access_times

= 2:00-9:00 12:00-24:00

}

# Limite les sessions telnet à 8 Méga octets de mémoire et un total de
# 20 secondes de temps CPU pour les processus fils.
service telnet
{

socket_type

= stream

wait

= no

nice

= 10

user

= root

server

= /usr/etc/in.telnetd

rlimit_as

= 8M

rlimit_cpu

= 20

}

#
# Cette entrée et les suivantes spécifient des services internes. Comme
# il s’agit du même service utilisant un type de socket différent,
# l’attribut id est utilisé pour identifier chaque entrée de façon unique
#
service echo
{

id

= echo-stream

type

= INTERNAL

socket_type

= stream

user

= root

wait

= no

}

service echo
{

id

= echo-dgram

type

= INTERNAL

socket_type

= dgram

user

= root

wait

= no

}

service servers
{

type

= INTERNAL UNLISTED

protocol

= tcp

port

= 9099

socket_type

= stream

wait

= no

}

#
# Exemple de service RPC
#
service rstatd
{

type

= RPC

socket_type

= dgram

protocol

= udp

server

= /usr/etc/rpc.rstatd

wait

= yes

user

= root

rpc_version

= 2-4

env

= LD_LIBRARY_PATH=/etc/securelib

}

#
# Exemple de service non listé
#
service unlisted
{

type

= UNLISTED

socket_type

= stream

protocol

= tcp

wait

= no

server

= /home/user/some_server

port

= 20020

}

xinetd(1L),

xinetd.log(5)

Postel J., Echo Protocol , RFC 862, May 1983

Postel J., Discard Protocol , RFC 863, May 1983

Postel J., Character Generator Protocol , RFC 864, May 1983

Postel J., Daytime Protocol , RFC 867, May 1983

Postel J., Harrenstien K., Time Protocol , RFC 868, May 1983

StJohns M., Identification Protocol , RFC 1413, February 1993

Si le flag INTERCEPT n’est pas utilisé, le contrôle d’accès sur l’adresse de la machine distante n’est pas effectué lorsque wait est à yes et socket_type est stream.

Si le flag INTERCEPT n’est pas utilisé, le contrôle d’accès sur l’adresse de la machine distante pour les services ou wait est à yes et socket_type est dgram est seulement effectué sur le premier paquet. Le serveur peut ensuite accepter des paquets en provenance de machines non autorisées dans la liste des contrôles d’accès. Cela peut arriver avec les services RPC

Il n’y a pas la possibilité de mettre un ESPACE dans une variable d’environnement.

Lorsque wait est à yes et socket_type est stream, la socket passée au serveur peut seulement accepter des connexions.

Le flag INTERCEPT n’est pas supporté pour les services internes ou les services multi-thread.

Christophe Donnier (Novembre 2001)