💾 Archived View for asteride.xyz › ~selve › articles › finger_openbsd.gmi captured on 2024-02-05 at 09:24:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Publié le 11 février 2023 et modifié le 22 octobre 2023
Le protocole finger est à l'image des premiers temps d'Internet : simplissime et convivial[1]. Publiée en 1977, la RFC 742 est la première à en détailler le fonctionnement. Notre protocole dépasse donc aujourd'hui les 45 ans. Trois autres RFC ont suivi la première, la dernière étant la RFC 1288, publiée en 1991.
finger est une sorte de super carnet d'adresses en ligne. Une simple requête permet de recevoir ce qu'on pourrait appeler la « page d'accueil » du serveur, qui contient souvent la liste des utilisateurs qui y sont connectés. Augmentée d'un nom d'utilisateur, la requête fournit une somme variable d'informations concernant cet utilisateur. Il s'agit traditionnellement de son nom complet, de l'emplacement de son dossier ~/, du programme shell qu'il utilise, de la date et de l'heure de sa dernière connexion, de son numéro de téléphone, de l'état de sa boîte courriel, etc. En outre, les serveurs finger affichent typiquement le contenu des fichiers ~/.project et ~/.plan. Le premier tend à contenir des informations générales sur l'utilisateur, sur ses intérêts, etc. ; le second est souvent plus spécifique et changeant et lui sert à informer les autres de ses plans à court terme, de ce qui l'occupe, de ce qu'il explore ou veut explorer, etc. Mais ce qu'affiche une requête finger dépend en définitive des préférences de l'administrateur et de l'utilisateur.
L'âge d'or de finger semble révolu. Il était une l'époque où très peu d'individus possédaient un ordinateur personnel et où une grande partie de ceux qui avaient à en utiliser un devaient se connecter à un ordinateur central, donc partagé, appartenant à quelque université ou entreprise. Alors, « toutes les machines Unix connectées au réseau avaient un serveur finger », dit-on[2]. Avant l'avènement du Web, c'était un des seuls moyens informatisés répandus et efficaces d'obtenir de l'information sur quelqu'un.
Aujourd'hui, le protocole, sans être totalement tombé en désuétude, est assez marginal ; c'est le moins qu'on puisse dire. Il jouit toutefois d'un regain d'intérêt récent avec la montée de l'Internet simple et indépendant (je suis toujours à la recherche d'un terme français pour « smol web »). Il est apprécié pour sa simplicité et pour son fonctionnement décentralisé. Plusieurs serveurs tildes mettent ainsi à la disposition de leurs membres un serveur finger.
Article de Solderpunk « We're bringin' finger back! » (en anglais)
J'héberge de depuis peu mon propre serveur finger. J'ai été séduit par sa simplicité et par l'espoir de le voir renaître comme moyen d'échange et de socialisation au sein des petites communautés de l'Internet citoyen.
C'est avec OpenBSD et ses outils que j'ai monté ce serveur, et en la matière, je n'ai pas d'expérience avec d'autres systèmes. Je n'aurai donc qu'OpenBSD en tête en écrivant cet article. Je serais cependant surpris d'apprendre que la marche à suivre diffère grandement entre les systèmes de type Unix.
De nombreux systèmes dérivés de Unix sont livrés avec le programme finger(1), qui permet de réaliser des requêtes par ce protocole.
$ finger selve@asteride.xyz
[asteride.xyz/207.148.27.164]
----------------
* ASTERIDE.XYZ *
----------------
Utilisateur: selve Nom: Selve
Dossier: /home/selve Shell: /bin/ksh
Courriel: selve@asteride.xyz
Gemini: gemini://asteride.xyz/~selve/
Langues: FranC'ais, catalan et anglais
DC)connectC) depuis le 2023-02-10 C 03:20:17 (UTC)
[Et cetera]
Le client d'OpenBSD ne gère que l'encodage ASCII. C'est pourquoi le texte n'est pas affiché correctement. Les RFC sur finger à partir de 1194 RECOMMANDENT en effet de filtrer des caractères et de ne laisser passer que les caractères entre 32 et 126, de même que t, r et n. Il est en outre spécifié que le serveur DOIT transmettre des caractères ASCII entre 128 et 255. D'habitude, je respecte les standards de bon cœur, mais quand j'écris en français, j'emploie les caractères en usage dans cette langue. Je ne me passerai ni des accents, ni des cédilles, ni des guillemets, ni, tant qu'à y être, d'autres commodités typographiques comme les ligatures. Je pense que nous pouvons nous permettre d'utiliser l'UTF-8[3].
Heureusement, le protocole est si simple qu'on peut simuler le fonctionnement du programme avec netcat ou telnet, qui ne souffrent pas des mêmes limitations. Il suffit d'ouvrir un connexion avec le serveur approprié au port 79 et d'envoyer une seule ligne de texte. Cette ligne correspond généralement à l'utilisateur au sujet duquel on veut obtenir de l'information.
$ telnet asteride.xyz 79
selve
----------------
* ASTERIDE.XYZ *
----------------
Utilisateur: selve Nom: Selve
Dossier: /home/selve Shell: /bin/ksh
Courriel: selve@asteride.xyz
Gemini: gemini://asteride.xyz/~selve/
Langues: Français, catalan et anglais
Déconnecté depuis le 2023-02-10 à 03:20:17 (UTC)
[Et cetera]
On peut même créer une fonction shell avec netcat pour remplacer le client de base. Elle n'est pas complète, mais elle sait faire l'important.
finger() {
echo $1 | grep @ >/dev/null &&
printf ${1%@*}rn | nc ${1##*@} 79 ||
printf ${1%@*}rn | nc 127.0.0.1 79
}
On peut souvent obtenir la liste des utilisateurs connectés à un système en ne précisant pas de nom d'utilisateur. Bien sûr, l'administrateur est maître de ce qui est envoyé.
$ finger @asteride.xyz
----------------
* ASTERIDE.XYZ *
----------------
Bienvenue sur asteride.xyz.
D'habitude, lorsqu'on interroge un serveur finger sans spécifier de nom
d'utilisateur, il répond par la liste de tous les utilisateurs actifs au
moment de la requête. Mais la liste risque d'être plutôt courte ici,
car asteride.xyz n'en compte qu'il seul : selve (il est actif en ce
moment!).
Il vous invite à exécuter « finger selve@asteride.xyz ».
Cela revient à envoyer une ligne vide.
$ telnet asteride.xyz 79
[ENTRÉE]
----------------
* ASTERIDE.XYZ *
----------------
Bienvenue sur asteride.xyz.
[Et cetera]
asteride.xyz ne compte qu'un seul (vrai) utilisateur. On peut aller voir sur des serveurs tildes comme zaibatsu.circumlunar.space, tilde.club, tilde.institude, etc. pour consulter une liste plus longue.
$ finger @zaibatsu.circumlunar.space $ finger @tilde.club $ finger @tilde.institute $ finger @etc.
Je veux aussi donner un exemple d'utilisation originale du protocole. Techniquement, il ne s'agit que d'envoyer du texte en réponse à une ligne de texte. Un serveur peut alors interpréter cette ligne comme il le veut. graph.no permet ainsi de consulter la météo avec finger.
$ finger québec~72@graph.no
[graph.no/178.255.144.27]
-= Meteogram for Quebec, Canada =-
'C Rain (mm)
-16
-17---
-18 ------
-19 ------ =--
-20 ---=--^^^ ---
-21 ^^^=== ---
-22 ====== ---
-23 ^^^
-24 =--=--
-25
18 19 20 21 22 23 09/02 02 03 04 05 06 07_08_09_10_11_12 Hour
W W W W W W W W W W W W NW W W W W W W Wind dir.
5 5 5 5 5 4 4 4 4 4 3 3 2 2 2 1 1 1 1 Wind(m/s)
Legend left axis: - Sunny ^ Scattered = Clouded =V= Thunder # Fog
Legend right axis: | Rain ! Sleet * Snow
[Terminal FTW!]
On peut envoyer une ligne vide pour consulter les options de ce serveur.
finger @graph.no
Cette présentation achevée, nous pouvons maintenant voir comment mettre en place un serveur finger sous OpenBSD. Ce n'est pas extrêmement compliqué. D'abord, le système d'exploitation vient un serveur finger (fingerd(8)) et avec tous les outils nécessaires à son fonctionnement.
fingerd(8) n'est pas un serveur à part entière : il ne tourne pas en arrière-plan (ce n'est un daimôn) et il n'accepte pas lui-même les connections entrantes ; il a besoin d'inetd(8) pour fonctionner. inetd(8) surveille une série de ports et transmet les requêtes à certains programmes.
C'est par le fichier de configuration /etc/inetd.conf qu'on lui indique quels ports surveiller et quel programme exécuter en cas de requête. Un exemple de configuration est disponible au /etc/examples/inetd.conf. Ce sont les lignes qui commencent par « #finger » qui nous intéressent. Il s'agit de les copier dans le fichier de configuration /etc/inetd.conf et de retirer ces dièses qui marquent les commentaires.
$ cat /etc/inetd.conf finger stream tcp nowait _fingerd /usr/libexec/fingerd fingerd -lsm finger stream tcp6 nowait _fingerd /usr/libexec/fingerd fingerd -lsm
Il y a deux lignes, car on veut qu'inetd(8) soit attentif au requêtes venants d'IPv4 et d'IPv6. Si on voulait surveiller non pas le port 79, qui est le port standard de finger, mais à un autre port, on replacerait le premier champ (« finger ») par le numéro de ce port. On peut aussi écrire :
$ cat /etc/inetd.conf.fictif 79 stream tcp nowait _fingerd /usr/libexec/fingerd fingerd -lsm 79 stream tcp6 nowait _fingerd /usr/libexec/fingerd fingerd -lsm
En fait, inetd(8) consulte le fichier /etc/services pour connaître la correspondance entre le nom du service et numéro de port à utiliser. Une autre option serait donc de modifier ce fichier.
Le quatrième champ spécifie le nom de l'utilisateur sous lequel exécuter le programme finger. Ici, il s'agit de _fingerd, ce qui est tout à fait approprié.
Le cinquième champ donne le chemin vers le programme qui doit traiter la requête. Ici, il nous utilisons le programme inclus dans OpenBSD. Les champs suivants seront donnés en argument à ce programme (avec « fingerd » comme argument 0). Trois options sont spécifiées. -l demande de noter chaque requête dans les journaux. -s empêche le transfert des requêtes. Sans cela, la commande
finger québec~72@graph.no@asteride.xyz
demanderait à asteride.xyz d'effectuer lui-même la requête à graph.no. Celui-ci n'aurait aucune idée de l'identité de l'initiateur et penserait qu'il s'agit d'asteride.xyz. On comprend que ce n'est pas ce qu'on souhaite permettre.
Finalement, l'option -m oblige l'utilisateur à envoyer le nom d'utilisateur exacte au serveur. Autrement, on s'attend à ce que, advenant une requête au sujet d'un utilisateur inexistant, le serveur réponde avec une liste nom d'utilisateurs qui ressemblent à celui de la requête.
La page du manuel de fingerd(8) dresse la liste de toutes les options disponibles.
fingerd(8) offre très peu d'options pour modifier l'apparence du contenu de la réponse ; la liberté de l'utilisateur se limite à ce qu'il peut écrire dans ~/.plan et dans ~/.project.
En fait, sur OpenBSD fingerd(8) ne s'occupe pas lui-même la recherche et de la présentation des données. Il délègue ces tâches à finger(1), le même programme qu'on utilise normalement pour effectuer une requête à partir de la ligne de commande. D'ailleurs, il est possible d'utiliser localement la commande sans serveur finger. Voici la réponse affichée par la commande finger(1) que j'ai exécutée sur mon ordinateur portable. (Notez l'absence de « @ »).
Login: selve Name: Selve
Directory: /home/selve Shell: /bin/ksh
On since Fri Feb 10 12:43 (EST) on ttyp0 from :0
On since Fri Feb 10 13:48 (EST) on ttyp4 from :0
On since Fri Feb 10 13:47 (EST) on ttyp6 from :0
On since Fri Feb 10 13:49 (EST) on ttyp7 from :0
On since Fri Feb 10 13:50 (EST) on ttyp8 from :0
On since Fri Feb 10 14:19 (EST) on ttypa from :0
New mail received Thu Feb 9 13:35 2023 (EST)
Unread since Wed Sep 14 18:06 2022 (EDT)
No Plan.
fingerd(8) propose d'utiliser un autre programme que finger(1). On l'indique à l'aide de l'option -P. Voici à quoi devrait ressembler le fichier de configuration d'inetd(8) si on voulait que fingerd(8) transmette le texte généré à chaque requête par le programme qui se trouve au /etc/finger. Bien entendu, il faut que ce programme soit exécutable par _fingerd.
$ cat /etc/inetd.conf finger stream tcp nowait _fingerd /usr/libexec/fingerd fingerd -lsm -P /etc/finger finger stream tcp6 nowait _fingerd /usr/libexec/fingerd fingerd -lsm -P /etc/finger
À partir de là, on peut faire ce qu'on veut. Selon ce que j'ai trouvé dans le code source de fingerd(8), le programme de remplacement devrait savoir gérer (ou ignorer) les options -smMpl, telles que décrites dans finger(1). Les arguments sont donnés par fingerd(8) dans cet ordre : les options sont placées d'abord, suivies du marqueur de fin des options (--) et du contenu de la seule ligne envoyée par le client (un nom d'utilisateur ou rien, la plupart du temps)[4]
Voici un exemple de programme de remplacement.
$ cat /etc/finger
#!/bin/sh
# interpréter les options (en fait, elles sont ignorées)
PLAN=1
while getopts "smMpl" OPT
do
case $OPT in
s) FG_COURT=1 ;;
m) FG_CHERCHER= ;;
M) FG_CHERCHER=1 ;;
p) FG_PLAN= ;;
l) FG_LONG=1 ;;
*) logger -t finger "L'option -$OPT n'est pas supportée."
esac
done
shift $((OPTIND - 1))
UTILISATEUR="$1"
printf '%snn' $UTILISATEUR
[ -r "/home/$UTILISATEUR/.plan" ] && cat "/home/$UTILISATEUR/.plan"
[ -r "/home/$UTILISATEUR/.projet" ] && cat "/home/$UTILISATEUR/.projet"
Ce programme n'est pas robuste. Il ne sait même pas gérer la ligne vide. De plus, les dossiers de certains utilisateurs ne se trouvent pas dans /home/ ; c'est le cas de root, par exemple. Il faudrait consulter /etc/passwd pour savoir où le dossier de chaque utilisateur se trouve. Le but est simplement de donner un aperçu du pouvoir qui est entre nos mains.
Cette section s'impose, car le protocole finger n'a pas une bonne réputation en matière de sécurité. Cette réputation n'est qu'en partie justifiée. Elle est répandue surtout à cause du ver de Morris, qui a, entre autres, profité d'une vulnérabilité dans le programme fingerd répandu à l'époque (c'est-à-dire 1988). Ce n'est pas le protocole lui-même qui a été pris en défaut, mais une mise en œuvre particulière. D'ailleurs, tout service exposé à l'Internet vient avec ses risques en matière de sécurité. Et gardons en tête que ces vulnérabilités ont d'autant moins de chances de survenir que le programme est simple.
Article Wikipédia sur le ver de Morris
Si on veut affirmer que finger n'est pas sécuritaire, c'est à l'objectif même du service qu'il faut s'en prendre. Si on essaie généralement de divulguer le moins d'information possible aux pirates potentiels, c'est parce qu'ils peuvent parfois s'en servir pour mieux cibler leurs attaques. Or, le but de finger est de partager de l'information. Disposer de la liste des utilisateurs connectés et connaître leurs plans et leurs intérêts a des chances de faciliter la vie de ces pirates. Ça ne fait aucun doute. Par contre, avoir un blogue, un compte Facebook, un compte Mastodon, etc. bref être présent et actif sur ce genre de plateforme accessible publiquement risque d'aider les pirates bien plus que d'avoir une présence sur finger.
S'il y a peu de chance d'y avoir une faille utile aux pirates dans les programmes finger contemporains et si j'estime que les risques associés à l'information disponible par leur truchement est négligeable, je crois qu'il faut être extrêmement vigilant au moment de créer un programme finger alternatif. Il est très facile de faire des erreurs, surtout dans des programmes shell. Prudence! donc.
Si la configuration de base d'un serveur finger sous OpenBSD est très simple, j'ai trouvé moins évident l'exécution d'un programme finger alternatif. Dans ce cas, malgré la réputation d'OpenBSD dans ce domaine, la page de manuel de fingerd(8) ne semble malheureusement aider que ceux qui savent déjà comment faire. J'ai en effet dû consulter le code source du programme pour comprendre comment le configurer. J'ai donc écrit ce guide pour aider ceux qui auraient la même idée que moi.
RFC 1288: The Finger User Information Protocol (en français malgré le titre)
[1] Certains ajouteraient que le peu de souci porté à la sécurité informatique fait de finger un digne représentant de son époque. Ce n'est pas exactement mon avis. J'y reviendrai.
[2] Voir l'article de Stéphane Bortzmeyer sur finger.
[3] Le client Bombadillo, par exemple, accepte les textes encodés en UTF-8. Je serais d'accord pour qu'on modifie le client d'OpenBSD afin qu'il respecte LC_CTYPE.
[4] Astuce : si on veut avoir une idée des arguments que finderd(8) donne au programme, on peut remplacer « /etc/finger » par « echo ». Ces arguments seront ainsi transmis par finger.
— Selve