httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mohit Anchlia" <mohitanch...@gmail.com>
Subject Re: [users@httpd] Block IP
Date Thu, 05 Jun 2008 22:32:19 GMT
On 6/5/08, André Warnier <aw@ice-sa.com> wrote:
>
>
>
> Mohit Anchlia wrote:
>
>> On 6/4/08, Dragon <dragon@crimson-dragon.com> 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 ?

Mime
View raw message