beeping spammers (BIG tip here!)

[faris]

I noticed loads of spam being sent through one of out systems this evening.
Unfortunately I couldn't figure out which account was compromised. There was no login visible. Just more and more spam coming in (but not going out, as I had stopped qmail). Tents of thousands of messages were coming in. But there was no login for me to tell which account it was.

I had a clue -- the "from" was a domain on the server. But not which account. As a precaution, I changed every single password on that account. No good. The messages continued.

I restarted qmail and xinetd -- nothing.
I blocked port 25 and 587. The messages still came in.
I disabled encryption, as I though I'd seen a login, but since it was encrypted I couldn't tell which account. Didn't help.

qmhandle showed me an IP in the headers of the spam messages, and with nothing else to go on, I took it to be the source. But going through the maillogs, I found no trace of it except several hours ago.

I tore my hair out. I couldn't understand it. What the hell was going on? Why couldn't I stop this darned spam? Was the system compromised? Haven't loads and loads of people mentioned similar problems in the past?

Eventually I thought to use netstat --- and saw the IP in question connected to the submission port. But I'd disabled submission AND firewalled it. What was going on?

Well, it seems that if someone is already connected, restarting xinetd with submission disabled doesn't not stop an existing connection. And obviously APF doesn't kill an existing connection either (WHAT? So if someone connects in the few seconds when the firewall is down during a flush, it doesn't kill all connections?????)

ANYWAY....netstat also showed me which process the bad IP was connected to: qmail-smtpd

Killing that process (there were two of them) instantly stopped the spammer in their tracks.

Unfortunately they've not come back so I still don't know which account was compromised.
A few other IPs have been trying two particular addresses (and failing since I changed the password) so I'm guessing one of those. But they have all gone quiet now, and that's annoying me. I wanted to see that IP come back and fail to login. As it is, I don't know if I've killed the problem or not. At least I now know what to do -- kill qmail-smtpd!!!!!! And now you do to!

The end. For now.

[prupert]

Unfortunately they've not come back so I still don't know which account was compromised.

Couldn't you just check the maillog for which account the IP address used to initiate the SMTP connection?

Since you are using Plesk and Qmail, here's a tip:

Code: Select all

grep cmd5checkpw /usr/local/psa/var/log/maillog | grep ipaddress

This should show you something like:

Code: Select all

timestamp servername cmd5checkpw: SMTP connect from rdns [ipaddress]
timestamp servername cmd5checkpw: SMTP user user@domain: logged in from rdns [ipaddress]

[faris]

Well in the end yes, it was that login "from 2 hours ago" (relative time). That login was the one that was sending the spam (and I knew which account from that). What confused me (and this was not mentioned in my original post) was that the messages were being sent in groups of 10, with a distinct pause between them.

This had me assuming there was a new smtp connection each time -- but I couldn't see it.

I wasted hours trying to find it - trying to find something that didn't exist. I could not conceive that a connection from 2 hours ago was still sending spam now. Nor could I understand why the connection didn't drop after I firewalled 25, 587, 993, 995, disabled encryption and disabled the submission port and restarted qmail.

I even disabled email on the domain in Plesk. None of these things stopped that existing connection.

And it is cases like this that have been reported on the Plesk forum in the past. People can't find a login in the maillog (it could have been a day ago), and changing passwords on the account, even if they know what account it is, doesn't stop the spam.

The key thing is to manually kill all processes to which there is an existing connection - that doesn't happen when you restart qmail. It has to be done manually.

netstat is the key -- but because I was looking for something that didn't exist (repeated smtp connections), I didn't think to check using netstat until too many hours had passed

[prupert]

This had me assuming there was a new smtp connection each time -- but I couldn't see it.

There is no limit on how many messages you can send per SMTP session on a default Plesk/Qmail setup. There is a timeout setting though, which is 20 minutes by default.

Code: Select all

/var/qmail/bin/qmail-showctl | grep timeoutsmtpd

Several Qmail patches/extensions exist to enforce a recipient limit per session. I believe Plesk previously even used one of them (maxrcpt via qmail-spp, http://qmail-spp.sourceforge.net/plugins/details/?id=34). Perhaps Scott knows more about this, or you can file a feature request at Plesk.

[faris]

The only timeout for incoming connections that I know about is

timeoutsmtpd
Number of seconds qmail-smtpd will wait for each new
buffer of data from the remote SMTP client. Default:
1200.

Unfortunately this doesn't do what I would want.

I'll keep looking though. There must be an overall timeout.

[scott]

Basically what you need is a limit on the maximum number of messages a user can send in a session. I think you can do that with policyd.

[faris]

I'll look into policyd.

spamdyke also does this, but most spamdyke rules are disabled when a user authenticates. I suspect this is one of them.

[faris]

policyd seems to be postfix only

[prupert]

Like I said in an earlier post in this thread, solutions for qmail exist:

Several Qmail patches/extensions exist to enforce a recipient limit per session. I believe Plesk previously even used one of them (maxrcpt via qmail-spp, http://qmail-spp.sourceforge.net/plugins/details/?id=34). Perhaps Scott knows more about this, or you can file a feature request at Plesk.