Блокировка при "большом" теле запроса

C

coder.neos

Active member
Добрый день. После активации модуля защиты столкнулись с проблемой блокировки POST запросов. В нашем конкретном случае при размере запроса в 11263 байт, происходит блокировка. При этом максимальный размер тела запроса в конфиге nginx равен 128 Мб.


Code: 
client_max_body_size 128m;
include /etc/nginx/nwaf/conf/global/*.conf;
include /etc/nginx/nwaf/conf/vhosts/*.conf;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/vhosts/*/*.conf;

Судя по всему блокировка происходит, если тело запроса буферизуется во временный файл, то есть если запрос превышает размер заданный в client_body_buffer_size. Задавать этот параметр выше стандартных 16 Кб (в нашей конфигурации это 8 Кб) не рекомендуется, т.к. это открывает дополнительные возможности при DDOS атаке. И если я верно понял, блокировка происходит по причине того, что модуль не может проанализировать тело запроса, которые было буферизовано в файл.

Как правильно настроить модуль, чтобы он не блокировал такие запросы?
 
Last edited:
Попробовал добавить правила исключения следующего вида:

WL ID:* "Z:BODY|$URL_X:/^\/admin/";
WL ID:* "Z:BODY|$URL_X:/admin";

Запросы вида: POST /admin/index.php?... блокируются. Судя по всему проверка размера тела запроса, происходит до применения правил исключения.
 
Выявили ещё одну проблему, даже если включен режим IDS nwaf_host_lm *;, происходит блокировка запроса, если тело запроса выше допустимого, что на мой взгляд является некорректным поведением.
 
coder.neos said:
Добрый день. После активации модуля защиты столкнулись с проблемой блокировки POST запросов. В нашем конкретном случае при размере запроса в 11263 байт, происходит блокировка. При этом максимальный размер тела запроса в конфиге nginx равен 128 Мб.


Code: 
client_max_body_size 128m;
include /etc/nginx/nwaf/conf/global/*.conf;
include /etc/nginx/nwaf/conf/vhosts/*.conf;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/vhosts/*/*.conf;

Судя по всему блокировка происходит, если тело запроса буферизуется во временный файл, то есть если запрос превышает размер заданный в client_body_buffer_size. Задавать этот параметр выше стандартных 16 Кб (в нашей конфигурации это 8 Кб) не рекомендуется, т.к. это открывает дополнительные возможности при DDOS атаке. И если я верно понял, блокировка происходит по причине того, что модуль не может проанализировать тело запроса, которые было буферизовано в файл.

Как правильно настроить модуль, чтобы он не блокировал такие запросы?
Click to expand...

Управление размером тела запроса при обработке модулем производится при помощи опции
Code: 
client_body_buffer_size 25M;
в файле /etc/nginx/nginx.conf

waf.pentestit.ru

Nemesida WAF и Nemesida AI | Nemesida WAF

Руководство по установке, настройке и эксплуатации основных компонентов Nemesida WAF — динамического модуля для Nginx и модуля машинного обучения Nemesida AI. Доменное имя example.com вместе с поддоменами в руководстве используется в качестве примера. Доменное имя .example.com включает в себя...
waf.pentestit.ru waf.pentestit.ru
 
rr said:
Управление размером тела запроса при обработке модулем производится при помощи опции
Code: 
client_body_buffer_size 25M;
в файле /etc/nginx/nginx.conf

waf.pentestit.ru

Nemesida WAF и Nemesida AI | Nemesida WAF

Руководство по установке, настройке и эксплуатации основных компонентов Nemesida WAF — динамического модуля для Nginx и модуля машинного обучения Nemesida AI. Доменное имя example.com вместе с поддоменами в руководстве используется в качестве примера. Доменное имя .example.com включает в себя...
waf.pentestit.ru waf.pentestit.ru
Click to expand...

Проблема в том, что у нас тело запроса может достигать 128 Мб (загружаются файлы). Буфер такого размера - может иметь крайне негативные последствия для производительности сервера (оперативная память будет быстро исчерпана).

Несколько вопросов:

1) Нет возможности отключить проверку тела через WL правила? Если нет, то на сколько я смог понять модуль защиты полагается на переменную $request_body, которая пуста в случае, если тело было буферизовано в файл. Проверка $request_body происходит до применения правил исключения. Возможно ли доработать модуль таким образом, что если правило исключения задано для всех ID:*, и для зоны BODY, то не считывать $request_body? В этом случае можно обойтись без изменения буфера.
2) А также, хотелось бы получить комментарий по данной проблеме:
Выявили ещё одну проблему, даже если включен режим IDS nwaf_host_lm *;, происходит блокировка запроса, если тело запроса выше допустимого, что на мой взгляд является некорректным поведением.
Click to expand...
 
coder.neos said:
Проблема в том, что у нас тело запроса может достигать 128 Мб (загружаются файлы). Буфер такого размера - может иметь крайне негативные последствия для производительности сервера (оперативная память будет быстро исчерпана).

Несколько вопросов:

1) Нет возможности отключить проверку тела через WL правила? Если нет, то на сколько я смог понять модуль защиты полагается на переменную $request_body, которая пуста в случае, если тело было буферизовано в файл. Проверка $request_body происходит до применения правил исключения. Возможно ли доработать модуль таким образом, что если правило исключения задано для всех ID:*, и для зоны BODY, то не считывать $request_body? В этом случае можно обойтись без изменения буфера.
2) А также, хотелось бы получить комментарий по данной проблеме:
Click to expand...

1) Подумаем, как это можно решить, не увеличивая выделяемый объем памяти.

2) По поводу второго вопроса - запрос будет блокироваться в любом случае, если тело запроса превышает значение, установленное параметром client_body_buffer_size, даже если установлен режим LM (посколько в таком режиме запрос в любом случае будет обрабатываться модулем).
 
rr said:
1) Подумаем, как это можно решить, не увеличивая выделяемый объем памяти.

2) По поводу второго вопроса - запрос будет блокироваться в любом случае, если тело запроса превышает значение, установленное параметром client_body_buffer_size, даже если установлен режим LM (посколько в таком режиме запрос в любом случае будет обрабатываться модулем).
Click to expand...
Понятно, спасибо!

Всё-таки режим IDS предполагает только логирование, а не реальную блокировку. Выходит, что нельзя безопасно протестировать и настроить модуль. Возможно стоит логировать, что тело запроса превышает допустимый размер, но не блокировать такой запрос?
 
coder.neos said:
Понятно, спасибо!

Всё-таки режим IDS предполагает только логирование, а не реальную блокировку. Выходит, что нельзя безопасно протестировать и настроить модуль. Возможно стоит логировать, что тело запроса превышает допустимый размер, но не блокировать такой запрос?
Click to expand...

Мы подумаем над этим, но для полноценного безопасного тестирования рекомендуется использовать полноценный IDS-режим, то есть проводить тестирование на копии трафика.
 
rr said:
Мы подумаем над этим, но для полноценного безопасного тестирования рекомендуется использовать полноценный IDS-режим, то есть проводить тестирование на копии трафика.
Click to expand...

Было бы отлично, если в документации был раздел с рекомендациями при первоначальном внедрении модуля.
 
coder.neos said:
Было бы отлично, если в документации был раздел с рекомендациями при первоначальном внедрении модуля.
Click to expand...

Спасибо, подумаем над этим.
 
coder.neos said:
Проблема в том, что у нас тело запроса может достигать 128 Мб (загружаются файлы). Буфер такого размера - может иметь крайне негативные последствия для производительности сервера (оперативная память будет быстро исчерпана).

Несколько вопросов:

1) Нет возможности отключить проверку тела через WL правила? Если нет, то на сколько я смог понять модуль защиты полагается на переменную $request_body, которая пуста в случае, если тело было буферизовано в файл. Проверка $request_body происходит до применения правил исключения. Возможно ли доработать модуль таким образом, что если правило исключения задано для всех ID:*, и для зоны BODY, то не считывать $request_body? В этом случае можно обойтись без изменения буфера.
2) А также, хотелось бы получить комментарий по данной проблеме:
Click to expand...

Эти особенности (1, 2) будут учтены в ближайших релизах. Спасибо за обратную связь и рекомендации.
 
coder.neos said:
Проблема в том, что у нас тело запроса может достигать 128 Мб (загружаются файлы). Буфер такого размера - может иметь крайне негативные последствия для производительности сервера (оперативная память будет быстро исчерпана).

Несколько вопросов:

1) Нет возможности отключить проверку тела через WL правила? Если нет, то на сколько я смог понять модуль защиты полагается на переменную $request_body, которая пуста в случае, если тело было буферизовано в файл. Проверка $request_body происходит до применения правил исключения. Возможно ли доработать модуль таким образом, что если правило исключения задано для всех ID:*, и для зоны BODY, то не считывать $request_body? В этом случае можно обойтись без изменения буфера.
2) А также, хотелось бы получить комментарий по данной проблеме:
Click to expand...

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

в текущей версии мы добавили параметр nwaf_body_exclude, исключающий анализ сигнатурным методом зоны BODY, а также отправку её содержимого в модули Nemesida AI MLA и Nemesida AI MLC. Например:
Code: 
nwaf_body_exclude example.com/uploads.php;
выключит анализ зоны BODY для example.com/uploads.php.
 
Отлично, спасибо! Верно я понимаю, что сравнение идёт по вхождению строки? Т.е. если правило записано так:
nwaf_body_exclude example.com/uploads, то исключение будет работать и для example.com/uploads?id=1, example.com/uploads/images и т.д.?
 
coder.neos said:
Отлично, спасибо! Верно я понимаю, что сравнение идёт по вхождению строки? Т.е. если правило записано так:
nwaf_body_exclude example.com/uploads, то исключение будет работать и для example.com/uploads?id=1, example.com/uploads/images и т.д.?
Click to expand...

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

не совсем так, требуется полное совпадения пути, например, для nwaf_body_exclude example.com/uploads исключения будут приниматься к example.com/uploads?id=1, но не будут к example.com/uploads/images.
 
You must log in or register to reply here.
Back
Top