17.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�:
/etc/hosts.allow
/etc/hosts.deny
Lorsqu'une requ�te client est re�ue par un service envelopp� avec TCP, ce dernier suit les �tapes �l�mentaires ci-dessous�:
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 � l'�tape suivante.
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 qu'il convient de prendre en compte lors de l'utilisation d'enveloppeurs TCP pour prot�ger des services 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 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 appuyant 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. Ce principe s'applique �galement � des r�gles s'�tendant sur plusieurs lignes o� le symbole de la barre oblique inverse est omis. L'exemple suivant illustre la partie pertinente d'un message de journal relatif � l'�chec d'une r�gle en raison de l'une ou l'autre des circonstances mentionn�es pr�c�demment�:
warning: /etc/hosts.allow, line 20: missing newline or line too long
17.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. Aucune ligne blanche ou commen�ant par 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 r�seau�:
<daemon list> — Correspond � une liste de noms de processus (pas de noms de services) s�par�s les uns des autres par une virgule ou au caract�re g�n�riqueALL (aussi appel� wildcard), (voir la Section 17.2.1.1). La liste des d�mons accepte �galement des op�rateurs (voir la Section 17.2.1.4 afin d'offrir une plus grande flexibilit�.
<client list> — Correspond � une liste de noms d'h�tes, d'adresses IP d'h�tes, de filtres sp�ciaux, (voir la Section 17.2.1.2) ou de jokers (aussi appel�s wildcards) sp�ciaux (voir la Section 17.2.1.1), dont les �l�ments sont s�par�s les uns des autres par une virgule. Cette liste identifie les h�tes auxquels la r�gle s'applique. La liste de clients accepte �galement les op�rateurs �num�r�s dans la Section 17.2.1.4 afin d'offrir une plus grande flexibilit�.
<option> — Correspond � une action facultative ou � une liste d'actions facultatives s�par�es les unes des autres par une virgule, devant �tre ex�cut�e lorsque la r�gle est appliqu�e. Les champs d'options prennent en charge les expansions (voir la Section 17.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 17.2.2).
Ci-apr�s figure un exemple �l�mentaire de r�gle d'acc�s d'h�tes�:
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 figurant ci-dessous est plus complexe et inclus deux champs d'option�:
Notez que 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.
Cet 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 doit �tre 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 obtenir des informations plus d�taill�es sur les options disponibles, reportez-vous � la Section 17.2.2.
17.2.1.1. Jokers
Les jockers (aussi appel�s wildcards) permettent aux enveloppeurs TCP d'autoriser plus facilement les groupes de d�mons et d'h�tes. Ils sont le plus souvent utilis�s dans le champ relatif � la liste de clients des r�gles d'acc�s.
Les jokers (ou wildcards) 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 (.), tel que locahost.
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 de se voir accorder l'acc�s au service.
17.2.1.2. Filtres
Les filtres peuvent �tre utilis�s dans le champ relatif � la liste de clients faisant partie 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 filtres les plus couramment 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 filtre 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'adressage 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 filtre 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 filtres. 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 filtres, moins utilis�s, sont �galement accept�s par les enveloppeurs TCP. Consultez la section 5 de la page de manuel d'hosts_access pour obtenir 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 r�seau.
Il est donc pr�f�rable, autant que possible, d'utiliser des adresses IP.
17.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 de noms d'h�tes car l'impl�mentation des enveloppeurs TCP de portmap 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 de portmap ne prennent pas toujours effet imm�diatement sans devoir red�marrer le service portmap.
�tant donn� que des services tr�s populaires comme NIS et NFS d�pendent de portmap pour fonctionner, assurez-vous de bien prendre ces limitations en compte.
17.2.1.4. Op�rateurs
� l'heure actuelle, les r�gles de contr�le d'acc�s acceptent un seul 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 plus 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
Au niveau de l'organisation, il est souvent plus facile d'�viter d'utiliser les op�rateurs EXCEPT. Ce faisant, d'autres administrateurs peuvent examiner rapidement les fichiers appropri�s pour voir les h�tes pour lesquels l'acc�s aux services doit �tre autoris� ou refus�, sans devoir examiner tous les op�rateurs EXCEPT.
17.2.2. Champs d'options
Outres les r�gles �l�mentaires autorisant ou refusant l'acc�s, l'impl�mentation de Red Hat Enterprise Linux des enveloppeurs TCP prend en charge des extensions au langage du contr�le d'acc�s gr�ce � 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 telles que la modification du comportement de journalisation, la consolidation du contr�le d'acc�s et le lancement de commandes du shell.
17.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 avec la facility par d�faut de syslogauthpriv (car aucune valeur de facility 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 qui tentent de se connecter au service SSH avec une facility de local0 et alert comme priorit�:
sshd : .example.com : severity local0.alert
Remarque
Dans la pratique, cet exemple ne fonctionne pas tant que le d�mon syslog (syslogd) est configur� pour journaliser sur la fonction local0. Consultez la page de manuel de syslog.conf pour obtenir de plus amples informations sur la configuration personnalis�e des fonctions de journalisation.
17.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 autorisent des connexions SSH � partir de client-1.example.com, mais les refusent � partir de client-2.example.com�:
En permettant le contr�le d'acc�s sur la base de r�gles individuelles, le champ 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.
17.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�:
twist — Remplace le service demand� par la commande sp�cifi�e. Cette directive est souvent utilis�e pour cr�er des pi�ges � l'intention des agresseurs (�galement appel�s "pots de miel" ou "honey pots"). 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 obtenir de plus amples informations sur les options des commandes du shell, consultez la page de manuel de hosts_options.
17.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 — Fournit l'adresse IP du client.
%A — Fournit 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 — Fournit le nom du processus d�mon.
%h — Fournit le nom d'h�te du client (ou l'adresse IP, si le nom d'h�te n'est pas disponible).
%H — Fournit le nom d'h�te du serveur (ou l'adresse IP, si le nom d'h�te n'est pas disponible).
%n — Fournit le nom d'h�te du client. S'il n'est pas disponible, unknown est affich�. S'il n'y a pas de correspondance entre le nom d'h�te et l'adresse du client, paranoid est alors affich�.
%N — Fournit le nom d'h�te du serveur. Si celui-ci n'est pas disponible, unknown est affich�. S'il n'y a pas de correspondance entre le nom d'h�te et l'adresse du client, paranoid est affich�.
%p — Fournit l'ID du processus d�mon.
%s — Fournit divers types d'informations sur le serveur, tels que le processus d�mon et l'h�te ou l'adresse IP du serveur.
%u — Fournit le nom d'utilisateur du client. Si celui-ci n'est pas disponible, unknown est affich�.
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�:
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 obtenir 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 d'hosts_access (man 5 hosts_access) et � la page de manuel d'hosts_options.
Pour obtenir des informations suppl�mentaires sur les enveloppeurs TCP, consultez la Section 17.5. Pour des informations sur la mani�re de s�curiser les enveloppeurs TCP, consultez le chapitre intitul� S�curit� du serveur du Guide de s�curit� de Red Hat Enterprise Linux.
