No "real" capture of HTTP:BL response

[nesretep-anp1]

Unfortunately the RBL operator returns the originally IP on match, but not the "real" response. This means, that this operator only could be used on a boolean base like "If there is a DNS response, then match".

IMHO being able to filter requests based on a score would be much better and more feasible, so I changed the code like mentioned below.

rbl.cc before 236

    if (rule && t && rule->hasCaptureAction()) {
        char *respBl;
        int first, second, third, fourth;

        respBl = inet_ntoa(sin.sin_addr);

        if (sscanf(respBl, "%d.%d.%d.%d", &first, &second, &third, &fourth) != 4) {
            ms_dbg_a(t, 4, "RBL lookup of " + ipStr + " failed: bad response");
            //return false;
        }
        else {
            t->m_collections.m_tx_collection->storeOrUpdateFirst(
            "1", std::string(respBl));

            t->m_collections.m_tx_collection->storeOrUpdateFirst(
            "2", std::to_string(fourth));
        }

        furtherInfo(&sin, ipStr, t, m_provider);
    }

rbl.cc before 126

        trans->m_collections.m_tx_collection->storeOrUpdateFirst(
        "2", std::to_string(score));

        trans->m_collections.m_tx_collection->storeOrUpdateFirst(
        "3", std::to_string(type));
        trans->m_collections.m_tx_collection->storeOrUpdateFirst(
        "4", std::to_string(days));

[airween]

@nesretep-anp1,

thanks for shared your idea.

Unfortunately I don't see the use case, so first could you share a real example where do you use this code? I mean write a rule...

Then feel free to send a PR.

Note, that unfortunately there is no any related test in our test cases, so it would be nice to figure out how can we check that all expected behavior is what we need.

[nesretep-anp1]

Well, ... if I'm right, then using the RPL alone results in a blocking each responded (by HTTP:BL) request; which means search engines as well e.g.! (The score of HTTP:BL is in Byte 3, not 4).

So, the rule for me looks like ...

SecRule REQUEST_HEADERS:X-Forwarded-For "@rbl dnsbl.httpbl.org." "id:95,chain,phase:1,t:none,capture,deny,msg:'HTTPBL Match of Client IP.',logdata:'%{tx.httpbl_msg}',setvar:tx.httpbl_msg=%{tx.1}"
  SecRule TX:2 "@gt 20" 

[airween]

Sorry, but now I'm totally confused about what do you want to achieve.

Well, ... if I'm right, then using the RPL alone results in a blocking each responded (by HTTP:BL) request; which means search engines as well e.g.!

It depends on the rule. @rbl is an operator and it needs an argument. The argument describes what RBL engine you want to use.

All operators (not just the @rbl) return with a TRUE or a FALSE value when checking the target (REQUEST_HEADERS:X-Forwarded-for in your rule). Based on that logical value (TRUE vs FALSE) the rule other parts (a mandatory disruptive action) decides the request will be blocked or not.

(The score of HTTP:BL is in Byte 3, not 4).

Sorry, but I don't understand this. What byte you think of it?

So, the rule for me looks like ...

SecRule REQUEST_HEADERS:X-Forwarded-For "@rbl dnsbl.httpbl.org." \
   "id:95,\
   chain,\
   phase:1,\
   t:none,\
   capture,\
   deny,\
   msg:'HTTPBL Match of Client IP.',\
   logdata:'%{tx.httpbl_msg}',\
   setvar:tx.httpbl_msg=%{tx.1}"
   SecRule TX:2 "@gt 20"

Just a side note: you mentioned here you use dnsbl.httpbl.org - do you have an API key for that, as the documentation desrcibes it, right?

"Note : If the RBL used is dnsbl.httpbl.org (Honeypot Project RBL) then the SecHttpBlKey directive must specify the user's registered API key."

[nesretep-anp1]

Sorry, but now I'm totally confused about what do you want to achieve.

That's surprising, because now I am very, very confused. ;)

Well, ... if I'm right, then using the RBL alone results in a blocking each responded (by HTTP:BL) request; which means search engines as well e.g.!

It depends on the rule. @rbl is an operator and it needs an argument. The argument describes what RBL engine you want to use.

All operators (not just the @rbl) return with a TRUE or a FALSE value when checking the target (REQUEST_HEADERS:X-Forwarded-for in your rule). Based on that logical value (TRUE vs FALSE) the rule other parts (a mandatory disruptive action) decides the request will be blocked or not.

Correct. That being said (by you and therefore repeated), the RBL operator (alone) filters IF a DNSBL returns an IP for a built host.

But, ... I do NOT want that!

Well, ...

(The score of HTTP:BL is in Byte 3, not 4).

Sorry, but I don't understand this. What byte you think of it?

... like you could see in the Project Honey Pot docs, there is a score given back for the requested host which represents the threat level of that IP.

So, certainly, I do want to have decisions made based on that score. But, again, as far as I understood in the sources, this score (or even the resulting IP) is NOT consulted in any way.

If sucess (match), then the original IP number is captured.

So, the rule for me looks like ...

SecRule REQUEST_HEADERS:X-Forwarded-For "@rbl dnsbl.httpbl.org." \
   "id:95,\
   chain,\
   phase:1,\
   t:none,\
   capture,\
   deny,\
   msg:'HTTPBL Match of Client IP.',\
   logdata:'%{tx.httpbl_msg}',\
   setvar:tx.httpbl_msg=%{tx.1}"
   SecRule TX:2 "@gt 20"

Just a side note: you mentioned here you use dnsbl.httpbl.org - do you have an API key for that, as the documentation desrcibes it, right?

"Note : If the RBL used is dnsbl.httpbl.org (Honeypot Project RBL) then the SecHttpBlKey directive must specify the user's registered API key."

Yes, right. Otherwise the result would just a complete different one, I think! ;)

[airween]

But, ... I do NOT want that!

Okay, but then it means you need a new operator :).

Well, ...

(The score of HTTP:BL is in Byte 3, not 4).

Sorry, but I don't understand this. What byte you think of it?

... like you could see in the Project Honey Pot docs, there is a score given back for the requested host which represents the threat level of that IP.

So, certainly, I do want to have decisions made based on that score. But, again, as far as I understood in the sources, this score (or even the resulting IP) is NOT consulted in any way.

If sucess (match), then the original IP number is captured.

Ah, now I think I see your idea.

Here is the debug message of the operator with given argument.

And here you can see how the operator adds the IP to the TX collection (if the rule has capture action).

So I can imagine that you send a PR where you add a new feature, if the used BL returns with a score, and if the capture has added, then the received score value will be added to TX:1. What do you think?

[nesretep-anp1]

Nice reply. It's nearly what I submitted in my first message! ;)

No, IMHO TX:1 should be the IP returned. TX:2 will then contain the score, which is out of different bytes depending on the used DNSBL.

In my suggestion I added TX:3 (type) and TX:4 (days) for HTTP:BL, but that is a matter of taste.

Why the score in TX:2 and the IP in TX:1? Because it may come to having to inspect the returned IP itself.

[nesretep-anp1]

No, I am very sorry, but I currently will not send a PR.

[airween]

Nice reply. It's nearly what I submitted in my first message! ;)

yes, now I see - sorry.

No, IMHO TX:1 should be the IP returned. TX:2 will then contain the score, which is out of different bytes depending on the used DNSBL.

In my suggestion I added TX:3 (type) and TX:4 (days) for HTTP:BL, but that is a matter of taste.

Why the score in TX:2 and the IP in TX:1? Because it may come to having to inspect the returned IP itself.

ah, I see. TX:0 holds the given IP, but you need the returned value from BL provider, right?

No, I am very sorry, but I currently will not send a PR.

No worries. But I'm afraid this request does not have any precedence now. And if there will be any other notes from anyone, we can consider that too - eg. if the feature is useful, we should implement that the Apache module (v2/master) too.