mlab Academy
EN
Sécuriser son domaine

Votre surface d'attaque : les sous-domaines

Ce que l'énumération de sous-domaines révèle à un attaquant, et comment réduire la surface : hôtes oubliés, préprod, interfaces d'admin.

1 Introduction

Le site de votre entreprise est exemple.fr, mais il est rarement seul. Au fil des années, on ajoute mail., boutique., preprod., vpn., jenkins. et un serveur de test monté pour une démo en 2021. Chacun de ces noms est une porte d'entrée vers votre organisation, et leur liste complète forme votre surface d'attaque.

Un attaquant ne commence pas par votre site principal, souvent le mieux entretenu. Il commence par lister vos sous-domaines, car c'est sur les oubliés que traînent les vieux logiciels, les mots de passe par défaut et les correctifs jamais appliqués. Cette liste se construit facilement à partir de sources publiques. La section Sous-domaines d'un scan de domaine vous montre la même liste que celle d'un attaquant, pour que vous fassiez le ménage avant lui.

3

Listes dans le rapport : les hôtes qui servent un site, les noms qui résolvent, et tous les noms déjà vus

2018

Chrome exige que les certificats TLS publics soient inscrits dans les journaux Certificate Transparency

Public

N'importe qui peut fouiller ces journaux : un nom présent sur un certificat n'a rien de secret

2 Comment ça marche

Le DNS ne permet pas de demander « donne-moi tous les noms sous exemple.fr ». On retrouve donc les sous-domaines de façon indirecte, grâce aux traces qu'ils laissent en public. La source principale est Certificate Transparency (CT) : chaque certificat émis par une autorité publique est inscrit dans des journaux publics en ajout seul, avec les noms qu'il couvre. Demandez un certificat pour preprod-admin.exemple.fr et ce nom est publié en quelques minutes, définitivement.

1

Découvrir

Rassembler tous les noms déjà vus pour le domaine, surtout dans les journaux de certificats. Les noms anciens ou morts en font partie.

2

Résoudre

Demander au DNS lesquels répondent encore aujourd'hui, avec quelle adresse (A, AAAA) ou quel alias (CNAME).

3

Visiter

Ouvrir la page d'accueil de chaque nom qui pointe vers une adresse publique, comme un navigateur, et noter le logiciel qui répond.

Ce qu'un attaquant fait de cette liste

Les noms parlent d'eux-mêmes : vpn et remote indiquent où se connectent les salariés, dev, test et preprod désignent des copies de votre application souvent moins protégées que la production, et grafana, gitlab ou jenkins donnent le nom exact du produit pour lequel chercher un exploit. Les outils qui automatisent tout cela (subfinder, amass, une recherche sur crt.sh) sont gratuits et tournent en quelques secondes. Rien dans cette section n'est une information cachée : c'est ce que tout le monde peut déjà voir.

3 Analyse détaillée

Sous-domaines exposés sur le web

C'est la liste la plus utile. Chaque sous-domaine qui pointe vers une adresse publique a été visité une fois : sa page d'accueil et son certificat TLS, rien de plus. Chaque ligne donne le statut HTTP, l'état du certificat, une note, les logiciels détectés et les vulnérabilités connues (CVE) de ces versions.

Des logiciels avec leur numéro de version

Quand un serveur annonce nginx 1.18.0 ou Apache 2.4.49, le rapport compare cette version à la base de vulnérabilités. Un hôte marqué Known exploited (exploité activement) fait tourner une version dont la faille est utilisée dans de vraies attaques (elle figure dans la liste KEV de la CISA) : à corriger ou couper en premier. Même sans CVE, masquez les bannières de version (server_tokens off; sous nginx, ServerTokens Prod sous Apache).

La note

Elle compte six en-têtes de sécurité HTTP, puis perd des lettres pour les problèmes de transport : HTTP en clair, certificat expiré ou au mauvais nom, vieux TLS 1.0 ou 1.1. Les API, les pages d'erreur et les challenges de CDN n'ont pas de lettre, la ligne explique pourquoi.

Le titre de la page est un indice

Un titre « Login », « Dashboard », « Welcome to nginx » ou « Index of / » sur un sous-domaine que vous ne reconnaissez pas mérite un coup d'œil aujourd'hui. Une interface d'administration ou une page d'installation par défaut n'a rien à faire sur internet.

Sous-domaines actifs

Tous les noms qui résolvent encore dans le DNS, avec leurs valeurs A (IPv4), AAAA (IPv6) et CNAME. Un nom peut être actif sans servir de site : un serveur de mail, une passerelle VPN ou une IP interne publiée par erreur apparaissent aussi ici. Vous pouvez vérifier chaque ligne vous-même : 

dig +short A preprod.exemple.fr
dig +short CNAME ancienne-boutique.exemple.fr

Des adresses privées dans le DNS public

Un enregistrement A comme 10.0.4.12 ou 192.168.1.20 est injoignable de l'extérieur, mais il dessine gratuitement votre réseau interne. Gardez les noms internes dans une zone DNS interne.

Des CNAME vers des plateformes tierces

Un CNAME vers un hébergeur, un stockage cloud ou un SaaS n'est sûr que tant que le compte cible existe. Si vous l'avez fermé, quelqu'un d'autre peut réclamer le nom : voir prise de contrôle de sous-domaine.

DNS wildcard

Si *.exemple.fr résout, n'importe quel nom répond, et « actif » ne veut plus dire grand-chose. Le rapport l'indique par un bandeau et écarte les noms qui ne répondent que grâce au wildcard.

Tous les sous-domaines découverts

L'historique complet : chaque nom trouvé dans les journaux de certificats, marqué Active s'il résout aujourd'hui, Inactive sinon. Un panneau dans la colonne « Suspicious Keyword » signale un nom qui contient un mot désignant souvent un service sensible (un VPN, une administration ou un environnement de test, par exemple). Regardez ceux-là d'abord.

Inactif ne veut pas dire disparu

Un nom qui ne résout plus est inoffensif en soi. Il compte quand un enregistrement DNS pointe encore vers lui, ou quand le serveur derrière tourne toujours sur une IP brute. Les noms qui ont existé sont traités dans sous-domaines fantômes.

Servez-vous-en comme d'un inventaire

Passez la liste en revue avec les responsables de chaque service. Chaque nom doit avoir un propriétaire et une raison d'exister. Ceux que personne ne réclame sont ceux à éteindre.

Réduire l'exposition, dans l'ordre

1

Urgent : corrigez ou coupez tout hôte marqué exploité activement, puis ceux qui ont des CVE critiques. Traitez les risques de prise de contrôle le jour même.

2

Cette semaine : placez les interfaces d'administration, la CI, les tableaux de bord de supervision et la préproduction derrière un VPN ou un proxy d'accès avec SSO (Zero Trust). Ils ne doivent pas afficher une page de connexion à tout internet.

3

Ce mois-ci : décommissionnez ce qui n'a pas de propriétaire. Supprimez l'enregistrement DNS puis arrêtez le serveur, dans cet ordre, pour qu'aucun nom ne pointe vers une ressource libérée.

4

Hygiène : masquez les versions, ajoutez les en-têtes de sécurité, renouvelez ou retirez les certificats expirés, et relancez un scan après chaque changement.

Garder des noms hors des journaux de certificats

Un nom publié dans les journaux CT ne peut plus en être retiré. Vous pouvez en revanche éviter d'en publier de nouveaux :

Certificats wildcard : un compromis

Un certificat pour *.exemple.fr n'affiche que le wildcard dans les journaux, pas chaque hôte. En contrepartie, la même clé privée est copiée sur tous les serveurs qui l'utilisent : un seul serveur compromis expose la clé de tous. Si vous en utilisez, faites-le par environnement, jamais une clé unique pour toute l'entreprise. Cela ne cache rien face à la devinette DNS non plus : un nom courant comme vpn se trouve de toute façon par force brute.

Services internes, certificats internes

Un service réservé au personnel n'a pas besoin d'un certificat public. Une autorité de certification privée (ou le certificat de votre proxy d'accès) garde son nom hors des journaux publics.

Cacher n'est pas protéger

Un nom discret fait gagner du temps, pas de la sécurité. Un hôte à jour et protégé par une authentification ne craint rien, même si tout le monde connaît son nom.

Cartographiez votre surface d'attaque sur mlab.sh

Un scan de domaine liste les sous-domaines trouvés dans les journaux de certificats, vérifie lesquels résolvent encore, visite chacun des hôtes publics et compare les logiciels trouvés aux vulnérabilités connues.

Scanner votre domaine sur mlab.sh

4 Red Flags

Un hôte marqué exploité activement

Le logiciel qu'il fait tourner a une faille utilisée dans de vraies attaques. C'est la première chose à corriger de tout le rapport.

Outils d'administration, de CI ou de supervision ouverts sur internet

Un Jenkins, un GitLab, un Grafana, un phpMyAdmin ou l'interface d'un routeur qui répond publiquement attire les essais de mots de passe et d'exploits. Mettez-les derrière un VPN ou un SSO.

Des copies de préproduction ou de test

Elles tournent souvent sur du code plus ancien, en mode debug, avec de vraies données copiées de la production. Réservez-les à votre équipe ou éteignez-les entre deux usages.

Des sous-domaines que personne ne reconnaît

Un projet d'agence oublié ou un ancien site de campagne n'est, par définition, plus mis à jour. Retrouvez son propriétaire ou décommissionnez-le.

Certificats expirés et HTTP en clair sur des hôtes actifs

Le signe que plus personne n'entretient l'hôte, et une porte ouverte à l'interception. Renouvelez et redirigez vers HTTPS, ou retirez l'hôte.

Propulsé par mlab.sh

Modules connexes

Prise de contrôle de sous-domaine et DNS orphelin

Comment un CNAME ou un NS oublié permet à n'importe qui de publier sur votre sous-domaine, et comment repérer et nettoyer ces entrées avant un attaquant.

Certificats, CAA et Certificate Transparency

Qui peut émettre des certificats pour votre domaine, ce que révèlent les journaux publics, et pourquoi les certificats partagés comptent.

Les vulnérabilités connues de votre site

Comment un scan relie une version logicielle à des CVE, ce que signifient CVSS, EPSS et KEV, et comment prioriser les correctifs.