Red Hat Linux 9: Guide de référence de Red Hat Linux | ||
---|---|---|
Prev | Chapter 15. Les enveloppeurs TCP et xinetd | Next |
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 cliente est reçue par un service enveloppé avec TCP, ce dernier suit les étapes élémentaires suivantes:
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.
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:
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 essentiel.
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 de réseau.
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>: ...] |
<daemon list> — correspond à une liste de noms de processus (pas des noms de services) ou caractère générique (ou 'wildcard') ALL, séparés par des virgules (Consultez Section 15.2.1.1 Jokers (ou 'Wildcards')). La liste des démons accepte aussi les opérateurs énumérés dans Section 15.2.1.3 Opérateurs afin d'offrir une plus grande flexibilité.
<client list> — correspond à une liste de noms d'hôtes, d'adresses IP hôtes, de gabarits spéciaux, (voir Section 15.2.1.2 Patterns) ou de jokers ('wildcards') (voir Section 15.2.1.1 Jokers (ou 'Wildcards')), séparés par des virgules, identifiant les hôtes auxquels la règle s'applique. La liste de clients accepte également les opérateurs énumérés dans Section 15.2.1.3 Opérateurs afin d'offrir une plus grande flexibilité.
<option> — correspond à une action facultative ou à une liste d'actions facultatives séparées par des virgules, devant être exécutées lorsque la règle est appliquée. Les champs d'options prennent en charge les expansions (voir Section 15.2.3.4 Expansions) et peuvent être utilisés pour lancer des commandes du shell, autoriser ou refuser l'accès et modifier le comportement de connexion (voir Section 15.2.3 Les champs d'options).
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.
![]() | 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 pressant sur la touche
|
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.
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.
![]() | 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 d'accéder au service. |
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.
![]() | Avertissement |
---|---|
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. |
À 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. |
![]() | Remarque |
---|---|
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. |
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.
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.
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 |
![]() | Remarque |
---|---|
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. |
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.
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.
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.