Un partage Samba exposé sur la machine file1 (adresse 10.0.0.30) peut révéler des fichiers à quiconque accède au service, sans nécessiter de déchiffrer un mot de passe ni d’installer un logiciel malveillant. Ce cas de figure est instructif pour notre laboratoire, car il démontre la nécessité de définir des limites avant d’entamer tout test de sécurité. Nous n’examinerons que les systèmes dont nous sommes propriétaires ou pour lesquels nous disposons d’une autorisation écrite, et nous consignerons les éléments exposés par le service afin que son propriétaire puisse corriger la vulnérabilité.
Notre environnement fixe repose sur le réseau privé 10.0.0.0/24. La machine Kali (10.0.0.10) sert de poste de test. web1 (10.0.0.20) est une cible Metasploitable 2 proposant des services sur les ports 21, 22 et 80, tandis que file1 (10.0.0.30) expose Samba sur les ports 139 et 445. Aucune adresse située en dehors de ce sous-réseau ne fait partie de l’exercice, et le laboratoire ne comporte aucune cible exposée à Internet. Nous présentons la nature d’une vulnérabilité et ses effets observables, et non des méthodes d’exploitation « weaponized » (prêtes à l’emploi) susceptibles d’être réutilisées contre un autre système. Examinons maintenant la limite qui circonscrit tous les exercices ultérieurs :
Ce schéma définit une direction autorisée : de Kali vers les deux cibles du laboratoire désignées. Une requête vers 10.0.0.30 entre dans le périmètre autorisé car file1 est une cible désignée ; la même requête vers une adresse inconnue est interdite, même si le service semble identique.
La limite du réseau ne suffisant pas à définir un comportement acceptable, nous avons besoin d’un accord sur les règles d’engagement (Rules of Engagement). Il s’agit d’un contrat écrit précisant qui peut effectuer des tests, quels actifs peuvent être testés, quand les tests peuvent avoir lieu et quelles méthodes sont autorisées. Pour ce cours, l’accord désigne web1 et file1, limite l’activité à la plage 10.0.0.0/24 et considère Kali comme l’unique point d’origine des tests. Une autorisation écrite permet de distinguer une évaluation contrôlée d’un accès non autorisé au regard de lois telles que le Computer Fraud and Abuse Act aux États-Unis ou le Computer Misuse Act 1990 au Royaume-Uni. Ce cours dispense un enseignement technique et ne constitue pas un conseil juridique.
Cet accord empêche également un exercice pour débutants de devenir nuisible. Nous pouvons identifier les services exposés et observer sans risque si une liste Samba anonyme révèle un nom de fichier. Nous ne cherchons pas à optimiser des charges utiles (payloads), à contourner la surveillance, à établir une persistance, à compromettre la disponibilité, à lancer des attaques par force brute (devinette de mots de passe) à grande échelle ni à consigner des identifiants réels dans nos notes. Un test doit produire des preuves vérifiables par un défenseur, et non entraîner une modification incontrôlée que le propriétaire du laboratoire devrait ensuite corriger.
Limite de sécurité
Si une action modifie l’accès, la disponibilité ou la persistance au-delà de l’observation convenue, arrêtez-vous et notez la situation plutôt que de poursuivre.
Chaque étape autorisée laisse une trace sous forme de preuve. Le carnet de notes consigne la commande telle qu’elle a été saisie, un horodatage, l’adresse cible et la sortie pertinente. Si la liste d’un partage affiche backup.zip, nous notons ce nom ainsi que les conditions d’accès, puis nous nous demandons quel journal de défenseur enregistrerait la connexion et quelle configuration empêcherait l’accès anonyme. Le tableau ci-dessous distingue les observations utiles des actions qui outrepassent notre accord :