Séparer le domaine interne du domaine externe

Utiliser le même nom de domaine pour le site public et pour tout le parc interne paraît commode et cela offre discrètement plusieurs avantages à l’attaquant d’un seul coup. L’argument pour les séparer n’est pas esthétique, il tient au fait qu’une poignée d’attaques concrètes cessent de fonctionner dès que les services internes vivent sous un nom qui n’apparaît jamais dans un certificat public ni dans une réponse DNS publique.

Pourquoi un domaine partagé fuit

Le certificat wildcard est le premier problème. Un *.company.com émis pour le web public reste, par construction, valable pour chaque hôte interne sous ce nom, de sorte que le jour où un seul serveur public est compromis, son certificat usurpe n’importe quel service interne sans qu’un navigateur ne bronche. Une clé volée et l’homme du milieu est de confiance partout.

La Certificate Transparency est le deuxième et c’est celui qu’on oublie. Chaque certificat publiquement reconnu est journalisé, publiquement, pour toujours et crt.sh transforme ce journal en carte gratuite de votre parc:

jenkins.company.com   → vous faites de la CI/CD, par ici
gitlab.company.com    → le code vit là
backup.company.com    → les sauvegardes sont là
ad.company.com        → Active Directory, par ici
vpn.company.com       → accès distant, frappez ici

Aucune de ces reconnaissances ne coûte à l’attaquant le moindre paquet envoyé vers vous. Vous l’avez publiée vous-même, à l’instant où vous avez demandé le certificat à une autorité publique. Des noms internes sous un domaine interne, signés par une autorité interne, n’entrent jamais dans un journal CT et la carte s’éteint.

Le troisième, c’est le DNS. Partager une zone entre l’intérieur et l’extérieur impose le split-horizon, pénible et dont les ratés vont dans le sens de la divulgation et il lie la résolution interne au sort de votre DNS externe: détournez ou empoisonnez le côté public et le côté interne suit.

Typosquatting et homographes

Le domaine sosie est la moitié ingénierie sociale du problème et il devient plus tranchant quand les services internes portent un nom d’allure publique, parce que l’utilisateur fait confiance à ce qui a l’air interne et saute la vigilance qu’il accorderait à un lien externe.

Les fautes de frappe sont la version bon marché: compeny.com, intranet.company.co amputé du m, intranet-company.com qui replie un sous-domaine dans un domaine. La version dangereuse est l’homographe IDN, un nom visuellement identique et différent octet par octet:

Légitime : company.com
Sosie    : сompany.com   (le 'с' cyrillique, U+0441)
Punycode : xn--ompany-hrf.com

Les substitutions latin vers cyrillique (a→а, c→с, e→е, i→і, o→о, p→р) rendent au pixel près dans la plupart des polices, si bien que le seul indice fiable reste le Punycode, c’est-à-dire précisément ce qu’un utilisateur pressé ne vérifie jamais. Le butin est le trio habituel: une fausse page de connexion qui moissonne les identifiants, une “mise à jour logicielle” qui livre du malware, une page de facture qui déroute un paiement.

L’architecture qui referme tout ça

Deux domaines, un public et un interne, sans recouvrement:

company.com            (public)           company.internal   (interne)
├── www.company.com                       ├── intranet.company.internal
├── mail.company.com                      ├── ad.company.internal
├── api.company.com                       ├── gitlab.company.internal
└── blog.company.com                      └── *.dev.company.internal

Depuis 2024, .internal est formellement réservé par l’ICANN pour l’usage privé et c’est la première fois que ce conseil repose sur plus solide qu’une convention: le nom ne pourra jamais être délégué sur l’internet public, donc jamais entrer en collision avec un enregistrement réel ni réclamer un certificat publiquement reconnu. .corp et .home figurent sur la même liste des noms jamais délégués et conviennent aussi, même si .internal est désormais celui qui porte une bénédiction explicite.

Le côté public prend des certificats individuels par service, jamais un wildcard, de sorte qu’une compromission ne se propage pas et que les journaux CT ne révèlent que ce qui est déjà censé être public. Le côté interne fait tourner sa propre PKI, où un wildcard est acceptable justement parce que rien n’en est publié:

Autorité racine (hors ligne, air-gap)
├── Intermédiaire - serveurs
├── Intermédiaire - utilisateurs et postes
├── Intermédiaire - développement (courte durée)
└── Intermédiaire - signature de code

Ce qu’il vaut la peine d’ajouter

L’enregistrement défensif réduit le risque sosie pour les noms qui feraient le plus mal, à la fois les fautes de frappe courantes et les homographes cyrilliques évidents de la marque, avec une surveillance des nouveaux plutôt qu’une tentative de préenregistrer un espace infini.

Côté technique, les leviers qui déplacent vraiment l’aiguille: des résolveurs internes faisant autorité sur la zone .internal, des navigateurs réglés pour forcer l’affichage Punycode des noms à scripts mélangés afin qu’un homographe cesse de se cacher, HSTS avec includeSubDomains et l’épinglage de certificat pour la poignée d’applications qui en justifient le coût d’exploitation.

Pour la surveillance, la CT elle-même devient un outil défensif dès qu’on l’observe pour son propre nom et les scanners de permutation de domaine couvrent l’espace du squatting:

# surveiller la CT pour tout ce qui revendique votre nom
curl -s "https://crt.sh/?q=%25company.com&output=json" \
  | jq '.[] | select(.name_value | contains("company"))'

# énumérer les sosies enregistrés, homographes compris
dnstwist --registered --format idna company.com

La règle côté utilisateur qui survit à tout l’outillage est ennuyeuse et efficace: les services internes vivent sous .internal, on les atteint par un signet et jamais par un lien d’e-mail et tout ce qui réclame des identifiants sous un nom d’allure publique mérite un second regard sur la barre d’adresse avant un mot de passe.

Là où la promesse s’arrête

La séparation ne rend pas le phishing impossible et quiconque la vend comme une “protection absolue” la survend. Ce qu’elle fait, c’est retirer du plateau des classes entières d’attaques: le wildcard qui usurpe l’intérieur, le journal CT qui le cartographie, le sosie public qui emprunte un nom d’allure interne. Cela vaut la peine d’être retiré en soi et une séparation nette entre le domaine public et un domaine interne réservé à cet usage est la façon la moins chère de le faire.