Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
1  
Don't count on .htaccess to restrict access to your files based on ip, this can be easily bypassed. –  Pedro Lobito Aug 24 '11 at 3:51
    
Can you elaborate on that tuga? –  Hrvoje Špoljar Aug 28 '11 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 '11 at 9:52

2 Answers 2

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? :-)

share|improve this answer
    
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. –  Hrvoje Špoljar Jul 7 '11 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 '11 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. –  Hrvoje Špoljar Jul 7 '11 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 '11 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 –  Hrvoje Špoljar Jul 8 '11 at 0:37
  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).
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.