I've got a series of "smtpd/saslauthd" messages in my logs. Someone is trying to guess email accounts and passwords - they're just trying random names from a dictionary of common names - which, as they're going for SMTPD (and not any other service), is probably someone trying to find an email account they can take over for spamming or whatever. The grand problem here is that I have got "fail2ban" in operation, but whoever's doing this has a botnet at their command, as the IP address is different every time. So I'm not really sure how I can repel this attack, if it's distributed like this. They're not hitting the server enough to cause a DDOS. That's not their aim. Indeed, I think they're even doing it slowly enough to ensure that it doesn't cause any noticeable problems with service, to not be discovered - as they really could hammer this system much harder than they are, with such an arsenal of bots (as the amount of IP addresses they seem to have under their command is substantial, looking at the log file). How does one reasonably deal with such an issue?
I guess there is not much that you can do when they stay below the ban threshold for failed attempts. Banning by country is most likely not an option, so the only thing that you can do is to monitor the mailqueue to react in case that an attacker was successful in guessing a password and require strong passwords from your customers (see settings in ISPConfig System > Interface > Main config).
Yeah, there really is not much to be done. The attempts are happening at a slow enough rate - say, on average, about 10 or 20 seconds apart - so I can't even do rate limiting or anything. They know what they're doing, as I can't think of any useful criteria that I could use to differentiate this from legitimate traffic. The IP addresses are coming from all over the planet - .de, .it, .ar, .nl, .br, .uk, etc. - so it can't be done by IP range or anything either. Mind you, I knew this would eventually be coming. We all know that, right? It's just a matter of time. The consolation is that, at that rate of attack, with completely random names and passwords - and we don't currently host that many emails yet - the odds of success are absurdly low. But it is extremely annoying.
Maybe one way might be to block them just enough to leave your IP alone, for example when they get a block rate of 80% or so. E.g. one might try to lookup the last successful login for an account in the log, find out the country of the IP address and then block all login requests to that account from other countries for e.g. one hour. I'm not aware of a software that is able to do that at the moment, it's just an idea. And you probably need a kind of whitelist so clients can opt-out from that in case ist causes them trouble.
Hmm, I wonder. Do email clients retry refused connections a few times? Because I'm wondering if "firewall greylisting" could be a thing? First connect to port 25 / 587. Dropped. If the same IP tries again, let it through. And, of course, it still goes through the SASL / fail2ban stuff, even when the firewall lets it pass. But, much like "email greylisting", the idea is that legitimate traffic will try again, but spammers are firing things off at random and will give up if they get, from their perspective, zero responses. Same idea as email greylisting but if it's done at the firewall level, then it doesn't even get in (on first attempt) and would even disguise that a server even handles email at all. Though this all hangs on the idea that a legitimate email client, with a legitimate user trying to grab or send their emails, will give it a second shot at connection, if it hits that initial drop. I don't know if that's actually the case for all email clients.
I fear that greylisting won't work well here because the email client will show an error message right on first failure as far as I know.
Did you search if there is a real-time blacklist out there that covers this exact topic? When enough systems are reporting this kind of failed logins to an RBL, then it might work against large botnets. There must be some rules of course that try to filter out false positives like attempts where the same username and wrong password are used repeatedly which is probably a client that mistyped his password.
Just reading up on "nolisting". The idea with that is to have a purposefully broken primary MX - points to an IP address that's not even listening on any email ports - because legitimate RFC-compliant clients will correctly move onto the secondary MX, which is correct, but fire-and-forget bots will tend to just hit the primary, fail and give up. Like greylisting, it's not perfect, but it does apparently have a useful effect on reducing noise. Can't really do that, though, until I've got more than one IP address available. But interesting reading nonetheless. (If only there were an RFC that did mandate that clients should retry a few times, then my "firewall greylisting" could work. But, yes, it does depend on clients retrying and, if they don't, then it can't be made to work.)
