Apache Forbidden
domain.com/highlightsicon.png --> Not working
You don't have permission to access /highlightsicon.png on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
[authz_core:error] [pid 92587] [client 179.43.176.2:14178] AH01630: client denied by server configuration: /home/username/public_html/domain.com/highlightsicon.png
Same file difrent name
domain.com/highligsicon.png --> working ..
where is a problem?
This .png working yeastarday this problem happen today..
-
please verify the rwx permissions of domain.com/highlightsicon.png 0 -
You maybe blocking direct access to files in the site's .htaccess file. Look for something similar to the following. RewriteRule \.(gif|jpg|png)$ - [F]
If you see this try commenting out this line and try accessing the file.0 -
Hi Goran, ran into the same issue. Last cpanel update contains an error. - Removed - # # Require all denied # 0 -
Confirmed, this is a real problem, they made a mistake since last update. line 95 on httpd.conf Require all denied .ht[access TYPO? should be .htaccess without the [. Cpanel please fix it. 0 -
Last cpanel update contains an error.
Got any more details on this you can share?0 -
Hi Goran, ran into the same issue. Last cpanel update contains an error. - Removed - # # Require all denied #
Thank you problem solver! Require all denied0 -
@BDuenk: Thanks! Also received several trouble tickets from customers today on a normally regular day regarding "forbidden errors". This solved the problem. For others seeking the solution. The file is located at /usr/local/apache/conf Restarted httpd afterwards. Regards. 0 -
Ran into this too today. [deleted] 0 -
Client store down all day because of this, totally killed the store. Thank you for the fix, sad that this bug got pushed to a production server! I do not understand how such a critical problem could get pushed out on the release branch 0 -
In - ea-apache24-2.4.25-5.5.1.cpanel this section appears to be: Require all denied In - ea-apache24-2.4.25-7.7.1.cpanel this was (incorrectly) set to: Require all denied 0 -
To fix: cp -a /var/cpanel/templates/apache2_4/ea4_main.default /var/cpanel/templates/apache2_4/ea4_main.local Edit /var/cpanel/templates/apache2_4/ea4_main.local Replace the section that says: Require all denied With: Require all denied Save /var/cpanel/templates/apache2_4/ea4_main.local Rebuild httpd.conf /scripts/rebuildhttpdconf And restart Apache /scripts/restartsrv_httpd It's a shame that this made it into production. If cPanel fixes this you will want to remove the local changes and rebuild httpd.conf and restart again. 0 -
To be clear for anyone trying to pull that regex apart, I could rewrite that as a couple of matches (if I understand it correctly): That regex decomposes to something like "if the file matches the following patterns": [LIST] - ".ht[acdespw|]"
- ".user.ini"
- "php.ini" Note, the periods in the previous patterns match any single non-space character too. sparek-3's fix should work just fine, although you can add the .user.ini and php.ini protections back in by instead putting the following into ea4_main.local, and doing the same. Require all denied Require all denied Require all denied
0 -
I would suggest using Jack's method. The original deny of .ht* helps secure backups like .htaccess.bak etc. as well. I really hope that stays in place, though I suppose a modsec rule could replace it if it gets removed. 0 -
$ grep -E ".ht[acdespw]" /usr/share/dict/words | wc -l 995 0 -
Require all denied is the old behavior as seen in ea-apache24-2.4.25-5.5.1.cpanel What cPanel probably wanted to do was: Require all denied but instead got too fancy with the regex matching and didn't test it. 0 -
Well, use the best of both worlds Require all denied Require all denied cPanel probably wanted to block access to .user.ini and php.ini files, that's why they added this. They just didn't do it right. 0 -
Well, use the best of both worlds Require all denied Require all denied cPanel probably wanted to block access to .user.ini and php.ini files, that's why they added this. They just didn't do it right.
Do note, that would still match files named auserwini or phpaini - probably better to just use the separate Files block anyway as you avoid the regex call within the Apache parsing engine once it's loaded into memory. Worth the few bytes to cut down on a few CPU calls for every request.0 -
Ah we encountered this today as well. After a full scope through the stack and hours grepping for strings in files related to "ghte", we narrowed it down to Apache, then stumbled upon this thread as we were going to post one ourselves. Our platform got owned since 3 am because of this, immense repeated downtime. The 403 error triggered a dynamic php page, and although cached, the pure volume of requests destroyed any hope (a pic that was forbidden was in the main menu, so many many times a second). Here is the synopsis: That regex snip is not good. It matches like this: "any single character" + "ht" + "any single char in acdepsw" = denied. Cause: The periods are not escaped, and brackets are used instead of the more precise parenthesis. Its pretty crazy that made it into httpd.conf (think of all the servers who got pwnd by this). Also its incomplete IMO, there should be an extra clause looking for things like .bak? I dunno just an idea. Corrected regex: (\.ht(access|passwds?)|\.user\.ini|php\.ini)
More broad regex (dont trust this unless you know you need it to block backup/default/upgrade files):(\.ht(access|passwds?)|\.user\.ini|php\.ini)\.*(bak(up)?|old|txt|default|rpmnew|\.)*
Below: i did not catch the difference in <> directive, apologies Jack: PS: @Jack Hayhurst - using .ht* means you will block "any single character" + "ht" + "any other characters" in url, which means it would deny "something.html". I would highly suggest not using that regex, especially if you are a NOC. It would immediately forbid all cache/SEO/legacy urls containing ".html" across all accounts.0 -
Hello Everyone! An emergency release to address this issue (as part of internal case EA-6088) is in-process. I'll update this thread once the updated RPMs are published and the /' /var/cpanel/templates/apache2_4/ea4_main.default; /scripts/rebuildhttpdconf; /scripts/restartsrv_httpd
Note: This command will need to be ran again if the upcp process runs before the updated RPMs are published. Thank you.0 -
PS: @Jack Hayhurst - using .ht* means you will block "any single character" + "ht" + "any other characters" in url, which means it would deny "something.html". I would highly suggest not using that regex, especially if you are a NOC. It would immediately forbid all cache/SEO/legacy urls containing ".html" across all accounts.
!= . A lot of people find simpler because the regex is confusing, so I went for the simpler path myself. You can totally do this in regex with also (and that's not wrong). Files does a glob-style match against the basename of the file. "somepage.html" will not match as the pattern ".ht*" does not have "somepage" at the start of it. That's also why "somepage.html" was not blocked before. If FilesMatch were used instead leading to regex, and ^ is not specified at the start, it would match as you described. :-)0 -
Hi, I'm syncing out packages now that have the fixed EA4 template. I'll let everyone know when you can yum update to get the fixes. Sorry for all the troubles. We'll be doing a retrospective on this release so we can ensure we're not coming across issues like this again. 0 -
Hello, The fixes for the FilesMatch issue in EA4 have been published to the mirrors. You can yum update to get the fixes. Please let us know if you come across any difficulties. 0 -
@Jack Hayhurst -- My bad!!! I failed to see that <> difference in the haste of this bug. Apologies for confusion. I struck out the PS :) 0
Please sign in to leave a comment.
Comments
23 comments