Scan passif et scan actif : ce que chacun trouve, quand l’utiliser

Les outils de sécurité qui regardent vos domaines de l’extérieur se rangent en deux familles. Un audit passif ne lit que ce qui est déjà public. Un scan actif envoie des requêtes conçues pour faire apparaître une faiblesse. Les deux sont utiles ; ils répondent à des questions différentes, présentent des risques différents et demandent des autorisations différentes.

Ce que fait un audit passif

Un audit passif se comporte comme un visiteur prudent. Il interroge le DNS, lit les journaux Certificate Transparency, charge votre page d’accueil, établit une connexion TLS, salue vos serveurs de messagerie et consulte des bases publiques qui indexent déjà Internet, comme les listes de ports ouverts et de vulnérabilités connues.

Il trouve beaucoup de choses : une politique DMARC absente, un certificat sur le point d’expirer, un sous-domaine qui peut être détourné, un port de base de données ouvert à tout Internet, une vieille version de bibliothèque annoncée dans votre page, un domaine sosie enregistré la semaine dernière. Comme il n’envoie rien d’inhabituel, il peut tourner chaque jour sur chaque domaine, sans que personne n’ait à signer quoi que ce soit.

Sa limite tient en un mot : il soupçonne. Quand une page annonce WordPress 6.1 et une extension avec une faille connue, l’audit peut dire que la faille est probable. Il ne peut pas dire si une extension de sécurité, un pare-feu ou un correctif rétroporté la bloque. Et il ne voit rien derrière votre page de connexion.

Ce que fait un scan actif

Un scan actif envoie des requêtes de test : il demande des chemins qui ne devraient pas exister, met des caractères inattendus dans les formulaires et les paramètres, essaie les requêtes dont une vulnérabilité connue a besoin, et regarde comment l’application répond. Deux types d’outils font l’essentiel du travail :

• Les scanners à modèles comme Nuclei envoient des requêtes précises pour les vulnérabilités connues, les mauvaises configurations, les fichiers et panneaux d’administration exposés. Rapides et précis, ils trouvent ce qui est déjà documenté.
• Les scanners d’applications web comme OWASP ZAP explorent l’application, puis essaient des familles d’attaques sur chaque paramètre trouvé : injection SQL et de commandes, cross-site scripting, traversée de répertoires. Plus lents, ils trouvent aussi les failles de votre propre code.

Avec un compte de test, les deux peuvent passer derrière la connexion, là où se trouve l’essentiel de la valeur d’une application.

Les risques des tests actifs

Un test actif n’est pas anodin, c’est pourquoi il lui faut des règles.

• L’autorisation. Tester un système sans l’accord de son propriétaire peut être une infraction dans de nombreux pays. Ne testez que ce qui vous appartient ou ce que vous avez l’autorisation écrite de tester, et gardez cette autorisation.
• La charge. Des milliers de requêtes en quelques minutes peuvent ralentir un petit site. Fixez un débit maximal et un créneau.
• Les effets de bord. Un robot qui clique sur « supprimer », « se désabonner » ou « payer » le fait vraiment. Les pages de déconnexion mettent fin à la session dont le scan a besoin. Excluez-les.
• Les tiers. Un sous-domaine peut pointer vers un serveur que vous n’exploitez pas : un hébergeur, une plateforme SaaS, un ancien prestataire. Vérifiez les adresses avant de les tester.
• Les identifiants. Un compte de test doit être un compte de test, créé pour l’occasion, jamais un administrateur de production, et son mot de passe ne doit ni circuler en clair ni rester dans un journal.

Lequel vous faut-il ?

Question	Audit passif	Scan actif
Mes e-mails sont-ils protégés contre l’usurpation ?	Oui	Non
Un nouveau sous-domaine ou certificat est-il apparu ?	Oui	Non
Une base de données ou un bureau à distance est-il ouvert à Internet ?	Oui, d’après les données publiques	Ce n’est pas son rôle
Cette vulnérabilité soupçonnée est-elle vraiment exploitable ?	La soupçonne	La confirme ou l’écarte
Mon formulaire de connexion ou de recherche a-t-il une faille d’injection ?	Non	Oui
Puis-je le lancer chaque jour sur tous mes domaines ?	Oui	Rarement utile, et plus lourd

Pour la plupart des petites entreprises et des agences, la réponse est : les deux, dans cet ordre. Un audit passif sur chaque domaine, en permanence, et un scan actif sur les applications qui comptent le plus, quelques fois par mois et après chaque mise en production importante. Aucun des deux ne remplace un test d’intrusion mené par une personne, qui trouve les failles de logique et les enchaînements de petites faiblesses qu’aucun outil ne voit.

Les combiner sans danger

1. Commencez par le passif. Corrigez ce que l’audit trouve : c’est peu coûteux, et cela retire le bruit qu’un scan actif signalerait sinon.
2. Écrivez le périmètre. Les hôtes, les adresses vers lesquelles ils pointent, les chemins à éviter, les dates et heures, le débit maximal, la personne qui autorise.
3. Utilisez un compte de test, avec des données réalistes et aucun vrai client.
4. Prévenez votre hébergeur et votre équipe sécurité, et dites-leur de quelle adresse viennent les requêtes.
5. Lisez les résultats à la lumière de l’audit. Un soupçon confirmé par un test actif passe en tête de liste ; celui qui n’est pas reproduit peut attendre, avec la raison écrite.

Comment Perimetry Cloud s’y prend

Chaque offre Perimetry Cloud exécute l’audit passif. Le scan actif vérifié, bientôt disponible en option par domaine, suit les étapes ci-dessus : il ne fonctionne que sur un domaine dont vous avez prouvé la propriété, après une autorisation signée dans l’application avec le périmètre, le créneau et le débit, depuis une adresse publiée, avec Nuclei et OWASP ZAP. Les tests destructifs, la recherche de mots de passe et les pages de déconnexion, de suppression et de paiement sont laissés de côté, et chaque soupçon de l’audit revient confirmé ou non reproduit.