Support

We have a few people who are trying to go to the main site and getting a 403 error.

The users are using iOS devices (iphone and ipad).

And their devices are not being assigned a IPv4 number (only IPv6).

I'm seeing no records in AdminTools logs for any connections via IPv6 at all. And no records indicating a 403 error.(And the "Do no log these reasons" setting is blank)

Is there a special setting that needs to be configured to allow IPv6-only clients to properly access the site when Admin Tools is enabled?

It's just strange that I see no IPv6 addresses anywhere in the akeeba admin logs, even though I know that at least this one user is connecting via IPv6 only and is getting errors.

I do know that they are manually typing in the web domain address in the address bar and being taken to the main page where they get the 403 error.

They are getting the error that we set-up in the WAF configuration Customisation "Custom messsage" area, with web site template applied.

I did get it working for this user by changing the "Enable IP workarounds" from YES (that was set by default) to AUTO

So the specific issue at hand is resolved; however, I'm still wondering ...

1. Why the Enable IP workarounds-Yes broke the site for anyone conecting via IPv6 only. (Do we need to change this for ALL our sites to make sure this doesn't happen anywhere else?)

2. Why did Akeeba Admin Tools not show any problem in any of the WAF listings or logs?

We've had no additional problems with this since changing the IP workarounds from YES to AUTO; however, we just started getting more reports of problems.

This time I just disabled Akeeba Admin tools (by renaming the plugin file) and everything worked fine.

I have done some digging and I've seen some reports of problems with certain configurations of servers using Plesk (which we are using) having issues with IPv6 routing. I'm checking on that.

However, I'm still not sure why the 403 error would be thrown when Akeeba Admin is enabled, but not when it isn't.

403 is an access/permission error. Why would that sort of thing change when Akeeba Admin is enabled?

Thanks for the pointer to the log file.

I've been able to find one of the instances of the problem.

The log file shows:

Error IP.ADDRESS 403 GET / HTTP/1.0 Apache SSL/TLS access

(that one is there once by itself, then again a couple seconds later followed by:)

Error  IP.ADDRESS  403   GET /autumn-womens-study HTTP/1.0   Apache SSL/TLS access

(autum-womens-study is a link that is public and goes to a page on our site)

Again, these users are only getting the 403 when Akeeba Admin Tools is enabled. As soon as I disable it, they don't get the 403 error.

Also, this appears to only be happening with several different users that happen to be using iOS mobile devices.

Any idea what setting in Akeeba Admin Tools might be causing this?

Or what 'problem' that Admin tools is seeing that we might need to fix?

OK ... I was now able to track this down to what I believe is the actually 'issue' triggering the problem.

We are receiving 404 shields from the blocked IP address.

The Target URL in the 404  entries on the Blocked Request Log in Akeeba indicate that the user's 'location' (i.e. IP address) tried to access the URL of a certain mp3 file multiple times within a short time period (within 1 minute). The url is ... <domain>/wp-content/.... etc. - which is obviously referencing links to the old WordPress version of the web site.

Although the user insists that they didn't attempt to access that file (esp. multiple times in 1-2 minutes), I realized that these mp3 files were associated with our podcast on Apple Podcasts. And it is likely their podcast player trying to connect and download that old podcast episode with the wrong (old WordPress) URL.

Although it would make sense to just go into the podcast an make changes to the URLs there. This apple podcast account has been inaccessible for several months (i.e. we can't log-in to change details because the person that had access died a couple months ago and we have no way to recover the Apple account login). [We have a new podcast feed on a different provider now]

I've been able to address this specific issue by adding some htaccess redirect/rewrite rules.

So the triggering action specific to this (the mp3 files) won't happen again.

However, we are still getting lots of 404 errors with people trying to access other /wp-conent/ URLs, and getting flagged in as a 404 Shield error.

I have 2 questions related to Akeeba Admin Tools:

1. Why is someone hitting the site with bad URLs (generating 404 errors) getting flagged with a 403 error? and seeing the Custom message from Akeeba Admin Tools (from the Customsation tab) after they try to access that same non-working URL?

Do we have something set-up wrong in Akeeba Admin Tools? We have it set-up just like all our other sites and never have this sort of problem on theirs, although none of the other sites we manage were previously a WordPress site with lots of old WP links that are now dead.

2. If I create a redirect within Joomla's core redirect component, would that prevent them being flagged as a 404 error? Does the core redirect get triggered before or after Akeeba Admin Tools?

Thanks for any further clarification you can provide so that we can resolve this issue and stop getting users blocked with 403 errors.

OK ... after doing some more looking, I think I found the problem.

In the Configure WAF / Cloaking Tab / 404 Shield area "wp-content/*" is listed.

I'm guessing that is what has been causing this issue.

Not sure why that is there (along with "wp-admin" and "wp-login" - which we do want to treat as a security issue - because the WP site was getting pelted with hacking attempts).

I've removed wp-content from that list and hopefully that will resolve the issue.

(The only problem with a complex extension like Akeeba Admin Tools is that it has so many useful settings - but if you're not careful you can accidently cause problems with one minor slip-up. But I'd rather have the features of admin tools with this potential as it makes it a great tool to work with. And always requires learning new things :-) )

Let me know if you think that should resolve the issue.

(I'll be monitoring for any more problems)

Well, that did solve the issue.

AND learned about that feature. A VERY handy feature - if used wisely :-)

Thanks again for the great support and great security tool.