Unique Issue Related to Admin Tools

[jimhill10]

Here is the scenario. Our sites run Akeeba Admin Tools Pro which blocks script kiddie attacks after a certain number of hits. A hacker tries to run an old tired script against the our home page such as /administrator/?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime + big long rest of the URL. We use a unique login stub in Admin Tools such that anyone attempting to login using the plain /administrator URL is redirected to the home page and the attack is logged. That is how Admin Tools handles anyone trying to visit the /administrator/index.php location but without the secret word url appended (?secret). Around that time we clear the Litespeed cache for all the pages because we made changes that required the flush (either by deleting the cache files in the lscache folder or pressing the button on the new Joomla Litespeed component). Then, the hacker's script kiddie hits the page again x more times and at some point their IP-4 address is blacklisted by Akeeba Admin Tools Pro and a page with an unfriendly message (you have been blocked) along with a 403 error code is presented to that viewer. At this point the blacklisted page is not entered into the Litespeed cache as it was just flushed. But on the next visit THAT page is cached (the one with the ugly 403 error code). Finally, this 403 error coded page is displayed to all users. This will happen regardless of whether we use htacess directives instead of the new plugin as the page being displayed is the front end page under attack during the time the cache is flushed.

A work around is to quit using the admin url slug (/administrator?secret-word) and revert to just administrator and then add a dual authentication method or just htaccess username / password. Problem solved. But I do like the admin url slug method better.

If you have used Admin Tools you will know what I mean. I can demonstrate the behavior on my dev system. I already put the fix in place that I listed above but this will perhaps help some others along the way. It is not easy to figure out.

[WuhuaChen]

Thanks for report, We'll fix that, will not cache 403 page anymore.

[jimhill10]

Here is what Nicholas at Akeeba he told me in response to this issue.

Your caching setup ignore web standards (http status, expires headers, etc.). As a result it's broken and dangerous. The correct solution is to set up your page caching, which sits in front of your web applications (Joomla), to only cache pages with a 200 OK HTTP response code AND either of a. no cache control headers; or b. a valid Expires header which defines a date into the future. This is how all proxies, caches and even browser caches work. Don't cache error replies and don't serve the error text from a cache with an HTTP 200 OK status code, this is just plain broken.
The solution I described works because Admin Tools uses Joomla's error page with an HTTP 403 Forbidden error code when blocking requests. When the access is blocked permanently (any kind of IP blocking, including GeoIP) Admin Tools generates its own page, again with an HTTP 403 Forbidden status response. Basically, we use the W3C standard for signaling that the request won't be served due to permissions error.
Further to that, the Expires header is the standard way for the web application to communicate to caching infrastructure and proxies how long the page should remain in the cache before it's considered stale. Joomla does make use of the Expires header, as long as you set up the System - Cache plugin. Pages which should not be cached, e.g. login pages or pages generated for logged in users, have an Expires header in the far past (the date Joomla! 1.0 was released in 2005). Error pages do not have an Expires header because you MUST NOT cache error pages, of course!

[WuhuaChen]

Thanks, I totally agree with your opinion. because this is an early testing version, the main purpose of this version is to test if this caching mechanism works on Joomla platform. We'll adapter your suggestion and give an official version soon.

[jimhill10]

Thanks. In our case it is easy because on our Joomla sites we do not allow users to log in other than admins. And all admin content is excluded. In the future we will be leveraging the use of the ESI functions for certain areas. Thanks for taking note of this issue as this has plagued us for several months and I know it affects others who are currently using the htaccess directive method on Litespeed Enterprise including many folks who have Joomla sites hosted by Rochen.

[jimhill10]

This can be closed, just take note of what we mentioned. Our production site is using the 1.0 release now, so far, so good, and performance is excellent. Seems to be as good or better than the former htacess directive method.