Som du ser är vår webbplats inte anpassad för äldre webbläsare. Vi rekommenderar att du uppgraderar till en nyare webbläsare.
!!

Vi söker en verksamhetschef till CERT-SE, en viktig roll i arbetet med att utveckla Sveriges förmåga att förebygga och hantera it-incidenter. Sista ansökningsdag är den 14 april.

Publicerad

Begränsa intrång - Vad? Hur? När? Var? Vem?

I den här delprocessen behandlas begränsning och avbrott av pågående attack, minimering av spridning samt insamling av bevis för vidare analys.

Följande punkter behandlas:

Isolera & Analysera system

Bör man isolera system vid en attack?

När organisationen nått den här delprocessen så är det bekräftat att en incident har skett.

I ett sådant fall bör organisationen isolera system för att avbryta attacken, förhindra följdattacker samt vidare spridning av eventuellt godtycklig kod. Det finns ett flertal metoder för att isolera system och avbryta attacker, de beskrivs senare i dokumentet. Hur systemet ska isoleras beror vanligen på klassningen av systemet eller organisationens policys.

Sedan när systemet är isolerat samlas data in för bevisföring i de fall organisationen vill leta upp och åtala förövaren.

Efter dessa steg är det dags för analys av insamlat data och här vill man gärna hitta svaren på frågorna:Vad? Hur? När? Var? Vem?

Det här är en väldigt känslig del i incidenthanteringsprocessen. Det är ytterst viktigt att följa rätt rutiner för insamling, behandling och förvaring av data som ska användas som bevis.

Under denna delprocess dyker frågor upp som handlar om polisanmälan, egna undersökningar för att hitta och åtala förövaren. CERT-SE behandlar inte dessa frågor utan beskriver dem lite kortfattat och i de fall där det behövs, hänvisar till andra externa parter som kan hjälpa till.

Vad kan CERT-SE bidra med?

  • Insamling av information

  • Insamling av data

  • Analys av information och data

  • Råd och rekommendationer

  • Länkar till mer information

  • Kontaktinformation till externa aktörer inom området

Förutsättningar och terminologi

CERT-SE rekommenderar att använda statiska binärer från ett externt media vid datainsamling och analys. Detta för att försäkra att binärerna inte har blivit trojaniserade av t.ex., ett rootkit eller liknande.

Det förutsätter också att alla kommandon kan köras som root-användaren.

De kommandon som anges i dokumentet (förutom där andra källor anges) är statiska binärer som finns att tillgå från:

  • HELIX Live-CD ver. 1.9

De flesta binärer som anges finns även förinstallerade och verifierade på WinXP, Win Server 2003 samt Ubuntu Linux 8.04.

CERT-SE rekommenderar att insamling och analyser - i den mån det är möjligt - görs på ett separat system som kan vara en forensisk arbetsstation eller annat externt system.

Vid insamling av flyktigt data från ett live-system så kan Live-CD:n monteras på Live-systemet (utan att starta upp operativsystemet) för att köra de statiska binärerna direkt från katalogen där de ligger.

Live-CD:n kan även användas för att starta en distribution som kan köras direkt från CD:n. I det fallet så får incidenhanteraren tillgång till flera verktyg och metoder som underlättar datainsamling och analys.

Forensisk arbetsstation = Specialkonfigurerat system som innehåller ett antal verktyg anpassade för forensiska undersökningar samt incidenthantering

Live-CD = CD-ROM-baserat operativsystem/distribution som kan köras direkt från CD:n

Live-system = Ett system som fortfarande är i sitt fulla bruk med nätverkskoppling

Nedtaget system = Ett isolerat system utan nätverkskoppling

Flyktigt data = är den typen av information som försvinner om systemet måste startas om - t.ex. data som finns i minnet, i form av systemprocesser, öppna filer, nätverksprocesser m.m

Chain of custody = kronologisk logg av bevishantering

Order of volatility = inbördes ordning av flyktigt data

Insamling av information från situationen

Genomgång av frågor kring den eventuella incidenten för att analysera läget och fastställa vilka åtgärder som är eller inte är vidtagna.

För att kunna avgöra hur eller om man ska avbryta incidenten så är det viktigt att sätta sig in situationen. Det finns ett antal parametrar som är avgörande för hur organisationen kan hantera avbrytandet av en incident.

Nedan följer några frågor som bör ställas i ett tidigt skede.

  • Är systemet isolerat från andra interna system?

  • Vad vill den drabbade organisationen göra åt incidenten?

    • Polisanmäla/åtala angripare?

    • Avbryta/stoppa angreppet så snabbt som möjligt?

    • Återställa systemet så snabbt som möjligt?

    • Låta systemet vara intakt, ta upp ett nytt system parallellt?

  • Kan/får systemet stängas ner?

  • Vilka mandat har intressenten/kontaktpersonen?

  • Är systemet "outsourcat"?

  • Vad har organisationen att förlora/vinna om man tar till motgrepp?

  • Finns det lokala loggar, nätverksloggar, brandväggsloggar, IDS-loggar?

  • Har organisationen kört någon sårbarhets-scanner för att upptäcka sårbarheter?

  • Har organisationen gjort egna analyser, i så fall vilka?

  • Vilka patchar är installerade på systemet?

  • Har organisationen redan skapat spegelkopior på HD?

  • Är systemet bortkopplat från Internet/nätverk?

  • Vad är viktigast för organisationen, få upp systemet så fort som möjligt, eller söka upp och åtala förövaren?

Isolering av drabbade system

Det är av stor vikt att isolera system för att begränsa skadan och förhindra vidare spridning inom organisationen. I vissa fall, då organisationen vill göra vidare analys av incidenten kan det vara viktigt att inte stänga ner system för att ha möjligheten att samla in bevis, samtidigt som organisationen bör isolera system för att förhindra vidare spridning.

Isolering av system och avbrott av attack samt konsekvenser

I fall, då organisationen inte vill samla in bevis kan hela systemet isoleras eller stängas ner för att avbryta incidenten. I sådana fall bör hänsyn tas till ett antal olika scenarier (beskrivna nedan) som kan spela en avgörande roll.

Det är väldigt känsligt på vilket sätt organisationen väljer att avbryta incidenten. Detta på grund av att en del illasinnade program innehåller inbyggda fällor som kan känna av om systemet stängs ner eller nätverkskablar dras ur, och då utlösas. Fällorna kan i vissa fall t.ex. radera data på hårddisk, kryptera hårddisk eller på andra sätt förstöra systemet.

Det finns en del olika alternativ att välja på när organisationen ska avbryta en pågående incident. Det som gör problemet ännu mer delikat är att om organisationen väljer något alternativ så följer samtidigt en konsekvens av agerandet. I vissa fall är det som att välja mellan pest eller kolera.

Att avbryta en incident är vanskligt, om något misstag görs kan det få stora konsekvenser. CERT-SE bör verkligen vara försiktiga med att föreslå åtgärder.

Olika motgrepp och konsekvenser

  • Avsluta “den illasinnade” processen: Ett relativt enkelt sätt att avbryta incidenten är att leta upp, isolera och (om det är möjligt) stoppa processen som orsakar problemet.

  • Konsekvens: Det kan finnas risk att någon fälla aktiveras.

  • Avsluta nätverks-session:På samma sätt som i exemplet ovan, leta upp, isolera och sedan avsluta sessionen.

  • Konsekvens: Det kan finnas risk att någon fälla aktiveras.

  • Blockera systemet mot Internet: Också detta är ett relativt enkelt sätt att avbryta incidenten, t.ex. blockera angriparens IP-adress eller hela systemet i brandvägg, router.

  • Konsekvens: Det kan finnas risk att någon fälla aktiveras.

  • Använda VLAN-teknik för att isolera systemet: Ett relativt enkelt sätt att isolera systemet genom att tilldela ett eget VLAN där systemet står ensamt.

  • Konsekvens: Det kan finnas risk att någon fälla aktiveras

  • Blockera systemets port i switch:Ocså ett enkelt sätt att isolera systemet.

  • Konsekvens: Det kan finnas risk att någon fälla aktiveras

  • Avlägsna nätverkskabel:Ett alternativ när det är bråttom.

  • Konsekvens: Det kan finnas risk att någon fälla aktiveras.

  • Stänga ner systemet på ett normalt sätt: Det kanske inte alltid är möjligt att stänga ner systemet.

  • Konsekvens: Det kan finnas risk att någon fälla aktiveras.

  • Stänga ner systemet abrupt - dra ur elkabel: Ett alternativ att ta till vid tillfällen då det är ytterst bråttom att avbryta incidenten.

    • Här hinner ingen fälla aktiveras

  • Konsekvens: Det finns risk att hårdvara skadas, t,ex, hårddiskar

Olika kommandon för att isolera systemet

Montera och kör nedanstående kommandon direkt från forensik-CD:n

Stoppa nätverksprocess

I vissa fall är det bra att på ett enkelt sätt kunna stoppa en ovanlig nätverkssession som inte bör finnas mot systemet. Det finns vanligtvis inbyggda kommandon för att göra det på ett enkelt sätt.

  • Win:

    • c:/> netstat -ano

    • c:/> taskkill /pid PID

      • *

  • Linux/Unix:

    • $ lsof -i tcp

    • $ kill -9 PID

Stänga av nätverkskort

Är ett sätt att avlägsna systemet från nätverket utan dra ur TP-kabel (i vissa fall finns det ingen fysisk åtkomst till systemet)

  • Win:

    • c:\> netsh interface disable interface name=”IF-STRÄNG”

      • *

  • Linux/Unix:

    • $ ifconfig eth0 down

Blockera IP-adress via routing

Ett alternativ för att blockera en IP-adress är via routing, nedan visas några kommandon.

  • Win:

    • c:\>route add “IP-adress” 127.0.0.1 metric 1

      • *

  • Linux/Unix:

    • $ route add -host “IP-adress” reject

    • $ ip route add blackhole “IP-adress”

Insamling av data från ett isolerat system

Efter isolering av systemet är det dags att samla in data.

Vid insamling av data/bevis så det av största vikt att logga allting som incidenthanteraren gör. Det kan vara så enkelt som att föra en loggbok där man för in klockslag för t.ex. telefonsamtal eller tidpunkter då insamlingen börjar och så vidare.

Insamling av data bör – för att underlätta hanteringen - i mesta möjliga mån ske automatiskt via skript eller programvaror. Det är väldigt tidskrävande att köra kommando för kommando.

Insamling av data bör ske utifrån en modell som kallas “Order of volatility” d.v.s. det data som har kortast livslängd bör samlas in först.

  1. Internminne

  2. “Swap”-filer, “page”-filer

  3. Nätverksprocesser

  4. Systemprocesser

  5. Filsystemsinformation

  6. Råa diskblock/cluster

Eftersom det ofta tar relativt lång tid att göra en forensisk spegelkopia av en hårddisk så kan det vara en bra idé – för att spara tid - att börja med att göra en spegelkopia och under tiden samla in flyktigt data.

Spegelkopia av hårddisk

Bland de första åtgärderna är att ta en spegelkopia på hårddisken. Vid bevisföring – för att försäkra sig om att inte påverka datat/informationen under analysen - så bör kopian tas på ett skrivskyddat media. Dessutom är det bra att ta en extra kopia på hårddisken (som backup) i ett rättsligt syfte – för att vara extra säker på ingen information har förändrats.

Diskspegling kan beroende på situationen antingen utföras på ett live-system eller på ett system som är bortkopplat från nätverket. Om det är möjligt så är det att föredra att göra spegelkopian från ett bortkopplat system p.g.a att det är minst risk att något oförutsett inträffar.

Det är även viktigt i de fall då insamling av bevis ska användas vid rättsliga åtgärder att skapa en så kallad “Chain Of Custody” (säkerhetskedja), d.v.s. föra en kronlogisk logg över hur bevismaterialet har hanterats, vilka som har haft tillgång till det, hur det har förvarats m.m.

Nedan beskrivs några olika metoder, även metoder som inte använder skrivskyddat media för spegling av hårddiskar, samt för- och nackdelar med dessa.

Diskspegling över nätverk

  • Fördelar – lämnar få spår på HD

  • Nackdelar – långsam överföring (beroende på hastigheten på nätverket)

    Några av de program som kan användas vid spegelkopiering av hårddisk över nätverk:

Diskspegling direkt via t.ex. USB, SCSI, SATA, IDE

  • Fördelar – snabb överföring

  • Nackdelar – lämnar spår i systemets loggar

    • Ewfacquire

Diskspegling med hårdvarulösningar (write blockers)

Diskspegling – exempel

Montera och kör nedanstående kommandon direkt från forensik-CD:n.

Generering checksummor för att säkra integritet av data på diskkopian

Det är av största vikt att generera checksummor på hela diskkopian, detta för att försäkra sig om att data inte har förändrats sedan spegelkopian togs.

Checksummorna tas på nedtagna system. Om checksummor tas på levande system så förändras de eftersom systemet förändras. Systemet måste frysas innan checksummor genereras för att kunna jämföras med andra kopior av hårddisken.

Vill organisationen känna sig extra säker är det bra att använda flera olika hash-funktioner vid generering av checksummor, t.ex., md5 och SHA1.

Några vanliga program för att generera checksummor (hashar) är:

  • md5

  • md5sum

  • md5deep

  • sha1sum

  • sha1deep

  • sha256sum

  • sha256deep

Beroende på vad organisationen vill veta kan checksummor genereras på flera sätt. Nedan beskrivs hur checksummor genereras från en spegelkopia av en hårddisk. I en del fall kan checksummor genereras rekursivt för alla filer under vissa partitioner, t.ex., /bin, /usr/bin, vilket inte beskrivs här nedan. I vissa fall är det intressant att jämföra checksummor på installerade binärer mot t.ex. CD:n de installerades ifrån. Här måste även hänsyn tas till eventuella uppdateringar (patchar, servicepack) som är installerade på systemet.

I exemplet nedan utgår vi ifrån att filerna med diskkopiorna heter linux.iso samt window.iso.

Vi börjar med att som root montera iso-filerna på den externa arbetsstationen som i det här fallet är en linux-maskin.

  • $ mount -t ext3 -o loop /incident/linux.iso /mnt/forensic/linux

  • $ mount -t ntfs -o loop /incident/windows.iso /mnt/forensic/windows

Generering av checksummor på hela diskkopian:

Linux/Unix:

  • $ md5 /mnt/forensic/linux

  • $ sha1sum /mnt/forensic/linux

Windows:

  • $ md5 /mnt/forensic/windows

  • $ sha1sum /mnt/forensic/windows

Insamling av data

Det här avsnittet har redan beskrivits i delprocessen identifiera - insamlingen av den här informationen borde redan gjorts under delprocessen identifiera. I de fall då datainsamlingen inte redan är gjord så är det dags nu.

Flyktigt data är den typen av information som försvinner om systemet måste startas om - t.ex. data som finns i minnet, i form av systemprocesser, öppna filer, nätverksprocesser m.m.

Insamlingen av flyktigt data görs medan systemet fortfarande är uppe, och helst innan systemet är isolerat, då en del flyktigt data som t.ex. nätverksprocesser försvinner om systemet kopplas bort från nätverk.

CERT-SE har valt att samla in data enligt följande ordning:

  • Nätverkstrafik (via sniffer) kan spelas in trafik under hela tiden incidenten pågår

  • Nätverksprocesser (flyktigt)

  • Systemprocesser och minne (flyktigt)

  • Öppna filer, registerinformation (flyktigt)

  • Ovanliga filer

  • Loggfiler

  • Konton och användare

  • Övriga ovanligheter

Nätverksprocesser

Finns det ovanliga nätverksuppkopplingar mot andra system?

Kontrollera om systemet lyssnar på ovanliga portar eller har nätverkssessioner mot ovanliga system på ovanliga portar.

  • Win:

    • c:\> netstat -ano (listar PID, öppna lyssnande portar samt pågående uppkopplingar mot andra system)

  • Linux/Unix:

    • $ netstat -anp (listar PID, program, öppna lyssnande portar samt pågående uppkopplingar mot andra system)

    • $ lsof -i tcp

Är det ovanligt många nätverksuppkopplingar eller hög nätverkslast på systemet?

För att leta efter indikationer på ett intrång är intressant att se om om nätverket är/har haft ovanligt mycket last under den senaste tiden.

  • Win:

    • c:\> netstat -s -p tcp

  • Linux/Unix:

    • $ netstat --statistics --tcp

    • $ netstat -m

Finns det några nya tjänster som lyssnar på ovanliga portar?

Andra indikationer på att något ovanligt är på gång är om systemet lyssnar på ovanliga portar som det annars inte lyssnar på.

  • Win:

    • c:\> netstat -an | findstr LISTEN

  • Linux/Unix:

    • $ netstat -l

    • $ netstat -an | grep LISTEN

Hur ser nätverks- och routingkonfigurationen ut på systemet?

Fler indikationer på ovanliga aktiviteter kan vara om routingtabeller och annan nätverkskonfiguration har ändrats.

  • Win:

    • c:\> ipconfig /all

    • c:\> route print

    • c:\> netstat -nr

    • c:\> arp -a

  • Linux/Unix:

    • $ ifconfig -a

    • $ route -n

    • $ netstat -nr

    • $ arp -a

Är något nätverkskort (som inte borde vara det) i ”promiscous mode”?

I vissa fall kan en angripare installera en sniffer på systemet för att fortsätta attacken mot andra system. Ett sätt att upptäcka det är att leta efter nätverkskort i lyssnande läge.

  • Win:

  • Linux/Unix:

    • $ dmesg |grep -i promisc

    • $ grep -i promisc /var/log/messages

Systemprocesser och minne

Finns det några ovanliga processer och tjänster i systemet?

Andra indikationer på ett intrång är att ovanliga processer är startade på systemet (för att ha en uppfattning bör organisationen ha gjort en ”base line” på sina system.

  • Win:

    • c:\> wmic process list full

    • c:\> net stat

    • c:\> tasklist /svc

    • c:\> tasklist -m

  • Linux/Unix:

    • $ ps aux

    • $ ps -ef

Använder systemet ovanligt mycket minne?

Om systemet använder ovanligt mycket minne kan det vara en indikation på ett intrång.

  • Win:

    • c:\> taskmgr.exe

  • Linux/Unix:

    • $ free

    • $ vmstat

Har systemet ovanligt hög CPU-last?

Även ovanligt hög CPU-last kan vara en indikation på ett intrång.

  • Win:

    • c:\> taskmgr.exe (taskmgr.exe finns inte på HELIX Live-CD, fins installerat på XP samt Server 2003)

  • Linux/Unix:

    • $ top

    • $ vmstat

    • $ uptime

Insamling av fysiskt och virtuellt minne

Det är viktigt att så snabbt som möjligt samla in det fysiska och virtuella minnet från systemet. I dagens läge finns det vissa typer av rootkit som endast arbetar i minnet och inte installeras på systemet.

För minnesdumpar på Linux så gäller att vissa distributioner har patchat kärnan så att det inte går att få ut mer än ca. 1Mb från minnet vid en dump, bland annat RedHat, Fedora och senare versioner av Ubuntu.

För minnesdumpar på Windows så gäller de metoder som beskrivs nedan på Windows 2000, XP (före SP3), Windows server 2003 (före SP 1)

Skapa spegelkopia på fysiskt samt virtuellt minne

Linux:

Kommando på källmaskinen:

  • $ dd if=/dev/mem | nc 192.168.1.1 31337

  • $ dd if=/dev/kmem | nc 192.168.1.1 31337

Kommando på målmaskinen 192.168.1.1:

  • $ nc -l -p 31337 | dd of=/tmp/mem.dmp

  • $ nc -l -p 31337 | dd of=/tmp/kmem.dmp

Verktyg för minnesanalys och -kopering:

Windows:

Kommando på källmaskinen:

  • c:\> dd if=\\.\PhysicalMemory |nc 192.168.1.1 31337

Kommando på målmaskinen (192.168.1.1):

  • $ nc -l -p 31337 | dd of=/tmp/PhysicalMemory.dmp

Verktyg:

SWAP eller Pagefile

Linux:

Först ta reda på var "swap"-partitionen finns:

  • $ cat /etc/fstab

Output:

# /etc/fstab: static file system information.

#

# <file system> <mount point> <type> <options> <dump> <pass>

proc /proc proc defaults 0 0

# /dev/sda1

UUID=eb9af6a2-a2ec-49e3-8a3c-1f66584ae298 / ext3 defaults,errors=remount-ro 0 1

# /dev/sda5

UUID=990cb051-fad9-4093-9094-4dddede6bfc9 none swap sw 0 0

/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec 0 0

/dev/scd0 /media/floppy0 auto rw,user,noauto,exec 0 0

Kommando på källmaskin:

  • $ dd if=/dev/sda5 |nc 192.168.1.1 31337

Kommando på målmaskin (192.168.1.1):

  • $ nc -l -p 31337 | dd of=/tmp/swap.dmp

Windows:

Kommando på källmaskin:

  • c:\> dd if=c:\pagefile.sys | nc 192.168.1.1 31337

Kommando på målmaskin (192.168.1.1):

  • $ nc -l -p 31337 | dd of=/tmp/pagefile.dmp

Öppna samt ovanliga filer

Vilka öppna filer finns på systemet?

Öppna filer kan visa på ovanligheter i systemet, eventuella processer använda dessa för att hämta information eller konfiguration.

  • Win:

    • c:\> openfiles /query /v (Programmet är inte installerat som standard, det måste initieras med kommandot: c:\>** openfiles /local on - som kräver omstart, vilket inte är att rekommendera vid en situation, programmet finns inte på HELIX Live-CD)

  • Linux/Unix:

    • $ lsof

Finns det några nya ovanliga filer i systemet?

Här söks efter filer med ovanliga rättigheter, funktioner eller storlek, vilka kan gen en indikation på att något inte står rätt till.

  • Win:

    • c:\> dir /A c:\

  • Linux/Unix:

    • $ find / -uid 0 -perm -400 -print

    • $ find / -size +10000k -print $ lsof +L1 $ find / -name ” ” -print

    • $ find / -regex '.+[\^A-Za-z0-9(+=_-/.,!@#$%\^&*\~:;)]' -print

Finns det ovanliga utdelningar av filer eller andra resurser?

Leta efter ovanliga utdelade resurser för att se vem som har en session mot systemet.

  • Win:

    • c:\> net view

    • c:\> net use

    • c:\> net session

  • Linux/Unix:

    • $ rpcinfo -p ”datornamn”

Finns det nya ovanliga program som startas automatiskt i systemet?

Här är det intressant att se om några ovanliga program startas automatiskt på systemet, många trojaner startas automatiskt via registret eller rc-script.

  • Win:

    • c:\> wmic startup list full

    • c:\> wmic startup list brief| find /i ”hklm”

    • c:\> regedit (Leta efter referenser till ovanliga program under registernycklarna):

HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_USERS\.DEFAULT

  • \Software\Microsoft\Windows\CurrentVersion\Run

\Software\Microsoft\Windows\CurrentVersion\RunOnce

  • \Software\Microsoft\Windows\CurrentVersion\RunOnceEx

  • \Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

  • \Software\Microsoft\WndowsNT\CurrentVersion\Winlogon

Linux/Unix:

  • $ ls /etc/rc*.d

Är DNS-information eller hosts-filen ändrad?

Det är lätt att kontrollera host-filen för att se om DNS-konfigurationen är förvanskad, det kan vara en indikation på oönskade aktiviteter.

  • Win:

    • c:\> more c:\windows\system32\drivers\etc\hosts

    • c:\> ipconfig /displaydns

  • Linux/Unix:

    • $ more /etc/hosts

    • $ more /etc/resolv.conf

Insamling av Loggfiler

Finns det några ovanliga loggposter i systemet, är några loggar raderade?

Här letar vi efter suspekta händelser, t.ex. om maskinen blivit omstartad, om några ny tjänster startats, om några tjänster/funktioner stoppats, massor av felaktiga inloggningsförsök m.m.

  • Win:

    • c:\> eventvwr.msc (leta efter suspekta meddelanden som: ”event log service was stopped”)

  • Linux/Unix:

    • $ ls -la /var/log

    • $ cat /var/log/messages

    • $ cat /var/log/syslog

Konton och användare

Finns det nytillagda användare och grupper i systemet?

Det är inte helt ovanligt vid ett intrång att det skapas nya användare och grupper med starka behörigheter för att en angripare ska kunna logga in på systemet åter igen. Här letar vi efter ovanliga användare och grupper

  • Win:

    • c:\> lusermgr.msc (lusermanager finns inte på HELIX Live-CD, fins installerat på XP samt Server 2003)

    • c:\> net users

    • c:\> net localgroup administrators

    • c:\> net group administrators(leta efter nya användare i administratorgruppen eller nytillagda användare med SID 500)

  • Linux/Unix:

    • $ cat /etc/passwd

    • $ cat /etc/group

    • $ grep :0: /etc/passwd (leta efter användare med UID 0 eller användare i root-gruppen)

Övriga ovanligheter

Är några säkerhetsfunktioner (som bör vara startade) inaktiverade på systemet, t.ex. AV, FW, HIDS, loggning, uppdateringar?

Det är viktigt att kontrollera om säkerhetsfunktioner är avstängda, det kan vara en ganska stark indikation på suspekta aktiviteter på systemet.

  • Win:

    • c:\> control.exe→ security center (kontrollera FW, AV, automatiska uppdateringar)

    • c:\> services.msc → event log (kontrollera om logg-tjänsten är startad)

  • Linux/Unix: (beror på unix-dialekt)

    • Linux iptables:$ iptables -L -n

Finns det nya ovanliga schemalagda jobb i systemet?

Här kan det finnas ovanliga schemalagda aktiviteter som körs regelbundet på systemet, t.ex. leylogger-information som FTP:as någontans.

  • Win:

    • c:\> at

    • c:\> schtasks (leta speciellt efter aktiviteter som körs som SYSTEM eller utan användarnamn)

  • Linux/Unix:

    • $ crontab -u root -l

    • $ more /etc/crontab

    • $ at

Lista användares inloggning- samt kommandohistorik

Det går att hitta ganska mycket intressant information genom att titta på kommandohistorik, t.ex. går det att se om en användare har installerat eller tagit bort program, startat sniffers, kompilerat program eller laddat ner suspekta filer.

  • Win:

    • Vet inte om det finns någon liknande funktion i Windows

  • Linux/Unix:

    • $ last

    • $ who

    • $ more /root/.bash_history

Har systemet nyligen startats om?

En annan indikation på att något ovanligt har sket är om systemet har startats om utan att det det har planerats.

  • Win:

    • c:\ net stats srv (leta efter raden: Stitstics since...)

  • Linux/Unix:

    • $ uptime

Ta fram en tidslinje från systemet (MAC-times)

Det är väldigt viktigt - för att kunna fastställa vad som har skett i systemet under en tid – att sammanställa tidstämplar från systemhändelser som t.ex. ändrade filer, nya filer, raderade filer till en tidlinje som kan följas. Tidslinjen är av största vikt för att spåra misstänkta händelser.

Att skapa en tidlinje är vanligen en tvåstegsprocess. För skapas en så kallad “body file” som innehåller temporärt data som t.ex.: filsystem, registerinformation, loggar vilket sparas ned i ett “body file”-format. För att göra detta kan man änvända verktyget fls som ingår i TSK.

Nedan visas exempel på insamling från ett Windows-system med en partition som startar på offset sector 63:

$ fls -o 63 -f windows -m / -r images/win-disk.dd > body.txt

Här ett exempel på ett Linuxsystem med två paritioner (den första startar på offset sector 63 den andra på offset sector 3233664:

$ fls -o 63 -f linux -m / -r images/lin-disk.dd > body.txt

$ fls -o 3233664 -f linux -m /var/ -r images/lin-disk.dd >> body.txt

Nåsta steg är att skapa en tidslinje utifrån datat som verktyget fls har genererat. Detta kan göras med verktyget mactime även det en del av TSK.

Nedan visas ett exempel som läser body.txt och tar fram all aktivitet i filsystemet sedan 2008-03-01

$ mactime -b body.txt 2002-03-01 > tl.2008-03-01.txt

Det finns även möjligheter att skapa en summerad indexfil vilken kan importeras i ett kalkylblad och grafas för att enklare se misstänkta händelser:

$ mactime -b body.txt -d -i hour data/tl-hour-sum.txt > timeline.txt

Insamling av loggar

För att få en god helhetsbild av situationen och detektera eventuella rootkit så är det – som redan nämnts - viktigt att så tidigt som möjligt sätta upp en nätverkssniffer och spela in trafiken för att se om det finns någon trafik mot systemet som systemet själv inte kan logga.

Andra loggar som bör samlas in (om de finns att tillgå):

  • Brandväggsloggar

  • IDS-loggar

  • IPS-loggar

  • Systemloggar

  • Routerloggar

Analys av systemet

Det är viktigt att avgöra vad som ska analyseras och varför. Det kan annars vara lätt att göra samma analyser om och om igen.

Analys av systemets tillstånd.

Det är viktigt att analysera systemets tillstånd för att upptäcka vilka sårbarheter som systemet innehåller. Detta för att kunna rensa eller installera om systemet och undvika att det tas i drift med samma brister som tidigare utnyttjats.

  • Vilka patchar är installerade på systemet? Det är bra att veta för att kunna ta reda på vilka sårbarheter som eventuellt kan finnas i systemet. Saknas nya säkerhetsuppdateringar som rättar till tidigare sårbarheter i operativsystemet eller programvaror?

  • Hur tog angriparen sig in i systemet? Om något i systemet har förändrats. Finns det bakdörrar eller försvarsmekanismer mot analyser eller forensiska undersökningar i systemet?

  • Användning av sårbarhetsscanner?Om organisationen tillåter (detta kommer att påverka systemets tillstånd, det vill säga allt som görs kommer att loggas i systemet) - för att upptäcka eventuella sårbarheter som kan ha utnyttjats för intrånget i systemet.

Analys av insamlat data

Vid analysen så är det samma data som samlats in som kommer att analyseras. Analysen kan antingen göras manuellt (väldigt tidskrävande) eller med hjälp av verktyg så som: SleuthKit, EnCase, TSK m.fl. (se mer under rekommendationer).

Det kan vara en god idé att använda sig av en checklista vid analysen för att undvika att något missas eller glöms bort.

Det data som analyseras är samma data som samlats in tidigare:

  • Minne, nätverksprocesser/-uppkopplingar, systemprocesser, registerinformation, öppna filer, tidslinjer (MAC times)

  • Filer, cluster, slackspace, alternativa dataströmmar (ADS)

  • Söka efter installerade program (rootkits)

  • Analys av lokala loggar

  • Analys av nätverksloggar

  • Filsystem

Analys av koden (binären)

Analys av binären/koden - om någon sådan använts för att angripa systemet. Vad gör den?, Hur beter den sig?, Varifrån kommer den?, Vem har tillverkat den?

Det är många frågor som kan besvaras genom en analys av koden. En sådan analys kan också hjälpa till att avgöra om angreppet är riktat mot organisationen.

En organisation kan få fram mycket data ur en enkel kodanalys. En del av den informationen kan hjälpa till i en utredning för att få fast förövaren.

Några olika sätt att göra det på kan vara:

Insamling och analys av data som kan knytas till förövaren

I ett angripet system kan det finnas information som kan knytas till angriparen. Den information som kan förekomma i ett system kan vara av typen:

  • IP-adresser

  • E-postadress

  • Domännamn

  • Eventuellt “hacker handle” (alias)

  • Speciella verktyg, eller script som planterats i systemet

  • Binärer – trojaner eller annan kod som körs på systemet

Sådan information kan upptäckas i systemet, bland annat i: nätverksloggar, systemloggar, analys av binärer och filer m.m. Genom analys av sådan information kan organisationen få fram information som kan användas för att få fast förövaren.

För mer information om hjälp med att begränsa eller avbryta angreppet se CERT-SE:s dokument Notice & Takedown.

Sökning efter information om förövaren

För att hitta information utifrån det data som insamlats så kan organisationen använda ett flertal standardverktyg för uppslag av information. En del lokala på det egna systemet och andra befintliga på Internet.

För att slå upp en IP-adress och knyta den till land och leverantör kan följande kommandon användas.

  • $ whois -h whois.cymru.com “-v -o -z IP-ADRESS”

  • $ whois -h whois.pwhois.com “IP-ADRESS”

För att leta ägare till nät:

  • $ whois -h whois.ripe.net IP-ADRESS
  • $ whois -h whois.arin.net IP-ADRESS
  • $ whois -h whois.apnic.net IP-ADRESS

För att ta reda på routinginformation till IP-adressen:

  • $ traceroute -w 2 IP-ADRESS

För information om domännamn:

  • $ dig -x IP-ADRESS

För information om IP-adresser med flera tidigare domännamn kopplade till sig

Organisationen kan använda sig av “Passive-DNS” för att se om en IP-adress har haft fler domännamn kopplade till sig.

http://cert.uni-stuttgart.de/stats/dns-replication.php

http://www.bfk.de/bfk_dnslogger.html

För att hitta samlad information kring en IP-adress

http://www.robtex.com

För att hitta ansvarig för registrering av toppdomäner:

  • $ whois -h whois.iana.org .TOPPDOMÄN (t.ex. .se)

I vissa fall kan en scanning av förövarens IP-adress ge infomation som kan komma till nytta för en undersökning.

Det måste påpekas att det i många fall kan vara förbjudet enligt organisationens IT-säkerhetspolicy och måste därför alltid först förankras hos organisationen. Det kan också eventuellt vara olagligt i andra länder.

Scanningar av alla portar på förövarens IP-adress:

$ nmap -P0 -p1-65535

För att följa annan information är sökmotorer på Internet en ovärderlig källa till information. Till exempel: sökningar på e-postadresser, “hacker-handles”, eller textsträngar som plockats ut från binärer ge ganska bra information som kan användas för vidare efterforskningar.

Polisanmälan eller egen utredning

En organisation som bedömt att det finns anledning att utreda vem eller vilka som har orsakat en incident bör ställa sig ett antal frågor innan man går vidare.

  • Är händelsen polisanmäld eller ska den polisanmälas?

    • Vilken typ av brott kan det röra sig om? Idag krävs det misstanke om brott som kan ge fängelse i två år eller mer för att polis ska kunna begära ut uppgifter från en ISP.

  • Finns det skadeståndskrav att rikta mot en eventuell förövare?

  • Ska incidenten endast utredas internt inom organisationen?

    • Dessa frågor bör sedan ligga till grund för resten av utredningen. Om händelsen ska polisanmälas bör kontakt tas med polisen i ett så tidigt skede som möjligt för att underlätta utredningen.

Vid polisanmälan

  • Sammanställ den tillgängliga informationen rörande incidenten på ett tydligt och lättfattligt sätt, tänk på att det ska gå att förstå även för en lekman. Nödvändig teknisk bevisning (t.ex. loggar, källkod) kan lämnas med som bilagor.

  • Ange eventuella skadeståndsanspråk, men reservera er för att de kan ändras om ytterligare uppgifter framkommer.

  • Om det finns information som är känslig för organisationen, men viktig för utredningen, var tydligt med att ange detta för den ansvarige utredaren. Det är mycket viktigt att sådan information inte finns med som en del av förundersökningen eftersom den då kommer att bli en offentlig handling om det går till domstol.

  • Erbjud polisen hjälp med utredningen om det kan gynna den egna organisationen.

Egen utredning

  • De efterforskningar som en organisation kan genomföra utan hjälp av polis eller andra myndigheter är oftast begränsade till publika källor samt den interna data som finns tillgänglig inom organisationen. Innan en intern utredning startas måste ett klart direktiv ges från en chef eller avdelning som har mandat att ge det. Inom många organisationer krävs det också tillstånd från personalavdelning innan en undersökning som rör egna anställda genomförs.

  • Sökmotorer: Dokumentera alla sökningar som görs. Om möjligt, spara ner en lokal kopia av relevanta träffar.

Rekommendation programvaror och tekniker för att analysera situationen

  • Rekommendera att sätta upp en nätverkssniffer och spela in trafiken snarast möjligt

  • Rekommendera användande av pålitliga program (Incident Response Kit) för analys av systemet för att upptäcka en eventuell incident. (HELIX Live-CD

  • Rekommendera användning (i mesta möjliga mån) av redan installerade standardprogram för analys av systemet

Rekommendation av tredjeparts-program för att analys av systemet

Sårbarhetsscanners:

Verktyg för att analysera PCAP-filer:

Verktyg för att söka efter rootkits:

Verktyg för analys av minne:

Länkar

http://www.giac.org/resources/whitepaper/network/17.php

http://www.forensicswiki.org

http://www.e-fense.com/helix

http://www.sans.org/reading_room/special/index.php?id=forensicimaging

http://www.zeltser.com/reverse-malware-paper/

http://wiki.sleuthkit.org/

Volatile Systems

FATKit

Volatility Tumblelog

Push The Red Button

Computer ForensiK Blog

Windows Incident Response

Memoryze