Cette section nous fera reviser un peu le daemon fort utile xinetd. Nous verrons à quoi il sert, quels sont ses avantages et comment on peut le configurer. Nous aurons également une petite initiation à deux serveurs tout simples qui sont souvent pris en charge par xinetd.
xinetd est un daemon qui écoute sur plusieurs ports à la fois en attendant des requêtes de connexion pour différents services. Lorsqu'il reçoit une demande de connexion sur un des ports qu'il surveille, il démarre le serveur correspondant et lui passe la demande. La connexion est donc établie et xinetd retourne à son état initial.
Les avantages d'utiliser xinetd:
Plusieurs serveurs peuvent être configurés aisément de façon à être utilisés avec xinetd, même s'ils ne le sont pas par défaut.
Retour à la table des matières de la section
3.1.1 - Les fichiers de configuration de xinetd
Ce fichier contient la liste de tous les services disponibles avec le port qui y est associé. Chaque ligne correspond à un service et est présentée ainsi:
nom_du_service port/protocole aliasLe protocole peut être tcp ou udp.
Les lignes débutant par un # sont évidemment des commentaires.
Bien que ce fichier ne fasse pas officiellement partie des fichiers de configuration de xinetd (d'ailleurs il existe sur le serveur avant même qu'on y installe xinetd), xinetd va le consulter lorsqu'il reçoit une demande sur un port. Il trouve alors dans /etc/services le nom du service associé et s'attend à trouver un fichier de configuration au même nom dans le répertoire /etc/xinetd.d.
Ce répertoire contient plusieurs fichiers. Il doit y avoir ici un fichier pour chaque service supporté par xinetd. Au départ, il y a 12 fichiers créés avec l'installation. L'installation d'un nouveau service prévu pour fonctionner avec xinetd créera normalement un nouveau fichier ici. Certains services configurables pour fonctionner avec xinetd ou non demanderont parfois de créer un fichier de configuration manuellement.
Chaque fichier contient en fait une définition de service contenant plusieurs paramètres avec des valeurs. Le fichier doit posséder le nom du service et être construit selon le format suivant:
service nom_du service { paramètre = valeur # ... paramètre = valeur }Il existe beaucoup de paramètres possibles et ceux qui seront nécessaires varieront d'un service à l'autre. Les plus courants sont:
On peut également déterminer les informations à ajouter au log dans le cas d'une connexion réussie ou échouée, en plus de préciser ici des restrictions d'accès selon la provenance de la demande et de l'heure. Voyez man xinetd.conf pour plus de détails.
Ce fichier contient la configuration générale de xinetd. Il est bâti exactement comme un fichier de service, mais avec l'entête "defaults".
defaults { paramètre = valeur # ... paramètre = valeur }Tous les paramètres donnés ici seront utilisés pour tous les services, à moins que l'un d'entre eux soit écrasé par une nouvelle valeur dans le fichier du service. Un service peut également ajouter des valeurs à un paramètre acceptant une liste, avec un += au lieu d'un égal dans la définition du paramètre.
On peut en fait voir les fichiers de /etc/xinetd.d/ comme la suite du fichier /etc/xinetd.conf - on pourrait aussi bien concaténer le tout dans un seul gros fichier. Le dernier paramètre de xinetd.conf indique d'ailleurs à xinetd d'aller lire les fichiers de /etc/xinetd.d/ pour trouver la suite...
C'est également dans xinetd.conf qu'on déteminera les options de log, ainsi que les limites de démarrage de processus. Encore une fois, faites un man xinetd.conf pour plus de détails sur les paramètres possibles.
Ces deux fichiers contiendront des règles pour gérer l'accès à différents services précis ou des règles générales pour l'accès à la machine.
Il y a quelques années, lorsque inetd, l'ancêtre de xinetd, était encore utilisé, on devait utiliser un deuxième daemon qui ne servait qu'à lire hosts.allow et hosts.deny et à déterminer si le serveur pouvait être démarré ou non. Dans ce cas, plutôt que de donner à inetd le chemin du serveur à démarrer, on lui donnait plutôt le chemin vers tcpd, à qui on passait en paramètre le chemin du serveur à démarrer. tcpd faisait ses vérifications et démarrait le serveur pour accepter la requête si c'était permis.
Maintenant xinetd fait lui-même la vérification des fichiers allow et deny et tcpd n'est donc plus nécessaire. Toutefois, si vous vouliez l'utiliser, il est possible de faire, à l'ancienne, dans un fichier de /etc/xinetd.d:
server = /usr/sbin/tcpd server_args = chemin_du_serveur_à_démarrerLe contrôle d'accès ne remplace évidemment pas un pare-feu, puisqu'il ne contrôle que l'accès aux services gérés par xinetd et qu'il ne contrôle absolument pas le trafic sortant. Il n'est qu'une addition intéressante à une stratégie de sécurité complète.
Notez qu'il est possible de forcer xinetd à relire ses fichiers de configuration sans nécessairement le redémarrer. On peut simplement lui envoyer le signal SIGHUP. Je vous laisse trouver comment...
Notez également en passant qu'une fois que xinetd est installé, la commande chkconfig indique à la fin de sa liste de services tous les services gérés par xinetd et lesquels sont actifs.
Retour à la table des matières de la section
Voyons plus en détails comment fonctionne le contrôle d'accès sur xinetd.
Retour à la table des matières de la section
Autrement dit, si les fichiers hosts.allow et hosts.deny sont vides (ou inexistants, un fichier inexistant étant traité comme un fichier vide), aucun contrôle d'accès ne sera fait et tout le monde pourra se connecter à tous les serveurs gérés par xinetd.
Retour à la table des matières de la section
3.2.2 - Le fonctionnement des fichiers
À l'intérieur d'un des deux fichiers, on retrouve une liste de règles indiquant un daemon et un client. xinetd tentera de trouver une correspondance dans cette liste avec le client qui tente de se connecter au daemon demandé. Il lira les règles dans l'ordre et s'arrêtera dès qu'une correspondance sera trouvée (donc l'ordre est important).
Retour à la table des matières de la section
3.2.3 - Le format des fichiers
ALL: .clg.qc.ca EXCEPT georges.clg.qc.ca
Notez que l'utilisation d'EXCEPT peut parfois être remplacée par une utilisation judicieuse des deux fichiers hosts.allow et hosts.deny. Par exemple, placer la règle ci-haut dans hosts.deny signifie "refuse tout client provenant de *.clg.qc.ca sauf georges.clg.qc.ca, peu importe le daemon qu'ils tentent d'exécuter". On pourrait arriver au même résultat en inscrivant dans hosts.allow:
ALL: georges.clg.qc.caet dans hosts.deny:
ALL: .clg.qc.caPar contre, si la ligne donnée en exemple plus haut est placée dans hosts.allow, il est impossible de faire l'équivalent en jouant avec les deux fichiers. En effet, allow est lu en premier et georges.clg.qc.ca obtiendrait une correspondance sur la première ligne. Le fichier deny ne serait donc pas lu et georges entrerait même si on ne le voulait pas.
Retour à la table des matières de la section
hosts.deny
ALL: ALL EXCEPT localhosthosts.allow
# On met ici uniquement ce qu'on veut permettre. # Si on ne met rien, tout est bloqué. in.ftpd: 172.16.27.10 in.identd: ALL
hosts.allow
ALL: ALLPeu importe ce qu'on mettra dans hosts.deny, ce dernier ne sera jamais lu et tout le monde pourra entrer. Complètement inutile, cette façon de faire revient exactement au même que de ne pas avoir de fichiers de contrôle d'accès.
On n'utilise pas le fichier hosts.allow et on place dans hosts.deny seulement ce qu'on veut spécifiquement bloquer. Le reste passe puisqu'il n'est mentionné dans aucun fichier (3ème règle).
hosts.deny
ALL: .microsoft.com, georges ALL EXCEPT in.fingerd: .clg.qc.ca
hosts.deny
ALL: ALL EXCEPT localhosthosts.allow
ALL: LOCAL
Retour à la table des matières de la section
Le protocole telnet permet simplement de se loguer à distance sur une machine et d'y exécuter un interpréteur de commandes. Lorsqu'on fait un telnet vers un serveur quelconque, on obtient un écran de login et on doit pouvoir fournir un compte et un mot de passe existant sur ce serveur. Telnet utilise les mêmes comptes que le login "physique", il n'y a pas de comptes "à part".
Telnet est un moyen simple d'exécuter des commandes sur un hôte distant. Toutefois, il tend à disparaître puisqu'il n'est absolument pas sécuritaire. Toute la communication entre le client et le serveur passe en clair sur le réseau, sans aucune encryption, y compris lors du login (et donc de la divulgation du mot de passe).
De plus, telnet ne permet pas l'échange de fichiers entre deux machines.
Il a été remplacé par ssh, qui est un protocole similaire mais avec une encryption.
Nous essaierons tout de même de configurer et d'installer telnet, question de l'avoir fait au moins une fois et de pouvoir le comparer ensuite avec ssh plus tard dans la session.
Par défaut, telnet utilise xinetd.
Retour à la table des matières de la section
Le protocole FTP est très répandu et encore très utilisé, malgré le fait que lui aussi n'est (par défaut) pas encrypté. Toutefois, beaucoup de serveurs (et donc de clients) supportent l'encryption du protocole FTP (en passant souvent par un tunnel ssh) mais malgré tout cette possibilité reste tout de même peu utilisée.
FTP signifie File Transfer Protocol et est utilisé uniquement pour échanger des fichiers entre deux machines distantes. Lorsque l'on utilise FTP, on doit s'authentifier sur l'hôte distant en utilisant soit un compte "régulier" de la machine (qui pourrait nous servir autant à se loguer physiquement sur la machine ou à travers un telnet) ou encore en utilisant un compte dit virtuel, créé uniquement pour l'accès FTP (comme par exemple le fameux compte anonymous).
On n'obtiendra pas alors un interpréteur de commandes régulier mais plutôt une fenêtre FTP, qui nous permettra de naviguer dans les répertoires distants, de récupérer des fichiers ou encore d'en envoyer. Tout cela dépendra tout de même des permissions qui nous sont accordés au niveau du système de fichiers.
Beaucoup de serveurs FTP peuvent fonctionner indépendamment de xinetd, mais plusieurs peuvent également être reconfigurés aisément pour passer via xinetd (comme ils le faisaient souvent avant).
Un des serveurs les plus populaires et les plus utilisés est vsftpd (Very Secure File Transfer Protocol Daemon). Nous verrons comment le sécuriser convenablement dans une prochaine section.
Retour à la table des matières de la section