Работа с правилами фильтрации ModSecurity#

WAF ModSecurity3.0 (далее MDS или libmodsecurity), используемый в SOWA, обеспечивает защиту веб-приложений от уязвимостей разных типов, используя следующие методы:

• обнаружение нарушений протокола HTTP и локально используемых политик;

• защита от наиболее известных веб атак;

• автоматическое обнаружение ботов, сканеров и другой вредоносной активности;

• защита от троянов;

• сокрытие кодов ошибок, отсылаемых сервером.

Для использования вышеописанной функциональности, ModSecurity необходимо сконфигурировать при помощи правил.

Конфигурирование правил фильтрации осуществляет прикладной разработчик.

Наборы правил#

В качестве базовых правил для использования и модификации в SOWA, были выбраны два набора правил - Comodo Rule Set и OWASP Core Rule Set.

Основные направления защиты набора правил OWASP:

Набор правил Comodo CRS берет за основу и дополняет набор OWASP CRS, что обеспечивает большее покрытие базовых уязвимостей.

Для совместного использования обоих наборов были выполнены соответствующие правки и отключения пересекающихся правил.

На данной основе были созданы собственные наборы правил, используемые в следующих примитивах - HTTP-MQ, WebSocket-proxy, HTTP-proxy.

Конфигурационный файл ModSecurity#

Главный конфигурационный файл MDS в отрендеренном конфигурационном файле расположен в каталоге /sowa/имя_профиля/services/имя_сервиса/.

Рекомендуется править правила в поставке, а не в отрендеренном конфигурационном файле.

Пользователю доступна настройка следующих директив:

[1] Части аудит лога

A - заголовок аудит лога;

B - заголовок запроса;

C - тело запроса (только в случае включенной обработки тела запроса - SecRequestBodyAccess on);

D - промежуточный заголовок ответа;

E - промежуточное тело ответа (только в случае включенной обработки тела ответа - SecResponseBodyAccess on);

F - окончательный заголовок ответа;

G - окончательное тело ответа;

H - запись о сработавших правилах;

I - замена части C. Логируется то же самое, за исключением случая, когда используется multipart/form-data. В таком случае, будет записано тело, содержащее информацию о параметрах, но не о файлах. Используется, чтобы не хранить большие файлы в аудит логах;

J - информация о файлах, загруженных с multipart/form-data;

K - полный список сработавших правил в порядке срабатывания, включая запись оператора и действия правила;

Z - конец записи.

Конфигурационный файл набора OWASP, поведение правил по умолчанию, anomaly score, paranoia level#

Конфигурационный файл набора правил OWASP в отрендеренной поставке расположен в каталоге /sowa/имя_профиля/services/имя_сервиса/modsecurity/owasp-crs/ crs-setup.conf.

Данный набор правил позволяет пользователю указать действие по умолчанию (block) при выполнении правила в определенной фазе обработки запросов\ответов.

SecDefaultAction "phase:1,log,auditlog,deny,status:403"
SecDefaultAction "phase:2,log,auditlog,deny,status:403"
SecDefaultAction "phase:3,log,auditlog,deny,status:403"
SecDefaultAction "phase:4,log,auditlog,deny,status:403"

По умолчанию, набор правил работает следующим образом: при срабатывании правила с важностью SEVERITY: 'CRITITCAL' запрос\ответ блокируется. В версии MDS 3.0 представлен новый механизм блокирования запросов\ответов - anomaly score. Благодаря этому, есть возможность понизить или повысить чувствительность WAF - при задании кастомного уровня аномалий, каждое выполненное правило будет увеличивать значение счетчика аномалий. Счетчик представляет собой сумму важности всех правил, выполнившихся в процессе обработки запроса\ответа. В зависимости от важности правила, значение счетчика аномалий изменяется больше\меньше, и только при достижении заданного пользователем значения запрос\ответ будет блокирован.

Уровни важности правил:

• CRITICAL: Anomaly Score = 5

• ERROR: Anomaly Score = 4

• WARNING: Anomaly Score = 3

• NOTICE: Anomaly Score = 2

Для использования механизма, необходимо снять комментарий со следующего правила и задать необходимые значения:

# [ Anomaly Threshold / Paranoia Level Quadrant ]
#
#     High Anomaly Limit   |   High Anomaly Limit
#     Low Paranoia Level   |   High Paranoia Level
#     -> Fresh Site        |   -> Experimental Site
# ------------------------------------------------------
#     Low Anomaly Limit    |   Low Anomaly Limit
#     Low Paranoia Level   |   High Paranoia Level
#     -> Standard Site     |   -> High Security Site
#
# setvar:tx.inbound_anomaly_score_threshold=5 предел счетчика аномалий для запросов
# setvar:tx.outbound_anomaly_score_threshold=4 предел счетчика аномалий для ответов
#
# Uncomment this rule to change the defaults:
#
#
#SecAction \
# "id:900110,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.inbound_anomaly_score_threshold=5,\
#  setvar:tx.outbound_anomaly_score_threshold=4"

Механизм Paranoia Level (уровень паранойи) представляет собой определенный порог, позволяющий при его увеличении активировать дополнительные, более строгие правила, предоставляющие большую безопасность. Однако, чем выше уровень паранойи - тем больше вероятность ложных срабатываний. Допустимые значения 1-4.

SecAction \
"id:900000,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.paranoia_level=4"

Общая структура правил#

Правила OWASP:

/usr/local/sowa/libmodsecurity/common/rules/modsecurity/owasp-crs/rules

Правила Comodo:

/usr/local/sowa/libmodsecurity/common/rules/modsecurity/comodo

Для описания правила в ModSecurity используется директива SecRule. Директива SecRule состоит из 4 общих частей:

SecRule ПЕРЕМЕННЫЕ "ОПЕРАТОР" "ДЕЙСТВИЯ И ТРАНСФОРМАЦИИ СОДЕРЖИМОГО ПЕРЕМЕННЫХ"

Пример правила, обнаруживающего SQL Injection:

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:(sleep\((\s*?)(\d*?)(\s*?)\)|benchmark\((.*?)\,(.*?)\)))" \

Список переменных, включающий в себя также указание исключений для определенных переменных, содержимое которых будет обрабатываться в соответствии с оператором. В качестве оператора здесь - регулярное выражение, направленное на нахождение инъекций, содержащих sleep() и benchmark().

Фаза, на которой будет выполняться данное правило:

 "phase:2,\

Версия правила, помогающая отследить изменения в данном правиле:

rev:'2',\

Версия набора правил:

ver:'OWASP_CRS/3.0.0',\

Величина от 1 до 9, характеризующая относительное количество тестов, проведенных с данным правилом:

maturity:'9',\

Величина от 1 до 9, характеризующая относительное количество ложных срабатываний:

accuracy:'8',\

Сохранить совпадения, выявленные выражением, для логирования (используется совместно с регулярным выражением в качестве оператора):

capture,\

Трансформации, в данном случае выполняется преобразование всех символов utf8 в юникод:

t:none,t:utf8toUnicode,\

Действие при выполнении правила:

block,\

Содержимое сообщения для логирования:

msg:'Detects blind sqli tests using sleep() or benchmark().',\

Номер правила:

id:942160,\

Список тэгов для логирования, позволяющий отслеживать категории уязвимостей, на которые направлены правила, либо категории применения правил:

tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-sqli',\ tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\

Формат записи в лог-файле:

logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\

Критичность/уровень важности правила. При стандартном поведении немедленно блокируются только правила с важностью CRITICAL. Иначе происходит обращение к счетчику аномалий:

severity:'CRITICAL',\

Задание переменных, содержащих сообщение и увеличение счетчиков аномалий. Значения, прибавляемые к счетчику, должны соответствовать важности. Если важность правила - critical, то и прибавляется к счетчику tx.critical_anomaly_score:

setvar:'tx.msg=%{rule.msg}', setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:'tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/SQLI-%{matched_var_name}=%{tx.0}'"

Анализ срабoтавших правил#

Логи сработавших правил можно посмотреть:

• в error-log файле сервиса;

• в аудит логах (описание приведено в статье "Работа с правилами фильтрации ModSecurity" в Руководстве по системному администрированию).

Типовой лог о срабатывании правила:

2019/07/18 15:03:04 [info] 14479#14479: *18 ModSecurity: 
Access denied with code 403 (phase 2).Matched "Operator `Rx' 
with parameter `((?:[\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\
;\"\'\\xc2\xb4\\xe2\x80\x99\\xe2\x80\x98\`\<\>][^\~\!\@\#\$\%
\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;\"\'\\xc2\xb4\\xe2\x80\x99\\xe2
\x80\x98\`\<\>]*?){8})' against variable `REQUEST_COOKIES:TE3
' (Value: `N0:C N1:E N2:E N3:E N4:E N5:C N6:C N7:C N8:C N9:C 
N10:C N11:C N12:C N13:C N14:C N15:C N16:C N17:C N1 (93 
characters omitted)' ) [file "/sowa/profile_storage/custom/
sbc_web/sbc_rules/REQ.conf"] [line "1402"] [id "7232"] [rev 
"2"] [msg "Restricted SQL Character Anomaly Detection 
(cookies): # of special characters exceeded (8)"] [data 
"Matched Data: :C N1:E N2:E N3:E N4:E N5:C N6:C N7: found 
within REQUEST_COOKIES:TE3: N0:C N1:E N2:E N3:E N4:E N5:C 
N6:C N7:C N8:C N9:C N10:C N11:C N12:C N13:C N14:C N15:C N16:C 
N17:C N18:E N19:C N20:C N21:C N22:C N23:C N24:C N25:C N26:C 
N27:C N28:C N29:C N30:C N31:C N32:C N33:C"] [severity "4"] 
[ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag 
"application-multi"] [tag "language-multi"] [tag "platform-
multi"] [tag "attack-sqli"] [tag "SQLi"] [tag "OWASP_CRS/WEB_
ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_
TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] 
[tag "paranoia-level/3"] [hostname "10.x.x.x"] [uri 
"/authenticate/login"] [unique_id "156345138464.788934"] 
[ref "o2,36o2,36o42,42o42,42o89,43o89,43o137,43o137,43v201,
193t:urlDecodeUni"], client: 10.x.x.x, server: localhost, 
request: "POST /authenticate/login HTTP/1.0", host: 
"localhost:8080", referrer: "http://localhost:8080/"

В первую очередь следует обратить внимание на следующее:

• ModSecurity: Access denied with code 403 (phase 2) - запрос был заблокирован фильтром ModSecurity со статус кодом 403 (статус код может быть переопределен с помощью постобработчика). Лог сообщения о блокировке запроса со статус кодом больше 530 рекомендуется игнорировать;

• REQUEST_COOKIES:TE3 - часть сообщения, на которой сработало правило. В данном примере это данные, содержащиеся в cookie запроса с именем TE3;

• id "7232" - ID сработавшего правила;

• [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "SQLi"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [tag "paranoia-level/3"] - теги сработавшего правила.

Отключение правил фильтрации ModSecurity#

Внимание!

Рекомендуется вносить правила-модификаторы, описанные в данной статье, в отдельный файл с говорящим названием. Например, mds_exclusions.conf.

filters:
  filter_mds:
    custom_rules:
      - mds_exclusions.conf
        ...

Файл с правилами-модификаторами должен быть расположен первым в блоке custom_rules.

Где находятся правила фильтрации?#

Расположение правил фильтрации зависит от способа подключения правил:

• если правила подключены в блоке rules, то директория с правилами расположена /sowa/profile_name/common/rules/modsecurity/sowa/[набор_правил];

  filters:
    filter_mds:
      rules:
        - sowa-ufs
  

• если правила подключены в блоке custom_rules, то директория с правилами расположена /sowa/profile_storage/custom/profile_name/[набор_правил].

  filters:
    filter_mds:
      custom_rules:
        - ufs_rules/rules.conf
  

Отключение проверки части сообщения для определенного сервиса (run-time)#

Примечание: ctl:ruleRemoveTargetById поддерживает возможность использования регулярных выражений.

Например,

SecRule REQUEST_FILENAME "@endsWith /wp-login.php" "id:9002100,phase:2,t:none,nolog,block,ctl:ruleRemoveTargetById=1;ARGS:'/^(p|P):wd$/'"

SecRule REQUEST_URI "@beginsWith /service/v1/context/one" \
"phase:1,id:1,t:none,pass,nolog,ctl:ruleRemoveTargetById=7199;ARGS:json.fields.laborActivity:customer:employerName"
SecRule REQUEST_URI "@beginsWith /service/v1/context/two" \
"phase:1,id:2,t:none,pass,nolog,ctl:ruleRemoveTargetById=7228;REQUEST_COOKIES"

где:

• /service/v1/context/one и/service/v1/context/two - контексты сервисов, для которых необходимо отключить правило. Возможно использовать регулярное выражение, если необходим широкий скоуп url для отключения правил, для этого есть оператор @rx;

  "@rx /service/v[1-9]/context/(one|two|three)"
  

• 1 и 2 - id правила-модификатора. Должно быть уникальным значением либо от 1 до 999 (для исключения любых правил), либо больше 900000 (для исключения правил, обрабатывающих тело запроса или ответ);

• phase:1 - фаза работы правила с исключением. Всегда 1, т.к. необходимо, чтобы правило с исключением срабатывало раньше обрабатываемого правила;

• 7199 и 7228 - id правила, для которого необходимо отключить проверку части сообщения;

• ARGS:json.fields.laborActivity:customer:employerName и REQUEST_COOKIES - часть сообщения, проверку которой необходимо отключить. Можно извлечь из лога о срабатывании правила, для которого необходимо исключение. Например, Matched Data: of(1) found within ARGS:json.ValidTo.

Кроме того, в аргументах можно также использовать регулярные выражения следующим образом:

SecRuleUpdateTargetById 942421 !REQUEST_COOKIES_NAMES:/PD_STATEFUL_[A-Za-z0-9_-]*/

где:

• 942421 - id правила, для которого создается исключение;

• !REQUEST_COOKIES_NAMES:/PD_STATEFUL_[A-Za-z0-9_-]*/ - исключаемый из проверки элемент;

• /PD_STATEFUL_[A-Za-z0-9_-]*/ - регулярное выражение.

Отключение проверки части сообщения для профиля (configure-time)#

SecRuleUpdateTargetById 7199 "!ARGS:json.fields.laborActivity:customer:employerName"

где:

• 7199 - id правила, для которого необходимо отключить проверку части сообщения;

• ARGS:json.fields.laborActivity:customer:employerName - часть сообщения, проверку которой необходимо отключить.

Перевод правила в неблокирующий режим для профиля (configure-time)#

В неблокирующем режиме правило не удаляется и продолжает использоваться при фильтрации.

При срабатывании правила, блокировка запроса\ответа не происходит, но сообщение о срабатывании правила записывается в лог.

1. Предпочтительный вариант с добавлением правила-модификатора в mds_exclusions.conf

   SecRuleUpdateActionById 7199 pass
   

   где:

   • 7199 - id правила, которое необходимо перевести в неблокирующий режим.

2. Если набор правил подключен в блоке custom_rules, может быть модифицировано непосредственно само правило.

Для перевода в неблокирующий режим, необходимо изменить параметр block или deny на pass.

Удаление правила для профиля (configure-time)#

1. Предпочтительный вариант с добавлением правила-модификатора в mds_exclusions.conf:

   SecRuleRemoveById 7199
   

   где:

   • 7199 - id правила, которое необходимо перевести в неблокирующий режим.

2. Если набор правил подключен в блоке custom_rules, может быть удалено непосредственно само правило.

3. Также есть возможность отключения группы правил по определенному тегу:

   SecRuleRemoveByTag "SQLi"
   

   где SQLi - тег правила.

Работа с содержимым в base64#

Существует возможность валидировать входящий xml запрос, закодированный в base64. Валидация осуществляется путем добавления модифицированных правил фильтрации. Рассмотрим валидацию на примере классического CMS контейнера.

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

При адаптации правил для тэгов с содержимым base64 необходимо:

1. Добавить в правило трансформацию base64.

   t:base64Decode
   

2. Настроить аргументы правила на выбранный тэг.

   В качестве примера рассмотрим одно из правил. Ниже приведено исходное правило mds:

   SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_HEADERS:User-Agent|REQUEST_HEADERS:Referer|ARGS_NAMES|ARGS|XML:/* "@detectSQLi" \
     "msg:'SQL Injection Attack Detected via libinjection',\
      id:7199,\
      severity:'CRITICAL',\
      rev:'1',\
      ver:'OWASP_CRS/3.0.0',\
      maturity:'1',\
      accuracy:'8',\
      phase:request,\
      block,\
      multiMatch,\
      t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:removeComments,\
      capture,\
      logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
      tag:'application-multi',\
      tag:'language-multi',\
      tag:'platform-multi',\
      tag:'attack-sqli',\
      tag:'SQLi',\
      tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
      tag:'WASCTC/WASC-19',\
      tag:'OWASP_TOP_10/A1',\
      tag:'OWASP_AppSensor/CIE1',\
      tag:'PCI/6.5.2',\
      setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
      setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},\
      setvar:'tx.msg=%{rule.msg}',setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{matched_var}" 
   

   Для валидации base64 модифицируем приведенное правило следующим образом:

   SecRule XML:////*/*/*/*/*/*[local-name()='X509Certificate']/text()|XML:////*/*/*/*[local-name()='DigestValue']/text()|XML:////*/*/*/*[local-name()='SignatureValue']/text()  "@detectSQLi" \
     "msg:'SQL Injection Attack Detected via libinjection',\
      id:77199,\
      severity:'CRITICAL',\
      rev:'1',\
      ver:'OWASP_CRS/3.0.0',\
      maturity:'1',\
      accuracy:'8',\
      phase:request,\
      block,\
      multiMatch,\
      t:none,t:base64Decode,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:removeComments,\
      capture,\
      logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
      tag:'application-multi',\
      tag:'language-multi',\
      tag:'platform-multi',\
      tag:'attack-sqli',\
      tag:'SQLi',\
      tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
      tag:'WASCTC/WASC-19',\
      tag:'OWASP_TOP_10/A1',\
      tag:'OWASP_AppSensor/CIE1',\
      tag:'PCI/6.5.2',\
      setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
      setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},\
      setvar:'tx.msg=%{rule.msg}',setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{matched_var}"
   

Созданный набор дополнительных правил REQ_XPATH.conf необходимо добавить в общий файл с правилами rules.conf.

Подключение правил в профиле осуществляется с помощью команды:

filter_mds:
   custom_rules:
-  путь в ресурсной папке профиля/rules.conf

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

Таймауты обработки тела сообщений ModSecurity#

Во избежание проблем с "зависанием" обработки тел сообщений фильтром ModSecurity добавлена возможность ограничения работы фильтра по времени.

Настройка ограничения осуществляется с помощью следующих директив:

Обратите внимение, что таймауты распространяются только на обработку тела запроса/ответа, а время обработки заголовков не учитывается.

Следующие переменные появились на уровне правил для обработки сообщений, прерванных по таймауту:

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

Например, правило для запроса будет выглядеть следующим образом:

SecRule REQUEST_TIMEOUT_ERROR "!@eq 0"
"id:'200003', \
phase:5,\
t:none,\
log,\
pass,\
msg:'MDS:%{request_timeout_error_msg}',\
tag:'timeout-error',\
logdata:'Request timeout error',
severity:2"

В этом случае проверяется, что REQUEST_TIMEOUT_ERROR !=0 (т.е. что таймаут сработал), и в лог уходит сообщение:

MDS:%{request_timeout_error_msg} 

(в переменной request_timeout_error_msg записано тело запроса).

Аналогичное правило необходимо будет сделать и для ответа с переменными REQUEST_TIMEOUT_ERROR и request_timeout_error_msg.

Фильтрация тел ответов парсером JSON/XML#

Настройка фильтрации тел ответов парсером JSON/XML осуществляется с помощью директивы SecResponceBodyProcessor, которая может принимать значения JSON или XML, в зависимости от формата соответствующего тела ответа.

Для обработки тел ответов процессором были добавлены следующие переменные:

Для использования процессора нужно в файл INIT.conf добавить соответствующее правило.

Пример ниже демонстрирует включение процессора XML в случае, если в заголовках ответа приходит Content-Type: text/xml или application/xml.

SecRule RESPONSE_HEADERS:Content-Type "(?:text|application)/xml" \
"id:1101,ctl:responseBodyProcessor=XML,phase:3,pass,nolog,t:none,t:lowercase,rev:1,severity:2,tag:'CWAF',tag:'Initialization'"

Далее в файле RESP.conf можно будет использовать переменную XML_RESP для составления новых правил:

SecRule XML_RESP:/* "@pm ..\ ../" \
"phase:response,\
msg:'Path Traversal Attack (/../)',\
id:78113,\
ver:'OWASP_CRS/3.0.0',\
rev:'1',\
maturity:'9',\
accuracy:'7',\
multiMatch,\
t:none,t:base64Decode,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,\
block,\
severity:CRITICAL,\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
capture,\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-lfi',\
tag:'OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL',\
setvar:'tx.msg=%{rule.msg}',\
setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
setvar:tx.lfi_score=+%{tx.critical_anomaly_score},\
setvar:'tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL-%{matched_var_name}=%{matched_var}'"

Особенности совместного использования наборов правил ModSecurity#

В Platform V SOWA реализованы следующие наборы правил фильтрации ModSecurity:

• base - осуществляет проверку корректности входящих запросов (парсинг json/xml/multipart запросов);

• owasp-crs - наиболее полный набор правил, разрабатываемый OWASP, направленный на анализ запросов и ответов, а также защиту от:

  • SQL Injection (SQLi);

  • Cross Site Scripting (XSS);

  • Local File Inclusion (LFI);

  • Remote File Inclusion (RFI);

  • Remote Code Execution (RCE);

  • HTTPoxy Shellshock;

  • Session Fixation;

  • Scanner Detection;

  • Metadata/Error Leakages;

• comodo - набор правил, основанный на owasp, в который включены доработки в области минимизации ложнопозитивных срабатываний и оптимизации ресурсоемкости.

Оба набора правил (owasp и comodo) не имеют в своем составе включения парсинга входящих и исходящих сообщений, что обеспечивается набором правил base.

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

Ниже приведены особенности совместного использования наборов правил.

Стоит отметить, что некоторые интеграции, обеспечиваемые Platform V SOWA, обладают рядом специфичных свойств, поэтому на основе base + owasp + comodo были подготовлены следующие наборы правил:

• sowa-http - набор для http-proxy сервисов, минимальные доработки для исключения ложноположительных срабатываний;

• sowa-ufs - форк от набора правил sowa-http с фокусом на производительности правил;

• sowa-kafka и sowa-mq - наборы для примитивов http-kafka-proxy и http-mq-proxy соответственно. Не включают в себя правила с анализом ответов от upstream, что позволяет экономить ресурсы в вышеописанных интеграциях;

• sowa-ws - правила со специфичными исключениями для проксирования websocket в примитивах ws-proxy.

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