Link to home
Start Free TrialLog in
Avatar of mcj
mcj

asked on

qmail / Finding the source of spam email in the outbound queue

Our mail server is linux/plesk/qmail. Plesk (in theory) has already been configured to not permit relaying from unauthenticated users. However I'm still finding spam messages in the outbound queue.

The headers include:
Received: (qmail XXXX invoked by uid 48); 14 Nov 2010 19:31:27 -0600

and:
getent passwd 48
comes back with Apache as the user matching uid 48

So apparently the spam is getting in (in some way) via Apache/php

What I'm unclear on is if this indicates that a legitimate user's account username/password has been phished and is being used to send the spam, or if a vulnerability in Apache is letting some spam in and relaying it even though unauthenticated relaying has theoretically been disabled in the Plesk settings.

What's the next step to get a deeper level view of the specific account source of one specific message? Most of the messages have the header:

Received: (qmail XXXX invoked from network); 14 Nov 2010 19:31:27 -0600

and then also a line under that with a valid username and IP they sent from. But for these spam messages only showing "invoked by uid 48" I'm unclear if this is spam from:

1) a valid user account being checked and confirmed valid, but the account has been phished and is being abused
2) no local user account whatsoever, through some vulnerability in apache/php

I suspect it is 1) primarily since there has been a very consistently similar spam message being sent many many times. I would think a generally security flaw in the server would be being exploited by multiple spammers to send various radically different messages.

If it is 1) then how do I track the "higher level" actual local user account that is dropping the messages into uid 48/apache.

Obviously the first thing I did was to read through ALL the headers of numerous spam messages and there is no consistency after the
Received: (qmail XXXX invoked by uid 48); 14 Nov 2010 19:31:27 -0600
header line. At best there is one more header that seems to point to webmail.foodomain.com as the entry domain, but that doesn't help me understand which user on foodomain.com is the phised account being abused.
ASKER CERTIFIED SOLUTION
Avatar of TRW-Consulting
TRW-Consulting
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mcj
mcj

ASKER

"my guess is that you are hosting some type of website(s) that will send email responses for certain events, such as registering on a forum, requesting information, password resets, etc.  And that some rogue program is accessing these sites and triggering those events that cause the email to be sent."

"Also do you have any cron job by uid 48"

Well I'm actualy already clear that the entry point is apache/php. As I mentioned uid 48 comes back from getent as apache. What that *doesn't* tell me is if this is a legitimate user account (that has been perhaps phished) that is logging in through the web interface, or somehow there is a way to drop messages in with no user account at all.


"there should be additional information in your logs pointing to some IP address that can be traced back to it's origin."

I'm less concerned about the source IP of the machine sending the spam to my mail server than understanding the method they are using to get my server to accept their message. I'm unclear on why my server simply doesn't refuse the messages.

If I run qmHandle -R and see message 509845 which looks suspicious, then qmHandle -m509845 to read the contents and see it is spam, then how do I determine what (if any) user account was the one that logged on and sent that message? I've never needed to find anything like this before so I have no idea how it would be in the system logs or where to look.
Hi mcj first to identify if the hit on apache from an external factor is creating the mail or is that some backdoor program on your machine is generating the mail, put a iptables block from any one outside hitting apache for a fraction of time. If the mails still get generated then we need to hunt the backdoor..

regards