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 ?
