CyberStrikeAI-driftsättning: även enkla verktyg kräver omsorg om detaljerna

Jag har nyligen pysslat med CyberStrikeAI, en AI-nativ säkerhetstestplattform skriven i Go. Jag trodde att ”driftsättning med ett klick” bara var att klona och köra ett skript, men snubblade på några fallgropar av lagom storlek. Medan minnet är färskt antecknar jag hela processen – många av snubbelstenarna beror nämligen inte på verktyget, utan på detaljer man inte lagt märke till.

Vad är detta för verktyg

CyberStrikeAI profilerar sig som ett ”operativsystem för AI-nativ cybersäkerhet”, skrivet i Go, som samlar planering, utförande, mänsklig tillsyn, bevarande av bevis och uppspelning i en enda granskningsbar arbetsyta. Kärnkomponenterna inkluderar en Eino-driven agent, MCP-nativa verktyg, RAG-kunskapsbas, visuella arbetsflöden samt modellering och analys av attackkedjor.

Verktyget har över 100 inbyggda verktygsrecept som täcker hela dödskedjan: nätverksskanning med nmap, masscan och rustscan; webbskanning med sqlmap, nikto, gobuster och ffuf; sårbarhetsskanning med nuclei, wpscan och dalfox; dessutom subdomänuppräkning, API-säkerhet, containersäkerhet, molnsäkerhet, binäranalys, exploits, lösenordsknäckning, forensik, post-exploitation med mera. I princip allt du behöver för auktoriserad penetrationstestning är redan orkestrerat.

Dessutom finns ett Burp Suite-plugin och ett webbläsartillägg som låter dig skicka insamlad trafik direkt till plattformen för AI-assisterad analys. Den designen är smart – du slipper ändra ditt befintliga arbetsflöde.

Miljöförberedelser före driftsättning

Officiellt krävs två förutsättningar, och var noga med att inte hamna under versionsgränserna:

• Go 1.25+(versionen som uttryckligen krävs i go.mod – med äldre versioner misslyckas kompileringen direkt)
• Python 3.10+(krävs för vissa verktyg, till exempel api-fuzzer och http-framework-test)

Snubbelsten ett: Go-versionen. Jag använde första gången systemets gamla Go-version, och felet kom först vid kompileringen. Kontrollera därför först go version – räcker det inte, installera en ny version från den officiella webbplatsen. Sådana ”förutsättningar” är lättast att förbise, eftersom felet dyker upp långt senare.

Driftsättning med ett klick: vad skriptet egentligen gör

Det officiella kommandot för driftsättning med ett klick är enkelt:

git clone https://github.com/Ed1s0nZ/CyberStrikeAI.git
cd CyberStrikeAI
chmod +x run.sh && ./run.sh

Men run.sh gör mer än du tror – i tur och ordning:

• ✅ Kontrollerar och validerar Go- och Python-miljön
• ✅ Skapar en virtuell Python-miljö
• ✅ Installerar Python-beroenden
• ✅ Hämtar Go-beroenden
• ✅ Bygger projektet
• ✅ Startar tjänsten

Detalj ett: venv hanteras automatiskt av skriptet. Katalogen venv/ skapas och underhålls automatiskt av run.sh, och de verktyg som kräver Python (api-fuzzer, http-framework-test m.fl.) använder miljön automatiskt. Skapa den inte manuellt – då uppstår lätt konflikter.

Verifiera uppstarten: några saker som måste kontrolleras

När skriptet körts klart – öppna inte webbläsaren direkt, kolla terminalen först:

• Kontrollera att terminalen visar ● ONLINEföljt av den faktiska adressen till webbgränssnittet
• Öppna den adressen: standardläget HTTPS använder ett lokalt självsignerat certifikat och webbläsaren varnar – acceptera bara en gång
• En engångslösenord för administratören ges vid ny installation: terminalen visar den under ADMIN SETUP REQUIRED – byt omedelbart efter inloggning

Detalj två: HTTPS eller HTTP. run.sh startar som standard med parametern –https (lokal självsignerad TLS, officiellt anges att detta är vänligare mot samtidiga strömmar). Vill du ha ren HTTP måste du uttryckligen ange ./run.sh --http. Vid manuell start: lägg till –https eller sätt miljövariabeln CYBERSTRIKE_HTTPS=1.

I produktionsmiljö, använd inte självsignerade certifikat – konfigurera i stället server.tls_cert_path och server.tls_key_path i config.yaml.

Snubbelsten två: fel om protokoll som inte matchar. Ser du ”client sent an HTTP request to an HTTPS server” i loggarna använder någon klient fortfarande http:// mot TLS-porten. Ändra bara URL:en – blanda inte in serverkonfigurationen.

Första konfigurationen: AI-kanalen är obligatorisk

Utan detta steg är plattformen som oinstallerad. Efter första uppstarten, besök https://127.0.0.1:8080/ (porten styrs av server.port i config.yaml) och gå till System Settings → Basic Settings → AI Channel Configuration, lägg till en kanal och fyll i provider, Base URL, API-nyckel, modell och token-gräns.

Du kan också redigera config.yaml direkt; formatet ser ungefär ut så här:

ai:
default_channel: openai-main
channels:
openai-main:
provider: openai_compatible
api_key: “${OPENAI_API_KEY}”
base_url: “https://api.openai.com/v1”
model: “gpt-4o”

Detalj tre: räckvidden för standardkanalen. ai.default_channel används för nya sessioner och uppgifter utan uttryckligt kanalval; i chattvyn kan du dessutom välja valfri sparad kanal per session. Har du flera modeller behöver du alltså inte nöja dig med en.

Med provider satt till openai_compatible kan du ansluta de flesta tjänster med OpenAI-kompatibla gränssnitt: byt base_url till https://api.deepseek.com/v1 och model till deepseek-chat, och detsamma gäller qwen3-max. Kinesiska modeller ansluts utan om och men – det är en vänlig detalj.

⚠️ Säkerhetsvarning: lägg aldrig riktiga nycklar i config.yaml. Officiellt framhålls att riktiga autentiseringsuppgifter inte ska committas – använd miljövariabler i stället.

Även uppgradering kräver metod

En officiell uppgraderingsscript finns, men första gången måste du först ge den körbehörighet:

chmod +x upgrade.sh && ./upgrade.sh –yes

Den gör: säkerhetskopierar config.yaml och data/-katalogen → hämtar ny kod från GitHub Release → uppdaterar versionsnumret i config.yaml → startar om tjänsten.De lokala katalogerna tools/, roles/ och skills/ bevaras alltid– det är avgörande: dina egna verktygsrecept skrivs inte över.

Snubbelsten tre: uppgraderingsskriptets beroenden. Det kräver curl eller wget för att hämta Release-paketet, och rsync för säker kodsynkronisering (officiellt rekommenderat/krävt). Om GitHub API begränsar din trafik, gör först export GITHUB_TOKEN="..." och kör sedan igen.

Vid problem kan du återställa från .upgrade-backup/ eller manuellt kopiera tillbaka data och config.yaml och sedan köra run.sh.

Viktig princip: läs alltid release notes för målversionen före uppgradering, särskilt vid ändringar i konfiguration, databas eller API. Ett officiellt uttalande är träffande – ”säkerhetskopiering är ett måste, även vid enbart patchuppgraderingar; versionsnumret i sig är ingen garanti för kompatibilitet.”

Snabb överblick av katalogstrukturen

Förstår du vad varje katalog gör blir det lättare att inte gå vilse vid senare underhåll:

• cmd/ — server, MCP stdio-ingång, verktyg
• internal/ — agent, MCP-kärna, hanterare, C2, säker exekverare
• web/ — statisk SPA och mallar
• tools/ — YAML-verktygsrecept (över 100 exempel)
• roles/ — rollkonfigurationer (över 12 fördefinierade säkerhetstestroller)
• skills/ — katalog för agentfärdigheter (SKILL.md + valfria filer)
• agents/ — multi-agent Markdown (orchestrator.md + underagenter)
• config.yaml — runtime-konfiguration
• run.sh / upgrade.sh — start-/uppgraderingsskript

Säkerheten – det kan verktyget inte göra åt dig

Plattformen integrerar högriskförmågor som WebShell-hantering och inbyggd C2 (lyssnare, krypterade beacon, sessioner, uppgiftskö). Den officiella hållningen är entydig:använd den endast mot system du själv äger eller har uttrycklig tillåtelse att testa.

Innan du aktiverar högriskverktyg i delade eller produktionsmiljöer, läs alltid säkerhetsmodellen och härdningsguiden. Det finns dessutom inbyggd avlyssning av verktygsanrop – konfigurerbara regexkontroller före MCP-exekvering, med skydd av regeringsdomäner aktiverat som standard.

Tjänsten lyssnar dessutom bara på 127.0.0.1 som standard; vill du exponera den utåt, härda först. Det är inga tomma ord – det är en varning som bara någon som trampat i klaveret skriver in i dokumentationen.

Avslutningsvis

I efterhand gick själva driftsättningen utan större problem – skriptet gjorde redan 90 % av jobbet. Det som faktiskt fick mig att stanna och bläddra i dokumentationen var uteslutande detaljer jag ”inte lagt märke till”: Go-versionsgränsen, att venv inte får skapas manuellt, att HTTPS är påslaget som standard och orsakar protokollkrock, att uppgradering kräver säkerhetskopiering, att nycklar inte ska läggas i konfigurationen.

Var och en av dessa detaljer är enkel, men missar du en kan den ställa till det i en halvtimme. Ju mognare verktyget, desto större vinst av att ”läsa dokumentationen” – det kapslar in komplexiteten i skript, och den kvarvarande komplexiteten gömmer sig i konfigurationsdetaljerna.

Projektet har tagits upp i knownsec 404Starlink och är öppen källkod under Apache 2.0. Testa gärna om du gör auktoriserad säkerhetstestning.

Driftsättning med ett klick betyder inte förståelse med ett klick – detaljerna är det som verkligen sparar tid.

Projektadress: github.com/Ed1s0nZ/CyberStrikeAI (flyttad till github.com/AIPentest/CyberStrikeAI)
Miljökrav: Go 1.25+ / Python 3.10+
Licens: Apache License 2.0
⚠️ Endast för auktoriserad testning