Первоначально, нужно понять какой софт сейчас самый эффективный: Сравниваем бесплатные версии WAF: NAXSI vs Nemesida WAF Free
Обучайтесь с нами! Мы в Telegram: https://t.me/hackyouhack
1. Группа Вконтакте: https://vk.com/hackyouhack
2. YouTube Канал: https://goo-gl.ru/5yW0
3. Blogger: https://hackyouhack1.blogspot.com/
ГО!
Сегодня мы хотим протестировать и сравнить работу двух бесплатных WAF: NAXSI и Nemesida WAF Free. В сравнении будут учитываться простота использования, качество предустановленных сигнатур, количество пропусков атак и частота ложных срабатываний.
NAXSI расшифровывается как Nginx Anti XSS & SQL Injection. Работает по принципу: всё, что не разрешено — запрещено. Каждый HTTP-запрос (GET|PUT|POST) проверяется на соответствие шаблонам запрещающих правил, заданных по умолчанию в файле naxsi_core.rules. Эти правила охватывают 99% всех возможных вариантов зловредных запросов. Например, по умолчанию запрещены все запросы, в URI которых содержится символ двойной кавычки. Если для нормальной работы приложения такой символ необходим, то вручную нужно внести соответствующие исключения в белый список. Но есть и обратная сторона медали — если разрешающие правила будут проработаны плохо, то NAXSI будет блокировать еще и часть легитимных запросов. Поэтому ответственность за конечный результат разработчики модуля целиком и полностью возлагают на администратора системы. Как и большинство модулей для Nginx, NAXSI из репозитория недоступен, поэтому его придется вручную скачивать и компилировать.
Nemesida WAF Free — бесплатная версия Nemesida WAF, представляющая собой динамический модуль для Nginx и обеспечивающая базовую защиту веб-приложения от атак класса OWASP на основе сигнатурного метода.
Отличительной особенностью Nemesida WAF Free является собственная база сигнатур, выявляющая атаки на веб-приложения при минимальном количестве ложных срабатываний, а также:
минимальные требования к аппаратным ресурсам;
обновление из репозитория;
установка и настройка за несколько минут;
обработка содержимого всех типов HTTP-запроса;
простота в обслуживании.
А теперь как его использовать:
Популярность веб-приложений (к которым относятся сайты, интернет-магазины, личные кабинеты, API и т.д.), большой стек применяемых технологий, дефицит опытных разработчиков, а доступность различного инструментария и знаний в области тестирования на проникновения приводит к ожидаемым последствиям — компрометации веб-приложения. Давайте попробуем повысить его защищенность.
Как обстоят дела с периметром? Доступны только порты для работы с HTTP? Или FTP/SSH etc. для удобства работы с контентом и обслуживанием сервера из любой точки мира? Имейте ввиду, что логин/пароль для SSH/FTP можно подобрать, а Fail2ban может и не сработать (или, наоборот, используя особенность работы Fail2ban можно заблокировать любой другой IP, а не только свой). Каждый доступный для атакующего сервис повышает риск компрометации. Не стоит забывать своевременно устанавливать обновления и периодически выполнять проверку сканерами уязвимостей.
Лимит обращений и ядро
Прежде, чем анализировать запросы, рекомендуется установить лимиты обращений. Это можно сделать, например, с помощью ngx_http_limit_req_module в Nginx. Установите оптимальное для вашего сервера количество запросов, чтобы снизить нагрузку в случае DoS-атаки. Кроме того, можно произвести тонкую настройку ядра, увеличив количество обрабатываемых соединений, времени таймаута при установки соединения, управлять взаимодействием со swap и т.д. Подробнее в этой статье.
Nginx: ограничиваем количество обращений к веб-серверу
Нежелательный User-agent
Отсечь часть нежелательного трафика можно простым добавлением списка блокируемых user-agent’ов в nginx.conf:
Блокируем нежелательные UA средствами Nginx
Веб-приложение
Чаще всего мы сталкиваемся с 2 типами атак: нецеленаправленная эксплуатация популярной уязвимости (к примеру, попытка эксплуатации уязвимости для Drupal на WordPress) и попытки подбора пароля (реже — других параметров).
Атаки методом перебора (brute-force)
Распространенный пример — атакующий пытается подобрать пароль к учетной записи. Помимо риска компрометации, такие атаки перегружают веб-приложение (интерпретатор, БД), ограничивая взаимодействие с ним легитимным пользователям.
Блокировать атаки методом перебора не всегда просто, особенно если невозможно использовать капчу или атака распределенная (атакующий может использовать прокси-сервера, в том числе бесплатные, которых тысячи), а другие параметры запроса (например, User-agent) — различаются. В самой масштабной распределенной атаке, с которой нам приходилось сталкиваться, было задействовано около 65.000 адресов.
Выявляем атакующих по схожести их запросов:
Так это выглядит на практике:
Атаки методом перебора, помимо угрозы компрометации данных (логин\пароль, бонусные балы, номера телефонов и т.д.), создают повышенную нагрузку на сервер, ограничивая доступ легитимных пользователей. Как правило, такие атаки не требуют больших мощностей, а для распределенной атаки злоумышленник может использовать публичные прокси-сервера (в том числе бесплатные).
Нецелевые атаки
Популярный пример такой атаки — злоумышленник производит массовое сканирование сайтов с помощью автоматического инструментария, развивая атаку на те сайты, где была обнаружена уязвимость. Использование WAF и системы блокирования на определенное время атакующего (бан) позволит значительно снизить риск обнаружения уязвимостей. Можно использовать связку ModSecurity/Naxsi + Fail2ban, потратить время на настройку и адаптацию, а можно использовать Nemesida WAF Free (бесплатная версия Nemesida WAF), которая помимо качественной сигнатурной базы имеет встроенный механизм блокирования источника на определенный промежуток времени. Кроме этого, заблокированные запросы отображаются в личном кабинете, в котором можно увидеть как состав сигнатуры, которая привела к блокированию запроса, так и получить готовое правило исключения (WL), если блокирование запроса произошло по ошибке:
Целевые атаки
Как правило, сложная атака, сопровождающаяся предварительным анализом веб-приложения. При такой атаке изучается серверное окружение, само приложение (если применимо: определяется тип, версия CMS/плагинов и разворачивается локальная копия, анализируется исходный код) и системы защиты (WAF).
WAF bypass
В контексте WAF применение решений на основе сигнатур упрощает атакующему возможность обхода WAF. Для наглядности мы часто приводим примеры, в которых происходит расщепление запроса символами, при этом запрос успешно отрабатывает на стороне веб-приложения так, будто символы расщепления не использовались:
un","ion se","lect
unIO%6e/*a*/selEC%74
Кроме того, атакующий может использовать особенности обработки запроса конечным интерпретатором, что приводит к пропуску атак сигнатурным методом, но выполнению запроса на целевом сервере:
%2f???%2f??t%20%2f???%2fp??s??
cat+/e't'c/pa'ss'wd
e'c'ho 'swd test pentest' |awk '{print "cat /etc/pas"$1}' |bash
и вот результат:
Магия Unicode
В чем разница между двумя запросами: defcon.ru/?s=ｗａｆ и defcon.ru/?s=waf? Вывод по ним будет абсолютно идентичный:
Если вам показалось, что в первом запросе добавлены пробелы между символами, то вам показалось. В одном случае используется Basic Latin, в другом — Fullwidth Latin. Суть в том, что это можно использовать для обхода сигнатур WAF. Как один из примеров применения — обход фильтрации.
Известен не один десяток способов байпаса сигнатурного WAF: двойной URL-encode, смена кодировки, расщепление запроса и т.д. Некоторые из них связаны с недостатком самого решения, другие — с особенностью обработки и интерпретации запроса конечным сервисом, но, в основном, все методы обхода содержат признаки атаки, пусть и модифицированные. Для выявления таких атак мы используем машинное обучение, которое, помимо снижения до минимума количества ложных срабатываний, позволяет выявлять различные способы обхода WAF.
Ко всему прочему машинное обучение производит построение поведенческих моделей на основе реального трафика, таким образом атакующий не сможет получить аналогичные модели в собственной инфраструктуре, что значительно усложнит попытки поиска способа обхода WAF. В случае использования сигнатурного анализа атакующему достаточно выявить способ в собственной среде и воспроизвести на удаленном сервере.
Заключение
Для защиты веб-приложений от атак рекомендуется:
соблюдать лучшие практики и рекомендации в области безопасной разработки
контролировать состояние веб-окружения и потенциальных «точек входа»
своевременно устанавливать security-обновления
устанавливать лимиты на обращения к сервисам
использовать WAF для защиты веб-приложения
проводить тестирование на проникновение веб-приложения, выполнять анализ исходного кода