dovecot - Mar 2012 - Proxying Authentication on both sides

I've recently set up a director proxy environment on my test servers, with 
the intention of deploying on our cluster soon.

One thing I found confusing in the proxying documentation [1] was the 
first bit about their being two ways to do the authentication...either you 
have the proxy forward the auth to the real server for authentication, or 
you have the proxy authenticate it and then login to the real server with 
a master password.

Well, we use /bin/checkpassword authentication which hooks into a variety 
of subsytems for various specific customer needs, and sometimes we need to 
know the username AND password of the user in order to determine their 
home directory information. So, using a master password (which requires 
the back-end server not getting the user password) is out.

However, when we have the front-end server do a static director proxy, the 
problem is that authentication failures are logged on the back-end server 
with a source IP of the proxy, and no authentication failure with the 
client IP address is logged on the proxy. So, fail2ban (which is a MUST 
these days, at least for us) will not be able to properly filter out the 
brute force attackers.


My solution was an alternative: I authenticate with our /bin/checkpassword 
on the proxy, which authenticates the user and only at that point returns 
the proxy=y nopassword=y switch to proxy the connection and forward the 
authentication.

As a result, we get logs on the proxy for failed attempts, and the full 
username and password is supplied to the back-end server for proper 
processing.

Food for thought in case anybody else is implementing this.

Thanks,
Andy


[1] http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

On 30.3.2012, at 16.25, Andy Dills wrote:
> However, when we have the front-end server do a static director proxy, the 
> problem is that authentication failures are logged on the back-end server 
> with a source IP of the proxy, and no authentication failure with the 
> client IP address is logged on the proxy. So, fail2ban (which is a MUST 
> these days, at least for us) will not be able to properly filter out the 
> brute force attackers.
This is a simple fix (and something you should do anyway): Add the proxy's
IP/netmask to login_trusted_networks setting in the remote server. For this to
work with POP3 you need v2.1.2+.
> My solution was an alternative: I authenticate with our /bin/checkpassword 
> on the proxy, which authenticates the user and only at that point returns 
> the proxy=y nopassword=y switch to proxy the connection and forward the 
> authentication.
Hm. Doesn't it do that even without nopassword=y?