Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] xinetd.conf - Fichier de configuration du démon amélioré des services Internet [size=18] [b]Description[/b] [/size] [b]xinetd.conf[/b] est le fichier de configuration qui définit les services fournis par [b]xinetd[/b]. 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 :[table][row][col]    [/col][col] .nf .ft B service <nom_du_service> {[table][row][col]    [/col][col] .ft B <attribut> <assign_op> <valeur> <valeur> ... [i]...[/i][/col][/row][/table] } .ft R .fi[/col][/row][/table]     L'opérateur d'assignation, [i]assign_op,[/i] peut être l'un des suivants [b]« = », [/b] [b]« += »,[/b] [b]« -= ».[/b] La majorité des attributs ne supporte que l'opérateur d'assignation simple, [b]« = ».[/b] Les attributs dont la valeur est un ensemble de valeurs supportent tous les opérateurs d'assignation. Pour de tels attributs, [b]« += » [/b] signifie ajouter une valeur à l'ensemble des valeurs et [b]« -= »[/b] 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 [i]nom_du_service[/i]. Voici une liste des attributs disponibles : [b]id[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]type[/b] [table][row][col]    [/col][col]N'importe quelle combinaison des valeurs suivantes peut être utilisée :[table][row][col]    [/col][col][/col][/row][/table] [b]RPC[/b] [table][row][col]    [/col][col]si c'est un service RPC[/col][/row][/table] [b]INTERNAL[/b] [table][row][col]    [/col][col]si c'est un service fourni par [b]xinetd[/b].[/col][/row][/table] [b]UNLISTED[/b] [table][row][col]    [/col][col]pour un service qui n'est pas listé dans un fichier système standard (comme [i]/etc/rpc [/i] pour les services RPC, ou [i]/etc/services[/i] Pour les services non-RPC).[/col][/row][/table][/col][/row][/table] [b]flags[/b] [table][row][col]    [/col][col]N'importe quelle combinaison des flags suivants peut être utilisée :[table][row][col]    [/col][col][/col][/row][/table] [b]REUSE[/b] [table][row][col]    [/col][col]Positionne le flag [i]SO_REUSEADDR[/i] sur la socket du service (voir [i]setsockopt(2)[/i] pour plus d'information).[/col][/row][/table] [b]INTERCEPT[/b] [table][row][col]    [/col][col]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).[/col][/row][/table] [b]NORETRY[/b] [table][row][col]    [/col][col]Empêche les tentatives d'essayer à nouveau dans le cas d'une impossibilité de forker.[/col][/row][/table] [b]IDONLY[/b] [table][row][col]    [/col][col]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 [b]USERID[/b] n'est pas utilisée.[/col][/row][/table] [b]NAMEINARGS[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]NODELAY[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]DISABLE[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]KEEPALIVE[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]NOLIBWRAP[/b] [table][row][col]    [/col][col]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).[/col][/row][/table] [b]SENSOR[/b] [table][row][col]    [/col][col]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.[/col][/row][/table][/col][/row][/table] [b]disable[/b] [table][row][col]    [/col][col]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.[/col][/row][/table][/col][/row][/table] [b]socket_type[/b] [table][row][col]    [/col][col]les valeurs possibles pour cet attribut sont :[table][row][col]    [/col][col][/col][/row][/table] [i]stream[/i] [table][row][col]    [/col][col]service de type stream[/col][/row][/table] [i]dgram[/i] [table][row][col]    [/col][col]service de type datagramme[/col][/row][/table] [i]raw[/i] [table][row][col]    [/col][col]service qui demande un accès direct à IP[/col][/row][/table] [i]seqpacket[/i] [table][row][col]    [/col][col]service qui demande une transmission de type datagramme séquentielle et fiable[/col][/row][/table][/col][/row][/table] [b]protocol[/b] [table][row][col]    [/col][col]détermine quel est le protocole employé par le service. Le protocole doit être présent dans le fichier [i]/etc/protocols.[/i] Si cet attribut n'est pas défini, le protocole par défaut utilisé par le service sera utilisé.[/col][/row][/table] [b]wait[/b] [table][row][col]    [/col][col]Cet attribut détermine si le service est de type mono-thread ou multi-thread. Si la valeur est [i]yes[/i] le service est de type mono-thread ; cela signifie que [b]xinetd[/b] 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 [i]no[/i], le service est de type multi-thread et [b]xinetd[/b] continuera à prendre en charge les requêtes pour ce service.[/col][/row][/table] [b]user[/b] [table][row][col]    [/col][col]détermine l'uid pour le processus serveur. L'utilisateur doit exister dans le fichier [i]/etc/passwd.[/i] Cet attribut est sans effet si [b]xinetd[/b] n'a pas été démarré sous l'uid du super-utilisateur.[/col][/row][/table] [b]group[/b] [table][row][col]    [/col][col]détermine le gid pour le processus serveur. Le groupe doit exister dans le fichier [i]/etc/group.[/i] Si le groupe n'est pas spécifié, le groupe de l'utilisateur [i]user[/i] sera utilisé (récupéré dans le fichier [i]/etc/passwd).[/i] Cet attribut est sans effet si [b]xinetd[/b] n'a pas été démarré sous l'uid du super-utilisateur.[/col][/row][/table] [b]instances[/b] [table][row][col]    [/col][col]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 [b]UNLIMITED[/b] ce qui signifie qu'il n'y a aucune limite.[/col][/row][/table] [b]nice[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]server[/b] [table][row][col]    [/col][col]détermine le programme à exécuter pour ce service.[/col][/row][/table] [b]server_args[/b] [table][row][col]    [/col][col]détermine les arguments passés au serveur. Contrairement à [b]inetd[/b], le nom du serveur ne doit [i]pas[/i] se trouver dans l'attribut [i]server_args[/i].[/col][/row][/table] [b]only_from[/b] [table][row][col]    [/col][col]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 :[table][row][col]    [/col][col][/col][/row][/table] [b]a)[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]b)[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]c)[/b] [table][row][col]    [/col][col]un nom de réseau (présent dans le fichier [i]/etc/networks)[/i][/col][/row][/table] [b]d)[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]e)[/b] [table][row][col]    [/col][col]un couple ip addresse/netmask de la forme 1.2.3.4/32.[/col][/row][/table][/col][/row][/table] [b][/b] [table][row][col]    [/col][col]Spécifier cet attribut sans une valeur, rend le service indisponible pour tous[/col][/row][/table] [b]no_access[/b] [table][row][col]    [/col][col]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 [b]only_from[/b]. Ces deux attributs déterminent le contrôle d'accès des hôtes effectué par [b]xinetd[/b]. 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 [b]only_from[/b] contient 128.138.209.0 et que [b]no_access[/b] contient 128.138.209.10 alors l'hôte avec l'adresse 128.138.209.10 ne peut pas accéder au service).[/col][/row][/table] [b]access_times[/b] [table][row][col]    [/col][col]détermine l'intervalle de temps pendant lequel le service est disponible. Un intervalle de temps est de la forme [i]heure:minute-heure:minute[/i] (les connexions [i]seront [/i] acceptées durant un intervalle de temps). Les heures vont de 0 à 23 et les minutes de 0 à 59.[/col][/row][/table] [b]log_type[/b] [table][row][col]    [/col][col]détermine où seront envoyés les logs de sortie. Il y a deux formats :[table][row][col]    [/col][col][/col][/row][/table] [b]SYSLOG [i]syslog_facility[/i] [syslog_level][/b] [table][row][col]    [/col][col]Les logs sont envoyés à syslog avec l'option spécifiée. Les différentes options sont pour les noms : [i]daemon,[/i] [i]auth,[/i] [i]authpriv,[/i] [i]user,[/i] [i]local0-7.[/i] pour les niveaux d'alerte : [i]emerg,[/i] [i]alert,[/i] [i]crit,[/i] [i]err,[/i] [i]warning,[/i] [i]notice,[/i] [i]info,[/i] [i]debug.[/i] Si le niveau d'alerte n'est pas précisé, les messages seront traités avec le niveau [i]info.[/i][/col][/row][/table] [b]FICHIER [i]fichier[/i] [soft_limit [hard_limit]][/b] [table][row][col]    [/col][col]Les logs sont ajoutés au [i]fichier[/i] 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) ; [b]xinetd [/b] va envoyer un message dès que cette limite est dépassée (si [b]xinetd[/b] envoie ses messages à syslog, le message sera envoyé avec un niveau de priorité [i]alert[/i] ). La deuxième limite est de type hard (rigide) ; [b]xinetd [/b] 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 [b]xinetd[/b] envoie ses logs à syslog, le message sera envoyé avec le niveau de priorité [i]alert[/i] ). 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 : [size=6]LOG_EXTRA_MIN[/size] et [size=6]LOG_EXTRA_MAX[/size] qui ont pour valeur par défaut respectivement 5K et 20K (ces constantes sont définies dans le fichier [i]config.h[/i]).[/col][/row][/table][/col][/row][/table] [b]log_on_success[/b] [table][row][col]    [/col][col]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 :[table][row][col]    [/col][col][/col][/row][/table] [b]PID[/b] [table][row][col]    [/col][col]loggue l'identificateur du processus serveur (si le service est implémenté par [b]xinetd[/b] sans forker un nouveau processus, l'identificateur du processus loggué sera 0)[/col][/row][/table] [b]HOST[/b] [table][row][col]    [/col][col]loggue l'adresse de l'hôte distant[/col][/row][/table] [b]USERID[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]EXIT[/b] [table][row][col]    [/col][col]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 [b]PID[/b] est utilisée)[/col][/row][/table] [b]DURATION [/b] [table][row][col]    [/col][col]loggue la durée d'une session pour le service concerné[/col][/row][/table][/col][/row][/table] [b]log_on_failure[/b] [table][row][col]    [/col][col]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 :[table][row][col]    [/col][col][/col][/row][/table] [b]HOST[/b] [table][row][col]    [/col][col]loggue l'adresse de l'hôte distant.[/col][/row][/table] [b]USERID[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]ATTEMPT[/b] [table][row][col]    [/col][col]loggue le fait qu'une tentative a été faite et a échoué (cette option est impliquée par toute les autres).[/col][/row][/table] [b]RECORD[/b] [table][row][col]    [/col][col]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 : [i]login,[/i] [i]shell,[/i] [i]exec,[/i] [i]finger.[/i][/col][/row][/table][/col][/row][/table] [b]rpc_version[/b] [table][row][col]    [/col][col]détermine la version RPC pour un service RPC. La version peut être un nombre simple ou une plage de la forme [i]chiffre[/i]-[i]chiffre[/i].[/col][/row][/table] [b]rpc_number[/b] [table][row][col]    [/col][col]détermine le numéro pour un service RPC [i]NON LISTÉ[/i] (cet attribut est ignoré si le service est connu).[/col][/row][/table] [b]env[/b] [table][row][col]    [/col][col]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 [b]xinetd[/b] plus les chaînes spécifiées).[/col][/row][/table] [b]passenv[/b] [table][row][col]    [/col][col]La valeur de cet attribut est une liste de variables d'environnement de l'environnement de [b]xinetd[/b] 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 [i]env.[/i] (notez que vous pouvez utiliser cet attribut en même temps que l'attribut [i]env[/i] pour spécifier précisément quels attributs seront passés au serveur).[/col][/row][/table] [b]port[/b] [table][row][col]    [/col][col]détermine le port du service. Si cet attribut est spécifié pour un service déjà listé dans le fichier [i]/etc/services,[/i] il doit avoir le même numéro de port que celui listé dans ce fichier.[/col][/row][/table] [b]redirect[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]bind[/b] [table][row][col]    [/col][col]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).[/col][/row][/table] [b]interface[/b] [table][row][col]    [/col][col]Synonyme de bind.[/col][/row][/table] [b]banner[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]banner_success[/b] [table][row][col]    [/col][col]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. [/col][/row][/table] [b]banner_fail[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]per_source[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]cps[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]max_load[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]groups[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]umask[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]enabled[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]include[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]includedir[/b] [table][row][col]    [/col][col]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 [b]includedir[/b] ne doit pas être spécifiée à l'intérieur d'une déclaration de service. [/col][/row][/table] [b]rlimit_as[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]rlimit_cpu[/b] [table][row][col]    [/col][col]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 ».[/col][/row][/table] [b]rlimit_data[/b] [table][row][col]    [/col][col]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 ».[/col][/row][/table] [b]rlimit_rss[/b] [table][row][col]    [/col][col]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 ».[/col][/row][/table] [b]rlimit_stack[/b] [table][row][col]    [/col][col]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 ».[/col][/row][/table] [b]deny_time[/b] [table][row][col]    [/col][col]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.[/col][/row][/table]     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 : 1 [table][row][col]    [/col][col] [b]socket_type[/b][/col][/row][/table] [b]user[/b] [table][row][col]    [/col][col](seulement pour les services non-[i]internes[/i])[/col][/row][/table] [b]server[/b] [table][row][col]    [/col][col](seulement pour les services non-[i]internes[/i])[/col][/row][/table] [b]wait[/b][/col][/row][/table] [b]protocol[/b] [table][row][col]    [/col][col](seulement pour le service [i]RPC[/i] et pour les services [i]non-listés[/i] )[/col][/row][/table] [b]rpc_version[/b] [table][row][col]    [/col][col](seulement pour le service [i]RPC[/i] )[/col][/row][/table] [b]rpc_number[/b] [table][row][col]    [/col][col](seulement pour les services RPC [i]non-listés[/i] )[/col][/row][/table] [b]port[/b] [table][row][col]    [/col][col](seulement pour les services non-RPC et [i]non-listés[/i] )[/col][/row][/table][/col][/row][/table]     Les attributs suivants supportent tous les opérateurs d'assignation : 1 [table][row][col]    [/col][col] [b]only_from[/b][/col][/row][/table] [b]no_access[/b][/col][/row][/table] [b]log_on_success[/b][/col][/row][/table] [b]log_on_failure[/b][/col][/row][/table] [b]passenv[/b][/col][/row][/table] [b]env[/b] [table][row][col]    [/col][col](ne supporte pas l'opérateur [b]« -= »[/b] )[/col][/row][/table][/col][/row][/table]     Ces attributs peuvent apparaître plus d'un fois pour un même service. Les attributs restants ne supportent que l'opérateur [b]« = »[/b] 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    [table][row][col]    [/col][col] .nf .ft B defaults {[table][row][col]    [/col][col] .ft B <attribut> = <valeur> <valeur> ... [i]...[/i][/col][/row][/table] .ft B } .ft R .fi[/col][/row][/table]     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 : 1 [table][row][col]    [/col][col] [b]log_type[/b][/col][/row][/table] [b]log_on_success[/b] [table][row][col]    [/col][col](effet cumulatif)[/col][/row][/table] [b]log_on_failure[/b] [table][row][col]    [/col][col](effet cumulatif)[/col][/row][/table] [b]only_from[/b] [table][row][col]    [/col][col](effet cumulatif)[/col][/row][/table] [b]no_access[/b] [table][row][col]    [/col][col](effet cumulatif)[/col][/row][/table] [b]passenv[/b] [table][row][col]    [/col][col](effet cumulatif)[/col][/row][/table] [b]instances[/b][/col][/row][/table] [b]disabled[/b] [table][row][col]    [/col][col](effet cumulatif)[/col][/row][/table] [b]enabled[/b] [table][row][col]    [/col][col](effet cumulatif)[/col][/row][/table][/col][/row][/table]     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 [i]disabled[/i] ils ont tous la même signification que si ils étaient spécifiés pour un service. [i]disabled[/i] 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 [i]disabled[/i] au lieu de tous les commenter. La valeur de cet attribut est une liste d'identificateurs séparés par des espaces. [i]enabled [/i] a les mêmes propriétés que l'attribut disabled. La différence étant que [i]enabled [/i] est une liste de services qu'il faut activer. Si [i]enabled [/i] est spécifié, il n'y a que les services spécifiés qui sont disponibles. Si [i]enabled [/i] n'est pas spécifié, tous les services sont supposés être activés, excepté ceux qui sont listé par l'attribut [i]disabled.[/i] [size=18] [b]Services internes[/b] [/size]     [b]xinetd[/b] fournit en interne les services suivants (à la fois ceux de type stream et ceux de type datagramme) : [i]echo,[/i] [i]time,[/i] [i]daytime,[/i] [i]chargen,[/i] et [i]discard.[/i] Ces services ont les mêmes règles d'accès que les autres services, sauf pour ceux qui ne demandent pas à [b]xinetd[/b] de forker un nouveau processus pour eux. Ceux-ci ([i]time[/i], [i]daytime[/i], et le [i]echo[/i] de type datagram, [i]chargen[/i], et [i]discard[/i]) n'ont aucune limitations de leur nombre d' [b]instances.[/b]     [b]xinetd[/b] fournit aussi deux services internes [i]NON-LISTÉS[/i] de type stream : [i]servers[/i] et [i]services.[/i] 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. [size=18] [b]Notes[/b] [/size] 1. 4 [table][row][col]    [/col][col]Les attributs des services suivants [i]ne[/i] peuvent être changés lors d'une reconfiguration : [b]socket_type,[/b] [b]wait,[/b] [b]protocol,[/b] [b]type.[/b][/col][/row][/table] 2. [table][row][col]    [/col][col]Lorsque les attributs [i]only_from[/i] et [i]no_access[/i] ne sont pas spécifiés pour un service (que ce soit directement ou par l'option [i]defaults[/i]) la vérification d'adresse est considérée comme bonne (c'est à dire que l'accès ne sera pas refusé).[/col][/row][/table] 3. [table][row][col]    [/col][col]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 [b]xinetd[/b] 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 [b]xinetd[/b] 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é.[/col][/row][/table] 4. [table][row][col]    [/col][col]Si l'option de log [b]USERID[/b] 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 [i]IDONLY[/i] soit utilisé.[/col][/row][/table] 5. [table][row][col]    [/col][col]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 [i]appels_système[/i]x[i]data_envoyé_par_appel[/i], c'est à dire chaque appel système [i]envoyé(2)[/i] à 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. 1[table][row][col]    [/col][col][table][row][col]    [/col][col][/col][/row][/table] [table][row][col]    [/col][col]Taille du datagramme (octets) Latence (msec)[/col][/row][/table] [table][row][col]    [/col][col]--------------------- --------------[/col][/row][/table] [table][row][col]    [/col][col]64 1.19[/col][/row][/table] [table][row][col]    [/col][col]256 1.51[/col][/row][/table] [table][row][col]    [/col][col]1024 1.51[/col][/row][/table] [table][row][col]    [/col][col]4096 3.58 2[/col][/row][/table] [table][row][col]    [/col][col]Octets envoyés Réduction de bande passante[/col][/row][/table] [table][row][col]    [/col][col]---------- -------------------[/col][/row][/table] [table][row][col]    [/col][col]10000x64 941 (1.2%)[/col][/row][/table] [table][row][col]    [/col][col]10000x256 4,231 (1.8%)[/col][/row][/table] [table][row][col]    [/col][col]10000x1024 319,300 (39.5%)[/col][/row][/table] [table][row][col]    [/col][col]10000x4096 824,461 (62.1%)[/col][/row][/table][/col][/row][/table] 1[/col][/row][/table] [size=18] [b]Exemple[/b] [/size]     [table][row][col]    [/col][col] .nf # # Exemple de fichier de configuration pour xinetd # defaults {[table][row][col]    [/col][col] log_type 20 [table][row][col]    [/col][col]= FILE /var/log/servicelog[/col][/row][/table] log_on_success [table][row][col]    [/col][col]= PID[/col][/row][/table] log_on_failure [table][row][col]    [/col][col]= HOST RECORD[/col][/row][/table] only_from [table][row][col]    [/col][col]= 128.138.193.0 128.138.204.0 128.138.209.0 [/col][/row][/table] only_from [table][row][col]    [/col][col]= 128.138.252.1 [/col][/row][/table] instances [table][row][col]    [/col][col]= 10[/col][/row][/table] disabled [table][row][col]    [/col][col]= rstatd[/col][/row][/table] } # # Note 1 : l'attribut du protocole n'est pas requis # Note 2 : l'attribut d'instances écrase l'attribut par défaut # service login {[table][row][col]    [/col][col][/col][/row][/table] socket_type 20 [table][row][col]    [/col][col]= stream[/col][/row][/table] protocol [table][row][col]    [/col][col]= tcp[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] user [table][row][col]    [/col][col]= root[/col][/row][/table] server [table][row][col]    [/col][col]= /usr/etc/in.rlogind[/col][/row][/table] instances [table][row][col]    [/col][col]= UNLIMITED[/col][/row][/table] } # # 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 {[table][row][col]    [/col][col][/col][/row][/table] socket_type 20 [table][row][col]    [/col][col]= stream[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] user [table][row][col]    [/col][col]= root[/col][/row][/table] instances [table][row][col]    [/col][col]= UNLIMITED[/col][/row][/table] server [table][row][col]    [/col][col]= /usr/etc/in.rshd[/col][/row][/table] log_on_success [table][row][col]    [/col][col]+= HOST RECORD[/col][/row][/table] } service ftp {[table][row][col]    [/col][col][/col][/row][/table] socket_type 20 [table][row][col]    [/col][col]= stream[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] nice [table][row][col]    [/col][col]= 10[/col][/row][/table] user [table][row][col]    [/col][col]= root[/col][/row][/table] server [table][row][col]    [/col][col]= /usr/etc/in.ftpd[/col][/row][/table] server_args [table][row][col]    [/col][col]= -l[/col][/row][/table] instances [table][row][col]    [/col][col]= 4[/col][/row][/table] log_on_success [table][row][col]    [/col][col]+= DURATION HOST USERID[/col][/row][/table] access_times [table][row][col]    [/col][col]= 2:00-9:00 12:00-24:00[/col][/row][/table] } # 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 {[table][row][col]    [/col][col][/col][/row][/table] socket_type 20 [table][row][col]    [/col][col]= stream[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] nice [table][row][col]    [/col][col]= 10[/col][/row][/table] user [table][row][col]    [/col][col]= root[/col][/row][/table] server [table][row][col]    [/col][col]= /usr/etc/in.telnetd[/col][/row][/table] rlimit_as [table][row][col]    [/col][col]= 8M[/col][/row][/table] rlimit_cpu [table][row][col]    [/col][col]= 20[/col][/row][/table] } # # 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 {[table][row][col]    [/col][col][/col][/row][/table] id 20 [table][row][col]    [/col][col]= echo-stream[/col][/row][/table] type [table][row][col]    [/col][col]= INTERNAL[/col][/row][/table] socket_type [table][row][col]    [/col][col]= stream[/col][/row][/table] user [table][row][col]    [/col][col]= root[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] } service echo {[table][row][col]    [/col][col][/col][/row][/table] id 20 [table][row][col]    [/col][col]= echo-dgram[/col][/row][/table] type [table][row][col]    [/col][col]= INTERNAL[/col][/row][/table] socket_type [table][row][col]    [/col][col]= dgram[/col][/row][/table] user [table][row][col]    [/col][col]= root[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] } service servers {[table][row][col]    [/col][col][/col][/row][/table] type 20 [table][row][col]    [/col][col]= INTERNAL UNLISTED[/col][/row][/table] protocol [table][row][col]    [/col][col]= tcp[/col][/row][/table] port [table][row][col]    [/col][col]= 9099[/col][/row][/table] socket_type [table][row][col]    [/col][col]= stream[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] } # # Exemple de service RPC # service rstatd {[table][row][col]    [/col][col][/col][/row][/table] type 20 [table][row][col]    [/col][col]= RPC[/col][/row][/table] socket_type [table][row][col]    [/col][col]= dgram[/col][/row][/table] protocol [table][row][col]    [/col][col]= udp[/col][/row][/table] server [table][row][col]    [/col][col]= /usr/etc/rpc.rstatd[/col][/row][/table] wait [table][row][col]    [/col][col]= yes[/col][/row][/table] user [table][row][col]    [/col][col]= root[/col][/row][/table] rpc_version [table][row][col]    [/col][col]= 2-4[/col][/row][/table] env [table][row][col]    [/col][col]= LD_LIBRARY_PATH=/etc/securelib[/col][/row][/table] } # # Exemple de service non listé # service unlisted {[table][row][col]    [/col][col][/col][/row][/table] type 20 [table][row][col]    [/col][col]= UNLISTED[/col][/row][/table] socket_type [table][row][col]    [/col][col]= stream[/col][/row][/table] protocol [table][row][col]    [/col][col]= tcp[/col][/row][/table] wait [table][row][col]    [/col][col]= no[/col][/row][/table] server [table][row][col]    [/col][col]= /home/user/some_server[/col][/row][/table] port [table][row][col]    [/col][col]= 20020[/col][/row][/table] }[/col][/row][/table][/col][/row][/table] [size=18] [b]Voir aussi[/b] [/size] [i]xinetd(1L),[/i]     [i]xinetd.log(5)[/i]     Postel J., [i]Echo Protocol,[/i] RFC 862, May 1983     Postel J., [i]Discard Protocol,[/i] RFC 863, May 1983     Postel J., [i]Character Generator Protocol,[/i] RFC 864, May 1983     Postel J., [i]Daytime Protocol,[/i] RFC 867, May 1983     Postel J., Harrenstien K., [i]Time Protocol,[/i] RFC 868, May 1983     StJohns M., [i] Identification Protocol,[/i] RFC 1413, February 1993 [size=18] [b]Bogues[/b] [/size]     Si le flag [b]INTERCEPT[/b] n'est pas utilisé, le contrôle d'accès sur l'adresse de la machine distante n'est pas effectué lorsque [i]wait[/i] est à [i]yes[/i] et [i]socket_type[/i] est [i]stream[/i].     Si le flag [b]INTERCEPT[/b] n'est pas utilisé, le contrôle d'accès sur l'adresse de la machine distante pour les services ou [i]wait[/i] est à [i]yes[/i] et [i]socket_type[/i] est [i]dgram[/i] 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 [b]RPC[/b]     Il n'y a pas la possibilité de mettre un [size=6]ESPACE[/size] dans une variable d'environnement.     Lorsque [i]wait[/i] est à [i]yes[/i] et [i]socket_type[/i] est [i]stream[/i], la socket passée au serveur peut seulement accepter des connexions.     Le flag [b]INTERCEPT[/b] n'est pas supporté pour les services internes ou les services multi-thread. [size=18] [b]Traduction[/b] [/size] Christophe Donnier (Novembre 2001)
Fichier