16.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 :

Lorsqu'une requête cliente est reçue par un service enveloppé avec TCP, ce dernier suit les étapes élémentaires suivantes :

  1. 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 à la deuxième étape.

  2. 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 à prendre en compte lors de l'utilisation d'enveloppeurs TCP pour protéger des services de réseau :

AvertissementAvertissement
 

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 pressant sur la touche [Entrée]), la dernière règle du fichier échouera et un message d'erreur sera journalisé soit dans /var/log/messages, soit dans /var/log/secure. Ceci s'applique aussi à des lignes de règles qui s'étendent sur plusieurs lignes sans inclure le symbole de la barre oblique inverse. L'exemple suivant illustre la partie pertinente d'un message de journalisation faisant référence à l'échec d'une règle en raison de l'une ou l'autre de ces circonstances :

warning: /etc/hosts.allow, line 20: missing newline or line too long

16.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. Toute ligne vierge ou commençant pas 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 de réseau :

<daemon list>: <client list> [: <option>: <option>: ...]

Ci-après figure un exemple élémentaire de règle d'accès d'hôte :

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 suivante 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 dans cet exemple, 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.

Cette 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 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 des informations plus détaillées sur les options disponibles, reportez-vous à la Section 16.2.2.

16.2.1.1. Jokers (ou Wildcards)

Les jockers permettent aux enveloppeurs TCP d'autoriser plus facilement les groupes de démons et les hôtes. Ils sont le plus souvent utilisés dans le champ de la liste de clients des règles d'accès.

Les jokers 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 (.), comme par exemple un hôte local.

  • 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.

AttentionAttention
 

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 d'accéder au service.

16.2.1.2. Gabarits

Les gabarits peuvent être utilisés dans le champ de la liste de clients 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 gabarits les plus communément 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 un modèle 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
     

    ImportantImportant
     

    Dans l'espace d'adresses 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 modèle 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 gabarits. 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 gabarits, moins utilisés sont également acceptés par les enveloppeurs TCP. Consultez la section 5 de la page de manuel relative à hosts_access pour de plus amples informations.

AvertissementAvertissement
 

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 de réseau.

Il est donc préférable, autant que possible, d'utiliser des adresses IP.

16.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 les noms d'hôtes car son implémentation des enveloppeurs TCP 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 portmap ne prennent pas toujours effet immédiatement sans redémarrer le service portmap.

Étant donné que des services très populaires comme NIS et NFS, dépendent de portmap pour leur fonctionnement, assurez-vous de bien prendre ces limitations en compte.

16.2.1.4. Opérateurs

À l'heure actuelle, les règles de contrôle d'accès acceptent un 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 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.

NoteRemarque
 

D'un point de vue organisationnel, il est souvent plus facile d'éviter d'utiliser les opérateurs EXCEPT. Ce faisant, d'autres administrateurs peuvent examiner rapidement le fichier approprié pour voir quels hôtes doivent être autorisés ou refusés pour quels services, sans devoir trier les divers opérateurs EXCEPT.

16.2.2. Les champs d'options

Au delà de la simple autorisation ou du refus d'accès, l'implémentation Red Hat Enterprise Linux des enveloppeurs TCP prend en charge des extensions au langage utilisé pour le contrôle d'accès au moyen 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, comme entre autres, la modification du comportement de journalisation, la consolidation du contrôle d'accès et le lancement de commandes du shell.

16.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 dans la fonction syslog authpriv par défaut (car aucune valeur de fonction 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 essayant de se connecter au service SSH dans local0 avec la priorité alert:

sshd : .example.com : severity local0.alert

NoteRemarque
 

Dans la pratique, cet exemple ne fonctionnera pas tant que le démon syslog (syslogd) est configuré pour qu'il journalise sur local0. Consultez la page de manuel relative à syslog.conf pour de plus amples informations sur la configuration personnalisée des fonctions de journalisation.

16.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 permettent 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 champs 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.

16.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 services demandé par la commande spécifiée. Cette directive est souvent utilisée pour créer des pièges pour les agresseurs. 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 de plus amples informations sur les options des commandes du shell, consultez la page de manuel relative à hosts_options.

16.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 — L'adresse IP du client.

  • %A — 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 — Le nom du processus du démon.

  • %h — Le nom d'hôte du client (ou l'adresse IP, si le nom d'hôte n'est pas disponible).

  • %H — Le nom d'hôte du serveur (ou l'adresse IP, si le nom d'hôte n'est pas disponible).

  • %n — Le nom d'hôte du client. S'il n'est pas disponible, unknown est imprimé. Si le nom d'hôte et l'adresse du client ne correspondent pas, paranoid est imprimé.

  • %N — Le nom d'hôte du serveur. Si celui-ci n'est pas disponible, unknown est imprimé. Si le nom d'hôte et l'adresse du client ne correspondent pas, paranoid est imprimé.

  • %p — L'ID du processus de démon.

  • %s — Divers types d'informations sur le serveur, comme le processus de démon et l'hôte ou l'adresse IP du serveur.

  • %u — Le nom d'utilisateur du client. Si celui-ci n'est pas disponible, unknown est imprimé.

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 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 relative à hosts_access (man 5 hosts_access) et à la page de manuel relative à hosts_options.

Pour obtenir des informations supplémentaires sur les enveloppeurs TCP, consultez la Section 16.5. Pour des informations sur la manière de sécuriser les enveloppeurs TCP, consultez le chapitre intitulé Sécurité du serveur dans le Guide de sécurité de Red Hat Enterprise Linux.