Блог

Я хочу создать правило mod security2x, которое будет блокировать запрос GET на определенный URL.

например, я хочу заблокировать URL-адрес с помощью GET в заголовке: ‘www.test.com ‘

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

Это будет примером запроса GET: GET/secure/bla/test/etc/

Это то, что у меня есть до сих пор: SecRule ARGS "www.test.com" phase:2,log,deny,id:'1234',msg:'403 Access Denied'

Вы хотите что-то вроде этого:

 SecRule REQUEST_URI "@streq /secure/bla/test/etc/" 
     "phase:1,id:1234,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"
    SecRule REQUEST_METHOD "@streq get" "t:none,t:lowercase"
  

Вам нужно связать два правила вместе, поскольку вы хотите проверить два условия (путь /secure/bla/test/etc/ и метод GET).

Если вы хотите добавить третье правило для проверки хоста (например, если у вас несколько виртуальных хостов и этот URL-адрес действителен для запросов GET на некоторых из них), то вы можете:

 SecRule REQUEST_URI "@streq /secure/bla/test/etc/" 
     "phase:1,id:1234,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"
    SecRule REQUEST_METHOD "@streq get" "t:none,t:lowercase,chain"
         SecRule SERVER_NAME "@streq www.example.com"
  

Или, в качестве альтернативы, вы можете использовать REQUEST_URI_RAW, который будет включать протокол и имя хоста, а также запрашиваемый ресурс:

 SecRule REQUEST_URI_RAW "^https?://www.test.com/secure/bla/test/etc/" 
     "phase:1,id:1234,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"
    SecRule REQUEST_METHOD "@streq get" "t:none,t:lowercase" 
  

Вы заметите, что я также добавил довольно много функций преобразования ( t: bits), чтобы помочь избежать попыток людей обойти это правило (например, с помощью пути like /secure/bla/TEST/../test/etc/ ).

Все это описано в справочном руководстве: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual но, признаю, требуется немного практики, чтобы привыкнуть!

Простой режим обнаружения аномалий означает, что правила, которые могут срабатывать для допустимых запросов, не блокируются немедленно, а вместо этого присваивается оценка, и если общая оценка всех правил для этого запроса превышает определенный порог, то он блокируется, если нет, то нет. Это позволяет по-прежнему включать «шумные» правила, но игнорировать их, если только для запроса не срабатывает множество шумных правил или если срабатывает одно важное правило.

Ничто не мешает вам явно блокировать с помощью опции «запретить», как я сделал выше, даже в режиме обнаружения аномалий. Это правило кажется довольно безопасным от случайного запуска для законного запроса (после того, как вы проверили, что оно работает!), Поэтому я бы просто перешел от прямой блокировки, как я сделал выше. Альтернативой является замена deny на block,setvar:tx.anomaly_score= %{tx.critical_anomaly_score} , которая будет иметь тот же эффект, когда оценка будет проверена позже, но, на мой взгляд, излишне усложняет читаемость правила, поскольку оно всегда будет блокироваться в любом случае.

Оценка аномалий по сравнению с традиционной оценкой более подробно рассматривается в этом сообщении в блоге: http://blog.modsecurity.org/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html

Я бы использовал метод белого списка, чтобы заблокировать запрос GET, например, login.php и change_password.php не требует никакого запроса GET.

     SecRule REQUEST_URI|ARGS_NAMES|REQUEST_FILENAME "/secure/bla/test/etc/" "phase:2,t:none,deny,chain"
    SecRule REQUEST_FILENAME "@pm login.php change_password.php"