När en incidentgrupp ska rekonstruera vad som hände under ett intrång räcker det sällan att läsa en enda logg. Händelser ligger utspridda i filsystem, webbläsarhistorik, registret, minnesutdrag och nätverksfångor, ofta med olika tidsformat och tidszoner. Timesketch, Googles öppen källkod-verktyg för kollaborativ tidslinjeanalys, löser just det problemet genom att samla alla händelser i ett sökbart, delat gränssnitt. I den här guiden installerar du Timesketch från grunden, matar in en tidslinje med Plaso och kör både Sigma-regler och automatiska analyzers för att hitta det som annars drunknar i brus.
Guiden är skriven för säkerhetsingenjörer och incidentresponders som redan känner till grunderna i digital forensik men vill ha en konkret, körbar installation istället för en teoretisk översikt. Vi utgår från version 20260630 av Timesketch, den senaste publicerade utgåvan enligt projektets sida på PyPI, och bygger ett komplett exempelprojekt steg för steg.
Du behöver inte vara expert på OpenSearch eller Celery för att följa guiden, men grundläggande erfarenhet av Docker och Linux-kommandoraden gör resan betydligt smidigare. Varje steg nedan går att köra på en enda server, och du kan alltid skala ut komponenterna separat senare om behovet växer. Målet är att du i slutet av artikeln ska ha en fungerande installation, en importerad tidslinje och minst en Sigma-regel som faktiskt producerar träffar, inte bara en teoretisk förståelse av hur Timesketch fungerar.
Vad är Timesketch och varför tidslinjeanalys avgör en utredning
Timesketch beskrivs av utvecklarna som en samarbetsplattform för forensisk tidslinjeanalys, byggd så att flera utredare kan arbeta i samma fall samtidigt. Det är inte ett verktyg som samlar in bevis självt. Istället tar Timesketch emot redan normaliserade händelser, oftast producerade av Plaso (vars kommandoradsverktyg kallas log2timeline.py), och indexerar dem i OpenSearch för sökning, filtrering, taggning och visualisering.
Arbetsflödet brukar se ut så här i praktiken. Du säkrar en diskbild eller ett minnesutdrag, kör Plaso mot bevismaterialet för att extrahera tidsstämplade artefakter, importerar resultatet till Timesketch och analyserar sedan händelserna tillsammans med kollegor i samma sketch. Styrkan ligger i att data från flera källor, till exempel filsystemsloggar, webbläsarhistorik och Windows-registret, hamnar i en enda tidslinje där mönster som annars är omöjliga att se för blotta ögat blir synliga.
Det kollaborativa inslaget är inte en bisak utan en central designprincip. En SOC med flera skift kan lämna över en pågående utredning mellan personer utan att förlora kontext, eftersom allt redan ligger sparat i samma sketch med kommentarer, taggar och sparade sökningar intakta. För en mindre organisation som bara har en eller två incidentresponders är fördelen istället att arbetet blir dokumenterat per automatik, vilket gör efterföljande granskning och rapportskrivning snabbare än om anteckningarna legat spridda i separata textfiler eller kalkylblad.
Timesketch skiljer sig från verktyg som samlar in bevis (Velociraptor, KAPE) eller gör djup filsystemsanalys (Autopsy) genom att fokusera uteslutande på det som händer efter insamlingen: att korrelera, söka och dokumentera. De tre lagren kompletterar varandra snarare än att konkurrera, vilket vi går igenom i detalj längre ner i artikeln.
Arkitekturen bakom Timesketch: fyra tjänster som samarbetar
Innan du installerar något är det värt att förstå vad som faktiskt startar när du skriver docker compose up. Timesketch är inte en enda applikation utan en liten samling tjänster som pratar med varandra, och att veta vilken tjänst som gör vad gör felsökningen mycket enklare senare. Enligt projektets egen utvecklardokumentation består en standardinstallation av webbapplikationen, en sökmotor, en relationsdatabas och ett kösystem för bakgrundsjobb.
OpenSearch är hjärtat i systemet. Alla importerade händelser, oavsett om de kommer från Plaso, en CSV-fil eller API-klienten, hamnar som dokument i OpenSearch-index, och det är också OpenSearch som gör sökningarna, filtreringarna och aggregationerna snabba även när en tidslinje innehåller miljoner rader. PostgreSQL håller istället reda på allt som inte är själva händelsedatan: användarkonton, vilka sketches som finns, behörigheter och kopplingen mellan en timeline och dess sketch.
Redis fungerar som kömotor för Celery-workers, som i sin tur är de processer som faktiskt kör analyzers och Sigma-matchningar i bakgrunden. När du klickar på “kör analyzer” i gränssnittet skickas jobbet till Redis, en ledig Celery-worker plockar upp det, bearbetar händelserna och skriver resultatet tillbaka till OpenSearch. Den här uppdelningen är medveten: tunga analysjobb ska aldrig blockera webbgränssnittet för andra användare som samtidigt söker i samma sketch.
Det praktiska resultatet av den här arkitekturen är att du kan skala varje del för sig beroende på var flaskhalsen faktiskt ligger. Om sökningar känns långsamma är det nästan alltid OpenSearch som behöver mer minne eller fler noder. Om analyzers och Sigma-regler tar lång tid att köra klart är det istället antalet Celery-workers som är den intressanta vredet att vrida på, eftersom fler workers kan processa fler jobb parallellt utan att själva webbapplikationen eller databasen behöver röras alls.
Förutsättningar och versioner innan du börjar
Innan du sätter igång behöver du en Linux-server eller en virtuell maskin med tillräckliga resurser. Timesketch-projektet pekar ut Docker som den officiellt stödda utvecklings- och driftsmiljön, så hela installationen nedan bygger på Docker Compose. Tabellen sammanfattar vad du behöver ha klart innan steg 1.
| Komponent | Version / krav | Syfte |
|---|---|---|
| Timesketch | 20260630 (senaste release) | Webbgränssnitt, API och analysmotor |
| Docker Engine | 24.x eller senare | Kör containerstacken |
| Docker Compose | v2-plugin (docker compose) | Orkestrerar tjänsterna |
| Plaso / log2timeline | senaste paketerade version, kontrolleras separat vid installation | Extraherar och normaliserar tidsstämplade artefakter |
| OpenSearch | ingår i Docker-stacken | Lagring och sökning av händelser |
| PostgreSQL | ingår i Docker-stacken | Metadata, användare och sketches |
| Redis | ingår i Docker-stacken | Köhantering för Celery-workers |
| RAM (minimum) | 8 GB | Grundkörning i testmiljö |
| RAM (rekommenderat) | 16 GB eller mer | OpenSearch-indexering vid större tidslinjer |
RAM-rekommendationen på 16 GB kommer från en tredjepartsanalys av Timesketch-driftsättningen och ska inte läsas som en officiell lägstanivå. Hur mycket minne och disk du faktiskt behöver beror på antal händelser, hur många tidslinjer som körs parallellt och hur länge du sparar data i OpenSearch. Ett labb med en enda testtidslinje klarar sig gott och väl på 8 GB, medan ett team som importerar flera incidenter samtidigt bör räkna med betydligt mer.
Steg 1-3: Installera Docker, hämta release 20260630 och förbered miljön
Första steget är att se till att Docker och Docker Compose-pluginet finns installerat på servern. På en färsk Ubuntu- eller Debian-maskin installerar du dem via det officiella Docker-förrådet. När det är klart klonar du själva Timesketch-repot och använder projektets egna installationsskript för att hämta rätt konfiguration till release 20260630.
# Steg 1: verifiera att Docker och Compose-pluginet finns
docker --version
docker compose version
# Steg 2: klona Timesketch och gå in i katalogen
git clone https://github.com/google/timesketch.git
cd timesketch
# Steg 3: hämta release-konfiguration via projektets deploy-skript
curl -s https://raw.githubusercontent.com/google/timesketch/master/contrib/deploy_timesketch.sh -o deploy_timesketch.sh
chmod +x deploy_timesketch.sh
./deploy_timesketch.shSkriptet laddar ner docker-compose.yml, config.env och ett par konfigurationsfiler, bland annat timesketch.conf, tags.yaml och mappningar för Plaso-fält. Öppna config.env och sätt egna lösenord för PostgreSQL och det initiala administratörskontot innan du går vidare. Kopiera aldrig lösenord rakt av från en gammal guide eftersom variabelnamn och standardvärden ändras mellan releaser.
Om du är ovan vid Docker Compose-syntaxen i sig är det värt att läsa igenom Dockers officiella Compose-dokumentation innan du börjar ändra i filerna. Den vanligaste nybörjarmissen är att ändra en porttilldelning eller ett volymnamn i docker-compose.yml utan att förstå att samma namn refereras av flera tjänster samtidigt, vilket kan göra att Celery-workers pekar mot fel Redis-instans eller att webbcontainern inte hittar sin databas.
Steg 4-5: Starta Docker Compose-stacken och skapa admin-konto
Med konfigurationen på plats är det tid att starta hela stacken. Timesketch-containern startar tillsammans med OpenSearch, PostgreSQL, Redis och ett antal Celery-workers som kör bakgrundsjobb, till exempel analyzers och Sigma-matchningar. Första uppstarten tar ofta några minuter eftersom OpenSearch behöver initiera sina index.
# Steg 4: starta containrarna i bakgrunden
docker compose up -d
# Kontrollera att alla tjänster är igång
docker compose ps
# Steg 5: skapa en admin-användare inuti timesketch-webbcontainern
docker compose exec timesketch-web tsctl create-user admin --password 'ByT-ett-starkt-losenord-2026'Logga sedan in på https://din-server:5000 (eller den port du satt i config.env) med kontot du precis skapade. Om sidan inte svarar, dubbelkolla att containern timesketch-web faktiskt är i status “running” med docker compose ps innan du letar efter brandväggsproblem.
Steg 6-7: Köra Plaso/log2timeline och extrahera en tidslinje
Timesketch i sig importerar inte råa diskbilder. Det jobbet gör Plaso, vars kommandoradsverktyg log2timeline.py går igenom en diskbild eller ett monterat filsystem och bygger en normaliserad händelseström, en så kallad Plaso storage-fil. Kör Plaso på en separat analysmaskin eller i en egen container, inte inuti Timesketch-stacken, för att hålla resursförbrukningen separerad.
# Steg 6: extrahera händelser från en diskbild till en Plaso storage-fil
log2timeline.py --storage-file utredning_2026.plaso /bevis/disk.E01
# Steg 7 (valfritt): konvertera storage-filen till CSV för snabb granskning
# Release 20260311 lade till stöd för Plaso event-filter direkt i importören
psteal.py --storage-file utredning_2026.plaso --output-format dynamic -w utredning_2026.csvBeroende på hur stor diskbilden är kan detta steg ta allt från minuter till flera timmar. Spara alltid originalfilerna separat från arbetskopian, och dokumentera exakt vilken Plaso-version du körde eftersom det blir relevant om du senare behöver reproducera resultatet inför en rättslig process.
Plaso bygger på ett system av parsers och plugins som vardera förstår ett specifikt artefaktformat, från webbläsarhistorik och Windows-registret till specifika loggformat för olika applikationer. Som standard försöker log2timeline.py identifiera och köra alla relevanta parsers automatiskt, men för stora avbilder går det att begränsa körningen till ett fåtal parsers med flaggan --parsers, vilket kan korta ner körtiden betydligt om du redan vet ungefär vilken typ av artefakt som är relevant för just den här incidenten.
Steg 8: Importera tidslinjen och skapa ditt första Sketch
I Timesketch-gränssnittet är en Sketch arbetsytan där du organiserar en eller flera tidslinjer, kommentarer och fynd för ett specifikt fall. Skapa en ny sketch, ge den ett namn som matchar ärendet (till exempel incidentnumret), och importera sedan din Plaso-fil direkt via webbgränssnittets uppladdningsfunktion eller via API-klienten.
# Import via Timesketch Python-klienten
from timesketch_import_client import importer
with importer.ImportStreamer() as streamer:
streamer.set_sketch_id(42)
streamer.set_timeline_name("utredning-2026-disk1")
streamer.add_file("utredning_2026.plaso")När importen är klar visas tidslinjen som en lista av händelser sorterad kronologiskt. Varje händelse har fält för källa, tidsstämpel, värdnamn, användare och den ursprungliga Plaso-meddelandetexten, vilket gör det möjligt att filtrera bort brus utan att förlora spårbarheten till originaldatan.
Steg 9-10: Sök, filtrera, tagga och köra Sigma-regler
Nästa steg handlar om att skala bort brus. Timesketch har ett sökfält som stödjer fritext och fältspecifika sökningar, och du kan spara en sökning som en vy som andra i teamet återanvänder. Tagga intressanta händelser direkt i listan, till exempel med etiketten “misstänkt” eller “bekräftad-ioc”, så att de dyker upp separat i en filtrerad vy senare.
En vanlig nybörjarmiss är att försöka läsa hela tidslinjen rad för rad från start. Med flera miljoner händelser i en enda importerad tidslinje är det i praktiken omöjligt och dessutom ett slöseri med tid. Ett bättre angreppssätt är att först avgränsa tidsfönstret till den period incidenten troligen inträffade, sedan filtrera på källa (till exempel bara registerhändelser eller bara webbläsarhistorik), och till sist växla mellan flera sparade vyer för att jämföra vad som hände på olika lager samtidigt.
Sigma-stöd har funnits i Timesketch sedan tidigt 2020 och fungerar genom att regler skrivna i Sigma-formatet översätts till OpenSearch-frågor och sedan taggar matchande händelser automatiskt. Varje regel körs som ett eget Celery-jobb, och enligt den officiella dokumentationen måste regelns status vara satt till “stable” för att analyzern ska bearbeta den. Projektet är tydligt med att Sigma-stödet fortfarande räknas som alfa-funktionalitet med kända prestandabegränsningar, så lita inte blint på att en regel täcker exakt samma logik som i en fullvärdig SIEM.
# Exempel på en enkel Sigma-regel för misstänkt PowerShell-nedladdning
title: Misstänkt PowerShell-nedladdning
status: stable
logsource:
category: process_creation
product: windows
detection:
selection:
CommandLine|contains:
- 'DownloadString'
- 'IEX'
condition: selection
level: highLadda upp regeln via webbgränssnittet eller API-klienten och kör Sigma-analyzern mot din tidslinje. Matchande händelser får automatiskt en tagg kopplad till regelns namn, vilket gör det enkelt att snabbt filtrera fram alla träffar i en stor tidslinje med tiotusentals rader.
Steg 11-12: Analyzers och aggregationer för automatisk analys
Analyzers är Python-skrivna bakgrundskomponenter som anrikar tidslinjedata automatiskt. Koden ligger under timesketch/lib/analyzers i källkoden och körs asynkront via Celery-workers, samma system som hanterar Sigma-matchningen. En analyzer kan till exempel slå upp kända skadliga hashvärden, identifiera ovanliga inloggningstider eller gruppera händelser efter värdnamn och lägga på taggar automatiskt utan att du manuellt behöver gå igenom varje rad.
Aggregationer är det andra verktyget för att hitta mönster i stora mängder data. Istället för att läsa rad för rad kan du aggregera tidslinjen på ett fält, till exempel källa, användare eller värdnamn, och se var aktiviteten koncentreras. Det är ofta aggregationen, inte en enskild rad, som avslöjar att en specifik tjänst startat om onormalt många gånger under en kort period, vilket i sin tur pekar mot var du bör gräva djupare.
# Köra en Sigma-analyzer och en aggregation via API-klienten
from timesketch_api_client import client
ts = client.TimesketchApi("https://din-server:5000", "admin", "ByT-ett-starkt-losenord-2026")
sketch = ts.get_sketch(42)
# Starta Sigma-analyzern mot en specifik tidslinje
sketch.run_analyzer("sigma", timeline_id=1)
# Aggregera händelser per värdnamn för att hitta hotspots
agg = sketch.aggregation.from_aggregator_name("field_bucket")
agg.run_aggregator(parameters={"field": "hostname", "limit": "20"})
print(agg.table)Steg 13: Dokumentera fynd med Stories
När analysen är klar behöver resultatet bli en läsbar rapport, inte bara en lista av taggade rader. Stories i Timesketch är sparade utredningsberättelser där du vävar in utvalda händelser, kommentarer, sparade vyer och grafer i en sammanhängande text direkt i gränssnittet. Det gör att nästa person som öppnar fallet kan följa samma resonemang som du gjorde, steg för steg, istället för att behöva gissa sig till hur slutsatsen drogs.
Bygg en story genom att infoga sparade sökningar och specifika händelser i den löpande texten, komplettera med en kort sammanfattning längst upp, och dela sedan sketchen med övriga teammedlemmar som behöver granska arbetet innan det går vidare till ledning eller en extern part.
Timesketch jämfört med Autopsy, KAPE och Velociraptor
Det är lätt att blanda ihop Timesketch med andra DFIR-verktyg eftersom de ofta nämns i samma mening. Skillnaden ligger i var i kedjan varje verktyg gör sitt jobb. KAPE och Velociraptor samlar in bevis, Autopsy gör djup filsystemsanalys av en avbild, och Timesketch tar vid efter att data redan normaliserats och visar den som en gemensam, sökbar tidslinje flera personer kan analysera samtidigt.
| Verktyg | Huvudsyfte | Bäst lämpat för | Samarbete flera användare |
|---|---|---|---|
| Timesketch | Kollaborativ tidslinjeanalys av redan normaliserade händelser | Korrelera data från flera källor i ett delat gränssnitt | Ja, inbyggt i designen |
| Autopsy | Fullständig forensisk fallplattform | Djup filsystems- och artefaktanalys av en diskavbild | Begränsat |
| KAPE | Snabb insamling och riktad processning | Triage på Windows-system, ofta som förarbete till Plaso | Nej, lokalt verktyg |
| Velociraptor | Liveåtkomst och frågor mot endpoints i stor skala | Jakt och insamling över en hel flotta av maskiner | Ja, via server-klient-arkitektur |
I praktiken används verktygen ofta tillsammans i samma utredning. Velociraptor eller KAPE samlar in artefakter från berörda maskiner, Plaso normaliserar dem till ett gemensamt tidsstämpelformat, och Timesketch blir den gemensamma ytan där hela teamet analyserar resultatet och skriver den slutgiltiga rapporten. Om du redan driftsatt Velociraptor i miljön, som vi gått igenom i vår separata guide om endpoint-forensik med Velociraptor, blir Timesketch ett naturligt nästa lager ovanpå den insamlade datan.
Autopsy, byggt ovanpå The Sleuth Kit, löser ett annat problem än Timesketch. Där Timesketch förutsätter att data redan normaliserats till händelser låter Autopsy dig bläddra i rå filsystemsstruktur, återskapa raderade filer och köra moduler för specifika artefakttyper direkt mot avbilden. De två verktygen konkurrerar sällan om samma uppgift i en utredning, utan en erfaren utredare växlar mellan dem beroende på om frågan är “vad hände och när” (Timesketch) eller “vad finns faktiskt kvar på disken” (Autopsy).
Systemkrav, OpenSearch-stacken och skalning i produktion
Allt data i Timesketch lagras i OpenSearch, vilket betyder att prestanda och skalbarhet i praktiken är en OpenSearch-fråga snarare än en fråga om Timesketch-applikationen själv. Ju fler händelser och ju fler parallella tidslinjer, desto mer minne och disk-I/O behöver klustret. PostgreSQL håller reda på metadata som användare, sketches och behörigheter, medan Redis och Celery-workers hanterar köade jobb som analyzers och Sigma-körningar.
| Miljö | Antal händelser (ungefär) | Rekommenderad RAM | Kommentar |
|---|---|---|---|
| Labb / enskild utredare | Under 1 miljon | 8 GB | Räcker för en enstaka diskbild eller ett minnesutdrag |
| Litet team | 1-10 miljoner | 16 GB | Flera parallella tidslinjer och analyzers samtidigt |
| SOC / flera samtidiga incidenter | Över 10 miljoner | 32 GB eller mer, skala OpenSearch separat | Överväg dedikerade OpenSearch-noder utanför Compose-stacken |
För en enskild utredare räcker standardinstallationen gott och väl. Växer teamet och antalet parallella ärenden bör du flytta OpenSearch till en egen nod eller kluster utanför Docker Compose-stacken, eftersom en enda server annars blir en flaskhals både för indexering och sökhastighet samtidigt som flera utredare kör tunga aggregationer.
Ett vanligt mönster i större SOC-miljöer är att separera vilka tidslinjer som ligger “varma” och sökbara just nu från äldre, avslutade ärenden. OpenSearch stödjer index-livscykelhantering som gör det möjligt att flytta äldre index till billigare, långsammare lagring utan att radera dem helt, vilket håller kostnaden nere samtidigt som gamla utredningar fortfarande går att återöppna vid behov, till exempel om en ny incident visar sig kopplad till ett ärende från tidigare under året.
Personuppgifter i tidslinjer: vad svenska team bör tänka på
En forensisk tidslinje innehåller nästan alltid personuppgifter. Användarnamn, IP-adresser, e-postadresser och ibland filnamn med tydliga namn på anställda hamnar rakt in i OpenSearch-indexet så snart en Plaso-fil importeras. För svenska organisationer som omfattas av GDPR betyder det att en Timesketch-installation i praktiken är ett personuppgiftsbiträde i samma mening som ett SIEM eller en loggplattform, även om syftet är utredning snarare än övervakning.
Det praktiska rådet är att behandla varje sketch som en egen datapost med en tydlig livscykel. Sätt en rutin för hur länge en avslutad utredning får ligga kvar sökbar i OpenSearch innan den exporteras till kall lagring eller raderas helt, och dokumentera vem som haft åtkomst under fallets gång. Eftersom Timesketch inte har en inbyggd automatisk raderingspolicy för gamla sketches måste det hanteras manuellt eller via ett eget skript som kör mot API-klienten med jämna mellanrum.
Tänk också på var servern fysiskt eller molnmässigt står. En DFIR-server med känsliga personuppgifter från en pågående utredning bör följa samma krav på lagringsplats och åtkomstkontroll som övrig säkerhetsloggning i organisationen, oavsett om Timesketch körs on-premise eller i en molnmiljö.
Ett enkelt men ofta förbisett steg är att gå igenom vilka analyzers som faktiskt är aktiverade i din installation. Vissa tredjepartsanalyzers kan skicka data vidare till externa tjänster för uppslag, till exempel för att slå upp hashvärden eller IP-adresser mot ett externt API. Om en sådan analyzer är aktiverad skickas potentiellt känslig incidentdata ut ur din egen miljö, vilket bör godkännas medvetet snarare än lämnas som standardinställning efter en snabb installation.
Fem vanliga fallgropar att undvika
De flesta problem med en Timesketch-installation går att spåra tillbaka till ett av ett par vanliga misstag, oftast begångna av team som installerar verktyget för första gången under tidspress mitt i en pågående incident. Lär känna dessa fem fallgropar innan du står i den situationen, inte efter.
- Att köra Plaso inuti Timesketch-containern. Plaso-processning är CPU- och minnestung och konkurrerar direkt med OpenSearch om resurser. Kör den alltid på en separat maskin eller i en fristående container.
- Att lita blint på Sigma-regler som fullvärdig detektion. Projektet klassar själva Sigma-stödet som alfa-funktionalitet, vilket betyder att du bör behandla träffar som ledtrådar att undersöka, inte som bekräftade larm.
- Att glömma sätta regelstatus till “stable”. En Sigma-regel med fel status bearbetas helt enkelt inte av analyzern, och du får inget felmeddelande som varnar dig, bara tystnad.
- Att underskatta disk- och minnesbehovet för OpenSearch. En tidslinje med flera miljoner händelser kan tvinga fram omindexering om klustret är underdimensionerat från start, vilket kostar både tid och förtroende mitt i en pågående utredning.
- Att inte separera bevisfiler från arbetskopior. Kör alltid Plaso mot en kopia, aldrig mot originalbeviset, och dokumentera exakt vilken kommandorad och version som användes för spårbarhetens skull.
Felsökning: åtta problem och hur du löser dem
Oavsett hur noggrant du följer installationsstegen dyker det upp friktion förr eller senare, särskilt första gången du driftsätter verktyget på en ny server. Nedan är åtta problem som dyker upp regelbundet i Timesketch-installationer, i ungefär den ordning de brukar upptäckas.
- Webbgränssnittet svarar inte alls. Kontrollera att containern
timesketch-webhar status “running” meddocker compose psinnan du letar efter nätverks- eller brandväggsproblem. - Importen av Plaso-filen hänger sig. Kontrollera loggarna för Celery-workern med
docker compose logs timesketch-worker, importen körs asynkront i bakgrunden och kan ta lång tid för stora filer. - Sigma-regler ger inga träffar alls. Dubbelkolla att regelns
status-fält faktiskt är satt tillstable, analyzern hoppar tyst över allt annat. - OpenSearch-containern kraschar vid uppstart. Kontrollera att servern uppfyller minneskraven, OpenSearch kan sluta svara om den allokerade heap-storleken är för liten för datamängden.
- Admin-kontot går inte att skapa. Kör kommandot igen efter att ha väntat tills alla containrar rapporterar “healthy”, databasen måste vara klar innan
tsctlfungerar. - Analyzers startar aldrig. Kontrollera att Redis-containern körs, Celery-workers kan inte hämta jobb från kön om Redis är nere.
- Fält från Plaso visas inte i Timesketch. Sigma-fältmappningar och Timesketch-fält måste matcha, kontrollera konfigurationsfilen för fältmappningar om en kolumn verkar saknas helt.
- Inloggningen misslyckas trots rätt lösenord. Rensa webbläsarens cookies för domänen eller testa i inkognitoläge, en gammal sessionscookie från en tidigare installation kan blockera inloggningen.
Avancerade tips för team och produktionsdrift
När grundinstallationen fungerar finns några förbättringar som gör stor skillnad i en skarp utredning. Sätt upp separata sketches per incident istället för en enda stor arbetsyta, det gör det enklare att arkivera avslutade fall och hålla behörigheter uppdelade mellan team. Skriv egna analyzers för mönster som återkommer i din organisation, till exempel kända interna IP-intervall eller specifika tjänstekonton som aldrig bör logga in interaktivt, eftersom det sparar timmar jämfört med att manuellt filtrera varje gång.
Automatisera importen genom att låta insamlingsverktyget (KAPE eller Velociraptor) skicka Plaso-filer direkt till en kö som API-klienten plockar upp, så att utredare möts av en redan importerad tidslinje istället för att själva behöva köra kommandon manuellt varje gång nytt bevismaterial kommer in. Kombinera detta med en fast namnkonvention för sketches och timelines, till exempel incidentnummer plus datum, så att sökningar och rapportering blir konsekvent över hela teamet oavsett vem som satte upp fallet.
Skriv egna Sigma-regler utifrån det publika Sigma-regelbiblioteket som bas och justera fältmappningarna mot din egen miljö istället för att importera community-regler rakt av. Många organisationer bygger upp ett litet bibliotek av verifierade, “stable”-märkta regler som täcker just de tekniker som brukar dyka upp i deras egna incidenter, till exempel specifika verktyg för initial åtkomst eller lateral förflyttning som återkommer i branschen de verkar i.
Sätt också upp en tydlig rutin för vem som får radera eller arkivera en sketch. Eftersom PostgreSQL håller all behörighetslogik centralt är det enkelt att bjuda in fel person till ett känsligt ärende av misstag, och eftersom en sketch ofta innehåller personuppgifter och interna systemnamn bör åtkomst granskas med samma noggrannhet som för resten av incidenthanteringsprocessen.
Komplett exempelprojekt: från minnesutdrag till färdig rapport
Låt oss knyta ihop hela flödet i ett konkret exempel. Anta att en kollega misstänker att en arbetsstation komprometterats via en skadlig e-postbilaga. Så ser hela kedjan ut från bevis till rapport:
# 1. Extrahera tidslinje från en diskbild med Plaso
log2timeline.py --storage-file incident-4471.plaso /bevis/arbetsstation.E01
# 2. Importera till Timesketch via API-klienten
python3 - <<'EOF'
from timesketch_import_client import importer
with importer.ImportStreamer() as streamer:
streamer.set_sketch_id(7)
streamer.set_timeline_name("incident-4471-disk")
streamer.add_file("incident-4471.plaso")
EOF
# 3. Kor Sigma-analyzern mot den nya tidslinjen
python3 - <<'EOF'
from timesketch_api_client import client
ts = client.TimesketchApi("https://din-server:5000", "admin", "ByT-ett-starkt-losenord-2026")
sketch = ts.get_sketch(7)
sketch.run_analyzer("sigma", timeline_id=3)
EOF
# 4. Aggregera pa korda processer for att hitta hotspots
# (gors i webbgranssnittet under fliken Aggregation)
# 5. Bygg en Story med de taggade handelserna och dela sketchenResultatet är en sketch där taggade händelser visar exakt när bilagan öppnades, vilken process som startades därefter och vilka filer som skrevs till disk inom de följande minuterna. Sigma-regeln för misstänkt PowerShell-nedladdning fångar ofta det andra steget i en sådan kedja, medan aggregationen på värdnamn avslöjar om fler maskiner i nätverket visar samma mönster. Hela resonemanget dokumenteras i en Story som kan delas direkt med ledningen eller en extern utredare utan att behöva skriva om analysen i ett separat dokument.
Lägg märke till att hela kedjan ovan går att skripta från början till slut. Det är precis den egenskapen som gör Timesketch användbart i en incidentprocess med flera samtidiga ärenden, eftersom samma fem steg kan återanvändas som mall för nästa incident utan att en utredare behöver komma ihåg exakt vilka knappar som ska klickas i gränssnittet. Byt bara ut sketch-id, filnamn och vilken Sigma-regel som körs, och samma skript fungerar för nästa ärende.
Samma metodik fungerar lika bra för minnesforensik. Har du redan extraherat processer och nätverksanslutningar med ett verktyg som Volatility3, vilket vi beskriver i vår guide om minnesforensik med Volatility3, kan den datan normaliseras till samma tidslinjeformat och importeras bredvid diskdatan i samma sketch för en helhetsbild av incidenten.
Den här typen av arbete passar också naturligt in i ett större incidenthanteringsflöde. Många team kopplar Timesketch-sketchen till ett ärende i en plattform som TheHive, där tidslinjen blir underlaget till de observabler och den rapport som dokumenteras i själva ärendet. På samma sätt kan indikatorer som identifieras i en Timesketch-tidslinje delas vidare till andra team via en threat intel-plattform som MISP, så att nästa incident upptäcks snabbare. Behöver du även snabb insamling från en hel flotta av maskiner innan tidslinjeanalysen börjar, finns det i vår guide om fjärrforensik med GRR Rapid Response.
Poängen med hela exempelprojektet är att visa att Timesketch sällan står ensamt i en verklig utredning. Verktyget löser ett specifikt problem, att göra stora mängder tidsstämplad data sökbar och delbar, och gör det bra. Resten av kedjan, från insamling till slutlig rapport till ledningen, kräver att Timesketch pratar bra med grannverktygen i din DFIR-stack snarare än att försöka ersätta dem.
Vanliga frågor om Timesketch
Är Timesketch gratis att använda?
Ja. Timesketch är öppen källkod och utvecklas av Google på GitHub under en öppen licens, utan kostnad för att ladda ner, installera eller köra verktyget.
Måste jag använda Plaso tillsammans med Timesketch?
Plaso är det vanligaste sättet att producera tidslinjedata till Timesketch, men det är inte det enda. Timesketch kan ta emot data i andra strukturerade format också, så länge fälten går att mappa till de förväntade kolumnerna, men merparten av dokumentationen och exemplen utgår från Plaso-flödet.
Kan Timesketch ersätta en SIEM-lösning?
Nej. Timesketch är byggt för djupanalys av insamlade forensiska data i efterhand, inte för realtidsövervakning och larmhantering. Sigma-stödet gör det möjligt att återanvända detektionslogik från en SIEM, men projektet beskriver själv den funktionen som alfa-mognad med kända begränsningar. Se Timesketch som komplementet som tar vid efter att SIEM:en redan larmat, inte som en ersättning för den.
Hur många användare kan arbeta i samma sketch samtidigt?
Det finns ingen hård gräns inbyggd i applikationen. Den praktiska begränsningen sätts av hur mycket resurser OpenSearch-klustret har, eftersom varje sökning och aggregation flera användare kör samtidigt belastar samma backend.
Vad är skillnaden mellan en Timeline och en Sketch?
En Timeline är en importerad samling händelser, till exempel resultatet av en enskild Plaso-körning. En Sketch är arbetsytan där en eller flera Timelines samlas, analyseras och dokumenteras tillsammans för ett specifikt ärende.
Behöver jag köra Timesketch i Docker?
Docker är den officiellt stödda och dokumenterade driftsmiljön, och det är det sätt som beskrivs i projektets egna installationsskript. Det går i teorin att installera komponenterna manuellt, men du förlorar då den enkla, reproducerbara uppsättning som Docker Compose-filerna ger.
Är Sigma-regler i Timesketch identiska med Sigma-regler i en SIEM?
Logiken i själva regeln är densamma, men exekveringen skiljer sig. Timesketch kör varje regel som ett eget Celery-jobb mot redan indexerad historisk data, medan en SIEM oftast matchar regler mot strömmande realtidsdata. Fältmappningarna mellan Sigma och Timesketch måste också stämma för att en regel ska ge korrekta träffar.
Hur ofta uppdateras Timesketch?
Projektet har en hög releasetakt med flera utgåvor publicerade under 2026, bland annat 20260119, 20260311 och 20260630 enligt release-historiken på GitHub och PyPI. Det är därför värt att kontrollera senaste versionen innan en ny installation istället för att utgå från en tidigare guide.
