Support

Admin Tools

#15355 Admin Tools blocking 127.0.0.1

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 nicholas on Monday, 11 March 2013 17:39 CDT

user6022

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 2.5.9
PHP version: 5.3.22
MySQL version: 5.0.96 community
Host: (optional, but it helps us help you)
Admin Tools version: (unknown)

Description of my issue:

After upgrading our server from PHP 5.2.9 to 5.3.22 and subsequently upgrading Admin Tools and Akeeba Backup, we are now getting security alerts from 127.0.0.1 and auto blocking on i think all sites. 

I don't believe any of Admin Tools setting have been changed. The server is a managed VDE and as far as I know no access originates from 127.0.0.1.

Just wondering if this normal?

Thanks

nicholas
Akeeba Staff
Manager

Hello Ral,

I suspect that you have a reverse proxy in front of your site (e.g. NginX configures as a reverse proxy or a Varnish cache) which is not configured to forward the user's real IP address to Apache. As a result all requests appear as coming from 127.0.0.1 (localhost). You need to check your server setup. Admin Tools 2.4.4 and later do support reverse proxies, as long as they pass along the original IP in HTTP headers (X-Forwarded-For, if you're curious) or directly to Apache via environment settings (NginX only).

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user6022

Nicholas,

Thanks for the quick response. I suspect that it is not a reverse proxy as I have had the server for several years and have never been advised of it. Also prior to the upgrade of PHP this was not happening. Also I am still seeing security alerts generated by external IPs.

Also I presume that if this was the case and 127.0.0.1 was getting blocked than that would effectively block all incoming traffic. The websites are certainly available to IPs others than the whitelisted IPs. If interested you can see teasme.com.au.

It appears that Admin Query String is the detected behaviour.

I will raise this issue with the host as well, what/ where are the best logs to provide to the host to review.  Any other advice you might have would be appreciated.

Thanks

Raoul

nicholas
Akeeba Staff
Manager

Is it possible that there is another script running on the same server (not necessarily the same site) which tries to access the admininstrator section of your site? That would explain both the IP and the blocking reason.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user6022

Nicholas

Not sure if it is related but:

At approximately 1206pm on the 9th i recevied 2 emails from www.yourbabycanread.com.au Admin Tools. Saying that someone had tried to login with incorrect details. This happens regularly and is not generally concerning however I recevied these emails in Spanish. This has never happened before.

Both login attemps apparently originated from 60.241.234.98 and tried to login with the Username: brad2512hotmail.com.

Interestingly I have just checked the Security Exceptions Log and Auto IP Block list on several sites and there has not been any blocked activity from 127.0.0.1 since 08/03/13. Most of the target URLs are related to akeeba products. Screenshots attached.

My host has asked:

May I know how does the admin-tools web-application-firewall identifies the suspect behavior ? Can we activate any debugging mode for this firewall? Does it check only with the administrator login link or the exact database query triggered to login to the administrator area?

I ask this because, the database connection string used on your website to connect to the database is:

Host: localhost
Db name:
Db user:
Db password:

Every time a database string is triggered it is through the "localhost" connection. The firewall may be detecting this connection as source of attack.

 

Thanks

nicholas
Akeeba Staff
Manager

A web application firewall bases its actions on the incoming HTTP request. The thing your host said about the database? Completely wrong. I won't even comment on it.

"Admin query string" as the block reason means: Someone tried to access your site's back-end (the /administrator URL). They did so without providing a proper secret URL parameter. As a result Admin Tools blocked them and didn't show the login page.

As for debug log, let me reiterate that Admin Tools' WAF comes with two (2) logs: one in the database (what you see in the component) and the admintools_breaches.log log file which can be found in the log directory of your site (usually "log" or "logs" under your site's root).

Looking at the URLs, they seem to be coming from you while administering your site. In fact, they seem to occur when your session expires. Do you or any other Super Administrator remember "suddenly" being thrown back to the site's front-page and having to re-login to the backend? If this is not the case I'll have to repeat my previous replies on this thread.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

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!