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