Toute personne familière avec inetd(8) a probablement entendu parlé à un moment ou à un autre de l'encapsuleur TCP (“TCP Wrappers”). Mais peu sont ceux qui semblent saisir complètement son intérêt dans un réseau. Il semble que tout le monde désire installer un coupe-feu pour contrôler les connexions réseaux. Alors qu'un coupe-feu peut avoir de nombreuses utilisations, il existe des choses qu'un coupe-feu ne peut gérer comme renvoyer un message à l'initiateur d'une connexion. L'encapsuleur TCP en est capable ainsi que bien d'autres choses. Dans les sections suivantes plusieurs fonctionnalités de l'encapsuleur TCP seront abordées, et, dès que ce sera possible, un exemple de configuration sera proposé.
L'encapsuleur TCP étend les capacités d'inetd au niveau du support pour chaque serveur sous son contrôle. En utilisant cette méthode il est possible d'offrir le support des ouvertures de session, de retourner des messages lors des connexions, de permettre à un “daemon” de n'accepter que les connexions internes, etc. Bien que certaines de ces fonctionnalités peuvent être obtenues par l'implémentation d'un coupe-feu, ce système ajoutera non seulement une couche supplémentaire de protection mais ira plus loin dans le contrôle que ce que peut fournir un coupe-feu.
Les fonctionnalités apportées par l'encapsuleur TCP ne peuvent se substituer à l'utilisation d'un bon coupe-feu. L'encapsuleur TCP peut être utilisé de paire avec un coupe-feu ou tout autre système de sécurité et il pourra alors servir comme une couche supplémentaire de protection pour le système.
Etant donné que ce programme est une extension à la configuration du programme inetd, le lecteur est supposé avoir pris connaissance de la section de configuration d'inetd.
Note : Bien que les programmes lancés par inetd(8) ne soient pas tout à fait des “daemons”, ils sont traditionnellement appelés “daemons”. C'est le terme que nous utiliserons également dans le reste de cette section.
Le seul pré-requis à l'utilisation de l'encapsuleur TCP sous FreeBSD est de s'assurer que le serveur inetd est lancé à partir de rc.conf avec l'option -Ww; c'est
la configuration par défaut. Bien évidemment une configuration correcte du
fichier /etc/hosts.allow est également sous-entendue, mais
dans le cas contraire syslogd(8) émettra des
messages d'avertissement dans les journaux du système.
Note : Contrairement à d'autres implémentations de l'encapsuleur TCP, l'emploi du fichier hosts.deny est obsolète. Toutes les options de configuration doivent être placées dans le fichier /etc/hosts.allow.
Dans la configuration la plus simple, la politique de connexion aux “daemons” est soit de tout autoriser ou soit de tout bloquer en fonctions des options choisies dans /etc/hosts.allow. La configuration par défaut sous FreeBSD est d'autoriser les connexions à chaque “daemon” lancé à l'aide d'inetd. La modification de ce réglage par défaut sera discutée une fois que la configuration de base aura été vue.
Une configuration de base prend en général la forme daemon : adresse : action. Où daemon est le nom du “daemon” lancé par inetd. L'adresse peut être un nom de machine valide, une adresse IP ou une adresse IPv6 entre crochets ([ ]). Le champ action pourra avoir comme valeur allow ou deny pour autoriser ou interdire l'accès. Gardez à l'esprit que ce type de configuration fonctionne de manière à honorer la première règle sémantique correspondante, cela signifie que le fichier de configuration est parcouru à la recherche d'une règle correspondant à la requête. Quand une correspondance est trouvée, la règle est appliquée et la recherche s'arrête.
Plusieurs autres options existent mais elles seront exposées dans une section ultérieure. Une simple ligne de configuration peut être construite avec peu d'information. Par exemple, pour autoriser les connexions POP3 via le “daemon” mail/qpopper, les lignes suivantes doivent être ajoutées au fichier hosts.allow:
# This line is required for POP3 connections: qpopper : ALL : allow
Après l'ajout de cette ligne, inetd devra être
redémarré. Cela sera fait en utilisant la commande kill(1), ou avec le
passage du paramètre restart à la commande /etc/rc.d/inetd.
L'encapsuleur TCP dispose également d'options avancées; elles permettrons plus de contrôle sur la manière dont sont gérées les connexions. Dans certains cas cela peut être une bonne idée de renvoyer un commentaire à certaines machines ou lors de connexions à certains “daemon”s. Dans d'autres cas, peut-être qu'un fichier journal pourrait être enregistré ou un courrier électronique pourrait être envoyé à l'administrateur. D'autres situations peuvent nécessiter l'utilisation d'un service uniquement pour les connexions locales. Tout cela est possible à l'aide des options de configuration connues sous le nom de jokers, caractères d'expansion et d'exécution de commandes externes. Les deux sections suivantes abordent ces situations.
Imaginez une situation dans laquelle une connexion doit être refusée et que la
raison de ce refus doit être envoyée à la personne qui a tenté d'établir
cette connexion. Comment cela peut-il être mis en place? Ce type d'action est rendu
possible par l'emploi de l'option twist. Quand
une tentative de connexion est faite, twist sera
appelée pour exécuter une commande ou une procédure d'interpréteur de
commande. Un exemple est déjà présent dans le fichier hosts.allow:
# The rest of the daemons are protected.
ALL : ALL \
: severity auth.info \
: twist /bin/echo "You are not welcome to use %d from %h."
Cet exemple montre que le message “You are not allowed to use daemon from hostname.” sera retourné pour tout “daemon” qui n'a pas été précédemment configuré dans le fichier d'accès. Cette fonction est très utile pour envoyer une réponse à l'initiateur de la connexion juste après le refus de la connexion. Notez que tout message à retourner doit être placé entre des guillemets "; il n'y a pas d'exception possible à cette règle.
Avertissement : Il est possible de lancer une attaque par déni de service sur le serveur si un agresseur, ou un groupe d'agresseurs sont en mesure de submerger ces “daemon”s avec des demandes de connexion.
Une autre possibilité dans ce cas est d'employer l'option spawn. Tout comme l'option twist,
spawn interdit implicitement les connexions et peut
être utilisée pour lancer une commande ou une procédure externe.
Contrairement à twist, spawn n'enverra pas de réponse à la personne qui a établi
la connexion. Examinons par exemple la ligne de configuration suivante:
# We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny
Cela interdira toute tentative de connexion à partir du domaine *.example.com, enregistrant simultanément dans le fichier /var/log/connections.log le nom de machine, l'adresse IP et le “daemon” auquel on tente d'accéder.
Il existe d'autres caractères de substitution en dehors de ceux déjà présentés, par exemple %a. Consultez la page de manuel hosts_access(5) pour une liste complète.
Jusqu'ici l'option ALL a été utilisée dans tous les exemples. Il existe d'autres options pour étendre un peu plus les fonctionnalités. Par exemple, l'option ALL peut être utilisée pour prendre en compte chaque instance d'un “daemon”, d'un domaine ou d'une adresse IP. Un autre joker disponible est l'option PARANOID qui peut être employée pour prendre en compte toute machine qui fournirait une adresse IP susceptible d'être falsifiée. En d'autres termes, l'option PARANOID peut être utilisée pour définir l'action a effectuer dès qu'une connexion se fait à partir d'une adresse IP qui diffère de celle attachée à une machine. L'exemple suivant apporte un éclairage sur cette option:
# Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny
Dans cet exemple, toutes les requêtes de connexion à sendmail à partir d'adresses IP différentes de celle correspondant au nom de la machine seront refusées.
AttentionUtiliser l'option PARANOID peut gravement paralyser les serveurs si le client ou le serveur a une configuration de DNS défectueuse. Les administrateurs sont maintenant prévenus.
Pour en apprendre plus sur les jokers et leurs fonctionnalités associées, consultez la page de manuel hosts_access(5).
Avant que n'importe quelle des lignes de configuration données ci-dessus ne fonctionne, la première ligne de configuration du fichier hosts.allow devra être dé-commentée. Cela a été noté en début de section.
| Précédent | Sommaire | Suivant |
| Mots de passe non réutilisables | Niveau supérieur | Kerberos |
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.