CyberStrikeAI-implementeringsberetning: Også enkle værktøjsudrulninger kræver omtanke

Jeg har for nylig rodet med CyberStrikeAI, en AI-native sikkerhedstestplatform skrevet i Go. Jeg troede, “one-click-udrulning” bare ville være clone og kør et script, men jeg trådte i et par faldgruber af moderate dimensioner. Mens hukommelsen stadig er frisk, nedfælder jeg hele forløbet – mange faldgruber skyldes ikke værktøjet, men oversete detaljer.

Først: hvad er det for et værktøj?

CyberStrikeAI er positioneret som et “aktionssystem for AI-native cybersikkerhed”, skrevet i Go, og samler planlægning, eksekvering, menneskelig overvågning, bevaring af beviser og afspilning i en auditerbar arbejdsbænk. Kernekomponenterne omfatter en Eino-drevet agent, MCP-native værktøjer, en RAG-vidensbase, visuelle workflows samt modellering og analyse af angrebskæder.

Der er indbygget 100+ værktøjsopskrifter, der dækker hele kill chain: netværksscanning med nmap, masscan og rustscan; web-scanning med sqlmap, nikto, gobuster og ffuf; sårbarhedsscanning med nuclei, wpscan og dalfox; samt subdomæne-enumeration, API-sikkerhed, containersikkerhed, cloudsikkerhed, binæranalyse, exploitation, kodeknækning, forensics, post-exploitation med mere. Dybest set er alt det udstyr, man behøver til autoriseret pentest, allerede orkestreret for én.

Derudover er der en Burp Suite-plugin og en browserudvidelse, så opsnappe trafik kan sendes direkte til platformen til AI-assisteret analyse. Designet er ret smart – du behøver ikke ændre din nuværende arbejdsgang.

Miljøforberedelse før udrulningen

De officielle krav er to forudsætninger; vær opmærksom på ikke at ramme versionsgrænserne:

• Go 1.25+(den versionskrav, der eksplicit står i go.mod; lavere versioner fejler direkte ved kompilering)
• Python 3.10+(kræves af nogle værktøjer, fx api-fuzzer og http-framework-test)

Faldgrube nr. 1: Go-versionen. Jeg brugte første gang systemets ældre Go, og fejlen kom først ved kompilering. Tjek derfor først go version , og installér en ny version fra den officielle side, hvis den ikke rækker. Den slags “forudsætninger” overses lettest, fordi fejlen viser sig langt senere.

One-click-udrulning: hvad scriptet faktisk gør

Den officielle one-click-kommando er kortfattet:

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

Men run.sh gør mere, end man skulle tro; den udfører i rækkefølge:

• ✅ Tjekker og validerer Go- og Python-miljøet
• ✅ Opretter et virtuelt Python-miljø
• ✅ Installerer Python-afhængigheder
• ✅ Henter Go-afhængigheder
• ✅ Bygger projektet
• ✅ Starter tjenesten

Detalje 1: venv håndteres automatisk af scriptet. Mappen venv/ oprettes og vedligeholdes automatisk af run.sh, og de værktøjer, der kræver Python (api-fuzzer, http-framework-test osv.), bruger automatisk dette miljø. Opret den ikke manuelt – det skaber nemt konflikter.

Verificér opstarten: et par ting, der skal bekræftes

Når scriptet er færdigt, skal du ikke skynde dig til browseren; kig først i terminalen:

• Bekræft, at terminalen viser ● ONLINE, efterfulgt af den faktiske Web UI-adresse
• Åbn den adresse: med standard HTTPS bruges et lokalt selvsigneret certifikat; browseren giver en advarsel, og du accepterer blot én gang
• En ny installation har en engangs-administratorkode: terminalen viser den under ADMIN SETUP REQUIRED; skift den straks efter login

Detalje 2: HTTPS eller HTTP. run.sh starter som standard med parameteren –https (lokal selvsigneret TLS; ifølge officielle oplysninger er det mere venligt over for samtidige forbindelser). Vil du have ren HTTP, skal du eksplicit bruge ./run.sh --http. Ved manuel start tilføj –https eller sæt miljøvariablen CYBERSTRIKE_HTTPS=1.

Brug ikke selvsignerede certifikater i produktionsmiljøer; konfigurér i stedet server.tls_cert_path og server.tls_key_path i config.yaml.

Faldgrube nr. 2: fejl ved protokolmismatch. Ser du “client sent an HTTP request to an HTTPS server” i loggen, bruger en klient stadig http:// mod TLS-porten. Ret blot URL'en; pil ikke ved serverkonfigurationen.

Første konfiguration: AI-kanalen er obligatorisk

Springes dette trin over, er platformen reelt ikke installeret. Efter første start skal du åbne https://127.0.0.1:8080/ (porten følger server.port i config.yaml) og gå til System Settings → Basic Settings → AI Channel Configuration, tilføje en kanal og udfylde provider, Base URL, API-nøgle, model og token-grænse.

Du kan også redigere config.yaml direkte; formatet er cirka sådan:

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”

Detalje 3: standardkanalens virkefelt. ai.default_channel gælder for nye sessioner og opgaver uden eksplicit kanalvalg; på chatsiden kan man pr. session stadig vælge enhver gemt kanal. Så når du har flere modeller, behøver du ikke kun konfigurere én.

Sætter du provider til openai_compatible, kan de fleste OpenAI-kompatible tjenester tilsluttes; udskift base_url til https://api.deepseek.com/v1 og model til deepseek-chat, og qwen3-max fungerer på samme måde. Kinesiske modeller kan tilsluttes frit – det er ret venligt.

⚠️ Sikkerhedsadvarsel: læg ikke rigtige nøgler i config.yaml. Det officielle budskab er eksplicit: commit ikke rigtige legitimationsoplysninger; brug miljøvariabel-injektion.

Også opgradering kræver metode

Der følger et one-click-opgraderingsscript med, men første gang skal eksekveringsrettighederne gives:

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

Den gør: sikkerhedskopierer config.yaml og data/-mappen → henter ny kode fra GitHub Release → opdaterer versionsnummeret i config.yaml → genstarter tjenesten.De lokale mapper tools/, roles/ og skills/ bevares altid– det er et afgørende punkt; dine brugerdefinerede værktøjsopskrifter bliver ikke overskrevet.

Faldgrube nr. 3: opgraderingsscriptets afhængigheder. Scriptet kræver curl eller wget til at hente Release-pakken og rsync til sikker kodesynkronisering (officielt anbefalet/påkrævet). Er GitHub API rate-begrænset, så vent først export GITHUB_TOKEN="..." og kør bagefter.

Ved problemer kan der gendannes fra .upgrade-backup/, eller data og config.yaml kopieres manuelt tilbage, hvorefter run.sh køres igen.

Vigtig tommelfingerregel: læs altid release notes for målversionen før opgradering; vær ekstra forsigtig, når der er ændringer i konfiguration, database eller API. Den officielle formulering er nedjordisk – “backup er et must, selv ved patch-opgraderinger; et versionsnummer er i sig selv ingen kompatibilitetsgaranti.”

Hurtigt overblik over mappestrukturen

At vide, hvad hver mappe gør, gør den senere vedligeholdelse lettere:

• cmd/ — server, MCP stdio-indgang, værktøjer
• internal/ — agent, MCP-kerne, processorer, C2, sikkerhedseksekutor
• web/ — statisk SPA og skabeloner
• tools/ — YAML-værktøjsopskrifter (100+ eksempler)
• roles/ — rollekonfigurationer (12+ forudsatte sikkerhedstestroller)
• skills/ — agent Skills-mappe (SKILL.md + valgfrie filer)
• agents/ — multi-agent Markdown (orchestrator.md + underagenter)
• config.yaml — runtime-konfiguration
• run.sh / upgrade.sh — start-/opgraderingsscript

Sikkerhed kan værktøjet ikke tage fra dig

Platformen integrerer risikofyldte evner som WebShell-administration og en indbygget C2 (lyttere, krypterede beacons, sessioner, opgavekøer). Den officielle holdning er helt klar:må kun bruges mod systemer, du selv ejer eller har eksplicit tilladelse til at teste.

Før du aktiverer risikofyldte værktøjer i delte eller produktionsmiljøer, bør du læse sikkerhedsmodellen og hærdningsvejledningen. Platformen har også indbygget interception af værktøjskald – konfigurerbare regex-tjek før MCP-eksekvering, og beskyttelse af myndighedsdomæner er aktiveret som standard.

Desuden lyttes der som standard kun på 127.0.0.1; skal tjenesten eksponeres udadtil, så hærd først. Det er ikke en formalia – det er en advarsel, der kun skrives ind i dokumentationen af folk, der har løbet ind i blodige fejl.

Afsluttende ord

Set i bakspejlet gik selve udrulningen egentlig glat; scriptet klarede 90 % af arbejdet. Det, der fik mig til at stoppe op og slå op i dokumentationen, var udelukkende “uopmærkede” detaljer: Go-versionsgrænsen, at venv ikke må oprettes manuelt, at HTTPS som standard gav protokolmismatch, at opgradering kræver backup, og at nøgler ikke skal i konfigurationen.

Hver detalje er hver for sig ikke svær, men mangler du én, kan den binde dig i en halv time. Jo mere modent værktøjet er, jo større er udbyttet af at “læse dokumentationen” – det indkapsler kompleksiteten i scriptet, og resten af kompleksiteten ligger i konfigurationsdetaljerne.

Projektet er optaget i knownsec 404Starlink og open source under Apache 2.0. Alle, der udfører autoriseret sikkerhedstest, kan prøve det.

One-click-udrulning er ikke det samme som one-click-forståelse; detaljerne er den egentlige nøgle til at spare tid.

Projektadresse: github.com/Ed1s0nZ/CyberStrikeAI (flyttet til github.com/AIPentest/CyberStrikeAI)
Miljøkrav: Go 1.25+ / Python 3.10+
Licens: Apache License 2.0
⚠️ Kun til autoriseret test