Karantænesætning af en kompromitteret EC2-instans

Hvis GuardDuty eller din overvågning viser, at en EC2-instans opretter ondsindede udgående forbindelser, miner kryptovaluta eller scanner dit netværk, skal den sættes i karantæne.

Karantæne isolerer instansen fra alt andet, så den ikke kan gøre mere skade, samtidig med at den holdes kørende til undersøgelse i stedet for at slette bevismaterialet.

Den reneste karantæne er at erstatte instansens sikkerhedsgrupper med én forensisk gruppe, der ikke har nogen indgående regler og helst heller ingen udgående regler.

Fordi sikkerhedsgrupper er tilstandsbevarende og knyttet til instansen, afbryder dette straks stort set alle nye forbindelser uden at påvirke noget andet i undernettet.

Hvis du stopper eller afslutter instansen, tømmes RAM, hvor meget malware befinder sig, og angriberens spor kan blive ødelagt.

Karantæne holder instansen kørende, men isoleret, så du kan tage et øjebliksbillede af disken, udlæse hukommelsen og observere adfærden. Du fjerner først truslen, når bevismaterialet er blevet sikret.

En kompromitteret instans har ofte en IAM-rolle via sin instansprofil, og angriberen kan være i gang med at eksfiltrere disse midlertidige legitimationsoplysninger for at bruge dem andre steder.

Erstat eller fjern rollen, og tilbagekald aktive sessioner, så de stjålne legitimationsoplysninger holder op med at virke på tværs af alle AWS-tjenester, ikke kun på selve instansen.

Tag straks et øjebliksbillede af alle tilknyttede EBS-diskenheder for at fastfryse disken, og indfang hukommelsen, hvis dine værktøjer understøtter det.

Mærk disse artefakter som karantænebevismateriale. Hvis du monterer kopier af øjebliksbilleder skrivebeskyttet på en separat forensisk instans, kan du undersøge dem uden at ændre originalerne eller risikere geninfektion.

Som et ekstra lag kan du tilføje en afvisningsregel i undernettets netværks-ACL for instansens private IP-adresse.

NACL'er er tilstandsløse og gælder ved undernettets grænse, så de opfanger enhver sti, som en ændring af sikkerhedsgruppen måtte overse. Brug dette som ekstra sikkerhed, ikke som den primære kontrol.

Hvis instansen befinder sig bag en Elastic Load Balancer eller i en Auto Scaling-gruppe, skal du afregistrere den, så trafikken holder op med at blive sendt til den.

Sæt Auto Scaling-instansen i standby, eller afkobl den, så gruppen ikke ødelægger dit bevismateriale ved at erstatte det, den opfatter som en usund vært.

I stor skala er manuelle trin for langsomme. Et almindeligt mønster er: GuardDuty-finding til EventBridge-regel til Lambda, som udskifter sikkerhedsgruppen, tager øjebliksbilleder af diskenheder, fjerner rollen og mærker instansen.

Det omdanner et svar med flere trin til én automatiseret handling, der udløses få sekunder efter registreringen.

Karantæne giver dig tid til at undersøge, hvordan angriberen kom ind. Gennemgå CloudTrail, VPC Flow Logs og logfiler på værten for at finde indgangspunktet — en eksponeret port, en upatchet sårbarhed eller en stjålet legitimationsoplysning.

Uden den grundlæggende årsag kan en genopbygget instans blive kompromitteret på præcis samme måde.

Når bevismaterialet er indfanget, og den grundlæggende årsag er forstået, skal du erstatte instansen fra en ren, patchet AMI i stedet for at rense den inficerede.

Du kan sjældent garantere, at en bagdør er fjernet fuldstændigt. Genudrulning fra et pålideligt image er hurtigere og langt mere pålideligt end at rense en kompromitteret vært.

Mærk den karantænesatte instans og dens øjebliksbilleder med tydelige mærker som Status=Quarantine og hændelses-id'et, så ingen automatisering eller operatør ved et uheld sætter den tilbage i drift eller sletter bevismaterialet.

Følg den frem til afslutning i din hændelsesregistrering, og bekræft både, at truslen er inddæmmet, og at de forensiske artefakter er bevaret.

Sæt en kompromitteret EC2-instans i karantæne ved at indsætte en sikkerhedsgruppe, der afviser alt, mens instansen holdes kørende. Tag derefter øjebliksbilleder af EBS-diskenheder, og indfang hukommelsen, før du ændrer noget. Fjern rollen fra instansprofilen, og tilbagekald aktive sessioner, så stjålne legitimationsoplysninger bliver ugyldige. Fjern instansen fra loadbalancere og Auto Scaling, og tilføj en NACL som ekstra sikkerhed. Automatiser hele processen fra GuardDuty, undersøg den grundlæggende årsag, og genopbyg fra en pålidelig AMI.