Surface d'attaque externe : le guide complet

Votre surface d'attaque externe, c'est l'ensemble des points par lesquels votre organisation est joignable depuis Internet, sans authentification préalable. Un serveur web, une API, un portail de connexion, un serveur de messagerie, un espace de stockage, une machine de préproduction oubliée : tout ce qui répond à une requête venue de l'extérieur en fait partie.

La nuance qui compte : cette surface n'est pas ce que vous avez décidé de publier. C'est ce qui est réellement joignable. L'écart entre les deux est précisément là où se logent les incidents.

Exposition et vulnérabilité ne sont pas la même chose Un service exposé n'est pas une faille. Un serveur web public est normal — c'est même son métier. Le risque naît de l'exposition non intentionnelle : une interface d'administration joignable sans VPN, une base de données ouverte au monde, un environnement de test qui tourne sur des données de production.

Réduire sa surface d'attaque ne consiste donc pas à tout fermer. Cela consiste à ce que chaque chose exposée le soit délibérément.

Aucune organisation ne décide d'élargir sa surface d'attaque. Elle s'élargit par accumulation, et presque toujours par les mêmes chemins :

• Une agence monte un site de campagne sur un sous-domaine. La campagne se termine ; le sous-domaine reste.
• Une équipe déploie une préproduction derrière un CNAME. Le projet est livré ; l'entrée DNS lui survit.
• Un service SaaS est testé puis abandonné, mais le sous-domaine continue de pointer vers lui.
• Un certificat est émis pour un hôte interne, et ce nom d'hôte atterrit dans un registre public que tout le monde peut consulter.

Leur point commun : personne n'a commis d'erreur visible. Chaque geste était raisonnable au moment où il a été fait. C'est l'absence d'inventaire, et non une faute, qui produit la dérive — d'où l'intérêt de regarder périodiquement son propre domaine avec les yeux de quelqu'un qui ne dispose que de sources publiques.

Un attaquant qui prépare une intrusion ne commence pas par attaquer votredomaine.com. Il commence par lister tout ce qui existe autour : vpn., admin., preprod., jenkins., backup., old. Chacun de ces noms est une cible potentielle, et les intéressantes sont rarement celles que vous surveillez.

Comment cette liste s’obtient sans vous toucher L'énumération de sous-domaines est aujourd'hui presque entièrement passive, et toutes les sources sont publiques.

• Les journaux de Certificate Transparency conservent la trace de chaque certificat jamais émis, et chacun nomme les hôtes qu'il couvre. crt.sh vous montre les vôtres depuis un navigateur.
• Des fournisseurs de DNS passif conservent l'historique des résolutions, y compris des enregistrements que vous avez supprimés il y a des années.
• Les moteurs de recherche ont déjà indexé des pages que personne n'avait l'intention de publier.
• Des scanners à l’échelle d’Internet publient ce qu’ils ont trouvé sur vos plages d’adresses.

Rien de tout cela n'envoie le moindre paquet à votre infrastructure. C'est la partie sur laquelle il faut s'arrêter : cette reconnaissance ne laisse aucune trace dans vos journaux. Vous ne pouvez donc pas détecter qu'elle a eu lieu, ni savoir si elle a déjà eu lieu.

Que faire de cette liste Énumérez d'abord, jugez ensuite. Constituez l'inventaire complet, puis rangez chaque entrée dans l'une de trois piles : elle doit être publique et elle est configurée en conséquence, elle ne doit pas être publique et doit passer derrière un VPN ou une liste d'autorisation, ou elle ne devrait plus exister et son enregistrement DNS doit disparaître.

Cette troisième pile est en général la plus fournie. C'est aussi la moins coûteuse à traiter, ce qui en fait le bon point de départ.

Chaque certificat émis par une autorité publiquement reconnue est consigné dans les journaux de Certificate Transparency. Ces journaux existent pour une bonne raison : ils permettent à quiconque de détecter un certificat émis frauduleusement pour un domaine qui lui appartient. Ils ont aussi un effet de bord facile à négliger.

Dès l'instant où vous demandez un certificat pour un hôte interne, son nom devient lisible par le monde entier. Des noms comme vpn., jenkins., sap-preprod. ou backup-admin. offrent à un attaquant la carte de vos conventions de nommage internes, et le plus souvent une liste de nouvelles cibles, y compris pour des hôtes injoignables depuis l'extérieur.

Vous pouvez voir les vôtres en cinq secondes :

https://crt.sh/?q=%25.exemple.com

ReconScope lit les mêmes journaux, via certSpotter avec crt.sh en repli, et signale les entrées dont les noms paraissent internes plutôt que publics.

Que faire - Ne mettez pas de noms d'hôtes purement internes dans des certificats publiquement approuvés. Utilisez une autorité de certification privée pour les services internes. - Envisagez un DNS à horizon séparé, pour que les noms internes n'aient jamais besoin d'un certificat public. - Utilisez un certificat wildcard là où des noms individuels décriraient votre architecture.

Une réserve qui change la façon d'aborder le sujet : un nom déjà publié dans un journal CT ne peut pas être retiré. Ces journaux sont par conception en ajout seul, et c'est exactement ce qui les rend dignes de confiance. Aucun nettoyage ne vous est offert. Le seul remède est de cesser d'en ajouter, et de considérer tout ce qui s'y trouve déjà comme connu de votre adversaire.

Le détournement de sous-domaine fait partie des rares constats qui sont presque toujours un problème réel et immédiatement exploitable, et non un risque théorique. C'est pourquoi il mérite d'être vérifié en premier quand vous découvrez un enregistrement inconnu.

Le mécanisme est simple. Un sous-domaine pointe, via un CNAME, vers un service tiers : une plateforme d'hébergement, un outil de documentation, un CDN. Le service est ensuite résilié, ou la ressource supprimée. L'enregistrement DNS, lui, reste. Le nom pointe désormais vers un emplacement libre chez ce fournisseur.

dig +short CNAME boutique.exemple.com
exemple-boutique.unfournisseur.net.
le compte n'existe plus chez le fournisseur
n’importe qui peut réenregistrer ce nom et y servir son contenu

Celui qui réclame cet emplacement sert du contenu depuis un nom d'hôte qui porte votre marque, votre réputation et, selon la portée de vos cookies, potentiellement vos sessions. Cela en fait une plateforme de phishing idéale, précisément parce que le domaine est authentiquement le vôtre. Aucun avertissement de navigateur ne se déclenchera. Vos clients n'ont aucun moyen de faire la différence.

Que faire Supprimez sans attendre les enregistrements DNS pendants, ou reprenez possession de la ressource chez le fournisseur. Puis rendez la correction structurelle : ajoutez un audit des CNAME à votre procédure de mise hors service, pour que retirer un service et retirer son enregistrement DNS deviennent une seule tâche au lieu de deux. C'est la seconde que tout le monde oublie.

Au-delà des noms, il y a ce qui répond réellement. Des scanners à l'échelle d'Internet cataloguent en continu les ports ouverts, les logiciels qui tournent et leur version. Ce catalogue est public et interrogeable : un attaquant peut donc trouver vos services exposés sans vous scanner — et donc sans apparaître dans le moindre de vos journaux.

Deux choses méritent ici d’être distinguées, car on les confond souvent.

Ce qui est à vous, et ce qui est à votre hébergeur Sur un hébergement mutualisé, la plupart des services visibles sur votre adresse IP appartiennent à l'hébergeur, pas à vous. Lire cette liste comme le catalogue de vos propres manquements est une erreur, et cela conduit à poursuivre des constats sur lesquels vous ne pouvez pas agir.

Ce qui reste vôtre, quel que soit l'hébergement, c'est tout ce par quoi vos propres identifiants transitent : un service FTP non chiffré, un panneau de contrôle servi en HTTP simple, une interface d'administration joignable depuis n'importe où. Ceux-là méritent d'être traités, quel que soit l'exploitant de la machine.

Les vulnérabilités connues Lorsqu'un scanner enregistre la version d'un service, la corréler aux CVE publiées est trivial. Un service non corrigé pour lequel un exploit public existe n'est pas un risque hypothétique : c'est une cible qui ne demande aucun effort de reconnaissance.

Le travail relève moins de l'outillage que de l'ordre des opérations. En pratique :

• Inventoriez d'abord. On ne protège pas ce qu'on n'a pas listé, et la liste est presque toujours plus longue que prévu.
• Supprimez avant de défendre. Chaque enregistrement DNS pendant et chaque service hors d'usage que vous retirez est une cible qu'il n'y a plus à protéger.
• Placez l'administration derrière une frontière. VPN ou liste d'IP autorisées pour les panneaux d'administration, les préproductions et l'outillage interne.
• Séparez la préproduction des données de production. Un environnement de test qui contient de vraies données est une fuite de production qui n'attend qu'un mot de passe plus faible.
• Faites de la mise hors service une checklist. L'essentiel de la dérive vient de services éteints sans que leur enregistrement DNS, leur certificat ou leur espace de stockage ne le soient avec eux.
• Recontrôlez périodiquement. La surface n'est pas un état, c'est un flux : elle change à chaque projet livré.

Rien de tout cela ne demande un gros budget. Cela demande de savoir ce qui existe.