Re: [FI] Dans un livre

["Philippe Verdy" <verdy_p@wanadoo.fr>]

En effet, finger permet de connaitre la liste des "utilisateurs" "connectés" à un système. En fait, il faut savoir ce qu'on appelle "connecté" et "utilisateur".
Ici le terme "connecté" correspond à l'établissement d'une session authentifiée qui permet d'utiliser les fonctions du système, avec plus ou moins d'habilitations. Pour se faire, le système demande habituellement un login et un mot de passe, qui correspondent à un utilisateur préalablement enregistré dans la liste des utilisateurs habilités à se servir du système, et enregistrée sous Unix dans le fameux fichier "/etc/passwd".

Ce fichier, lisible par tous les utilisateurs connecté (mais protégé contre toutes les écritures), porte mal son nom car maintenant sur la plupart des systèmes Unix, le mot de passe crypté n'est plus stocké dans ce fichier, pour des raisons de sécurité, car tout le monde pouvait accéder au mot de passe crypté. Ce n'était pas suffisant pour obtenir le mot de passe en clair, mais des programmes de décryptage pouvaient être utilisés en dehors du système lui-même, pour faire une attaque en force et obtenir la liste des mots de passe en clair de tous les utilisateurs.

Aussi le champ mot de passe est maintenant simplement remplacé par un simple "x", et le mot de passe crypté est désormais situé dans un fichier séparé (/etc/opasswd, ou fichier shadow suivant les systèmes), stocké dans un répertoire protégé appartenant exclusivement à "root", et qui n'est lisible ou modifiable QUE par l'utilisateur "root".

Pour que ce système marche, il faut néanmoins protéger le fichier "/etc/passwd". Celui-ci devant rester en lecture publique pour peremettre les connexions (de même que le répertoire /etc qui doit en plus être exécutable pour pouvoir être parcouru), faute de quoi les propriétaires de fichiers ne pourront pas être identifiés autrement que par leur seul UID numérique, et aucune information ne sera rendue à l'utilisateur concernant par exemple le "home directory" d'un utilisateur qui se connecte, ou son nom en clair (le libellé à contenu libre situé après le mot de passe dans /etc/passwd).

Certains systèmes malgré tout arrivent à garder ce fichier "/etc/passwd" privé, en utilisant la technique du "chroot", qui permet à un utilisateur non privilégié (donc hormis root ou bin) de ne voir sur le système qu'une partie de ses fichiers (son répertoire "/" sera en fait un sous-répertoire du système une fois connecté). Donc avec "chroot", utilisé dans le script système qui gère les connexions, on peut restreindre un utilisateur à une toute petite partie des fonctions du système, les fichiers dont il a besoin par exemple "/bin/ls" étant soit copiés dans son répertoire "/bin" (en fait "/home/<utilisateur>/bin), soit liés physiquement au fichier original (un lien symbolique ne peut pas marcher, car la destination du lien ne pourrait pas être résolu par l'utilisateur après le "chroot"). Ainsi l'utilisateur connecté peut avoir accès librement à son propre répertoire "/", qui contient déjà un sous-répertoire "bin" contenant les fichiers dont il a besoin pour pouvoir faire ce à quoi il est habilité (par exemple "/bin/sh", "/bin/ls", "/bin/cat", "/bin/more", ... commandes non dangereuses), plus un répertoire "/dev" devant contenir la liste des périphériques qont il a besoin et qui ne sont pas dangereux pour le système (par exemple au minimum "/dev/null", "/dev/tty", mais on peut exclure les imprimantes du système comme "/dev/lp" ou les lecteurs de bandes ou de disquettes). La liste minimale des périphériques nécessaires pour chaque utilisateur est propre à chaque système (consulter le man de chroot).

Si un utilisateur n'a pas de compte sur le système pour se connecter, celui-ci peut être autorisé à se connecter de façon très restreinte sous un pseudonyme commun à tous, généralement configuré avec un "chroot". C'est le cas de l'utilisateur "anonymous" utilisé pour les connexions FTP. Il est autorisé à rentrer sans mot de passe réel (le serveur FTP permet parfois de remplacer la saisie du mot de passe non nécessaire par l'indication d'une adresse de courriel, qu'il garde en log ou pour des autorisations spécifiques). Une fois connecté sous FTP, l'utilisateur est vu par le système en tant que "anonymous". Il peut lancer une commande "/bin/ls" par exemple au travers de la commande FTP utilisateur "DIR".

Maintenant que fait "finger". En fait il recense uniquement les utilisateurs ayant obtenu un accès au système par un "login", en fournissant un code utilisateur et un mot de passe. Une fois connecté, le système lui a assigné un terminal (associé spécifiquement pour cette session à /dev/tty, mais qui correspond réellement à un périphérique /dev/ttyN si la connexion se fait par un port série local du système, ou /dev/console si l'utilisateur s'est connecté par la console système, ou à un des pseudo-terminaux /dev/ptyN gérés par le démon réseau permettant cette connexion).

Donc en fait, "finger" ne recensera pas les connexions HTTP, car la session créée ne se fait qu'au travers d'une seule application, le serveur Web lui-même, qui n'a pas besoin de créer de session utilisateur sur le système pour répondre aux requêtes des clients. Certains serveurs FTP plus modernes et plus sécurisés font de même: il n'y a jamais de création de session, et un client qui lance un "DIR" et transmet "/bin/ls" n'exécute jamais directement la commande "/bin/ls", qui est prise en charge et émulée au sein du serveur FTP lui-même (cela évite d'avoir à gérer les couteuses configurations "chroot" et économise énormément de ressources sur le système, tout en fermant pas mal de trous possibles de sécurité).

Comment "finger" permet-il d'interroger les utilisateurs connectés à un système: il se connecte par TCP/IP sur le serveur indiqué, en indiquant un numéro de port réservé au service "fingerd" tournant sur ce système. De l'autre coté, il faut que le serveur interrogé dispose d'un service "fingerd" qui comprenne le protocole d'échange utilisé par "finger". Si un administrateur système n'a pas activé le service "fingerd" (soit dans /etc/inetd.conf, soit en le lançant en tant que démon), cela ne passera pas, et le client recevra une erreur de non connexion.

Mais ce n'est pas suffisant: on a deux possibilités pour faire tourner un service réseau sous Unix:

1) soit en le faisant tourner de façon permanente à vide, pour intercepter les connexions qui viendraient éventuellement plus tard. Le problème c'est que cela prend de façon permanente des ressources sur le système, même si le service n'est pas utilisé. Parfois le service peut être démarré en tant que processus dans un script de démarrage (voir /etc/rc* ou /etc/inittab suivant les systèmes), ou alors il peut être démarré au sein d'un autre service ou d'un pilote de périphérique situé au sein du noyau (par exemple les services ARP et ICMP qui sont généralement démarrés au sein des pilotes TCP/IP). Cela a l'avantage que le service peut répondre immédiatement aux requêtes, car aucune autre ressource n'est nécessaire. C'est généralement le cas des services destinés à servir beaucoup de connexions clientes tels que "telnetd", "ftd", "httpd", et "inetd".

2) soit en le faisant tourner à la demande, au sein de "inetd", grace à la configuration du fichier "inetd.conf". Le problème de cette configuration est que si le service est trop sollicité, inetd va créer énormément de processus pour gérer chacune des requêtes, ce qui peut entâcher gravement les performances du système en cas d'attaque massive de type "DoS" (déni de servie). Il y a bien un moyen d'éviter de planter complètement un système: cela consiste à limiter le nombre de processus que "inetd" peut créer. Au delà, inetd peut suspendre temporairement la réponse, en attendant que la ressource soit libérée, ou la rejeter immédiatement (cela libère rapidement des ressources de sessions TCP utilisées par les connexions en attente, le nombre de sockets TCP étant aussi une ressource précieuse pour le système entier, car si le système ne dispose plus de sockets libres, il ne pourra plus en allouer d'autres pour répondre aux autres services tournant sur le système). Généralement chaque service tournant sous Unix alloue un nombre maximal prédéfini de services qu'il est autorisé à mettre en attente. C'est le cas de inetd, qui crée une file d'attente, pour chaque ligne définie dans inetd.conf.

Donc la disponibilité des ressources nécessaires pour accéder à un service est une chose importante. Si des services sont vitaux au fonctionnement du système, mieux vaut éviter que ceux-ci soient soumis aux attaques de type "DoS". Cela consiste souvent à fermer l'accès à tous les services non nécessaires, au sein du firewall, qui peut donc être configuré pour ne pas laisser entrer sus le système les connexions autres que HTTP voire FTP. Dans ce cas, le client situé en amont ne pourra pas interroger le système avec "finger", car le port "fingerd" du serveur sera inaccessible.

Donc pas d'affolement avec "finger" !

Sachez que les attaques de type "DoS" sont plus difficiles sur un serveur "HTTP", car les sessions TCP créées sont relativement courtes (cela dépend des performances du serveur Web), et la socket utilisée est rapidement fermée dès que la réponse a été transmise. Néanmoins l'attaque est possible, en évitant que la socket soit fermée par le serveur, par exemple en tardant du côté du client à intercepter la réponse (dans ce cas la socket reste ouverte sur le serveur). La parade consiste à limiter strictement au sein de la configuration TCP du serveur Web le temps nécessaire à la récupération des réponses par les clients (au delà le serveur Web doit pouvoir fermer autoritairement la socket, même si les données n'ont pas toutes été récupérées par le client).

L'ennui, est que le serveur Web doit pouvoir rester accessible aux clients les plus lents qui se connectent par modem: aussi une page Web volumineuse ou de grosses images peuvent ralentir cette récupération, et le client peut très bien mettre plus de trente secondes à charger l'image. La parade en ce domaine est l'insertion de serveurs proxy HTTP transparents entre le serveur et le client, généralement au sein du fournisseur d'accès: c'est le serveur proxy qui charge rapidement la réponse (libérant rapidment le serveur) et qui maintient les données qui sont chargées par les clients les plus lents. Aussi, un "time out" voisin de 30 à 60 secondes peut être utilisé sur le serveur HTTPd. L'idéal serait de pouvoir réduire ce temps, mais les fournisseurs d'accès n'ont pas tous des serveurs proxy HTTPd très performant. D'autre part, tous les clients qui se connectent par modem ne transitent pas forcément par un serveur proxy HTTP (transparent ou non).

Dans ce domaine, on peut protéger un serveur important :
- en utilisant plusieurs serveurs distribués dans divers points du monde, et accédés aléatoirement par une configuration spéciale du serveur DNS. Néanmoins cela reste inefficace en cas d'attaque distribuée au niveau mondial.
- en utilisant plusieurs serveurs ayant des capacités de réponse différentes en fonction de la route suivie. Cela permet de segmenter le "marché" des clients, en évitant qu'une catégorie précise de clients monopolise toutes les ressources du serveur. C'est efficace pour protéger l'accès au serveur par un Intranet d'entreprise, en acceptant que les accès par l'Internet soient bloqués. Mais c'est inacceptable pour un serveur Web de commerce, destiné essentiellement à servir les clients Internet, qui eux restent sensibles aux attaques de type "DoS"
- en passant des accords de distribution avec les plus grands fournisseurs d'accès, de façon à ce que ceux-ci fournissent la plateforme technique nécessaire au bloquage des attaques de type "DoS": il suffit que le fournisseur d'accès utilise un serveur proxy transparent, et limite le nombre de connexions simultanées par un même client vers un même serveur. Le proxy assurera la mise en cache local des principales requêtes, et interceptera les réponses pour les pages non cachables, de façon à libérer rapidement les ressources des serveurs.

L'autre problème qui peut subsister est lié aux requêtes HTTP qui précisent l'option "KEEP-ALIVE". Cette option subsiste, mais est fortement déconseillée dans la mise en oeuvre d'un service. En effet, ces requêtes ne sont pas cachables par le serveur proxy. Leur seule utilisation devrait être réservée aux requêtes HTTPS (sécurisées). Si HTTPS n'est pas nécessaire, mieux vaut ne jamais créer un service qui dépend de connexions permanentes et fermer cette possibilité (même si certains browsers "accélérateurs" autorisent cette possibilité, qui permet de télécharger une page Web et toutes ses images sur la même connexion TCP/IP).

En moyenne laisser la possibilité d'utiliser le "Keep-Alive" fait gagner des ressources au serveur, car il n'y a pas d'établissement de sessions multiples pendant le chargement d'une même page. Mais il y a le risque de rendre le serveur plus vulnérable aux attaqwues de type "DoS", car les sessions restent connectées après chaque requête, et une attaque distribuée peut très bien alors monopoliser à elle-seule toutes les sessions TCP autorisées.

La parade ici peut consister à configurer le serveur Web pour qu'il autorise un nombre limité de sessions utilisant le "Keep-Alive", les autres sessions étant fermées de façon autoritaire. Aussi le service ne doit pas dépendre de la possibilité du Keep-Alive, et supposer que toutes les connexions seront non permanentes. L'autre possibilité est d'intégrer au serveur Web un système qui ferme autoritairement les sessions TCP inactives les plus anciennes, de façon à libérer les ressources pour les autres sessions en Keep-Alive. Cette méthode est beaucoup moins contraignante pour les utilisateurs, car ceux-ci ne verront un ralentissement du à la fermeture d'une session Keep-alive que lors d'une charge importante du serveur ayant à répondre à de nombreuses requêtes, et le serveur pourra répondre efficement en temps normal. On peut compléter le dispositif en donnant une priorité plus importante aux connexions qui effectuent leur première requête, et en laissant les autres sessions en attente jusqu'à ce qu'elles soient fermées autoritairement (le Keep-Alive ne devrait jamais être prioritaire, sauf si la session est sécurisée par HTTPS).

En fait le véritable danger des attaques DoS distribuées vient du fait que les serveurs sont librement accessibles par tout le monde et que tout le monde est logé à la même enseigne. Si les serveurs pouvaient être relayés par des services spécialisés et regroupés par des fournisseurs d'accès sérieux implémentant le proxy transparent, et utilisant des connexions sécurisées vers des serveurs proxy transparent des principaux fournisseurs d'accès du monde, on pourrait définitivement balayer ce type d'attaque, car la charge ne serait plus concentrée au sein du seul serveur attaqué, mais localisée au sein des serveurs proxy transparents des fournisseurs d'accès, qui peuvent appliquer des mesures efficaces de protection de leur bande passante.

Hors actuellement les serveurs Web veulent tout gérer eux-mêmes et ne font pas confiance aux serveurs proxy (ou refusent de louer les services avanvés proposés par leurs fournisseur de présence Internet). De même, les fournisseurs d'accès des clients devraient passer des accords de distribution avec les grands fournisseurs de présence des sites, et ne plus relayer directement leurs clients  internautes vers les différents sites.

Le problème est technique en partie, mais surtout financier (il faut acquérir les plateformes techniques et les maintenir, et il faut passer des accords de distribution pour ouvrir des passerelles sécurisées vers des serveurs proxy mis en place par les grands fournisseurs de points de présence). Hors la grande majorité des fournisseurs d'accès (sauf les très grands tels qu'AOL ou Wanadoo) ne dispose pas des financements nécessaires, ni de compétences commerciales suffisantes pour passer de tels accords de distribution. Je crois que cela laisse la place alors à des services spécialisés dans ce genre de négociation de bande passante.

Aussi, à l'avenir, les fournisseurs de points de présence pourront proposer la connectivité efficace avec les principaux fournisseurs d'accès Internet, grace à un routage sécurisé spécifique, le serveurs pouvant alors traiter efficement et sans DoS possible, les requêtes provenant des internautes connectés par des fournisseurs d'accès sérieux ayant passé les accords de distribution. Les autres requêtes pouvant toujours être servies, mais restant sensible aux attaques de type "DoS". Mais si la part des grands forunisseurs d'accès devenait prépondérante, cela rendrait inefficace les attaques "DoS" distribuées, car celles-ci seraient relayées principalement par des fournisseurs d'accès protégés. Donc l'attaque "DoS" sur la partie non protégée tomberait rapidement à l'eau car elle pourrait être facilement localisée et détectée sur le réseau protégé, sans nuire à la qualité de service de ce réseau.

Au pire, si l'attaque subsistait, elle resterait confinée uniquement sur la partie non protégée du réseau, et ne pénaliserait pas la majorité des utilisateurs passant par les fournisseurs d'accès sérieux, et donc par un réseau protégé contre ce type d'attaques.

----- Original Message ----- 
From: "Charles Goyard" <charles.goyard@wanadoo.fr>
To: <debian-french@lists.debian.org>
Sent: Friday, May 19, 2000 9:44 AM
Subject: [FI] Dans un livre


> Salut
> 
> Il ne s'agit pas de remuer le couteau dans la plaie, mais:
> 
> Donc, dans un livre (la sécurité sur l'Internet*, Firewalls (ora), je vois,
> page 279:
> " [...] ainsi que le moment de leur plus récent login et la machine
> d'où ils se sont logés. finger peut également servir à montrer la liste
> des utilisateurs actuellement connectés à un ordinateur."
> 
> C'est une bombe, cette phrase!
> 
> *(perso, je dis Internet et pas l'Internet, bien que je reconnaisse
> la validité grammaticale de l'Internet)
> 
> (si commentaires il y a, les faire en privé, merci.)
> 
> Charles
> 
> 
> --  
> To UNSUBSCRIBE, email to debian-french-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>