One problem you might run into is having authenticated SPAM, ie. a situation where SPAM leaves your MTA by using real credentials. In this case, some evil computer is using you by:
- connecting to your MTA
- authenticating using SMTP AUTH (where’d they get the credentials?)
- sending SPAM through your server (often authenticated users mail is not scanned)
- making you get into black lists
Effectively it is like your server was an open relay for that evil computer, although it is configured correctly and does not allow open relaying. (Because authenticated users can relay) You can and should always check if you’re not open relay anway. eg with http://www.abuse.net/relay.html
My friend had an exact problem with his qmail setup. What I found out first was that the qmail-smtpd (/var/log/qmail/smtpd/current) log was showing authenticated relays from unkown clients/domains to unkown domains, like so:
CHKUSER relaying rcpt: from <kbradford@philadefender.org:test:> remote <User:unknown:82.128.32.42> rcpt <aikens_l@msn.com> : client allowed to relay CHKUSER relaying rcpt: from <kbradford@philadefender.org:test:> remote <User:unknown:82.128.32.42> rcpt <aggie-87@cox-internet.com> : client allowed to relay
My friend was not hosting any of these domains. As you see the account used was SMTP AUTH was test. This means that the offender (82.128.32.42) knows the username and password for test account. That can also be checked with vuserinfo from vpopmail package:
# vpopmail test name: test passwd: some_passwordhash_here clear passwd: some_password comment/gecos: some comment uid: 0 gid: 0 flags: 0 gecos: gecos limits: No user limits set. dir: /home/vpopmail/domains/domain/D/test quota: 52428800S usage: 0% last auth: Tue Nov 25 10:55:01 2008 last auth ip: 82.128.32.42
The last line shows again the IP of the offender. That’s enough to make you want to change the password, rename the account or simply use CDB or firewalls to circumvent the abuse.
However, there’s actually a bit more you can see. Actually this is what I did, when I first had this I didn’t see the ‘test’ account being used.
Using tcpdump I recorded some network traffic to a file, like:
# tcpdump -w dump.txt host 82.128.32.42
I gave it 30 seconds to record and CTRL+C’d it. Then had a look into the dump.txt file. From all that traffic, what you can actually see is a lot of trash + some commands at the end like: EHLO, AUTH LOGIN, etc..
What I was able to decipher from that was roughly this:
AUTH LOGIN 334 VXNlcm5hbWU6 dGVzdA== 334 UGFzc3dvcmQ6 dGVzdA==' 235 2.0.0 OK Authenticated
As you may or may not now, AUTH LOGIN here uses base 64 encoding. So I took this ‘dGVzdA==’ and pushed it through the base64_decode function in PHP. What I got was that the user and password used was: test/test (Obscene security hole with password matching the user. No wonder that got exploited)
Anyway what is also visible here is that:
- not only you should keep enforce strong password policy for external facing SMTP systems (both complexity and password expiration)
- you should enforce encrypted channels when sending authentication data with SMTP AUTH.
This should get you off blacklists and prevent load due to abuse like this.
Cheers mates!
