|Summary:||order allow,deny does not work on IPv6|
|Product:||Apache httpd-2||Reporter:||Vernon Mauery <vernon>|
|Component:||mod_access||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Vernon Mauery 2010-08-10 11:24:18 UTC
I was playing with access control and found that while 'order allow,deny' does work as advertised on http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order for IPv4, it does not work for IPv6. I have in my virtual host config file some lines like: <Location /> order allow,deny allow from 2001:4860::/32 allow from 10.0.0.0/8 allow from 192.168.0.0/16 .... # no deny lines at all, so deny if not allow match </Location> With this, I am able to see that IPv4 addresses not in the list get blocked, but IPv6 addresses not in the list do not get blocked. This is a bug as far as I can tell (or something wrong with the documentation). But it is possible that I am mistaken somehow.
Comment 1 William A. Rowe Jr. 2010-08-23 11:54:12 UTC
Did you mean; allow from [2001:4860::]/32 ? Please recheck that this fails.
Comment 2 Vernon Mauery 2010-08-23 12:21:08 UTC
I figured that the unbracketed notation of IPv6 addresses was okay because on another configuration "deny from 2001:470:80e9:0:227:13ff:fe67:7c63" works just fine. But at your request, I tried adding brackets to the IP address and this is what I get: root@telly:/etc/apache2/sites-available# /etc/init.d/apache2 reload Syntax error on line 40 of /etc/apache2/sites-enabled/000-mauery.org: The specified IP address is invalid. ...fail! Line 40 is: allow from [2001:4860::]/32 As I understand the documentation, "order allow,deny" should default to deny in the case of only "allow from ..." statements. So if all my statements are allows, then it should deny everything else. This seems to work fine on the IPv4 addresses, but not on IPv6.
Comment 3 Stuart Longland 2011-04-02 03:18:08 UTC
The documentation states that brackets should not be included in mod_access specifications, and gives examples in that form. I have tried numerous variations to get allow-by-IPv6 subnets for the best part of a year. It was a problem in older versions of Apache, and continues to be a problem in 2.2.16. I'll try it on a couple of other platforms, and double check, but I know it to be a problem on i686 Linux. I have the following in my Apache configuration: Alias /portage /home/portage <Directory /home/portage> AllowOverride None Options +Indexes -ExecCGI Order deny,allow Deny from all Allow from 127.0.0.0/8 Allow from 192.168.0.0/16 Allow from 10.0.0.0/8 Allow from 2001:388:d000:1100::/56 </Directory> I have tried: * Allow from 2001:0388:d000:1100:0000:0000:0000:0000/56 * Allow from 2000/3 * Allow from :: With and without the IPv4 addresses. They are correct according to the docs and the configuration file parser, they should work, but don't.
Comment 4 Stuart Longland 2011-04-02 03:23:12 UTC
Should have added this the first time. Logs when attempting via IPv6: ==> /var/log/apache2/error_log <== [Sat Apr 02 17:22:45 2011] [error] [client 2001:388:d000:1100:223:32ff:fece:508] client denied by server configuration: /home/portage/ ==> /var/log/apache2/access_log <== 2001:388:d000:1100:223:32ff:fece:508 - - [02/Apr/2011:17:22:45 +1000] "GET /portage/ HTTP/1.1" 403 263 Logs when attempting via IPv4: ==> /var/log/apache2/access_log <== 192.168.64.40 - - [02/Apr/2011:17:21:54 +1000] "GET /portage/ HTTP/1.1" 200 1469
Comment 5 Stefan Fritsch 2011-04-05 17:23:20 UTC
This works for me both with 2.2.9 and with 2.2.17. Maybe there is some interaction with other parts of your configuration. Can you provide a (minimal) complete httpd configuration that exhibits the problem? Which version of apr are you using?
Comment 6 firstname.lastname@example.org 2014-08-07 09:57:26 UTC
I have experienced the same problem with deny statements in .htaccess to block IPv6 addresses with stock Apache 2.2.16 as delivered by Debian. It simply doesn't work. This is may be related what is described here: http://serverfault.com/questions/484239/apache-ipv4-deny-directive-blocks-ipv6-addresses In brief: IPv6 addresses get blocked by bitmasks for IPv4 addresses, since the first bits for IPv4 addresses also match the first bits for certain IPv6 addresses. A test could be to figure out what IPv4 address might have the same bitmask as 2001:4860::/32 and see if that blocks 2001:4860::/32. With an innocent side victim in IPv4 space, of course.
Comment 7 Vernon Mauery 2014-08-08 17:38:26 UTC
Yup. That would totally make sense. Blocking 184.108.40.206/19 (0x2a010000) would also amount to blocking 2a01:4f8:120:8201::2/128 (0x2a0104f8012082010000000000000002) if one failed to check which type of IP address they were looking at. 0x2a010000/19 bitmask = 0xffffe000 0xffffe000.......................0 0x2a0104f8012082010000000000000002 (logical and) 0x2a010000000000000000000000000000 And this gives us the significant network bits of 220.127.116.11/19. Q.E.D. Fix the code to check what kind of IP address the netmasks are specified in and it should work just fine.
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:33 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.