prénom
hosts_access - format des fichiers de contrôle Linux avec accès hôte.
La description
Cette page de manuel décrit Linux comme un simple langage de contrôle d'accès basé sur les modèles de client (nom d'hôte / adresse, nom d'utilisateur) et de serveur (nom de processus, nom d'hôte / adresse). Des exemples sont donnés à la fin. Le lecteur impatient est invité à passer à la section Exemples pour une introduction rapide. Une version étendue du langage de contrôle d’accès est décrite dans la section hosts_options (5) document. Les extensions sont activées au moment de la construction du programme en construisant avec -DPROCESS_OPTIONS.
Dans le texte suivant, démon est le nom du processus d'un processus de démon réseau, et client est le nom et / ou l'adresse d'un hôte demandant le service. Les noms de processus du démon réseau sont spécifiés dans le fichier de configuration inetd.
Fichiers de contrôle d'accès
Le logiciel de contrôle d'accès consulte deux fichiers. La recherche s'arrête au premier match.
L'accès sera accordé lorsqu'une paire (démon, client) correspond à une entrée du /etc/hosts.allow fichier.
Sinon, l’accès sera refusé lorsqu’une paire (démon, client) correspond à une entrée de la liste. /etc/hosts.deny fichier.
Sinon, l'accès sera accordé.
Un fichier de contrôle d'accès non existant est traité comme s'il s'agissait d'un fichier vide. Ainsi, le contrôle d'accès peut être désactivé en ne fournissant aucun fichier de contrôle d'accès.
Règles de contrôle d'accès
Chaque fichier de contrôle d'accès est constitué de zéro ou plusieurs lignes de texte. Ces lignes sont traitées par ordre d'apparition. La recherche se termine lorsqu'une correspondance est trouvée.
Un caractère de nouvelle ligne est ignoré lorsqu'il est précédé d'un caractère barre oblique inverse. Cela vous permet de séparer les longues lignes afin qu’elles soient plus faciles à modifier.
Les lignes vierges ou commençant par le caractère "#" sont ignorées. Cela vous permet d'insérer des commentaires et des espaces afin que les tableaux soient plus faciles à lire.
Toutes les autres lignes doivent respecter le format suivant, les éléments entre étant facultatifs:
daemon_list: client_list : shell_command
liste_demon est une liste d'un ou plusieurs noms de processus de démon (valeurs argv 0) ou caractères génériques (voir ci-dessous).
liste_client est une liste d'un ou plusieurs noms d'hôtes, adresses d'hôtes, modèles ou caractères génériques (voir ci-dessous) qui seront comparés au nom ou à l'adresse de l'hôte du client.
Les formes les plus complexes daemon @ host et utilisateur @ hôte sont expliquées dans les sections sur les modèles de noeud final de serveur et sur les recherches de nom d'utilisateur du client, respectivement.
Les éléments de la liste doivent être séparés par des blancs et / ou des virgules.
À l'exception des recherches de groupe réseau NIS (YP), toutes les vérifications du contrôle d'accès sont sensibles à la casse.
Les motifs
Le langage de contrôle d'accès implémente les modèles suivants:
Une chaîne qui commence par un "." personnage. Un nom d'hôte est associé si les derniers composants de son nom correspondent au modèle spécifié. Par exemple, le modèle `.tue.nl 'correspond au nom d'hôte` wzv.win.tue.nl'.
Une chaîne qui se termine par un `. ' personnage. Une adresse d'hôte est mise en correspondance si ses premiers champs numériques correspondent à la chaîne donnée. Par exemple, le motif «131.155». correspond à l'adresse de (presque) chaque hôte du réseau de l'Université d'Eindhoven (131.155.x.x).
Une chaîne qui commence par un caractère «@» est traitée comme un nom de groupe de réseau NIS (anciennement YP). Un nom d'hôte est associé s'il s'agit d'un membre hôte du groupe réseau spécifié. Les correspondances de groupe réseau ne sont pas prises en charge pour les noms de processus de démon ni pour les noms d'utilisateur client.
Une expression de la forme «n.n.n.n / m.m.m.m.m» est interprétée comme une paire «net / mask». Une adresse d'hôte IPv4 est mise en correspondance si «net» est égal au bit AND de l'adresse et du «masque». Par exemple, le modèle réseau / masque «131.155.72.0/255.255.254.0» correspond à toutes les adresses de la plage «131.155.72.0» à «131.155.73.255».
Une expression de la forme `n: n: n: n: n: n: n: n / m 'est interprétée comme une paire` net / prefixlen'. Une adresse d'hôte IPv6 est mise en correspondance si les bits `prefixlen 'de` net' sont égaux aux bits `prefixlen 'de l'adresse. Par exemple, le modèle net / prefixlen `3ffe: 505: 2: 1 :: / 64 'correspond à chaque adresse de la plage` 3ffe: 505: 2: 1 ::' à `3ffe: 505: 2: 1: ffff: ffff: ffff: ffff '.
Une chaîne commençant par un caractère "/" est traitée comme un nom de fichier. Un nom d'hôte ou une adresse est associé s'il correspond à un nom d'hôte ou à un modèle d'adresse répertorié dans le fichier nommé. Le format de fichier est zéro ou plusieurs lignes avec zéro ou plusieurs modèles de nom d’hôte ou d’adresse séparés par des espaces. Un modèle de nom de fichier peut être utilisé partout où un nom d'hôte ou un modèle d'adresse peut être utilisé.
Caractères génériques "*" et "?" peut être utilisé pour faire correspondre les noms d’hôte ou les adresses IP. Cette méthode de correspondance ne peut pas être utilisée conjointement avec la correspondance `net / mask ', la correspondance du nom d'hôte commençant par`.' ou la correspondance d'adresse IP se terminant par «.
Wildcards
Le langage de contrôle d'accès prend en charge les caractères génériques explicites, notamment:
'TOUT'
Le caractère générique universel correspond toujours.
'LOCAL'
Correspond à tout hôte dont le nom ne contient pas de caractère point.
'INCONNU'
Correspond à tout utilisateur dont le nom est inconnu et à tout hôte dont le nom est ou adresse sont inconnus. Ce modèle doit être utilisé avec précaution: les noms d'hôte peuvent ne pas être disponibles en raison d'incidents temporaires sur le serveur de noms. Une adresse réseau sera indisponible lorsque le logiciel ne pourra pas déterminer le type de réseau avec lequel il parle.
'CONNU'
Correspond à tout utilisateur dont le nom est connu, et à tout hôte dont le nom est et adresse sont connus.Ce modèle doit être utilisé avec précaution: les noms d'hôte peuvent ne pas être disponibles en raison d'incidents temporaires sur le serveur de noms. Une adresse réseau sera indisponible lorsque le logiciel ne pourra pas déterminer le type de réseau avec lequel il parle.
'PARANOÏAQUE'
Correspond à tout hôte dont le nom ne correspond pas à son adresse. Lorsque tcpd est construit avec -DPARANOID (mode par défaut), il supprime les demandes de ces clients avant même de consulter les tables de contrôle d'accès. Construisez sans -DPARANOID lorsque vous souhaitez davantage de contrôle sur ces requêtes.
'LES OPÉRATEURS'
'SAUF'
L'utilisation prévue est de la forme: `list_1 EXCEPT list_2 '; cette construction correspond à tout ce qui correspond list_1 sauf si cela correspond liste_2 . L'opérateur EXCEPT peut être utilisé dans daemon_lists et dans client_lists. L'opérateur EXCEPT peut être imbriqué: si le langage de contrôle autorisait l'utilisation de parenthèses, `a EXCEPT b EXCEPT c 'serait analysé ainsi:' (a EXCEPT (b EXCEPT c)) '.
Commandes Shell
Si la règle de contrôle d'accès associée en premier contient une commande shell, cette commande est soumise à% de substitutions (voir section suivante). Le résultat est exécuté par un / bin / sh processus enfant avec entrée, sortie et erreur standard connecté à / dev / null . Spécifiez un "&" à la fin de la commande du terminal si vous ne souhaitez pas attendre la fin de celle-ci.
Les commandes de shell ne doivent pas dépendre du paramètre PATH de inetd. Au lieu de cela, ils doivent utiliser des noms de chemin absolus ou commencer par une instruction explicite PATH = any.
le hosts_options (5) document décrit une autre langue qui utilise le champ de commande shell d’une manière différente et incompatible.
% D'expansions
Les extensions suivantes sont disponibles dans les commandes du shell:
% a (% A) - L'adresse de l'hôte client (serveur).
% c - Informations client: utilisateur @ hôte, utilisateur @ adresse, un nom d'hôte ou simplement une adresse, en fonction du nombre d'informations disponibles.
%ré - Le nom du processus démon (valeur argv 0).
% h (% H) - Le nom d'hôte ou l'adresse du client (serveur), si le nom d'hôte n'est pas disponible.
% n (% N) - Le nom d'hôte du client (serveur) (ou "inconnu" ou "paranoïaque").
% p - L'identifiant du processus démon.
% s - Informations sur le serveur: démon @ hôte, démon @ adresse ou simplement un nom de démon, en fonction du nombre d'informations disponibles.
% u - Le nom d'utilisateur du client (ou "inconnu").
%% - S'agrandit à un seul caractère «%».
Les caractères dans les extensions% qui peuvent confondre le shell sont remplacés par des traits de soulignement.
Modèles de points finaux de serveur
Afin de distinguer les clients en fonction de l'adresse réseau à laquelle ils se connectent, utilisez des modèles du formulaire:
nom_processus @ host_pattern: liste_client …
Des modèles comme ceux-ci peuvent être utilisés lorsque la machine a différentes adresses Internet avec différents noms d'hôte Internet. Les fournisseurs de services peuvent utiliser cette fonctionnalité pour proposer des archives FTP, GOPHER ou WWW avec des noms Internet pouvant même appartenir à différentes organisations. Voir aussi l'option `twist 'dans le document hosts_options (5). Certains systèmes (Solaris, FreeBSD) peuvent avoir plusieurs adresses Internet sur une interface physique. avec d'autres systèmes, vous devrez peut-être recourir à des pseudo-interfaces SLIP ou PPP qui résident dans un espace d'adressage réseau dédié.
Host_pattern obéit aux mêmes règles de syntaxe que les noms d'hôtes et les adresses dans le contexte client_list. En règle générale, les informations sur les points de terminaison du serveur ne sont disponibles qu'avec les services orientés connexion.
Recherche du nom d'utilisateur du client
Lorsque l'hôte client prend en charge le protocole RFC 931 ou l'un de ses descendants (TAP, IDENT, RFC 1413), les programmes d'encapsulation peuvent extraire des informations supplémentaires sur le propriétaire d'une connexion. Les informations sur le nom d'utilisateur du client, lorsqu'elles sont disponibles, sont consignées avec le nom d'hôte du client et peuvent être utilisées pour faire correspondre des modèles tels que:
daemon_list: … user_pattern @ host_pattern …
Les wrappers de démon peuvent être configurés au moment de la compilation pour effectuer des recherches de nom d'utilisateur basées sur des règles (par défaut) ou pour toujours interroger l'hôte client. Dans le cas de recherches de nom d’utilisateur pilotées par des règles, la règle ci-dessus ne provoque la recherche de nom d’utilisateur que lorsque liste_demon et le host_pattern rencontre.
Un modèle utilisateur a la même syntaxe qu'un modèle de processus démon, les mêmes caractères génériques s'appliquent donc (l'appartenance à un groupe réseau n'est pas prise en charge). Il ne faut cependant pas s'emballer avec des recherches de nom d'utilisateur.
Les informations de nom d’utilisateur du client ne peuvent pas être approuvées lorsque cela est le plus nécessaire, c’est-à-dire lorsque le système client a été compromis. En général, ALL et (UN) KNOWN sont les seuls modèles de nom d'utilisateur qui ont du sens.
Les recherches de nom d'utilisateur ne sont possibles qu'avec les services basés sur TCP et uniquement lorsque l'hôte client exécute un démon approprié; dans tous les autres cas, le résultat est "inconnu".
Un bogue de noyau UNIX bien connu peut entraîner une perte de service lorsque les recherches de noms d'utilisateur sont bloquées par un pare-feu. Le document README sur le wrapper décrit une procédure permettant de déterminer si votre noyau a ce bogue.
Les recherches de nom d'utilisateur peuvent entraîner des retards notables pour les utilisateurs non-UNIX. Le délai d'attente par défaut pour les recherches de nom d'utilisateur est de 10 secondes: trop court pour faire face à des réseaux lents, mais suffisamment long pour irriter les utilisateurs de PC.
Des recherches sélectives sur les noms d'utilisateur peuvent atténuer le dernier problème. Par exemple, une règle comme:daemon_list: @pcnetgroup ALL @ ALL
correspondrait aux membres du groupe réseau pc sans effectuer de recherches de nom d'utilisateur, mais effectuerait des recherches de nom d'utilisateur avec tous les autres systèmes. Une faille dans le générateur de numéros de séquence de nombreuses implémentations TCP / IP permet aux intrus d'emprunter facilement l'identité d'hôtes sécurisés et de s'y introduire via, par exemple, le service shell distant.Le service IDENT (RFC931, etc.) peut être utilisé pour détecter ce type d'attaques d'usurpation d'adresse hôte et d'autres. Avant d'accepter une demande client, les wrappers peuvent utiliser le service IDENT pour savoir que le client n'a pas du tout envoyé la demande. Lorsque l'hôte client fournit le service IDENT, un résultat de recherche IDENT négatif (le client correspond à «UNKNOWN @ host») constitue une preuve solide d'attaque d'usurpation d'hôte. Un résultat de recherche IDENT positif (le client correspond à «KNOWN @ host») est moins fiable. Il est possible pour un intrus d'usurper à la fois la connexion client et la recherche IDENT, bien que cela soit beaucoup plus difficile que d'usurper une simple connexion client. Il se peut également que le serveur IDENT du client soit en train de mentir. Remarque: les recherches IDENT ne fonctionnent pas avec les services UDP. Le langage est suffisamment souple pour que différents types de politique de contrôle d'accès puissent être exprimés avec un minimum de tracas. Bien que le langage utilise deux tables de contrôle d'accès, les stratégies les plus courantes peuvent être implémentées, l'une des tables étant triviale, voire vide. Lors de la lecture des exemples ci-dessous, il est important de réaliser que la table allow est analysée avant la table deny, que la recherche se termine lorsqu'une correspondance est trouvée et que l'accès est accordé lorsqu'aucune correspondance n'est trouvée. Les exemples utilisent des noms d'hôte et de domaine. Ils peuvent être améliorés en incluant des informations d'adresse et / ou de réseau / masque de réseau afin de réduire l'impact des échecs de recherche temporaire du serveur de noms. Dans ce cas, l'accès est refusé par défaut. Seuls les hôtes explicitement autorisés ont un accès autorisé. La politique par défaut (pas d'accès) est implémentée avec un fichier de refus trivial: /etc/hosts.deny: ALL: ALL Cela refuse tout service à tous les hôtes, à moins qu'ils ne soient autorisés à y accéder par des entrées du fichier d'autorisation. Les hôtes explicitement autorisés sont répertoriés dans le fichier d'autorisation. Par exemple: /etc/hosts.allow: ALL: LOCAL @some_netgroupALL: .foobar.edu SAUF terminauxerver.foobar.edu La première règle autorise l’accès des hôtes du domaine local (pas de «.» Dans le nom d’hôte) et des membres du some_netgroup netgroup. La deuxième règle autorise l’accès de tous les hôtes du foobar.edu domaine (notez le point principal), à l'exception de terminauxerver.foobar.edu . Ici, l'accès est accordé par défaut. seuls les hôtes explicitement spécifiés se voient refuser le service. La stratégie par défaut (accès accordé) rend le fichier d'autorisation redondant afin qu'il puisse être omis. Les hôtes explicitement non autorisés sont répertoriés dans le fichier de refus. Par exemple: /etc/hosts.deny: ALL: un.nom.hôte,. un.domaineTOUS SAUF in.fingerd: other.host.name, .other.domain La première règle refuse à certains hôtes et domaines tous les services; la deuxième règle autorise toujours les demandes de doigt d'autres hôtes et domaines. L'exemple suivant autorise les requêtes TFTP émanant d'hôtes situés dans le domaine local (remarquez le point principal). Les demandes de tout autre hôte sont refusées. Au lieu du fichier demandé, une analyse de doigt est envoyée à l'hôte en cause. Le résultat est envoyé au superutilisateur. /etc/hosts.allow: in.tftpd: LOCAL, .my.domain/etc/hosts.deny:in.tftpd: ALL: spawn (/ some / where / safe_finger -l @% h | / usr / ucb / mail -s% d-% h root) &
La commande safe_finger est fournie avec l’enveloppe tcpd et doit être installée à un endroit approprié. Il limite les dommages éventuels causés par les données envoyées par le serveur finger distant. Il offre une meilleure protection que la commande finger standard. Le développement des séquences% h (hôte client) et% d (nom du service) est décrit dans la section consacrée aux commandes shell. Attention: Ne piégez pas le démon de votre doigt, sauf si vous êtes prêt pour une boucle infinie. Sur les systèmes de pare-feu de réseau, cette astuce peut être poussée encore plus loin. Le pare-feu réseau typique ne fournit qu’un nombre limité de services au monde extérieur. Tous les autres services peuvent être "bogués" comme dans l'exemple de TFTP ci-dessus. Le résultat est un excellent système d'alerte précoce. tcpd (8) programme d'encapsulation de démon tcp / ip.tcpdchk (8), tcpdmatch (8), programmes de test.
Important: Utilisez le homme commande ( % homme ) pour voir comment une commande est utilisée sur votre ordinateur. Détection d'attaques d'usurpation d'adresse
Exemples
Principalement fermé
Principalement ouvert
Pièges
Voir également
