Résumé

  • L’article de 1993 de Dan Farmer et Wietse Venema propose de confronter les systèmes à la perspective d’un intrus, puis SATAN rend cette vérification reproductible pour les administrateurs.
  • Le CERT décrit un outil qui collecte des informations réseau et recherche des problèmes potentiels, mais avertit que le mode exploratoire peut sonder des hôtes hors du domaine administratif de l’opérateur.
  • Le résultat d’un scan ne prouve ni compromission, ni intention, ni autorisation ; il indique seulement ce que les contrôles ont observé sur les cibles et pendant la période effectivement couverte.

Faire de la perspective adverse un outil

Conseiller aux administrateurs de « penser comme un attaquant » ne suffit pas. Il faut des méthodes que l’équipe peut appliquer à ses propres systèmes et des résultats qu’elle peut examiner. Dans leur article de 1993, « Improving the Security of Your Site by Breaking Into It », Farmer et Wietse Venema défendent cette approche : tester les services accessibles depuis le réseau permet d’apercevoir certaines faiblesses qu’un contrôle interne, machine par machine, pourrait manquer.

Les noms successifs de SATAN témoignent de son parcours. L’article de 1993 développe l’acronyme comme « Security Analysis Tool for Auditing Networks » ; l’avis du CERT de 1995 parle du « Security Administrator Tool for Analyzing Networks ». Les deux auteurs comptent dans cette histoire : la notoriété du programme ne doit pas faire disparaître la coécriture de Venema. Dans un entretien publié par USENIX en 2014, Farmer se souvient que la mention de SATAN dans leur article a suscité davantage d’intérêt que prévu et les a conduits à réfléchir plus concrètement à sa réalisation.

Il s’agit de son récit rétrospectif, pas d’une preuve de déploiement ou d’usage particulier.

Le CERT décrit un outil de test et de compte rendu. SATAN examinait des services comme finger, NFS, NIS, FTP et rexd, puis pouvait résumer les informations recueillies ou appliquer des règles simples pour signaler des problèmes potentiels, accompagnés de pistes de correction. Il rassemblait aussi des éléments de topologie, de services, de matériel et de logiciels. Ce passage à l’échelle rendait l’audit plus reproductible : l’administrateur pouvait rapprocher les services observés de la configuration attendue et prioriser des correctifs.

Un résultat restait toutefois une observation, pas un verdict. Une vulnérabilité signalée appelle une enquête ; elle ne prouve pas qu’un intrus l’a exploitée. À l’inverse, l’absence de signal ne garantit pas la sécurité : elle dépend des hôtes, des services et des contrôles inclus dans l’exécution.

Le périmètre fait partie du test

L’avis CA-1995-06 du 3 avril 1995 s’appuyait d’abord sur l’examen de la version bêta 0.51, puis fut mis à jour après la sortie officielle 1.1.1. Le CERT y explique que le mode exploratoire pouvait sonder des hôtes non explicitement spécifiés, éventuellement au-delà du domaine administratif de l’équipe. Il évoque à la fois la recherche malveillante de machines vulnérables et le risque qu’un administrateur légitime touche accidentellement un autre réseau.

L’intention de l’opérateur ne délimite donc pas à elle seule le trafic produit. Il faut savoir ce qui a été saisi au départ, ce que l’outil découvre ensuite et jusqu’où ses vérifications se propagent. Un réseau partagé, un service tiers ou une machine voisine peut recevoir des sondes sans avoir été visé par la personne qui a lancé l’audit. La portée est une propriété de l’exécution, non une supposition tirée de l’objectif initial.

Le CERT sépare cette question d’un autre problème : après SATAN 1.0, un avis CA-95.07a a décrit une vulnérabilité dans le logiciel lui-même. Une sonde qui sort du périmètre et un défaut de sécurité du scanner sont deux faits distincts. Les confondre ferait perdre la précision du dossier historique.

La documentation permet d’affirmer que SATAN a facilité l’audit et que son mode exploratoire pouvait dépasser les cibles nommées. Elle ne permet pas d’attribuer une intention à une personne précise, de conclure à une compromission ni d’établir qu’un incident particulier a eu lieu. La Note 65 de Heng Lu, « Running-Code Primacy », intervient uniquement comme grille éditoriale : une observation produite par un système en fonctionnement doit être limitée à ce que le test a effectivement fait. Elle ne constitue pas une source sur Farmer ou SATAN.

Sources