Hello
I habe been desperately trying to get Roundcube to send the correct REMOTE_ADDR of the connecting client to a dovecot IMAP Server which supports remote IP logging by x-originating-ip ID command and login_trusted_networks setting. As google shows, that not only I had this problems, I share the solution and hope one of the developers reading here could submit that small fix:
Here are the changes needed for it to work
rcube_imap.php, define the ident option not only if debugging is enabled, and add x-originating-ip to the array.
if ($this->options['debug']) {
$this->set_debug(true);
} // <= Added
$this->options['ident'] = array(
'name' => 'Roundcube',
'version' => RCUBE_VERSION,
'php' => PHP_VERSION,
'os' => PHP_OS,
'x-originating-ip' => $_SERVER['REMOTE_ADDR'], // <=Added
'command' => $_SERVER['REQUEST_URI'],
);
// }
Now this works as expected and dovecot (including it's post-login script) are getting the IP of the connecting webbrowser and not the one of the webserver, if the webserver's IP is in login_trusted_networks.
Benoit Panizzon
I m p r o W a r e A G -
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 07 CH-4133 Pratteln Fax +41 61 826 93 02 Schweiz Web http://www.imp.ch ______________________________________________________
Very cool feature :)
Would love to see this fixed and added
-- Tom Sommer (via iPhone)
On 06/11/2014, at 16.22, Benoit Panizzon benoit.panizzon@imp.ch wrote:
Hello
I habe been desperately trying to get Roundcube to send the correct REMOTE_ADDR of the connecting client to a dovecot IMAP Server which supports remote IP logging by x-originating-ip ID command and login_trusted_networks setting. As google shows, that not only I had this problems, I share the solution and hope one of the developers reading here could submit that small fix:
Here are the changes needed for it to work
rcube_imap.php, define the ident option not only if debugging is enabled, and add x-originating-ip to the array.
if ($this->options['debug']) { $this->set_debug(true); } // <= Added $this->options['ident'] = array( 'name' => 'Roundcube', 'version' => RCUBE_VERSION, 'php' => PHP_VERSION, 'os' => PHP_OS, 'x-originating-ip' => $_SERVER['REMOTE_ADDR'], // <=Added 'command' => $_SERVER['REQUEST_URI'], );// }
Now this works as expected and dovecot (including it's post-login script) are getting the IP of the connecting webbrowser and not the one of the webserver, if the webserver's IP is in login_trusted_networks.
Benoit Panizzon
I m p r o W a r e A G -
______________________________________________________Zurlindenstrasse 29 Tel +41 61 826 93 07 CH-4133 Pratteln Fax +41 61 826 93 02 Schweiz Web http://www.imp.ch ______________________________________________________ _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
It's very easy to make a plugin out of this, so i went ahead and did it.
https://github.com/corbosman/ident https://github.com/corbosman/ident
I'll make a proper plugin with composer support and everything tomorrow.
Cor
On Thu, Nov 6, 2014 at 4:22 PM, Benoit Panizzon benoit.panizzon@imp.ch wrote:
Hello
I habe been desperately trying to get Roundcube to send the correct REMOTE_ADDR of the connecting client to a dovecot IMAP Server which supports remote IP logging by x-originating-ip ID command and login_trusted_networks setting. As google shows, that not only I had this problems, I share the solution and hope one of the developers reading here could submit that small fix:
Here are the changes needed for it to work
rcube_imap.php, define the ident option not only if debugging is enabled, and add x-originating-ip to the array.
if ($this->options['debug']) { $this->set_debug(true); } // <= Added $this->options['ident'] = array( 'name' => 'Roundcube', 'version' => RCUBE_VERSION, 'php' => PHP_VERSION, 'os' => PHP_OS, 'x-originating-ip' => $_SERVER['REMOTE_ADDR'], // <=Added 'command' => $_SERVER['REQUEST_URI'], );// }
Now this works as expected and dovecot (including it's post-login script) are getting the IP of the connecting webbrowser and not the one of the webserver, if the webserver's IP is in login_trusted_networks.
Pretty good but please be aware that $_SERVER['REMOTE_ADDR'] doesn't reflect the client IP if your webserver is behind a reverse proxy or load balancer. There's rcube_utils::remote_addr() which extracts the real client IP from the headers such intermediate systems add to the request.
Best, Thomas
Am 07.11.2014 um 10:30 schrieb Thomas Bruederli:
Pretty good but please be aware that $_SERVER['REMOTE_ADDR'] doesn't reflect the client IP if your webserver is behind a reverse proxy or load balancer. There's rcube_utils::remote_addr() which extracts the real client IP from the headers such intermediate systems add to the request
in a sane setup it does http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
rcube_utils::remote_addr() is dangerous, the X-Forwarded-For is not trustable and hence "mod_remoteip" or for older Apache versions "mod_rpaf" - the important difference is that:
a) the serveradmin knows the server is behind a proxy b) the serveradmin knows the IP of the proxy c) what remote_addr() does happens transparent d) and it happens in a trustable way
I changed my plugin to use the rcube_utils function, https://github.com/corbosman/ident https://github.com/corbosman/ident
Reindl has a point though, but that should be changed in that function then,
Cor
Am 07.11.2014 um 12:17 schrieb Cor Bosman:
I changed my plugin to use the rcube_utils function, https://github.com/corbosman/ident
Reindl has a point though, but that should be changed in that function then
it can't
the point of "mod_remoteip" is that you never face the phyiscal IP anywhere in the application, not in the logs and not in apache modules like mod_security if they are implemented correctly
if you read the mod_remoteip docs careful you see that this header can list more than one address (two proxys between the user and your own proxy which adds his physical client ID) and hence it is important which is your own trusted one nad god beware you try to handle that inside the application and making mistakes if the result is used for authentication and permissions
that's why you *never* should deal with that inside a webapp and keep the resposibility by the webserver admin
On 07 Nov 2014, at 12:24, Reindl Harald h.reindl@thelounge.net wrote:
Am 07.11.2014 um 12:17 schrieb Cor Bosman:
I changed my plugin to use the rcube_utils function, https://github.com/corbosman/ident
Reindl has a point though, but that should be changed in that function then
it can't
the point of "mod_remoteip" is that you never face the phyiscal IP anywhere in the application, not in the logs and not in apache modules like mod_security if they are implemented correctly
if you read the mod_remoteip docs careful you see that this header can list more than one address (two proxys between the user and your own proxy which adds his physical client ID) and hence it is important which is your own trusted one nad god beware you try to handle that inside the application and making mistakes if the result is used for authentication and permissions
that's why you *never* should deal with that inside a webapp and keep the resposibility by the webserver admin
This plugin's sole purpose is to hint to dovecot what the actual user's ip address was that connected to roundcube, instead of roundcube's own ip address. That hint could then serve you for further investigation.
I dont know what roundcube itself does with that info, but I dont think it does anything 'dangerous' with it,
Cor
Am 07.11.2014 um 12:30 schrieb Cor Bosman:
On 07 Nov 2014, at 12:24, Reindl Harald h.reindl@thelounge.net wrote:
Am 07.11.2014 um 12:17 schrieb Cor Bosman:
I changed my plugin to use the rcube_utils function, https://github.com/corbosman/ident
Reindl has a point though, but that should be changed in that function then
it can't
the point of "mod_remoteip" is that you never face the phyiscal IP anywhere in the application, not in the logs and not in apache modules like mod_security if they are implemented correctly
if you read the mod_remoteip docs careful you see that this header can list more than one address (two proxys between the user and your own proxy which adds his physical client ID) and hence it is important which is your own trusted one nad god beware you try to handle that inside the application and making mistakes if the result is used for authentication and permissions
that's why you *never* should deal with that inside a webapp and keep the resposibility by the webserver admin
This plugin's sole purpose is to hint to dovecot what the actual user's ip address was that connected to roundcube, instead of roundcube's own ip address. That hint could then serve you for further investigation.
I dont know what roundcube itself does with that info, but I dont think it does anything 'dangerous' with it
*but* dovecot may do depending on the configuration because forwarding that information has the simple reason that otherwise you can't enforce ip based access lists for webmail users
finally that means: don't forward untrustable informations to dovecot
doing so breaks until that happens sane and secure configurations and secure in that context means nobody but the server admin knows the big picture of proxies, NAT and access lists and hence is responsible to deal with that - that's why mod_remoteip exists
On 07 Nov 2014, at 12:44, Reindl Harald h.reindl@thelounge.net wrote:
Am 07.11.2014 um 12:30 schrieb Cor Bosman:
On 07 Nov 2014, at 12:24, Reindl Harald h.reindl@thelounge.net wrote:
Am 07.11.2014 um 12:17 schrieb Cor Bosman:
I changed my plugin to use the rcube_utils function, https://github.com/corbosman/ident
Reindl has a point though, but that should be changed in that function then
it can't
the point of "mod_remoteip" is that you never face the phyiscal IP anywhere in the application, not in the logs and not in apache modules like mod_security if they are implemented correctly
if you read the mod_remoteip docs careful you see that this header can list more than one address (two proxys between the user and your own proxy which adds his physical client ID) and hence it is important which is your own trusted one nad god beware you try to handle that inside the application and making mistakes if the result is used for authentication and permissions
that's why you *never* should deal with that inside a webapp and keep the resposibility by the webserver admin
This plugin's sole purpose is to hint to dovecot what the actual user's ip address was that connected to roundcube, instead of roundcube's own ip address. That hint could then serve you for further investigation.
I dont know what roundcube itself does with that info, but I dont think it does anything 'dangerous' with it
*but* dovecot may do depending on the configuration because forwarding that information has the simple reason that otherwise you can't enforce ip based access lists for webmail users
finally that means: don't forward untrustable informations to dovecot
doing so breaks until that happens sane and secure configurations and secure in that context means nobody but the server admin knows the big picture of proxies, NAT and access lists and hence is responsible to deal with that - that's why mod_remoteip exists
Dovecot doesnt. All dovecot does with that information is log the x-forwarded-ip if, and only if, your roundcube server is listed as a host that is allowed to provide that info.
I really fail to see the security implications as long as one realises this info is meant as a hint, not absolute fact. It's still slightly more useful than having the roundcube ip listed in your imap logfile. But YMMV.
Cor
Am 07.11.2014 um 12:51 schrieb Cor Bosman:
On 07 Nov 2014, at 12:44, Reindl Harald h.reindl@thelounge.net wrote:
I dont know what roundcube itself does with that info, but I dont think it does anything 'dangerous' with it
*but* dovecot may do depending on the configuration because forwarding that information has the simple reason that otherwise you can't enforce ip based access lists for webmail users
finally that means: don't forward untrustable informations to dovecot
doing so breaks until that happens sane and secure configurations and secure in that context means nobody but the server admin knows the big picture of proxies, NAT and access lists and hence is responsible to deal with that - that's why mod_remoteip exists
Dovecot doesnt. All dovecot does with that information is log the x-forwarded-ip
and than on the server runs "fail2ban" enforcing blocking based on that log - congratulations
with forwarding untrusted input over roundcube you have opened a easy to use DOS because they only thing an attacker needs to do now is write a script using the header with the IP he wants to lock out and send wrong passwords
if and only if, your roundcube server is listed as a host that is allowed to providethat info.
yes, but the admin of the mailserver expects that his webmail is trustable, by forwarding untrusted input that way that's no longer true and i doubt that many people realize that it may lead in fail2ban become vulernable
I really fail to see the security implications as long as one realises this info is meant as a hint, not absolute fact
don't get me wrong but obviously is not your business and frankly carelessly implented features by not looking at the big picture are the root cause of most if not all security troubles we have to deal all day long
It's still slightly more useful than having the roundcube ip listed in your imap logfile. But YMMV.
AGAIN: that is all fine as long you are using $_SERVER['REMOTE_IP'] but if you start to use untrusted headers and so bypass mod_remoteip you trigger security holes and unexpected and uncontrollable behavior
it is *not* your business inside the web-application deal with proxy-headers
Am 07.11.2014 um 12:51 schrieb Cor Bosman:
On 07 Nov 2014, at 12:44, Reindl Harald h.reindl@thelounge.net wrote:
I dont know what roundcube itself does with that info, but I dont think it does anything 'dangerous' with it
*but* dovecot may do depending on the configuration because forwarding that information has the simple reason that otherwise you can't enforce ip based access lists for webmail users
finally that means: don't forward untrustable informations to dovecot
doing so breaks until that happens sane and secure configurations and secure in that context means nobody but the server admin knows the big picture of proxies, NAT and access lists and hence is responsible to deal with that - that's why mod_remoteip exists
Dovecot doesnt. All dovecot does with that information is log the x-forwarded-ip
and than on the server runs "fail2ban" enforcing blocking based on that log - congratulations
That still doesnt compromise your security, but I see your point. A DOS possibility, even a remote possibiity, is annoying.
I'll revert my plugin back to $_SERVER, and i'll leave it up to rc devs what to do with the rcube_utils function,
Cor
Am 07.11.2014 um 13:08 schrieb Cor Bosman:
Am 07.11.2014 um 12:51 schrieb Cor Bosman:
On 07 Nov 2014, at 12:44, Reindl Harald h.reindl@thelounge.net wrote:
Dovecot doesnt. All dovecot does with that information is log the x-forwarded-ip
and than on the server runs "fail2ban" enforcing blocking based on that log - congratulations
That still doesnt compromise your security, but I see your point. A DOS possibility, even a remote possibiity, is annoying.
if you ever have a security audit on your infrastructure you will see that you get a red flag for *any* known DOS possibility and if the audit was given in order by a customer that means you have 24 hours to fix that issue or shutdown the server - been there or better said we are there every week (currently only for webservers but that may change from one day to the next)
the point is not only the DOS - but that's one example where i needed only to think 5 seconds after "it's just used for logging" - there are people out there with a lot of time thinking how they can abuse IT systems
http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets are you 100% sure that it don't use that information or will not do so in later releases?
the idea behind "mod_remoteip" is that you can *trust* $_SERVER['REMITE_ADDR'] to contain the clients IP behind a proxy and hence Allow from / Deny from in Apache is using also that information hence it is trustable in a correct setup
I'll revert my plugin back to $_SERVER, and i'll leave it up to rc devs what to do with the rcube_utils function
thank you!
http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets are you 100% sure that it don't use that information or will not do so in later releases?
That's not the dovecot option that applies here.
Cor
Am 07.11.2014 um 13:30 schrieb Cor Bosman:
http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets are you 100% sure that it don't use that information or will not do so in later releases?
That's not the dovecot option that applies here
i know that!
but can you assure that the forwarded IP will not be used in a future release (maybe optional) in that context too or in some 3rd party module?
the point is simple: don't forward possible untrusted input if you have a trustable source too because you can't know the implications on other parts of the mail stack
security is a complex topic
did you know that $_SERVER['PHP_SELF'] is vulnerable for XSS until you set "AcceptPathInfo Off" in your Apache config which maybe breaks other applications? i did not until a security audit showed a red flag! http://stackoverflow.com/questions/6080022/php-self-and-xss
Am 07.11.2014 um 12:24 schrieb Reindl Harald:
Am 07.11.2014 um 12:17 schrieb Cor Bosman:
I changed my plugin to use the rcube_utils function, https://github.com/corbosman/ident
Reindl has a point though, but that should be changed in that function then
it can't
the point of "mod_remoteip" is that you never face the phyiscal IP anywhere in the application, not in the logs and not in apache modules like mod_security if they are implemented correctly
if you read the mod_remoteip docs careful you see that this header can list more than one address (two proxys between the user and your own proxy which adds his physical client ID) and hence it is important which is your own trusted one nad god beware you try to handle that inside the application and making mistakes if the result is used for authentication and permissions
that's why you *never* should deal with that inside a webapp and keep the resposibility by the webserver admin
to make that more clear:
- there are different headers for the proxied IP possible
- hence you configure mod_remoteip to the header *your* trusted proxy adds combined with the *phyiscal* ip of *your* proxy
whatever application implements fuzzy logic here is *vulnerable* by definition because it don't know about "mod_remoteip" and my see one of the other headers which can be randomly injected by the client and get completly ignored by "mod_remoteip"
so the only one you face inside the fuzzy logic is by definition untrusted user input
practical example:
- my reverse proxy adds X-Forwarded-For
- my backend server makes the transition with mod_remoteip based on that
- frankly X-Forwarded-For *don't exist* fro that moment that is no assumption, that's *proven* by phpinfo() 10 seconds ago
- the attacker set HTTP_X_REMOTECLIENT_IP or HTTP_CLIENT_IP
- the fuzzy logic looks if one of that *three* headers is present
- X-Forwarded-For is stripped by mod_remoteip
- the application uses HTTP_X_REMOTECLIENT_IP for authnetication
- you made my properly configured proxy + backend server vulnerable
don't do that - *period* *ANY HEADER IS UNTRUSTED USER INPUT*
it took me enough energy to convince mod_security upstream that they need to adopt it for Apache 2.4 because the previous handling for whitelisting IP's and logging was a showstopper for upgrade to Apache 2.4 and so please don't break the now existing sane environments by playing fuzzy logic and *luck* inside web applications
On Fri, Nov 7, 2014 at 10:37 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 07.11.2014 um 10:30 schrieb Thomas Bruederli:
Pretty good but please be aware that $_SERVER['REMOTE_ADDR'] doesn't reflect the client IP if your webserver is behind a reverse proxy or load balancer. There's rcube_utils::remote_addr() which extracts the real client IP from the headers such intermediate systems add to the request
in a sane setup it does http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
rcube_utils::remote_addr() is dangerous, the X-Forwarded-For is not trustable and hence "mod_remoteip" or for older Apache versions "mod_rpaf" - the important difference is that:
You're certainly right about this but if you look at the implementation of remote_addr() you'll find that the X-Forwarded-For header is only considered if the request comes from a known proxy IP which can be set with the 'proxy_whitelist' config option. For those not using mod_remoteip, this should do the job.
However, we should consider $_SERVER['REMOTE_IP'] in remote_addr() if available.
~Thomas
Am 07.11.2014 um 13:12 schrieb Thomas Bruederli:
On Fri, Nov 7, 2014 at 10:37 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 07.11.2014 um 10:30 schrieb Thomas Bruederli:
Pretty good but please be aware that $_SERVER['REMOTE_ADDR'] doesn't reflect the client IP if your webserver is behind a reverse proxy or load balancer. There's rcube_utils::remote_addr() which extracts the real client IP from the headers such intermediate systems add to the request
in a sane setup it does http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
rcube_utils::remote_addr() is dangerous, the X-Forwarded-For is not trustable and hence "mod_remoteip" or for older Apache versions "mod_rpaf" - the important difference is that:
You're certainly right about this but if you look at the implementation of remote_addr() you'll find that the X-Forwarded-For header is only considered if the request comes from a known proxy IP which can be set with the 'proxy_whitelist' config option. For those not using mod_remoteip, this should do the job.
please take a look at the mod_remoteip docs
can you assure that you handle the case where the HTTP header contains more than one IP strict enough and what are you doing if the proxy is using one of the AFAIK 3 possible HTTP headers and one of the remaining are present?
in that case and with "mod_remoteip" you only see the untrusted ones in the PHP layer and have no hint that the real one is already translated
so in a large environment that may lead in somebody fixes the HTTP setup because logging and other issues and configures 'mod_remoteip' and that maybe is not the same person who configured roundcube
also consider if the "mod_remoteip" logic/code turns out to contain a security relevant flow (that was indeed the case not so long ago) and get a fix this is applied to every single web application not dealing with that itself __________________________________
Apache 2.4.8:
- mod_remoteip: Correct the trusted proxy match test. PR 54651
- mod_remoteip: Use the correct IP addresses to populate the proxy_ips field
docs are unchanged, but the implementation had an error
However, we should consider $_SERVER['REMOTE_IP'] in remote_addr() if available
please do so!
-
Benoit Panizzon -
Cor Bosman -
Reindl Harald -
Thomas Bruederli -
Tom Sommer