У многих такое было: пишешь скрипт или целого монстра на коленке, локально всё взлетает и работает, а вот у счастливчика, с кем ты поделился проектом — нет! Для решения этой проблемы (и не только) мир придумал Docker. Упаковал приложение в контейнер, проверил — работает. Отдал Dockerfile товарищу — и у него всё завелось один в один. И это реально круто.

А теперь немного о пентесте и причем тут, казалось бы, контейнеры?

Пентест‑инструментарий — это искусство и боль в одном флаконе. Искусство — изящное (или не всегда) решение повседневных задач. Боль — поддержка и зависимости. Наустанавливаешь тонну пакетов в систему, обновишься раз, другой, а потом смотришь в черный экран смерти, в лучшем случае можешь почитать буквы на экране... И ты уже понимашь, что твоя боевая лошадка превратилась в тыкву, и не факт, что сможет оправиться от такого сокрушительного удара зависимостей, а может и еще чего‑то.

Специализированные дистрибутивы не лишены этого изъяна, а даже чаще больше подвержены. Предлагаю рассмотреть некоторые популярные дистрибутивы, а именно:

  • Kali Linux

  • ParrotOS

  • BlackArch

Kali Linux сложно назвать стабильной ОС для домашнего или повседневного использования. Как пишут сами разработчики в документации:

kali‑rolling — это основная ветка по умолчанию, которую следует использовать большинству пользователей. Она постоянно обновляется, поскольку получает обновления из kali‑dev после проверки стабильности сомнительных пакетов и объединения их с пакетами из kali‑rolling‑only. Время от времени сюда могут попадать ошибки в пакетах из‑за ошибок в debian‑testing.

По опыту использования ArchLinux и VoidLinux, скажу, что rolling release (беспрерывное обновление пакетов вместо выхода крупного релиза раз в несколько месяцев) — это круто. Но не для систем, где есть зависимости, возраст которых сравним с нашим, при этом еще и не поддерживаемые более разработчиками. Такой дистрибутив лучше держать на виртуальной машине и подальше от себя, и не в коем случае не как основную ОС.

ParrotOS, если верить Wiki, основан на ветке тестирования Debian (Buster) с LTS ядром 5.10. На момент написания статьи я лично сижу на ядре Linux 7.2.11. Для сравнения, ядро 5.10 вышло в 2020 году! Ничего не имею против возраста ядра, особенно, если для него до сих пор выходят обновления (!), но уже попахивает прошлым веком, не правда ли?

И теперь наш толстяк BlackArch, надеюсь, никто меня за такое высказывание не возненавидит... Вес его образа ISO не может не впечатлять, при максимальной комплектации до 22ГБ, и это только образ!

Мнение субъективное, но это лучший из представленных вариантов, так как репозиторий BlackArch можно с легкостью добавить в любой Arch‑based дистрибутив и работать система будет достаточно стабильно, в то время как Debian‑based загнутся достаточно быстро после добавления репозиторием Kali/Parrot

А теперь кратко о проблеме использования таких дистрибутивов...

Готовые пентестерские дистрибутивы перегружены инструментами, но справедливости ради, они для этого и были созданы! Kali содержит в себе около 600 инструментов для тестирования на проникновение и разведки, ParrotOS около 800, в репозиторий BlackArch входят 2863 инструмента(!)

А сколько инструментов используешь ТЫ? Готов поспорить, их можно по пальцам пересчитать!

Разработчики предлагают Docker образы для своих дистрибутивов

Kali предлагают для загрузки несколько вариантов образов Docker, для примера возьму kali‑rolling. Его начальный веc составляет 46МБ, не так уж и много, согласитесь? Но это только до тех пор, пока он пустой. Однако, по мере установки необходимого инструментария его раздует до одного ГБ, позднее до двух, и так далее. Хотя в этом и есть прелесть данного решения: ставишь только то, что тебе нужно и ничего более. Опять же, rolling release и Debian, это не самое лучше решение, хоть уже и не так страшно, если образ по той или иной причине скажет «пока‑пока!»

Итого, мы имеем следующие варианты использования пентест‑инструментария, а точнее среды их использования:

  • На своем железе, как основную ОС (крайне не рекомендуется)

  • На виртуальной машине

  • В среде контейнеров

Мое решение, которое сможет уберечь тебя от преждевременной седины!

Все гениальное начинается с простого, с обыденного. Я ни в коем случае не утверждаю, что мое решение гениально, но оно заслуживает, как минимум, внимания.

Когда‑то я начинал изучение инструментов на своей основной ОС, на то время только перешел с микромягких товарищей на джентельмена в смокинге, а называли его Ubuntu. Короче, начинал как и многие другие пользователи Linux. По свежекупленной книге «Хакинг на Linux» начал пылесосить взглядом страницы в поиске тайных секретов взлома систем и IT‑гигантов. Начал пробовать на вкус nmap, поставил его прямо из репозитория дистрибутивы и поехали веселиться! Но в скором времени я узнал такое понятие, как Script kiddie и желание продолжать в том же духе быстро испарилось. В свобоное время начал изучать основы, но по тем или иным причинам двигался я достаточно медленно, то работа в 5/2, то еще что‑то, а на выходных уже не было желания чему‑то учиться, а кто с таким не сталкивался?

И спустя время я оброс какими‑то знаниями, уже что‑то умел кодить на Python3, немного шарил за уязвимости. На тот момент уже понимал как работают большинство инструментов, которые используют профи своего дела. Что‑то нащупывал опытным путем, а что‑то подглядывал в исходных текстах инструментов(спасибо, если они были написаны на Python3 или Ruby).

Со временем осознал, что теперь то я могу попользоваться готовыми наработками других ребят, я ведь уже не скрипт кидди! И на этом моменте я понял, что мне не хочется засорять свою систему тулзами, которые вплетутся в нее корнями и будут дергать за зависимости. А использование виртуальных машин я не мог себе позволять, а точнее железо едва ли тянуло ArchLinux + i3wm, так что о VirtualBox можно было и не мечтать. Но я не из тех парней, которые смирились с ограничениями и не забил на это...

Упаковка инструментов: Начало

Так уж получилось, что я уже был немного знаком с контейнерами, а именно с Docker, и мог позволить себе писать Dockerfile, упаковывать инструменты и запускать их в контейнерах. Со временем я познакомился с прекрасной альтернативой докеру — Podman.

Ключевое отличие Podman от Docker заключается в архитектуре и концепции:

  • Docker использует центральный фоновый демон (Docker Daemon), требующий прав администратора (root), а Podman работает без демона (daemonless) и по умолчанию поддерживает работу в режиме без прав root (rootless).

  • Podman поддерживает работу с «подами» (группами контейнеров, разделяющими общие сетевые пространства и ресурсы), в то время как контейнеры Docker запускаются по отдельности (для связки используется Docker Compose или Swarm).

Итак, я уже активно что‑то тыкал на TryHackMe, HackTheBox, PicoCTF, но для решения CTF уж очень не хотелось нести что‑то в свою систему и по этой причине собирал образы и запускал инструменты в контейнерах. Сначал казалось все круто, в системе чисто, ничего лишнего, но со временем обратил внимание на то, что именно я делаю. А делал я следующее: клонировал репозиторий, писал Containerfile/Dockerfile, если же Dockerfile не был добавлен разработчиком и собирал образ. За время моих эксперементов я изрядно надругался над файоловой системой и был, мягко говоря, не сильно доволен ситуацией.

К чему я пришел

В конечном итоге мною было принято решение создать своеобразный и разношерстный сборник рецептов Containerfile. Таким образом начал зарождаться VoidSec! Его идеи простые и прозрачные:

  • Один инструмент — один контейнер;

  • Сборка инструментов исключительно из исходных текстов в изолированной среде;

  • Независомость от выбора дистрибутива основной ОС;

  • Отсутствие конфликтов зависимостей в основной системе;

  • Стандартизация сборки инструментов в изолированных средах

Теперь, когда было нащупано решение, которое меня полностью удовлетворяет во всех смыслах, оставалось только автоматизаровать сборку, добавить какой‑то элемент менеджмента образами, созданными в условиях проекта VoidSec. Для этого была написана небольшая обертка на python3, которая позволяет в удобном интерфейсе командной строки собирать и удалять образы, искать инструменты по ключевым словам в самом VoidSec.

Давай посмотрим на пример сборки nmap:

Пример удаления:

А если нам что‑то нужно найти?

Что нам нужно для добавления нового инструмента в VoidSec? В директории packages создать директорию под инструмент. В нее добавить два файла: Containerfile и package.json.

Пример Containerfile:

FROM alpine 

RUN apk add --no-cache fish python3 git vim
RUN /usr/bin/fish -c "set -U fish_greeting"
WORKDIR /root
RUN git clone https://github.com/rickert155/CyberWarn cyberwarn
RUN apk del git
WORKDIR /root/cyberwarn
RUN python3 -m venv venv && ./venv/bin/pip install -r packages.txt
RUN echo "source /root/cyberwarn/venv/bin/activate.fish" > /root/.config/fish/config.fish
CMD ["fish"]

И пример package.json

{
    "name":"cyberscan", # название инструмента
    "description":"Automated Cyber Security Threat Detection Tool", # краткое описание
    "source":"https://gitea.com/cyberwarn/cyberscan", # источник исходных текстов
    "containerfile":"Containerfile", # имя файла для сборки образа
    "category":"fuzzing | webapp", # категории или теги для оптимизации поиска
    "image":"localhost/cyberscan-container" # имя образа
}

Сейчас репозиторий насчитывает два десятка крутых тулзов, и на этом я не планирую останавливать. VoidSec создавался как личный инструмент для спасения основной системы от захламления, а вырос в удобную альтернативу тяжелым пентест‑дистрибутивам.

Если вам близка концепция чистой ОС и/или контейнеризации в ИБ — залетайте, тестируйте и делитесь мыслями. Буду искренне рад вашим идеям и Pull Request'ам!

Проект на GitHub: https://github.com/Rickert155/VoidSec/