Bug 6800

Summary: Koha authentication should handle proxies better
Product: Koha Reporter: Jared Camins-Esakov <jcamins>
Component: AuthenticationAssignee: Jared Camins-Esakov <jcamins>
Status: CLOSED WONTFIX QA Contact: Bugs List <koha-bugs>
Severity: major    
Priority: P3 CC: chris, dpavlin, paul.poulain, semarie
Version: 3.6   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5511
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: proposed patch
Bug 6800: Handle X-Forwarded-For headers
Bug 6800: Handle X-Forwarded-For headers

Description Jared Camins-Esakov 2011-08-27 14:23:09 UTC
At the moment, Koha's authentication/session feature uses the remote address for its sessions. In situations with load balancers or other proxies, the REMOTE_ADDRESS will be the proxy address rather than the client address. In order to handle proxied clients (or any clients when behind a load balancer), Koha needs to use the X-Forwarded-For header to identify the ultimate client. This problem can be seen by configuring Koha to listen on 127.0.0.1 and setting up a Squid proxy with the following configuration options on the same server:

# BEGIN SQUID CONFIGURATION
# The next two lines must go at the top of the squid configuration file:
http_port ${PUBLIC_IP}:80 accel defaultsite=${YOUR_DOMAIN} vhost
cache_peer 127.0.0.1 parent 80 0 no-query originserver name=myAccel

# The next four lines must go AFTER the line "acl CONNECT method CONNECT
acl our_sites dstdomain .${YOUR_DOMAIN}
http_access allow our_sites
cache_peer_access myAccel allow our_sites
cache_peer_access myAccel deny all
# END SQUID CONFIGURATION

If you view the session log after connecting via ${PUBLIC_IP}:80, you will see an entry for 127.0.0.1. Although X-Forwarded-For can be spoofed, in situations where all clients would have the same immediate REMOTE_ADDRESS (e.g. load balancing, reverse proxy, corporate firewall), using X-Forwarded-For seems the lesser of two evils (if you're running the proxy, you can guarantee that the most recent entry in X-Forwarded-For is accurate).
Comment 1 Jared Camins-Esakov 2011-08-28 15:31:49 UTC Comment hidden (obsolete)
Comment 2 Paul Poulain 2011-09-12 16:07:11 UTC
I think it's not en ENH:
* the current Koha does not work for ppl with a load balancer/proxy/... so even if this patch improves the behaviour, for ppl with such a network, it's a problem and it should be considered as a bug.
* shouldn't we remove the IP checking at all ? For libraries that really need security, https is a better way to go isn't it ?

Anyway, i'm upgrading severity (patch untested yet)
Comment 3 Chris Cormack 2011-12-11 00:06:39 UTC
Jared, if you have time, could you reformat the patch, we no longer need all the other sysprefs just the english one.

(It won't currently apply until that is done)
Comment 4 Jared Camins-Esakov 2011-12-11 00:29:19 UTC Comment hidden (obsolete)
Comment 5 Jared Camins-Esakov 2011-12-11 00:30:05 UTC
Rebased on latest master.
Comment 6 Chris Cormack 2011-12-20 21:56:19 UTC
You can test this with curl also


curl -c cookies.txt -d "userid=username&password=password&koha_login_context=intranet&submit=Login" http://192.168.2.135:8080
curl -b cookies.txt http://192.168.2.135:8080

Still logged in

curl -H 'X-Forwarded-For: blah, blah2' -H 'Client-IP: blah' -b cookies.txt http://192.168.2.135:8080

Still logged in

Change system preference

curl -H 'X-Forwarded-For: blah, blah2' -H 'Client-IP: blah' -b cookies.txt http://192.168.2.135:8080

Not logged

Log in again

curl -c cookies.txt -d "userid=username&password=password&koha_login_context=intranet&submit=Login" http://192.168.2.135:8080

curl -H 'X-Forwarded-For: 192.168.2.135' -b cookies.txt http://192.168.2.135:8080

Still logged in.
Comment 7 Chris Cormack 2011-12-20 21:57:27 UTC
Created attachment 6894 [details] [review]
Bug 6800: Handle X-Forwarded-For headers

Previously Koha always used the remote address for its sessions. This is a
problem where a sizable percentage of sessions are being routed through the
same proxy (for example, in the case of load balancers or reverse proxies,
or even a corporate proxy). This commit adds support for pulling the
client's IP address out of the X-Forwarded-For HTTP header, so that sessions
will be keyed to the client and not the proxy.

Although X-Forwarded-For can be spoofed, in situations where all clients
would have the same immediate REMOTE_ADDRESS (e.g. load balancing, reverse
proxy, corporate firewall), using X-Forwarded-For seems the lesser of two
evils (if you're running the proxy, you can guarantee that the most recent
entry in X-Forwarded-For is accurate, hence the behavior when the syspref is
set to require a routable IP).

=== SYSPREFS ===
This commit adds the syspref HandleXForwardedFor with the following options:
* Always use the address of the machine connecting to Koha as the client IP
    for authenticated sessions. This is appropriate for configurations with
    no reverse proxy or load balancer, and is exactly the same as the
    previous behavior.
* Always use the address of the machine with the web browser as the client
    IP for authenticated sessions. This is appropriate for configurations
    that are contained entirely within a LAN, and therefore non-routable IPs
    can be mapped to specific computers.
* Use the first routable address or the address of the last hop before the
    proxy as the client IP for authenticated sessions. This is appropriate
    for configurations that include a reverse proxy or load balancer exposed
    via the public Internet. Anyone connecting through an additional proxy
    will have their session linked to that proxy's IP.

=== API CHANGES ===
This commit adds the get_clientip method to C4::Auth to handle
identification of the client IP:

  my $clientip = get_clientip($remote_addr, $forwarded_for, $require_routable);

Parses the remote IP address (passed to the function in $remote_addr), the
X-Forwarded-For header (passed to the function in $forwarded_for), and
retrieves the IP address of the client, returning a string representation of
the IP address. If $require_routable is set to "first", this function will
always return the most-distant IP address. If $require_routable is set to
"routable", this function will choose the first routable IP address in the
list of relays, or the address immediately before the closest proxy. If
$require_routable is set to "ignore", this function will always return the
most recent hop (i.e. the remote address). "Ignore" is the default, if
$require_routable is not set.

=== TESTING INSTRUCTIONS ===
The problem with the current configuration in Koha can be seen by
configuring Koha to listen on 127.0.0.1 and setting up a Squid proxy with
the following configuration options on the same server:

 # BEGIN SQUID CONFIGURATION
 # The next two lines must go at the top of the squid configuration file:
http_port ${PUBLIC_IP}:80 accel defaultsite=${YOUR_DOMAIN} vhost
cache_peer 127.0.0.1 parent 80 0 no-query originserver name=myAccel

 #  The next four lines must go AFTER the line "acl CONNECT method CONNECT
acl our_sites dstdomain .${YOUR_DOMAIN}
http_access allow our_sites
cache_peer_access myAccel allow our_sites
cache_peer_access myAccel deny all
 # END SQUID CONFIGURATION

If you view the session log after connecting via ${PUBLIC_IP}:80, you will
see an entry for 127.0.0.1. This is the default behavior after this patch is
applied as well, but by changing the syspref HandleXForwardedFor to "Always
use the address of the originating machine," you can ensure that the IP that
shows up will always be the IP address of the machine with the web browser,
or by setting the syspref to "Use the first routable address or address of
last hop before proxy," you can ensure that the IP will always be either the
first routable address or the address of the system connecting to the
reverse proxy. On a LAN, the difference between those two options can be
tested by daisy-chaining a second squid proxy to the first, and connecting
through that.

In addition to these steps for testing, several tests have been added to
confirm that C4::Auth::get_clientip correctly handles valid input.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Comment 8 Paul Poulain 2012-02-01 21:16:31 UTC
Sorry but patch does not apply anymore:
CONFLICT (content): Merge conflict in C4/Auth.pm
Auto-merging installer/data/mysql/sysprefs.sql
CONFLICT (content): Merge conflict in installer/data/mysql/sysprefs.sql
Auto-merging installer/data/mysql/updatedatabase.pl
CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl
Failed to merge in the changes.

I could deal with updatedatabase & syspref, but prefer to let you do with Auth.pm
Comment 9 Jared Camins-Esakov 2012-02-01 21:32:19 UTC
I am not inclined to spend anymore time on this bug. My system no longer requires the patch, and clearly the issue isn't bothering anyone else. Marking RESOLVED-WONTFIX.
Comment 10 Jared Camins-Esakov 2012-12-03 13:09:57 UTC
A similar patch may be necessary when using nginx+Starman, if you do not want to configure the psgi script to handle the reverse proxy. However, rebasing this patch is left as an exercise for the person who wants Koha to handle the reverse proxy rather than Starman.