102

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.

19
  • 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. Commented Nov 27, 2017 at 7:39
  • 5
    Is it the same account being tried or different accounts?
    – schroeder
    Commented Nov 27, 2017 at 9:43
  • 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
    Commented Nov 27, 2017 at 10:42
  • 8
    @schroeder: The user names tried in the last two hours are info@<mydomain> (1 try), admin@<mydomain> (1 try), and AB<char13> (2 tries). Looks like classic brute-force guessing to me.
    – Heinzi
    Commented Nov 27, 2017 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
    Commented Nov 27, 2017 at 13:40

5 Answers 5

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.

11
  • 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... Commented Nov 27, 2017 at 14:28
  • 75
    Maybe change the admin password to one that they already tried. That'll trip them up. </joke> Commented Nov 27, 2017 at 23:11
  • 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
    Commented Nov 28, 2017 at 0:27
  • 77
    The passwords wouldn't be commonly used if they weren't good, right? Commented Nov 28, 2017 at 9:19
  • 27
    @StigHemmer This is why enterprises have mostly standardised on "Password123!"
    – James_pic
    Commented Nov 28, 2017 at 13:58
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.

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.

4
  • 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
    Commented Nov 27, 2017 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
    Commented Nov 27, 2017 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.
    Commented Nov 29, 2017 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
    Commented Nov 30, 2017 at 16:19
7

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.

2
  • 5
    For more on this, read about the Hail Mary Cloud.
    – JdeBP
    Commented Nov 28, 2017 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. Commented Nov 30, 2017 at 17:50
1

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.

1
  • 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
    Commented Dec 24, 2017 at 22:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .