You are here: Foswiki>Tasks Web>Item1028 (26 Feb 2009, SvenDowideit)Edit Attach

Item1028: Foswiki.org site should disable IP matching as it creates problems for people behind load sharing type firewall proxies.

pencil
Priority: Normal
Current State: Closed
Released In:
Target Release:
Applies To: Web Site
Component:
Branches:
Reported By: StefanPalm
Waiting For:
Last Change By: SvenDowideit
Today I failed twice to open a taks on 'foswiki.org' due to authentification errors.

  • Scenario 1 (connecting through a loadbalanced proxy (195.233.250.6, 195.233.250.7))
    • Login to 'foswiki.org'
    • Entering basic information on 'http://foswiki.org/Tasks/'
    • Being forwarded to LoginPage
    • Entering user credentials
    • Being forwarded to LoginPage
      • lost in an endless loop

  • Scenario 2 ("direct" connection without proxy)
    • Login to 'foswiki.org'
    • Entering basic information on 'http://foswiki.org/Tasks/'
    • Being forwarded to 'http://foswiki.org/bin/edit/Tasks/ItemXXXXXXXXXX'
    • Entering additional information
    • Taks has been opened.

-- StefanPalm

oh neat :/, I'm marking this as urgent, just in case someone clever notices it

-- SvenDowideit - 08 Feb 2009

This situation probably happens because of $Foswiki::cfg{Sessions}{UseIPMatching}: a session cookie is generated for one IP and invalidated when it's given by another IP. Unless all requests to login (GET login, POST to login and GET origurl) come from the same IP, it will not work and the session will be lost the first in the first request from another IP...

Here on foswiki.org, this option seems to be enabled (it is enabled by default).

-- GilmarSantosJr - 09 Feb 2009

Are any reasons to keep that option enabled? To me it's a major PITA to login every other minute...

-- StefanPalm - 10 Feb 2009

the reason it exists and why its on by default is that its a way to reduce the chance of session hijacking. basically, if a server sees 2 IP's claiming to be the same person, its more than likely a hacking attempt.

I would have thought that its pretty weird that you would configure proxies like that, but what do I know smile

-- SvenDowideit

maybe that is why i am also asked to re-login "all the time"? all of guadalajara's megacable customers are NAT'ed through something like 32 IP addresses... frown, sad smile so i would expect to have more collisions, but maybe i'm also being redirected through some sort of load-balancing system, and therefore my IP address changes too?

-- WillNorris - 11 Feb 2009

Actually in a corporate environment, this kind of configuration is quite common. Doesn't have to be a proxy - just a firewall & more than one IP address. Sometimes it's intentional load balancing; others it's just random luck (based on how a firewall router handles NAT when it has more than one public IP address.)

There might be a partial work-around of the form: if the IP address is different, do a reverse DNS lookup. Check the IP addresses associated with the result; if the original IP address is in the same group (e.g. associated with the same host), you've been load-balanced.

This won't work 100% - if each IP has a unique name, we lose.

-- TimotheLitt - 11 Feb 2009

I agree with Timothe - this is quite common for large sites. As a solution on some sites - I believe Oracle metalink is one of them - you can choose within your user profile if "IP-switching" should be allowed for your sessions. Maybe somebody could implement this kind of feature for Foswiki too.

-- StefanPalm - 11 Feb 2009

It's not really a profile parameter; it has to do with what site you are currently connecting from. In my network, one site has multiple static IPs; all the others have a single - dynamic - IP. When I'm connecting - using the same profile - from inside a large corporate network, I'm behind proxy as well as NAT IP switching. Then if one's traveling, one's at the mercy of the hotel...or client...or airport.

So, unless a profile only connects from a single location, profile won't work - and will be misunderstood.

IP matching will work much of the time for dynamic IP addresses (as are used by most residential ISPs) - they change slowly enough not to be very annoying. It will work for static IP, if the client site has just one. It's broken for the case of static IP with multiple addresses. It's also broken in the (less common) case of sites with multiple dynamic IP addresses that load balance.

The bottom line is that it's the client site profile that would need to be marked, not the user profile.

Besides using the "same host, multiple IP" approximation that I mentioned previously, there are a few other tricks one could play. For example, the IP blacklists used for mail filtering could be used as pretty good hints. They blacklist residential/dynamic IPs. So switching there is probably bad. These lists are easy to check - they're a DNS lookup that returns a magic code. Most cable operators obey the RFC that suggests naming conventions for reverse DNS of dynamic IPs. IPs that don't have a reverse DNS entry can be prohibited from switching. IPs switches where reverse DNS gives a different TLD or 2nd level domain are usually (but not always) bad.

So one could have heuristics for this. They can't be perfect. Even maintaining a database of where your users connect from would be a significant effort. The main problem is that it's client and client ISP behavior that's variable - and Foswiki administrators only control the server. Someone would have to have a strong personal interest to make this happen - it's a tricky problem; solving it along any of these lines would require lots ongoing maintenance.

Another thing is to make sure that your webserver is configured for HTTP1.1 persistent connections with a reasonably long timeout; besides performance, a persistent connection will not switch IP addresses. There's a tradeoff for a potential DOS attack.

The only real solution is to disable the IP switching hack, and use real access control. This is one of the reasons why I developed the X.509 authentication plugin. With it, the X.509 certificate is your token; you prove your identity on every connection. SSL is rather useful for this... though not all web browsers support client authentication. (Chrome is the big omission at present.)

Life is hard.

-- TimotheLitt - 11 Feb 2009

The conclusion I draw on this is

  • Foswiki's IP matching works exactly as it says on the "package". No error to fix
  • Foswiki.org may be better off turning the IP matching feature off. It is of little use anyway. And with Foswiki being a public site with public access people do not need to steal an identity to edit a page. They can just register and start writing. So there is no need to be hysterical. The IP matching is a nice feature for a corporate site on the Intranet and gives extra protection. And inside the firewall all IP addresses are unique.

I changed the headline.

-- KennethLavrsen - 12 Feb 2009

done

-- SvenDowideit - 26 Feb 2009

ItemTemplate edit

Summary Foswiki.org site should disable IP matching as it creates problems for people behind load sharing type firewall proxies.
ReportedBy StefanPalm
Codebase
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Web Site
Component
Priority Normal
CurrentState Closed
WaitingFor
Checkins
ReleasedIn
Topic revision: r11 - 26 Feb 2009, SvenDowideit
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy