Listes de contrôle d'accès basé sur l'hôte

Ecriture des règles

Toutes les règles de contrôle d'accès sont écrites sous forme de ligne dans les fichiers hosts.allow et hosts.deny. Chaque ligne vide ou commençant par le symbole de commentaire (#) n'est pas prise en compte. Chaque règle doit être écrite sur une ligne séparée.

Les règles doivent se présenter de la façon suivante :

<liste_démons>: <liste_clients>[: <commande_shell> ]

Chacune de ces options fait référence à une portion différente de la règle :

• liste_démons — Ensemble d'un ou plusieurs noms de processus ou de caractères spéciaux, séparés par un espace.

• liste_clients — Un ou plusieurs noms d'hôte, adresses hôte, motifs ou caractères spéciaux, séparés par un espace, à utiliser lorsqu'un nom de processus correspond à un service demandé.

• commande_shell — Commande optionnelle qui précise ce qui doit être fait lorsqu'une règle est utilisée.

Les motifs se révèlent pratiques lorsqu'il s'agit de définir des groupes de clients qui peuvent ou ne peuvent pas avoir accès à un service donné. En plaçant le symbole "." (point) au début d'une chaîne, la même règle se verra appliquée à tous les hôtes qui ont en commun la fin de cette chaîne. Ainsi, .domain.com détecterait tant system1.domain.com que system2.domain.com. Le symbole "." (point) à la fin d'une chaîne a le même effet, mais dans la direction opposée. Ceci est surtout utilisé pour les adresses IP ; ainsi une règle s'appliquant à 192.168.0. sera valable pour tout le bloc de classe C de cette adresse IP. On peut aussi utiliser des expressions de masque réseau comme motif pour contrôler l'accès à un groupe d'adresses IP donné. Vous pouvez même utiliser des astérisques (*) ou des points d'interrogation (?) pour définir des groupes entiers de noms d'hôte ou d'adresses IP. Toutefois, ceux-ci ne peuvent être utilisés dans la même chaîne, comme les autres types de motif.

Si votre liste de noms d'hôte pouvant accéder à un service est trop longue ou difficile à contrôler à l'intérieur de host.allow ou hosts.deny, il est alors possible d'indiquer le chemin d'accès complet vers un fichier, tel que /etc/telnet.hosts.deny. Ce fichier doit contenir les différents noms d'hôte, adresses hôte ou motifs, séparés par un espace, qui sont autorisés ou non à accéder à ce service. Cette méthode peut être utilisée également de façon efficace pour partager des listes de contrôle d'accès entre différents services, en permettant les changements des paramètres dans un fichier seulement pour tous les services.

Les mots ou caractères spéciaux suivants peuvent être utilisés dans les règles de contrôle d'accès à la place d'hôtes ou de groupes d'hôtes spécifiques :

• ALL — Correspond à chaque client lié à ce service précis ou même chaque service utilisant le contrôle d'accès. ALL est aussi applicable aux démons.

• LOCAL — Correspond à tous les hôtes sans le symbole ".".

• KNOWN — Correspond à tous les hôtes dont le nom d'hôte, l'adresse hôte ou l'utilisateur est connu.

• UNKNOWN — Correspond à tous les hôtes dont le nom d'hôte, l'adresse hôte ou l'utilisateur est inconnu.

• PARANOID — Correspond à tout hôte dont le nom ne correspond pas à l'adresse d'hôte.

	Avertissement
	Les mots KNOWN, UNKNOWN et PARANOID doivent être utilisés prudemment car la moindre erreur de frappe pourrait empêcher des utilisateurs légitimes d'accéder à un service réseau.

Le langage de contrôle d'accès contient également une variable puissante, EXCEPT, qui consent la mise en commun de plusieurs listes au sein d'une même ligne de règle. Lorsque EXCEPT est utilisé entre deux listes, la première s'applique sauf s'il y a correspondance entre un paramètre de la seconde liste et un autre spécifié dans la première. EXCEPT peut être employé avec des démons ou des listes de clients. Voici un exemple de fichier hosts.allow :

# tous les hôtes domain.com sont autorisés à se connecter
# à tous les services, sauf cracker.domain.com
ALL: .domain.com EXCEPT cracker.domain.com

# les adresses 123.123.123.* peuvent utiliser tous les services sauf FTP
ALL EXCEPT in.ftpd: 123.123.123.

	Remarque
	Il est préférable d'utiliser la variable EXCEPT avec parcimonie et d'inclure plutôt les exceptions à la règle dans un autre fichier de contrôle d'accès. Ceci permet aux administrateurs de visualiser rapidement quels hôtes ou noms d'hôte peuvent accéder ou non à quels services sans avoir à relire toutes les variables EXCEPT ou à vérifier leur élaboration.

La meilleure façon d'utiliser hosts.allow et hosts.deny pour contrôler l'accès, consiste à les utiliser ensemble pour obtenir le résultat escompté. Ainsi, les utilisateurs souhaitant empêcher tout hôte autre que des hôtes spécifiques à accéder aux services placent d'abord ALL: ALL dans le fichier hosts.deny. Ils placent ensuite des lignes dans hosts.allow, telles que portmap, in.telnetd: 10.0.1.24 ou in.ftpd: 10.0.1. EXCEPT 10.0.1.1, pour permettre l'accès à certains hôtes seulement.

Autrement, certains administrateurs laissent libre accès aux services de réseau à tous, à l'exception de certains hôtes bien définis. Dans ce cas, rien n'est indiqué dans hosts.allow et les informations concernant les hôtes interdits sont placées dans hosts.deny, tel que in.fingerd: 192.168.0.2.

Attention

Il faut toutefois prêter une certaine attention lors de l'écriture de noms d'hôte ou de noms de domaine dans ces deux fichiers de contrôle d'accès, plus particulièrement dans hosts.deny. Plusieurs modes de contournement des règles spécifiées par nom sont connus des pirates. De plus, si votre système autorise les accès en les sélectionnant sur la base de leur nom d'hôte ou de domaine, celui-ci deviendrait inaccessible aux utilisateurs autorisés en cas de rupture du service DNS. On peut donc éviter beaucoup de désagréments en utilisant des adresses IP lors de la création de règles de contrôle d'accès chaque fois que cela s'avère faisable, surtout pour les règles interdisant les accès.

Au-delà de la simple autorisation ou du refus d'accès aux services à certains hôtes, le langage de contrôle d'accès prend également en charge l'utilisation de commandes du shell lorsque cette règle est utilisée. Ces commandes du shell sont utilisées essentiellement avec des règles d'interdiction (deny), dans le but de parer à des bombes à retardement, à l'origine d'actions créant rapidement des journaux contenant les accès manqués sous forme de fichier spécial ou de message électronique envoyé à l'administrateur du réseau. Voici l'exemple d'une bombe à retardement située dans le fichier hosts.deny qui génère l'écriture d'un journal contenant la date et le client chaque fois qu'un hôte, dont l'adresse IP est comprise entre 10.0.1.0 et 10.0.1.255, tente de se connecter via Telnet :

in.telnetd: 10.0.1.: (/bin/echo `date` %c >> /var/log/telnet.log) &

Voici une liste d'extensions contenant des informations spécifiques relatives au client, au serveur et aux processus utilisés disponibles aux commandes du shell :

• %a — Adresse IP du client.

• %A — Adresse IP du serveur.

• %c — Différents types d'information sur le client, tels que nom d'utilisateur et nom d'hôte ou nom d'utilisateur et adresse IP.

• %d — Nom du processus démon.

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

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

• %n — Nom d'hôte du client. Si aucune information n'est disponible, le mot unknown est affiché. Dans le cas où le nom d'hôte du serveur et l'adresse d'hôte ne correspondraient pas, le mot paranoid est affiché.

• %N — Nom d'hôte du serveur. Si aucune information n'est disponible, le mot unknown est affiché. Dans le cas où le nom d'hôte du serveur et l'adresse d'hôte ne correspondraient pas, le mot paranoid est affiché.

• %p — Identifiant du processus démon.

• %s — Différents types d'information sur le serveur, tels que processus démon, adresse d'hôte ou adresse IP du serveur.

• %u — Nom d'utilisateur du client. Si aucune information n'est disponible, le mot unknown est affiché.

Pour de plus amples informations concernant les commandes du shell, ainsi que d'autres exemples de contrôle d'accès, veuillez vous reporter à la page de manuel de hosts_access(5).

Remarque

Prêtez une attention particulière à la commande portmap lorsqu'elle est utilisée avec des listes de contrôle d'accès aux hôtes. Seules des adresses IP et l'option ALL devraient être employées lors de la définition d'autorisation et de refus d'accès aux hôtes, dans la mesure ou les noms d'hôte ne sont pas pris en charge. De plus, les changements apportés aux listes de contrôle d'accès d'hôtes qui concernent portmap ne sont pas nécessairement appliqués immédiatement. Vu que certains services très utilisés, tels que NIS et NFS, dépendent de portmap pour leur fonctionnement, tenez compte de ces limitations avant de dépendre des fichiers hosts.allow et hosts.deny pour contrôler l'accès de certains hôtes.