[Bug 6800] New: Koha authentication should handle proxies better
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Bug #: 6800 Summary: Koha authentication should handle proxies better Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Authentication AssignedTo: jcamins@cpbibliography.com ReportedBy: jcamins@cpbibliography.com QAContact: koha-bugs@lists.koha-community.org CC: dpavlin@rot13.org 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). -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 --- Comment #1 from Jared Camins-Esakov <jcamins@cpbibliography.com> 2011-08-28 15:31:49 UTC --- Created attachment 5185 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5185 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 |PATCH-Sent Status|NEW |ASSIGNED Patch Status|--- |Needs Signoff -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.poulain@biblibre.com See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=5511 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major --- Comment #2 from Paul Poulain <paul.poulain@biblibre.com> 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) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz Patch Status|Needs Signoff |Does not apply --- Comment #3 from Chris Cormack <chris@bigballofwax.co.nz> 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) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5185|0 |1 is obsolete| | --- Comment #4 from Jared Camins-Esakov <jcamins@cpbibliography.com> 2011-12-11 00:29:19 UTC --- Created attachment 6703 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6703 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Does not apply |Needs Signoff --- Comment #5 from Jared Camins-Esakov <jcamins@cpbibliography.com> 2011-12-11 00:30:05 UTC --- Rebased on latest master. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 --- Comment #6 from Chris Cormack <chris@bigballofwax.co.nz> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #6703|0 |1 is obsolete| | --- Comment #7 from Chris Cormack <chris@bigballofwax.co.nz> 2011-12-20 21:57:27 UTC --- Created attachment 6894 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6894 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> -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Needs Signoff |Signed Off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|PATCH-Sent (DO NOT USE) |P3 Status|Signed Off |Patch doesn't apply --- Comment #8 from Paul Poulain <paul.poulain@biblibre.com> 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 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |RESOLVED Resolution| |WONTFIX --- Comment #9 from Jared Camins-Esakov <jcamins@cpbibliography.com> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 --- Comment #10 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org