Запрос отклонен waf 444 что это
Почему (сегодня) return 444 не всегда полезен
В web-сервере Nginx есть замечательный код ответа 444, который «закрывает» соединение без отправки данных. Данный функционал весьма полезен при фильтрации паразитного трафика — если мы уверены, что клиент по каким-то критериям не является валидным, то нет необходимости его уведомлять, например, 403-м ответом. Эффективнее просто прекратить передачу данных, что, зачастую, позволяет существенно снизить нагрузку на сервер.
Рекомендации использовать такие ответы можно встретить повсеместно в инструкциях по блокировках переходов по ссылкам с популярных сайтов и реферального спама, защите от DDoS и т.п.
И, в общем-то, на протяжении многих лет эти советы можно было использовать почти не глядя, но… современные браузеры не стоят на месте и периодически преподносят нам новые сюрпризы.
Google Chrome 67.0.3396.99 (Официальная сборка), (64 бит)
Firefox Quantum 61.0 (64-бит)
Я взял для опытов только браузеры Chrome и Firefox. Не потому, что остальные безгрешны, просто в этих двух описанное ниже поведение было достаточно стабильным.
Итак, у нас есть сайт и мы хотим ограничить доступ к location без всяких условий и не передавая никаких данных:
Chrome отправил запрос, не получил ответа, тут же отправил ещё один запрос, после чего стал периодически проверять сайт на доступность.
Firefox решил не мелочиться и сразу же отправил 20 запросов (иногда делает 10). Но потом уже не совершает «проверок».
При этом в отладчике он отчитывается как за один запрос:
Тем самым, ожидая получить один запрос от клиента, на деле мы получаем 3-20 запросов. Кроме совсем ненужных нам обращений есть риск скормить такой лог, например, анти-DDoS скрипту и заблокировать данный ip. И казалось бы полбеды, ведь мы и так ему «отдавали» 444, то есть нам его не жалко, но может случиться и наоборот — мы покажем клиенту то чего не вообще планировали.
Здесь мы запретили отдачу контента всем клиентам имеющим реферер »
https://habr.com/post/415565/ » при переходе на страничку tison.ru/codeif/444
Зная уже описанные выше особенности, мы допустим, что браузеры сделают более одного запроса, но 200-го ответа от сервера они не получат.
В виде лога, опять же, ожидаем одну или несколько строк вида:
При отладке в консоли всё работает ожидаемо. Сервер закрыл соединение и никакого контента мы не получили:
Ну и браузерная реальность.
Сделав несколько «честных» запросов запросов оба браузера отбросили реферер и спокойно отобразили блокируемую страницу. Firefox, правда, делает это не всегда. На моих тестах
в 15% запросов, что ещё больше «помогает» в анализе.
Такое поведение наблюдается уже достаточно давно, но когда именно Chrome и Firefox перешли на данный режим работы сказать не могу. Как впрочем и сколько времени этот режим будет действовать.
Поэтому сегодня использование return 444 не всегда приведёт к ожидаемым результатам. Ну а завтра, с нетерпением будем ждать, чем нас ещё порадуют разработчики браузеров.
Запрос отклонен waf 444 что это
Информация предназначена исключительно для ознакомления. Не нарушайте законодательство.
Web Application Firewall — популярный инструмент для противодействия атакам на веб-приложения. В этой статье я продемонстрирую несколько способов обхода WAF.
WAF bypass: SQL injection
Такой прием позволяет выполнить обход WAF, при этом на стороне веб-приложения запрос будет собран и обработается, как union select : [«1807192982′)) union/**/select/**/1,/**/2,/**/3,/**/4,/**/5,/**/6,/**/7,/**/8,/**/9,/**/’pentestit’,/**/11#»]
Также, можно использовать замену отдельных символов на их 16-ричный код: [«1807192982′)) %2f**%2funion%2f**%2fselect (1),(2),(3),(4),(5),(6),(7),(8),(9),(0x70656e746573746974),(11)#»]
Данный способ схож с предыдущим, но здесь в 16-ричный код переводится «слэш».
WAF bypass: RCE
Попробуем изменить запрос:
cat /etc/pa?swd
cat /etc/pa’ss’wd
cat /etc/pa**wd
Метод, похожий на предыдущий, с использованием функции awk : c\a\t \/\e\t\c/\p\a\s\sw\d
В bash при помощи \ можно экранировать символы. Воспользуемся этой возможностью для составления запроса.
Таким образом, выявление атак на основе сигнатур не является надежным средством защиты веб-приложения. Понимание принципа составления сигнатур и использование машинного обучения поможет справиться с методами обхода систем защиты.
P.S.: Если вы используете WAF — убедитесь, что он блокирует приведенные примеры их модификации.
Оставить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Что нам стоит WAF настроить
Занимаясь разработкой или обслуживанием веб-приложений, в какой-то момент времени приходится сталкиваться с необходимостью использовать WAF (Web Application Firewall). Если опыта работы с такого класса решением у вас нет или устали от постоянных ложных срабатываний, я расскажу, как упростить задачу, а также поделюсь советами и фишками. В качестве инструмента будем использовать Nemesida WAF Free — бесплатную версию Nemesida WAF.
Визуализация, или начнем с конца
Наблюдать за работой Nemesida WAF Free можно через браузер, поэтому после недолгой настройки системы мы получим доступ к веб-интерфейсу, в котором будет доступна информация по заблокированным атакам, причинах блокировки, информации об IP-адресах и т.д. Кроме этого появятся разделы со сводной статистикой в виде графиков, диаграмм и данными по трафику от модуля VTS (если он используется).
Демонстрационный стенд: demo.lk.nemesida-security.com (demo@pentestit.ru / pentestit)
Приступаем к установке.
Установка Nemesida WAF Free
Несмотря на то, что бесплатная версия — ответвление полноценной, она содержит большой набор возможностей для выявления, блокирования и визуализации атак на веб-приложения. Под веб-приложением подразумеваем все, что построено на протоколе HTTP: сайты, личные кабинеты, интернет-магазины, площадки для обучения, API и все остальное.
В предыдущем абзаце я специально разделил функционал блокирования атак на выявление и блокирование, поскольку есть 2 (даже три) режима работы продукта: IDS, IPS и PseudoIDS (режим LM).
Режим IDS
IDS режим позволяет использовать WAF на копии трафика, выявляя, но не блокируя атаки. Такой режим работы полезен, например, для первичного запуска или для пассивного мониторинга, чтобы исключить любое блокирование запросов или увеличение, пусть и незначительное, времени отклика. Для примера настройки будем использовать Nginx для передающего сервера (хотя можно использовать любой другой, например, Apache2 или IIS).
Настройка передающего сервера:
(вместо 192.168.0.1 необходимо указать адрес сервера с установленным Nemesida WAF)
После внесения изменений и перезапуска веб-сервера, поступающие на этот сервер запросы будут транслироваться на сервер 192.168.0.1 с установленным Nemesida WAF (его настройка проста и будет описана ниже). Такая схема работы позволяет мониторить атаки без их блокирования, но в то же время, без воздействия на основной сервер.
Режим IPS и PseudoIDS
Остальные 2 режима работы предполагают использование WAF «вразрез», при этом в режиме IPS выявленные инциденты безопасности блокируются, в режиме PseudoIDS — фиксируются, но не блокируются. Последний режим удобен тем, что переключение между этими двумя режими происходит с помощью простых опций: возможность перевода в режим PseudoIDS как по имени сервера (опция nwaf_host_lm ), так и по IP-адресу клиента (опция nwaf_ip_lm ).
Вообще, в Nemesida WAF Free предусмотрено множество параметров для «тонкой» настройки системы: гибкий функционал создания собственных правил блокировок и исключений, возможность добавлять IP клиента в «список исключений», опция настройка бана для всех и для каждого отдельного виртуального хоста и т.д. Всем этим хозяйством можно управлять через конфигурационный файл в бесплатной версии, а в полноценной — еще и через вызовы API.
Вернемся к процедуре установки. Nemesida WAF представлен в виде нескольких компонентов:
Динамический модуль Nemesida WAF
Для тех, кто устанавливает дистрибутив не в первый раз, процесс установки и запуска динамического модуля занимает примерно 5-10 минут. Динамический модуль Nemesida WAF можно подключить к уже установленному Nginx (или скомпилированному из исходников с собственными модулями).
Репозитории Nemesida WAF доступны для следующих ОС: Debian 9/10, Ubuntu 16.04/18.04/20.04, Centos 7/8. На Youtube-канале опубликованы видео-инструкции по установке и первичной настройке компонентов. Рекомендуем ознакомиться с одной из них, но установку и настройку советуем производить по документации на основном сайте, поскольку некоторые параметры могут устаревать, другие — добавляться.
После того, как Nginx будет настроен, подключите соотвествующий вашей ОС репозиторий Nemesida WAF и приступайте к установке. Обновление продукта производится также из репозитория. Инструкция по установке доступна по ссылке: waf.pentestit.ru/about/2511.
Nemesida WAF API и Личный кабинет
После того, как динамический модуль будет установлен и запущен, пора переходить к установке оставшихся двух компонентов: Nemesida WAF API и Личный кабинет.
Nemesida WAF API представлен в виде API, написанного с использованием Flask, и предназначен для приема событий от Nemesida WAF, Nemesida WAF Scanner и Nemesida AI с последующим помещением этих событий в БД. В качестве СУБД используется PostgreSQL. В бесплатной версии Nemesida WAF в БД будут передаваться только информация о заблокированных запросах.
После того, как Nemesida WAF API будет настроен и подключен к PostgreSQL, пора приступать к запуску Личного кабинета. Согласно документации производим установку, настройку, выполняем миграцию, указываем пользователя и пароль для входа.
По опыту установка двух последних компонентов вызывает больше затруднений (обычно пропускаются какие-то шаги, например, забывают сделать миграцию или разрешить подключение к Postgres), поэтому для быстрого старта мы подготовили Virtual Appliance (виртуальный диск с Debian 10 и компонентами Nemesida WAF, 3GB до распаковки), а также сделали 2 Docker-образа: для динамического модуля и для Nemesida WAF API/Личного кабинета.
Ну что, самая скучная часть позади, теперь можем проверить WAF в действии.
Первый hack
Чтобы проверить работу уже настроенного WAF, не обязательно вспоминать различные вариации атак. Мы создали тестовую сигнатуру, которая позволит проверить, работает ли Nemesida WAF и отображаются ли заблокированные атаки в ЛК. Актуальный набор используемых сигнатур всегда можно посмотреть на rlinfo.nemesida-security.com.
Отправляем запрос (я это сделал через консоль, но лучше делать через браузер для наглядности):
или, если хочется что-то более приближенное к реальности:
В ответ получаем код ответа 403:
А в ЛК через несколько секунд должна появиться атака:
Если запрос не заблокировался — WAF некорректно подключен или настроен (возможно, адрес или хост добавлен в WL/LM), если блокирование запроса произошло, но в ЛК информации нет — проверьте корректность настройки взаимодействия с Nemesida WAF API и ЛК. В любом случае, всегда можно задать вопрос на форуме.
Кастомная 403 страница
По умолчанию 403 страница (страница с 403 кодом ответа) невзрачна и скупа на информацию. Nemesida WAF в связке с Nginx позволяет ее сделать красивой и более информативной.
Чтобы ваш сервер отдавал такую страницу, необходимо:
1. Создать файл конфигурации для кастомных страниц (например, в /etc/nginx/snippets/custom_pages.conf );
Описание:
error_page 403 405 = 222 /403.html; — задаем кастомный 222 код ответа для кодов ответа 403 и 405 и возвращаем локацию /403.html ;
Определяем локацию /403.html как внутреннюю (то есть если обратиться к ней example.com/403.html — она не будет доступна), добавляя специальные заголовки для вывода ID запроса ($request_id), виртуального хоста ($host), к которому обращаемся, IP посетителя ($remote_addr) и реакцию (причину блокировки) Nemesida WAF ($nwaf_block_type). У Nemesida WAF есть несколько типов блокировки, например, 1 и 2 — запрос заблокирован сигнатурным анализом, 3 — модулем машинного обучения, 4 — антивирусом и т.д.
2. Подключить созданный файл:
Пример подключения файла конфигурации кастомных страниц в файле с виртуальным хостом (например, в /etc/nginx/conf.d/example.com.conf ):
3. Создать кастомную страницу (например, /var/www/custom_pages/403.html ) следующего содержания (для примера):
После перезапуска Nginx (с установленным Nemesida WAF) все страницы, имеющие код ответа 403 и 405, будут выглядеть следующим образом:
При этом кастомная страница будет обновляться каждые 7 секунд, и если IP клиента не будет забанен, то возвратится корневая страница сайта.
Автоматический бан
Вы, наверняка, слышали или даже используете системы автоматического бана вроде Fail2ban и знаете об их достоинствах и недостатках. В Nemesida WAF используется встроенный и простой в настройке механизм бана, позволяющий устанавливать произвольный период блокировки для виртуальных хостов сервера. Блокирование происходит по IP-адресу, а для управления доступны следующие опции:
Списки исключений (While lists)
Работа WAF построена по принципу анализа поступающих на сервер запросов и реакции в случаях, когда в них содержатся признаки атаки или аномалий. Применение алгоритмов машинного обучения вкупе с улучшенной технологией нормализации в полноценной версии Nemesida WAF позволяет выявлять такие атаки точно и с ультра-минимальным количеством ложных срабатываний (порядка 0.01%), но в бесплатной версии для снижения количества ложных срабатываний мы упираемся в ограничения, заложенные в архитектуру сигнатурного анализа. Таким образом, бесплатная версия имеет большее количество ложных срабатываний, и для решения этой проблемы приходится использовать списки исключений (или «white lists»). В Nemesida WAF также доступно создание правил исключений.
Чаще всего ложные срабатывания появляются, когда администратор/модератор веб-ресурса производит обновление или изменение через веб-интерфейс, передавая в теле запроса нетипичные для пользователя конструкции:
.
$html = curl_exec($ch);
curl_close($ch);
return json_decode($html,true);
.
В случаях, когда администраторы приложений не могут взаимодействовать с ним в обход WAF, можно добавить IP-адрес, с которого они обращаются к ресурсу, в список исключений или же перевести адрес в режим PseudoIDS (опция nwaf_ip_lm ) для фиксации событий без блокирования. Но с такими действиями всегда нужно быть достаточно осторожными.
Кстати, Nemesida WAF позволяет добавлять не только IP-адреса, но и подсети, если в этом появляется необходимость.
Заключение
Независимо от того, насколько качественно на ваш взгляд написан код, применяются в нем функции фильтрации ввода и специальные фреймворки вроде HTML Purifier, призванные удалять если не весь вредоносный код, то большую его часть, необходимо использовать WAF для повышения уровня защищенности.
Если использовать WAF предполагается впервые, или вы устали от бесконечных добавлений правил исключения, рекомендуем попробовать бесплатную Nemesida WAF Free. Для профессионального использования (блокирование сложных атак, атак методом перебора, СМС флуда; поиск уязвимостей; наличие системы виртуального патчинга и т.д.) требуется полноценная версия Nemesida WAF с модулем машинного обучения и сканером уязвимостей. Тем не менее, для большинства нецелевых атак и массовых сканирований Nemesida WAF Free будет хорошим и удобным инструментом.
В статье я постарался раскрыть ситуации, чаще других возникающие при использовании решений такого класса. Буду рад, если в комментариях вы вспомните еще.
Методы уклонения от Web Application Firewall (WAF)
Часто в веб-приложениях обнаруживается уязвимость удаленного выполнения команд Remote Command Execution и это подтверждается «OWASP Top 10 application security risk 2017», которые ставят «Injection» на первое место:
Угрозы Injection (внедрение), такие как SQL, NoSQL, OS и LDAP injection, возникают, когда ненадежные данные отправляются интерпретатору как часть команды или запроса. Враждебные данные злоумышленника могут заставить интерпретатор выполнить непреднамеренные команды или получить доступ к данным без надлежащей авторизации.
Все современные Web Application Firewall (брандмауэры веб-приложений) способны перехватывать (и даже блокировать) попытки RCE, но когда это происходит в системе Linux, у нас появляется невероятное количество способов обойти набор правил WAF. Самый большой друг тестера на проникновение — это не этого собака… (из фразы «собака друг человека») а «подстановочный знак — wildcard». Прежде чем начать рассказывать о метода обхода WAF, я хочу показать вам вещи, которые вы, возможно, не знаете о bash и подстановочных знаках (wildcards).
Что вы можете не знать о подстановочных знаках
Стандартные подстановочные знаки Bash (также известные как globbing patterns) используются различными утилитами командной строки для работы с несколькими файлами. Для получения дополнительной информации о стандартных подстановочных знаках обратитесь к странице руководства, набрав man 7 glob. Не все знают, что существует множество синтаксисов bash, которые позволяют вам выполнять системные команды, просто используя вопросительный знак «?», косую черту «/», цифры и буквы. Вы даже можете получить список файлов или получить их содержимое, используя одно и то же количество символов. Как? Я приведу несколько примеров:
Вместо выполнения команды ls вы можете использовать следующий синтаксис: /. /?s
/bin/cat /etc/passwd выполнился с символом подставновки
Как вы можете видеть на скриншоте выше, есть 3 ошибки /bin/cat*: Is a directory». Это происходит потому, что /. /??t может быть «переведен» процессом globbing в /bin/cat, а также /dev/net или /etc/apt, и т.п…
Преобразовав IP-адрес 127.0.0.1 в «long» формат (2130706433), вы можете избежать использования символов точки в своем HTTP-запросе.
В моем kali (дистрибутив линукс) мне нужно использовать nc.traditional вместо nc, у которого нет параметра -e, чтобы выполнить /bin/bash после подключения. Полезная нагрузка становится примерно такой:
executing a reverse shell using wildcard
Соответственно две предыдущие команды можно использовать так:
Перечислять файлы и каталоги, используя echo? Да, можно. Команда echo может перечислять файлы и каталоги в файловой системе, используя подстановочные знаки. Например: echo /*/*ss* :
перечислять файлы и каталоги, используя команду echo
Это может быть использовано на RCE для получения файлов и каталогов в целевой системе, например:
enumerate files and directories through a WAF
Но почему использование подстановочного знака (и, в частности, знака вопроса) может обойти набор правил WAF? Позвольте мне начать с Sucuri WAF!
Sucuri WAF evasion
Какой лучший способ проверить набор правил WAF? Создайте самый уязвимый PHP-скрипт в мире и опробуйте все возможные приемы! На скриншоте выше мы видим: в верхней левой панели мое уродливое веб-приложение (это просто PHP-скрипт, который выполняет команды):
В левой нижней части окна вы можете увидеть тест удаленного выполнения команд на моем веб-сайте, защищенный Sucuri WAF (test1.unicresit.it). Как вы видите, Sucuri блокирует мой запрос по причине «An attempted RFI/LFI was detected and blocked». Эта причина не совсем верна, но хорошая новость заключается в том, что WAF заблокировал мою атаку (я даже не знаю, почему брандмауэр должен сообщить мне причину заблокированного запроса, но должна быть причина… наверняка).
Правая панель является самой интересной из всех, потому что она показывает тот же запрос, но с использованием «вопросительного знака» в качестве подстановочного знака. Результат пугающий … Запрос принят Sucuri WAF, и мое приложение выполняет команду, которую я ввел в параметр c. Теперь я могу прочитать файл /etc/passwd и даже больше … Я могу прочитать исходный текст PHP-приложения, я могу запустить обратную оболочку, используя netcat (или, как мне нравится называть это: /. /?c), или Я мог бы выполнять такие программы, как curl или wget, чтобы выявить реальный IP-адрес веб-сервера, который позволил бы мне обойти WAF, подключившись напрямую к цели.
Я не знаю, происходит ли это из-за того, что я что-то пропустил в своей конфигурации Sucuri WAF… Я спросил у Sucuri, является ли это активным поведением и настроено ли оно по умолчанию на «низкий уровень паранойи», чтобы избежать ложных положительные, и я все еще жду ответа.
Пожалуйста, имейте в виду, что я делаю этот тест, используя тупой скрипт PHP, который не представляет реальный сценарий. ИМХО, вы не должны судить о WAF, основываясь на том, сколько запросов он блокирует, и Sucuri не менее безопасен только потому, что не может полностью защитить намеренно уязвимый веб-сайт.
ModSecurity OWASP CRS 3.0
Я действительно люблю ModSecurity, я думаю, что новая libmodsecurity (v3), используемая с Nginx и Nginx connector, является лучшим решением, которое я когда-либо использовал для развертывания брандмауэра веб-приложений. Я также большой поклонник набора основных правил OWASP (OWASP Core Rule Set)! Я использую его повсюду, но, если вы плохо знаете этот набор правил, вам нужно обратить внимание на небольшую вещь, называемую уровень паранои!
Уровень параноии для новичков
Следующая «схема», которую вы можете найти здесь, является хорошим обзором того, как каждый уровень работает по правилам «REQUEST PROTOCOL ENFORCEMENT». Как вы можете видеть с PL1, строка запроса может содержать только символы ASCII в диапазоне 1–255, и она становится более строгой, пока PL4 не блокирует все, что не является символом ASCII в очень небольшом диапазоне.
давайте проведем тест со всеми уровнями!
Paranoia Level 0 (PL0)
Уровень паранойи 0 означает, что многие правила отключены, поэтому абсолютно нормально, что наша полезная нагрузка может без проблем привести к удаленному выполнению команд. Не паникуйте 🙂
RCE принят ModSecurity с PL0 (не паникуйте, все в порядке)
Паранойя 1-го уровня в ModSecurity означает «безупречные правила высокого качества практически без ложных срабатываний», но это также слишком много разрешающего. Вы можете найти список правил, сгруппированных по уровню паранойи, на веб-сайте netnea: https://www.netnea.com/cms/core-rule-set-inventory/
Paranoia Level 1 и 2 (PL1, PL2)
Я сгруппировал уровни 1 и 2, потому что их различия (как вы можете видеть на схеме выше) не влияют на нашу цель, все действия такие же, как описано ниже.
с PL1 (и PL2) ModSecurity явно блокирует мой запрос «OS File Access Attempt» (930120). Но что, если я использую знак вопроса в качестве подстановочного знака? Запрос принят моим WAF:
with PL1 and PL2 my RCE attack was not blocked and I can read /etc/passwd
Это происходит потому, что «знак вопроса», «косая черта» и «пробел» находятся в допустимом диапазоне символов в правилах 920271 и 920272. Более того, использование «вопросительных знаков» вместо командного синтаксиса позволяет мне избежать «OS Files» фильтры, которые перехватывают общие команды и файлы операционных систем (такие как /etc/passwd в нашем случае).
Paranoia Level 3 (PL3)
Этот уровень паранойи имеет плюс: он блокирует запрос, содержащий символы типа «?» более чем в n раз. Фактически, мои запросы были заблокированы как «Meta-Character Anomaly Detection Alert — Repetitive Non-Word Characters». это здорово! отличная работа ModSecurity, ты выиграл плюшевого мишку! 🐻 Но, к сожалению, мое веб-приложение настолько уродливо и уязвимо, что я все равно могу использовать меньше вопросительных знаков и читать файл passwd, используя следующий синтаксис: c=/?in/cat+/et?/passw?
Как видите, используя всего 3 «?» Вопросительный знак Я могу обойти этот уровень паранойи и прочитать файл passwd внутри целевой системы. ОК, это не значит, что вы должны установить уровень паранойи на 4 всегда и безоговорочно. Имейте в виду, что я тестирую его с действительно глупым PHP-скриптом, который не представляет реальный сценарий … Я надеюсь …
Теперь все знают, что 42 — это ответ на жизнь, вселенную и все остальное. Но как насчет: «Будете ли вы уклоняться от набора правил OWASP на уровне 4 паранойи?»
Paranoia Level 4 (PL4)
в основном нет, я не могу. Все символы вне диапазона a-z A-Z 0–9 заблокированы! Ни в коем случае … и поверьте мне, когда вам нужно выполнить команду для чтения файлов, существует 90% вероятностей, что вам нужен символ «пробел» или «косая черта» 😉
Вы хотите больше?
Заключение
Вернуться к статическим HTML-страницам … это самый быстрый способ повысить безопасность вашего веб-приложения! Трудно сказать, какая конфигурация лучше всего избегать уклонения от WAF или какой уровень паранойи лучше всего использовать. ИМХО, мы не должны доверять набору правил, равномерно распределенному в веб-приложении. Действительно, я думаю, что мы должны настроить наши правила WAF, контекстуализированные для каждой функциональности приложения.
В любом случае, когда вы пишете новый SecRule на свой ModSecurity или что-то подобное, имейте в виду, что, вероятно, есть много способов обойти ваш фильтр или регулярное выражение в правиле. Поэтому сразу обдумывайте все возможности его обхода.