[Dovecot] 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?
On Fri, 30 Mar 2012, Timo Sirainen wrote:
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+.
Well, the problem isn't that my proxies would be banned; the problem is I have no way of seeing the remote IP of the failed authentication so I can ban the people who should be banned.
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?
Perhaps...I was going by the docs which seemed to suggest that nopassword=y was how you get the proxy to forward the users authentication credentials to the back-end server.
I had been trying a lot of different things, and it was only when I realized I needed to not do a static passdb on the proxy, but instead do a full authentication so that the auth failure would be logged on the proxy for fail2ban, that things began to work the way I needed.
It seems obvious in retrospect, but for whatever reason the way the docs were written made me feel like having the full authentication happen on both the proxy and the backend wasn't possible.
Thanks, Andy
Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972
On 30.3.2012, at 17.51, Andy Dills wrote:
On Fri, 30 Mar 2012, Timo Sirainen wrote:
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+.
Well, the problem isn't that my proxies would be banned; the problem is I have no way of seeing the remote IP of the failed authentication so I can ban the people who should be banned.
This is what the setting changes. The remote IP will be seen by the backends.
It seems obvious in retrospect, but for whatever reason the way the docs were written made me feel like having the full authentication happen on both the proxy and the backend wasn't possible.
Oh. This is a pretty common configuration. I guess the docs could be clarified.
participants (2)
-
Andy Dills
-
Timo Sirainen