Chap 6-Démon INETD et XINETD

Chapitre 6 INETD& XINETD

SALIM 1

INETD& XINETD

I. Démon INETD

1. Introduction

Avant l’écriture d’inetd, tous les services réseau étaient démarrés en arrière-plan au démarrage du système. Peu importe si ces processus allaient effectivement être utilisés ou non, Ces services sont dits fonctionnant en mode « autonome » ou « standalone ». Au fils du temps, le nombre de démons développés pour répondre à des besoins les plus divers a constamment augmenté, à tel point que des problèmes de performance ont commencé à se poser. Pour résoudre cette difficulté, l’université de Berkeley a développé inetd (aujourd’hui xinetd), qui peut être considéré comme un « Super Serveur Internet », à l'écoute sur plusieurs ports. Il s’agit également d’un processus fonctionnant en arrière plan, mais dont le rôle est de recevoir les demandes de connexion de plusieurs clients (telnet, ftp,...) et de lancer le serveur correspondant à la demande. A son démarrage il consulte les fichiers:

• /etc/services qui contiennent la liste générale des services TCP/IP avec leur numéro de port et le protocole de transport associé.

• /etc/inetd.conf qui contient la liste des services activés sur une machine donnée

Dans les distributions récentes, inetd a été remplacé par xinetd. Le principe est très similaire, à la seule différence que, dans /etc/xinetd.d, chaque service (telnet, ftp, pop3...) dispose de son propre fichier de configuration.

2. Fichier /etc/services :

Syntaxe générale :

<nom-service> <n°port/protocole>

Exemple :

$ more /etc/services : tcpmux 1/tcp daytime 13/udp netstat 15/tcp ftp-data 20/tcp ftp 21/tcp telnet 23/tcp smtp 25/tcp mail time 37/udp timserver

3. Fichier /etc/inetd.conf

Syntaxe générale : <nom_service> <type-sock> <protocole> <flags> <user> <path-service> <args>


SALIM 2

• nom_service : Définit le nom du service, généralement pour correspondre à un service mentionné dans le fichier /etc/services.

• type-sock protocole : ‘stream tcp’ ou ‘dgram udp’ ou ‘raw ip’ • flags : Détermine si le service est mono-fil (single-threaded, wait) ou multi-fils (multi-

threaded, nowait). • user : Détermine l'ID d'utilisateur sous lequel le processus est exécuté • path-service : Définit le chemin du fichier binaire exécutable devant être lancé • args : arguments de l’application en n’oubliant pas l’argument 0 (nom de

l’application) Exemple : # more /etc/inetd.conf ftp stream tcp nowait root /usr/sbin/ftpd ftpd telnet stream tcp nowait root /usr/sbin/telnetd telnetd #shell stream tcp nowait root /usr/sbin/rshd rshd #login stream tcp nowait root /usr/sbin/rlogind rlogind #exec stream tcp nowait root /usr/sbin/rexecd rexecd

Le # devant une ligne rend la ligne inactive donc le service non disponible

Ici, il n'y a que les services telnet et ftp qui sont activés.

4. Fonctionnement de inetd :

Lors d'une demande de connexion TCP (Ex : telnet), inetd extrait le numéro de port destination du message, il recherche le nom de service dans "/etc/services" et vérifie si le service est activé dans le fichier /etc/inetd.conf. En cas de succès, il crée un processus et lance l'exécution du binaire (exec) dont le chemin est spécifié dans "/etc/inetd.conf". Les messages qui suivent seront dirigés vers ce processus.

Client

Socket associée au port 1635

Serveurs

TCP/IP TCP/IP

/etc/services /etc/inetd.conf

telnetinetd

In.telnetd httpd

Lancé au démarrage du système

23 80


SALIM 3

5. Activation/arrêt de inetd :

Linux active Inetd lors de la phase d'initialisation. Si tel n'est pas le cas sur votre système, entrez :

# chkconfig -add inetd

Il est possible d’arrêter ou de relancer le service de manière interactive : # /etc/init.d/inetd stop #/etc/init.d/inetd start

Si on modifie le fichier /etc/inetd.conf, il faut prévenir le demon inetd en lui envoyant le signal n° 1 (SIGHUP) # ps –e | grep inetd 309 ? 00 :00 :00 inetd # kill –HUP 309

II. TCP Wrappers

1. Introduction

Le mécanisme de TCP_wrappers permet de contrôler et de restreindre l'accès à certain services réseau. Il offre une couche de protection. En fait il utilise le démon tcpd qui intercepte les demandes de connexion à un service et vérifie dans les fichiers hosts.allow et hosts.deny si le client est autorisé à utiliser ce service ou non. Dans tous les cas de figure tcpd transmettra à syslogd (deamon de log) votre demande (cette demande se retrouvera loguer dans le fichier /var/log/securite).

Sur les versions de linux actuelles, tcpd est installé par défaut. Par contre il n'est pas actif dans sa partie contrôle d'accès. TCP_Wrappers est un élément à mettre en œuvre pour sécuriser une machine sous linux, il ne peut toutefois pas remplacer complètement un vrai FireWall.

2. Fonctionnement du wrapper tcpd

Lorsqu'une requête client est reçue par un service enveloppé avec TCP, ce dernier suit les étapes élémentaires ci-dessous :

Serveur

/etc/services /etc/inetd.conf

telnet inetd In.telnetd

Client

Requête sur port 23

tcpd

/etc/hosts.allow /etc/hosts.deny


SALIM 4

Le service enveloppé avec TCP analyse le fichier /etc/hosts.allow de manière séquentielle et applique la première règle spécifiée pour ce service. Si une règle correspond au service, il autorise la connexion. Sinon, il passe à l'étape suivante.

Le service enveloppé avec TCP analyse le fichier /etc/hosts.deny de manière séquentielle. Si une règle correspond au service, il refuse la connexion. Sinon, il autorise l'accès au service.

Ci-après figurent des points importants qu'il convient de prendre en compte lors de l'utilisation d'enveloppeurs TCP pour protéger des services réseau :

Parce que les règles d'accès contenues dans le fichier hosts.allow sont appliquées en premier, elles ont priorité par rapport aux règles spécifiées dans le fichier hosts.deny. Par conséquent, si l'accès à un service est autorisé dans hosts.allow mais qu'une règle refusant l'accès à ce même service est contenue dans le fichier hosts.deny, cette dernière ne sera pas prise en compte.

Étant donné que les règles dans chaque fichier sont lues de haut en bas et que la première règle appliquée à un service donné est la seule règle prise en compte, l'ordre de ces dernières est extrêmement important.

Si aucune règle contenue dans l'un ou l'autre des fichiers ne s'appliquent au service ou si aucun de ces fichiers n'existe, l'accès au service est autorisé.

Des services enveloppés avec TCP ne mettent pas en cache les règles des fichiers d'accès d'hôtes, ainsi, tout changement apporté à hosts.allow ou hosts.deny prend effet immédiatement sans devoir redémarrer les services réseau

3. Les fichiers Hosts.allow et Hosts.deny :

Syntaxe générale des deux fichiers : <daemon list>: <client list> [: <option>: <option>: ...]

• <daemon list> : Correspond à une liste de noms de processus (pas de noms de services) séparés les uns des autres par une

• <client list> : Correspond à une liste de noms d'hôtes ou d'adresses IP d'hôtes

• <option> : Correspond à une action facultative ou à une liste d'actions facultatives séparées les unes des autres par une virgule, devant être exécutée lorsque la règle est appliquée.

Remarque : le format détaillé des fichiers hosts.allow et hosts.deny est décrit dans le manuel hosts_access Exemples : # more /etc/hosts.allow ALL : LOCAL in.ftpd : 192.168.0., 10.194.168.0/255.255.255.0, 192.168.1.1 in.telnetd : .ac-creteil.fr


SALIM 5

On autorise tout les ports depuis un accès local, et on autorise ftp pour les machines venant du réseau 192.168.0.0, ainsi que les machines du réseau 10.194.168.0 (avec une autre notation) et enfin la seule machine qui a pour adresse 192.168.1.1 #more /etc/hosts.deny ALL:ALL

Le fichier hosts.deny est simple à comprendre, il interdit tout par défaut. Le fichier hosts.allow indique les services qu’on veut autoriser (Le nom du service doit être identique au nom qui se trouve dans inetd.conf).

On peut contrôler plus finement les accès à sa machine en contrôlant le fichier de log, en envoyant un message à la personne qui cherche à se connecter, on peut aussi se faire envoyer des messages en utilisant la commande mail. Voici un exemple un peu plus complet et complexe que le précédent :

# more /etc/hosts.allow ALL: LOCAL .ucam.ac.ma EXCEPT sousdomaine.ucam.ac.ma: ALLOW in.ftpd : ALL : banners /root/messages.txt : spawn (echo " Accès au serveur ftp par l'adresse" %a "le " 'date') >> var/log/ftp.log & sshd : 192.168.0. in.telnetd : 10.94.243.1 EXCEPT PARANOID : spawn (/bin/mail -s "Alert le nom du hote et l’adresse IP ne correspondent pas" root@%H)&

La ligne 1 indique que tous les ports sont ouverts pour la machine LOCAL et pour le

domaine ucam.ac.ma sauf pour sousdomaine.ucam.ac.ma

La ligne 2 autorise toutes les connexions sur le service ftp, mais envoi un message sur la machine qui se connecte, reste à placer le texte dans le fichier message.txt. spawn vous permet de faire appel à la commande echo qui envoie un message dans le fichier de log ftp.log avec l'adresse de la machine qui se connecte %a et la date.

La ligne 3 que seul le réseau 192.168.0.0 peut se connecter via ssh à la machine.

La ligne 4 autorise la connexion en telnet depuis la machine 10.94.243.1 uniquement si l'adresse IP de la machine et le nom d'hôte correspondent. On envoie alors un message en utilisant la commande mail.

Le fichier hosts.deny restant avec ALL : ALL Les variables que vous pouvez utiliser sont :

%a L'adresse IP du client %A L'adresse IP du serveur %c Informations disponibles sur l'utilisateur %d Le nom du démon %h Le nom du client ou son adresse IP si on ne peut avoir le nom %H Le nom du serveur ou son adresse IP si on ne peut avoir le nom %n Idem mais en vérifiant le reverse DNS


SALIM 6

%N Idem pour le serveur %p Le pid du daemen %s Informations disponibles sur le serveur %u Nom de l'utilisateur

Les tentatives d'accès depuis des machines extérieures sont toutes enregistrées dans des fichiers particuliers. Ces enregistrements sont effectués par le processus syslogd qui à son démarrage lit le fichier /etc/syslog.conf pour trouver dans quel(s) fichier(s) il doit enregistrer les différentes tentatives d'accès.

Extrait de /etc/syslog.conf # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none; /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure

Extrait de /var/log/messages Feb 3 18:02:52 ns1 ftpd[1051]: FTP session closed Feb 3 18:03:31 ns1 syslogd 1.3-3: restart. Feb 3 18:07:34 ns1 in.ftpd[1057]: refused connect from cli1.archinet.edu Feb 3 18:07:46 ns1 in.ftpd[1058]: connect from ns1.archinet.edu uid=0) Feb 3 18:10:57 ns1 login[1063]: LOGIN ON ttyp3 BY mlx FROM puce

III. XINETD

1. Introduction

xinetd remplace inetd avec de nouvelles possibilités et un paramétrage plus fin. Le principe est le même que celui de TCP_Wrappers avec des fonctionnalités en plus. Il gère la connexion de certains protocoles (telnet, pop, ftp,....) et permet d'autoriser ou d'interdire les connexions sur la machine en fonction de l’adresse IP, du nom d'hôte du client ou de son domaine, de l'heure, du taux de charge, du nombre de connexions simultanées, du nombre de connexions entrantes par seconde, ce qui permet de limiter les tentatives de Deny of Service. Si on ne doit pas utiliser les services gérés par xinetd, il est préférable de ne pas le démarrer. Il vaut mieux choisir entre inetd et xinetd

xinetd est un élément à mettre en œuvre pour sécuriser une machine sous linux. Il n'est pas en mesure de gérer tous les protocoles.

2. Fonctionnement de xinetd

Lorsque vous souhaitez vous connecter sur une machine distante en telnet, par exemple, le xinetd intercepte votre demande de connexion et vérifie dans le fichier xinetd.conf, puis dans /etc/xinetd.d/telnet si le service telnet par exemple est utilisable.


SALIM 7

Si la réponse est positive, votre demande de connexion sera autorisée, sinon vous serez rejeté. Dans tous les cas de figure et cela est l'autre fonction de xinetd, il transmettra à syslogd (deamon de log) votre tentative de connexion.

Remarque : Un service géré par inetd = une ligne du fichier /etc/inetd.conf

ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -l -a un service géré par xinetd = un fichier dans /etc/xinetd.d

service ftp { socket_type = stream wait = no

user = root server = /usr/sbin/in.ftpd

}

3. L'installation

Lorsque vous installez une nouvelle machine, xinetd est installé par défaut. Si inetd est aussi installé il n’est pas conseillé de le remplacer par xinetd. Les deux peuvent tourner en parallèle.

xinetd peut avoir été installé avec l'option de compilation --with-libwrap, cette option permettant de conserver les fichiers hosts.allow et hosts.deny propre à TCP_Wrappers. Cette option permettant de continuer à utiliser certains programmes qui ne connaissent que tcp_wrapers. Le problème de cela étant qu’on a en plus des fichiers de xinetd à vérifier les fichiers hosts.allow et hosts.deny.

Si xinetd est compilé avec cette option les fichiers hosts.allow et hosts.deny sont lus les premiers.

4. Activation/arrêt du service xinetd

Le démon xinetd est normalement activé au démarrage par un script RC (par exemple /etc/rc.d/rc3.d/s56xinetd) Il est possible d’arrêter ou de relancer le servic de manière interactive :

/etc/xinetd.conf

xinetd

Répertoire/etc/xinetd.d

login telnet ftp


SALIM 8

# /etc/init.d/xinetd stop # /etc/init.d/xinetd start

Si on modifie l’un des fichiers présents dans /etc/xinetd.d, il faut prévenir le demon xinetd en lui envoyant :

• Le signal 10 (SIGUSR1) qui provoque une reconfiguration paisible • Le signal 12 (SIGUSR2) qui provoque une reconfiguration violente : non seulement il

ajuste sa configuration, mais arrête éventuellement les serveurs qui ne doivent plus être activés.

5. Le fichier xinetd.conf

Le fichier /etc/xinetd.conf contient des paramètres généraux de configuration ayant une influence sur tous les services placés sous le contrôle de xinetd. Le fichier /etc/xinetd.conf est lu seulement lors du lancement du service xinetd. Voici un exemple de fichier /etc/xinetd.conf :

defaults

{

disable = yes

instances = 60

log_type = SYSLOG authpriv

log_on_success = HOST PID

log_on_failure = HOST

no_access = 0.0.0.0/0

cps = 25 30

per_source = 4

}

includedir /etc/xinetd.d La description des instructions utilisées dans l’exemple précédent est présentée dans le tableau suivant : Disable tout est désactivé par défaut 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. 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.

no_access par défaut aucun réseau ne peut se connecter. On peut à la place utiliser no_access.


SALIM 9

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.

per_source on n'autorise que 4 connexions en provenances de la même machine. 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/.

On peut désactiver service par service. On enlève alors la première ligne et on ajoute plusieurs lignes "disable" pour les différents services. Cela donne : disable = telnet ftp disable = cvs Le défaut de cela est qu'il faut penser à tous les mettre, l'avantage est par contre d'avoir tous les services dans un seul fichier.

6. Les fichiers de configuration par service

Le répertoire /etc/xinetd.d/ contient les fichiers de configuration relatifs à chaque service géré par xinetd. Le nom de ces fichiers de paramétrage fait référence aux services. Pour comprendre comment ces fichiers sont structurés, le fichier /etc/xinetd.d/telnet est présenté en exemple :

service telnet

{

disable = yes

socket_type = stream

wait = no

user = root

server = /usr/sbin/in.telnetd

log_on_failure += USERID

access_times = 09:00-17:30 only_from = 172.16.0.0/16 only_from = .ucam.ac.ma only_from = 10.0.0.{10,11,12}

}

Les instructions qui contrôlent les différents aspects du service telnet sont décrits dans le tableau suivant : service Définit le nom du service, généralement pour

correspondre à un service énuméré dans le fichier /etc/services.

socket_type Spécifie le connecteur réseau comme étant de type stream.


SALIM 10

wait Détermine si le service est mono-fils ('single-threaded', yes), ou multi-fils fil ('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 ceux déjà

définis dans xinetd.conf. log_on_failure Détermine les paramètres de déjà définis dans

xinetd.conf. nice Détermine le niveau de priorité du serveur. access_times Détermine la période pendant laquelle l’accès au serveur

est autorisé only_from Détermine les machines autorisées à se connecter au

serveur

Pensez enfin à relire le fichier de configuration, lorsque vous faites des modifications avec la commande killall -HUP pid_xinetd.

Documents

Chap 6-Démon INETD et XINETD