Email Admin’s Weblog

Gluing Linux email systems since 2000

  • Blog Stats

    • 6,522 hits

Authenticated SPAM – detection and intervening [qmail]

Posted by Maciej Sołtysiak on November 25, 2008

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:

  1. connecting to your MTA
  2. authenticating using SMTP AUTH (where’d they get the credentials?)
  3. sending SPAM through your server (often authenticated users mail is not scanned)
  4. 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:

  1. not only you should keep enforce strong password policy for external facing SMTP systems (both complexity and password expiration)
  2. 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!



Posted in Problem scenarios | Tagged: , , , | 3 Comments »

My case of pyzor: check failed: internal error

Posted by Maciej Sołtysiak on June 23, 2008

One of my routine tasks is, of course, to check the logs of running systems. I stumbled upon this warning message in my spamassassin logs:

warn: pyzor: check failed: internal error

Being a lazy person I usually google for an answer but in this case each advice I found didn’t apply to me. This means I had to do detective work.

Okay, so it looked like pyzor’s having some problems. Since it is usually executed as merely one of the programs in a scanning path, normally you might not even notice it’s not running right because other engines may work well enough. You might just notice increased spam levels or more false positives. Anyway what you should do is some checking, eg. using the pyzor ping command, as such:

# pyzor ping
82.94.255.100:24441     (200, 'OK')

This tells us that pyzor’s working fine and the server IP it has cached is also responding properly. Now let’s take a step back. Where did I get this message from. Who (what process) wrote it, to which log…

Well, this was found in the spamassassin log in /var/log/spamd/current. In Bill Shupp’s qmail toaster you get SA logging exactly there. It’s started from daemontools via the /service/spamd/run script. In there you usually have something like:

#!/bin/sh
exec /usr/sbin/spamd -x -u vpopmail -s stderr 2>&1

So pyzor was being executed from spamassassin with privileges of the user it was running under. And here we see that spamassassin is running under the vpopmail user. Well, so let’s check out our spamassassin configuration and permissions in there. They are usually in /etc/mail/spamassassin. Checking the local.cf file I found that I have a directive pointing pyzor where to look for it’s per-user config. Including the servers that are obtained with the pyzor discover command (found in the servers file). The config line that was doing this was (local.cf):

pyzor_options --homedir /etc/mail/spamassassin

Okay, so I have all my pyzor settings that are executed from spamassassin with vpopmail user in there. Let’s checkout permissions:

drwxr-xr-x   4 root     root  4096 2008-06-08 19:34 .
drwxr-xr-x 118 root     root 12288 2008-06-21 14:48 ..
-rw-r--r--   1 root     root   939 2007-10-01 20:55 65_debian.cf
lrwxrwxrwx   1 root     root    16 2007-10-24 07:21 FuzzyOcr.cf -> FuzzyOcr.cf.real
-rw-r--r--   1 root     root  5448 2007-05-03 00:54 FuzzyOcr.cf.real
-rw-r--r--   1 root     root   425 2007-05-03 00:54 FuzzyOcr.words
-rw-r--r--   1 root     root  1297 2008-06-08 19:34 init.pre
-rw-r--r--   1 root     root   689 2008-03-22 13:12 local.cf
-rw-r--r--   1 root     root  1208 2007-10-24 06:21 local.cf.bak
drwx------   2 root     root  4096 2008-06-17 07:29 sa-update-keys
-rw-------   1 root     root    20 2008-03-22 13:11 servers
drwxr-xr-x   2 vpopmail root  4096 2008-06-23 02:44 .spamassassin
-rw-r--r--   1 root     root  2599 2008-06-08 19:33 v310.pre
-rw-r--r--   1 root     root  1194 2007-10-24 06:16 v312.pre
-rw-r--r--   1 root     root  2412 2008-06-08 19:33 v320.pre

The culprit is the red server file. As you see vpopmail user can’t access it. Changing the permissions accordingly fixed my problem. 🙂

Note that I am currently not sure if I added this line myself, was it some installation script or is it a Ubuntu package configuration.

Did you have a similar issue?

Posted in Problem scenarios | Tagged: , | 7 Comments »

Hello email admins!

Posted by Maciej Sołtysiak on June 22, 2008

Welcome to the – hopefully helpful – Email Admin’s blog.

I am an applications and systems administrator since 2000 and this place is a spot for my blurbs about Linux email system components. The main focus is qmail, vpopmail, spamassassin, clamav, courier-imap, dovecot, maildrop, simscan, qmail-scanner, squirrelmail, roundcube, pyzor, razor, … get the idea? All those parts of that should work well to have a nice email service. However note, that you won’t find anything about other MTAs like: postfix, exim, sendmail. I’ve had good experience with postfix, but somehow I feel qmail is the most difficult to get working and fix, so I think it’s better to contribute in the least covered area.

For my own purposes and for an other 1000 user system I’ve been using Bill Shupp’s excellent qmail toaster. Or rather my own variants of it.

And the most important thing: I hope to write a post around once a month.

Wish me luck!

Posted in Organizational | 2 Comments »