SASL failures: find out which mailbox they're connecting to?

[chrismcb]

I'm seeing quite a few brute force login attempts to send mail, however the mail logs aren't very helpful.

Code: Select all

postfix/smtpd[14389]: warning: 66.64.240.218.nw.nuvox.net[66.64.240.218]: SASL LOGIN authentication failed: authentication failure

Repeated lines like above all at the same second - then another from a different IP a few minutes later.


Is there any way to figure out which vhost or, better yet, mailbox they're trying to connect to?

[faris]

Right. This is a botnet-based attack - the use of multiple IPs means that no single IP connects often enough to be blacklisted (usually). I have a FR open on detecting this.

As to actually figuring out the username.....

With qmail you get:
cmd5checkpw: SMTP user USERNAME: auth FAILED from unknown [a.b.c.d]

I don't understand why the same isn't the case with postfix. Maybe there's a verbosity configuration somewhere?

These KBs (middle one in particular) will be useful for IMAP/pop3 but don't do anything for SMTP auth.

http://kb.parallels.com/en/10
http://kb.parallels.com/en/112316
http://kb.parallels.com/en/114066

You could use tcpdump on port 25/587, catch an IP doing its thing, then search for communications with that ip in the dump.

[chrismcb]

Thanks Faris.

As you've pointed out, since it's postfix, there doesn't seem to be the same functionality available than for qmail.

I have taken a dump (one of the first things I did), but didn't go through with processing it hoping there was a better solution.

I looked through all the KB articles and I also followed postfix instructions to increase the verbosity of logging, but it is the plesk_saslauthd process which is doing the logging:

Code: Select all

Dec  7 13:05:58 server plesk_saslauthd[18676]: activity on 1 channel(s)
Dec  7 13:05:58 server plesk_saslauthd[18676]: new client (fd=10) registered
Dec  7 13:05:58 server plesk_saslauthd[18676]: main cycle iteration
Dec  7 13:05:58 server plesk_saslauthd[18676]: activity on 1 channel(s)
Dec  7 13:05:58 server plesk_saslauthd[18676]: some read activity on client 10
Dec  7 13:05:58 server plesk_saslauthd[18676]: read(10, &buf, 2)=2
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=0]
Dec  7 13:05:58 server plesk_saslauthd[18676]: read(10, &buf, 5)=5
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=1]
Dec  7 13:05:58 server plesk_saslauthd[18676]: read(10, &buf, 2)=2
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=2]
Dec  7 13:05:58 server plesk_saslauthd[18676]: read(10, &buf, 8)=8
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=3]
Dec  7 13:05:58 server plesk_saslauthd[18676]: read(10, &buf, 2)=2
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=4]
Dec  7 13:05:58 server plesk_saslauthd[18676]: read(10, &buf, 4)=4
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=5]
Dec  7 13:05:58 server plesk_saslauthd[18676]: read(10, &buf, 2)=2
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=6]
Dec  7 13:05:58 server plesk_saslauthd[18676]: processing client data chunk [state=7]
Dec  7 13:05:58 server plesk_saslauthd[18676]: Invalid mail address 'frank@'
Dec  7 13:05:58 server plesk_saslauthd[18676]: main cycle iteration
Dec  7 13:05:58 server plesk_saslauthd[18676]: activity on 1 channel(s)
Dec  7 13:05:58 server plesk_saslauthd[18676]: some write activity on client 10
Dec  7 13:05:58 server plesk_saslauthd[18676]: attempt to write(10, &buf, 4)
Dec  7 13:05:58 server plesk_saslauthd[18676]: client 10 processed
Dec  7 13:05:58 server plesk_saslauthd[18676]: main cycle iteration
Dec  7 13:05:58 server postfix/smtpd[18453]: warning: rrcs-67-52-184-130.west.biz.rr.com[67.52.184.130]: SASL LOGIN authentication failed: authentication failure
Dec  7 13:05:58 server postfix/smtpd[18453]: disconnect from rrcs-67-52-184-130.west.biz.rr.com[67.52.184.130]

That does show a connection with login as "frank@" - but nothing more.

I too think its a botnet, but have no clue how to stop it.

I have asked Atomicorp to create a rule to try to shun the IPs - the majority are 5 failed connections all in one second.

[faris]

one thing that MIGHT help is that invalid address logins MIGHT be logged in /var/log/messages as opposed to the maillog. They are with qmail, but without an IP to go with them. Bah

If it is the same botnet that's been hitting us, the majority of the IPs are in latin america (and spain) although the perps are in Eastern Europe.

The LatAm IPs seem to be allocated mostly in /16s (Brazil, mostly) so I firewall them entire /16 each time I see a new IP having a go. But that's only because we have no customers there and don't want any either.

My suggestion to resolve this was a rule that looked at the failed username and if more than one IP was failing for that same IP to block them. Well, that's the very basics of it. But if you aren't getting a username logged...bah! That's no good.

[chrismcb]

Scott is currently making a change to OSSEC as a bug in it ignores duplicated lines and pushing out an update soon which should help combat the randomness of the botnet.

It's not causing a load increase on the server, but has been persistent since Friday morning.

My connections are a bit more varied, with US IPs, Turkey and China... a bit too wide to do anything manually about it really.

Will just keep an eye on it until the new update comes out.