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: | Tying sessions to IP address - some real world data |
|---|---|
| Date: | Wed, 15 Sep 2004 11:36:21 +0100 |
Hi,
This issue has come up here several times. I thought I would use my personal website to harvest some data. I enabled Apache's mod_usertrack, default configuration which allocates a "browser window lifetime" cookie for every request that does not have a cookie. I update my logs to include this cookie, and also the X-Forwarded-For header.
I plan to leave this running for a few weeks and write up the results properly. However, here's some early indications. They're just rough as I'm still working on the processing. Of 840 unique IP addresses, about 15 were observed changing IP address - and not just AOL users, various ISPs. Sometimes this appeared to be a user changing IP address - i.e. some pages are requested with one IP address. Then there's a gap. Then another (nearby) IP address requests some pages with the same cookie. But there are definite logged examples of load balanced proxies. When this happens, requests come from a whole bunch of IP addresses - usually 8 or so. They have always been in a 'close' range. Here's a couple of examples:
Host 26.47.138.212.in-addr.arpa not found: 3(NXDOMAIN) cache1-2.ruh.isu.net.sa has address 212.138.47.11 cache10-4.ruh.isu.net.sa has address 212.138.47.20 cache13-4.ruh.isu.net.sa has address 212.138.47.21 cache2-2.ruh.isu.net.sa has address 212.138.47.12 cache3-2.ruh.isu.net.sa has address 212.138.47.13 cache7-4.ruh.isu.net.sa has address 212.138.47.17 cache9-4.ruh.isu.net.sa has address 212.138.47.29
cache-dtc-aa06.proxy.aol.com has address 205.188.116.10 cache-dtc-aa07.proxy.aol.com has address 205.188.116.11 cache-dtc-aa08.proxy.aol.com has address 205.188.116.12 cache-dtc-aa14.proxy.aol.com has address 205.188.116.18 cache-dtc-ab01.proxy.aol.com has address 205.188.116.65 cache-dtc-ac04.proxy.aol.com has address 205.188.116.133 cache-dtc-ac05.proxy.aol.com has address 205.188.116.134 cache-dtc-ad02.proxy.aol.com has address 205.188.116.196 cache-dtc-ad11.proxy.aol.com has address 205.188.116.205 cache-dtc-ad15.proxy.aol.com has address 205.188.116.209 cache-dtc-ae10.proxy.aol.com has address 205.188.117.14 cache-dtc-ae11.proxy.aol.com has address 205.188.117.15 cache-dtc-ae19.proxy.aol.com has address 205.188.117.23
Other results... about 15% of requests included an X-Forwarded-For header; many of these reveal private IP addresses. Something that has suprised me is a low proportion of clients appears to accept cookies - 460, just over 50%.
So, what does this mean for tying sessions to IP addresses? Well, for a start it confirms that the practice will cause trouble, for about 2% of users. One suggestion was to tie the session not to the IP address, but to the class C network. The AOL results show that this is not sufficient - even looser coupling would be required. Another suggestion was to allow the user to re-authenticate with each IP address, adding them to the "allowed pool". With the AOL request coming from 13 different proxies, this will not work well.
However, there may be a glimmer of hope... Some websites have an option at login time "restrict IP address - more secure" vs "don't restrict IP address - works with all ISPs". I would generally be against this, because I don't think most users are able to make the choice. However... the logs show that it would be possible to autodetect whether the user's IP will change, before they login. The real question of course is how reliable that would be. If it's 90% reliable, then that will reduce 2% of users having problems down to 0.2% - a much more acceptable figure.
I'll be in touch again when I have more data.
Paul
-- Paul Johnston Internet Security Specialist Westpoint Limited Albion Wharf, 19 Albion Street, Manchester, M1 5LN England Tel: +44 (0)161 237 1028 Fax: +44 (0)161 237 1031 email: paul@westpoint.ltd.uk web: www.westpoint.ltd.uk
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Web PT, Kishor Sonawane |
|---|---|
| Next by Date: | RSA vs. Versigin. How do I choose?, GUY MONTGOMERY |
| Previous by Thread: | HacMeBank - help lesson 1c, Marc Davison |
| Next by Thread: | Re: Tying sessions to IP address - some real world data, Andrew Sledge |
| Indexes: | [Date] [Thread] [Top] [All Lists] |