Server being used to relay spam (Pesk + Qmail), how do I stop it?
 

I have a Root server with 1and1. They use Plesk as the control panel so that is what I have been using.
I got a notice from them that our server has been sending spam and they are getting complaints.

The server uses Qmail with spamassassin

In the Plesk control panel I have set (From day 1) for mail relay to be on, but require SMTP authentication.

When I look in the mail queue for the server I see the same sender (not a domain on my server) sending mass emails to a group of 100+ users.

I went through and looked at everything I could to see if I had something setup that was not correct and I just do not see it.

I ran a telnet to the server and attempted to send from a domain not in the RCPT list and it failed.

What logs can I look at or how can I determine if they are sending directly from the server or if I have a site on there that has been compromised?

Thank you for all your help!

I checked the secure log and see a lot of the lines like the following, some are legit and a lot of not.

Nov 18 15:25:31 u15262964 xinetd[3826]: START: smtp pid=3435 from=202.75.56.43

I checked and this is a AU IP. Some are from Africa, Amsterdam, China, etc



These are obviously the spammers, but are they connecting from the outside world to my server to send?

First, check your SMTP authentication. I'm not clear on the details of SMTP-AUTH, but Wikipedia suggests that it can use password authentication; this could be a simple matter of someone brute-forcing your password. The first thing I'd do is change your password and see if the problem stops.

If the server has been compromised, then the chances are that it's a known rootkit that's being used to send spam; you should probably try running chkrootkit to test for this. http://www.chkrootkit.org/.

Can you get hold of a sample spam message? This may tell you if they are using your mail system or not (qmail headers) and may even yield something about the upstream message sender, such as an IP address or the mail agent that they are using.

Qmail logs to /var/log/qmail/ (at least, it does on my server, but I'm running quite an old configuration). There are various files in subdirectories, each named current, that hold the main logs for each module. You probably want to look at /var/log/qmail/smtpd/current.

The other thing you really should do is tell your server provider. Most providers are very happy to help track down problems when servers may have been compromised, but they will usually want to re-image your server to be sure, so make sure that you have a backup of anything important on the server.

xinetd is controlled from /etc/xinetd.conf. Generally, it will be configured to spawn a dæmon when an incoming connection arrives on a particular port, so the chances are that this is an incoming connection from the outside world that's forcing its way past your SMTP-AUTH.

I have SMTP Auth turned on and when I run all my tests it shows the server is not an open relay. I will try to get ahold of a sample spam message so we can take a look at it.
I checked the qmail logs and all they are really telling me is that person@notmydomain.com is attempting to send to person@atnotmydoman.com.
It doesnt really state if it had been delivered and when I check the queue through Plesk I see them sitting there. So I clear them out, then in a few more days they are there again, waiting to be delivered.
I will post up any log you need to see.
I added a boat load of ip's to my host.deny for ssh because I saw there was someone running a dictionary attack on the server as well.

I have spent the last few hours trying to dig deeper into this and it seems I just come up with more questions, lol

I also ran chkrootkit and the only thing I see that came back infected was:

Checking `bindshell'... INFECTED (PORTS: 465)


Which from what I read might be ok (false negative)

Do you know what version of qmail-smtpd-auth you are using? According to the changelog (http://members.elysium.pl/brush/qmail-smtpd-auth/) there was a fix in version 0.26 that could let an attacker get relay access (not sure under what conditions).

Again, SMTP-AUTH isn't worth anything if your password is guessed, so changing your password really might be worth trying.

I did change my password as soon as I got the email from 1and1 telling me about the spam. I have about 25 domains on the server right now, so in theory anyone of the accounts setup with mail could of had there passwords guessed and they are using that account right? How would I find out what account it is?

How do I check the version of qmail-smtpd-auth?

It's more likely the password of one of the users that is able to relay. You need to work out which user is being authenticated for spamming purposes.

How do I go about finding that out? I tried looking in all the logs I have and nothing seems to tell me what AUTH ACCT is sending the spam.

Don't your maillogs tell you anything useful? Who's the sender of mail? Is there an authentication showing up at the same time? What distro are you using?

You should be able to find this out from the headers of one of the spam messages after qmail has added it's headers.

You may also be able to find the version of smtp-auth from your distribution's package manager.

The distro is FDC 4
The mail logs show me the sender and the recipients email address but never shows me an account it was sent with.

Nov 18 13:35:48 u15262964 qmail-remote-handlers[31212]: from=alert@abbey.com
Nov 18 13:35:48 u15262964 qmail-remote-handlers[31212]: to=zinch@publiconline.co.uk

The secure log shows me smtp access and from what IP address like above but nothing that shows me what account they are using to send, if in fact it is one of my customers email accounts they are using.

one of the issues I'm running into is the spam is being sent to people not on our domain so I have no way of getting those headers, unless there is another way from the server level to obtain them.

My customers do get spam from the outside world as most do, we run spamassassin, APF, and a few other security sets to keep that down.

Do you mean Fedora Core 4?

Yes sir it is Fedora Core 4. And thanks to all you for taking the time to help me with this.

I think the outgoing messages get queued into /var/qmail/queue/. I think that the headers may be split into separate files, and I'm not sure which subdirectory they go into (I only use qmail for incoming mail, and it's usually gone by the time I check the queue). But if you want to find a spam message then that would probably be the place to look.

I have no logs in the /var/qmail/queue directory, all I have is directories with 0-18 directories with no data in them.
There are a few places I looked like /usr/local/psa/var/ but didnt have anything helpfull in there

I get better logging with postfix, eg

Can you add verbosity to qmail logging somehow?

As an aside, FC4 is no longer receiving security updates, so you should think about upgrading as a priority.

I completely agree, I keep up with the server but have not set the plan into action to get it upgraded. This is absolutely the next thing I will do after I get this figured out. I really am afraid of getting on a blacklist that will cause even more issues.

I'm not sure on the verbose mode for qmail, I will have to look that up on there site.

This may help; it contains an example of tracking down an account with a weak password:

http://www.cherpec.com/2008/07/plesk...spam-problems/

There are many variables to this problem.
Here is some info for auditing.

One of your clients might have an insecure PHP form which is being attacked. This wouldn't show up as an email user on your system, and the attacker wouldn't have to break any passwords; that all would be taken care of by PHP.

I believe FDC4 is a legit name. Google hits show it is more than likely FeDora Core 4 (not sure on this, though).

If that's the case, that is a very OLD version!

EDIT - It appears that when I originally posted this, it didn't post but hung in dramatic fashion, which kept it from being posted in a timely fashion. I'm deleting the content of my next response.

Or because the D is next to the F? Anyway, he confirmed FC4

<content removed to avoid confusion>