17.2. Fichiers de configuration des enveloppeurs TCP
Afin de déterminer si un ordinateur client est autorisé à se connecter à un service, les enveloppeurs TCP référencent les deux fichiers suivants, couramment appelés fichiers d'accès des hôtes :
/etc/hosts.allow
/etc/hosts.deny
Lorsqu'une requête client est reçue par un service enveloppé avec TCP, ce dernier suit les étapes élémentaires ci-dessous :
Le service référence /etc/hosts.allow — 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 référence /etc/hosts.deny — 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.
 | Avertissement | |
|---|---|---|
Si la dernière ligne du fichier d'accès d'hôtes ne correspond pas au caractère symbolisant une nouvelle ligne (créé en appuyant sur la touche
|
17.2.1. Formatage des règles d'accès
Le format est le même pour le fichier /etc/hosts.allow et le fichier /etc/hosts.deny. Aucune ligne blanche ou commençant par un symbole dièse (#) n'est pas prise en compte ; de plus, chaque règle doit figurer sur sa propre ligne.
Chaque règle utilise le format élémentaire suivant pour contrôler l'accès aux services réseau :
<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 virgule ou au caractère génériqueALL (aussi appelé wildcard), (voir la Section 17.2.1.1). La liste des démons accepte également des opérateurs (voir la Section 17.2.1.4 afin d'offrir une plus grande flexibilité.
<client list> — Correspond à une liste de noms d'hôtes, d'adresses IP d'hôtes, de filtres spéciaux, (voir la Section 17.2.1.2) ou de jokers (aussi appelés wildcards) spéciaux (voir la Section 17.2.1.1), dont les éléments sont séparés les uns des autres par une virgule. Cette liste identifie les hôtes auxquels la règle s'applique. La liste de clients accepte également les opérateurs énumérés dans la Section 17.2.1.4 afin d'offrir une plus grande flexibilité.
<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. Les champs d'options prennent en charge les expansions (voir la Section 17.2.2.4) et peuvent être utilisés pour lancer des commandes du shell, autoriser ou refuser l'accès et modifier le comportement de connexion (voir la Section 17.2.2).
Ci-après figure un exemple élémentaire de règle d'accès d'hôtes :
vsftpd : .example.com |
Cette règle donne aux enveloppeurs TCP l'instruction de surveiller les connexions établies au démon FTP (vsftpd) à partir de tout hôte du domaine example.com. Si cette règle apparaît dans hosts.allow, la connexion sera acceptée. En revanche, si la règle est présente dans hosts.deny, la connexion sera refusée.
La règle d'accès d'hôtes figurant ci-dessous est plus complexe et inclus deux champs d'option :
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny |
Notez que chaque champ d'option est précédé de la barre oblique inverse (\). L'utilisation de ce symbole empêche que la règle n'échoue en raison de sa longueur.
Cet exemple de règle stipule que si un hôte du domaine example.com essaie d'établir une connexion au démon SSH (sshd), la commande echo doit être exécutée (permettant de journaliser cette tentative de connexion dans un fichier spécial) et la connexion doit être refusée. Puisque la directive optionnelle deny est utilisée, cette ligne entraînera un refus de l'accès même si elle figure dans le fichier hosts.allow. Pour obtenir des informations plus détaillées sur les options disponibles, reportez-vous à la Section 17.2.2.
17.2.1.1. Jokers
Les jockers (aussi appelés wildcards) permettent aux enveloppeurs TCP d'autoriser plus facilement les groupes de démons et d'hôtes. Ils sont le plus souvent utilisés dans le champ relatif à la liste de clients des règles d'accès.
Les jokers (ou wildcards) suivants peuvent être utilisés :
ALL — Accorde à tout client l'accès d'un service. Ce joker peut être utilisé aussi bien pour la liste des démons que celle des clients.
LOCAL — Autorise tout hôte ne contenant pas de point (.), tel que locahost.
KNOWN — Autorise tout hôte dont le nom ou l'adresse d'hôte sont connus ou lorsque l'utilisateur est connu.
UNKNOWN — Autorise tout hôte dont le nom ou l'adresse d'hôte sont inconnus ou lorsque l'utilisateur est inconnu.
PARANOID — Autorise tout hôte dont le nom d'hôte ne correspond pas à l'adresse d'hôte.
 | Attention |
|---|---|
Les jokers KNOWN, UNKNOWN et PARANOID doivent être utilisés avec précaution car une rupture de la résolution de noms peut empêcher des utilisateurs légitimes de se voir accorder l'accès au service. |
17.2.1.2. Filtres
Les filtres peuvent être utilisés dans le champ relatif à la liste de clients faisant partie des règles d'accès afin de spécifier de manière plus précise des groupes d'hôtes clients.
Ci-dessous figure une liste des filtres les plus couramment acceptés pour une entrée dans la liste de clients :
Nom d'hôte commençant par un point (.) — En plaçant un point au début d'un nom d'hôte, tous les hôtes partageant les éléments listés du nom seront autorisés. L'exemple suivant s'applique à tout hôte du domaine example.com :
ALL : .example.com
Adresse IP finissant par un point (.) — En plaçant un point à la fin d'une adresse IP, tous les hôtes partageant les premiers groupes numériques d'une adresse IP seront autorisés. L'exemple suivant s'applique à tout hôte du réseau 192.168.x.x :
ALL : 192.168.
Paire adresse IP / masque réseau — Les expressions de masques réseau peuvent également être utilisées comme filtre pour contrôler l'accès à un groupe particulier d'adresses IP. L'exemple suivant s'applique à tout hôte doté d'une adresse IP comprise entre 192.168.0.0 et 192.168.1.255 :
ALL : 192.168.0.0/255.255.254.0
Important Dans l'espace d'adressage IPv4, les déclarations de paires adresse / longueur de préfixe (prefixlen) ne sont pas prises en charge. Seules les règles IPv6 peuvent utiliser ce format.
Paire [adresse IPv6] / prefixlen — Les paires [net] / prefixlen peuvent également être utilisées comme un filtre pour contrôler l'accès à un groupe particulier d'adresses IPv6. L'exemple suivant s'applique à tout hôte doté d'une adresse IP comprise entre 3ffe:505:2:1:: et 3ffe:505:2:1:ffff:ffff:ffff:ffff :
ALL : [3ffe:505:2:1::]/64
L'astérisque (*) — Des astérisques peuvent être utilisés pour autoriser des groupes entiers de noms d'hôtes ou d'adresses IP, à condition qu'ils ne fassent pas aussi partie d'une liste de clients contenant d'autres types de filtres. L'exemple suivant s'appliquerait à tout hôte du domaine example.com :
ALL : *.example.com
La barre oblique (/) — Si une liste de clients commence par une barre oblique, elle est considérée comme un nom de fichier. Ce symbole est utile lorsque des règles spécifiant de nombreux hôtes sont nécessaires. L'exemple suivant renvoie les enveloppeurs TCP au fichier /etc/telnet.hosts pour toutes les connexion à Telnet :
in.telnetd : /etc/telnet.hosts
D'autres filtres, moins utilisés, sont également acceptés par les enveloppeurs TCP. Consultez la section 5 de la page de manuel d'hosts_access pour obtenir de plus amples informations.
| Avertissement |
|---|---|
Soyez très prudent lorsque vous utilisez des noms d'hôtes et des noms de domaines. Des agresseurs peuvent recourir à une variété de tactiques pour contourner une résolution de nom précise. En outre, toute perturbation du service DNS empêcherait même des utilisateurs autorisés d'utiliser les services réseau. Il est donc préférable, autant que possible, d'utiliser des adresses IP. |
17.2.1.3. Portmap et les enveloppeurs TCP
Lors de la création de règles de contrôle d'accès pour portmap, n'utilisez pas de noms d'hôtes car l'implémentation des enveloppeurs TCP de portmap ne prend pas en charge la consultation des hôtes. Pour cette raison, utilisez seulement des adresses IP ou le mot-clé ALL lors de la spécification des hôtes dans hosts.allow ou hosts.deny.
De plus, les changements apportés aux règles de contrôle d'accès de portmap ne prennent pas toujours effet immédiatement sans devoir redémarrer le service portmap.
Étant donné que des services très populaires comme NIS et NFS dépendent de portmap pour fonctionner, assurez-vous de bien prendre ces limitations en compte.
17.2.1.4. Opérateurs
À l'heure actuelle, les règles de contrôle d'accès acceptent un seul opérateur, à savoir EXCEPT. Il peut être utilisé aussi bien dans la liste des démons d'une règle que dans celle des clients.
L'opérateur EXCEPT permet d'introduire des exceptions spécifiques à des correspondances plus générales au sein de la même règle.
Dans l'exemple ci-dessous tiré d'un fichier hosts.allow, tous les hôtes example.com sont autorisés à se connecter aux services sauf cracker.example.com :
ALL: .example.com EXCEPT cracker.example.com |
Dans l'autre exemple ci-dessous tiré du fichier hosts.allow, les clients du réseau 192.168.0.x peuvent utiliser tous les services sauf FTP :
ALL EXCEPT vsftpd: 192.168.0. |
 | Remarque |
|---|---|
Au niveau de l'organisation, il est souvent plus facile d'éviter d'utiliser les opérateurs EXCEPT. Ce faisant, d'autres administrateurs peuvent examiner rapidement les fichiers appropriés pour voir les hôtes pour lesquels l'accès aux services doit être autorisé ou refusé, sans devoir examiner tous les opérateurs EXCEPT. |
17.2.2. Champs d'options
Outres les règles élémentaires autorisant ou refusant l'accès, l'implémentation de Red Hat Enterprise Linux des enveloppeurs TCP prend en charge des extensions au langage du contrôle d'accès grâce à des champs d'options. En utilisant des champs d'options au sein des règles d'accès d'hôtes, les administrateurs peuvent accomplir un vaste éventail de tâches telles que la modification du comportement de journalisation, la consolidation du contrôle d'accès et le lancement de commandes du shell.
17.2.2.1. Journalisation
Les champs d'options permettent aux administrateurs de changer facilement la fonction de journalisation et le niveau de gravité d'une règle à l'aide de la directive severity.
Dans l'exemple suivant, les connexions au démon SSH à partir de tout hôte du domaine example.com sont journalisées avec la facility par défaut de syslog authpriv (car aucune valeur de facility n'est spécifiée) avec une priorité emerg :
sshd : .example.com : severity emerg |
Il est également possible de spécifier un service à l'aide de l'option severity. L'exemple suivant journalise tous les hôtes du domaine example.com qui tentent de se connecter au service SSH avec une facility de local0 et alert comme priorité :
sshd : .example.com : severity local0.alert |
| Remarque |
|---|---|
Dans la pratique, cet exemple ne fonctionne pas tant que le démon syslog (syslogd) est configuré pour journaliser sur la fonction local0. Consultez la page de manuel de syslog.conf pour obtenir de plus amples informations sur la configuration personnalisée des fonctions de journalisation. |
17.2.2.2. Contrôle d'accès
Les champs d'options permettent également aux administrateurs d'autoriser ou de refuser de manière explicite des hôtes dans une seule règle en ajoutant la directive allow ou deny en tant que dernière option.
Par exemple, les deux règles suivantes autorisent des connexions SSH à partir de client-1.example.com, mais les refusent à partir de client-2.example.com :
sshd : client-1.example.com : allow sshd : client-2.example.com : deny |
En permettant le contrôle d'accès sur la base de règles individuelles, le champ d'options parmet aux administrateurs de consolider toutes les règles d'accès dans un seul et même fichier : soit hosts.allow, soit hosts.deny. Pour certains, cette méthode est la manière la plus simple d'organiser des règles d'accès.
17.2.2.3. Commandes du shell
Les champs d'options permettent aux règles d'accès de lancer des commandes du shell au moyen des deux directives suivantes :
spawn — Lance une commande du shell en tant que processus enfant. Cette directive permet d'effectuer des tâches comme l'utilisation de /usr/sbin/safe_finger pour obtenir des informations supplémentaires sur le client faisant une requête ou pour créer des fichiers de journalisation spéciaux en utilisant la commande echo.
Dans l'exemple suivant, les clients essayant d'accéder aux services Telnet à partir du domaine example.com sont journalisés dans un fichier spécial :
in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow
twist — Remplace le service demandé par la commande spécifiée. Cette directive est souvent utilisée pour créer des pièges à l'intention des agresseurs (également appelés "pots de miel" ou "honey pots"). Elle peut également être utilisée pour envoyer des messages à des clients se connectant. La commande twist doit se trouver à la fin de la ligne de règles.
Dans l'exemple suivant, les clients essayant d'accéder aux services FTP à partir du domaine example.com reçoivent un message envoyé au moyen de la commande echo :
vsftpd : .example.com \ : twist /bin/echo "421 Bad hacker, go away!"
Pour obtenir de plus amples informations sur les options des commandes du shell, consultez la page de manuel de hosts_options.
17.2.2.4. Expansions
Les expansions, lorsqu'elles sont utilisées de concert avec les directives spawn et twist permettent d'obtenir des informations sur le client, le serveur et les processus impliqués.
Ci-après figure une liste des expansions prises en charge :
%a — Fournit l'adresse IP du client.
%A — Fournit l'adresse IP du serveur.
%c — Fournit diverses informations sur le client, comme les noms d'utilisateur et d'hôte, ou le nom d'utilisateur et l'adresse IP.
%d — Fournit le nom du processus démon.
%h — Fournit le nom d'hôte du client (ou l'adresse IP, si le nom d'hôte n'est pas disponible).
%H — Fournit le nom d'hôte du serveur (ou l'adresse IP, si le nom d'hôte n'est pas disponible).
%n — Fournit le nom d'hôte du client. S'il n'est pas disponible, unknown est affiché. S'il n'y a pas de correspondance entre le nom d'hôte et l'adresse du client, paranoid est alors affiché.
%N — Fournit le nom d'hôte du serveur. Si celui-ci n'est pas disponible, unknown est affiché. S'il n'y a pas de correspondance entre le nom d'hôte et l'adresse du client, paranoid est affiché.
%p — Fournit l'ID du processus démon.
%s — Fournit divers types d'informations sur le serveur, tels que le processus démon et l'hôte ou l'adresse IP du serveur.
%u — Fournit le nom d'utilisateur du client. Si celui-ci n'est pas disponible, unknown est affiché.
L'exemple de règle suivant utilise une expansion en même temps que la commande spawn pour identifier l'hôte client dans un fichier de journalisation personnalisé.
Lors de toute tentative de connexion au démon SSH (sshd) à partir d'un hôte du domaine example.com, exécutez la commande echo afin de journaliser non seulement la tentative, mais également le nom d'hôte du client (à l'aide de l'expansion %h), dans un fichier spécial :
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \ : deny |
De même, des expansions peuvent être utilisées pour personnaliser les messages renvoyés au client. Dans l'exemple suivant, les clients essayant de se connecter aux services FTP à partir du domaine example.com sont informés qu'ils ont été bannis du serveur :
vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!" |
Pour obtenir une explication complète des expansions disponibles et des options supplémentaires de contrôle d'accès, reportez-vous à la section 5 de la page de manuel d'hosts_access (man 5 hosts_access) et à la page de manuel d'hosts_options.
Pour obtenir des informations supplémentaires sur les enveloppeurs TCP, consultez la Section 17.5. Pour des informations sur la manière de sécuriser les enveloppeurs TCP, consultez le chapitre intitulé Sécurité du serveur du Guide de sécurité de Red Hat Enterprise Linux.