httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mohit Anchlia" <>
Subject Re: [users@httpd] Block IP
Date Fri, 06 Jun 2008 16:26:31 GMT
On 6/5/08, André Warnier <> wrote:

> 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", is
>>>>>>>>> there
>>>>>>>>> a
>>>>>>>>> way to get the real IP so that we don't end up blocking
>>>>>>>>> coming
>>>>>>>>> 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
>>>>>>>> and
>>>>>>>> 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
>>>>>>> IPv4
>>>>>>> addresses a long time ago.
>>>>>>> Dragon
>>>>>>> If there is no way to get the real IP address then how would
>>>>>> 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. 
>>>>>> it
>>>>>> 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

As per your suggestion I looked at PerlAccessHandler, how would this
approach be in terms of performance as compared to have "deny from IP", is
it still going to be really bad.
 <Location /URL>
    PerlAccessHandler Example::AccessHandler
I will try running some test also.

View raw message