Convert to GutenPalm or to PalmDoc par Frédéric Raynal L´auteur: Frédéric Raynal prépare actuellement une thèse en informatique sur le tatouage d'images à l'INRIA (Institut National de Recherche en Informatique et Automatique). Sommaire: defaults pour les services Configurer un service Attachement à un port: l'attribut bind Redirection d'un service vers une autre machine: l'attribut redirect Services spéciaux Une énigme pour commencer chrooter un service Un serveur pop3 Erreurs de configuration avec la RH7.0, la Mandrake 7.2 et peut-être d'autres ... Discussion sur cet article

xinetd

Résumé:

xinetd - extented Internet services daemon - fournit une excellente sécurité contre les intrusions, et limite certains risques d'attaques par Deny of Services (DoS). Comme la paire plus connue (inetd+tcpd), il permet de fixer des droits d'accès à une machine, mais ses capacités s'étendent bien au-delà. Cet article vous propose de les découvrir.

Kesako xinetd ?

xinetd offre des capacités de contrôle d'accès similaires à celles offertes par tcp_wrapper. Toutefois, ses possibilités s'étendent bien au-delà :

• contrôle d'accès pour des services TCP, UDP et RPC (pour ces derniers, tout ne fonctionne pas très bien) ;
• contrôle d'accès fondé sur des plages horaires ;
• logging puissant, autant en cas de succès que d'échec de la connexion ;
• prévention efficace contre les attaques de type Deny of Services (DoS) qui bloquent une machine en saturant ses ressources :
• limitations du nombre de serveurs d'un même type qui peuvent tourner en même temps ;
• limitations du nombre total de serveur ;
• limitations sur la taille des fichiers de log.
• attachement d'un service à une interface particulière : ceci permet, par exemple, de rendre des services accessibles à votre réseau interne mais pas au reste du monde ;
• peut faire office de proxy vers d'autres systèmes, ce qui s'avère très pratique dans le cas de l'ip masquerading (ou de NAT) afin d'atteindre des machines situées sur le réseau interne.

La première partie de cet article explique le fonctionnement général de xinetd. Nous nous attarderons, par l'intermédiaire d'exemples, sur la configuration générale d'un service, sur quelques options particulières (attachement à une interface, redirection). La seconde partie illustre le fonctionnement de xinetd, les logs qu'il génère et finit avec une petite astuce très utile.
 

Compilation & Installation

1. --with-libwrap : avec cette option, xinetd commence par examiner les fichiers de configuration de tcpd (/etc/hosts.{allow, deny}) et ensuite, si l'accès est accordé, il utilise ses propres mécanismes de contrôle. Cette option nécessite la présence du tcp_wrapper et des bibliothèques qui l'accompagnent. (Note de l'auteur : ce qui est réalisable avec le wrapper l'est tout aussi bien par xinetd. Autoriser cette compatibilité conduit à multiplier les fichiers de configuration, ce qui complique l'administration ... bref, je ne le recommande pas);
2. --with-loadavg : cette option permet à xinetd de supporter l'option de configuration max_load (charge maximale). Cela permet de désactiver certains services lorsque la charge de la machine dépasse le seuil donné, ce qui est essentiel pour prévenir certains DoS (voir l'attribut max_load dans le tableau 1 ;
3. --with-inet6 : si vous voulez utiliser IPv6, cette option en garantit le support. Les connexions IPv4 et IPv6 sont gérées, mais les adresses IPv4 se transforment au format IPv6.

Certains signaux influencent le comportement de xinetd:

• SIGUSR1: reconfiguration soft : le fichier de configuration est relu et les paramètres des services sont ajustés;
• SIGUSR2: reconfiguration hard : comme ci-dessus, mais tue en plus les démons qui ne correspondent plus aux critères;
• SIGTERM: termine xinetd et tous les démons qu'il a générés.

Configuration

Deux utilitaires (itox et xconv.pl) sont fournis avec xinetd et permettent de convertir le fichier /etc/inetd.conf en fichier de configuration pour xinetd. Bien évidemment, ceci ne suffit pas dans la mesure où les règles stipulées dans les fichiers de configuration du wrapper sont ignorées. itox n'évolue plus, même s'il est encore maintenu. xconv.pl offre une meilleure solution, même si le résultat nécessite d'être modifié, ne serait-ce que parce que xinetd offre plus de possibilités qu'inetd.

>>/usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf

La section des valeurs par défauts s'écrit:

defaults
{
    attribut opérateur valeur(s)
    ...
}

only_from = 192.168.1.0/24 192.168.5.0/24 192.168.10.17

Chaque section décrivant un service dans le fichier de configuration est de la forme:

service nom_du_service
{
    attribut opérateur valeur(s)
    ...
}

Le tableau 1 décrit succinctement quelques uns des attributs. Nous verrons leur utilisation dans les exemples qui suivront. La lecture de la page man de xinetd.conf fournit de plus amples informations.
 
 

Les quatre derniers attributs présentés dans le tableau 1 permettent de contrôler les ressources attachées aux serveurs. Ceci permet de lutter efficacement contre certaines attaques par Deny of Service (DoS), dont le but est de paralyser une machine en occupant toutes ses ressources.

Cette partie présentait quelques unes des possibilités offertes par xinetd. Les parties suivantes montrent comment s'en servir et précisent certaines règles de bon fonctionnement.  

defaults pour les services

Interdire, par défaut,  tout accès à sa machine est la première étape d'une politique de sécurisation viable. Ensuite, il ne restera qu'à autoriser, en fonction des services, l'accès à qui de droit. Nous avons vu deux attributs permettant de contrôler l'accès à sa machine fondés sur les adresses IP: only_from et no_access. Choisir le second en mettant:

no_access = 0.0.0.0/0

only_from = 0.0.0.0/0

Sep 17 15:11:12 charly xinetd[26686]: Service=echo-stream: only_from list and no_access list match equally the address 192.168.1.1

only_from = 192.0.0.0/8

only_from =

Détail important, voire essentiel: en cas d'absence complète de règles d'accès (i.e. ni only_from, ni no_access) pour un service (allouées soit de manière directe, soit par le biais de la section default), l'accès au service est autorisé!

Voici un exemple de defaults :

defaults
{
  instances       = 15
  log_type        = FILE /var/log/servicelog
  log_on_success  = HOST PID USERID DURATION EXIT
  log_on_failure  = HOST USERID RECORD
  only_from       =
  per_source      = 5

  disabled = shell login exec comsat
  disabled = telnet ftp
  disabled = name uucp tftp
  disabled = finger systat netstat

  #INTERNAL
  disabled = time daytime chargen servers services xadmin

  #RPC
  disabled = rstatd rquotad rusersd sprayd walld
}

Configurer un service

Certains attributs doivent impérativement apparaître en fonction du type du service (INTERNAL, UNLISTED ou RPC) :
 
 

L'exemple ci-dessous illustre la définition de services :

service ntalk
{
  socket_type   = dgram
  wait          = yes
  user          = nobody
  server        = /usr/sbin/in.ntalkd
  only_from     = 192.168.1.0/24
}

service ftp
{
  socket_type  = stream
  wait         = no
  user         = root
  server       = /usr/sbin/in.ftpd
  server_args  = -l
  instances    = 4
  access_times = 7:00-12:30 13:30-21:00
  nice         = 10
  only_from    = 192.168.1.0/24
}

Attachement à un port: l'attribut bind

Par exemple, une société veut mettre en place un serveur FTP pour ses employés (afin qu'ils puissent consulter des documents internes). Elle tient également à fournir à ses clients un accès FTP vers ses produits: bind est fait pour cette société :) Nous allons définir deux services FTP. Toutefois, xinetd doit pouvoir les distinguer: c'est là qu'intervient l'attribut id, qui définit de manière unique un service (lorsqu'il n'est pas défini dans un service, il vaut, par défaut, le nom du service).
 

service ftp
{
  id           = ftp-public
  wait         = no
  user         = root
  server       = /usr/sbin/in.ftpd
  server_args  = -l
  instances    = 4
  nice         = 10
  only_from    = 0.0.0.0/0 #autorisation pour tous les clients
  bind         = 212.198.253.142 #adresse IP publique de ce serveur
}

service ftp
{
  id           = ftp-private
  socket_type  = stream
  wait         = no
  user         = root
  server       = /usr/sbin/in.ftpd
  server_args  = -l
  only_from    = 192.168.1.0/24 #usage interne seulement
  bind         = 192.168.1.1  #adresse IP locale de ce serveur (charly)
}

00/9/17@16:47:46: START: ftp-public pid=26861 from=212.198.253.142
00/9/17@16:47:46: EXIT: ftp-public status=0 pid=26861 duration=30(sec)
00/9/17@16:48:19: START: ftp-interne pid=26864 from=192.168.1.1
00/9/17@16:48:19: EXIT: ftp-interne status=0 pid=26864 duration=15(sec)

Un problème apparaît clairement: que se passe-t-il si la machine ne dispose pas de deux adresses IP fixes? Ce cas de figure se produit par exemple avec des connexions ppp ou si vous utilisez le protocole dhcp. Il semble donc qu'il vaudrait mieux lier les services aux interfaces qu'aux adresses. Toutefois, ceci n'est pas encore prévu avec xinetd et pose de nombreux problèmes (entre autres, écrire un module C pour accéder aux interfaces et aux adresses dépend fortement de l'OS de l'ordinateur, or xinetd est supporté par beaucoup d'OS différents...) L'utilisation d'un script permet de résoudre ce problème à moindre coût:

#!/bin/sh

PUBLIC_ADDRESS=`/sbin/ifconfig $1 | grep "inet addr" | awk '{print $2}'| awk -F: '{print $2}'`
sed s/PUBLIC_ADDRESS/"$PUBLIC_ADDRESS"/g /etc/xinetd.base > /etc/xinetd.conf

Redirection d'un service vers une autre machine: l'attribut redirect

service telnet
{
  flags  = REUSE
  socket_type = stream
  wait  = no
  user  = root
  server = /usr/sbin/in.telnetd
  only_from = 192.168.1.0/24
  redirect = 192.168.1.15 23
}

>>telnet charly
Trying 192.168.1.1...
Connected to charly.
Escape character is '^]'.
 

Digital UNIX (sabrina) (ttyp1)

login:

Services spéciaux

1. servers: révèle les serveurs actuellement en cours d'utilisation ;
2. services: affiche les services disponibles, leur protocole et leur port ;
3. xadmin: mélange les fonctions des deux précédents.

defaults {
  ...
  disabled = servers services xadmin
  ...
}

1. seule la machine sur laquelle tourne xinetd doit pouvoir s'y connecter ;
2. limiter le nombre d'instances à une;
3. n'autoriser l'accès qu'à la machine sur laquelle tourne le serveur.

service xadmin
{
  type  = INTERNAL UNLISTED
  port  = 9100
  protocol = tcp
  socket_type = stream
  wait  = no
  instances = 1
  only_from = 192.168.1.1  #charly
}

1. help ...
2. show run: comme pour le service servers, montre les serveurs actuellement utilisés;
3. show avail: comme pour le service services, affiche les services disponibles (et quelques autres informations qui n'apparaissent pas services);
4. bye ou exit ...

Jouons un peu ...

Une énigme pour commencer

Nous n'avons besoin que du service finger :

service finger
{
  flags  = REUSE NAMEINARGS
  server = /usr/sbin/tcpd
  server_args = in.fingerd
  socket_type = stream
  wait  = no
  user  = nobody
  only_from = 192.168.1.1  #charly
}

pappy@charly >> finger pappy@charly
[charly]
pappy@charly >>

pappy@bosley >>  finger pappy@charly
[charly]

pappy@bosley >>

Il semble que la requête n'ait pas fonctionné correctement, qu'elle soit exécutée de charly (192.168.1.1), machine autorisée, ou bien de bosley (192.168.1.10). Examinons les fichiers de logs:

/var/log/servicelog :
00/9/18@17:15:42: START: finger pid=28857 from=192.168.1.1
00/9/18@17:15:47: EXIT: finger status=0 pid=28857 duration=5(sec)
00/9/18@17:15:55: FAIL: finger address from=192.168.1.10

/var/log/services:
Sep 18 17:15:42 charly in.fingerd[28857]: refused connect from 192.168.1.1

Résumons les éléments en notre possession:

1. xinetd a autorisé la requête;
2. la requête finger passe par tcpd;
3. in.fingerd a refusé cette même requête.

En fait, telles que les lignes server et server_args du service ont été définies, les capacités du wrapper restent accessibles (banner -il existe aussi un attribut banner avec xinetd-, spawn, twist, ...). Rappelons que l'option de compilation --with-libwrap ajoute uniquement une vérification préalable, à l'aide des hosts.{allow,deny}, des droits d'accès avant que le processus propre à xinetd ne s'enclenche. Les écritures présentées ici permettent donc de continuer à employer les mécanismes mis en oeuvre avec le wrapper.

Ce chevauchement des capacités, s'il peut fonctionner, peut également conduire à d'étranges comportements. Pour faire cohabiter xinetd, inetd et portmap, il vaut mieux qu'un service ne soit géré que par un seul de ces "super-démons".

chrooter un service

chroot [options] nouvelle_racine

service ftp
{
  id           = ftp
  socket_type  = stream
  wait         = no
  user         = root
  server       = /usr/sbin/chroot
  server_args  = /var/servers/ftp /usr/sbin/in.ftpd -l
}

Conclusion

Vous pouvez vous demander quel démon choisir entre xinetd et inetd. En fait, xinetd demande un petit effort supplémentaire d'administration, surtout tant qu'il ne sera pas inclus directement dans les distributions (il l'est dans la Red Hat 7.0). La solution la plus sûre consiste à utiliser xinetd sur votre (vos) machine(s) ayant un accès public (comme Internet) car il offre une meilleure ligne de défense. Pour les autres, à l'intérieur de votre réseau, inetd suffit amplement. Ne pas négliger toutefois l'emploi d'un firewall: son travail ne se situe pas au même niveau.
 

Un serveur pop3

Un service très populaire semble être pop3 : j'ai reçu beaucoup de messages concernant sa mise en oeuvre au travers de xinetd. Voici la configuration nécessaire :

     service pop3
     {
             disable = no
             socket_type             = stream
             wait                    = no
             user                    = root
             server                  = /usr/sbin/ipop3d
     #       log_on_success          += USERID
     #       log_on_failure          += USERID
     }

L'utilisation de pop3 via xinetd peut s'avérer laborieuse selon les directives de logs que vous donnez. En effet, comme nous l'avons vu, l'emploi de la valeur USERID provoque une requête de xinetd vers un serveur identd du client pop. Or, si aucun serveur de ce type ne fonctionne, le timeout est de 30 secondes.

Ainsi, lorsqu'une personne se connecte pour retirer son courrier, elle devra attendre au moins 30 secondes si aucun serveur identd ne fonctionne chez elle. Vous devez donc choisir entre :

1. installer un serveur identd sur toutes les machines clientes afin de conserver des logs complets (attention toutefois: les informations délivrées par un serveur identd peuvent être modifiées) ;
2. dégrader la qualité de vos logs pour ce service afin de ne pas ralentir les requêtes d'accès au courrier des utilisateurs.

Erreurs de configuration avec la RH7.0, la Mandrake 7.2 et peut-être d'autres ...

bug 24279 rapporté sur bugzilla. Certains services configurés dans le répertoire /etc/xinetd.d ne sont pas définis dans le fichier /etc/services.

[pappy@rootdurum xinetd.d]# grep service *udp
chargen-udp:service chargen-udp
daytime-udp:service daytime-udp
echo-udp:service echo-udp
time-udp:service time

Le responsable du bug chez RH signale qu'on ne peut pas utiliser la correction que j'ai suggérée car ça poserait des problèmes de manipulation avec chkconfig et ntsysv. Entre ces outils et l'utilisation de xinetd, mon choix est vite fait ;-)
 

Discussion sur cet article

2001-03-18, generated by lfparser version 2.8