Не блокируется атака, то есть не выводится 403 forbidden при срабатывании RL правила

KaspePP

Member
Здравствуйте, создал RL правило в /etc/nginx/nwaf/conf/global/nwaf.conf.
YmtNSXzodQY.jpg

При вводе в поле логина на сайте, правило срабатывает и отображается в waf api, но не выводится 403 forbidden.
2XutKoJMK9I.jpg
 
как сделать также чтобы редиректило на 403 как и при срабатывании стандартных правил в waf ?
 

\{\{.+\}\}ARGS
Как я понимаю есть вот такое 35 правило, но срабатывает оно только когда я передаю на уязвимый сайт {{{config}}}, а {{config}} пропускает. Если убрать по { слева и } справа, то перестает пускать {config} и вываливается в forbidden. Не могу никак ему объяснить, что плохо именно {{config}}
 
Также заметил, что банит и при правиле PX:\{\{.+\}", то есть {{config}, или при {\{.+\}\}", то есть {config}}, но никак не работает с {{config}} и конфигурация сервера выводится
 
Добрый день!

Из-за специфики работы сигнатур при передаче {{config}} в аргументах запроса срабатывает сигнатура 35, но также срабратывает сигнатура 111, которая приводит к разблокировке запроса (мы поправили поведение сигнатур, {{{config}}} теперь тоже не приводит к блокировке. Чтобы изменения вступили в силу необходимо перезапустить сервис nwaf_update). Поэтому при передаче в аргументах {{config}} у вас не блокируется запрос из-за его разблокировки. При составлении правила блокировки вам следует добавлять дополнительные символы в шаблон сигнатуры создаваемого правила, чтобы сигнатура не попадала под действие сигнатуры 111.

Например, если вы хотите, чтобы у вас происходила блокировка {{config}} в аргументах запроса, то ваше правило будет выглядеть следующим образом:

RL 50001 "PX:=\{\{.+\}" "SC:XSS:12" "Z:BODY|URL|ARGS|HEADERS";

при таком правиле запрос с ={{config}} в аргументах будет блокироваться.

Если вам требуется помощь с составлением сигнатуры для других случаев, то, пожалуйста, сообщите нам.
 
Добрый день!

Из-за специфики работы сигнатур при передаче {{config}} в аргументах запроса срабатывает сигнатура 35, но также срабратывает сигнатура 111, которая приводит к разблокировке запроса (мы поправили поведение сигнатур, {{{config}}} теперь тоже не приводит к блокировке. Чтобы изменения вступили в силу необходимо перезапустить сервис nwaf_update). Поэтому при передаче в аргументах {{config}} у вас не блокируется запрос из-за его разблокировки. При составлении правила блокировки вам следует добавлять дополнительные символы в шаблон сигнатуры создаваемого правила, чтобы сигнатура не попадала под действие сигнатуры 111.

Например, если вы хотите, чтобы у вас происходила блокировка {{config}} в аргументах запроса, то ваше правило будет выглядеть следующим образом:

RL 50001 "PX:=\{\{.+\}" "SC:XSS:12" "Z:BODY|URL|ARGS|HEADERS";

при таком правиле запрос с ={{config}} в аргументах будет блокироваться.

Если вам требуется помощь с составлением сигнатуры для других случаев, то, пожалуйста, сообщите нам.
Спасибо, {{config}} теперь блокирует после этого правила и рестарта nwaf_update.
Но теперь он блокирует если посылаешь {{config}}, {{config}}\, {{config}}a и так далее после последней скобки, но не блокирует, если ты посылаешь a{{config}}, \{{config}} и так далее.
 
Разобрался сам. Правило следующее: RL ID:50001 "PX:=.+\{\{.+\}" "SC:XSS:12" "Z:BODY|URL|ARGS|HEADERS"; Вдобавок нужно еще такое же правило RL ID:50002 "PX:=\{\{.+\}" "SC:XSS:12" "Z:BODY|URL|ARGS|HEADERS"; Только при таких двух правилах блокирует комбинации {{config}}, (любыесимволы){{config}}, {{config}}(любыесимволы), (символы){{config}}(символы). В одно правило это нельзя как нибудь запихнуть?
 
Разобрался сам. Правило следующее: RL ID:50001 "PX:=.+\{\{.+\}" "SC:XSS:12" "Z:BODY|URL|ARGS|HEADERS"; Вдобавок нужно еще такое же правило RL ID:50002 "PX:=\{\{.+\}" "SC:XSS:12" "Z:BODY|URL|ARGS|HEADERS"; Только при таких двух правилах блокирует комбинации {{config}}, (любыесимволы){{config}}, {{config}}(любыесимволы), (символы){{config}}(символы). В одно правило это нельзя как нибудь запихнуть?
Используя регулярные выражения, вы можете создавать правила для поиска любого вхождения символов. для проверки корректности созданного регулярного выражения вы можете воспользоваться любым сервисом создания регулярных выражений, например, regex101.
 
Back
Top