Я просто читаю - и экспериментирую с - modsecurity и надеюсь, что кто-то сможет немного рассказать о методе, стоящем за безумием.
Подход, который я обычно использую с любым брандмауэром, - это занести в белый список то, что я хочу, и заблокировать все остальное. Ничего из того, что я читал о modsecurity, похоже, использует этот подход, фокус, кажется, полностью основан на правилах, соответствующих известным угрозам, с исключением, основанным на отключении соответствующих идентификаторов. Меня это озадачивает, поэтому я уверен, что неправильно понял природу угрозы или программы.
Несомненно, наиболее водонепроницаемая настройка modsecurity будет соответствовать всем ожидаемым запросам, пока (.*?) все остальное?
Желаемый подход может быть реализован с помощью ModSecurity. Однако, если ваше приложение на 100% защищено, вам не нужен WAF, такой как ModSecurity (зачем беспокоиться о внесении в белый список запросов POST, которые вы хотите разрешить в ModSecurity, если вы можете просто сделать это в приложении?).
Общие наборы правил ModSecurity, такие как набор правил OWASP, предназначены для обнаружения общих угроз, а не для блокировки или разрешения определенного доступа к вашим URL-адресам. Они не предназначены для вашего приложения и конкретной настройки. Поверх них могут быть добавлены определенные правила. Сказать, что общие наборы правил по-прежнему имеют большую ценность, поскольку в них содержится много накопленных знаний. Вы говорите, что ваши запросы «экранированы должным образом», но это не такая простая задача, как следует из этого простого утверждения. Существуют различные способы обхода экранирования (кодирование URL-адресов, обратная косая черта, двойная обратная косая черта и т. Д.), И каждый из них отличается в зависимости от всех частей в вашей среде. Проверки SQL-инъекций в наборах правил OWASP, например, создавались годами и дорабатывались сообществом. Также то, что у вас есть хорошие проверки выхода в НЕКОТОРОЙ области приложения, не означает, что разработчики не забыли делать это для КАЖДОГО параметра / поля. Или что веб-сервер или сервер приложений не имеют какой-либо уязвимости еще до того, как достигнут вашего приложения.
Обычно ModSecurity дополнительный уровень защиты, поскольку веб-серверы должны быть открытыми по самой своей природе. Вы не можете занести в белый список только хорошие запросы и легко занести в черный список плохие из-за открытой и различающейся природы сети и того, как два похожих запроса (хорошие или плохие) могут выглядеть совершенно по-разному в зависимости от того, кто их отправляет. Ты в значительной степени иметь чтобы разрешить соединения HTTP / HTTPS, вы иметь чтобы разрешить такие аргументы, как параметры и файлы cookie, вы иметь чтобы разрешить запросы GET, хотя, как вы говорите, можно ограничить запросы POST определенными URL-адресами.
ModSecurity позволяет вам иметь общие проверки, позволяет вам иметь конкретные проверки (хотя я лично предпочитаю размещать их в веб-приложении как можно больше, если это не намного проще реализовать в ModSecurity), а также имеет дополнительное преимущество, позволяя вы должны быстро внедрить новые тесты и проверки по мере изменения ситуации (например, уязвимости нулевого дня, конкретные атаки и ошибки, обнаруженные вами при ведении журнала), давая вам время для внесения надлежащего патча / исправления позже.
Подумайте, если это уточнение поверхности атаки. Основной брандмауэр ограничивается портом 80/443, ваш веб-сервер и ModSecurity дополнительно удаляют «плохие запросы», затем приложение выполняет свои проверки, и, наконец, вы можете делать то, для чего приложение было предназначено.
Да, в идеале мы должны вносить в белый список только разрешенные запросы, но на самом деле это легче сказать, чем сделать ...