Annoying DNS queries with @rbl operator about modsecurity HOT 18 CLOSED

Who can spot the typos here? https://github.com/owasp-modsecurity/ModSecurity/blob/v3/master/src/operators/rbl.h#L70-L76

from modsecurity.

So, not really fixing this, but #3127.

from modsecurity.

Okay, I think I found the root cause.

libmodsecurity3 (I haven't checked mod_security2 yet) uses getaddrinfo() to make a DNS lookup here. This function uses the system's resolver.

If you have a search line in your /etc/resolv.conf, eg:

search 0x42.ch
nameserver ....
nameserver ....

then in case of a nonexistent domain response the resolver tries to look up the original query with appending your search value.

The possible workaround is that you use FQDN at the secrule:

SecRule REMOTE_ADDR "@rbl xbl.spamhaus.org." \

see the . (dot) character at the end of the service. This will prevent the second DNS query.

I don't know what would be the nice final solution: append an implicit . at the end of provider name if it does not contain, or just fix the documentation (which suggest this (used) form)?

(I think we have to check that in case of mod_security2 too).

Any ideas?

from modsecurity.

Personally, I'd go with the FQDN approach. If you want to check multiple domains you can write multiple rules, so there shouldn't be an argument for using resolv.conf as a fallback.

from modsecurity.

@airween Thank you.
This trick with the FQDN solves the queries with the search domain. It should be documented with the @rbl parameter. ;)

Seems the behaviour seen started with the upgrade to Debian Bookworm which installed systemd-resolved.

from modsecurity.

As the problem is solved (by using FQDN name) I'll close the issue.

from modsecurity.

That would be 0x42.ch in your case?

from modsecurity.

Yes

from modsecurity.

Do you happen to know if the apache / ModSec2 docker container has the same problem?

from modsecurity.

No, sorry. I only use the Nginx version.

from modsecurity.

@ne20002 thanks for the report.

Could you provide an example, how can I try the explained behavior?

It does not happen from other containers in the pod nor any other system in my network.

This means the "vanilla" ModSecurity instance does not do this?

from modsecurity.

This means the "vanilla" ModSecurity instance does not do this?

No, this just means that no other server in my network creates dns requests with the seen postfix. It's just the queries created by the @rbl checks.

This is the part in my config:

# xbl.spamhaus.org to block malicious/infected ips
SecRule IP:PREVIOUS_RBL_CHECK "@eq 1" "phase:1,id:910201,t:none,pass,nolog,skipAfter:END_RBL_LOOKUP"
  
SecRule REMOTE_ADDR "@rbl xbl.spamhaus.org" \
   "phase:1,id:910202,\
    t:none,pass,nolog,auditlog,\
    msg:'RBL Match for SPAM Source',\
    tag:'AUTOMATION/MALICIOUS',\
    severity:'CRITICAL',\
    setvar:'tx.msg=%{rule.msg}',\
    setvar:'tx.lfi_score=+%{tx.critical_anomaly_score}',\
    setvar:'tx.inbound_anomaly_score_pl1=+%{tx.critical_anomaly_score}',\
    setvar:ip.spammer=1,\
    expirevar:ip.spammer=86400,\
    setvar:ip.previous_rbl_check=1,\
    expirevar:ip.previous_rbl_check=86400,\
    skipAfter:END_RBL_CHECK"

SecAction "phase:1,id:910203,\
    t:none,nolog,pass,\
    setvar:ip.previous_rbl_check=1,\
    expirevar:ip.previous_rbl_check=3600"

SecMarker END_RBL_LOOKUP

SecRule IP:SPAMMER "@eq 1" \
    "phase:1,id:910204,\
    t:none,pass,nolog,auditlog,\
    msg:'Request from Known SPAM Source (Previous RBL Match)',\
    tag:'AUTOMATION/MALICIOUS',\
    severity:'CRITICAL',\
    setvar:'tx.msg=%{rule.msg}',\
    setvar:'tx.lfi_score=+%{tx.critical_anomaly_score}',\
    setvar:'tx.inbound_anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

SecMarker END_RBL_CHECK

from modsecurity.

Tip: lines 74 and 76.

from modsecurity.

Don't know if it solves this, but it is definitely broken.

from modsecurity.

@ne20002 could you check again with current master branch?

from modsecurity.

It might be difficult for @ne20002 if he is using pods for this, as the container is not updated with the new code from master.

@airween Maybe we can do a quick build and use the secrule he posted above with a simple curl test? From the source code, debug information is being printed with level 4 or up.

from modsecurity.

I can take a look at at the evening.

from modsecurity.

Just FYI: mod_security2 works as the same as libmodsecurity3. With the rules above it repeats the query, appending a . (dot) character. If I add a . at the end of xpl.spamhaus.org, then the engine makes only one (A) query.

We should decide how we want to solve it: append explicit . to the provider's name if there isn't it, or modify the documentation.

from modsecurity.