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.
