Mettre en quarantaine une instance EC2 compromise

Si GuardDuty ou votre système de surveillance indique qu’une instance EC2 établit des connexions sortantes malveillantes, effectue du minage de cryptomonnaie ou analyse votre réseau, elle doit être mise en quarantaine.

La mise en quarantaine isole l’instance de tout le reste afin qu’elle ne puisse plus causer de dommages, tout en la maintenant active pour permettre l’investigation au lieu d’effacer les preuves.

La méthode de mise en quarantaine la plus propre consiste à remplacer les groupes de sécurité de l’instance par un seul groupe d’analyse judiciaire, dépourvu de règles entrantes et, idéalement, de règles sortantes.

Comme les groupes de sécurité conservent l’état des connexions et sont associés à l’instance, cette opération coupe immédiatement l’essentiel des nouvelles connexions sans toucher au reste du sous-réseau.

L’arrêt ou la suppression de l’instance efface la mémoire vive, où résident de nombreux logiciels malveillants, et peut détruire les traces laissées par l’attaquant.

La mise en quarantaine maintient l’instance active mais isolée, ce qui vous permet de créer un instantané du disque, de vider la mémoire et d’observer son comportement. Ne procédez à l’éradication qu’après avoir sécurisé les preuves.

Une instance compromise possède souvent un rôle IAM via son profil d’instance, et l’attaquant peut exfiltrer ces identifiants temporaires pour les utiliser ailleurs.

Remplacez ou supprimez le rôle et révoquez les sessions actives afin que les identifiants volés cessent de fonctionner dans tous les services AWS, et pas uniquement sur l’instance elle-même.

Créez immédiatement un instantané de chaque volume EBS attaché afin de figer le disque, et capturez la mémoire si vos outils le permettent.

Étiquetez ces éléments comme preuves de mise en quarantaine. Le montage en lecture seule de copies des instantanés sur une instance d’analyse judiciaire distincte vous permet d’enquêter sans modifier les originaux ni risquer une nouvelle infection.

Pour ajouter une couche de protection, vous pouvez créer une règle de refus dans l’ACL réseau du sous-réseau pour l’adresse IP privée de l’instance.

Les NACL sont sans état et s’appliquent à la limite du sous-réseau ; elles interceptent donc tout chemin qu’une modification du groupe de sécurité aurait pu laisser passer. Utilisez-les comme protection complémentaire, et non comme contrôle principal.

Si l’instance se trouve derrière un Elastic Load Balancer ou dans un groupe Auto Scaling, désenregistrez-la afin que le trafic cesse de lui être acheminé.

Placez l’instance Auto Scaling en veille ou détachez-la afin que le groupe ne détruise pas vos preuves en remplaçant ce qu’il considère comme un hôte défaillant.

À grande échelle, les étapes manuelles sont trop lentes. Un schéma courant consiste à relier une détection GuardDuty à une règle EventBridge, puis à une fonction Lambda qui remplace le groupe de sécurité, crée des instantanés des volumes, supprime le rôle et étiquette l’instance.

Vous transformez ainsi une réponse en plusieurs étapes en une seule action automatisée, déclenchée quelques secondes après la détection.

La mise en quarantaine vous donne le temps de déterminer comment l’attaquant est entré. Examinez CloudTrail, les journaux de flux VPC et les journaux présents sur l’hôte afin de trouver le point d’entrée : un port exposé, une vulnérabilité non corrigée ou un identifiant volé.

Sans connaître la cause première, une instance reconstruite peut être compromise exactement de la même manière.

Une fois les preuves capturées et la cause première comprise, remplacez l’instance à partir d’un AMI propre et corrigé plutôt que de nettoyer celle qui est infectée.

Il est presque impossible de garantir qu’une porte dérobée a été entièrement supprimée. Redéployer depuis une image fiable est plus rapide et bien plus sûr que de nettoyer un hôte compromis.

Marquez l’instance mise en quarantaine et ses instantanés avec des étiquettes explicites telles que Status=Quarantine et l’identifiant de l’incident, afin qu’aucune automatisation ni aucun opérateur ne la remette accidentellement en service ou ne supprime les preuves.

Suivez-la jusqu’à la clôture dans votre dossier d’incident, en vérifiant à la fois que la menace est contenue et que les éléments d’analyse judiciaire sont préservés.

Choisissez l’étape appropriée concernant l’identifiant.

Mettez en quarantaine une instance EC2 compromise en lui attribuant un groupe de sécurité qui refuse tout le trafic, tout en la maintenant active ; créez ensuite un instantané des volumes EBS et capturez la mémoire avant toute autre modification. Supprimez le rôle du profil d’instance et révoquez les sessions actives afin d’invalider les identifiants volés, détachez l’instance des équilibreurs de charge et d’Auto Scaling, puis ajoutez une protection complémentaire avec une NACL. Automatisez l’ensemble du processus à partir de GuardDuty, recherchez la cause première et reconstruisez l’instance depuis un AMI fiable.