On 6/5/08, André Warnier <[EMAIL PROTECTED]> wrote:
>
>
> Mohit Anchlia wrote:
>
>> On 6/5/08, André Warnier <[EMAIL PROTECTED]> wrote:
>>
>>>
>>>
>>> Mohit Anchlia wrote:
>>>
>>> On 6/5/08, André Warnier <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>> Mohit Anchlia wrote:
>>>>>
>>>>> On 6/4/08, Dragon <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> André Warnier wrote:
>>>>>>
>>>>>>> Mohit Anchlia wrote:
>>>>>>>
>>>>>>> 2. Another question I had was sometimes we don't get real physical IP
>>>>>>>
>>>>>>>> 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 people
>>>>>>>>> coming
>>>>>>>>> from
>>>>>>>>> that "router" or "proxy"
>>>>>>>>>
>>>>>>>>> In my opinion, you cannot. The whole point of such routers and
>>>>>>>>> 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,
>>>>>>>> and
>>>>>>>> that's it. Your server never receives the original requester IP
>>>>>>>> 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
>>>>>>> IPv4
>>>>>>> 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
>>>>>> 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 "
>>> a234d-45hjk-dialin-atlanta.cox-t-warner.net" 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 : http://en.wikipedia.org/wiki/DNSBL
>>>
>>
>>
>>
>>
>> Thanks ..it 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 : http://cpan.uwinnipeg.ca/search?query=apache2&mode=dist
> 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
</Location>
I will try running some test also.
