Utilisez l’OSquery de l’adresse externe dans le playbook de fichier /etc/hosts

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 2 minutes de lecture

    • Utilisez ce playbook pour enquêter sur les incidents qui indiquent qu’un nom d’hôte ou un domaine interne a été affecté à une adresse IP externe sur le DNS local (/etc/hosts) d’un serveur Linux. Les étapes suivantes vous fournissent une procédure pas à pas des actions, des tâches et des flux secondaires disponibles dans la requête OSquery de l’adresse externe dans le playbook de fichier /etc/hosts.

    Avant de commencer

    Rôle requis :
    • sn_si.admin
    • flow_designer

    Procédure

    1. Lorsque le playbook est déclenché et commence à s’exécuter, dans l’action 1, identifiez le nom d’hôte ou le nom de domaine correspondant à la traduction IP externe à partir du journal brut.
    2. Dans l’action 2, rassemblez les détails de l’adresse IP et du nom d’hôte.
    3. Dans l’action 3, vérifiez si cette adresse IP appartient ou non à la plage d’adresses IP publique/privée de l’organisation interne.
    4. Dans l’action 4, si l’adresse IP appartient à la plage d’adresses IP publique/privée de l’organisation interne, procédez comme suit :
      1. Dans l’action 5, documentez les résultats obtenus jusqu’à présent.
      2. Dans l’action 6, lancez une revue post-incident.
        Dans l’action 7, après la revue post-incident, le flux s’arrête.
    5. Si l’adresse IP n’appartient pas à la plage d’adresses IP publique/privée de l’organisation interne, identifiez l’utilisateur qui s’est connecté au serveur pendant la période d’alerte lors de l’action 8.
    6. Dans l’action 9, si l’adresse IP semble suspecte, posez un ticket informatique au propriétaire ou à l’équipe du serveur pour modifier la configuration dès que possible.
    7. Dans l’action 10, vérifiez s’il y a eu une activité malveillante sur le serveur avant et après l’ajout de l’entrée DNS.
    8. Dans l’action 11, vérifiez les connexions à l’adresse IP externe à partir du serveur.
    9. Dans l’action 12, documentez les résultats obtenus jusqu’à présent.
    10. Dans l’action 13, vérifiez si les informations du propriétaire ou de l’équipe sont disponibles ou non.
    11. Dans l’action 14, si les informations sur le propriétaire ou l’équipe sont disponibles, procédez comme suit :
      1. Dans l’action 15, contactez le propriétaire ou l’équipe du serveur pour voir s’ils reconnaissent l’activité.
        Vous pouvez utiliser le modèle d’e-mail fourni pour contacter le propriétaire ou l’équipe du serveur.
      2. Dans l’action 16, vérifiez si le propriétaire ou l’équipe a fourni une justification commerciale valide ou non.
      3. Dans l’action 17, si le propriétaire ou l’équipe fournie n’a pas fourni de justification commerciale valide, le flux s’arrête.
        Toutefois, si le propriétaire ou l’équipe a fourni une justification commerciale valide, procédez comme suit :
        1. Dans l’action 18, documentez les résultats obtenus jusqu’à présent.
        2. Dans l’action 19, lancez un examen post-incident.

          Dans l’action 20, après la revue post-incident, le flux s’arrête.

    12. Dans l’action 21, si les informations du propriétaire ou de l’équipe ne sont pas disponibles, isolez le système hôte.
    13. Dans l’action 22, réinitialisez les informations d’identification potentiellement compromises.
    14. Dans l’action 23, bloquez l’accès réseau à l’hôte compromis.
    15. Dans l’action 24, corrigez les appareils concernés.
    16. Dans l’action 25, lever le confinement et ramener les systèmes aux normes opérationnelles.
    17. Dans l’action 26, effectuez la revue post-incident avant de fermer la tâche.