How to tell Modsec to not treat lines coming from unix socket

[quenenni]

Hello,

I configured Anubis in our setup and now have these kind of lines in Apache logs:

www.XXXX.be:80 unix: - - [04/Mar/2026:18:57:24 +0100] "GET /actes/login.php HTTP/1.0" 200 4567 "http://www.XXXX.be/actes/tab_naiss.php" "Anubis-OGTag-Fetcher/1.0"

And Modsecurity doesn't like the "unix:" (instead of the ip address) part and I have lots of noise in the error.log

[Wed Mar 04 18:57:24.332780 2026] [security2:error] [pid 1099861:tid 1099861] [client 127.0.0.1:54318] [client 127.0.0.1] ModSecurity: IPmatch: bad IPv6 specification "unix:". [hostname "www.XXXX.be"] [uri "/actes/login.php"] [unique_id "aahyhOAeY7rI59rQMcYbPgAAAAc"], referer: http://www.XXXX.be/actes/tab_naiss.php
[Wed Mar 04 18:57:24.332955 2026] [security2:error] [pid 1099861:tid 1099861] [client 127.0.0.1:54318] [client 127.0.0.1] ModSecurity: Rule processing failed (id=905110, msg=). [hostname "www.XXXX.be"] [uri "/actes/login.php"] [unique_id "aahyhOAeY7rI59rQMcYbPgAAAAc"], referer: http://www.XXXX.be/actes/tab_naiss.php

I tried to configure a rule in my REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf (first rule in the file):

SecRule REQUEST_HEADERS:User-Agent  "@pm Anubis-OGTag-Fetcher"    "phase:request,id:999,log,allow,ctl:ruleEngine=off"

I can see in the log that my rule is treated, but still have the 2 lines from the rule 905110

[Wed Mar 04 18:57:24.338704 2026] [security2:error] [pid 1099861:tid 1099861] [client 127.0.0.1:54318] [client 127.0.0.1] ModSecurity: Access allowed (phase 2). Matched phrase "Anubis-OGTag-Fetcher" at REQUEST_HEADERS:User-Agent. [file "/etc/modsecurity/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf"] [line "10"] [id "999"] [hostname "www.XXXX.be"] [uri "/actes/login.php"] [unique_id "aahyhOAeY7rI59rQMcYbPgAAAAc"], referer: http://www.XXXX.be/actes/tab_naiss.php

My /etc/apache2/mods-enabled/security2.conf file:

<IfModule security2_module>
    # Default Debian dir for modsecurity's persistent data
    SecDataDir /var/cache/modsecurity

    Include /etc/modsecurity/modsecurity.conf
    Include /etc/modsecurity/crs-setup.conf
    Include /etc/modsecurity/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
    Include /etc/modsecurity/crs/*.conf
    Include /etc/modsecurity/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
</IfModule>

How can I do to have Modsec no treat these lines from Anubis in apache logs?

The rule 905110 is way after my rule, so why Modsec does treat this rule when my rule says to allow the request and disable Modsec?

Any suggestion on how to handle this?

Thanks

NB: I also contacted Anubis in hope they can tell me if I can avoid these lines in the logs, waiting to see if there is a solution.

[airween]

Hi @quenenni,

sorry to hear you faced with this issue.

I'm not an Apache expert (at least not as good to know the solution), and I've never met any similar issue.

But I think I understand the problem: ModSecurity wants to use the client's IP address in many cases, and if that field is empty, that could be a problem.

You might try Apache's mod_remoteip module, with something similar config:

<IfModule mod_remoteip_module>
    RemoteIPHeader X-Forwarded-For
    RemoteIPInternalProxy 127.0.0.1
</IfModule>

But honestly, I don't have any other idea now.

@dune73 have you faced any issue like this one?

[airween]

And one more very important thing:

I tried to configure a rule in my REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf (first rule in the file):

SecRule REQUEST_HEADERS:User-Agent  "@pm Anubis-OGTag-Fetcher"    "phase:request,id:999,log,allow,ctl:ruleEngine=off"

Please NEVER use any target which depends on the client, like REQUEST_HEADERS:User-Agent. It's easy to replace in any request and that turns off your engine.

[quenenni]

Thanks for your help @airween .

The thing is that it's Anubis itself who initiate the query (I don't know why yet, hopefully they can explain me the reason behind this).
But that means there isn't an intial ip address (or remote ip or real ip).
All the others requests coming from outside have their ip address in the logs.

I then can't use your example as it will remove all good ip addresses.

Please NEVER use any target which depends on the client, like REQUEST_HEADERS:User-Agent. It's easy to replace in any request and that turns off your engine.

I know and I won't put such a rule in my production server, but I wanted to ask why this rule is not enough for Modsec to not go on with other rules.

As I understand, the fact I used 'allow' and not 'pass' as parameter should stop Modsec from testing other rules after mine, or didn't I understand how Modsec works?

But I also understand that even then, as I can't use the rule like as such, I'm still not sure how I'll be able to find the right rule.

Maybe if I could play with the fact that the ip address is 'unix:' instead of an actual ip address.
Any chance there is a way to achieve this?

Here is a example of modsec log for such a line in the logs

--6eb86c06-A--
[04/Mar/2026:16:00:39.547019 +0100] aahJF3-7hVkn1hzZA2nPlQAAAAY unix: 47112 127.0.0.1 80
--6eb86c06-B--
GET /actes/tab_naiss.php
Host: XXXX.be
X-Real-IP: unix:
X-Http-Version: HTTP/1.1
X-Forwarded-For: unix:
X-Forwarded-Proto: https
X-Forwarded-Port: 443
Connection: close
User-Agent: Anubis-OGTag-Fetcher/1.0
Accept-Encoding: gzip

--6eb86c06-F--
HTTP/1.1 301 Moved Permanently
Location: http://www.XXXX.be/actes/tab_naiss.php
Content-Length: 431
Connection: close
Content-Type: text/html; charset=iso-8859-1

--6eb86c06-E--
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.XXXX.be/actes/tab_naiss.php">here</a>.</p>
<hr>
<address>Apache/2.4.66 (Debian) Server at XXXX.be Port 80</address>
</body></html>

--6eb86c06-H--
Message: IPmatch: bad IPv6 specification "unix:".
Message: Rule processing failed (id=905110, msg=).
Apache-Error: [file "apache2_util.c"] [line 275] [level 3] [client 127.0.0.1] ModSecurity: IPmatch: bad IPv6 specification "unix:". [hostname "XXXX.be"] [uri "/actes/tab_naiss.php"] [unique_id "aahJF3-7hVkn1hzZA2nPlQAAAAY"]
Apache-Error: [file "apache2_util.c"] [line 275] [level 3] [client 127.0.0.1] ModSecurity: Rule processing failed (id=905110, msg=). [hostname "XXXX.be"] [uri "/actes/tab_naiss.php"] [unique_id "aahJF3-7hVkn1hzZA2nPlQAAAAY"]
Stopwatch: 1772636439537287 9880 (- - -)
Stopwatch2: 1772636439537287 9880; combined=3403, p1=2959, p2=0, p3=20, p4=83, p5=341, sr=353, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.7 (http://www.modsecurity.org/); OWASP_CRS/3.3.4.
Server: Apache/2.4.66 (Debian)
Engine-Mode: "ENABLED"

--6eb86c06-Z--

[quenenni]

I found that these error in error.log are only for rules where the first line of the rule use @ipMatch

I created a rule with ipMatch in the first line and the number of errors in error.log doubled.

I then modified the rule 905110 (/usr/share/modsecurity-crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf) to this:

#
# Exception for Apache internal dummy connection
#
SecRule REQUEST_HEADERS:User-Agent  "!@pm Anubis-OGTag-Fetcher/1.0" \
    "id:905110,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-apache',\
    tag:'attack-generic',\
    ver:'OWASP_CRS/3.3.4',\
    chain"
    SecRule REMOTE_ADDR "@ipMatch 127.0.0.1,::1" \
        "t:none,\
        chain"
    SecRule REQUEST_HEADERS:User-Agent "@endsWith (internal dummy connection)" \
        "t:none,\
        chain"
        SecRule REQUEST_LINE "@rx ^(?:GET /|OPTIONS \*) HTTP/[12]\.[01]$" \
            "t:none,\
            ctl:ruleEngine=Off,\
            ctl:auditEngine=Off"

And no more errors in the logs.
And if I'm not wrong, this modification should not be a problem in production (except I'll disable the official rule 905110 and will create a rule 905111 that will be like this one to not modify file from the package).

---

I wrote earlier this:

As I understand, the fact I used 'allow' and not 'pass' as parameter should stop Modsec from testing other rules after mine, or didn't I understand how Modsec works?

My custom rules are loaded before all the Crs rules (as configured in this file /etc/apache2/mods-enabled/security2.conf).

In my custom rule file, the first rule was my test I showed you before:

SecRule REQUEST_HEADERS:User-Agent  "@pm Anubis-OGTag-Fetcher"    "phase:request,id:999,log,allow,ctl:ruleEngine=off"

My second test rule in my custom file was this (more basic, but similar to rule 905110):

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1"  "phase:request,id:1000,nolog,allow,ctl:ruleEngine=off"

With this, in error.log, I only see the error for the rule 905110, but not for the rule 1000.

If I comment out the first rule, in the error.log, I see an error for id 905110 and one for id 1000.

That means that my first rule works as expected and no other rules from my custom files are tested.

So why the rule 905110 from Crs is triggered despite being loaded after my custom rules?
Is it because my assumption works only for rules in one file, but for different files, they are still tested?

[dune73]

I'd try to identify the request early in phase 1 and then disable the rule engine via a ctl-statement.

And this unix: as part of the IP address is seriously strange. I'm sure ModSec is not the only thing that misbehaves. I do not know who is to blame here, but if Anubis did this and they did this deliberately, then I think they should fix it and not you.

[quenenni]

@dune73

Thanks for your help.

My feeling here is that Anubis is doing something wrong. For me, it shouldn't do a request with 'unix:' as the initial request was blocked by anubis (the request didn't pass the challenge).
I'm waiting to hear from them to know if I did something wrong or not (I linked the post in Anubis repo to help having the all context).

So I'm happy to have found a temporary fix in Modsec to not have all the errors in error.log in the meantime.

My question that remains here, is why the rule 905110 is triggered.
AS you said, "I'd try to identify the request early in phase 1", and that's what I did with 'request' as option for my first rule in my custom rule file that is loaded as first file, and I ask to disable Modsec in that case "ctl:ruleEngine=off".

[dune73]

Please keep up us posted.

And I do not really see why this rule would be triggered. But this remote IP is so funny, you can not really anticipate how an internal operator aimed at IP addresses would behave. Or anything else.

[quenenni]

The solution was to use a TCP port between Anubis and Nginx instead of a unix socket and use "proxy_add_x_forwarded_for" instead of "remote_addr" in the proxy_set_header X-Real-IP

The Nginx vhost after Anubis

server {
    listen 8003;

    server_name _;

    # Get the visiting IP from the TLS termination server
    set_real_ip_from 127.0.0.1;
    real_ip_header X-Real-IP;

    location / {
        proxy_pass http://127.0.0.1:80;
        modsecurity_rules_file /etc/nginx/modsecurity_includes.conf;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $proxy_add_x_forwarded_for;
        proxy_set_header X-Http-Version $server_protocol;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;
    }
    access_log /var/log/nginx/anubis_return_access.log withhost;
    error_log /var/log/nginx/anubis_return_error.log;
}

And in Anubis:

TARGET=http://127.0.0.1:8003

I still have all the lines that I think Anubis shouldn't do

www.xxxx.be 127.0.0.1 - - [13/Mar/2026:15:47:11 +0100] "GET /films/production/darius-films/grille/B/6:9/title/ASC HTTP/1.1" 301 0 "-" "Anubis-OGTag-Fetcher/1.0"

But at least, I don't have problem with Modsec anymore as the problematic lines have now 127.0.0.1 as ip address in the logs instead of unix:
Here is the link to my last post about this:
TecharoHQ/anubis#1509

Closing this as Modsec is running nicely with Nginx connector and I'm very happy.
Thanks a lot for all your help.