• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Статья Автоматизация OWASP ZAP, Часть 2, Запуск в Docker, доступ к API

Приветствую на второй части статьи по OWASP ZAP. В данной статье мы рассмотрим запуск ZAP в DOCKER, а так же различные тонкие моменты его запуска, различные режимы работы и типы контейнеров.

С первой частью статью можно познакомиться тут: Автоматизация OWASP ZAP. Часть 1. Вводная часть

Почему Docker?
Тут все очевидно и просто. Докер образ нам позволяет изолировать среду, более быстро и оперативно решать проблемы, либо не решать их совсем, а просто откатываться к предыдущим версиям образов, или обнулять все конфигурации например. К тому же докер нам позволяет переносить все зависимости и всю среду AS IS(как есть) практически на любую операционную систему, а также позволяет постоянно обновляться и проводить тестирование на самых новых версиях OWASP ZAP.

Также докеризация приложений является современным мэйнстримом и некоторые CI/СD системы предпочитают работать именно с такими сервисами и приложениями. (например GitLAB c его билдером, в котором собираются приложения докер образы и доставляются на целевые хосты, а также проводятся различные тесты. Каждая система тестов должна быть запущена в своем Docker контейнере).

В общем закончим лирическое отступление, и перейдем ближе к теме. Про докер очень много везде материала, и советую с ним все таки познакомиться поближе, если вы этого еще не сделали.
У Docker есть только один пожалуй недостаток(оно так же является и преимуществом), он не сохраняет данные которые сам в себе сохраняет. Но с этой проблемой мы будем бороться ниже.

Docker образы OWASP ZAP
Тут пожалуй позволю себе переписать немного документации разработчиков. Ссылочку оставляю тут:


Итак, OWASP ZAP имеет 4 докер образа. Обо всех по порядку:
  1. owasp/zap2docker-stable полный стабильный образ со всеми возможными пакетами (curl, nano и т.п.) и скриптами запуска ZAP. Примерный размер 1.4 GB
  2. owasp/zap2docker-weekly то же самое что и в п.1 только обычно правила более свежие + различные недельные доработки. Не столь стабилен как п.1. Может что-то вылезти в процессе эксплуатации.
  3. owasp/zap2docker-live ну это в принципе еше менее стабильный релиз. Что накодили разрабы, то и зарелизили сюда.
  4. owasp/zap2docker-bare это максимально обрезанный Docker image который как раз и предназначен для встраивания в CI/CD пайплайны, для быстрого разворачивания, переносимости и скачивания. В идеале надо пользоваться только им. Размер примерно 350 мб.
Мы же будем пользоваться образом преимущественно из п.1. Почему? Ведь мы вроде рассматриваем встраивание в CI/CD, хотим оперативного переноса контейнера и прочие плюшки? Все просто, для этого есть пару причин, а именно:
  • нам нужна будет отладка (curl очень нужен будет например, которого нет в обрезанной версии из п.4).
  • нам нужен будет один из режимов запуска zap, для удобной отладки и конфигурирования на первых шагах, а также просмотра того, что мы собственно наконфигурировали в скриптах и что происходит при сканировании. Да и происходит ли оно?
Да и честно говоря, до изучения "внутренностей" контейнера из п 4 я пока еще не дошел.

Заметка: В дальнейшем zap лучше еще установить на локальной машине, для большего быстродействия и быстрой отладки. Docker нужен на целевой хост машине, с целью исключения неприятных сюрпризов. В "идеале" настраиваться и писать скрипты сразу на хост системе, которая будет прокси сервером для браузеров с регрессионными тестами (см. мою статью часть 1), но честно признаюсь, не очень хватает нервов для этого. Поэтому лучше сделать следующее:
  1. Развернуть целевую систему и проверить её работоспособность. Опишу в данной статье.
  2. Установить OWASP ZAP локально, для тестирования скриптов. (можно и без этого пункта, решать вам, и устанавливать тоже).
Запускаемся
Замечание:
здесь я предполагаю, что у пользователя установлены все пакеты docker и это все работоспособно. Для начала, как говорит нам документация, надо на хостовую систему скачать нужный нам image:
Bash:
docker pull owasp/zap2docker-stable
Проверить, что image скачался и есть в локальном хранилище можно так:
Bash:
root@cs30975:~# docker images | grep zap
owasp/zap2docker-stable                         latest               a05b3e5e1979        6 weeks ago         1.38GB
Замечание: Если у вас активно используется докер, смотрите за количестом образов хранимых на хосте. Может внезапно кончиться место. Для того, чтобы запускалась каждый раз новая версия образа, необходимо периодически удалять хранимый на хосте образ zap либо проверять обновления через команду docker pull указанную выше.

Удалять же образы можно следующим способом:
  • Ищем нужный образ:
    Bash:
    root@cs30975:~# docker images | grep zap
    owasp/zap2docker-stable latest a05b3e5e1979 6 weeks ago 1.38GB
  • Удаляем образ по его уникальному номеру:
    Bash:
    root@cs30975:~# docker rmi  a05b3e5e1979
Шаг с пулом контейнера можно пропустить, и сразу приступить к запуску контейнера. При этом если образ ранее не был скачан docker обратиться к публичному хранилищу dockerhub скачает оттуда Dockerfile и создаст докер образ. Если он был скачан и собран ранее, он возьмет готовый образ из локального хранилища. Я например сразу делал так:
Bash:
docker run --rm -u zap -p 8080:8080 -p 8090:8090 --name owasp-zap -d owasp/zap2docker-stable zap-webswing.sh
Кратко пробежимся по команде:
--rm
- говорит о том, что контейнер будет удален, после его остановки.
-u zap -p 8080:8080 -p 8090:8090 - в контейнере будет сервис запускаться под пользователем zap, у контейнера необходимо "выбросить" порты 8080 и 8090 на хостовую систему.
--name owasp-zap -даем контейнеру имя, чтобы потом с ним было проще управляться и обращаться через присвоенное нами имя, а не через его ID или случайное имя.
-d owasp/zap2docker-stable zap-webswing.sh - запускаемся в тихом режиме (-d) указываем образ который запустить, и ENTRIPOINT. Т.е. какую команду выполнить.

В данном случае, мы запускаем ZAP в режиме webswing. Ну а теперь поподробнее разберем режимы ZAP.
ВАЖНОЕ ЗАМЕЧАНИЕ: все свои конфиги, сохраненные сессии и скрипты zap хранит в домашней дирректории, т.е. /home/zap/.ZAP/

WEBSWING
Тут мы будем работать максимально. Это самый идеальный режим для отладки. По сути это режим в котором можно управлять OWASP ZAP через полноценный GUI WEB интерфейс и в реальности смотреть, что на нем сейчас работатает, состояние сканирований и т.п.

Раз уж мы в нем запустились, давайте сразу настроимся для дальнейшей удобной работы.

Допустим, что контейнер у меня работает на серевере с IP 1.1.1.1.

Чтобы запустить ZAP и попасть в GUI надо перейти по ссылке: - тут порт, который мы ранее выкидывали в запуске докер контейнера.

Обратите внимание, что /zap обязательно, иначе вы попадете не куда надо, а на страницу логина:

login.jpg


После открытия, запуститься сессия ZAP.

Обратите внимание: прокси zap будет доступно по порту 8090 только после того, как вы запустите сессию, т.е. перейдете по ссылке указанной выше. Там же будет и сессия.

Итак, мы запустили сессию. Теперь давайте настроим некоторые параметры, чтобы достучаться до API ZAP. Изначально, приложение достаточно закрыто. Это надо исправить.

Идем: Tools -> Options. Выбираем раздел API. Настраиваем как на картинке.

API.jpg


Стоит понимать, что данные настройки только для тестовой среды. Желательно ограничить IP адресацию для которой доступна API. Я это делаю на iptables, поэтому тут разрешил все. Также можете указать свой АПИ ключ, либо выключить его, поставив галку внизу.

Также можете тут-же доставить различные Add-ons. Как это сделать, описано в документации, не буду акцентировать внимание:

А теперь, чтобы при каждом запуске, не изменять конфигурации давайте сохраним их на хосте. И далее сделаем так, чтобы все, что ZAP создал в ходе своей работы, мы с легкостью могли взять с хостовой системы, не боясь, что что-то удалится при очередном перезапуске контейнера. Для этого:
  • копируем домашнюю папку и webswing.config с контейнера на хост. Допустим у меня все будет находиться в папке /www/owasp_zap/
    Bash:
     cd /www/owasp_zap/
    docker cp owasp-zap:/zap/webswing/webswing.config ./webswing/webswing.configdocker cp owasp-zap:/home/zap/ ./zap/
  • Далее мы увидим, что все файлы у нас буду под root. Для того, чтобы все заработало и пользователь в докере смог зацепить данные файлы. На полученные папки и файлы нам надо изменить владельца. Следующими командами, узнаем uid и guid необходимые и меняем владельца.
    Bash:
    root@cs30975:/www/owasp_zap# docker exec owasp-zap id
    uid=1000(zap) gid=1000(zap) groups=1000(zap)
    root@cs30975:/www/owasp_zap# chown -R 1000:1000 ./zap && chown -R 1000:1000 ./webswing
  • теперь мы можем грохнуть контейнер
    docker stop owasp-zap
  • И запустить его с сохраненными ранее данными.
    Код:
    docker run --rm -v $(pwd)/zap:/home/zap -v $(pwd)/webswing/webswing.config:/zap/webswing/webswing.config -u zap -p 8080:8080 -p 8090:8090 --name owasp-zap -d owasp/zap2docker-stable zap-webswing.sh
Как тут видно, наша команда немного увеличилась в размерах, а именно появился флаг -v (-volume). Теперь туда ZAP может записывать все свои данные, измененные конфиги и т.д, и мы их сможем оттуда забирать, а также без помощи докера отдавать ему файлы.

СОВЕТ: На начальном этапе, когда данные чистые, советую указанные папки сохранить в GIT. (в игнор можно поставить пару папок, а именно: sessions, reports). Сессии достаточно объемны (могут достигать нескольких Гб) и их сохранять не очень желательно в гите. Ну отчетам в гите тоже не место. В идеале эти папки мапить вообще не надо, а сразу запускать с нужными параметрами zap. В режиме zap.sh мы это сможем сделать. В webswing есть одно предположение как это сделать (будет озвучено ниже), но пока не пробывал. Так же вопрос возникает с добавлением Add-ons при запуске.

webswing.config
Ссылка на документацию настроек webswing оставлю здесь:

Итак. При тесте я словил баг. Что сессия у меня не хотела выходить, но при этом она не сбрасывалась и в общем в GUI я не мог попасть. Начал поиск решения проблемы. Решение заключается в данном файлике webswing.config. По факту после копирования данного файла из контейнера, советую поменять параметр: "maxClients" : 5 (по умолчанию, значение равно 1).
Так же отмечу интересный параметр:
JSON:
"launcherConfig" : {
        "args" : "-host 0.0.0.0 -port 8090",
Подозреваю, что это как раз и есть обходной путь из совета раздела WEBSWING. Т.е. тут в параметре args необходимо дописать с какими флагами будет запускаться zap.sh. По факту надо скопировать и вставить флаги и их данные из раздела ниже, но повторюсь, мною не тестировалось, при желании можете протестировать и отписаться в теме.

ZAP.sh режим
На самом деле это основной режим, в котором планируется постоянная эксплуатация OWASP ZAP. Т.е. режим в котором работает OWASP ZAP как прокси и доступно API. В большинстве случаев этого достаточно. Здесь не буду много расписывать. Приведу только команду запуска, как это выглядит у меня:
Bash:
docker run --rm -u zap -p 8090:8090 --env ZAP_PORT=8090 --name owasp-zap -d owasp/zap2docker-stable zap.sh -daemon -host 0.0.0.0 -port 8090 -config api.key=123456789 -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true
Обратите внимание, тут я не маплю папки из раздела webswing. Предполагаем, что в пайплайне это лишнее. Если мапить папки, как в разделе WEBSWING, то команда чуть измениться на и оборвется на указании порта. Если не мапить, остается открытым вопрос, по поводу сохранения установленных Add-ons. Как их доставлять и устанавливать в случае необходимости.

Справка о параметрах команды:
--env ZAP_PORT=8090 -(переписываю дефолтный порт, на котором запуститься прокси и АПИ, по дефолту это 8080)
zap.sh -daemon -host 0.0.0.0 -port 8090 -config api.key=123456789 -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true - это команда запуска демона zap.sh с определенными параметрами.

Теперь нам надо бы проверить, а запустился ли zap, и все корректно и через него можно запускать регрессионные тесты. Так сказать, надо создать некий HOOK для запуска тестов. Приведу тут команду, которой это все можно проверить в bash через утилиту zap-cli. (в будущем будет модифицироваться в Python):
Bash:
while docker exec owasp-zap zap-cli  status | grep -q "ZAP is not running"; do sleep 1; echo "Waiting.."; done
Тут все просто, пока Waiting то запускаться нельзя. Тут команда больше для справки, чтобы было видно, как можно проверить готовность ZAP к работе.

Примечание: при тестировании данного режима у меня возник вопрос, а создаются ли дефолтно сессии при запуске zap.sh? И надо ли их создавать через запросы к API? Ответ был найден. Сессии создаются. И ни что не препятствует не создавать сессию, а сразу создавать контекст (при необходимости). Об этом поговорим в дальнейших частях.

API и организация к нему доступа
Предположим что мы запустились в одном из указанном режиме выше. Будем предполагать, что это режим Webswing.

Мы перешли по ссылке: и запустили сессию.

Отлично. Теперь проверим работу прокси сервера:

Поставим в нашем любимом браузере proxy на 1.1.1.1 port 8090 (ведь именно там работает прокси в данном режиме судя по команде запуска докера).

proxy.jpg


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

Теперь нам надо попасть к API и получить его описание. Попробуем открыть:
и увидим печальную надпись после долгого ожидания:

Failed to read within 20 seconds, check to see if the site is available and if so consider adjusting ZAP's read time out in the Connection options panel.

Вот тут я потерял много времени. (т.к. эта ошибка может и не выводиться в принципе, а просто не открываться страница).

РЕШЕНИЕ: необходимо обращаться к api только по hostname . Т.е. по адресу . Поэтому для машины, с которой будете осуществлять доступ к АПИ необходимо в /etc/hosts прописать следующее:
Код:
1.1.1.1    zap
После этого у вас все должно заработать.

Также если вы развернули zap в docker на локальном компе, полезная команда, для получения IP zap контейнера выглядит так:
Bash:
docker inspect owasp-zap | grep IPAddr
            "SecondaryIPAddresses": null,
            "IPAddress": "172.17.0.4",
                    "IPAddress": "172.17.0.4",
Далее необходимо прописать в /etc/hosts полученный адрес по схеме выше.
Для локальной установки ZAP все работает предсказуемо, и можно зайти через

ОСТАНОВКА и удаление контейнера. Иные полезные команды
После того как попользовались, чтобы не оставлять контейнер работающим, его можно остановить командой docker stop owasp-zap. Т.к. мы указывали ранее флаг --rm то данный контейнер удалиться после остановки.

Также посмотреть все запущенные и работающие контейнеры можно через
docker ps
Посмотреть совсем все контейнеры( в т.ч. нештатно работающие или остановленные) можно через docker ps -a
Удаление контейнера: docker rm owasp-zap

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

В следующей части поговорим об основных понятиях ZAP. Возможно уже рассмотрим скрипты API на питоне. Все будет зависеть от объема данных которые будут попадать в статью.
 

chelsea

One Level
03.04.2020
2
1
BIT
0
Сначала хотел высмеять что пробрасываются иксы и нет никакой секурити изоляции, но заглянул в докер файл увидел что графика идет через vnc.
Уж лучше 1 раз поставить на голый линукс с иксами zap/любую другую gui программу и запускать ее в виртуалке с пробросом через SPICE протокол, чем запускать gui программ в докере с vnc.
Использовать gui программы в докере - это создание себе дополнительные проблемы на ровном месте. Потому что, сначала тебе в докере нужна одна программа, а завтра еще одна, а после надо прокинуть железку/флешку/аудио колонки/микрофон/кусок диска/оперативки/поснифирить траффик через tcpdump и т.д.. И все это надо будет делать через докер, а не стандартными средствами ОС, придется переписывать докер файл/свой супер универсальный скрипт скрипт для запуска GUI программы, пересобирать образ/тестировать под каждый случай, КАРЛ.
А еще придется бороться с багами vnc viewer-ов (есть парочка досадных багов у всех популярных вьюверов, с пробросом кнопок из тайловых wm, и эти баги уже как 10лет не фиксятся). Что там в этом докере запускается openbox? придется еще бороться с его глюками по отрисовки или открытию/закрытию/ресайзингу окошек GUI программ.
 
  • Нравится
Реакции: Shadow User

zakrush

Well-known member
21.03.2018
81
118
BIT
0
Уж лучше 1 раз поставить на голый линукс с иксами zap/любую другую gui программу и запускать ее в виртуалке с пробросом через SPICE протокол, чем запускать gui программ в докере с vnc.
Вы видимо суть всего проекта не уловили, и не уловили цель, почему в докере запустил. Весь этот большой докер не будет таскаться, и в конечном итоге вообще не будет использоваться. Он нужен только для отладки, чтобы быть максимальным приближенным к боевой системе. Далее, когда будут написаны скрипты и все отлажено. Подводные камни все пойманы, я перейду на урезанный докер zap-bore. Где нет ни каких GUI и прочего. А только голый ZAP. На целевой системе ГУЙ ни к чему.
А голый линукс я посмотрю как вы будете использовать в CI/CD особенно масштабировать его, и направлять на несколько хостов сразу. (можно и с VM заморочиться) но это путь дольше и время деплоя увеличится. + надо самому все поддерживать и собирать систему. Я немного не админ, чтобы этим заморачиваться.
Пока по использованию, ни каких багов не замечено. НИ чего переписывать (Докер файл и скрипты не надо). Все будет использоваться исключительно готовое, разработчиками. Писаться будут только скрипты обращения к API и скрипты ZAP(обработки и модификации запросов, правил авторизации и хождения по приложению и т.д.), а это на Docker ни как не завязано.
 
Последнее редактирование:

chelsea

One Level
03.04.2020
2
1
BIT
0
.. на урезанный докер zap-bore. Где нет ни каких GUI и прочего. А только голый ZAP.
А голый линукс я посмотрю как вы будете использовать в CI/CD особенно масштабировать его, и направлять на несколько хостов сразу. (можно и с VM заморочиться) но это путь дольше и время деплоя увеличится.

Если не будет использоваться GUI, а код zap не будет меняться, тогда зачем вообще нужно его запихивать в докер. Можно же zap и так запускать в нескольких инстансах с разными профилями, изолировав процессы с помощью selinux или firejail.
 

zakrush

Well-known member
21.03.2018
81
118
BIT
0
@zakrush Спасибо за интересную статью. Когда продолжения ждать?
Постараюсь в ближайшую неделю. Но там больше не статья будет. Больше уже готовый код, с кучей интеграцией. Времени нет ни как обезличить все данные и шаблоны. На самом деле я уже даже запускаюсь чуть подругому, ни как в статье описано. НО общий принцип остался вроде.
 

fourth_4

One Level
10.04.2020
2
0
BIT
0
Постараюсь в ближайшую неделю. Но там больше не статья будет. Больше уже готовый код, с кучей интеграцией. Времени нет ни как обезличить все данные и шаблоны. На самом деле я уже даже запускаюсь чуть подругому, ни как в статье описано. НО общий принцип остался вроде.
Отлично, будет интересно почитать. Сам пытаюсь построить подобную систему, но с ZAP-ом особого опыта нет. Думаю ваш опыт мне очень поможет։)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!