WAF — своими руками25.01.2025 23:15

05fb7ec048f584f52b09ffc8eb264915.png

Здравствуйте!

В данной статье мы рассмотрим пример реализации шлюза вэб фильтрации на базе ПО с открытым исходным кодом (стек Apache/ModSecurity/OWASP CRS/ProjectHoneyPot)

Посмотрим как это все объединить в одно целое. Где взять и как подгрузить сигнатуры. Как отладить (дифолтные конфигурации — не наш метод). В процессе напишем пару дополнительных правил, наступим на грабли, найдем что-то похожее на изящный выход из ситуации. Узнаем как собирать статистику о ботах и как от них защититься.

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

Штош, приступим !

Введение

Для начала отвечу на один из главных вопросов — почему OpenSource? — Все просто, можно взять F5, Imperva, есть решения и у Fortinet, и у Check Point, и у Palo. Конечно же есть решения Российских вендоров. Взять-то конечно можно, но вот доступ к таким технологиям имеет лишь не самая большая аудитория. По этой причине рассматриваем OpenSource

Очень актуальный сегодня вопрос согласования с ИБ оставим за скобками. Риски, как ни крути присутствуют и я бы 10 раз подумал (и отказался) прежде чем реализовывать нечто подобное для защиты критической инфраструктуры.

В то же время, данное решение может подойти малому бизнесу и энтузиастам в ИТ. Ведь сколько у нас приложений опубликовано в сеть с минимальной фильтрацией ? А сколько из них обновляется ?

И так, что же такое WAF?

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

Вендорские решения охватывают несколько больший функционал. Как правило это:

  • Анализ трафика приложения облегчающий составление политик фильтрации

  • Фильтрация OWASP сигнатурами (защита от XSS, SQL инджектов, анализ HTTP заголовков, защита от известных уязвимостей нулевого дня и так далее)

  • Защита от ботов

  • Некоторые вендоры в довесок предоставляют функционал NGF. Здесь вам и песочница, и IPS, и защита от вредоносного ПО. Все стандартно.

  • Так же встречаются WAF с функцией балансировщика

Что из этого мы можем реализовать ? — Многое. Придется ли при этом страдать изобретая велосипед ? — Несомненно

  • Анализ, репорты ? Только своими руками. Можно (и даже нужно) конечно логи перенаправлять в SIEM именно с этой целью

  • OWASP? Ну, да. Никаких вам графических интерфейсов и только хардкор

  • Детекция приложений ? Теоретически тоже да. Здесь придется писать собственные сигнатуры

  • Защита от ботов ? В какой-то мере.

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

Но в общеобразовательных целях мы будем рассматривать OpenSource

ModSecurity

ModSecurity есть ничто иное как кросс-платформенный модуль шлюза вэб фильтрации для вэб сервера. Поддерживается как Apache, так и Nginx. Может выполнять фильтрацию своими силами, а может использовать сигнатуры OWASP CRS

Установка здесь тривиальная и не займет много времени. Предположу что у вас уже есть Linux дистрибутив и вэб сервер (здесь и далее рассматриваем Debian + Apache)

apt install libapache2-mod-security2
a2enmod security2
mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
grep SecRuleEngine /etc/modsecurity/modsecurity.conf
grep SecResponseBodyAccess /etc/modsecurity/modsecurity.conf
cat /etc/apache2/mods-enabled/security2.conf
systemctl restart apache2
systemctl status apache2

OWASP CRS

Что же это такое? Не более чем общий набор статических правил оценки и фильтрации трафика для ModSecurity

Установка

cd /var/tmp

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.10.0.tar.gz
wget https://github.com/coreruleset/coreruleset/releases/download/v4.10.0/coreruleset-4.10.0.tar.gz.asc
gpg --fetch-key https://coreruleset.org/security.asc
gpg --edit-key 

gpg> trust
Your decision: 5 (ultimate trust)
Are you sure: Yes
gpg> quit

gpg --verify coreruleset-4.10.0.tar.gz.asc v4.10.0.tar.gz
mkdir /etc/crs4
tar -xzvf v4.10.0.tar.gz --strip-components 1 -C /etc/crs4
cd /etc/crs4
mv crs-setup.conf.example crs-setup.conf
nano -w /etc/apache2/mods-enabled/security2.conf
# Include OWASP ModSecurity CRS rules if installed
#IncludeOptional /usr/share/modsecurity-crs/*.load
IncludeOptional /etc/crs4/crs-setup.conf
IncludeOptional /etc/crs4/plugins/*-config.conf
IncludeOptional /etc/crs4/plugins/*-before.conf
IncludeOptional /etc/crs4/rules/*.conf
IncludeOptional /etc/crs4/plugins/*-after.conf
systemctl restart apache2
systemctl status apache2

Настройка

  • Разбираемся с конфигом. Конфиг, если его прочитать, сам ответит на все возникающие вопросы.

nano -w /etc/crs4/crs-setup.conf
SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"

  • Выставляем Paranoia Level = 3 (А почему бы и да ? Секурность мы с вами повысим, а с ложными срабатываниями разберемся при необходимости) Кто бы знал во что это выльется :)

SecAction \
    "id:900000,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.blocking_paranoia_level=3"
SecAction \
    "id:900010,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.enforce_bodyproc_urlencoded=1"
SecAction \
    "id:900100,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.critical_anomaly_score=5,\
    setvar:tx.error_anomaly_score=4,\
    setvar:tx.warning_anomaly_score=3,\
    setvar:tx.notice_anomaly_score=2"
SecAction \
    "id:900110,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.inbound_anomaly_score_threshold=5000,\
    setvar:tx.outbound_anomaly_score_threshold=4000"
SecAction \
    "id:900115,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.reporting_level=2"
SecAction \
    "id:900130,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.enable_default_collections=1"

  • Включаем ограничение HTTP методов. Я добавил PUT метод используемый CMS (Здесь и далее — осторожнее, ибо многое зависит от опубликованных приложений. Я писал под себя, по этому внимательно и без копипасты) Подробнее про логику здесь и здесь

SecAction \
    "id:900200,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT'"
SecAction \
    "id:900220,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |text/html|'"
SecAction \
    "id:900230,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:'tx.allowed_http_versions=HTTP/1.1'"
SecAction \
    "id:900280,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:'tx.allowed_request_content_type_charset=|utf-8|'"

  • Ограничиваем количество аргументов, длину имени аргумента и его собственную длину, суммарную длину всех аргументов.

SecAction \
    "id:900300,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.max_num_args=255"
SecAction \
    "id:900310,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.arg_name_length=100"
SecAction \
    "id:900320,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.arg_length=400"
SecAction \
    "id:900330,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.total_arg_length=64000"
SecAction \
    "id:900340,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.max_file_size=1048576"
SecAction \
    "id:900350,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.combined_file_sizes=1048576"
SecAction \
    "id:900950,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.crs_validate_utf8_encoding=1"

  • Остальное оставляем по умолчанию

  • Включаем фильтрацию в конфигурации виртуального хоста

nano -w /etc/apache2/sites-enabled/null.conf
# WAF

  SecRuleEngine On

systemctl restart apache2

Отладка

tail -f /var/log/apache2/modsec_audit.log | grep -iE ".*notice.*|*.warning.*|.*error.*|.*critical.*"

Проблема 1

Message: Rule 7faba9cd8db8 [id "951250"][file "/etc/crs4/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"][line "365"] - Execution error - PCRE limits exceeded (-47): (null).
nano -w /etc/modsecurity/modsecurity.conf
# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 500000
SecPcreMatchLimitRecursion 250000

Проблема 2

Message: Warning. Match of "within %{tx.allowed_request_content_type}" against "TX:content_type" required. [file "/etc/crs4/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1012"] [id "920420"] [msg "Request content type is not allowed by policy"] [data "|multipart/form-data|"] [severity "CRITICAL"] [ver "OWASP_CRS/4.10.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153"] [tag "PCI/12.1"]
nano -w /etc/crs4/crs-setup.conf
SecAction \
    "id:900220,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |text/html|'"

Проблема 3 — фундаментальная

Message: Warning. Found 24 byte(s) in ARGS:name outside range: 32-36,38-126. [file "/etc/crs4/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1611"] [id "920272"] [msg "Invalid character in request (outside of printable chars below ascii 127)"]

пример
ARGS:name: \xd0\x9e\xd1\x82\xd0\xbb\xd0\xb0\xd0\xb4\xd0\xba\xd0\xb0

  • Все дело в том, что OWASP CRS отказывается в кириллические кодировки, а у нас именно тот случай. (я пробовал подсунуть ему и windows-1251 charset, и koi8-r — безрезультатно. Разработчик отделывается общими фразами аля «дефолтный конфиг работает». Не знаю, не проверял, да и зачем нам дефолт ? Что либо с этим сделать не понижая PL практически невозможно, посему пишем байпас.

SecRule ARGS:name "@rx (.*)" \
        "id:001001001,\
        phase:1,\
        pass,\
        nolog,\
        msg:'Charset Check Bypass - Cyrilic encoding is not supported',\
        ctl:ruleRemoveById=920272"

Проблема 4

Message: Warning. Matched phrase "var/log" at ARGS:html. [file "/etc/crs4/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "116"] [id "930120"] [msg "OS File Access Attempt"] [data "Matched Data: var/log found within ARGS:html: ***** tail -f /var/log/apache2/modsec_audit.log

  • Здесь он уже умничает при анализе содержимого страницы :) Выхода три: править сигнатуру, писать байпас либо не использовать ругательных слов в контенте. Первое отработает ровно до первого апдейта, третье, в нашем случае, не вариант. Пишем байпас.

SecRule ARGS:html "@rx (.*)" \
        "id:001001002,\
        phase:1,\
        pass,\
        nolog,\
        msg:'Matched pattern bypass',\
        ctl:ruleRemoveById=930120"

Проблема 5 — отсюда вытекающая

  • По факту мы с вами столкнулись с тем, что у нас огромное количество ложных срабатываний по причине используемой кодировки и по причине весьма специфичного контента. Что же делать ? Глобально — либо понижать PL либо писать байпасы (выбор ваш). Плохо и то, и другое. Поэтому учитывайте специфику при подборе WAF.

  • Я уже был готов понижать PL и вовсю парсил логи, как пришло озарение:) 99% процентов срабатываний происходит в момент публикации контента из админки. Что это значит ? Не более чем то, что мы можем привязаться к HTTP REQUEST_METHOD и сделать глобальный байпас всего.

  • Плюсы-минусы ? Плюсы — избавимся от срабатываний по кодировке и истерии по поводу скриптового контента. Минусы — на сайте есть формы поиска и авторизации, так что в них можно будет долбиться в обход политик.

  • Выбор в целом сводится к тому чтобы либо принять риски, либо писать 100500 правил без гарантии отсутствия ложных срабатываний в будущем. Я эти риски принял. В целом можно прикрутить IPS с сигнатурами на POST метод и спать несколько спокойнее.

  • Мои кривые потуги в парсер если кому будет нужно

echo > /var/log/apache2/modsec_audit.log

cat /var/log/apache2/modsec_audit.log | grep -iE ".*notice.*|*.warning.*|.*error.*|.*critical.*" | perl -ne 'm/.*(ARGS:\w+)/ && print "$1\n"' | sort | uniq >> /var/tmp/args.txt

cat /var/log/apache2/modsec_audit.log | grep -iE ".*notice.*|*.warning.*|.*error.*|.*critical.*" | perl -ne 'm/ARGS:html.*(id "\d+")/ && print "$1\n"' | sort | uniq >> /var/tmp/args_html.txt

cat /var/tmp/args_html.txt | sed 's/id \"/ctl:ruleRemoveById=/g' | sed 's/\"/\,\\/g' >> /var/tmp/html_rules.txt
SecRule REQUEST_METHOD "@rx (POST|PUT)" \
        "id:001001001,\
        phase:1,\
        pass,\
        nolog,\
        msg:'Admin Panel WAF bypass',\
        ctl:ruleEngine=Off"
SecRule REMOTE_ADDR "@ipMatchFromFile admin_panel_whitelist.txt" \
        "id:001001001,\
        phase:1,\
        pass,\
        log,\
        msg:'Admin Panel WAF bypass - POST|PUT only',\
        ctl:ruleEngine=Off,\
        chain"

SecRule REQUEST_METHOD "@rx (POST|PUT)"
nano -w /etc/crs4/crs-setup.conf
SecAction \
    "id:900110,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.10.0',\
    setvar:tx.inbound_anomaly_score_threshold=5,\
    setvar:tx.outbound_anomaly_score_threshold=4"
Action: Intercepted (phase 2)
Apache-Handler: application/x-httpd-php
Stopwatch: 1737805433007092 8481 (- - -)
Stopwatch2: 1737805433007092 8481; combined=5102, p1=911, p2=2835, p3=0, p4=0, p5=1355, sr=75, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.7 (http://www.modsecurity.org/); OWASP_CRS/4.10.0.
Server: Apache
Engine-Mode: "ENABLED"
fail2ban-client status apache-modsecurity
Status for the jail: apache-modsecurity
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- File list:        /var/log/apache2/error.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     6
   `- Banned IP list:   193.41.206.98

Бонусные правила

nano -w /etc/apache2/mods-enabled/security2.conf
# Manipulating server signaturte
ServerTokens Min
SecServerSignature "null"
systemctl restart apache2

  • Проверяем

curl -i --header 'Host: null.somedomain.name' https://null.somedomain.name | less
Server: null

  • Далее подумаем, а нужно ли нам такое:) Представим, что мы хостим некий контент на который прямых ссылок нет и не предвидится. Технически — можно пройтись каким-нибудь кроулером по сайту в поисках HTTP 200 и дальше уже с этим работать (вопрос сложности и целесообразности оставим в стороне)

  • Что с этим можно сделать ? Описанная ситуация предполагает некое количество HTTP 404 возвращенных клиенту до того как он получит HTTP 200, а с этим уже можно работать.

  • Напишем что-то такое (улетаем в бан на день после 10ти HTTP 404)

SecRule REMOTE_ADDR "@ipMatchFromFile http_404_whitelist.txt" \
        "id:001002001,\
        phase:1,\
        pass,\
        nolog,\
        msg:'IP Whitelisted for HTTP 404',\
        ctl:ruleRemoveById=001002002,\
        ctl:ruleRemoveById=001002003"

SecRule RESPONSE_STATUS "@streq 404" \
        "id:001002002,\
        phase:3,\
        pass,\
        setvar:IP.bad_http_request=+1,\
        expirevar:IP.bad_http_request=86400,\
        log,\
        msg:'Page Not Found - HTTP 404 - Count %{IP.bad_http_request}'"

SecRule IP:BAD_HTTP_REQUEST "@gt 10" \
        "id:001002003,\
        phase:3,\
        drop,\
        log,\
        msg:'Client Exceeded HTTP 404 Request Limit of 10 - Banned For a Day'"

Project Honey Pot

Что это за зверь такой ? Не более чем база IP адресов ботов (впрочем, чуть более чем просто база, но об этом далее)

Установка «ловушки»

Несколько слов о том, зачем это все — в первую очередь позволяет собрать дополнительную статистику о разных ботах: роботах, кроулерах, спамерах (в том числе в камментах :)) и прочих харвестерах.

Работает все до нельзя просто:

  • Ханипот генерит скрипт, который потом можно захостить, активировать и тем самым получить свой ханипот

  • Дальше задача насытить сайт ссылками

  • Ну, а дальше ждем пришествия роботов «прокликивающих» абсолютно все, в том числе нашу «ловушку»

  • Дальше данные о попаданце сливаются на ханипот и, собственно, к нам

  • Так же скрипт позволяет позволяет скормить ботам некоторое количество почтовых адресов и если на эти адреса пойдет спам рассылка — отправитель попадает в черный список 

Надеюсь вы поняли

Приступим !

  • Регистрируемся на сайте и скачиваем скрипт для интеграции с сайтом (в нашем случае похопе). 

  • Публикуем и выставляем разрешения

chown -R root:www-data /var/www/bookstack/public/hello.php
chmod 644 /var/www/bookstack/public/hello.php

  • Вызываем браузером и активируем

  • Добавляем в footer ну или куда-либо еще (только так, чтоп человекам не видно было)


            

SecContentInjection On
SecStreamOutBodyInspection On

SecRule RESPONSE_CONTENT_TYPE "@contains text/html" \
        "id:001003001,\
        phase:4,\
        pass,\
        nolog,\
        chain"

SecRule STREAM_OUTPUT_BODY "@rsub s/<\/html>/<\/a><\/html>/"

Привязываем черные списки к ModSecurity

Как было понятно из предыдущей главы, если где-то есть база не очень хороших дядь и теть, то было бы странно ей не воспользоваться.

  • Генерируем ключ доступа к API на сайте проекта

  • Создаем правило (убедитесь что его айдишник отрабатывает первым)

nano -w /etc/crs4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
# HTTPBL Check
SecHttpBlKey API ключ

SecRule TX:REAL_IP|REMOTE_ADDR "@rbl dnsbl.httpbl.org" \
        "id:001001001,\
        phase:1,\
        capture,\
        block,\
        log,\
        msg:'HTTPBL Match of Client IP.',\
        logdata:'%{tx.httpbl_msg}',\
        setvar:tx.httpbl_msg=%{tx.0},\
        chain"

SecRule TX:0 "threat score (\d+)" "chain,capture"
SecRule TX:1 "@gt 20"

Заключение

На этом пока остановимся. Впереди Snort, DDoS Offloading, возможно SIEM (логи смотреть было бы крайне полезно)

Спасибо всем кто дочитал до конца ! По традиции — кросс линк ProjectNull (сеошник во мне не умер :))

Буду рад ответить на вопросы по теме

© Habrahabr.ru