On Friday 10 May 2013 09:17:28 Steve Campbell wrote:

But I believe fail2ban uses iptables, and I don't run a local firewall on the server. I'd prefer not to use a separate server to inject firewall rules on the border firewall. I might be wrong about fail2ban, though.

I was hoping there was a file for pop and imap in dovecot similar to the smtp "access" file in sendmail (which is what I use, BTW)

Yes, Fail2Ban uses iptables. I don't think there is another way (using Dovecot itself) to block a remote host since Fail2Ban is documented on Dovecot' wiki: http://wiki2.dovecot.org/HowTo/Fail2Ban (it looks like one of the best way to achieve this).

Gilles.

========================================= Gilles CHAUVIN Administrateur systèmes Pôle Systèmes Direction de l'informatique & des systèmes d'information Université de ROUEN Bat.16-IRESE-B-Place Émile Blondel 76821 MONT-SAINT-AIGNAN CÉDEX Accès: http://goo.gl/cYgtX

Tél: 02.35.14.82.92 Fax: 02.35.14.64.64 Accueil DSI: 02.35.14.61.00 Mail fonc: systeme@univ-rouen.fr Mail pers: gilles.chauvin@univ-rouen.fr

On 5/10/2013 6:17 AM, Steve Campbell wrote:

But I believe fail2ban uses iptables, and I don't run a local firewall on the server. I'd prefer not to use a separate server to inject firewall rules on the border firewall. I might be wrong about fail2ban, though.

I was hoping there was a file for pop and imap in dovecot similar to the smtp "access" file in sendmail (which is what I use, BTW)

I run both - a border firewall and iptables on individual systems. The border firewall allows or denies traffic to specific systems; for instance, web traffic can go to web servers, but web traffic destined for mail servers is dropped.

Local servers also have basic rules like this (mail servers drop all web traffic), but they also have more specific rules, such as the fail2ban abuse detection rules.

This is called the belt and suspenders approach to security, and is a good idea. With your current method, if a hacker gains access to one system, they can launch attacks at other systems on the same network which they would not be able to do from outside the network. Belt and suspends mitigates much of that.

Just having local iptables, but no border firewall means that a hacker that gains access to a system can disable iptables and use the system to launch attacks at other systems, use the system as a malware repository that is accessed on non-standard ports, etc. Belt and suspenders mitigates this also.

If you are able, you should consider running iptables locally on each system. This would then let you run fail2ban, also.

FWIW, I also run an invisible IDS at the border and local IDS's that are not so invisible, but that is beyond the scope of your comment.

Dem

On 5/10/2013 10:05 AM, Oscar del Rio wrote:

On 05/10/13 08:17 AM, Steve Campbell wrote:

...

Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler.

How about TCP wrappers? http://wiki2.dovecot.org/LoginProcess - "Login access check sockets" - "TCP wrappers support"

I use Centos and the default dovecot RPM. I seem to recall there was a way to determine if dovecot was built with "--with-libwrap". Can anyone shed light on how to determine this, please?

Thanks

steve

On 5/10/2013 10:53 AM, Michael Wessel wrote:

Did you have a look at this? http://wiki2.dovecot.org/Authentication/RestrictAccess

On 5/10/2013 5:17 AM, Steve Campbell wrote:

...

Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler.

Thanks

steve campbell

The reason I'm asking about all of this is that a particular IP address is attempting to connect to our pop server, and it's trying every possible common user name (I think this is call a dictionary attack).

I can't restrict access to a particular IP subnet because our users access their email from all over the place. So this suggestion seems to not be a solution, as I see it.

Thanks though.

If I have to, I'll just go put this IP on the firewall, but I don't have remote access (for security), so it's a little more effort than accessing the pop server.

steve