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.
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.
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.
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.
Utiliser 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.
Ce document, ainsi que d'autres peut être téléchargé sur ftp://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>.