Support

Admin Tools

#28079 Local IP unexpectedly banned

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by on Sunday, 06 August 2017 17:17 CDT

PTWD
Suddenly this morning (about 5 hours before I got up) my site started sending me email messages from AdminTools (Pro) about a range of local IP addresses being auto-banned. (10.10.111.x, where x is any number.) I have no idea why, since I hadn't even visited the site (never mind logged in) in almost a week. I disabled main.php so I could login and managed to get it working again, but I'm very concerned about what would cause this to happen.

I had set AdminTools to auto-ban repeat offenders, so I reset that to No. My own IP had been put in the "never block" tab but I discovered today that it has changed since I last entered it, so I corrected that. But even with my correct IP set to "never block," I kept getting blocked (after re-enabling main.php) until I found the list of auto-blocked IPs (all "local" IPs) and removed them. Since then (knock wood, fingers crossed) I'm not being blocked after re-enabling main.php.

The IP workaround setting might be being changed for no apparent reason, or maybe just the setting that will work gets changed. Today I had to set it to No to keep from being blocked, whereas it was set to Yes when I logged in this morning. This setting in AdminTools has always been a bit of a mystery. Until today, the "recommended" setting was always opposite the one it was set to, regardless of what that was. Today suddenly they're in agreement, regardless of what I set it to. In other words, if I set it to No, it will say the recommended setting is No; if I set it to Yes, it says it should be Yes. Before today, it was always the other way around -- if it was set to No, it would recomment Yes, and vice versa.

That said, the recommended setting has always been meaningless anyway -- it's always been trial and error to find the setting that works. Right now the setting it likes is No. However, it was set to Yes when I logged in this morning and I'm pretty sure it would have been set to Yes previously -- I'm assuming this because the development site (where I test changes and then upload them using Kickstart) is currently set to Yes. The live installation (that was locking me out today) would have been the same, the last time I uploaded it after making changes (which was weeks ago).

I'm pretty sure this is not the first time the required IP workaround setting has changed. I've suspected this has been happening occasionally for a long time now. What could cause it to be changed? It's disturbing that the site can be offline if I don't happen to be around when it suddenly starts logging every visitor as a local IP and therefore blocking them all. This is what happened this morning.

I'm really baffled and would like to figure out how to prevent this from happening again. Many thanks in advance.

tampe125
Akeeba Staff
Hello,

the Workaround detection tries its very best to identify your environment, but sometimes it fails since there could be a lot of things getting in the way. If internal IPs are detected (ie 10.x.x.x) you should enable IP workaround, since it means that there's a proxy between your server and the original request.
Honestly this is the first time I see something like this: such info are stored inside the database, this means that someone would have to change it in some way. Maybe someone restored a previous backup?

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

PTWD
Hi Davide,

Thanks for your reply. I'm the only person with access to the site, and as I mentioned, I hadn't logged in for about 5 or 6 days. Although it had been logging all visitors as a local IP for the last 2 days (according to the exceptions log), the only reason I became aware of this was because some of them had become auto-banned. I had to take the auto-ban setting off again, which is unfortunate.

The only other way I can think of for it to have changed is if the webhost had restored an older version of the site, but that seems unlikely. When I logged in the last time, I added a new article and that is still there on the site.

The webhost had told me last year that they'd had reports of Joomla not working well with their server architecture. Is it possible that if something in the server configuration changed, it might cause AdminTools to require a different IP workaround setting?

tampe125
Akeeba Staff
The webhost had told me last year that they'd had reports of Joomla not working well with their server architecture. Is it possible that if something in the server configuration changed, it might cause AdminTools to require a different IP workaround setting?
If they added one or more reverse proxy in front of the "real" servers, you will have to turn on IP workarounds

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!