qmail insecure no matter what

[egs2009]

Hey guys I've been having this problem in all the Plesk versions including this one:

What does this log mean?

Sep 16 23:12:22 qmail-remote-handlers[21958]: Handlers Filter before-remote for qmail started ...
Sep 16 23:12:22 qmail-remote-handlers[21958]: from=
Sep 16 23:12:22 qmail-remote-handlers[21958]: [email protected]

Basically from what I can see is that somehow remote hosts are able to send mail to anywhere they want and it's getting me blacklisted.

They don't appear to be logging in.
I have Plesk set to open relay but require authorization for pop & SMTP

How do I find more info about how they are doing this? Is it a direct connection or could it be a script on my server?

I know my server itself is not compromised, there are no rootkits etc.....

It seems SW-Soft gives an easily exploitable version of Qmail out standard

If someone has any answers that would be nice

Thanks

 

[atomicturtle]

Id say its an exploitable web application, a compromised smtp_auth account, or a poplock whitelist thats the culprit. I roughed out a forensic procedure here:

http://www.atomicorp.com/wiki/index.php/Spam

 

[egs2009]

Hi atomicturtle


Thanks for the post. Actually I checked the logs to see what a script send looks like and these are not scripts for sure.

My gut feeling since I'm not seeing logins from any unusual hosts or accounts is that this is a vulnerability in qmail itself.

How do I know if it is a whitelist that is causing this? The only whitelist is 127.0.0.1 and if I remove it Plesk says webmail won't work. What is a poplock?

Here is one of the bouncebacks that is worrysome:

Why would root uid 0 be sending these? I have checked for rootkits and incoming connections are completely locked down especially for SSH

Only important ports like FTP, SSH are open and SSH is restricted to just a few IPs
================
Hi. This is the qmail-send program at mail.xxxxxxxxxxxxxxx.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[email protected]>:
64.18.5.10 does not like recipient.
Remote host said: 550 No such user - psmtp
Giving up on 64.18.5.10.

--- Below this line is a copy of the message.

Return-Path: <[email protected]>
Received: (qmail 21794 invoked by uid 0); 17 Sep 2007 07:49:07 -0700
Date: 17 Sep 2007 07:49:07 -0700
Message-ID: <[email protected]>
From: [email protected]
To: [email protected]
MIME-Version: 1.0
Subject: Re: censored lol
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

 

[atomicturtle]

Close, but its not an exploit in qmail. Your server has most likely been compromised, this line:

Received: (qmail 21794 invoked by uid 0); 17 Sep 2007 07:49:07 -0700

Indicates that the message was sent by the root account.

 

[egs2009]

Hi atomicturtle

I'm not sure if it's an exploit actually.
In most cases I can often find that those messages sent by root are being sent in response to original messages sent to my server to non-existent accounts.

Or is there no valid reason for root ever sending an e-mail?

So far I haven't been blacklisted again.
The only person logged into the server is me and I've checked with the updated version of rkhunter.

Any idea what kind of compromise this would be and how to check/resolve it for sure ?

It would be nice to have peace of mind about this

Thanks so much atomicturtle

 

[atomicturtle]

Yeah if you follow the procedure outlined in the wiki above you can look at the source spam messages, rather than the bounce which is what you pasted. I think you'll find its either a bad password combo (like info/info, or web/admin) on smtp_auth (we call this a "joe" account), or its some exploitable web application.

As for the kinds of compromises... I'll use the perl motto "Theres more than one way to do it!". Start with the procedure I outlined in the wiki first, thats going to tell you where its coming from. Thats the first step in the investigation.