Bonjour à tous. Vous aurez remarqué que je n’ai rien publié depuis un mois ; c’est tout simplement parce que j’étais en vacances ! Du coup j’ai décidé de reprendre nos réflexions sur une note légère.

Je vous propose aujourd’hui de parler de fichier hosts, une notion assez simple qui ne devrait donc pas générer un article trop long.

Le fichier Hosts c’est quoi ?

La dernière fois on a parlé de DNS et de comment ce système permet de traduire des noms de domaines faciles à retenir par l’humain en adresses IP utilisables par les machines. Pour ceux qui ont lu cet article (les autres, allez le lire) vous vous rappellerez peut-être qu’on avait évoqué la possibilité de garder un tableau de correspondance DN <> IP sur toutes les machines reliées à l’internet, avant de préciser que ce n’était pas une option viable vu la masse de données à stocker.

Eh bien figurez-vous que le fichier hosts c’est justement ça : un tableau de correspondance DN <> IP conservé sur votre machine qui permet de faire le même travail de résolution d’un DNS. Alors pourquoi avoir ce type de fichier localement puisqu’on a démontré la dernière fois les limites de cette idée ?

En l’an 20 avant internet…

L’internet est officiellement né le 12 mars 1989 mais il n’est pas le premier né de sa famille. 20 ans plus tôt, le 29 octobre 1969, l’université de Californie à Los Angeles (UCLA) lançait Arpanet. Le but de ce réseau de communication était de permettre la communication de pair à pair au sein d’un parc informatique hétérogène et géographiquement répartis. Il est l’ancêtre direct de l’internet moderne.

Dès les débuts d’Apanet, l’idée des noms de domaines et de leur résolution en adresse IP s’est présentée, avec les questions technologiques que cela soulève. Toutefois, à l’époque, l’Arpanet n’était pas un réseau ouvert : il fallait être membre du réseau et l’inscription était réservée à des établissements de recherche.

Du coup, les problèmes sont déjà moindres :

• on n’a pas du tout le même nombre de machines connectées qu’aujourd’hui : pour vous donner une idée ils ont commencé avec 4 hôtes en 1969 et ont terminé avec environ 160 000 hôtes en 1989. On est très loin des milliards de machines actuellement connectées à l’internet. C’est donc très gérable
• on peut déléguer la maintenance de cette liste à un tiers de confiance puisque le réseau n’est pas un open bar.

Et dans les faits, c’est ce qui a eu lieu : le Stanford Research Institute a pris sur lui de maintenir manuellement une liste à jour des liens DN <> IP et de rendre disponible à tous cette liste par transfert de fichier sur le réseau Arpanet. Le DNS permettant la publication automatique des mises à jour et la résolution dynamique des DN n’a été décrit puis mis en place qu’en 1983 et 1984 respectivement pour faire face à la croissance du réseau (avec le recul, ils ont eu peur de pas grand-chose parce que bon côté croissance… on a mis un gros facteur d’échelle depuis ; en 1984 ils ont atteint 1000 hôtes).

Du coup dans le fonctionnement : Stanford maintient la liste à jour et chacun peut aller la copier de manière asynchrone sur sa machine. La faible taille du réseau fait de la taille du fichier et de sa maintenabilité des obstacles acceptables et le fait qu’on aille le recopier de temps en temps de façon asynchrone permet de ne pas saturer la bande passante du lien avec Stanford. Malin non ?

Fichier hosts en 2022

Alors vous vous dites peut-être : “Sympa ton cours d’histoire mais pourquoi tu nous parles d’une technologie qui a été remplacée en 1984 par un truc vachement mieux que tu nous as déjà décrit le mois dernier ?”.

Et bien pour vous répondre je vais faire simple : parce que les fichiers hosts n’ont pas disparu de la circulation. Vos machines Mac, Windows ou Linux ont encore un fichier hosts, héritage de cette ancienne époque et figurez-vous qu’il est même fonctionnel et qu’il peut donc permettre des trucs un peu sympas.

Déjà j’aimerais vous parler de son usage le plus courant, lié à sa configuration par défaut, que vous avez sans doute mis en œuvre des dizaines de fois sans même y réfléchir… j’ai nommé localhost.

Il est conventionnel d’avoir une carte réseau virtuelle dire de loopback qui permet d’adresser sa propre machine via l’adresse IP 127.0.0.1. De fait, ce faisant on appelle notre propre hôte local sans passer par un réseau sortant. On a donc eu la brillante idée d’associer le DN localhost à cette IP. Le fait que localhost soit automatiquement résolu en 127.0.0.1 n’est pas le fruit du hasard : c’est un comportement décrit dans le fichier hosts de votre machine.

On met le nez dedans pour voir ? Sur les machines Linux (et Mac, mais d’aucuns rétorqueront que ce n’est jamais qu’un Linux sexy et payant), le fichier hosts se trouve à ‘/etc/hosts’. Pour Win10 je vous invite à aller le trouver à ‘c:\Windows\System32\Drivers\etc\hosts‘. Voici le contenu classique par défaut de ce fichier pour une distribution Linux :

127.0.0.1	localhost
::1		localhost

Rien de bien méchant : la première ligne associe l’IPv4 127.0.0.1 à localhost et la seconde associe l’IPv6 0000:0000:0000:0000:0000:0000:0000:0001 (qu’on abrège volontiers en ::1) à localhost également.

Vous pouvez rajouter librement des lignes sous cette forme pour créer de nouvelles associations. Notez que le séparateur est une double tabulation et ne contient pas d’espaces !

Sachez que pour la plupart des systèmes le fichiers hosts est consulté avant toute tentative de résolution DNS. Tout DN y figurant sera donc résolu par le biais du fichier hosts et non pas par le chemin DNS habituel.

Il est possible d’associer plusieurs DN à la même IP soit en créant plusieurs ligne soit en séparant les DN par des espaces sur une ligne unique.

A quoi ça peut bien servir ?

Bon ok, mon histoire de localhost ne vous époustoufle pas ? Vous voulez des usages plus pratico-pratique ?

Le firewall du pauvre

Vous voulez bloquer un site pour les utilisateurs de cette machine ? Il suffit de créer une ligne qui associe le DN en question à l’IP 0.0.0.0 (attention à la mise en cache possible de votre navigateur, il vous faudra peut-être vider voter cache)

0.0.0.0 twitter.com

De la même façon, pour pouvez vouloir bloquer des sites malveillants reconnus ou des fournisseurs de publicité. Il existe des listes préétablies d’hôtes que vous pourriez vouloir bloquer de cette manière. L’une des plus réputées est celle de Steven Black.

D’autres ALIAS pour Localhost

Vous développez localement la future application disponible à l’adresse titi.fr ? Cela peut être une bonne idée d’ajouter titi.fr comme alias de 127.0.0.1 sur votre machine pendant les développements afin d’éviter de passer à côté de certains problèmes.

Attention toutefois à bien retirer cette association une fois le site de titi.fr en ligne car vous seriez alors court-circuité et renvoyé vers localhost.

En attendant la màj…

Comme le fichier hosts passe avant la résolution DNS vous pouvez l’utiliser en palliatif en attendant que la création ou la mise à jour d’une association DN <> IP soit répercutée dans les différents DNS pertinents. Là encore, pensez à enlever cette ligne une fois le vrai circuit DNS prêt à l’action.

Une utilisation malveillante

Vous l’aviez peut-être vu venir : j’ai comme d’habitude un message moralisateur à vous servir. Le fichier hosts peut être un vecteur d’attaque sur votre machine. Supposez par exemple que je redirige un site “classique” tel que gmail.com vers une IP qui n’est pas la bonne… et sur laquelle j’ai mis une réplique du site dans le but de récupérer votre mot de passe ! Il se passe quoi à votre avis ?

Ceux qui suivent (et qui s’en souviennent) viennent de soupirer de soulagement car ils se rappellent que l’utilisation désormais standard des certificats a mis à mal ce type d’attaque. En effet, si vous n’avez pas dit à votre navigateur de faire confiance à des certificats CA douteux et si vous n’ignorez pas le warning qui va s’imposer à vous lors de la redirection houleuse faite par le fichier hosts, vous ne devriez pas tomber dans le panneau.

Sachez néanmoins pour votre culture qu’avant la mise en place du HTTPs ce type d’attaque était courant puisque vous n’aviez aucun moyen de vous assurer de l’identité du serveur sur lequel vous vous trouviez.