Templates/files updated (unreviewed pages in bold): Modèle:CC-BY-SA, Modèle:Copy
[checked revision] | [checked revision] |
(No difference)
|
par Anne
Où comment utiliser xinetd pour sécuriser encore plus votre manchot préféré.
Cet article a pour objectif d'expliquer le fonctionnement et la configuration du super démon xinetd. Pourquoi particulièrement celui-ci ? Parce qu'il est utilisé fréquemment pour l'accès à nombre de services réseau et devient un outil non négligeable de sécurisation de celui-ci (en plus d'un bon firewall bien sûr). Cet article n'a pas pour objectif d'être complètement exhaustif mais de présenter les configurations les plus courantes de xinetd. Pour plus d'infos, consulter le man (on s'en serait douté ;) )
Selon la distribution vous trouverez soit un démon inetd, soit un démon xinetd. La tendance est tout de même d'utiliser de plus en plus ce dernier.
Dans l'absolu, inetd et xinetd ont le même rôle, à savoir de piloter l'accès à un ou plusieurs services réseaux. Ils agissent comme une standardiste. Ils reçoivent des requêtes de clients, extérieurs pour la plupart, qui demandent un accès à un service réseau déterminé (ex : ftp, telnet, ssh...). Le super démon va, en fonction des instructions qu'on lui aura données (fichiers de configuration) transmettre ou rejeter l'appel.
inetd, jusque là utilisé, permettait, grâce au fichier /etc/inetd.confet au wrapper tcpd, de paramétrer l'accès aux services en l'autorisant/interdisant totalement ou partiellement. (cf. les fichiers /etc/hosts.allow et /etc/hosts.deny).
xinetd apporte des fonctionnalités bien plus importantes et permet d'affiner les paramétrages d'accès aux services. On citera dans le désordre :
Si votre distribution préférée utilise inetd et qu'après avoir eu le courage de lire cet article, vous souhaitez utiliser xinetd, il existe un script qui vous permettra de transformer le fichier inetd.conf en fichier xinetd.conf, utilisable par xinetd
Ce script, xconv.pl, est un script perl fourni avec xinetd. Attention si ce script peut vous donner la structure générale du fichier de configuration, il ne vous permettra pas de profiter des apports de xinetd. Rien de tel qu'un bon éditeur de texte et ce qui suit ci-dessous.
On entre dans le vif du sujet :). Pour configurer xinetd, vous aurez à connaître la syntaxe, commune de /etc/xinetd.conf et, selon les cas de figure, les fichiers situés dans le répertoire /etc/xinetd.d.
L'arborescence de la configuration de xinetd est relativement simple. On en rencontre 2 types :
C'est ce deuxième cas de figure qui est le plus couramment utilisé dans les distributions.
Le fichier de configuration de xinetd est un ensemble d'une ou plusieurs directives dont la syntaxe est la suivante :
service nom_du_service
{
...
}
Le nom de la directive est soit defaults et la configuration porte alors sur l'ensemble des services gérés par xinetd, soit le nom d'un des services géré par xinetd. A l'intérieur de chacune de ces directives on trouvera des attributs, un par ligne, écrits de la manière suivante :
<attribut> <assignement> <valeur> <valeur> ...
Les attributs seront détaillés plus loin. Les assignements peuvent prendre différentes valeurs : =, -=, +=.
Exemple :
root@pingu# cat /etc/xinetd.d/telnet
service telnet
{
...
server = /usr/sbin/in.telnetd
...
}
avec :
attribut : server
assignement : "="
valeur : /usr/sbin/in.telnetd
Pour reprendre l'arborescence de xinetd et les 2 cas de figure exposés ci-dessus, on obtiendra les fichiers suivants :
un seul fichier de configuration | un fichier de configuration par service |
/etc/xinetd.conf defaults { ... } service service1 { ... } service service2 { ... } |
/etc/xinetd.conf defaults { ... } /etc/xinetd.d/service1 service service1 { ... } /etc/xinetd.d/service2 service service2 { ... } |
Nous allons lister les différents attributs utilisables pour configurer xinetd. Certains sont facultatifs et vous permettent d'affiner son rôle. Toutefois d'autres sont obligatoires et s'ils ne sont pas présents, empêcheront tout ou partie des services de fonctionner.
Avant de les lister, petit point de vocabulaire : on distingue les services dits internes et externes. A quoi ? A xinetd bien sur :). Les services internes, comme servers, services, xadmin sont des services propres à xinetd qui fournissent des informations sur le fonctionnement du super-démon. Il vaut mieux ne pas utiliser ces services car ils exposent la machine inutilement et les fichiers de log de xinetd vous fourniront les mêmes informations.
Voilà donc les attributs que vous devrez utiliser :
Attribut | Définition |
socket-type | type de socket utilisé pour le service : dgram s'il utilise le protocole UDP, stream s'il utilise le protocole TCP - consulter le fichier /etc/services pour avoir l'information. |
user | identité sous laquelle le service sera lancé |
server | chemin et nom du serveur |
wait | Définit le comportement du service dans le traitement des threads : yes pour un service mono-thread (une connexion simultanée par service et une seule), no pour un service multithread (possibilité d'avoir plusieurs connexions simultanées au service) |
protocol | Protocole utilisé par le service. Si rien n'est précisé, c'est le protocole spécifié dans le fichier /etc/services qui sera utilisé. |
rpc_version rpc_number |
Ne concerne que les services basés sur les RPC (exemple : NFS) |
port | Port associé au service. Là encore, s'il n'est pas précisé, c'est le port spécifié pour le service dans le fichier /etc/services. |
Une des fonctionnalités de xinetd est de permettre d'affiner ce que vous voulez loguer et dans quel(s) fichier(s) vous voulez le loguer.
C'est l'attribut log_type qui va donner cette localisation. Il peut prendre 2 valeurs :
Outre la localisation des logs, il est possible également de paramétrer le contenu des logs. On utilisera les attributs log_on_success et log_on_failure qui, comme l'intitulé l'indique, listent ce qui sera logué en cas de succès et d'échec de l'accès au service. Les valeurs sont :
Les 4 valeurs sont utilisables avec l'attribut log_on_success. Seuls HOST et USERID sont utilisables avec log_on_failure.
Exemple :
service trucmuche
{
...
log_type = FILE /var/log/xinetd/trucmuche.log
log_on_success = PID USERID HOST DURATION
log_on_failures = HOST USERID
...
}
Dans ce cas de figure, le fichier de log du service trucmuche sera /var/log/xinetd/trucmuche.log. Les informations recueillies dans tous les cas seront l'adresse du client et son identité et en cas de succès, on aura également le PID du serveur et la durée de la session
Xinetd dispose de nombreux attributs complémentaires, facultatifs mais qui vont permettre d'en faire un outil de sécurisation des services réseaux et du système dans son ensemble. Ci-dessous, les principales fonctionnalités proposées.
Avec des attributs supplémentaires, vous allez pouvoir filtrer les clients qui vont pouvoir ou non se connecter à vos serveurs.
Filtrer des adresses : only_from = valeur [valeurs...].
La connexion au service ne sera possible qu'à partir de la liste fournie à cet attribut. Elle peut contenir :
Vous pouvez bien sûr panacher les valeurs.
Exemple : configuration des accès ftp sur ma machine :
service proftpd
{
...
only_from = citrouille 192.168.1.0 lea-linux.org
...
{
Les seuls autorisés à utiliser mon serveur ftp seront : la machine "citrouille", les machines du réseau 192.168.1.0 et celles du domaine lea-linux.org.
Un attribut qui a également pour effet de filtrer les accès est no_access = valeur [valeurs...]. Il fonctionne exactement de la même façon que only_from sauf qu'il détermine les machines, adresses IP, hostnames, adresses réseaux et/ou noms de domaine pour lesquels vous voulez interdire l'accès à votre service.
Attention, encore une fois, xinetd utilisé seul ne vous garantira pas la sécurité de votre système. Il est essentiel d'y adjoindre un bon firewall.
Vous pouvez choisir le moment auquel vous autoriserez les accès à tout ou partie de vos services réseaux. On utilisera l'attribut access_times. Il vous permet de définir une ou plusieurs plages horaires pendant lesquelles la connexion sera possible.
Syntaxe : access_times = interval [interval...]
L'intervalle de temps s'écrit : heures:minutes-heures:minutes
Exemple : Je veux limiter l'accès de mon ftp de 9h à 12h et de 14h à 16h.
service proftpd
{
...
access_time = 9:00-12:00 14:00-16:00
...
{
Véritable couteau suisse de la configuration de services réseau, xinetd vous permet de "chrooter" un service. Rappel : la commande chroot permet de lancer un programme en restreignant ses accès disques à une sous arborescence. En fait pour le processus, la racine du disque est la racine de l'arborescence dans laquelle il a été restreint.
L'attribut server_args va nous permettre d'automatiser le chroot : la commande chroot est considérée comme le serveur et le service est passé en argument.
Exemple : Je veux chrooter mon serveur ftp.
service proftp
{
...
server = /usr/sbin/chroot
server_args = /opt/proftpd/proftpd
...
{
Lorsqu'un client tente un accès ftp, chroot est exécuté en tant que serveur et proftpd en tant qu'argument, ce qui revient à la commande connue : /usr/bin/chroot opt/proftpd/proftpd.
Dans la plupart des distributions, les services installés et gérés par xinetd sont désactivés d'office, pour des raisons de sécurité. D'autre part vous pouvez, pour un temps, choisir de désactiver complètement un service. Tout ceci est lié à l'utilisation de l'attribut disable.
Syntaxe : disable = yes|no
Exemple : Je veux désactiver telnet.
service telnet
{
disable = yes
...
{
flags = SENSOR
deny_time = minutes
SENSOR empêche toute connexion au service concerné et stocke l'adresse IP pendant un temps déterminé par l'attribut deny_time. Si cette même adresse tente de se connecter à n'importe quel service géré par xinetd, il sera automatiquement bloqué. Le temps est déterminé en minutes, mais vous pouvez utiliser également la valeur FOREVER : l'IP restera blacklistée jusqu'au prochain redémarrage de xinetd.
Je ne verrai pas ici toutes les possibilités offertes par xinetd mais 2 en particulier : la redirection de port et l'attribution d'un service à une interface réseau.
Même si ce n'est pas sa fonction principale, xinetd peut vous permettre de faire de la redirection de port, si vous ne souhaitez pas approfondir iptables. On utilisera pour cela l'attribut redirect.
Syntaxe : redirect = adresseIP port
Exemple : Je dispose d'une passerelle vers Internet et une machine sur le même réseau local dont l'adresse IP est 192.168.0.3. Je souhaite installer un serveur telnet sur cette dernière machine. Je vais donc faire en sorte que les requêtes qui arrivent de l'extérieur pour mon serveur telnet soient redirigées vers cette machine.
root@pingu# cat /etc/xinetd.d/telnet
service telnet
{
...
server = /usr/sbin/in.telnetd
redirect = 192.168.0.4 23
}
On teste maintenant la connexion :
root@pingu# telnet 217.11.12.13
Trying 217.11.12.13...
Connected to 217.11.12.13.
Escape character is '^]'.
Red Hat Linux release 8.0 (Psyche)
Kernel 2.4.18-14 on an i586
login: anne
Password:
Last login: Fri Nov 8 12:26:44 on :0
[anne@citrouille anne]$ hostname
citrouille
La connexion telnet est établie et la commande hostname nous confirme que je ne suis pas sur la passerelle mais sur la machine citrouille dont l'adresse IP est 192.168.0.4
xinetd va vous permettre de lier un service à une adresse IP grâce à l'attribut bind.
Pour éclaircir la description de cet attribut, nous allons nous appuyer sur un exemple. Je vais reprendre mes 2 machines de l'exemple précédent. Mon objectif : je veux construire 2 serveurs ftp bien différenciés. L'un sera réservé à mes machines en local (serveur de fichiers interne) l'autre mettra à disposition d'autres fichiers sur un serveur ftp réservé aux connexions externes. (Après tout je ne partage pas tout :)).
Ma machine pingu (ma passerelle) a 2 interfaces réseau avec les adresses IP respectives : 192.168.0.3 et 217.11.12.13. Je vais donc effectuer les attributions grâce au fichier suivant :
root@pingu# cat /etc/xinetd.d/proftpd
service proftpd
{
id = ftp_public
...
server = /opt/proftpd/proftpd
bind = 217.11.12.13
}
service proftpd
{
id = ftp_privé
...
server = /opt/proftpd/proftpd
bind = 192.168.0.3
}
L'attribut id sert uniquement à différencier les 2 configurations du service. Tout ceci bien sûr doit s'accompagner d'une configuration de votre serveur ftp.
Pour finir, xinetd vous permet également d'afficher des messages lors de la connexion à un service grâce aux attributs suivants :
Ci-dessous quelques exemples de fichiers de configuration de services, issus entre autres du man de xinetd.conf
Le 1er exemple est un fichier de configuration du service ftp.
root@pingu# cat /etc/xinetd.d/ftp
service ftp
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.ftpd
server_args = -l
instances = 4
log_type = FILE /var/log/ftp.log
log_on_success = DURATION HOST USERID
access_times = 2:00-9:00 12:00-24:00
}
Le serveur ftp, hormis les paramètres génériques de configuration, autorise des connexions entre 2h et 9h et entre midi et minuit. Son fichier de log est /var/log/ftp.log et contient, en cas de connexions réussies, la durée de la connexion, le nom de la machine cliente et l'UID de l'utilisateur connecté. Seules 4 instances simultanées sont autorisées
.
Le 2e exemple est un fichier de configuration du service telnet.
root@pingu# cat /etc/xinetd.d/telnet
service telnet
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.telnetd
rlimit_as = 8M
rlimit_cpu = 20
}
Le dernier exemple se compose de 2 fichiers de configuration pour la gestion de samba. par xinetd. En effet, le service samba lance 2 démons, nmbd et smbd
root@pingu# cat /etc/xinetd.d/netbios-ssn
service netbios-ssn
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/smbd
only_from = 192.168.0.0
disable = no
}
root@pingu# cat /etc/xinetd.d/netbios-ns
service netbios-ns
{
socket_type = dgram
protocol = udp
wait = no
user = root
server = /usr/sbin/nmbd
only_from = 192.168.0.0
disable = no
}
Hormis les paramètres génériques de configuration de smbd et nmbd, on a configuré samba de manière à ce qu'il ne soit utilisable que sur le réseau interne 192.168.0.0.
Je n'ai pas exploré ici l'intégralité des possibilités de xinetd. La meilleur des choses à faire pour cela est de se reporter au man. Si vous disposez encore une distribution utilisant inetd, et au vu de toutes les fonctionnalités de xinetd, il semble opportun d'abandonner le premier pour le deuxième. Bien exploité, il devient véritablement un outil de sécurisation de votre système, dès lors que vous mettez en place un certains nombres de serveurs qui, ouvrant votre machine sur l'extérieur, ouvre également la voie aux vilains hackers ;).
N'hésitez pas à me faire parvenir vos remarques et ajouts divers sur le contenu de cet article.
@ Retour à la rubrique Réseau et sécurité
Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Anne le 15/11/2002.
© 15/11/2002 Anne Nicolas
![]() ![]() ![]() |
Ce document est publié sous licence Creative Commons Attribution, Partage à l'identique 4.0 : https://creativecommons.org/licenses/by-sa/4.0/ |