15.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 fait l'analyse grammaticale du 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 connection. Sinon, il passe à la deuxième étape.

  2. Le service référence /etc/hosts.deny. — Le service enveloppé avec TCP fait l'analyse grammaticale du fichier /etc/hosts.deny de manière séquentielle. Si une règle correspond au service, il refuse la connection. 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:

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

WarningAvertissement
 

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 des circonstances mentionnées ci-dessus:

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

Cette exemple de règle stipule que si un hôte d 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 15.2.3 Les champs d'options.

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

CautionAttention
 

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.

15.2.1.2. Patterns

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 l'élément listé du nom seront autorisés. L'exemple suivant s'appliquerait à 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'appliquerait à tout hôte du réseau 192.168.x.x:

    ALL : 192.168.
  • Paire adresse IP/masque réseau — Les expression de masques réseau peuvent également être utilisées comme un gabarit pour contrôler l'accès à un groupe particulier d'adresses IP. L'exemple suivant s'appliquerait à 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
     
  • 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 à l'accès d'hôtes (hosts_access) pour de plus amples informations.

WarningAvertissement
 

Soyez très prudent lorsque vous créez des règles nécessitant une résolution de nom, comme par exemple, noms d'hôtes et noms de domaines. Des agresseurs peuvent recourir à une variétés 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 du réseau.

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

15.2.1.3. 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'utiliser les opérateurs EXCEPT avec parcimonie, en choisissant plutôt de placer les exceptions à la règle dans l'autre fichier de contrôle d'accès. 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.

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

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

15.2.3. Les champs d'options

Au delà de la simple autorisation ou du refus d'accès, l'implémentation Red Hat 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.

15.2.3.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 le journal 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 local0. Consultez les pages de manuel relatives à syslog.conf pour de plus amples informations sur la configuration personnalisée des fonctions de journalisation.

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

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

15.2.3.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 adresse IP, si le nom d'hôte n'est pas disponible).

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

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

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

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

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

  • %u — Le nom d'utilisateur du client. Si celui-ci n'est pas disponible, c'est unknown qui 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é.

Elle indique aux enveloppeurs TCP que, lors de toute tentative de connexion au démon SSH (sshd) à partir d'un hôte du domaine example.com, ils doivent exécuter 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ètes 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 des ressources supplémentaires sur les enveloppeurs TCP, reportez-vous à Section 15.5 Ressources supplémentaires.