I have set up fail2ban for Postfix, banning failed attempts after 10 tries.

It "works" in the sense that the ban does get triggered.
I even get an email about it, so the mail-whois action works.
But it seems the IP address is never banned in iptables, meaning the iptables action doesn't seem to be working. Any ideas?

This is my /etc/fail2ban/jail.local file:

[postfix]
enabled  = true
port     = smtp,ssmtp
filter   = postfix
action   = mail-whois[name=postfix, dest=my@email.com]
           iptables[name=postfix, port=smtp, protocol=tcp]
           iptables[name=postfix, port=ssmtp, protocol=tcp]
logpath  = /var/log/mail.log
maxretry = 10

This is my /etc/fail2ban/filter.d/postfix.local:

[Definition]

failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed
            reject: RCPT from (.*)\[<HOST>\]: 554
ignoreregex =

This is how the /var/log/mail.log file looks. (I have changed the IP address etc. for privacy reasons, and changed "authentication failure" to "auth. failure" to make it more readable).

Notice how fail2ban sends the email after 10 (or rather 11) failed attempts. But the guy can still connect to my server after that. He continues to do so until time 06:55:56, a whole minute after the "ban".

Why? Maybe it takes iptables that long to apply the ban?

Oct 26 06:54:42 plato postfix/smtpd[15226]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:43 plato postfix/smtpd[15231]: connect from unknown[12.345.678.912]
Oct 26 06:54:44 plato postfix/smtpd[15231]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:44 plato postfix/smtpd[15232]: connect from unknown[12.345.678.912]
Oct 26 06:54:45 plato postfix/smtpd[15232]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:46 plato postfix/smtpd[15233]: connect from unknown[12.345.678.912]
Oct 26 06:54:47 plato postfix/smtpd[15233]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:47 plato postfix/smtpd[15234]: connect from unknown[12.345.678.912]
Oct 26 06:54:48 plato postfix/smtpd[15234]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:49 plato postfix/smtpd[15235]: connect from unknown[12.345.678.912]
Oct 26 06:54:50 plato postfix/smtpd[15235]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:50 plato postfix/smtpd[15236]: connect from unknown[12.345.678.912]
Oct 26 06:54:51 plato postfix/smtpd[15236]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:52 plato postfix/smtpd[15237]: connect from unknown[12.345.678.912]
Oct 26 06:54:53 plato postfix/smtpd[15237]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:53 plato postfix/smtpd[15238]: connect from unknown[12.345.678.912]
Oct 26 06:54:54 plato postfix/smtpd[15238]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:55 plato postfix/smtpd[15239]: connect from unknown[12.345.678.912]
Oct 26 06:54:56 plato postfix/smtpd[15239]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:56 plato postfix/smtpd[15240]: connect from unknown[12.345.678.912]
Oct 26 06:54:57 plato postfix/smtpd[15240]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:57 plato postfix/pickup[15215]: E57BF33B49: uid=0 from=<root>
Oct 26 06:54:57 plato postfix/cleanup[15248]: E57BF33B49: message-id=<20131026999999.E57BF33B49@plato.email.com>
Oct 26 06:54:57 plato postfix/qmgr[9270]: E57BF33B49: from=<root@plato.email.com>, size=2023, nrcpt=1 (queue active)
Oct 26 06:54:57 plato postfix/pipe[15254]: E57BF33B49: to=<my@email.com>, relay=dovecot, delay=0.02, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service)
Oct 26 06:54:57 plato postfix/qmgr[9270]: E57BF33B49: removed
Oct 26 06:54:58 plato postfix/smtpd[15258]: connect from unknown[12.345.678.912]
Oct 26 06:54:59 plato postfix/smtpd[15258]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:54:59 plato postfix/smtpd[15259]: connect from unknown[12.345.678.912]
Oct 26 06:55:00 plato postfix/smtpd[15259]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:55:01 plato postfix/smtpd[15260]: connect from unknown[12.345.678.912]
Oct 26 06:55:02 plato postfix/smtpd[15260]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:55:02 plato postfix/smtpd[15261]: connect from unknown[12.345.678.912]
Oct 26 06:55:03 plato postfix/smtpd[15261]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:55:04 plato postfix/smtpd[15262]: connect from unknown[12.345.678.912]
Oct 26 06:55:05 plato postfix/smtpd[15262]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 26 06:55:05 plato postfix/smtpd[15263]: connect from unknown[12.345.678.912]
...
Oct 27 06:55:56 plato postfix/smtpd[15296]: warning: unknown[12.345.678.912]: SASL LOGIN authentication failed: auth. failure
Oct 27 06:55:56 plato postfix/smtpd[15297]: connect from unknown[12.345.678.912]
Oct 27 06:55:56 plato postfix/smtpd[15297]: warning: Connection concurrency limit exceeded: 51 from unknown[12.345.678.912] for service smtp

What does your fail2ban log say?

Thanks so much for looking at this. I really appreciate it. Here is some further information:

I had the good fortune of being able to see this happen live (many times actually; the same guy had multiple IP addresses to play with). This is what I found:

• As soon as fail2ban triggers and sends me the email, it does indeed right away apply the iptables rule: I checked "sudo iptables -L" right after getting the email, and the IP address was indeed listed there as banned.
• However, the IP address can still connect to my Postfix for 1-2 minutes after that. So it appears that my iptables rules, although applied, are not taking effect immediately.

So the question is, why aren't my iptables rules taking effect immediately?

To answer your question, the /var/log/fail2ban.log contains the following. Notice, again, how the ban takes effect, but the guy can still try connecting for 1-2 minutes after that.

2013-10-28 05:31:50,995 fail2ban.actions: WARNING [postfix] Ban 123.56.789.123
2013-10-28 05:32:17,642 fail2ban.actions: WARNING [postfix] 123.56.789.123 already banned
2013-10-28 05:32:44,173 fail2ban.actions: WARNING [postfix] 123.56.789.123 already banned
2013-10-28 05:33:11,207 fail2ban.actions: WARNING [postfix] 123.56.789.123 already banned
2013-10-28 05:33:36,239 fail2ban.actions: WARNING [postfix] 123.56.789.123 already banned
2013-10-28 05:34:04,274 fail2ban.actions: WARNING [postfix] 123.56.789.123 already banned

It looks to me like they had already made 51 connections to the smtp port before your ban was triggered. My guess is that you probably have your iptables rule applying to new connections only so the connections that were already made can continue to do their thing until they get disconnected.

This "limit exceeded" thing appeared the first time, but it hasn't appeared since. Some guy from Asia has been trying to attack me whole day now using multiple IP addresses and he's still at it. After one IP address gets banned, he switches to another one maybe 30-60 mins later. Again, what bothers me is that the IP doesn't get blocked immediately, it seems.

That's an excellent question, and I don't seem to be able to find an answer. On one system I deal with, it's set to block an address after four failed ssh login attempts - sometimes attackers can get five or six tries in, but it takes seconds or less to stop traffic; nowhere near a full minute.

If there seems to be consistently a delay of a minute, I would guess that there's some sort of batching going on in the kernel where it waits to apply new rules. Otherwise, perhaps the load on your system prevents it from being applied immediately, or it could even be a kernel bug.

This does not directly address the problem, but you could set up firewall rules to rate-limit connections to the ports in question. This would at least reduce the speed of attempts. Be careful in your settings - you don't want to keep out legitimate connections. (Note that Postfix has its own rate-limiting which might be easier to use than iptables - this is what the "Connection concurrency limit" log message was about. I don't have first-hand experience setting it up, but it looks as simple as setting smtpd_client_connection_rate_limit in main.cf and restarting Postfix.)

On a side note, it can be easy to take attacks personally when you're starting out. In truth, there isn't "some guy from Asia" sitting at a keyboard on the other end of the connection. It's a random compromised Windows box or web server that is just one of many that is part of a botnet running an automated script. Like a Terminator, it can't be reasoned with, bargained with, intimidated, or even annoyed. It'll just try until it sees it's not succeeding, then move on. Meanwhile another bot will try.

If this is the case (and maybe dee4 can confirm by pasting the rules that f2b concocts), then you can force postfix to disconnect the user after a number of errors (which could include auth failures). The config parameters you'd be interested in are smtpd_soft_error_limit (connection is slowed after this many errors), smtpd_error_sleep_time (connection is slowed by this much after smtpd_soft_error_limit errors are reached) and smtpd_hard_error_limit (connection is severed after this many errors). See what they are currently (postconf -d | grep _error_) and adjust as you see fit.

Thanks for the replies. I still have Ubuntu 10.04 LTS. I'll let you know how things go after I upgrade to Ubuntu 12.04 LTS, but this could be after a few months so don't wait around for me.

It seems to me that the default Postfix parameters will work just fine for now (in particular the smtpd_error_sleep_time, smtpd_soft_error_limit, and smtpd_hard_error_limit).

The question is, why would anyone engage in this attack? Seems to me that I'd have to have a very weak password for their attacks to be successful, even if I turn off Fail2Ban. I suppose they just keep looking until they find a very weak server, don't they?

That's been answered already in this thread.

There is NOBODY doing this - it's all scripted botnets (compromised workstations or servers) sifting thru the net looking for low hanging fruit. If you have a public IP, then you're a target.

Best solution - don't use passwords on server services (like ssh) and enforce encryption and strong passwords on your email accounts - and then ignore the chaff, it will NEVER go away.

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

Thanks, that makes sense, but it makes me more curious.

Suppose I follow this guide to setup email on my node: https://library.linode.com/email/postfi ... 0.19-mysql

Suppose I then get rid of all connection/rate/login limits etc. from Postfix. I also don't install Fail2Ban and don't have any rate limits through iptables.

Under this setup, how easy would it be for a cracker to brute force crack a strong password?

What I'm asking, under the Postfix/Dovecot setup in that guide, is each password trial slow enough such that a reasonably strong password (e.g. 20 characters of numbers, letters and symbols) would take centuries to crack?

In cryptography, this is often done with lots of PBKDF2 iterations to slow down each attempt. Do Postfix/Dovecot have that after following the guide?

Based on the $6$ in the Library section on adding users, Dovecot appears to be using SHA-512 hashes, with just a single round of hashing.

It's my understanding that this a hash that is not intended to have the same work-factor properties as bcrypt or PBKDF2. It looks like you can make Dovecot use bcrypt, but only if your libc supports it (see man crypt on your system).

Edit: some of this is incorrect; the SHA-512 hash scheme uses multiple rounds and is at least partly designed to increase the work factor. See posts below for details.

Thanks for pointing me in the right direction.

If I look at this link: http://wiki2.dovecot.org/Tools/Doveadm/Pw
it seems to me that they use 5000 rounds by default for SHA512-CRYPT. The reason I say this is that currently (after following Linode's guide), the form of the email user passwords in my MySQL database is like this:

$6$grF.zp/BK.HuJ/vv$MLhrz7o/kmyx1ykNaz4lzL3nBpI7YqcJfaO.7OHu/NNFzajISgi.Hoj1XMF2ECJhzhhMH8vGahwcfNBu62d.v0

Indeed, if I type in
sudo doveadm pw -p "hello" -s SHA512-CRYPT
I get a similar output:

{SHA512-CRYPT}$6$yXhlPOzKNYhBViN/$SDKbHqjex/CHE2spoI4tBLh86kSFUOy5k8o5lIopCYeELaWtkVe5Y8RwuyxvDIXzF2cN0838x1RE.JGrcFrR31

However, if I specify the rounds the rounds show up in the result, so if I type
sudo doveadm pw -p "hello" -r 100000 -s SHA512-CRYPT
I get:

{SHA512-CRYPT}$6$rounds=100000$3yLxwVr5ryV8YT0I$PpzQVIq.qOg0b.eIiRPYu3z4/01hguuzX0bcRR2Tmjav3Upqj8r7sd4MwTXGRbMOm5QabX2icHIuU2STeAaA0/

Meaning that since there were no rounds stored in MySQL, it means it's using the default of 5000 rounds.

Maybe I'm missing something. By all means correct me if I'm wrong!

Good catch. I made a mistake by assuming it was a single round for SHA-512. In fact you are correct; 5000 rounds is the default.

According to that document, you can specify up to 999999999 rounds and (Linux) libc should handle it. So I think things should work if you choose 100000 rounds (although I would time it to make sure it doesn't take too long).

Very good, thanks, it works!
To summarize, here is how people boost the security of their default email setup after following Linode's guide:

1. Use some password generator to generate a strong > 20 character password with letters, numbers and symbols. (Or some other strong password generator such as Diceware)
2. Change the type of the password column in your virtual_users table in MySQL to TEXT (the default is VARCHAR(106) and the new password won't fit there).
3. Use sudo doveadm pw -p "theStrongPassword" -r 50000 -s SHA512-CRYPT to generate the new encrypted password. Note that we are now using doveadm to generate the password instead of using MySQL functions (as Linode do in the guide)
4. Put your new encrypted password into the database (everything including and following the $6$)
5. Open ~/.bash_history and remove the lines showing your passwords.

Hope that helps someone, or myself when I need to do this again later

It could be a) this is creating only one of the iptables rules, or b) you're running iptables on port 587 as well and its this one being attacked. There is iptables-multiport and iptables-ipset-proto6 for dealing with blocking multiple ports. There was a problem using the same action more than once in the same jail that was only fixed one or two fail2ban versions ago.




Note: this probably applies to you too now http://www.kb.cert.org/vuls/id/686662

Grab an official replacement https://github.com/fail2ban/fail2ban/bl ... stfix.conf and/or look up why un-anchored regexs are dangerous ( https://github.com/fail2ban/fail2ban/bl ... er/FILTERS ).