mrkbr

For Apache 2.4 the plugin adds bans like this:

<IfModule mod_authz_core.c>
	<RequireAll>
		Require all granted
		Require not env DenyAccess
		Require not ip 111.222.111.222
		Require not ip 222.111.222.111
	</RequireAll>
</IfModule>

If someone wants to password protect a directory this way

AuthType Basic
AuthName "Protected by AuthType Basic"
AuthUserFile /path/to/.htpasswd
Require valid-user

Require vaild-user has to be moved inside <RequireAll></RequireAll>

e.g.

<RequireAll>
	Require all granted
	Require not env DenyAccess
	Require not ip 111.222.111.222
	Require not ip 222.111.222.111
	Require valid-user
</RequireAll>

BUT everytime the plugin updates the bans the protection gets lost.

• This reply was modified 1 year, 11 months ago by mrkbr.
• This reply was modified 1 year, 11 months ago by mrkbr.

Hi Shalom Taiwo,

thank you for another suggestion.
So we are looking for a workaround using the plugin’s IP bans using PHP but not harming by writing to htaccess?
Now that I know how it works and that it could happen at any time that a plugin disables protection I keep Write to Files switched of look for additional protection.

Having such a combination of plugin and setting causing such side effects seems to risky.

I feel there’s a need to prevent this either by the plugin’s way to set it or using general server configuration outside .htaccess.

A number of hosters have this in their user documentation and there are even htaccess generators and hosting tools out there using (only) this way of protection.

The combination of frequently seen recommendations *) to protect directory access this way in combination with the plugin could really lead to TROUBLE in my opinion.

Best regards,
mrkbr

*) https://www.google.com/search?q=%22How+to+Password+Protect+a+Directory%22+htaccess
or
https://www.google.com/search?q=%22How+to+Password+Protect+a+folder%22+htaccess

Hi Shalom Taiwo,

disabling Write to Files seems to fix the problem only when disabled before a ban is added to .htaccess.

This is what I found and what helps (as mostly expected):

• 1) deactivating the plugin (immediately) *)
• 2) removing all (manually) Banned Users
  • 2a) after “flush-files” (runs “once hourly”) *)
  • 2b) immediately after deactivating/reactivating *)

*) But only if Write to Files is active in the plugin’s configuration!

Deactivating Write to Files seems not helpful if a ban is already in .htacces.

Write to Files setting seems valid when deactivating or removing the plugin, too.
Write to Files seems to mean “Change Files” in any way at any time.

After deactivating Write to Files the changes made by the plugin are not removed (as might be expected if the file isn’t touched).
Deactivating the plugin doesn’t help anymore if Write to Files is disabled after a ban was added (as might be expected).

Configure -> Global Settings -> disable Write to Files doesn’t help if a ban is already in .htaccess.

I hope this helps and a more “co-operative” solution can be found to enable Auth Basic and IP Bans.

Best regards,
@mrkbr

By the way:
It looks as if a “itsec_cron_test” event is not being removed after removal of the plugin, too.

• This reply was modified 1 year, 12 months ago by mrkbr.
• This reply was modified 1 year, 12 months ago by mrkbr.

Hi Shalom Taiwo,

in my experience it is as bad as you can imagine.

It seems that it doesn’t matter at which position (before or after) the Auth Basic rules are added. As soon as the ban is added/flushed the intended Auth rules doesn’t do what is expected.
The only way I’m not able to access the “protected” pages any more is to add a ban for my own IP.

I think that the given rules in combination work as one would expect logically but not as intended.

It seems a bit of a nightmare if the intended protection would be important. As soon as one adds/the plugin flushes a ban in this type of setup the doors seem wide open.
And one even doesn’t notice this before the flush happens. :-/

That’s how I found the problem: If you deactivate and reactivate the plugin the ban rules are added immediately.

Best regards,
@mrkbr

• This reply was modified 1 year, 12 months ago by mrkbr.