7

I found this in my apache access logs

access.log:555.555.555.555 - - [05/May/2011:12:12:21 -0400] "GET /somedir/ HTTP/1.1" 403 291 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0"
access.log:555.555.555.555 - - [05/May/2011:12:12:29 -0400] "GET /somedir/ HTTP/1.1" 200 7629 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0"

So /somedir/ has .htaccess file which looks like

Order Deny,Allow
Deny from all
Allow from 333.333.333.333
Allow from 444.444.444.444

htaccess was not modified within timeframe (8 seconds between 12:12:21 and 12:12:29

Any ideas how this is possible to hit 403 Forbidden and then 8 sec later 200 OK; I'm puzzled

3
  • 1
    Don't count on .htaccess to restrict access to your files based on ip, this can be easily bypassed. Aug 24, 2011 at 3:51
  • Can you elaborate on that tuga? Aug 28, 2011 at 1:03
  • Is /somedir/ (or its location) reachable through different servers and/or VirtualHosts? Do all of them have the same AllowOverride parameters?
    – codehead
    Sep 19, 2011 at 9:52

2 Answers 2

1

I believe that .htaccess is only checked at tcp session initiation, and with clever manipulation at the packet level it may still be possible to manipulate the frames so that the first frames have a fake IP only while the session is being setup, and the real session then have the real IP which you were trying to block.

This is why we have stateful firewalls -- htaccess is not a replacement for a firewall.

Either that, or your ,htaccess is not checked at all -- have you tested that it work? :-)

6
  • it works for normal requests; and I believe that what I found in logs is some crafted request that was allowed when it should have been blocked. Jul 7, 2011 at 15:57
  • Do you have a firewall in place... there is likely some IP spoofing going on if you believe you have already tested that it works in general.
    – Soren
    Jul 7, 2011 at 16:00
  • well; apache is only listening on single IP on port 80; what would you spoof? HTTP is tcp protocol nothing to spoof here if you want to get the response. Jul 7, 2011 at 16:09
  • tcp session is created through a number syn-ack-control packets before any data starts to flow, there is plenty to hijack and spoof. en.wikipedia.org/wiki/…
    – Soren
    Jul 7, 2011 at 19:00
  • 2
    True data can be sniffed(unless SSL); but altering source IP adress in tcp protocol unless you have control of the routing path will necessarily mean you wont get the response in TCP session meaning you don't get "200 OK" or "403 Forbidden" or any other answer really because you don't establish a tcp connection. You are mixing apples and pears here because ARP is layer 2 os OSI model (en.wikipedia.org/wiki/OSI_model) and TCP is layer 3; so in order to do session hijacking you need to be in local network with source you want to hijack from and IPs mentioned are by no means in same subnet Jul 8, 2011 at 0:37
1
  1. Does your top level config allows you to use .htaccess? Check your AllowOverride http://httpd.apache.org/docs/1.3/mod/core.html#allowoverride directive You should have set it to All or Limit
  2. Check if you don't have any Auth restrictions in your config(s).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .