Slackbot для тестирования безопасности, построенный на бэкенде Kubernetes в Google Cloud Platform
ПРИМЕЧАНИЕ: Я больше не поддерживаю этот проект активно. Я работаю над версией 2 Kubebot вместе с несколькими другими людьми, которая, вероятно, будет представлена на одной из предстоящих конференций по безопасности.
1 - API-запрос (инструмент, цель, параметры) инициируется из Slackbot, отправляется на API-сервер, который работает как Docker-контейнер в кластере Kubernetes (K8s) и может масштабироваться.
2 - API-сервер помещает полученный запрос как сообщение в тему PubSub Tool.
3 - Сообщения публикуются в подписку Tool.
4 - Worker(ы) подписки, работающие как Docker-контейнер(ы) в кластере K8s, потребляют сообщение из подписки. Количество этих worker'ов также может масштабироваться.
5 - В зависимости от инструмента, цели и параметров, полученных от конечного пользователя, запускаются соответствующие Tool Worker(ы) в том же кластере K8s как Docker-контейнеры. Результаты временно сохраняются в локальной директории этого контейнера. Клонируется Github-директория этого инструмента.
6 - Проверяется, существовал ли сгенерированный файл результатов. Если его не было, он добавляется и изменения отправляются в Github. Если он существует, файлы сравниваются, новый файл отправляется в Github, и в следующий шаг передаются только изменения.
7 - Webhook от Tool Worker(ов) отправляет изменения обратно в Slack. Tool worker(ы) удаляются, так как они больше не нужны.
PS - Все Docker-образы API-сервера, Worker(ов) подписки и Tool Worker(ов) загружаются из Google Container Registry этой учетной записи GCP перед развертыванием в кластере K8s.
Список инструментов, интегрированных на данный момент (Этот список будет обновляться по мере добавления новых инструментов. В папке tools есть еще несколько инструментов, но они все еще находятся в разработке.)
Список автоматизированных рабочих процессов, интегрированных на данный момент (Этот список будет обновляться по мере добавления новых рабочих процессов)
config - Содержит файлы конфигурации для развертывания компонентов Kubebot.
cronjobs - Содержит пример файла развертывания (.yaml) для настройки cron-заданий для запуска определенного инструмента с определенным интервалом и отправки результатов обратно в Slack через Webhook.
Утилита-контейнер с именем checkfile используется для выполнения операции diff над файлами Github для выявления любых изменений между предыдущим и последним запуском инструмента. Этот контейнер запускается после каждого контейнера инструмента.
Утилита с именем converttobq используется для преобразования данных из инструментов в формат, пригодный для загрузки в BigQuery. Эта утилита запускается в автоматизированных рабочих процессах, где результаты каждого инструмента сохраняются в BQ для дальнейшего использования другими инструментами.
Утилита с именем wfuzzbasicauthbrute используется для перебора механизма базовой аутентификации конечных точек, хранящихся в таблице BQ, со всеми секретами, хранящимися в другой таблице BQ.
.env.sample - Переименуйте этот файл в .env и убедитесь, что значения в нем корректны, когда вы хотите развернуть Kubebot локально.
Makefile - makefile для сборки вашего окружения Kubebot.
Список задач - Пожалуйста, помогите мне сделать Kubebot лучше!
Запуск Kubebot удаленно - Когда вы убедитесь, что Kubebot работает как ожидалось локально (с использованием Minikube) и теперь хотите раскрыть его потенциал и использовать в полную силу в облаке, его можно развернуть в кластере Google Container Engine (GKE). Однако я пока не могу предоставить инструкции для удаленного развертывания. Тем не менее, если будет интерес, я с удовольствием помогу. И если вы хотите просто использовать Kubebot как Slack-приложение и не беспокоиться о бэкенд-инфраструктуре, это также может быть организовано за небольшую ежемесячную плату, так как я буду размещать бэкенд в своем личном аккаунте GCP, а вы будете нести только обычные расходы, связанные с хостингом VPS у облачного провайдера. Пожалуйста, свяжитесь со мной, чтобы обсудить эти варианты.
Обратите внимание, как можно выполнить slash-команду с именем инструмента, параметрами и целью(ями). Я говорю «цель(и)», потому что можно выполнить одну slash-команду для запуска одного инструмента с набором параметров против нескольких целей. Например, команда gitrob ниже выполняется против test и abc.
/runtool nmap|-Pn -p 1-1000|google.com
/runtool sublist3r|-t 50|test.com
/runtool gobuster|-m dns -w fierce_hostlist.txt -t 10 -fw|google.com
anshumanbh/kubebot
