Home / server / Questions / 968610
Accepted
Yes Barry
Asked: 2019-05-24 10:17:24 +0800 CST

mod_security X-Forwarded-For not being blocked

  • 772

I made some changes to my config as per this suggestion:

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}'"

But nothing seems to happen. I noticed that my apache error_log was using the default error log format and logging everything as 127.0.0.1.

So I changed my ErrorLogFormat to:

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

That made my logs better, but ModSecurity is still not doing any blocking. What's weird is that most of the ModSec logs in the apache error_log have an extra client IP section in them:

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

I have no idea where the extra [client 127.0.0.1] is coming from - I know it's definitely only doing this for ModSecurity logs in the error_log.

It seems like either ModSecurity is either constantly trying to block 127.0.0.1 or just not blocking anything..

So how can I get ModSecurity to block using the X-Forwarded-For header?

NOTE

  1. I do have SecRuleEngine On set properly.
  2. Versions: Apache 2.4, ModSecurity 2.9, OWASP 3
security

1 Answers

  1. Best Answer

    The first part of your linked suggestion has this

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

    As you can see it specifies that x-forwarded-for is part of REQUEST_HEADERS but that is missing from your version of this.

    Do be aware that just logging the IP will not cause blocking. It is used to persist data that can be used in subsequent rules (e.g. log a counter against an IP and iterate it with each request, and then block if it goes above a certain limit for basic DoS protection). So make sure you’ve got some rules configured to DO something with that IP address!

    Also, as discussed in the comments, ModSecurity logs collections in a disk based file. This causes contention when lots of Apache processes try to access it at the same time. And the cleanup that ModSecurity does also can fail meaning the file grows and grows until it eats up all disk space or slows Apache to a crawl. I am not a fan of using them, especially on a site with an volume. I see them as a proof of concept of what ModSecurity could do to expand its single request rules based engine to a cross request one, but it’s not production ready IMHO. For more on this see here: https://sourceforge.net/p/mod-security/mailman/message/34393121/

    The double client_ip logging is a remnant of when ModSecurity used to use a non-standard way of logging. They moved to Apache native logging (which has more features - like the ability to log HTTP Headers like x-forwarded-for) but only noticed late the double client_ip (as both Apache standing logging module and ModSecurity is now logging this). They left as is to avoid breaking anyone who depended on the original client_ip logging. See here for more details: https://github.com/SpiderLabs/ModSecurity/pull/840

    • 1