Support

Can't get any Text Format to work, sorry! I am using Joomla with Admin Tools 7.9.3 and an Apache/ISPConfig hosting environment. I have encountered a reproducible issue with the "Common hacking tools and bandwidth hoggers" / User-Agent blocking rules generated by the .htaccess Maker. ISPConfig configures custom Apache error documents for the website, including: Alias /error/ "/var/www/example.com/web/error/" ErrorDocument 403 /error/403.html ErrorDocument 404 /error/404.html ErrorDocument 500 /error/500.html Admin Tools generates User-Agent blocking rules similar to: RewriteCond %{HTTP_USER_AGENT} Ahrefs [NC,OR] RewriteCond %{HTTP_USER_AGENT} curl [NC,OR] RewriteCond %{HTTP_USER_AGENT} Go-http-client [NC,OR] ... RewriteCond %{HTTP_USER_AGENT} wp2shell [NC] RewriteRule ^ - [F,L] Requests using one of these blocked User-Agents can result in HTTP 500 instead of HTTP 403. Apache logs: AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. The issue is reproducible, for example: GET / HTTP/1.1 User-Agent: AhrefsBot/7.0 → HTTP 500 GET /error/403.html HTTP/1.1 User-Agent: AhrefsBot/7.0 → HTTP 500 The same behaviour occurs with several User-Agents blocked by the generated rules, including: curl/8.6.0 AhrefsBot/7.0 Go-http-client/1.1 PetalBot Bytespider python-requests/2.32.3 Apache subsequently logs AH00124. My assumption is that the following happens: blocked User-Agent → RewriteRule [F,L] → HTTP 403 → Apache ErrorDocument /error/403.html → internal request for /error/403.html → same User-Agent is blocked again → HTTP 403 → ErrorDocument /error/403.html → ... → AH00124 / HTTP 500 I therefore tried to exclude the ISPConfig error pages using: RewriteRule ^error/ - [L] I entered this under: Custom .htaccess rules at the top of the file However, in the generated .htaccess this rule is placed after the "Common hacking tools and bandwidth hoggers" User-Agent block. The resulting order is essentially: RewriteEngine On # PHP Authorization rule ##### Common hacking tools and bandwidth hoggers block -- BEGIN ... RewriteRule ^ - [F,L] ##### Common hacking tools and bandwidth hoggers block -- END RewriteBase / # HTTPS redirect ##### Custom Rules (Top of File) -- BEGIN RewriteRule ^error/ - [L] ##### Custom Rules (Top of File) -- END Consequently, the /error/ exclusion cannot prevent the recursion because the blocked User-Agent has already matched the earlier [F,L] rule. Could you please clarify: 1. Is this interaction between the generated User-Agent blocking rules and Apache ErrorDocument 403 known or expected? 2. What is the recommended way to exclude /error/ from the User-Agent blocking rules generated by Admin Tools? 3. Is there an Admin Tools setting intended for this situation? 4. Should "Custom .htaccess rules at the top of the file" normally be emitted before the "Common hacking tools and bandwidth hoggers" block? 5. Would you recommend disabling the User-Agent blocking feature when Apache/ISPConfig uses URI-based custom ErrorDocuments such as /error/403.html, or is there a preferable solution? I would prefer to solve this through the .htaccess Maker configuration rather than manually editing the generated .htaccess, since manual changes would be lost when the file is regenerated. The problem has been reproduced repeatedly and correlates directly with Apache AH00124 entries. Normal requests from non-blocked User-Agents are unaffected. Thank you.

One additional detail may be relevant: ISPConfig 3.3.2 changed its default behaviour regarding custom error pages. According to the ISPConfig 3.3.2 release notes, "Custom error pages are now disabled by default for newly created websites", while existing websites are not changed by the update. This website is an existing ISPConfig website and therefore still has the traditional ISPConfig configuration: Alias /error/ "/var/www/example.com/web/error/" ErrorDocument 400 /error/400.html ErrorDocument 401 /error/401.html ErrorDocument 403 /error/403.html ErrorDocument 404 /error/404.html ErrorDocument 405 /error/405.html ErrorDocument 500 /error/500.html ErrorDocument 502 /error/502.html ErrorDocument 503 /error/503.html This seems particularly relevant because the recursion I can reproduce starts when an Admin Tools User-Agent blocking rule generates a 403 response and Apache subsequently internally requests /error/403.html. ISPConfig 3.3.2 does not state in its release announcement that the changed default for custom error pages is related to this particular recursion issue, so I do not want to assume that there is a direct connection. However, I thought this change was worth mentioning.

Thank you. I tested your first suggestion. The /var/www/example.com/web/error directory does exist and contains the ISPConfig error documents 400.html, 401.html, 403.html, 404.html, 405.html, 500.html, 502.html and 503.html. The files exist and are readable. I added "error" to "Allow direct access, except .php files, to these directories" and regenerated the .htaccess file. Admin Tools correctly generated the corresponding rules: RewriteCond %{REQUEST_FILENAME} !(.php)$ RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^error/ - [L] However, this rule is generated later in the .htaccess file than the "Common hacking tools and bandwidth hoggers" User-Agent blocking rules. Therefore, the problem remains reproducible. After regenerating the .htaccess file, I tested these two requests: GET / with User-Agent: AhrefsBot/7.0 GET /error/403.html with User-Agent: AhrefsBot/7.0 Both requests still result in Apache logging: AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. The corresponding Apache log entries were generated at 16:53:57 immediately after the two test requests. This seems to confirm that the direct-access exception for /error/ cannot prevent this particular recursion because the User-Agent blocking rule with [F,L] is evaluated before the generated direct-access exception. There are also additional AH00124 entries caused by real external requests, so the behaviour is not limited to my controlled tests. I will now test your second suggestion using "ErrorDocument ... default" in "Custom .htaccess rules at the bottom of the file" and report the result. Your second suggestion using “ErrorDocument ... default” in “Custom .htaccess rules at the bottom of the file” solved the issue. The previously failing requests now correctly return HTTP 403 instead of HTTP 500, and no new AH00124 entries are generated. I also verified that the existing protection rules still work as expected: a request for /.env returns HTTP 404, while a normal request to / returns HTTP 200. So this solution works correctly in my ISPConfig setup. Thank you for your help.