Вопрос или проблема
Я тестирую веб-приложение и установил ModSecurity 2.9, который запускает Core ModSecurity Rule Set версии 2.2.9, и для тестирования веб-приложения я также установил DVWA. Платформа: Windows. Я пытаюсь сделать инъекцию команд, и это разрешено, даже если я включил правила для инъекции команд modsecurity_crs_40_generic_attacks.conf. Все остальные правила для SQL-инъекций, XSS и т.д. работают нормально. 
Правило для инъекции команд выглядит следующим образом:
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?i)(?:;|\{|\||\|\||&|&&|\n|\r|`)\s*[\(,@\'\"\s]*(?:[\w'\"\./]+/|[\\\\'\"\^]*\w[\\\\'\"\^]*:.*\\\\|[\^\.\w '\"/\\\\]*\\\\)?[\"\^]*(?:\.[\"\^]*\w+)?\b" \
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'8',capture,t:none,t:normalisePath,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'950907',tag:'OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%{tx.0},skipAfter:END_COMMAND_INJECTION1"
SecMarker END_COMMAND_INJECTION1
Я хочу знать, что можно сделать, чтобы, если я инъектирую команду 127.0.0.1 & shutdown /l или что-либо еще после “&” в текстовом поле, ModSecurity перенаправил на страницу 403. Я прочитал аналогичные посты и решения; если я попробую, мой сервер Apache будет падать.
Ваш набор правил (2.2.9) “немного” устарел, вам следует использовать более новую версию (фактически 3.3).
Я не совсем понимаю ваш вопрос “что можно сделать, если я инъектирую…“.
Как вы видите, оператор – это @rx, и у него есть аргумент. Список переменных содержит ARGS, так что я предполагаю, что ваша форма содержит поле ввода, которое будет оцениваться как аргумент (член ARGS). Здесь я попытался продемонстрировать, как это правило проверяет ваш запрос.
Если ваше правило не сработало, это означает, что сравнение (ваше поле ввода с аргументом оператора) не совпадает, или движок не включен.
Поэтому, пожалуйста, проверьте вашу настройку SecRuleEngine, она должна быть включена On.
Мое мнение: возможно, правило не включает преобразование t:urlDecode, потому что, если вы отправите символ &, я предполагаю, что ваш браузер отправит его в закодированной форме.
Если возможно, обновите ваш Modsecurity, как сказал @airween.
Если я правильно понимаю, вы хотите блокировать сразу при обнаружении такой атаки, если это так:
- Измените разрушительное действие правила с “block” на “deny”
Посмотреть детали: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#deny
Ответ или решение
Для решения проблемы с неправильной работой модуля ModSecurity при попытке внедрения команд, необходимо обратить внимание на несколько ключевых аспектов. Если вы используете ModSecurity 2.9 с набором правил Core ModSecurity Rules Set версии 2.2.9 и не можете успешно заблокировать команды внедрения через DVWA (Damn Vulnerable Web Application), учитывайте следующие рекомендации:
1. Обновление ModSecurity и NGINX/Apache
Прежде всего, рекомендуется обновить вашу версию ModSecurity до более новой, например, до версии 3.3. Новые версии обычно включают не только исправления ошибок, но и улучшенные алгоритмы работы, которые могут повысить эффективность защиты.
2. Включите SecRuleEngine
Проверьте, что директива SecRuleEngine у вас установлена в значение On. Если она отключена, то ваши правила не будут применяться, и любые попытки внедрения пройдет без блокировки.
SecRuleEngine On3. Проверьте наличие предобработки (transformations)
Ваша текущая настройка правил может не учитывать, что некоторые символы, такие как &, могут быть отправлены в закодированном виде (например, &). Убедитесь, что в ваших правилах применяются соответствующие трансформации, такие как t:urlDecode, чтобы корректно обрабатывать закодированные данные:
t:urlDecode4. Тестирование правил
Необходимо протестировать ваше правило, чтобы убедиться, что оно действительно срабатывает при попытке внедрения. Используйте тестовые данные, которые вы ожидаете проверить, чтобы убедиться, что правило работает должным образом. Убедитесь, что ваша регулярная таблица в правиле соответствует ожидаемому формату ввода.
5. Изменение действия при обнаружении
Как упоминалось, изменение действий правила с block на deny позволит более агрессивно реагировать на атаки. Это изменит способ взаимодействия модуля с запросами и даст возможность автоматически закрывать соединение при обнаружении атаки:
"phase:2,log,deny," // изменить 'block' на 'deny'6. Мониторинг и журналирование
Включите журналирование с достаточным уровнем детализации, чтобы можно было диагностировать, почему определенные попытки не блокируются. Это поможет вам лучше понять, какие данные приходят и как они обрабатываются. Таким образом, вы сможете вносить необходимые изменения в правила.
7. Конфликты с другими правилами
Возможно, другие правила могут конфликтовать с вашим правилом для командного внедрения. Проверьте, имеются ли какие-то другие правила, которые могут принимать верх над вашим правилом и, таким образом, не позволяют ему блокировать запросы.
Заключение
Эти шаги должны помочь вам оптимизировать работу ModSecurity и эффективно обрабатывать попытки командного внедрения. Регулярное обновление и тестирование системы безопасности является важной частью предотврашения возможных угроз для вашего веб-приложения. Следуя данным рекомендациям, вы сможете значительно улучшить уровень защиты вашей инфраструктуры от атак, таких как Command Injection.