Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Filtering by client IP address for Web App Sessions |
|---|---|
| Date: | Wed, 23 Feb 2005 20:54:00 -0800 |
On Wed, Feb 23, 2005 at 09:12:50AM -0600, Evans, Arian wrote:
2. Are there many ISPs or large organizations using megaproxies that swap client source IPs across entire classes of netblock (e.g. -like AOL does)?
I know of at least one significant ISP (run by one of the telcos) that runs megaproxies.
I've been telling people for years that you can't filter by source or even last octet netblocks and lately have been wondering if I'm dense and this is a US-centric bias of mine thanks to the ISP behaviors I've had to deal with over the years.
Having spent the last 6 years at various L4-7 companies, I can tell you that you're right. For load balancing this shows up in the form of wanting to do persistence based on client IP. Basically, relying on source IP for any transaction related tracking is risky. Client IP addresses move, load balanced forward proxies can fail causing users to pop out of another proxy server, or (most likely), you end up with a ton of users hitting one server when the other servers sit idle.
From a filtering perspective, it's a great way to reverse DoS a
site doing any kind of source IP based filtering. An attacker needs to only launch an attack (even a trivial one) from behind a significant NAT/proxy server that has a lot of users behind it and if the site bans the IP, it ends up banning a significant number of users. In the US/AOL case, that could be a serious segment of your user population. ACLs based on flood attacks are also bad news -- spoof the source IP of a syn flood to come from the AOL subnet and you can block a few million users in one shot. If you just want to get someone fired without hurting all of the Internet, launch a syn flood from the corporate NAT IPs so the CEO thinks the web site is down. -Steve -- Steve Shah sshah@planetoid.org - http://www.planetoid.org/ Beating code into submission, one OS at a time...
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Doubt in Application Audit, Jeffory Atkinson |
|---|---|
| Next by Date: | What is more secure?, Tomas |
| Previous by Thread: | Re: Filtering by client IP address for Web App Sessions, Paul Johnston |
| Next by Thread: | Re: Filtering by client IP address for Web App Sessions, exon |
| Indexes: | [Date] [Thread] [Top] [All Lists] |