2011 Hakim Benameurlaine 1

Table des matières 1 SÉCURITÉ DU RÉSEAU TCP/IP... 2 1.1 But de TCP Wrappers... 2 1.1.1 Avantages de TCP wrappers... 2 1.2 Listes de contrôle d'accès basé sur l'hôte... 2 1.2.1 Ecriture des règles... 3 1.3 Contrôle d'accès à l'aide de xinetd... 5 1.3.1 Fichiers de configuration de xinetd... 5 1.3.2 Contrôle d'accès dans xinetd... 7 1.3.3 Liaison et réacheminement de port... 9 2011 Hakim Benameurlaine 1

1 SÉCURITÉ DU RÉSEAU TCP/IP Le contrôle d'accès aux réseaux peut se révéler une opération complexe. Les pare-feu servent à contrôler les accès depuis et vers un réseau donné, mais leur configuration est parfois difficile. TCP Wrappers et xinetd contrôlent les accès à l'aide du nom d'hôte et de l'adresse IP. De plus, ces outils comprennent des fonctions de journalisation et de gestion simple à configurer. 1.1 But de TCP Wrappers Un nombre important de services réseau (ssh, telnet et ftp par exemple) utilise TCP wrappers qui vient s'interfacer entre les demandes d'accès à un service et le service même. Le concept à la base de TCP wrappers est de "regrouper" des demandes d'accès du client aux applications serveur à l'aide d'un service de vérification. 1.1.1 Avantages de TCP wrappers Lorsqu'un utilisateur cherche à se connecter à un serveur où est installé TCP wrappers, le "wrapper" établit un rapport détaillant le nom du service demandé et les informations concernant l'hôte client. Une fois les conditions de contrôle d'accès satisfaites, il est déchargé et libère toutes les ressources qui lui sont associées. Les avantages de TCP Wrappers par rapport aux méthodes traditionnelles de contrôle sont doubles : Le client qui se connecte n'est pas au courant de sa présence. Les utilisateurs habilités ne perçoivent aucune différence et les malintentionnés ne reçoivent aucune information quant au pourquoi du refus d'accès. TCP Wrappers est indépendant des applications en cours qu'il a pour but de protéger. 1.2 Listes de contrôle d'accès basé sur l'hôte Les accès aux services basés sur le nom d'hôte qui utilisent TCP Wrappers dépendent de deux fichiers : hosts.allow et hosts.deny. Ces fichiers, situés dans le répertoire /etc, font appel à une méthode simple de contrôle de l'accès de certains systèmes ou usagers aux services d'un serveur. La règle par défaut consiste à autoriser tous les accès aux services si aucune règle n'est spécifiée dans les fichiers hosts.allow ou hosts.deny. Cependant, les règles contenues dans hosts.allow ont la priorité par rapport à celles qui se trouvent dans hosts.deny. Même si une règle interdit tout accès à un service donné dans le fichier hosts.deny, les hôtes autorisés à y accéder selon le fichier hosts.allow seront autorisés à se connecter au service en question. Les règles définies dans ces deux 2011 Hakim Benameurlaine 2

fichiers sont prises en compte dans l'ordre à partir du sommet, ce qui implique une certaine rigueur dans leur écriture. 1.2.1 Ecriture des règles Toutes les règles de contrôle d'accès sont définies 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 ont le format suivant : <liste_démons>: <liste_clients>[: spawn <commande_shell> ] Chacune de ces options fait référence à une portion différente de la règle : liste_demons 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. Si votre liste de noms d'hôte pouvant accéder à un service est trop longue ou difficile à contrôler à l'intérieur de hosts.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. 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 où l'utilisateur est connu. UNKNOWN Correspond à tous les hôtes dont le nom d'hôte, l'adresse hôte où l'utilisateur est inconnu. PARANOID Correspond à tout hôte dont le nom ne correspond pas à l'adresse. 2011 Hakim Benameurlaine 3

Lorsque EXCEPT est utilisé entre deux listes, la première s'applique sauf s'il y a correspondance avec un paramètre de la seconde liste. EXCEPT peut être employé avec des listes de démons ou 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. 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 compris entre 10.0.1.0 et 10.0.1.255, tente de se connecter via telnet : in.telnetd: 10.0.1.: spawn (/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'informations 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 n'est pas disponible). %H Nom d'hôte du serveur (ou son adresse IP si le nom 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'informations sur le serveur, tels que processus démon, adresse d'hôte ou adresse IP du serveur. 2011 Hakim Benameurlaine 4

%u Nom d'utilisateur du client. Si aucune information n'est disponible, le mot unknown est affiché. 1.3 Contrôle d'accès à l'aide de xinetd Les avantages de l'utilisation de TCP wrappers se multiplient lorsqu il agit de concert avec xinetd, un démon qui offre des outils supplémentaires d'accès, de journalisation, de liaison, de réacheminement et d'utilisation des ressources. Linux configure de nombreux services réseaux très répandus à utiliser xinetd, tels que ftp, telnet. Le démon xinetd gère les demandes d'accès à ces services depuis /etc/services, lorsque l'on y accède via leur numéro de port. Avant de rendre disponible le service demandé à l'utilisateur, xinetd s'assure de la conformité des informations d'hôte du client relatives aux règles d'accès ; le nombre d'instances pour ce service est maintenu sous un seuil particulier et chaque autre règle inhérente à ce service ou tout autre service xinetd est suivie. Une fois que le service demandé est autorisé au client, xinetd retourne en veille, attendant la prochaine demande. 1.3.1 Fichiers de configuration de xinetd Le service xinetd est contrôlé par le fichier /etc/xinetd.conf ainsi que les différents fichiers spécifiques à des services situés dans le répertoire /etc/xinetd.d. /etc/xinetd.conf Le fichier xinetd.conf est le parent de tous les fichiers de configuration de services contrôlés par xinetd, étant donné que chaque fichier spécifique à un service se voit analyser à chaque lancement de xinetd. Par défaut, xinetd.conf contient des paramètres de configuration de base qui s'appliquent à tous les services : defaults { } instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 includedir /etc/xinetd.d Ces lignes contrôlent les différentes modalités d'application de xinetd : instances Définit le nombre maximum de demandes d'accès qu'un 2011 Hakim Benameurlaine 5

log_type log_on_success log_on_failure service peut traiter à la fois. Invite xinetd à utiliser le journal authpriv, spécifié dans /etc/syslog.conf et configuré par défaut sur /var/log/secure. Si on utilisait FILE /var/log/xinetdlog à la place, xinetd effectuerait la journalisation dans un fichier séparé /var/log/xinetdlog. Définit ce que xinetd doit journaliser lorsque la connexion est établie avec succès. L'adresse IP de l'hôte distant et l'identifiant de processus du serveur traitant la demande d'accès sont enregistrés par défaut. Définit ce que xinetd doit journaliser lorsque la connexion n'est pas établie ou est refusée. Les paramètres log_on_success et log_on_failure du fichier /etc/xinetd.conf sont souvent rajoutés par chacun des différents services, ce qui signifie que les connexions réussies et refusées à chacun des services journalisent généralement plus d'informations que ce qui est indiqué ici. /etc/xinetd.conf et les fichiers de configuration xinetd spécifiques à des services offrent de multiples options de journalisation : ATTEMPT DURATION EXIT HOST PID RECORD USERID Journalise une connexion manquée (log_on_failure). Journalise la durée d'utilisation d'un service par un système distant. Journalise l'état ou le signal de fin du service (log_on_success). Journalise l'adresse IP de l'hôte distant. Journalise l'identifiant de processus du serveur qui reçoit la demande Journalise les informations relatives au système distant dans le cas où le service n'aurait pu être lancé. Seuls des services spéciaux, tels que login et finger, peuvent utiliser cette option (log_on_failure). Journalise les données concernant l'utilisateur distant selon les directives définies dans RFC 1413 pour tous les services de type multi-thread (log_on_failure et log_on_success). D'autres options sont disponibles pour /etc/xinetd.conf, telles que per_source, qui limite le nombre maximum de connexions depuis une adresse IP donnée à un service spécifique. Fichiers du répertoire /etc/xinetd.d Les différents fichiers qui se trouvent dans le répertoire /etc/xinetd.d sont lus à chaque démarrage de xinetd, grâce à l'instruction includedir /etc/xinetd.d insérée à la fin de /etc/xinetd.conf. Ces fichiers, 2011 Hakim Benameurlaine 6

appelés notamment finger, pop3 et rlogin, se réfèrent aux différents services contrôlés par xinetd. Les fichiers présents dans /etc/xinetd.d utilisent les mêmes règles et options que celles employées dans /etc/xinetd.conf. La raison première de leur séparation dans des fichiers de configuration, un pour chaque service, est de simplifier l'ajout ou la suppression de services du domaine de xinetd sans affecter ses autres services. Pour se familiariser avec la structure de ces fichiers, prenons l'exemple du fichier wu-ftp : service ftp { socket_type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l -a log_on_success += DURATION USERID log_on_failure += USERID nice = 10 disable = yes } La première ligne définit le nom du service en cours de configuration. Ensuite, les lignes entre accolades renferment des paramètres de démarrage et d'utilisation de ce service. Le fichier wu-ftp indique que le service FTP utilise un type de socket stream, le type de fichier binaire exécutable à utiliser, les arguments à passer au binaire, l'information à journaliser en plus des paramètres de réglage de /etc/xinetd.conf, l'ordre de priorité d'exécution du service, etc. L'utilisation de xinetd avec un certain service peut aussi servir comme degré de protection de base contre les attaques du type refus de service (DoS). L'option max_load utilise une valeur de point flottant pour déterminer le seuil d'utilisation du processeur limitant ainsi le nombre de connexions possibles pour un service spécifique et évitant toute surcharge du système. L'option cps permet d'utiliser une valeur entière pour définir de façon numérique le nombre maximum de connexions disponibles par seconde. En imposant une valeur basse, 3 par exemple, on empêche toute attaque inondant le système de demandes d'accès simultanées à un service donné. 1.3.2 Contrôle d'accès dans xinetd 2011 Hakim Benameurlaine 7

Les utilisateurs de xinetd ont le choix entre le recours aux fichiers de contrôle d'accès aux hôtes TCP wrappers (hosts.allow et hosts.deny), l'autorisation d'accès par le biais de fichiers de configuration xinetd ou un mélange des deux. Le contrôle d'accès aux hôtes xinetd, disponible par le biais de ses multiples fichiers de configuration, est différent de celui employé par TCP wrappers. Alors que TCP wrappers regroupe toutes les configurations d'accès dans deux fichiers, /etc/hosts.allow et /etc/hosts.deny, chaque fichier de service contenu dans /etc/xinetd.d peut contenir des règles d'accès basées sur les hôtes qui seront autorisés à utiliser ce service. Les options suivantes sont acceptées dans les fichiers xinetd pour contrôler l'accès des hôtes : only_from no_access access_times Autorise les hôtes spécifiés à accéder au service. Empêche les hôtes spécifiés de se servir du service. Définit les heures de disponibilité du service. Cette plage horaire doit être spécifiée comme suit : HH:MM-HH:MM, en utilisant la forme 24 heures. Les options only_from et no_access peuvent utiliser une liste préétablie d'adresses IP ou de noms d'hôte ou encore un réseau entier. Tout comme avec TCP wrappers, il est possible de mettre en commun les contrôles d'accès xinetd avec les configurations de journalisation dans le but non seulement d'empêcher les connexions, mais aussi d'enregistrer toute tentative d'accès aux services. Par exemple, le fichier /etc/xinetd.d/telnet suivant peut être utilisé pour interdire l'accès via telnet à un groupe précis d'utilisateurs et limiter la plage horaire disponible aux utilisateurs autorisés : service telnet { disable flags socket_type wait user } = no = REUSE = stream = no = root = /usr/sbin/in.telnetd server log_on_failure += USERID no_access = 10.0.1.0/24 log_on_success += PID HOST EXIT access_times = 09:45-16:15 2011 Hakim Benameurlaine 8

Dans cet exemple, lorsqu'un ordinateur du sous-réseau 10.0.1.0/24, tel que 10.0.1.2, cherche à établir une connexion telnet avec l'hôte boo, le message Connection closed by foreign host lui est envoyé. De plus, cette tentative d'accès est journalisée dans le fichier /var/log/secure : May 15 17:35:47 boo xinetd[16188]: START: telnet pid=16191 from=10.0.1.2 May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2 May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2 May 15 17:38:49 booxinetd [16252]: EXIT: telnet status=0 pid=16256 1.3.3 Liaison et réacheminement de port Les fichiers de configuration de service xinetd prennent également en charge les liaisons de services vers une adresse IP spécifique et le réacheminement des demandes d'accès au service vers une autre adresse IP, un autre nom d'hôte ou un autre port. Les liaisons, telles que définies par l'option bind dans les fichiers de configuration de service, relient explicitement les services vers une autre adresse IP utilisée par le système, autorisant ainsi l'accès au service uniquement lorsqu'il arrive par cette adresse IP. Ceci se révèle tout particulièrement utile lorsque la configuration du système comprend plusieurs cartes réseau et utilise des adresses IP multiples, tels que sur des ordinateurs employés comme pare-feu, avec une carte en contact avec Internet et l'autre reliée au réseau local. Aussi est-il possible d'empêcher des pirates essayant de se connecter à un service donné, tel que telnet ou ftp, via Internet de se connecter au service alors que les utilisateurs internes peuvent se connecter au service via le NIC branché au réseau local. L'option redirect, qui accepte une adresse IP ou un nom d'hôte suivi d'un numéro de port, indique au service de réacheminer toute demande pour ce service vers l'emplacement spécifié. Cette fonction peut être utilisée pour : pointer vers un autre numéro de port sur le même système réacheminer la demande vers une adresse IP différente sur le même ordinateur passer la demande à un système et un numéro de port totalement différents ou mélanger ces diverses possibilités. De cette façon, il est possible de dérouter la connexion d'un utilisateur à un service donné d'un système sur un autre système sans aucune perturbation. 2011 Hakim Benameurlaine 9

Le démon xinetd est en mesure d'effectuer cette redirection en générant un processus qui demeure actif pendant toute la durée de la connexion entre l'ordinateur client effectuant la demande et l'hôte qui fournit le service, transférant les données entre les deux systèmes. Tout l'intérêt des options bind et redirect se concrétise lorsqu'elles sont utilisées simultanément. En reliant un service à une adresse IP spécifique sur un ordinateur donné et en redirigeant les demandes d'accès à ce service vers un autre ordinateur reconnu uniquement par le premier, vous pouvez utiliser un système interne pour offrir des services à un réseau complètement différent. Prenons par exemple un système utilisé comme pare-feu avec les réglages suivants pour son service ftp : service ftp { socket_type wait server log_on_success } = stream = no = /usr/sbin/in.telnetd += DURATION USERID += USERID log_on_failure bind = 123.123.123.123 redirect = 10.0.1.13 21 23 Les options bind et redirect de ce fichier s'assurent que: le service ftp sur cet ordinateur est lié à l'adresse IP externe (123.123.123.123), celle qui est en contact direct avec le monde Internet. En outre, toute demande d'accès ftp envoyée à l'adresse 123.123.123.123 est réacheminée à l'aide d'une deuxième carte interface de réseau vers une adresse IP interne (10.0.1.13), accessible uniquement par le pare-feu et les systèmes internes. Ce même pare-feu établit ensuite les communications entre les deux systèmes et le système qui se connecte pensera s'être connecté à l'adresse 123.123.123.123 alors qu'il est en fait connecté à un tout autre ordinateur. 2011 Hakim Benameurlaine 10