httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] Block IP
Date Fri, 06 Jun 2008 00:18:27 GMT

Mohit Anchlia wrote:
> On 6/5/08, André Warnier <> wrote:
>> Mohit Anchlia wrote:
>>> On 6/5/08, André Warnier <> wrote:
>>>> Mohit Anchlia wrote:
>>>> On 6/4/08, Dragon <> wrote:
>>>>> André Warnier wrote:
>>>>>> Mohit Anchlia wrote:
>>>>>> 2. Another question I had was sometimes we don't get real physical
>>>>>>> of
>>>>>>> the
>>>>>>>> machine but the IP of something that's in between like "router",
>>>>>>>> there
>>>>>>>> a
>>>>>>>> way to get the real IP so that we don't end up blocking people
>>>>>>>> from
>>>>>>>> that "router" or "proxy"
>>>>>>>> In my opinion, you cannot.  The whole point of such routers
>>>>>>>> proxies
>>>>>>> is
>>>>>>> to make the requests look like they are coming from the router/proxy,
>>>>>>> so
>>>>>>> that is the sender IP address you are seeing at your server level,
>>>>>>> that's it.  Your server never receives the original requester
>>>>>>> address.
>>>>>>> ---------------- End original message. ---------------------
>>>>>> There are legitimate reasons for this to be done as well,
>>>>>> indiscriminately
>>>>>> blocking such access is a bad idea as it will affect legitimate users.
>>>>>> NAT
>>>>>> and IP address sharing are among the reasons. This allows an
>>>>>> organization
>>>>>> to
>>>>>> have a router with one public IP address to serve a larger internal
>>>>>> network
>>>>>> with private IP addresses. Without this, we would have run out of
>>>>>> addresses a long time ago.
>>>>>> Dragon
>>>>> If there is no way to get the real IP address then how would router know
>>>>> which machine to direct the response to. It got to have some information
>>>>> in
>>>>> the packet. For eg: If A send to router B and router sends to C then
>>>>> when
>>>>> C
>>>>> responds how would B know that the response is for A.
>>>>> You are perfectly right : the router knows the real IP address.  But
>>>> will not tell you, haha.
>>>> Seriously, this is how it works :
>>>> the original system sends out an "open session" packet, through the
>>>> router,
>>>> to the final destination.
>>>> The router sees this packet, and analyses it.  It extracts the IP address
>>>> and port of the original sender, and keeps it in a table.
>>>> Then it replaces the IP address by it's own, adds some port number, and
>>>> also memorises this new port number in the same table entry.
>>>> Then it sends the modified packet to the external server (yours).
>>>> It knows that the server on the other side is going to respond to this
>>>> same
>>>> IP address and port (the ones of the router).
>>>> When the return packet from the server comes back, the router looks at
>>>> the
>>>> port in it, finds the corresponding entry in it's table, and now it knows
>>>> to
>>>> whom it should send the packet internally.
>>>> And so on.
>>>> So :
>>>> - the router knows everything
>>>> - the internal system thinks it is talking directly to the external
>>>> server
>>>> - the external server (yours) only sees the router IP and port, so it
>>>> thinks that is where the packet comes from.
>>>> That's NAT for you, in a nutshell.
>>>> Yes ?
>>>> ---
>>> Thanks for the great explanation. But, I wonder how do people design app
>>> agains Denial of Service attack. Say Computer A uses Cox/Times warner
>>> (cable) Internet connection and starts attacking B, then how would a
>>> system be configured in a way that not all the users using Times
>>> Warner/Cox
>>> are affected. Should it be granular enough to give IP and source Port in
>>> IP
>>> blocking rules ?
>> I think that is quite a different case.  Not all users of an ISP (like the
>> one you mention I suppose) are "behind" a NAT router that hides their IP
>> address.  Instead, these ISP's have a large pool of public IP addresses
>> which they "own", and they attribute them dynamically to users when they
>> connect (and put the address back in the pool when the user disconnects).
>> If a DOS attack came from a router with a fixed IP address, and everyone
>> would know that this IP address belongs to company xyz, I'm sure that it
>> would not be long before company xyz would be facing a big lawsuit.
>> But in the case of an ISP, with tens of thousands of customers, each one of
>> which gets a different IP address each time he turns on his computer (and
>> anyway once per 24 hours in general), finding out who exactly was "
>>" between 17:45 and 17:53
>> yesterday is a bit more time-consuming.
>> But in that case anyway, you do have a real individual sender IP address
>> when the packet reaches your server, so you can decide to block it.
>> And keep blocking all packets from this address for the next 24 hours.
>> And that's exactly what many servers do.
>> And that is also why sometimes you may turn on your PC at home (getting a
>> brand-new IP address) and find out that you cannot connect to some server
>> because it is rejecting your IP address.  Chances are that you are unlucky
>> enough to have received today the IP address that was used yesterday by
>> someone else who used it to send out 1M emails.
>> But isn't this getting a bit off-topic ?
>> If you want to know more about this, I suggest you Google a bit on
>> "blacklists", "greylists" and "whitelists" for example.
>> or start here :
>  Thanks did go off-track a little bit and but it helps me understand
> what I should expect when doing such a blocking. Thanks for your
> explanation.
> Now coming back on track, out of below 2 approaches which one is better:
> 1. Use "deny from IP" in <LocationMatch>
> 2. Use RewriteCond and call a perl script dynamically. This helps me
> configure IP dynamically without having to stop and start servers everytime
> I change httpd.conf
> Is there any performance impact of using 2 over 1 or any other issues.

There will be a very big difference : in case (1), the IP addresses or 
ranges are pre-processed by Apache at startup time, and the comparison 
will be made by an internal (and fast) Apache module, on the base of 
information in memory.  In case (2), not only are you using a rewrite of 
the URI, but in addition you will be executing a script, which itself is 
going to read an external file.  That is going to be several hundred 
times slower, at least.  Thousands of times slower if you recompile and 
execute the script with perl each time (if not under mod_perl).
Now wether it matters or not in your case, depends on the load of your 
server. If it is doing nothing anyway 90% of the time, it doesn't 
matter.  An Apache restart may or may not be such a big problem either, 
it all depends on your circumstances.

But rather than using a perl script, I would definitely in that case use 
a mod_perl add-on module written as a PerlAccessHandler.  But that's 
another story, and one more for the mod_perl list.
I would bet that there exists already such a mod_perl module by the way.
Have a look here :
or, there is probably an example in the Mod_perl Cookbook

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message