User Tools
Table of Contents
DPI из подручных материалов
Всем привет!
Однажды, много лет назад, во времена эпидемии вируса Code Red, я работал сисадмином в одном вузе и невежливо ответил на электронное письмо из какого то-банка с требованием немедленно прекратить атаку на их веб сервер, работающий под управлением Apache, через месяц пришло бумажное письмо от их службы безопасности, и завертелось. Так я познакомился с системой Snort, которая некоторое время защищала Интернет от наших студентов. Со временем, большая часть трафика стала https, и решение потеряло смысл, но, есть места, где он снова превращается в http, например после https прокси. Тут то мы и сможем его “подсмотреть”, выявить атаки и заблокировать злоумышленника!
Что бы было интереснее, не будем рассматривать реальный кейс, а воспроизведем все “в домашних условиях”. На единственной системе развернем https прокси, веб приложение за ним, и защитим от атак на основе анализа содержимого http запросов. Потребуется VirtualBox (или любой другой гипервизор) и дистрибутив Linux, например Ubuntu, там Snort имеется в виде пакета. Можно взять мой готовый ova образ:
https://val.bmstu.ru/unix/img/My%20Documents/ubuntu_24.04_01.ova
и выполнить 1-й шаг из этой статьи
Шаг 2. Разворачиваем http приложение
Можно развернуть что-нибудь поинтереснее, но, сути это не меняет, поэтому обойдемся простым вариантом:
$ sudo -i
# apt update
# apt install docker.io
# docker run --name http-app -d --restart=always httpd
# docker inspect http-app -f {{.NetworkSettings.IPAddress}}
# curl http://172.17.0.2
http приложение готово!
Шаг 2. Создаем сертификат для https прокси
Для “игрушечного” примера подойдет само подписанный сертификат c атрибутами “по умолчанию”
# openssl genrsa -out /etc/ssl/private/http-app.key 2048 # openssl req -new -x509 -days 3650 -key /etc/ssl/private/http-app.key -out /etc/ssl/certs/http-app.crt
На все “вопросы” последней команды достаточно нажать Enter (даже про Common Name, поскольку тестировать все будем по ip адресу)
Шаг 3. Разворачиваем https прокси
В качестве https прокси рассмотрим nginx (можно haproxy, суть не изменится). Поскольку тестировать все будем по ip адресу, настроим перенаправление любых запросов (server_name _) на 443 порт в наше http приложение. X-Forwarded-For в нашем случае нужен потому, что только в этом заголовке будет ip адрес клиента в трафике между https прокси и приложением.
# apt install nginx # nano /etc/nginx/sites-available/http-app
server {
listen 443 ssl;
server_name _;
ssl_certificate /etc/ssl/certs/http-app.crt;
ssl_certificate_key /etc/ssl/private/http-app.key;
location / {
proxy_pass http://172.17.0.2;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
# ln -s /etc/nginx/sites-available/http-app /etc/nginx/sites-enabled/http-app # systemctl restart nginx.service
Теперь наше http приложение должно быть доступно по URL: https://ip_адрес_виртульной_машины/ правда, браузер будет ругаться на сертификат и придется “перейти на сайт небезопасно”
Шаг 4. Разворачиваем IDS Snort
# apt install snort
В вопросах инсталлятора про сетевые интерфейсы указываем docker0, в нашем случае именно через него идет трафик между https прокси и http приложением в контейнере. Остальные ответы “по умолчанию”, результат работы инсталлятора записывается в файл:
# less /etc/snort/snort.debian.conf
... DEBIAN_SNORT_INTERFACE="docker0" ...
В основном файле конфигурации отключаем проверку контрольной суммы пакетов, поскольку эта функциональность актуальна только для “входящего” трафика, а в нашем случае, http трафик будет “выходить” из интерфейса docker0, добавляем опцию анализа заголовка X-Forwarded-For в http трафике и настраиваем вывод сообщений об обнаруженных атаках в syslog с типом сообщений auth и уровнем важности alert:
# nano /etc/snort/snort.conf
...
# Configure IP / TCP checksum mode
config checksum_mode: none
...
preprocessor http_inspect_server: server default \
...
enable_xff \
webroot no
...
####################################################################
# Step #6: Configure output plugins
...
output alert_syslog: LOG_AUTH LOG_ALERT
...
# systemctl restart snort.service
Для тестирования будем использовать тот самый злополучный Code Red, для которого, как раз, есть правило “из коробки”:
# less /etc/snort/rules/web-iis.rules
... alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS CodeRed v2 root.exe access"; flow:to_server,established; uricontent:"/root.exe"; nocase; reference:url,www.cert.org/advisories/CA-2001-19.html; classtype:web-application-attack; sid:1256; rev:8;) ...
Симулировать атаку можно обращаясь к нашему приложению по URL: https://ip_адрес_виртульной_машины/root.exe
В журнале должны появляться характерные сообщения:
# tail -f /var/log/auth.log
...
2024-05-12T18:06:07.467018+00:00 ubuntu snort[6978]: [1:1256:8] WEB-IIS CodeRed v2 root.exe access [Classification: Web Application Attack] [Priority: 1] {TCP} 172.17.0.1:40890 -> 172.17.0.2:80
...
Но, стоп, в них отсутствует адрес клиента, здесь только адрес прокси и самого приложения!
Оказывается, информация из заголовка X-Forwarded-For попадает в двоичный файл, для анализа которого авторы Snort добавили специальную утилиту:
# u2spewfoo /var/log/snort/snort.alert
...
priority: 1 ip source: 172.17.0.1 ip destination: 172.17.0.2
...
type: 1 datatype: 1 bloblength: 12 Original Client IP: 192.168.1.100
...
Этот файл создается и непрерывно растет с момента запуска Snort, а утилита умеет выводить его только целиком. Для нашей следующей задачи будет удобнее, если полученная таким образом информация будет тоже последовательно писаться в журнал. Пришлось “сочинить” такого “крокодила” (ключи -с +1 команды tail из-за двоичного формата файла, u2spewfoo не умеет читать из STDIN, stdbuf отключает буферизацию ввода и вывода, logger все пишет в syslog от имени приложения snort с типом сообщений auth и уровнем важности info):
# stdbuf -i0 -o0 u2spewfoo <(tail -c +1 -f /var/log/snort/snort.alert) | logger -t snort -p auth.info
В журнале теперь будут появляться такие сообщения (понадобится вторая консоль):
# tail -f /var/log/auth.log
... 2024-05-12T18:16:25.965360+00:00 ubuntu snort: #011type: 1#011datatype: 1#011bloblength: 12#011Original Client IP: 192.168.1.100 ...
Можно оформить запуск “крокодила” через systemd
# nano /etc/systemd/system/snort-alert-unified2-syslog.service
[Unit] Description=Send snort alert_unified2 to syslog After=snort.service [Service] ExecStart=/bin/bash -c '/usr/bin/stdbuf -i0 -o0 /usr/sbin/u2spewfoo <(/usr/bin/tail -c +1 -f /var/log/snort/snort.alert) | /usr/bin/logger -t snort -p auth.info' [Install] WantedBy=multi-user.target
# systemctl enable snort-alert-unified2-syslog --now
Шаг 5. Превращаем IDS в IPS
Теперь в журнале поваляются адреса клиентов, сигнатуры пакетов которых попадают в правила Snort (с правилами все печально, Snort принадлежит Cisco, были платные подписки или бесплатно с месячной задержкой, теперь только Community rules, в составе пакета, ну, и, можно писать свои)
Для чтения журнала и блокировки злоумышленников будем использовать fail2ban
Вообще, он ставится командой:
# apt install fail2ban
но, на текущий момент (май 2024) в 24-й ubuntu он не работает (надеюсь, починят) и приходится устанавливать его так:
# wget https://launchpad.net/ubuntu/+source/fail2ban/1.1.0-1/+build/28291332/+files/fail2ban_1.1.0-1_all.deb # dpkg -i fail2ban_1.1.0-1_all.deb
В любом случае, конфигурация выглядит так:
# nano /etc/fail2ban/filter.d/snort_filter.conf
[Definition] failregex = .*Original Client IP: <HOST>.*
# nano /etc/fail2ban/jail.d/snort_jail.conf
[snort] enabled = true bantime = 300 filter = snort_filter maxretry = 3 logpath = /var/log/auth.log action = iptables-allports
# systemctl restart fail2ban.service
Вот тут я “забанил” сам себя и потерял history команд при подготовке статьи, так что лучше продолжать “атаки” с другого домашнего устройства, например с телефона :)
https://ip_адрес_виртульной_машины/root.exe
В журнале можно наблюдать реакцию fail2ban на “атаки”:
# tail -f /var/log/fail2ban.log
А также снять блокировку:
# fail2ban-client status snort # fail2ban-client set snort unbanip <IP>
Спасибо что дочитали, надеюсь было интересно, буду рад ответить на вопросы!
