101

This has been going on for about 1-2 days now:

heinzi@guybrush:~$ less /var/log/mail.log | grep '^Nov 27 .* postfix/submission.* warning'
[...]
Nov 27 03:36:16 guybrush postfix/submission/smtpd[7523]: warning: hostname bd676a3d.virtua.com.br does not resolve to address 189.103.106.61
Nov 27 03:36:22 guybrush postfix/submission/smtpd[7523]: warning: unknown[189.103.106.61]: SASL PLAIN authentication failed:
Nov 27 03:36:28 guybrush postfix/submission/smtpd[7523]: warning: unknown[189.103.106.61]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 04:08:58 guybrush postfix/submission/smtpd[8714]: warning: hostname b3d2f64f.virtua.com.br does not resolve to address 179.210.246.79
Nov 27 04:09:03 guybrush postfix/submission/smtpd[8714]: warning: unknown[179.210.246.79]: SASL PLAIN authentication failed:
Nov 27 04:09:09 guybrush postfix/submission/smtpd[8714]: warning: unknown[179.210.246.79]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 05:20:11 guybrush postfix/submission/smtpd[10175]: warning: hostname b3d0600e.virtua.com.br does not resolve to address 179.208.96.14
Nov 27 05:20:16 guybrush postfix/submission/smtpd[10175]: warning: unknown[179.208.96.14]: SASL PLAIN authentication failed:
Nov 27 05:20:22 guybrush postfix/submission/smtpd[10175]: warning: unknown[179.208.96.14]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 06:42:43 guybrush postfix/submission/smtpd[12927]: warning: hostname b18d3903.virtua.com.br does not resolve to address 177.141.57.3
Nov 27 06:42:48 guybrush postfix/submission/smtpd[12927]: warning: unknown[177.141.57.3]: SASL PLAIN authentication failed:
Nov 27 06:42:54 guybrush postfix/submission/smtpd[12927]: warning: unknown[177.141.57.3]: SASL LOGIN authentication failed: VXNlcm5hbWU6
Nov 27 08:01:08 guybrush postfix/submission/smtpd[14161]: warning: hostname b3db68ad.virtua.com.br does not resolve to address 179.219.104.173
Nov 27 08:01:13 guybrush postfix/submission/smtpd[14161]: warning: unknown[179.219.104.173]: SASL PLAIN authentication failed:
Nov 27 08:01:19 guybrush postfix/submission/smtpd[14161]: warning: unknown[179.219.104.173]: SASL LOGIN authentication failed: VXNlcm5hbWU6

There is one single failed login attempt every 1-2 hours, always from the same domain, but every time from a different IP address. Thus, it won't trigger fail2ban and the logcheck messages are starting to annoy me. :-)

My questions:

  1. What's the point of this kind of "attack"? The rate is much too slow to do any efficient brute-forcing, and I really doubt that someone would specifically target my tiny personal server.

  2. Is there anything I can do against it except banning that provider's complete IP range? I could just stop worrying and add those messages to my logcheck ignore config (since my passwords are strong), but that might cause me to miss more serious attacks.

Heinzi
  • 2,954
  • 2
  • 21
  • 25
  • 34
    Whether or not your personal server is tiny doesn't matter. It can become useful to botnet anyway. Slow speed could be simply to avoid tripping any detection mechanisms in place ( although that's just my opinion, not gonna make any hard statements). As for banning the provider range - that doesn't matter either. Botnet has plenty of ips available, and they potentially spoofable. – Sergiy Kolodyazhnyy Nov 27 '17 at 07:39
  • 5
    Is it the same account being tried or different accounts? – schroeder Nov 27 '17 at 09:43
  • 3
    @schroeder: Good question. I have just enabled logging the user names of failed attempts and will report back. – Heinzi Nov 27 '17 at 10:22
  • 18
    @Heinzi this would appear to be crucial info. If it is the same account and not one that you have, then someone misconfigured their server – schroeder Nov 27 '17 at 10:42
  • 8
    @schroeder: The user names tried in the last two hours are `info@` (1 try), `admin@` (1 try), and `AB` (2 tries). Looks like classic brute-force guessing to me. – Heinzi Nov 27 '17 at 13:34
  • 16
    I've seen this before on my honeypots. It's "background radiation". Brute force attempts spread out over a very wide scope. Guest's answer is the likely correct one. – schroeder Nov 27 '17 at 13:40
  • Simple solution: [Fail2Ban](https://www.fail2ban.org/wiki/index.php/Main_Page) with a custom jail and maxretry set to 1. That’s what I use and it works well. – Jim Garrison Nov 27 '17 at 19:18
  • 2
    Interestingly, they all seem to originate from one datacenter owned by Virtua in Brazil. Which makes me wonder, who would pay for servers if they could as well use bots that don't cost money and aren't linked to their credit card? – Damon Nov 28 '17 at 09:56
  • 3
    @Damon Virtua as a datacenter? What the hell are you talking about? Virtua is the former name of http://www.netcombo.com.br/, a residential cable TV / internet provider. You can even see the first part of the addresses seem to be customer MACs. – That Brazilian Guy Nov 28 '17 at 10:55
  • This appears to be a scan for default passwords, as the LOGIN provided is a username of `Username` and a password of the empty string. – Riking Nov 28 '17 at 23:31
  • If you're small enough, you could whitelist every ip netblock from which your devices might check email. So that would be any IP block assigned to your cellco, and the IP ranges from remote sites where you might get wireless (friends, workplace, etc) or just stay on cellular data. Not really advisable for anything larger than a home environment. – Criggie Nov 28 '17 at 23:41
  • Another dirty mitigator is to disallow IPv4 connections and only permit mail checks via IPv6, assuming you have it at both ends. The script kiddies tend to focus on IPv4 connections only. – Criggie Nov 28 '17 at 23:42
  • 1
    @Heinzi If the attack is coming from a Virtua-connected host, that's the reason you're seeing ever-changing IP's. That connection is notorious for suddenly changing IP's for no reason mid-use and can be headache-inducing for some applications. It is a domestic connection, mind you, so the attacking machine is probably part of a botnet of a domestic user trying to do "funny things" – T. Sar Nov 29 '17 at 10:44
  • Google for `fail2ban`. – peterh Nov 30 '17 at 23:57
  • @peterh: Please read the question again, fail2ban is already mentioned. – Heinzi Dec 01 '17 at 08:29
  • IIUC correctly, the attacks themselves have about zero chance of succeeding, but the main issue is they are filling up logcheck, and might possibly obscure other more serious attacks. Right? – smci Dec 01 '17 at 08:43
  • 1
    @smci: Exactly. I can just add those messages to my logcheck ignore config, but I was worried that I might miss more serious attacks then. However, after reading the answers, it seems that there is no easy answer to that problem and I should just filter those messages and stop worrying. – Heinzi Dec 01 '17 at 09:18
  • @Heinzi: ok but my point is you want to edit and restate the question per my paraphrase above. – smci Dec 01 '17 at 09:30
  • 1
    @smci: Done. I tried to make the change as small as possible, to avoid invalidating existing answers. – Heinzi Dec 01 '17 at 10:07

5 Answers5

148

What's the point of this kind of "attack"? The rate is much too slow to do any efficient brute-forcing, and I really doubt that someone would specifically target my tiny personal server.

You may be seeing connections very rarely, but how do you know the bots doing the brute forcing aren't constantly saturating their uplinks, and your site is just one of many being attacked? There is no advantage for an attacker to spend a short time going after one site at a time (and triggering fail2ban), compared to attacking a huge number of servers at once, where each server only sees infrequent connections. Both can have the same total rate of outgoing authentication attempts per second, but attacking one site at a time is simply a less efficient use of the attacker's bandwidth.

Is there anything I can do against it except banning that provider's complete IP range (or ignoring the messages, since my passwords are strong)?

No, not really. Chances are, these are coming from a botnet or a cluster of low-cost VPSes. It is not possible to determine what other IP ranges may be being used just by seeing a few of these. If they are not on the same subnet, they cannot be predicted. You can safely ignore these connections. It is nothing more than the background noise of the internet. Just make sure you aren't low-hanging fruit.

forest
  • 65,613
  • 20
  • 208
  • 262
  • 85
    at 1 try/ hour it takes around 4 days to try the 100 most common passwords on an account without tripping anything... I can see a huge return on this kind of attack for someone building a botnet... – Caterpillaraoz Nov 27 '17 at 14:28
  • 75
    Maybe change the admin password to one that they already tried. That'll trip them up. – potatopeelings Nov 27 '17 at 23:11
  • @Caterpillaraoz So you're suggesting we _not_ run servers secured against remote access by a password chosen from a list of 100 of the most common passwords? – Darren Ringer Nov 27 '17 at 23:23
  • 7
    @Caterpillaraoz You don't know how many servers they are hitting. In 4 days if they send the top 100 passwords to 30,000 mail servers they very likely got in to a few of them. – Qwertie Nov 28 '17 at 00:27
  • 4
    I suggest we all use "baseball!" as a password :P @Qwertie that is what I mean, "going slow" on many thousands of servers and hit many many many many accounts, out of curiosity I tried to SSH as default admin in my company`s F****G DATABASE and got in.... – Caterpillaraoz Nov 28 '17 at 09:10
  • 77
    The passwords wouldn't be commonly used if they weren't good, right? – Stig Hemmer Nov 28 '17 at 09:19
  • 27
    @StigHemmer This is why enterprises have mostly standardised on "Password123!" – James_pic Nov 28 '17 at 13:58
  • 3
    @James_pic: I would never guess Password123!, I usually give up after Admin, admin and root and ask someone who acutally knows the password – Christian Nov 28 '17 at 16:05
  • 4
    One thing that might extract a small measure of pain is if the response time for a failed password attempt against your host was increased. – JimmyJames Nov 28 '17 at 16:49
  • 3
    @Christian Thanks to Apple, root is a pretty fantastic guess on many Macs these days. – Daniel Nov 30 '17 at 04:32
  • @Daniel As username – EpicKip Dec 08 '17 at 12:48
14

Question 1 -- Unless it is a misconfiguration (as mentioned in the comments), in my experience it seems that these are automated attacks looking for accounts from which unsolicited commercial emails (or phishing attempts) can be sent from.

Question 2 -- If the range of IPs that your legitimate logins come from is knowable and small enough, it might be easier to block everything except those ranges.

I administer a small business email server, this type of probing happens almost continuously for us.

David Rouse
  • 241
  • 1
  • 3
12

1 attempt every 1-2 hours? That's not a brute force.

Maybe its someone's iPhone with an expired password. Problably yours! Or, if you are reusing a hosting company's IP addresses, the previous "owner" could still have some email client somewhere, configured to go to [now] your IPs.

If you have the IP addresses, the least you could do is trace them.

oxygen
  • 248
  • 1
  • 9
  • 2
    VXNlcm5hbWU6 is apparently a base64 encode of "Username", which apparently Postfix does send as a encoded prompt. Something related to "AUTH LOGIN" (lots of google hits) – infixed Nov 27 '17 at 22:45
  • @infixed Yeah, that string is a standard part of the AUTH LOGIN mechanism. In AUTH LOGIN, everything is base64-encoded going both ways. Underneath that encoding, the exchange is simple: (1) server sends "Username" (2) client sends the username (3) server sends "Password" (4) client sends the password. (Though I wonder if the string's presence in the log file might indicate that the client is actually sending "Username" as the username...) – David Z Nov 27 '17 at 23:49
  • 2
    If you hit 30k servers every 90 minutes it's still 5.5 requests per second, yes, this is brute force. – Daniel W. Nov 29 '17 at 12:23
  • 1
    Brute force is about approach, not about speed. Described attack definitely constitutes "brute force", even though it's rate rather evokes connotations with "gentle kindness". – Agent_L Nov 30 '17 at 16:19
6

Standard existing practice of banning IPs that repeatedly try to crack into a system only work against targetted attacks.

A botnet can find a huge list of servers, and distribute both who is making the attack and who they attack among the botnet. The symptom is going to be a background level of failed login attempts against your system, until one succeeds, at which point they'll deploy some kit that escalates to root and add your system to the botnet.

You can defend against this in very few ways.

Strong passwords are one possible defence, but need to be paired with keeping your system otherwise secure against non-password based attacks. Suppose it gets out that there is a buffer overflow/underflow attack on your login system; the botnet could be switched to make that attack and root 1000s of systems per minute, including yours.

Another defence could be obscurity. These kind of attacks go after low-hanging fruit. Modify your login system to (say) require a ping to a particular port number before it lets login attempts through. This is purely obscurity, but suddenly it stops looking like there is a place to login there. The cost is that you now need to craft a specific ping to login remotely. Or you can whitelist a few IP addresses from which you are permitted to login remotely from.

A final, extremely hard approach would be to generate a distributed botnet password hacking system detector. Just as systems keep track of IP addresses attacking them, a distributed system could keep track of botnets attacking anyone. Throw in a flow of trust system and you could build infrastructure that can detect such password cracking botnets and have everyone block them.

Such an effort would take years of work and would probably fail. But it is something you could do.

Yakk
  • 499
  • 2
  • 7
  • 5
    For more on this, read about [the Hail Mary Cloud](http://bsdly.blogspot.co.uk/2013/10/the-hail-mary-cloud-and-lessons-learned.html). – JdeBP Nov 28 '17 at 16:30
  • 2
    @JdeBP Can make an answer out of this short comment? An answer with the term "Hail Mary Cloud" and the reference given should be here. – Sir Cornflakes Nov 30 '17 at 17:50
0

SASL PLAIN authentication failed: and b3db68ad.virtua.com.br does not resolve to address 179.219.104.173

So long as you don't have PLAIN authentication enabled for any user, you should be ok. In addition, this: b3db68ad.virtua.com.br does not resolve to address 179.219.104.173 tells you that the domain(s) is a bogus domain, as it's not resolving to the IP used. Another fail. So it may not even be coming from that domain. You can spend a lot of time with Postfix writing rules to ban this sort of thing, but in the end the amount of time you expend far outweighs the load to your system.

Harry McGovern
  • 109
  • 2
  • More secure authentication methods (hashing +- kerberos) only protects the password from getting sniffed somewhere along the way or from logs, which means it protects the user the password is used, possibly through a centralised login, for auth on other systems. So he will not be ok! Brute force still works, regardless of how secure password testing is, even with Kerberos which uses some sort of hash+challenge approach (to not even send a reusable hash over the network). – oxygen Dec 24 '17 at 22:30