Я размещаю приложение nextcloud на своем производственном сервере apache2, на котором я использую modsecurity для защиты.

Поскольку modsecurity будет определять многие запросы, сгенерированные Nextcloud, как ложные срабатывания, я хочу включить специальные исключения modsecurity nextcloud через tx.crs_exclusions_nextcloud=1. Поскольку я размещаю несколько vHosts/Subdomains на этом сервере, а nextcloud имеет свой собственный (а также то, что нельзя делать такие исключения глобально для каждого субдомена), я хочу включить эти исключения через Apache VirtualHost Config Directory:

<VirtualHost _default_:443>
    ServerName nextcloud.mydomain.tld
    ...
    SecAction "id:x,pass,log,setvar:tx.crs_exclusions_nextcloud=1" #also tried ALL possible combinations of variables (id, log, nolog, pass, ...) etc, please don't assume the issue being here as long as you don't are 100% sure.
    ...
</VirtualHost>

Это не работает. И я совершенно не понимаю, почему. В документации сказано, что эту команду можно использовать в разделе VirtualHost, и я проверил порядок включения файлов конфигурации.
Заказ:

• Загружается сам мод
  
• /etc/apache2/mods-enabled/security2.conf
  
• /etc/modsecurity/000_modsecurity.conf
  
• /etc/modsecurity/001_crs-setup.conf
  
• /etc/modsecurity/rules/*.conf | OWASP ModSecurity CRS v3.3.0 ‹--- Определение правила
• /etc/modsecurity/002_crs-exclusions.conf ‹--- Текущее исправление, см. ниже
• Site-Configs ‹--- ‹VirtualHost›

Поскольку SecAction в VirtualHost не работает, а modsecurity по-прежнему определяет многие запросы nextcloud как ложные срабатывания, в настоящее время я использую последний файл, 002_crs-exclusions.conf, для активации исключений nextcloud:

SecRule REQUEST_HEADERS:Host ^nextcloud.mydomain.tld$ "id:900130,phase:1,nolog,pass,t:none,setvar:tx.crs_exclusions_nextcloud=1"

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

Второй выпуск

Modsecurity блокирует URI запроса /remote.php/dav/calendars/<user>/personal/<uuid>.ics, если пользователь пытается обновить запись календаря. Это связано с тем, что этот запрос имеет заголовок Content-Type: application/xml, но не содержит настоящего xml-контента, что приводит modsecurity к ошибке синтаксического анализа libxml2. Итак, я хочу исключить правило № 200000 (это правило определяет, что запросы заголовка Content-Type: application/xml должны проходить через xml-парсер modsecurity) для URI /remote.php/dav/calendars/.* с SecRuleRemoveById через директиву «Местоположение»:

<Location ~ "/remote.php/dav/calendars/.*">
    Header set LocDebug "works"  #to check if <Location> is applied correctly
    SecRuleRemoveById 200000
</Location>

Результат:
Каждый запрос, поступающий на один из этих URI (загрузка календаря и т. д.), содержит заголовок LocDebug, показывающий, что правила в ‹Location ...› применяются успешно, но если пользователь попытается обновите запись календаря (запрос с неверным XML), запрос по-прежнему завершается с ошибкой HTTP 500, а modsecurity сообщает об ошибке синтаксического анализа. Этот запрос не имеет заголовка LocDebug, что заставляет меня предположить, что есть какая-то проблема с порядком этих действий и примененных команд. относительно того, когда запрос фактически анализируется.
Я также пытался установить SecRuleRemoveById глобально, но это ВООБЩЕ не работает.

Я пробовал все, буквально все, и, как указано выше, с заказом не должно быть проблем.
Кто-нибудь знает, что я могу делать неправильно или в чем может быть проблема? Я не знаю.

Техническая информация:

• ОС: Debian 10 Buster - все пакеты последней версии.
• Апач: апач2.4.38-3+деб10у4
• ModSecurity: libapache2-mod-security2 v2.9.3-1