1

Topic: Continuing frustration with Brute force attempts

This morning it happened again. POP was knocked out by continued hammering per the following in dovecot log (to the tune of 8000+ entries), where "somedomain" is MY domain:

Feb 27 06:12:50 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<support@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:50 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<info@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:53 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<help@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:55 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<support@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:55 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<help@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:56 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<info@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:57 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<support@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:57 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<help@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X
Feb 27 06:12:58 pop3-login: Info: Aborted login (auth failed, 1 attempts): user=<Administrator@somedomain.net>, method=PLAIN, rip=217.33.154.50, lip=10.X.X.X.X

My firewall status is as follows:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
110/tcp                    LIMIT       Anywhere
995/tcp                    LIMIT       Anywhere
465/tcp                    LIMIT       Anywhere
25/tcp                      LIMIT       Anywhere
Apache                     LIMIT       Anywhere

The LIMIT is set to the default: 6 per 30 seconds. How on earth is this happening? Why isn't the firewall stopping this ridiculous behavior? As you can see it's the exact same IP address every time...so that should trigger the limit, no?

So, IRedmail community, any help is GREATLY appreciated. Thoughts?

Thank you in advance.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Continuing frustration with Brute force attempts

I have installed Fail2Ban.

dovecot-pop3imap.conf

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#
failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted login \(auth failed|Aborted login \(tried to use disabled|Disconnected \(auth failed).*rip=(?P<host>\S*),.*

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

The following added to jail.local

# DOVECOT

[dovecot-pop3imap]

enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
      sendmail-whois[name=DOVECOT, dest=root@localhost, sender=fail2ban@mydomain.com]
logpath = /var/log/dovecot.log
maxretry = 20
findtime = 30
bantime = 3600

Does this look sensible?

Any advice is appreciated.

3

Re: Continuing frustration with Brute force attempts

I'm still not sure why LIMIT in ufw did not catch this though...

4

Re: Continuing frustration with Brute force attempts

Excuse me, could you explain what result you exactly want?

Is it possible to turn on debug mode in dovecot to check more detail error?

5

Re: Continuing frustration with Brute force attempts

@glacierdigital: the fact that you have LIMIT in ufw doesn't necessarily help. It only blocks on new TCP/IP connections. But I think the same connection can be reused - I'm not sure about that, I never tested if the connection is closed on failed authentication.

You should increase findtime, 30 seconds is not enough. Maybe 300 or 600? I've seen distributed attacks against my servers that wait for up to 20 seconds before another try from the same IP.

Most important: also add fail2ban rules for SSH, SMTP (you an crack password trying SMTP too), and also for Roundcube. I think that for the latest version of RoundCube it correctly writes the remote IP in the logs.

Also, don't leave any inbound ports open. Only permit what you need, drop or reject everything else.

6

Re: Continuing frustration with Brute force attempts

ZhangHuangbin wrote:

Excuse me, could you explain what result you exactly want?

Is it possible to turn on debug mode in dovecot to check more detail error?

Specifically, I want to stop these brute force attacks from happening. These actually kill Dovecot for a few minutes, which is unacceptable. Meaning I'd like to tarpit IPs that attempt to connect too many times.

I have turned on:

mail_debug = yes
auth_debug = yes

Thanks in advance.

7

Re: Continuing frustration with Brute force attempts

Thanks maxie,

I appreciate the feedback on LIMIT. I confirmed yesterday that it the LIMIT issue is the case. The connection is not closed on a failed attempt to authenticate.

Thank you for your response regarding fail2ban. I'll make those adjustments.

For SMTP do you just use the default settings?

Can you share your Roundcube .conf and jail files?

Other than the ufw status above everything else is denied.

Thanks again!

8

Re: Continuing frustration with Brute force attempts

Please take care that filter files are distribution-specific. My filters might not work on your distro. Test them with fail2ban-regex.

Postfix not logged in:

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 553 5.7.1 <(.*)>: Sender address rejected: not logged in;
ignoreregex =

Regarding Roundcube, I still use version 0.3.x, which I patched manually to write the correct IP in it's own logs, so my filter files won't apply to you. I'll test 0.5.1 someday this week, it's supposed to already have this feature built-in.

9 (edited by maxie_ro 2011-03-02 02:25:50)

Re: Continuing frustration with Brute force attempts

Hi, I tested it today with roundcube 0.5.1.

What I did:
* Upgraded Roundcube
* Change config file to log to syslog / local 5, thrown to /var/log/roundcube (so I don't pollute the main maillog)
* Modified filter files for fail2ban

These are instructions for CentOS 5.x, adapt them accordingly for your distro:

roundcube's main.inc.php:

$rcmail_config['log_driver'] = 'syslog';
$rcmail_config['syslog_id'] = 'roundcube';
$rcmail_config['syslog_facility'] = LOG_LOCAL5;
$rcmail_config['smtp_log'] = true; // <- optional
$rcmail_config['log_logins'] = true; // <- i think this is optional too

/etc/syslog.conf:

# Roundcube
local5.*                                                /var/log/roundcube.log

/etc/fail2ban/filter.d/roundcube.conf

[Definition]
failregex = roundcube: (.*) Error: Login failed for (.*) from <HOST>\.
ignoreregex =

I use shorewall as firewall, modify it for ufw for you:

[roundcube-shorewall]
enabled  = true
filter   = roundcube
action   = shorewall
    sendmail[name="<Roundcube failed authentications>"]
logpath  = /var/log/roundcube
findtime = 3600
maxretry = 10
bantime  = 3600

Test:

[root@mx1 fail2ban]# fail2ban-regex /var/log/roundcube.log /etc/fail2ban/filter.d/roundcube.conf
[...]
Success, the total number of match is 1
[...]

10

Re: Continuing frustration with Brute force attempts

That's awesome. Thanks maxie!