Статья 4 «Мониторинг атак и разбор функционала Вебмониторэкс»

Онлайн курс: Вебмониторэкс Getting Started

Приветствуем всех читателей! В данной статье курса «Вебмониторэкс Getting Started» мы проведём ряд автоматизированных атак с помощью утилиты GoTestWAF, рассмотрим логи в дашборде, переведём ноду в режим блокировки и заблокируем ручную XSS атаку.

1. Запуск GoTestWAF

Варианты запуска утилиты описаны в Github. Мы же клонируем репозиторий на Kali Linux и запустим при помощи go run:
git clone https://github.com/wallarm/gotestwaf.git
go run ./cmd --url=http://45.12.231.63 --skipWAFIdentification --blockStatusCodes 200
После запуска начинается отправка запросов на наш URL:

В консоли управления во вкладке Events мы видим, что нода детектит нашу атаку:

2. Чтение логов

Date - показывает дату атаки и её длительность;
● Hits - количество хитов в атаке;
● Payloads - тип атаки и количество уникальных вредоносных пэйлоадов;
● Top IP / Source - адрес источника атаки; если атаку проводили с нескольких айпи адресов, то указывается тот, с которого пришло больше всего запросов;
● Domain / Path - адрес атакуемого ресурса;
● Code - код ответа ресурса; если ответов несколько, то отображается самый частый;
● Parameter - параметры хита и теги парсеров, которые были применены к запросу;
● Active verification - статус перепроверки атаки;
При раскрытии атаки мы видим каждый хит отдельно. А также теги векторов атак, размер пакета с ответом ресурса и время ответа на запрос. Ещё из этой панели мы можем создать кастомное правило для каждого хита и/или отметить его как False Positive.

Выберем в данной атаке только XSS:

И затем раскроем один из хитов:

Мы видим: айди запроса, адрес и айди ноды, которая задетектила этот хит, теги и сам HTTP запрос с заголовком и телом.
Можем раскрыть тело запроса, вредоносная нагрузка подсвечена жёлтым:

3. Блокировка вредоносных запросов

Давайте переведём ноду в режим блокировки.
Для этого открываем /etc/nginx/conf.d/default.conf и меняем значение параметра wallarm_mode с «monitoring» на «block»:

Далее нам нужно открыть файл /etc/nginx/nginx.conf и в блок http добавить строку wallarm_block_page &/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html response_code 445 type=attack;
Таким образом мы укажем кастомную страницу и код ответа, которые будут отображаться при блокировке запроса. В данном случае мы используем стандартную страницу от Вебмониторэкс, но можно также использовать и свою.
Перезапускаем nginx командой systemctl restart nginx
Попробуем в браузере выполнить атаку типа Path Traversal: http://45.12.231.63/etc/shadow.
Нода заблокировала запрос:

Можно увидеть указанными наш внешний айпи, время блокировки и айди запроса.
Откроем наш хит в консоли управления Вебмониторэкс.
В поле Code мы видим, что код ответа 445, как мы и указали в конфиге:

Справа находится кнопка “False”. Если мы считаем, что это легитимный запрос, с помощью “False” можно пометить его как ложно-положительный:

При этом консоль напишет, что применение настроек может занять от 2х до 15ти минут:

Ждём и пытаемся перейти на http://45.12.231.63/etc/shadow

Результат: нода пропускает запрос до ресурса.
Также можно отметить всю атаку как false positive:

4. Обучение ноды на боевом и тестовом трафике

Рекомендуем после установки ноды перевести её в режим мониторинга и разрешить весь трафик до защищаемого ресурса.

Нода анализирует весь проходящий трафик и синхронизируется с вычислительным кластером Вебмониторэкс, который на основе этих данных создаёт “портрет” вашего приложения. Он начинает лучше понимать, какие запросы приходят к вашему приложению, и эффективнее выявлять аномалии в трафике.

После 1-2 недель мониторинга можно переключать ноду в режим блокировки и следить, нарушается ли трафик до ресурса.

В следующей заключительной статье мы рассмотрим сферы применения Вебмониторэкс, нюансы лицензирования продукта и поговорим о запуске пилотного проекта.

Пройти сертификацию

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

Сертифицироваться