CyberStrikeAI — zapis z wdrożenia: nawet proste narzędzie wymaga dbałości o szczegóły

Ostatnio bawiłem się CyberStrikeAI, napisaną w Go natywną dla AI platformą do testów bezpieczeństwa. Myślałem: „wdrożenie jednym kliknięciem”, klonuję, odpalam skrypt i po sprawie — a tu kilka mniejszych i większych wpadek. Póki pamięć jest świeża, zapisuję cały proces — wiele z tych pułapek to nie wina narzędzia, lecz szczegółów, których nie zauważyłem.

Najpierw: co to za narzędzie

CyberStrikeAI pozycjonuje się jako „system działań dla natywnego wobec AI bezpieczeństwa sieciowego”; napisany w Go, zbiera w jednym możliwym do audytu warsztacie planowanie, wykonanie, nadzór człowieka, gromadzenie dowodów oraz odtwarzanie przebiegu. W skład rdzenia wchodzą agent napędzany przez Eino, natywne narzędzia MCP, baza wiedzy RAG, wizualne przepływy pracy oraz modelowanie i analiza łańcuchów ataku.

Ma wbudowanych ponad 100 przepisów narzędzi obejmujących cały łańcuch ataku: skanowanie sieci w rodzaju nmap, masscan czy rustscan; skanowanie Web w rodzaju sqlmap, nikto, gobuster i ffuf; skanowanie podatności w rodzaju nuclei, wpscan i dalfox; a także enumerację subdomen, bezpieczeństwo API, bezpieczeństwo kontenerów i chmury, analizę binarną, eksploatację, łamanie haseł, forensics i posteksploatację. W zasadzie wszystko, czego potrzeba do autoryzowanych testów penetracyjnych, zostało tu zorkiestrowane.

Dochodzą do tego wtyczka do Burp Suite i rozszerzenie przeglądarki, które pozwalają wrzucić przechwycony ruch bezpośrednio na platformę do analizy wspomaganej AI. To sprytny pomysł — nie musisz zmieniać swojego obecnego sposobu pracy.

Przygotowanie środowiska przed wdrożeniem

Twórcy wymagają dwóch warunków wstępnych — uważaj na wersje:

• Go 1.25+(wersja wprost wymagana w go.mod; przy niższej kompilacja od razu zgłosi błąd)
• Python 3.10+(wymagany przez część narzędzi, na przykład api-fuzzer czy http-framework-test)

Pułapka pierwsza: wersja Go. Za pierwszym razem użyłem starego Go dostarczanego z systemem i błąd wyskoczył dopiero na etapie kompilacji. Najpierw warto go version to sprawdzić, a jeśli wersja nie wystarcza — pobrać nowszą z oficjalnej strony. Takie „wymagania wstępne” najłatwiej przeoczyć, bo błąd pojawia się bardzo późno.

Wdrożenie jednym poleceniem: co robi za ciebie skrypt

Oficjalne polecenie wdrożenia jest bardzo zwięzłe:

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

Ale run.sh robi więcej, niż myślisz — wykonuje po kolei:

• ✅ sprawdzenie i walidacja środowisk Go oraz Python
• ✅ utworzenie wirtualnego środowiska Python
• ✅ instalacja zależności Python
• ✅ pobranie zależności Go
• ✅ zbudowanie projektu
• ✅ uruchomienie usługi

Szczegół pierwszy: venv zarządza skrypt. Katalog venv/ jest tworzony i utrzymywany automatycznie przez run.sh, a narzędzia wymagające Pythona (api-fuzzer, http-framework-test i inne) same z niego skorzystają. Nie twórz go ręcznie — łatwo o konflikt.

Weryfikacja uruchomienia: kilka punktów obowiązkowych

Po zakończeniu skryptu nie otwieraj od razu przeglądarki — najpierw zajrzyj do terminala:

• Upewnij się, że terminal pokazuje ● ONLINE, a po nim właściwy adres Web UI
• Otwórz ten adres: domyślny tryb HTTPS używa lokalnego certyfikatu self-signed, więc przeglądarka wyświetli ostrzeżenie — wystarczy je raz zaakceptować
• Przy nowej instalacji pojawia się jednorazowe hasło administratora: terminal wyświetla je pod ADMIN SETUP REQUIRED — po zalogowaniu natychmiast je zmień

Szczegół drugi: HTTPS czy HTTP. run.sh domyślnie startuje z parametrem –https (lokalny TLS self-signed; według twórców radzi sobie lepiej z równoległymi strumieniami). Jeśli wolisz czysty HTTP, musisz jawnie użyć ./run.sh --http. Przy ręcznym uruchomieniu dodaj –https albo ustaw zmienną środowiskową CYBERSTRIKE_HTTPS=1.

W środowisku produkcyjnym nie używaj certyfikatu self-signed — skonfiguruj server.tls_cert_path i server.tls_key_path w config.yaml.

Pułapka druga: błąd niezgodności protokołu. Jeśli w logach widzisz „client sent an HTTP request to an HTTPS server”, znaczy to, że jakiś klient wciąż uderza przez http:// na port TLS. Wystarczy poprawić URL — nie grzeb w konfiguracji serwera.

Konfiguracja początkowa: kanał AI jest obowiązkowy

Bez tego kroku platforma jest jak niezainstalowana. Po pierwszym uruchomieniu wejdź na https://127.0.0.1:8080/ (port zgodny z server.port w config.yaml) i przejdź do System Settings → Basic Settings → AI Channel Configuration, dodaj kanał i wypełnij provider, Base URL, API key, model oraz limit tokenów.

Można też od razu edytować config.yaml — format wygląda mniej więcej tak:

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”

Szczegół trzeci: zakres działania kanału domyślnego. ai.default_channel służy nowym sesjom i zadaniom bez wyraźnie wybranego kanału; na stronie czatu można też wybrać dowolny zapisany kanał osobno dla danej sesji. Mając kilka modeli, nie musisz więc ograniczać się do jednego.

Ustawienie provider na openai_compatible pozwala podłączyć większość usług zgodnych z interfejsem OpenAI — możesz podmienić base_url na https://api.deepseek.com/v1 i model na deepseek-chat, tak samo z qwen3-max. Modele chińskie podłączają się bez problemu, co jest bardzo wygodne.

⚠️ Ostrzeżenie bezpieczeństwa: nie zapisuj w config.yaml prawdziwych kluczy. Twórcy wprost ostrzegają, by nie commitować prawdziwych poświadczeń — wstrzykuj je przez zmienne środowiskowe.

Aktualizacja też wymaga metody

Twórcy udostępniają skrypt aktualizacji jednym poleceniem, ale za pierwszym razem trzeba nadać mu prawa wykonywania:

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

Robi to: kopię zapasową config.yaml i katalogu data/ → pobranie nowego kodu z GitHub Release → aktualizację numeru wersji w config.yaml → restart usługi.Lokalne katalogi tools/, roles/ i skills/ są zawsze zachowywane — to kluczowe: twoje własne przepisy narzędzi nie zostaną nadpisane.

Pułapka trzecia: zależności skryptu aktualizacji. Wymaga curla albo wget do pobrania paczki Release oraz rsync do bezpiecznej synchronizacji kodu (według twórców zalecany lub niezbędny). Jeśli API GitHuba nałoży ograniczenia przepustowości, najpierw export GITHUB_TOKEN="..." odczekaj, a potem uruchom.

W razie problemów można odtworzyć stan z .upgrade-backup/ albo ręcznie skopiować z powrotem data oraz config.yaml i uruchomić run.sh.

Ważna zasada: przed aktualizacją koniecznie przeczytaj release notes wersji docelowej, zwłaszcza gdy zmieniają się konfiguracja, baza danych lub API. Twórcy ujęli to trafnie — „kopia zapasowa jest obowiązkowa, nawet przy samej łatce; sam numer wersji nie jest gwarancją kompatybilności”.

Szybki przegląd struktury katalogów

Warto wiedzieć, za co odpowiada każdy katalog, żeby nie zgubić się przy późniejszym utrzymaniu:

• cmd/ — serwer, wejście MCP stdio, narzędzia
• internal/ — agent, rdzeń MCP, procedury obsługi, C2, bezpieczny wykonawca
• web/ — statyczne SPA i szablony
• tools/ — przepisy narzędzi w YAML (ponad 100 przykładów)
• roles/ — konfiguracja ról (ponad 12 gotowych ról testów bezpieczeństwa)
• skills/ — katalog Agent Skills (SKILL.md + pliki opcjonalne)
• agents/ — Markdown dla wielu agentów (orchestrator.md + agenty podrzędne)
• config.yaml — konfiguracja uruchomieniowa
• run.sh / upgrade.sh — skrypt uruchomieniowy / aktualizacyjny

Bezpieczeństwa narzędzie za ciebie nie załatwi

Platforma integruje funkcje wysokiego ryzyka, takie jak zarządzanie WebShell czy wbudowane C2 (listener, szyfrowany beacon, sesje, kolejka zadań). Stanowisko twórców jest jednoznaczne:można jej używać wyłącznie wobec systemów, które sam posiadasz lub na testy których masz wyraźną autoryzację.

Przed włączeniem narzędzi wysokiego ryzyka w środowisku współdzielonym lub produkcyjnym koniecznie przeczytaj model bezpieczeństwa i przewodnik hardeningu. Wbudowano też blokowanie wywołań narzędzi — konfigurowalną kontrolę regexową przed wykonaniem MCP, z domyślnie włączoną ochroną domen rządowych.

Ponadto domyślnie nasłuchuje tylko na 127.0.0.1 — jeśli chcesz wystawić usługę na zewnątrz, najpierw koniecznie ją utwardź. To nie grzecznościowy frazes, lecz uwaga, którą wpisuje do dokumentacji ktoś, kto już się dotkliwie sparzył.

Na koniec

Patrząc wstecz, samo wdrożenie nie sprawiło większych problemów — skrypt odwalił 90% roboty. To, co naprawdę zmusiło mnie do sięgnięcia po dokumentację, to same „niezauważone” detale: linia wersji Go, zakaz ręcznego tworzenia venv, domyślnie włączone HTTPS powodujące niezgodność protokołu, konieczność kopii zapasowej przy aktualizacji i zakaz wpisywania kluczy do konfiguracji.

Każdy z tych szczegółów z osobna jest prosty, ale pominięcie jednego może kosztować pół godziny. Im dojrzalsze narzędzie, tym większy zwrot z „czytania dokumentacji” — ono zamyka złożoność w skrypcie, a cała reszta złożoności zostaje w detalach konfiguracji.

Projekt trafił do knownsec 404Starlink i jest otwarty na licencji Apache 2.0. Jeśli zajmujesz się autoryzowanymi testami bezpieczeństwa, warto spróbować.

Wdrożenie jednym kliknięciem to nie zrozumienie jednym kliknięciem — detale są prawdziwym kluczem do oszczędności czasu.

Adres projektu: github.com/Ed1s0nZ/CyberStrikeAI (przeniesiony na github.com/AIPentest/CyberStrikeAI)
Wymagania środowiskowe: Go 1.25+ / Python 3.10+
Licencja: Apache License 2.0
⚠️ Wyłącznie do autoryzowanych testów