Назад | Перейти на главную страницу

mod_security X-Forwarded-Чтобы не заблокировать

Я внес некоторые изменения в свою конфигурацию согласно это предложение:

SecAction \
    "id:901321,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    initcol:global=global,\
    initcol:ip=%{x-forwarded-for}_%{tx.ua_hash},\
    setvar:'tx.real_ip=%{x-forwarded-for}'"

Но вроде ничего не происходит. Я заметил, что мой apache error_log использовал формат журнала ошибок по умолчанию и записывал все как 127.0.0.1.

Итак, я изменил свой ErrorLogFormat кому:

ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %{X-Forwarded-For}i] %M% ,\ referer\ %{Referer}i"

Это улучшило мои журналы, но ModSecurity по-прежнему не блокирует. Что странно, так это то, что большинство журналов ModSec в В apache error_log есть дополнительный раздел IP-адреса клиента:

[Wed May..2019] [err] [pid X:tid X] [client XXX.XX.XX.XXX] [client 127.0.0.1] ModSecurity: Warning...

Я понятия не имею, где лишний [client 127.0.0.1] исходит от - я знаю, что он определенно делает это только для журналов ModSecurity в error_log.

Похоже, либо ModSecurity постоянно пытается заблокировать 127.0.0.1, либо просто ничего не блокирует ..

Итак, как я могу заставить ModSecurity заблокировать, используя X-Forwarded-For заголовок?

НОТА

  1. я делать иметь SecRuleEngine On установить правильно.
  2. Версии: Apache 2.4, ModSecurity 2.9, OWASP 3

Первая часть вашего связанного предложения имеет это

SecAction "phase:1,nolog,pass,initcol:IP=%{REQUEST_HEADERS.x-forwarded-for}"

Как вы можете видеть, он указывает, что x-forwarded-for является частью REQUEST_HEADERS, но этого нет в вашей версии this.

Имейте в виду, что простая регистрация IP не вызовет блокировки. Он используется для сохранения данных, которые могут использоваться в последующих правилах (например, регистрировать счетчик по IP-адресу и повторять его с каждым запросом, а затем блокировать, если он превышает определенный предел для базовой защиты от DoS). Поэтому убедитесь, что у вас настроены некоторые правила, позволяющие что-то делать с этим IP-адресом!

Кроме того, как обсуждалось в комментариях, ModSecurity регистрирует коллекции в файле на диске. Это вызывает конкуренцию, когда множество процессов Apache пытаются получить к нему доступ одновременно. И очистка, которую выполняет ModSecurity, также может потерпеть неудачу, что означает, что файл растет и растет, пока он не займет все дисковое пространство или не замедлит Apache до обхода. Я не любитель их использовать, особенно на сайте с томом. Я рассматриваю их как доказательство концепции того, что ModSecurity может сделать, чтобы расширить свой механизм, основанный на правилах единого запроса, до механизма перекрестных запросов, но IMHO он не готов к производству. Подробнее об этом см. Здесь: https://sourceforge.net/p/mod-security/mailman/message/34393121/

Двойное ведение журнала client_ip - это пережиток того, когда ModSecurity использовала нестандартный способ ведения журнала. Они перешли на собственное ведение журнала Apache (которое имеет больше функций - например, возможность регистрировать HTTP-заголовки, такие как x-forwarded-for), но только поздно заметили двойной client_ip (поскольку оба модуля постоянного ведения журнала Apache и ModSecurity теперь регистрируют это). Они оставили все как есть, чтобы не нарушить работу тех, кто зависел от исходного журнала client_ip. Подробнее см. Здесь: https://github.com/SpiderLabs/ModSecurity/pull/840