Support

Admin Tools

#16249 possible unclosed apache processes

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 Tuesday, 04 June 2013 09:22 CDT

lcdservices
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? y
Have I searched the tickets before posting? y
Have I read the documentation before posting (which pages?)? y
Joomla! version: 2.5.11
PHP version: 5.3
MySQL version: 5.5
Host: (optional, but it helps us help you)
Admin Tools version: 2.5.5

Description of my issue:
we're using the auto-blocking tool for exceptions, because we were seeing an increased number of brute force login attempts. it has worked well in terms of identifying the exceptions and blocking the IP after repeated attempts.

however -- it appears that when it blocks IPs, or perhaps when it's processing the exception, it may not be closing the apache process correctly. during a few times when we had a large volume of hits, we found apache processes failing to close and would hit our max connection limit (they were getting stuck in CLOSE_WAIT which suggests the application is not closing them properly).

I can't definitively say that it's caused by AdminTools, but it seems that way. the problem arose once we implemented the auto-blocking; and we recently starting limiting access to the admin login via IP and the issue resolved -- suggesting something about the exception tracking and auto blocking was the culprit.

are there any known issues along these lines?

nicholas
Akeeba Staff
Manager
Admin Tools is deliberately adding a waiting period to auto-banned IPs. You can remove it be finding these lines in plugins/system/admintools/admintools/pro.php around line 2342:
		// If we are still here, the user was auto-banned. Waste some of his time and
		// die with a 403 error. We try to waste as much time as possible. This will make
		// most hackbots give up or, at least, they will not waste tons of our server
		// resources trying to hack us.
		if(function_exists('ini_get')) {
			$maxexec = ini_get("max_execution_time");
			$waste = $maxexec - 3;
			if($waste < 0) $waste = 5;
		} else {
			$waste = 5;
		}

and remove them.

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!

lcdservices
ok, great -- I'll try that.

I understand the logic behind that chunk of code. but if you get hit pretty hard by a distributed brute force attacks (via multiple IPs), it can hose the system. for reference, we were blocking after 9 attempts in 1 hr (which I think is on the quick side of things -- i.e. quick to block).

part of the problem with the code above is that it determines the wait time based on the max_execution_time value, which may vary significantly based on the server and site. in our case, that value is probably set higher than many systems (600 sec) because we have some applications running that involve some potentially complex queries that can take some time to complete, and we don't want the app to timeout.

rather than base the wait time on the php config value, maybe you can move it to the admintools config, and just provide a warning that the wait time should not exceed max_execution_time (perhaps retrieve and display the value to make it easier for people to know what the limit should be)

nicholas
Akeeba Staff
Manager
In retrospect, that code is useless and achieves the opposite result. Instead of saving your server resources it depletes them. I will remove it from the next release.

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!

lcdservices
...or even better --
leave the existing code in place, but add a config option that can optional override the calculated value via the interface.

lcdservices
(you replied as I was adding my second follow up)

you're probably right. while there might be value in wasting the attackers time, our chief concern is to maintain the site's stability and security.

nicholas
Akeeba Staff
Manager
Yes, exactly.

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!