Blacklist – blocked IPs accessing!?

Hi Mike,

I’m not sure, but I can think of two possible reasons:

1. If your site is a subdirectory install, black listing will only protect the back-end – this is a known issue.
2. If you have any other rules in your .htaccess file before the blacklisting rules you pasted here, they might prevent the blacklisting rules from being executed.

Cheers,
?eslav

Hi ?eslav,

thanks for your reply.

1. No, it is NOT a subdirectory-install
2. Yes, there are a lot of rules in the .htaccess before the blacklisting rules. But all of them are created by AIOWPSF, by the way…

Is there a posibility to “test” if the blacklisting is even working at all?
Can this be done somehow without having the need to block my own IP or IP-range?

Hi Mike,

Is there a posibility to “test” if the blacklisting is even working at all?

Maybe there’s a service for this somewhere out there, but I always just block my own IP address/range when I want to test .htaccess this way. Of course, it’s better to edit .htaccess file via FTP instead of from within admin interface when performing such test ??

Rules created by AIOWPSF shouldn’t collide with each other.

Do you know what Apache version do you have on server? If it’s 2.3 or newer, maybe check if mod_authz_core module is enabled (you can find this in output of phpinfo for example).

I couldn’t find out the exact Apache version by checking phpinfo(), BUT mod_authz_core IS listed in the “apache2handler” > “Loaded Modules” section.

I will check the functionality by blocking my own IP as soon as I find time for it…

Thanks for now!

OK – I had time for some tests unexpectedly…

Outcome:

• all Order allow,deny – Deny from <IP-address> variants are working
• all Require not ip <IP-address> – Require all granted variants are NOT working
• mod_authz_core is listed in the “Loaded Modules” section of phpinfo()

Any idea?

[EDIT]:
The <IfModule...>-directives seem to fail ^^

• This reply was modified 7 years, 11 months ago by bios4.
• This reply was modified 7 years, 11 months ago by bios4.

This is a bit strange, because mod_authz_core is available only on Apache 2.3+ that requires the new syntax (Require not ip etc.), so the <IfModule> checks should be fine.

Can you check, if you have also mod_access_compat active?

That’s ^^ what I thought, too.

But blocking of my own IP worked only without the <IfModule...> sections, and only with the older syntax of Apache < 2.3.

And yes – mod_access_compat is also listed in the “Loaded Modules” section…

• This reply was modified 7 years, 11 months ago by bios4.

Ok, I run some tests and I believe mod_access_compat is most likely the culprit. It allows you to use old syntax in .htaccess for Apache 2.3+, but reportedly can cause troubles when .htaccess mixes old and new syntax.

As I said, I run some tests on my development machine with mod_access_compat on and I can reproduce your problem only when I enable some other firewall features in addition to blacklist manager. I’m not an expert in this field, so it’s hard for me to say what exact rules are causing this issue.

I’m not sure if adding additional <IfModule mod_access_compat.c> checks makes sense here. For the time being, if you cannot disable mod_access_compat on your webserver, you can use the “Custom Rules” tab and insert the IPs using old syntax. I know it’s not that convenient, but it’s designed for such edge cases.

Cheers,
?eslav

Hi ?eslav,

thanks for investigating this issue!

I can reproduce your problem only when I enable some other firewall features in addition to blacklist manager

This sounds reasonable, as I have almost all other firewall features enabled, too:
– Basic firewall
– XMLRPC (blocking all access)
– Debug file security
– Extended firewall (all features)
– 6G firewall
– Bot security
– Hotlink prevention
– 404

I will ask my hosting provider if there is a specific reason for them to have the mod_access_compat-module enabled or if it can be disabled for my hosting package without any further downsides.

Is there anything you could do on development side to make the plugin properly work also for such configurations?

Is there maybe a chance to find out on code-level which version of Apache is running, and deciding based on the outcome of this check whether to apply the old or the new syntax?

Or would the fact that mod_access_compat is enabled also hinder the .htaccess from working properly even if there is only EITHER/OR of the code available?

Thanks a lot for your efforts!

[EDIT]: by the way – all other features seem to work flawlessly as far as I can say…

• This reply was modified 7 years, 11 months ago by bios4.
• This reply was modified 7 years, 11 months ago by bios4.
• This reply was modified 7 years, 11 months ago by bios4.

?eslav,

I got a response from my hosting provider in the meantime.

They confirmed that a “mixed syntax” for Apache < 2.3 AND Apache 2.3+, as it is written to .htaccess by the plugin currently, does NOT WORK with the mod_access_compat-module enabled!

The module provides the possibility to use EITHER old OR new syntax, but NOT both in one .htaccess file AT THE SAME TIME…

Which leads me to the next issues: knowing that, it is not anymore affecting only the blocking of IPs with the blacklist manager, but also ALL OTHER features where the “either/or”-syntax is used!!!

– WordPress file security (license.txt, readme.txt, wp-config.php)
– .htaccess file security
– 6G firewall (bad_bot)
– XMLRPC-securty

This seems to be quite some impact to me.
Any ideas?

Thanks,
Mike

• This reply was modified 7 years, 11 months ago by bios4.

Hi,

any follow-ups on this?

Hi,

Sorry, X-Mas are coming…

This issue is complex. The assumption here is that most of plugin users don’t know what server they have (not to mention version), so asking them for it makes no sense. Unfortunately, there is no reliable way how to determine this type of information via PHP, so we took <IfModule mod_authz_core.c> approach to support both older and newer Apache servers. This is de-facto standard approach, I think Wordfence and other security plugins (or rulesets like 6G) do exactly the same.

I don’t know if any of them can deal with active mod_access_compat. I can dig this issue further, but – to be honest – it has low priority to me, cause it is of no interest to my employer. I don’t know if any of the other plugin authors wants to pick up this issue (ping to @wpsolutions here).

You can always manually clean up .htaccess file from old directives and disable firewall rules in the plugin (and only use “Custom Rules” tab for black listing). I can’t really offer a better solution for the time being.

• This reply was modified 7 years, 11 months ago by ?eslav Przywara. Reason: grammar

Hi ?eslav,

thanks for your reply.

I was not expecting a fix (soon), especially an “easy one”.
But I wanted to hear back from you and what your options are on that issue.

I see (and did already) that one can clean up the code on .htaccess-level, so I am fine for the time being.

Maybe one of the other developers is interested in diving into that issue, so that (maybe) there can be a fix in any future version.

Thanks for your time and Merry Christmas!

Mike