404 Detection – Reoccurrence Blacklisted IPs

Hi,

IP address 93.174.93.71 has been blacklisted a couple of days ago but that address is still showing up in my event logs as of today. It seems like this IP address is still trying to continue to access an attempted URL that’s forbidden even though it’s blacklisted

Is your server running Apache and if that is the case can you verify that this IP address does indeed appear in your .htaccess file? If the answer is yes to both questions I recommend that you ask your host support people why those apache directives are not working. Maybe you can try a test by adding one of your personal IP addresses in the Blacklist feature and see if you get blocked. (Just make sure you have ftp or cpanel access so you can edit the .htaccess access file to unblock yourself if required)

Also I know they can easily be confused but the “Permanent Block List” is not the same as the “Black List”.
The former, blocks IP addresses at the PHP level and the latter uses Apache directives in the .htaccess file.
I will try and make that clearer by adding some more info in a future release.
I will also try and add the “Permanent Block List” as one of the available blocking methods in the 404 table list.

Hey wpsolutions,

I am running Apache 2.4.18 and I can see the IP address in my .htaccess file with the syntax “deny from”…

I tried banning my own address but I get an error message: “You cannot ban your own IP address”.

Thank you for the clarification. I look forward to your next release.

I will check with my host provider, but would you happen to know which apache directives I need to add for this feature to work?

The blacklist feature automatically adds rules which will work for older apache versions (< 2.4) and also >2.4.

Hey wpsolutions,

I see. Do you know if I need to modify my apache.conf virtual hosts file? My presumption is once an IP address is blacklisted, I shouldn’t see that same address pop up in my event log, correct? Any IP address that appears in the event log are only the ones which I haven’t blacklisted, correct?

Also, I am not sure if it’s normal to have a “blank” Locked Status column when the event log is exported via cvs.

I strongly believe my Apache directives are set up properly. I just don’t know if I need to tweak Apache to make this recurrence vanish.

Thanks for your help as always!

Hi again Joe,
Actually what might be happening is that one of the other rules could be overriding the blacklist rules.
Can you please try a simple test – disable the 6G and 5G if they are active and let me know if you still see the same blocked IP addresses getting through.

I might need to add some special checks when people are activating multiple rules/features for .htaccess.

• This reply was modified 7 years, 3 months ago by wpsolutions.

Hey wpsolutions,

I also just noticed something really bizarre. Certain IP addresses, like 163.172.153.12, are being “temporarily blocked” not blacklisted without my approval. I didn’t even select “temp block IP” from the action dropdown box.

My 404 detection options are as follows:
1. Enable 404 IP Detection and Lockout: Checked
2. Time Length of 404 Lockout (min): 60
3. 404 Lockout Redirect URL: https://127.0.0.1

I will try disabling 6G since that’s the active one.

Hey wpsolutions,

Do you know if more blacklisted IP addresses results into slower performance due to apache having to read more content in the .htaccess file?

Hey wpsolutions,

I think I found what’s causing the issue specifically for the blacklisted IP address 93.174.93.71. When I check my .htaccess file, I see two syntaxes for this address. One says Deny from 93.174.93.71 and the other Require not ip 93.174.93.71. I am not sure why the require not syntax is getting added.

Maybe it’s because when the IP addresses appear on my event log, some are blacklisted while others are not. The order is mixed up as there are gaps. For example, the above IP address was on the 1 of 50 pages on my event log. It was in the middle labeled as blacklisted under the Locked Status column, but there were also other new/non-blacklisted IP addresses on top and on the bottom of that one.

Instead of having to select the new addresses and check the blacklist option, I checked the box on the top to select ALL addresses on that page including the addresses that were previously blacklisted to blacklist everything all at once. I notice I have to perform this action twice, that is check the box to select everything, click blacklist, click the popup OK box. These same steps are repeated a second time, otherwise, only a few addresses are blacklisted not the entire list of fresh ones.

I think what I will do is delete all the blacklist addresses and start fresh. I will blacklist one address and monitor the .htaccess file to see what gets logged.

I will report my findings.

Thanks again!

Hey wpsolutions,

Sorry for the large influx of messages. I just blacklisted a new IP address 62.210.105.116 and noticed in my .htaccess file that same address appears twice like the other one in two places: deny from 62.210.105.116 and require not ip 62.210.105.116. All the other previously blacklisted IP address also have the require not ip syntax.

All and in all, my blacklisted IP addresses are showing up in two sections of the .htaccess file while I think they should only show up under one, which is the deny from.

The require not ip syntax gets added under the section <IfModule mod_authz_core.c> in the .htaccess file for your info.

Hopefully this analysis sheds some light on the culprit.

Hey wpsolutions,

I tried disabling 6G and deleted the IP addresses with the require not ip syntax in my .htaccess file.

No luck. I still see the same IP addresses being recycled in the event log history like 179.43.146.230 even though I deleted the require not ip syntax for this particular address.

Argghh!! Hope we can find a resolution. This is so irritating.

same address appears twice like the other one in two places:

That’s how it is supposed to be – don’t worry about it. One is for older apache versions and the other is for 2.4+. The code has an if statement and uses the relevant one for your server.

Try a test where only the blacklist rules are in your .htaccess file to see if they work then.

Hope we can find a resolution

I recommend you talk to your host tech support about this.
I know that these rules are written correctly and many people including me have tested them and they work. For instance just now I tried blocking the IP from my mobile device and it blocks successfully even with 6G and other rules enabled. Your issue is specific to your setup and your host guys are the best people to solve it.

I had the same problem. My Black list was being overridden and ignored. I needed to turn off the 6G Ruleset to fix this.

This is the offending line in the 6G Ruleset. https://perishablepress.com/6g/

# Apache >= 2.3
<IfModule mod_authz_core.c>
<RequireAll>
Require all Granted <== THIS OVER RIDES YOUR BLACK LIST REMOVE IT
Require not env bad_bot
</RequireAll>
</IfModule>

Hey Wasca,

Just want to thank you from the bottom of my heart. You’re an absolute life saver.

I went ahead and disabled the 6G ruleset and I don’t see any previous blacklisted IP addresess; only new IP addresses are appearing

Quick question. Would it be better from a security standpoint to enable 6g and disable 404 detection?

Much love and thanks brother!

God bless you!

Hi @rebornhairppp, if I had to choose between 6G rule set and 404 Detection I would chose 6G rule set. This provides a lot of protection to a site.

You could also try to add 6G rule set via custom rules and remove the code that @wasca mentioned above. I believe this would work.

Let me know if it works for you if you decide to try my suggestion above.

Kind regards

• This reply was modified 7 years, 1 month ago by mbrsolution.

@rebornhairppp I simply turned off the 6G option in the config, then copied the 6G Ruleset from https://perishablepress.com/6g/ removed the offending line and then added the Ruleset to the custom rules section.

The 6G set is great but can go a little overboard in some areas and interfere in others.

Glad I could help.