Red Hat Enterprise Linux 3: Guide de référence | ||
---|---|---|
Précédent | Chapitre 16. Les enveloppeurs TCP et xinetd | Suivant |
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 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.
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 :
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 de 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 pressant sur la touche
|
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 la Section 16.2.1.1). La liste des démons accepte aussi les opérateurs énumérés dans la Section 16.2.1.4 afin d'offrir une plus grande flexibilité.
<liste de clients> — correspond à une liste de noms d'hôtes, d'adresses IP hôtes, de gabarits spéciaux, (voir la Section 16.2.1.2) ou de jokers (wildcards) spéciaux (voir la Section 16.2.1.1), 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 la Section 16.2.1.4 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 la Section 16.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 16.2.2).
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.
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 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 |
![]() | Important |
---|---|
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.
![]() | 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 de réseau. Il est donc préférable, autant que possible, d'utiliser des adresses IP. |
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.
À 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'é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. |
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.
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 |
![]() | Remarque |
---|---|
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. |
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 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.
Précédent | Sommaire | Suivant |
Les enveloppeurs TCP et xinetd | Niveau supérieur | xinetd |