Nederlands

← Terug naar overzicht

CyberStrikeAI in de praktijk deployen: ook bij een eenvoudige tool draait het om de details

itadol5j

De laatste tijd ben ik bezig met CyberStrikeAI, een AI-native securitytestplatform geschreven in Go. Ik dacht: 'one-click deployment', clonen, script draaien, klaar — maar ik liep tegen een paar flinke valkuilen aan. Terwijl alles nog vers in het geheugen ligt, zet ik hier het hele proces op papier — veel valkuilen liggen niet aan de tool, maar aan details die je over het hoofd ziet.

CyberStrikeAI-deployment

Eerst: wat voor tool is dit eigenlijk?

CyberStrikeAI positioneert zich als een 'actiesysteem voor AI-native cybersecurity', geschreven in Go, dat planning, uitvoering, menselijk toezicht, bewijsbewaring en replay samenbrengt in één auditeerbare werkbank. De kern bestaat uit een door Eino aangedreven Agent, MCP-native tools, een RAG-kennisbank, visuele workflows en aanvalsketenmodellering en -analyse.

Standaard zitten er 100+ toolrecepten in die de volledige kill chain dekken: netwerkscans als nmap, masscan en rustscan; webscans als sqlmap, nikto, gobuster en ffuf; kwetsbaarheidsscans als nuclei, wpscan en dalfox; plus subdomeinenumeratie, API-beveiliging, containerbeveiliging, cloudbeveiliging, binary-analyse, exploiteren, wachtwoordkraken, forensisch onderzoek, post-exploitatie en meer. Vrijwel alles wat je voor geautoriseerd pentesten nodig hebt, is al voor je georkestreerd.

Er zijn ook een Burp Suite-plug-in en een browserextensie waarmee je onderschepte traffic rechtstreeks in het platform gooit voor AI-ondersteunde analyse. Slim ontworpen — je bestaande workflow hoeft niet te veranderen.

De omgeving voorbereiden vóór de deployment

Officieel zijn er twee voorwaarden; let op dat je niet onder de vereiste versies zakt:

  • Go 1.25+(expliciet vereist in go.mod; daaronder compileert het direct met een foutmelding)
  • Python 3.10+(nodig voor sommige tools, zoals api-fuzzer en http-framework-test)

Valkuil 1: de Go-versie. De eerste keer gebruikte ik de verouderde Go-versie die het systeem meebracht, en pas bij het compileren verscheen de fout. Controleer daarom eerst go version en installeer zo nodig een nieuwe versie vanaf de officiële site. Dit soort 'voorwaarden' wordt het makkelijkst over het hoofd gezien, omdat de fout pas veel later opduikt.

One-click deployment: wat het script allemaal voor je doet

Het officiële one-click-deploycommando is kort:

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

Maar run.sh doet meer dan je denkt; het voert achtereenvolgens uit:

  • ✅ De Go- en Python-omgeving controleren en valideren
  • ✅ Een Python virtual environment aanmaken
  • ✅ Python-afhankelijkheden installeren
  • ✅ Go-afhankelijkheden downloaden
  • ✅ Het project bouwen
  • ✅ De service starten

Detail 1: de venv wordt door het script beheerd. De map venv/ wordt automatisch door run.sh aangemaakt en onderhouden; tools die Python nodig hebben (api-fuzzer, http-framework-test enz.) gebruiken die omgeving automatisch. Bouw zelf geen handmatige — dat geeft makkelijk conflicten.

De start verifiëren: een paar punten die je moet checken

Als het script klaar is, open dan niet meteen je browser maar kijk eerst in de terminal:

  • controleer of de terminal ● ONLINE toont, gevolgd door het echte adres van de Web UI
  • open dat adres: de standaard HTTPS-modus gebruikt een lokaal zelfondertekend certificaat; de browser waarschuwt, eenmalig accepteren is genoeg
  • Bij een nieuwe installatie is er een eenmalig beheerderswachtwoord: de terminal toont het onder ADMIN SETUP REQUIRED; verander het direct na het inloggen

Detail 2: HTTPS of HTTP. run.sh start standaard met de parameter –https (lokaal zelfondertekend TLS; volgens de documentatie werkt dat beter met gelijktijdige verbindingen). Wil je puur HTTP, dan moet je expliciet ./run.sh --httpgebruiken. Start je handmatig, voeg dan –https toe of zet de omgevingsvariabele CYBERSTRIKE_HTTPS=1.

Gebruik in productie geen zelfondertekend certificaat: configureer server.tls_cert_path en server.tls_key_path in config.yaml.

Valkuil 2: de foutmelding bij protocolmismatch. Zie je in de logs 'client sent an HTTP request to an HTTPS server', dan gebruikt er nog een client http:// naar de TLS-poort. Pas gewoon de URL aan en ga niet rommelen met de serverconfiguratie.

AI-native securitytestplatform

Eerste configuratie: het AI-kanaal is verplicht

Sla je deze stap over, dan is het platform zoveel als niet geïnstalleerd. Ga na de eerste start naar https://127.0.0.1:8080/ (de poort staat in server.port van config.yaml) en open System Settings → Basic Settings → AI Channel Configuration, voeg een kanaal toe en vul provider, Base URL, API key, model en de tokenlimiet in.

Je kunt config.yaml ook rechtstreeks aanpassen; het formaat ziet er ongeveer zo uit:

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”

Detail 3: hoe ver reikt het standaardkanaal. ai.default_channel geldt voor nieuwe sessies en taken zonder expliciet kanaal; in de chatpagina kun je per sessie nog steeds elk opgeslagen kanaal kiezen. Heb je meerdere modellen, dan hoef je dus niet bij één te blijven.

Met provider op openai_compatible sluit je op vrijwel elke dienst met een OpenAI-compatibele interface; zet base_url op https://api.deepseek.com/v1 en model op deepseek-chat, en qwen3-max werkt net zo. Je koppelt er zonder gedoe elk Chinees model aan — dat is prettig.

⚠️ Beveiligingswaarschuwing: zet geen echte sleutels in config.yaml. De documentatie zegt expliciet dat je echte credentials niet moet committen; gebruik omgevingsvariabelen.

Ook upgraden vraagt om methode

Er is een one-click-upgradescript, maar de eerste keer moet je eerst uitvoerrechten geven:

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

Het doet dit: back-up van config.yaml en de map data/ → nieuwe code uit de GitHub Release halen → het versienummer in config.yaml bijwerken → de service herstarten.De lokale mappen tools/, roles/ en skills/ blijven altijd behouden— dat is cruciaal: je eigen toolrecepten worden niet overschreven.

Valkuil 3: de afhankelijkheden van het upgradescript. Het heeft curl of wget nodig om het Release-pakket te downloaden en rsync voor veilige codesynchronisatie (volgens de documentatie aanbevolen/verplicht). Als de GitHub API je ratelimit, doe dan eerst export GITHUB_TOKEN="..." en voer het daarna opnieuw uit.

Gaat er iets mis, dan kun je herstellen vanuit .upgrade-backup/, of handmatig data en config.yaml terugzetten en run.sh opnieuw draaien.

Belangrijk principe: lees vóór elke upgrade de release notes van de doelversie, en wees extra alert bij wijzigingen in configuratie, database of API. De documentatie zegt het terecht — 'back-ups zijn verplicht, zelfs bij een patch-upgrade; een versienummer is op zichzelf geen garantie voor compatibiliteit.'

De mapstructuur in één oogopslag

Weet je wat elke map doet, dan raak je bij het onderhoud nooit de weg kwijt:

  • cmd/ — server, MCP stdio-ingang, tools
  • internal/ — Agent, MCP-kern, handlers, C2, security-executor
  • web/ — statische SPA en templates
  • tools/ — YAML-toolrecepten (100+ voorbeelden)
  • roles/ — rolconfiguraties (12+ voorgeconfigureerde securitytestrollen)
  • skills/ — Agent Skills-map (SKILL.md + optionele bestanden)
  • agents/ — multi-agent Markdown (orchestrator.md + subagents)
  • config.yaml — runtimeconfiguratie
  • run.sh / upgrade.sh — start-/upgradescripts

Veiligheid kun je niet aan een tool overlaten

Dit platform integreert hoog-risicocapaciteiten zoals WebShell-beheer en een ingebouwde C2 (listeners, versleutelde beacons, sessies, taakwachtrijen). De houding van de makers is ronduit duidelijk:gebruik het uitsluitend op systemen die je zelf bezit of waarvoor je expliciet toestemming hebt om te testen.

Voordat je high-risktools in een gedeelde of productieomgeving activeert, lees eerst het beveiligingsmodel en de hardinggids. Er zit ook toolaanroepblokkering ingebouwd — configureerbare regex-controles vóór de MCP-uitvoering, met standaard bescherming voor overheidsdomeinen.

Bovendien luistert de service standaard alleen op 127.0.0.1; wil je hem extern bereikbaar maken, hard de omgeving dan eerst af. Dat is geen beleefdheidsformule, maar een waarschuwing van iemand die er in de praktijk hard tegenaan is gegaan.

Configuratie van een pentestplatform

Tot slot

Achteraf bezien verliep de deployment zelf zonder echte problemen; het script deed 90% van het werk. Wat mij telkens deed stoppen en de documentatie in duiken, waren details die ik 'niet had opgemerkt': de Go-versiegrens, de venv die je niet handmatig mag aanmaken, protocolmismatch door standaard HTTPS, back-ups bij upgrades, en sleutels die niet in de configuratie thuishoren.

Los hiervan bekeken is geen enkel detail moeilijk, maar één overslaan kan je een half uur kosten. Hoe rijper de tool, hoe meer 'documentatie lezen' oplevert — het script verpakt de complexiteit, en wat overblijft zit precies in die configuratiedetails.

Het project is opgenomen in knownsec 404Starlink en open source onder Apache 2.0. Iedereen die geautoriseerde securitytests doet, kan het eens proberen.

One-click deployment betekent niet one-click begrip; de details zijn de echte tijdsbesparing.

Projectadres: github.com/Ed1s0nZ/CyberStrikeAI (verhuisd naar github.com/AIPentest/CyberStrikeAI)
Omgevingsvereisten: Go 1.25+ / Python 3.10+
Licentie: Apache License 2.0
⚠️ Uitsluitend voor geautoriseerde tests gebruiken