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).
Created attachment 5185 [details] [review] proposed patch 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.
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)
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)
Created attachment 6703 [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.
Rebased on latest master.
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.
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>
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
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.
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.