Дневник на инсталацията на CyberStrikeAI: дори простата инсталация на инструмент изисква внимание към детайлите

Напоследък се занимавах с CyberStrikeAI — AI-нативна платформа за тестове на сигурността, написана на Go. Мислех, че „инсталация с едно кликване“ значи клонираш, пускаш скрипт и толкова, но се натъкнах на няколко яда — нито големи, нито дребни. Докато спомените са свежи, записвам целия процес — много от ядовете не са проблем на инструмента, а недогледани детайли.

Първо — какъв инструмент е това

CyberStrikeAI се позиционира като „операционна система за AI-нативна киберсигурност“, написана на Go, и събира планирането, изпълнението, човешкия надзор, съхранението на доказателства и възпроизвеждането в една одитируема работна среда. Основните компоненти включват агент, задвижван от Eino, нативни MCP инструменти, RAG база знания, визуални работни процеси и моделиране и анализ на атакуващи вериги.

Вградени са над 100 рецепти за инструменти, покриващи пълната kill chain: мрежово сканиране с nmap, masscan, rustscan; уеб сканиране с sqlmap, nikto, gobuster, ffuf; сканиране за уязвимости с nuclei, wpscan, dalfox; плюс изброяване на поддомейни, сигурност на API, сигурност на контейнери, сигурност в облака, двоичен анализ, експлоатация, кракинг на пароли, форензика, пост-експлоатация и други. Практически всичко, от което се нуждае едно упълномощено тестово проникване, е вече подредено.

Освен това има плъгин за Burp Suite и разширение за браузър, с които прихванатият трафик се изпраща директно в платформата за AI-подпомогнат анализ. Доста умно решение — не се налага да променяте текущия си работен процес.

Подготовка на средата преди инсталацията

Официално има две предварителни изисквания — внимавайте с версиите:

• Go 1.25+(изрично изискваната версия в go.mod; при по-ниска версия компилацията директно дава грешка)
• Python 3.10+(нужна е за част от инструментите, например api-fuzzer, http-framework-test)

Яд първи: версията на Go. Първия път ползвах старата Go версия, идваща със системата, и грешката изскочи чак при компилация. Препоръчвам първо да go version проверите; ако не стига, инсталирайте нова от официалния сайт. Такива „предварителни изисквания“ най-лесно се пренебрегват, защото грешката се появява много по-късно.

Инсталация с едно кликване: какво прави скриптът вместо вас

Официалната команда за инсталация с едно кликване е кратка:

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

Но run.sh в действителност върши повече работа, отколкото си мислите, като изпълнява последователно:

• ✅ Проверява и валидира средите Go и Python
• ✅ Създава Python виртуална среда
• ✅ Инсталира Python зависимостите
• ✅ Изтегля Go зависимостите
• ✅ Строи проекта
• ✅ Стартира услугата

Детайл първи: venv се управлява автоматично от скрипта. Директорията venv/ се създава и поддържа автоматично от run.sh, а инструментите, нуждаещи се от Python (api-fuzzer, http-framework-test и др.), ползват автоматично тази среда. Не правете такава ръчно — лесно се получава конфликт.

Проверка на старта: няколко задължителни точки

След като скриптът свърши, не бързайте с браузъра — първо погледнете терминала:

• проверете, че терминалът показва ● ONLINE, следвано от действителния адрес на Web UI
• отворете този адрес: по подразбиране HTTPS режимът ползва локален самоподписан сертификат, браузърът ще предупреди — приемете веднъж и толкова
• Новата инсталация има еднократна администраторска парола: терминалът я показва под ADMIN SETUP REQUIRED; сменете я веднага след влизането

Детайл втори: HTTPS или HTTP. run.sh стартира по подразбиране с параметъра –https (локален самоподписан TLS; официално твърдение: по-дружелюбен към едновременните потоци). Ако искате чист HTTP, трябва изрично да ползвате ./run.sh --http. При ръчен старт добавете –https или задайте променливата на средата CYBERSTRIKE_HTTPS=1.

В продукционна среда не ползвайте самоподписан сертификат — конфигурирайте server.tls_cert_path и server.tls_key_path в config.yaml.

Яд втори: грешка от несъответствие на протокола. Ако в логовете видите „client sent an HTTP request to an HTTPS server“, значи някой клиент още достъпва TLS порта с http://. Сменете URL-а и не се занимавайте с конфигурацията на сървъра.

Първоначална конфигурация: AI каналът е задължителен

Без тази стъпка платформата е сякаш неинсталирана. След първия старт отворете https://127.0.0.1:8080/ (портът се определя от server.port в config.yaml) и влезте в System Settings → Basic Settings → AI Channel Configuration, добавете канал и попълнете provider, Base URL, API key, model и лимита на токените.

Може и директно да редактирате config.yaml; форматът е приблизително такъв:

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”

Детайл трети: обхватът на канала по подразбиране. ai.default_channel важи за новите сесии и задачите без изрично избран канал; в страницата за чат може и по сесия да изберете който и да е запазен канал. Значи при няколко модела не сте принудени да конфигурирате само един.

С provider = openai_compatible се свързват повечето услуги с OpenAI-съвместим интерфейс; base_url може да стане https://api.deepseek.com/v1, а model — deepseek-chat, същото важи и за qwen3-max. Свободно се закачат и китайски модели — доста любезно.

⚠️ Предупреждение за сигурността: не слагайте истински ключове в config.yaml. Официално е ясно казано — не правете commit на истински креденшъли, инжектирайте ги чрез променливи на средата.

И ъпгрейдът изисква метод

Официално има скрипт за ъпгрейд с едно кликване, но първия път първо дайте права за изпълнение:

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

Той прави: бекъп на config.yaml и директорията data/ → дърпа новия код от GitHub Release → обновява номера на версията в config.yaml → рестартира услугата.Локалните директории tools/, roles/ и skills/ винаги се запазват — това е ключово, персонализираните ви рецепти за инструменти няма да се презапишат.

Яд трети: зависимостите на ъпгрейд скрипта. Нужни са му curl или wget за изтегляне на Release пакета, а rsync — за безопасна синхронизация на кода (официално: препоръчително/задължително). Ако GitHub API е ограничил заявките, първо export GITHUB_TOKEN="..." проверете лимита, а после пуснете.

При проблем може да възстановите от .upgrade-backup/ или ръчно да върнете data и config.yaml и пак да пуснете run.sh.

Важно правило: преди ъпгрейд непременно прочетете release notes на целевата версия, а при промени в конфигурацията, базата данни или API — бъдете особено внимателни. Официална максима, казана по същество: „Бекъпът е задължителен, дори при ъпгрейд само с кръпки; самият номер на версия не е гаранция за съвместимост.“

Бърз преглед на структурата на директориите

Когато е ясно какво върши всяка директория, поддръжката после не те обърква:

• cmd/ — сървърна част, MCP stdio вход, инструменти
• internal/ — агент, MCP ядро, обработващи модули, C2, безопасен изпълнител
• web/ — статичен SPA и шаблони
• tools/ — YAML рецепти за инструменти (100+ примера)
• roles/ — конфигурации на роли (12+ предварително зададени роли за тестове на сигурността)
• skills/ — директория Agent Skills (SKILL.md + опционални файлове)
• agents/ — многоагентски Markdown (orchestrator.md + подагенти)
• config.yaml — конфигурация по време на изпълнение
• run.sh / upgrade.sh — скриптове за старт / ъпгрейд

В сигурността инструментът не може да те замести

Платформата интегрира високорискови възможности като управление на WebShell и вграден C2 (listener-и, шифровани beacon-и, сесии, опашки от задачи). Официалната позиция е изключително ясна:ползва се единствено за системи, които притежавате или за чието тестване имате изрично разрешение.

Преди да включите високорискови инструменти в споделена или продукционна среда, непременно прочетете първо модела на сигурност и упътването за закаляване. Платформата има и вградено прихващане на извикванията на инструменти — конфигурируеми проверки с регулярни изрази преди MCP изпълнение, а защитата на правителствени домейни е включена по подразбиране.

Освен това по подразбиране се слуша само на 127.0.0.1; ако ще излагате услугата навън, първо непременно я закалете. Това не са учтиви фрази, а напомняне, което човек би написал в документацията само след горчив опит.

В заключение

Оглядвайки назад, самата инсталация не породи големи проблеми — скриптът свърши 90% от работата. А какво ме накара да спра и да търся в документацията, бяха изцяло „недогледани“ детайли: границата на версията на Go, че venv не се прави ръчно, че HTTPS е включен по подразбиране и това води до несъответствие на протокола, че ъпгрейдът изисква бекъп, че ключовете не се пишат в конфигурацията.

Поотделно тези детайли не са трудни, но ако изпуснеш един, може да те задържи половин час. Колкото по-зрял е инструментът, толкова по-голяма е печалбата от „четенето на документацията“ — той опакова сложността в скрипта, а остатъчната сложност се крие в детайлите на конфигурацията.

Проектът е приет в knownsec 404Starlink и е с отворен код под Apache 2.0. Онези, които вършат упълномощени тестове на сигурността, могат да го пробват.

Инсталацията с едно кликване не е равна на разбиране с едно кликване — детайлите са истинският ключ за пестенето на време.

Адрес на проекта: github.com/Ed1s0nZ/CyberStrikeAI (преместен на github.com/AIPentest/CyberStrikeAI)
Изисквания към средата: Go 1.25+ / Python 3.10+
Лиценз: Apache License 2.0
⚠️ Само за упълномощено тестване