Apache 2.4 – 403 HTTP Status Code Solution

apache-2.4hostshttp-status-code-403PHPvirtualhost

I'm getting a 403 error message with Apache, in Debian Testing.

Apache version:

# aptitude show apache2 | grep -i version
Version: 2.4.9-1

# ls -la /home/

total 28
drwxr-xr-x  4 root    root     4096 Apr  3 13:19 .
drwxr-xr-x 23 root    root     4096 Apr  4 07:28 ..
drwx------  2 root    root    16384 Apr  3 13:13 lost+found
drwx--x--x 36 username username  4096 Apr  7 13:30 username

# ls -la /home/username/Development/PHP/foo.dev.com/

total 16
drwx--x--x 4 username username 4096 Apr  3 14:35 .
drwx--x--x 6 username username 4096 Apr  3 14:36 ..
drwx--x--x 2 username username 4096 Apr  3 14:35 logs
drwx--x--x 8 username username 4096 Apr  3 14:35 public_html

# cat /etc/apache2/sites-enabled/dev.com.conf
UseCanonicalName Off

<VirtualHost *>
    VirtualDocumentRoot "/home/username/Development/PHP/%0/public_html/"
    <Directory "/home/username/Development/PHP/%0/public_html/">
        Require all granted
    </Directory>
</VirtualHost>

# cat /var/log/apache2/error.log
[Mon Apr 07 14:08:15.069251 2014] [authz_core:error] [pid 8649] [client 127.0.0.1:48578] AH01630: client denied by server configuration: /home/username/Development/PHP/foo.dev.com/public_html/

Firefox, "No proxy for" configuration:
localhost, 127.0.0.1, *.dev.com

# cat /etc/hosts:
hosts        hosts.allow  hosts.deny
root@username:/home# cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   username.mymachine.local    username

# Custom
127.0.0.1   teste.dev.com

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

UPDATE 1:

SELinux does not seems to be installed:

$ aptitude search ~i | grep selinux
i   libselinux1                     - SELinux runtime shared libraries

UPDATE 2:

$ ls -la /home/
total 28
drwxr-xr-x  4 root    root     4096 Apr  3 13:19 .
drwxr-xr-x 23 root    root     4096 Apr  4 07:28 ..
drwx------  2 root    root    16384 Apr  3 13:13 lost+found
drwx--xr-x 38 username username  4096 Apr  9 08:26 username

Best Answer

client denied by server configuration: /home/username/Development/PHP/foo.dev.com/public_html/

This make me think about a similar issue i had :

Ensure that www-data user has the x bit permission set for each folders on the path to /home/username/Development/PHP/foo.dev.com/public_html

Either by making www-data the owner of the folders : chown www-data

Or grant the x bit to others : chmod o+x

EDIT :

Finally i have been able to reproduce. It seems that %0 is not supported in <Directory> directive. I have corrected this adding a * instead :

UseCanonicalName Off
<VirtualHost *>
    VirtualDocumentRoot "/home/username/Development/PHP/%0/public_html/"
    <Directory "/home/username/Development/PHP/*/public_html/">
        Require all granted
    </Directory>
</VirtualHost>

Related Solutions

Subdomains returning HTTP 403 after updating Apache from 2.2 to 2.4

Apache 2.4 handles virtual host directive in a different way that 2.2, review the following link for examples.

http://httpd.apache.org/docs/current/vhosts/examples.html

Basically, change NameVirtualHost *:80 -> Listen 80

So it looks like this:

Listen 80

# This is the "main" server running on 172.20.30.40
ServerName server.example.com
DocumentRoot /www/mainserver

<VirtualHost 172.20.30.50>
    DocumentRoot /www/example1
    ServerName www.example.com

    # Other directives here ...
</VirtualHost>

<VirtualHost 172.20.30.50>
    DocumentRoot /www/example2
    ServerName www.example.org

    # Other directives here ...
</VirtualHost>

You might also want to check the rest of your httpd.conf and vhosts.conf for other deprecations and conflicts. See this link. http://httpd.apache.org/docs/trunk/upgrading.html

You're self answer is partially correct, the order/require change but if you browse that page, you'll see quite a few more. I'd suggest reading through it well and making sure you've tackled everything. Even if you get it working, check and double check, some of the changes might not break apache or even log.. but could cause other issues (security/stability).

Linux – Random 403 Forbidden error (Apache 2.4)

I was having this exact problem, I am not sure if the below reason is what always causes this error(specifically in the described in the question way) but this was the case for me, so I just wanted to share my thoughts.

Debian 7 wheezy (7.7), apache 2.2.2

I was making a feature when the user should change the messages' status as read/unread, while clicking on a "link", when ajax was being sent to server, so, while testing - quickly clicking on that link to see if it works fine(so it wont be 2 concurrent ajax requests) I got this error

Forbidden

You don't have permission to access /messages on this server.

The strange part was that before that there were a few successful ajax requests with normal path including the domain name like http://example.com/messages/changeStatus/11. Which means the code was ok. But, on the other hand if I could just wait a few seconds and try again, it would work fine.

I had mod-security and mod-evasive installed, so after this error I found these last lines from /var/log/apache2/modsec_audit.log file.

--ba0f4035-E--
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /messages/changeStatus/24
on this server.</p>
</body></html>

--ba0f4035-H--
Apache-Error: [file "mod_evasive20.c"] [line 246] [level 3] client denied by server configuration: /home/user_name/www/example/messages, referer: http://example.com/messages
Stopwatch: 1421177262896100 4724 (- - -)
Stopwatch2: 1421177262896100 4724; combined=10, p1=0, p2=0, p3=2, p4=0, p5=7, sr=0, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.6.6 (http://www.modsecurity.org/).
Server: Apache/2.2.22 (Debian) PHP/5.4.36-0+deb7u1 mod_ssl/2.2.27 OpenSSL/1.0.1h

--ba0f4035-Z--

Doing some more search, as I found out the log's error in this article. https://www.atomicorp.com/wiki/index.php/Mod_evasive

so, mod evasive is the reason, because the default params of it are too sensitive, mainly in /etc/apache2/mods-available/mod-evasive.conf file by default I had these options

<ifmodule mod_evasive20.c>
   DOSHashTableSize 3097
   DOSPageCount  2
   DOSSiteCount  50
   DOSPageInterval 1
   DOSSiteInterval  1
   DOSBlockingPeriod  10
   DOSLogDir   /var/log/mod_evasive
   DOSEmailNotify  EMAIL@DOMAIN.com
   DOSWhitelist   127.0.0.1
</ifmodule>

as we learn from the above link

MODEV_DOSPageCount - This is the threshhold for the number of requests for the same page (or URI) per page interval. Once the threshhold for that interval has been exceeded, the IP address of the client will be added to the blocking list.

and

MODEV_DOSPageInterval - The interval for the page count threshhold; defaults to 1 second intervals.

So, according to default options if I would do 2 requests for the same url during 1 second it would show 403 error, and it was smth that happened to me: ASA I increased the number to 20, I was unable already replicate the error message.

on other hand

MODEV_DOSBlockingPeriod The blocking period is the amount of time (in seconds) that a client will be blocked for if they are added to the blocking list. During this time, all subsequent requests from the client will result in a 403 (Forbidden) and the timer being reset (e.g. another 10 seconds). Since the timer is reset for every subsequent request, it is not necessary to have a long blocking period; in the event of a DoS attack, this timer will keep getting reset

so, as we can see, after DOSBlockingPeriod time has passed the ip will be deleted from blacklist; as I am guessing this is the reason, that there are no banned IPs in logs, also that, when clicking F5 after a few seconds it works fine, as the blocked period has passed.

I also tested this with long blocking period and small page count values, mainly setting 1000 and 1 respectively. and After a 2-3 ajax requests it started showing 403 and did not go away after a few seconds.

Hope this will help someone.