Pull to refresh

Comments 6

Не зависимо от того, насколько качественно на ваш взгляд написан код, применяются в нем функции фильтрации ввода и специальные фреймворки вроде HTML Purifier, призванные удалять если не весь вредоносный код, то большую его часть, необходимо использовать WAF для повышения уровня защищенности.

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


WAF стоит ставить, если есть понимание, что кодовая база крайне низкокачественная, и быстро исправить ее нельзя.

Спорно, потому что WAF создает боль? Какой использовали?
такие проблемы должны экранироваться на уровне приложения

Удачи в «допиливании» парка проприетарных продуктов и в системах, где риск желательно устранять превентивно, а не когда выпустят патч.

Спасибо за статью — давно заняю ваш WAF, но не думал, что есть пробная бесплатная версия!


У меня есть несколько вопросов и буду рад, если ответите:


  1. можете сделать какой-то ликбез относительно ModSecurity? Что ловится регекспами и используются ли они, а что ML?


  2. если используются регекспы, то что внутри: PCRE JIT, Hyperscan, или вообще что-то свое?


  3. можете ли дать какой-то ориентир сколько RPS ваш WAF может обработать на одно ядро CPU в каких-то конфигурациях (например, минимально, 100 регекспов, полная база)?


Спасибо за отзыв,

бесплатная версия не имеет ограничений по времени использования, также есть пробная
полная версия.

1. > можете сделать какой-то ликбез относительно ModSecurity? Что ловится регекспами и используются ли они, а что ML?

Относительно регекспов (сигнатур) и нивелирования их недостатков машинным обучением — это отдельная тема для статья, если вкратце, то: не под все атаки можно составить сигнатуры так, чтобы они блокировались с минимальным количеством ложных срабатываний. В качестве примера можно привести конструкцию cmd=; cat+/e?c/pa???d, под которую сложно создать сигнатуру таким образом, чтобы она не фолсила (не только в параметрах, но и других зонах HTTP). При этом вместо /etc/passwd может быть любой другой файл, например ./se????gs.??? (settings.php) или что-то еще.

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

Дополнительно, информация по работе сигнатур/ML в Nemesida WAF доступна в видео.

2. > если используются регекспы, то что внутри: PCRE JIT, Hyperscan, или вообще что-то свое?

Для модуля сигнатурного анализа используется PCRE.

3. > можете ли дать какой-то ориентир сколько RPS ваш WAF может обработать на одно ядро CPU в каких-то конфигурациях (например, минимально, 100 регекспов, полная база)?

Все зависит от качества составленной сигнатуры и размера запроса, например, вы составили сигнатуру union.+select.+from и пытаетесь обработать есть тело запроса в 5 МБ (еще учитываем, что это не единственная используемая сигнатура) — время обработки будет в раз больше, чем если бы сигнатура выглядела так union.{1,250}select.{1,250}from. С базовым набором сигнатур, который доступен на сайте rlinfo.nemesida-security.com (автоматически обновляется) среднее время обработки запроса может увеличиться на 200-500 мс.

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



Даже в полноценной версии мы все равно задействуем сигнатурный анализ, поскольку принятие им решения занимает гораздо меньше времени, чем принятие решения модулем машинного обучения. Тем не менее, некоторые блокировки сигнатурным анализом модуль машинного обучения в Nemesida WAF может отменить, за счет чего и достигается практически полное отсутствие FP.
Sign up to leave a comment.