Единственное, чего мне не хватало, это фаза обработки, на которой это правило должно быть помещено, чтобы оно работало. так что действительное правило здесь.
SecRule REQUEST_URI|ARGS|REQUEST_BODY "km0ae9gr6m" "phase:4,log,deny,msg:'Access Denied'"
С помощью этого правила вы можете легко заблокировать любой тип ответа, который вы не хотите, чтобы ни один пользователь видел. Modsecurity обнаружит его на пути к серверу и заблокирует его.
Какую версию ModSecurity вы используете? Переменная ARGS
включает только QUERY_STRING
+ POST_PAYLOAD
в версии 1.X. Если вы используете версию 2.X, с указанным выше правилом, тестирование с запросом, как показано ниже:
http://domain.com/a?b=km0ae9gr6m
, вы увидите что-то вроде этого в audit_log
:
[modsecurity] [клиент xxxx] [домен domain.com] [302] [/ 20120813 / 20120813-1226 / 20120813-122624-70QXqH8AAAEA
AEucDbkAAAAA] [файл «/etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf»] [строка «305»] [сообщение «Доступ запрещен»] Доступ запрещен с кодом 403 (фаза 2). Соответствие шаблону "km0ae9gr6m" в ARGS: b.
В ModSecurity 2.x, ARGS
расширяется до отдельных переменных. Итак, попробуйте следующее:
SecRule REQUEST_URI|ARGS|REQUEST_BODY "km0ae9gr6m" "log,deny,msg:'Access Denied'"
Выше ответ правильный, используйте этап: 1. Вы также можете использовать оператор частичного совпадения строк «@contains», чтобы остановить запрос, который содержит нежелательную строку как часть более длинной строки. Например, у меня нет word press, поэтому, когда я получаю запросы на wp-login, wp-admin и т. Д., Я могу заблокировать их все одним правилом: SecRule REQUEST_URI "@contains wp-" "id: 101, phase: 1, deny, status: 409, msg: 'Denied'"
Кстати, сообщение из msg: кажется, появляется только в журналах,сообщение, которое видит пользователь, я добавил в конфигурацию apache ErrorDocument 409 «ДОСТУП СТРОГО ЗАПРЕЩЕН»