Utiliser la requête OS d’adresse externe dans le playbook de fichier /etc/hosts

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 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 donnent une procédure pas à pas des actions, des tâches et des flux secondaires qui sont disponibles dans le système d’exploitation 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, collectez 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 publiques/privées de l’organisation interne.
      Figure 1. Requête système d’exploitation de l’adresse externe dans le playbook de fichier /etc/hosts
      Tâche de réponse pour vérifier si cette adresse IP appartient à 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 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 se termine.
    5. Si l’adresse IP n’appartient pas à la plage d’adresses IP publiques/privées de l’organisation interne, identifiez l’utilisateur qui s’est connecté au serveur pendant la période d’alerte dans l’Action 8.
    6. Dans l’action 9, si l’adresse IP semble suspecte, envoyez 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 toutes 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 du propriétaire ou de 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 fourni 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 une revue post-incident.

          Dans l’action 20, après la revue post-incident, le flux se termine.

        Figure 2. Utilisation de la requête OSquery d’adresse externe dans le playbook de fichier /etc/hosts
        Tâche de réponse pour vérifier si les informations du propriétaire ou de l’équipe sont disponibles.
    12. Dans l’Action 21, si les informations sur le propriétaire ou 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 Action 24, appliquez un correctif aux 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, terminez la revue post-incident avant de fermer la tâche.