Cidram: Question: not completely blocked (403) in Wordpress ?

[eurobank]

Hello.

I use CIDRAM with two different scripts. I use this page to check for Security (it belongs to Ninja Firewall company):

https://webscanner.nintechnet.com/

In the first site (not Wordpress) i get immediately a 403 error, since they use some Hetzner IPs that are blocked from CIDRAM.

The second site (Wordpress) i get no 403 and the tests complete with mixed results. BUT i see the block in CIDRAM logs as blocked.

I have no idea what that means. Both sites (scripts) are in the same hosting plans and i use the same prepend in .htaccess.

If anyone knows what it means, i would like to hear it. I mean why a 403 is not issued, Or it is issued and the Security page doesn't understand it for some reason ?

[eurobank]

Fixed. one config of CIDRAM has 200 and not 403 as forbid_on_block.

Sorry guys.

[eurobank]

Actually i was very quick and wrong. All CIDRAM forbid_on_block are 200 (from what i see now in two plans) but for some reason some sites return Forbidden and some not.

[Maikuolan]

Any caching solutions being used at the sites issuing the 200 responses instead of the expected 403 responses?

Also, possibly related (but not confirmed): #126.

[eurobank]

I only use Wordpress WP Supercache. Nothing else, plugin or server cache.

[DanielRuf]

Wordpress WP Supercache

Which could be the cause.
Please try it again after disabling it.
Cache plugins often output static content + statuscode 200.

[eurobank]

@DanielRuf But CIDRAM is BEFORE Wordpress, how a plugin (WP Super Cache) can be involved ?

Isn't everything stopped/blocked AT Cidram ?

[dev-101]

Some plugins can override things directly on the server. Just give a test as Daniel said.

[eurobank]

Ok, let me repack this.

Litespeed server 7.20

1. CIDRAM + Wordpress + WP SuperCache with forbid_on_block=403, no apparent problem, blocked using the above security script page. The scanner returns 403 and stops.

2. CIDRAM + Wordpress + WP SuperCache with forbid_on_block=200, doesn't stop the scanner for some reason.

3. CIDRAM + Wordpress without WP SuperCache with forbid_on_block=200, doesn't stop the scanner for some reason.

4. CIDRAM + Osclass script (hello dev101) with forbid_on_block=200, stops the scanner with 403. Same server, same plan. That is kinda strange since all sites use ONE (same) CIDRAM installation per plan.

[DanielRuf]

2. CIDRAM + Wordpress + WP SuperCache with forbid_on_block=200, doesn't stop the scanner for some reason.

Why should a 200 (= OK) stop it?

[eurobank]

@DanielRuf I could ask the same question to you: Why 200 stops the scanner as i say at #4 ?

So what exactly means forbid_on_block=200 ? Doesn't stop anything ?

Maybe i got all this wrong. I dunno.

[dev-101]

That's just a response header code, not page content.

Check your cPanel and see if LiteSpeed caching is on somewhere, it may work for WordPress site without your knowledge in the background.

[ghost]

forbid_on_block is where you set the server side code (HTTP status code) that CIDRAM will return on a block. These are often referred to as "Apache codes" and are what the server replies to the client during normal usage as well.

They are specified in RFC's and Wikipedia has a good summary of them as well.

CIDRAM allows you to choose from a subset of these, which in turn will make the client (spider, visitor, bot, ...) behave a bit differently depending on your choice.

Normally you would use 403, but there are some cases when you want something else depending on configuration or ideology. _(418 I'm a teapot, anyone?)_

[eurobank]

@Maikuolan So Whatever you put in (200,403,500) in CIDRAM, the block happens. Right ? Or not ?

Because i had 200 from the start and i saw the blocks in the logs and everything.

[DanielRuf]

@Maikuolan So Whatever you put in (200,403,500) in CIDRAM, the block happens. Right ?

Exactly.

[DanielRuf]

https://github.com/CIDRAM/Docs/blob/master/readme.en.md#forbid_on_block

"forbid_on_block"
Which HTTP status message should CIDRAM send when blocking requests?

[eurobank]

Ok. then if whatever CIDRAM returns (200,403,503) the block happens, then how the security scanner is not stopped ? What does it test ? It tests the CIDRAM script ? What happens after a block ? A second request ?

Sorry guys if my questions are a bit ignorant (correct word?) but i'm just a webmaster.

[dev-101]

forbid_on_block option should be named HTTP_RESPONSE_HEADER_code imho, as it is a bit confusing and ambiguous as it is now.

[DanielRuf]

Ok. then if whatever CIDRAM returns (200,403,503) the block happens, then how the security scanner is not stopped ? What does it test ? It tests the CIDRAM script ? What happens after a block ? A second request ?

A scanner does not care about the statuscode normally and just runs all tests to see which are blocked / detected (403) and which not (200). Otherwise it does not make much sense.

[dev-101]

Well, googlebot analyses both code and content, others might ignore content etc.

[Maikuolan]

Sorry guys if my questions are a bit ignorant (correct word?) but i'm just a webmaster.

No problem. :-)

By discussing these things, we can figure it all out together and get to the bottom of what's going on here exactly.

forbid_on_block option should be named HTTP_RESPONSE_HEADER_code imho, as it is a bit confusing and ambiguous as it is now.

Fair call. :-)

The main reason for the current name, is because of how that configuration directive worked back in the early days of CIDRAM, when it was first implemented. Back when it was first implemented, it acted just as a simple on/off switch (true/false), for whether to send a 403 header ("forbidden") when a request is blocked (i.e., should CIDRAM "forbid on block"?), or whether to just leave it be and allow the standard 200 OK header to be sent instead. The various other options (410, 418, 451, 503) were added later, during various stages of development.

I agree though, that something like http_response_header or similar would make more sense as a name, considering how it works at this point. Maybe renaming this configuration directive is something we should earmark for v3.

A scanner does not care about the statuscode normally and just runs all tests to see which are blocked / detected (403) and which not (200). Otherwise it does not make much sense.

Good point.

From the perspective of the security scanner, even if the request is blocked by CIDRAM, the security scanner would probably consider it a successful request, due to the returned status code (200 instead of 403). The security scanner most likely isn't aware of CIDRAM, so won't necessarily know the difference between what your WordPress site should normally look like and what the CIDRAM Access Denied page should look like (i.e., it most likely isn't specifically looking for any indication that the request had been blocked by CIDRAM). So, it makes sense, that if CIDRAM is returning a 200 status code, that the scanner will think that the request has been successful.

[eurobank]

Closing this with a suggestion. The default value for Cidram could better be 403 and not 200.