Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Since a few days, my web/mailserver (centos 6.4) is sending out spammails by the bunch, and only stopping the postfix service is putting an end to it.

SMPT is set up to only accept connections over ssl and using username/pwd. And I already changed the password of the (suspected) infected emailaccount.

Email was set up via iRedMail.

Any help on identify and stopping this is more then welcome!

ADDED: Some logs excerpts:

Mar 23 05:01:52 MyServer postfix/smtp[9494]: 4E81026038: to=<bet@magiccablepc.com>, relay=mail.suddenlinkmail.com[208.180.40.132]:25, delay=3, delays=0.07/0/2.4/0.5, dsn=2.0.0, status=sent (250 Message received: 20140323040153.YPML21660.txedge-vm03.suddenlink.net@MyServer.org)
Mar 23 05:02:01 MyServer postfix/smtp[9577]: 209BA26067: to=<gino.c@bigpond.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=14, delays=12/0/0/2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B654226078)
Mar 23 05:02:01 MyServer postfix/smtp[9495]: 8278726077: to=<harry@gunship.org>, relay=mx-biz.mail.am0.yahoodns.net[98.139.171.245]:25, delay=0.88, delays=0.25/0/0.47/0.14, dsn=4.7.1, status=deferred (host mx-biz.mail.am0.yahoodns.net[98.139.171.245] said: 421 4.7.1 [TS03] All messages from [IPADDRESS] will be permanently deferred; Retrying will NOT succeed. See http://postmaster.yahoo.com/421-ts03.html (in reply to MAIL FROM command))

A mailheader of an undeliverable report:

Return-Path: <MAILER-DAEMON>
Delivered-To: info@fotografieluna.be
Received: from localhost (icantinternet.org [127.0.0.1]) 
        by icantinternet.org (Postfix) with ESMTP id 4669E25D9D 
        for <info@fotografieluna.be>; Mon, 24 Mar 2014 14:20:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at icantinternet.org
X-Spam-Flag: YES
X-Spam-Score: 9.501
X-Spam-Level: *********
X-Spam-Status: Yes, score=9.501 tagged_above=2 required=6.2 
        tests=[BAYES_99=3.5, BAYES_999=0.2, RAZOR2_CF_RANGE_51_100=0.5, 
        RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RDNS_NONE=0.793,  
        URIBL_BLACK=1.7] autolearn=no
Received: from icantinternet.org ([127.0.0.1]) 
        by localhost (icantinternet.org [127.0.0.1]) (amavisd-new, port 10024) 
        with ESMTP id FOrkYnmugXGk for <info@fotografieluna.be>; 
        Mon, 24 Mar 2014 14:20:13 +0100 (CET)
Received: from spamfilter2.webreus.nl (unknown [46.235.46.231]) 
        by icantinternet.org (Postfix) with ESMTP id D15BA25D14 
        for <info@fotografieluna.be>; Mon, 24 Mar 2014 14:20:12 +0100 (CET)
Received: from spamfilter2.webreus.nl (localhost [127.0.0.1])  
        by spamfilter2.webreus.nl (Postfix) with ESMTP id 7FB2EE78EFF 
        for <info@fotografieluna.be>; Mon, 24 Mar 2014 14:20:13 +0100 (CET)
X-Virus-Scanned: by SpamTitan at webreus.nl
Received: from mx-in-2.webreus.nl (mx-in-2.webreus.nl [46.235.44.240]) 
        by spamfilter2.webreus.nl (Postfix) with ESMTP id 3D793E78E5A 
        for <info@fotografieluna.be>; Mon, 24 Mar 2014 14:20:09 +0100 (CET)
Received-SPF: None (mx-in-2.webreus.nl: no sender authenticity 
  information available from domain of 
  MAILER-DAEMON@athosian.udag.de) identity=pra; 
  client-ip=62.146.106.25; receiver=mx-in-2.webreus.nl; 
  envelope-from=""; x-sender="MAILER-DAEMON@athosian.udag.de"; 
  x-conformance=sidf_compatible
Received-SPF: None (mx-in-2.webreus.nl: no sender authenticity 
  information available from domain of 
  postmaster@athosian.udag.de) identity=mailfrom; 
  client-ip=62.146.106.25; receiver=mx-in-2.webreus.nl; 
  envelope-from=""; x-sender="postmaster@athosian.udag.de"; 
  x-conformance=sidf_compatible
Received-SPF: None (mx-in-2.webreus.nl: no sender authenticity 
  information available from domain of 
  postmaster@athosian.udag.de) identity=helo; 
  client-ip=62.146.106.25; receiver=mx-in-2.webreus.nl; 
  envelope-from=""; x-sender="postmaster@athosian.udag.de"; 
  x-conformance=sidf_compatible
Received: from athosian.udag.de ([62.146.106.25]) 
  by mx-in-2.webreus.nl with ESMTP; 24 Mar 2014 14:20:03 +0100
Received: by athosian.udag.de (Postfix) 
        id 3B16E54807C; Mon, 24 Mar 2014 14:19:59 +0100 (CET)
Date: Mon, 24 Mar 2014 14:19:59 +0100 (CET)
From: MAILER-DAEMON@athosian.udag.de (Mail Delivery System)
Subject: ***Spam*** Undelivered Mail Returned to Sender
To: info@fotografieluna.be
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;  
        boundary="36D9C5488E5.1395667199/athosian.udag.de"
Content-Transfer-Encoding: 7bit
Message-Id: <20140324131959.3B16E54807C@athosian.udag.de>
share|improve this question
    
Please add the relevant headers of one of the spam mails. That will generally be everything that starts with Received. –  Jenny D Mar 26 at 7:45
    
Thanks Jenny, some logging added. –  Borniet Mar 26 at 7:53
    
Thanks, but could you please add the headers from one of the spam emails? The logs show that your server is trying to send the spam, they don't show where it comes from. That is why the headers in the email are needed. –  Jenny D Mar 26 at 7:56
    
Added some mailheaders! –  Borniet Mar 26 at 8:04
1  
You don't need the outgoing headers. Just grep your log for (for instance) 4E81026038 and check out how postfix received it and by whom. –  Shadur Mar 26 at 11:43

2 Answers 2

up vote 3 down vote accepted

Pravin offers some good general points, but doesn't really elaborate on any of them and doesn't address your likely actual problems.

First, you need to find out how postfix is receiving those messages and why it's choosing to relay them (the two questions are very likely related).

The best way to do it is by looking at the message ID of any one of the messages and then grepping the mail.log file for all log entries regarding it. This will tell you at the very least where the message came from and what postfix did with it right up until it left its care and went on into the world. Here's a (redacted) sample excerpt:

Mar 26 00:51:13 vigil postfix/smtpd[9120]: 3B7085E038D: client=foo.bar.com[1.2.3.4]
Mar 26 00:51:13 vigil postfix/cleanup[9159]: 3B7085E038D: message-id=<------------@someserver>
Mar 26 00:51:13 vigil postfix/qmgr[5366]: 3B7085E038D: from=<foo@bar.com>, size=456346, nrcpt=2 (queue active)
Mar 26 00:51:13 vigil postfix/lmtp[9160]: 3B7085E038D: to=<fred@someplace.else>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.3, delays=0.11/0/0/0.19, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04611-19, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 6EA115E038F)
Mar 26 00:51:13 vigil postfix/qmgr[5366]: 3B7085E038D: removed

This tells me the following things:

  1. The message came in from foo.bar.com, a server with IP address 1.2.3.4 calling itself foo.bar.com
  2. (Implied by the lack of warnings) According to forward and reverse DNS, that address does indeed match that name.
  3. The message was meant for a user named fred@someplace.else, which the server decided was an acceptable destination address.
  4. As per its configuration, the mail server relayed the message through 127.0.0.1:10024 (our spam/virus filter) for further processing.
  5. The filter said "Okay, I'll queue this as message with ID 6EA115E038F and handle it from here."
  6. Having received this confirmation, the main server declared it was done and removed the original message from the queue.

Now, once you know how the message got into the system you can start finding out where the problem lies.

  • If it came from elsewhere and was relayed to somewhere else entirely, postfix is currently functioning as an open relay. This is very, very bad and you should tighten up your smtpd_recipient_restrictions and smtpd_client_restrictions settings in /etc/postfix/main.cf.

  • If it came in from localhost, it's very likely that one webhosting user or another has been compromised with a php script that sends out spam on demand. Use the find command to look for .php files that were recently added or altered, then take a good look at any suspicious names.

Anything more specific will depend too much on the outcome of the above investigation so it's pointless to attempt to elaborate. I will leave you with the more general admonishment to at the very least install and configure postgrey at earliest opportunity.

share|improve this answer
    
Thanks Shadur, you tips lead to the solution! It's somewhere inside one of the wordpress installations on my server. Still trying to figure out what/where exactly, but the mail-issue is solved, and the site is in quarantaine! So, Thanks! –  Borniet Mar 27 at 8:02
    
As a note, you can configure postfix to deny mail access to specific users. Assuming that your webhosting service setuids to each individual website's owner that would let you allow the site to remain running while still protecting your mail -- although whether you want to allow a known compromised site to remain running at all in the first place is a judgement call. –  Shadur Mar 27 at 13:30
1  
Thanks, that sure is a useful tip! However, in this particular issue, I'm opting to keep the site offline until it is proven clean! –  Borniet Mar 28 at 12:38
    
@borniet Best practice in any case. –  Shadur Mar 28 at 14:33
  • Make PHP send the mail through your local postfix installation and not directly out on the internet or through the web hosting host.

  • Please check any php script triggering mails.

  • Make the mail server send its HELO (EHLO) with its correct FQDN

  • Don't configure your server as Open Relay.

  • Implement DKIM signing of outgoing emails

  • Publish an SPF record for your domain that indicate that your server is a legitimate sender host for your domain

  • Add your server to DNSWL.ORG

share|improve this answer
    
Let's start with the beginning:Make PHP send the mail through your local postfix installation and not directly out on the internet or through the web hosting host. Please check any php script triggering mails. How do I do these? –  Borniet Mar 26 at 11:32
    
You can't do the former -- any php script is capable of specifying a server to use while sending email -- and the latter would involve a manual check of every php script on your server. –  Shadur Mar 26 at 11:42
    
@Shadur you could. Iptables allows matching based on the sending user. You can put in an ALLOW on the 'postfix' user to port 25, and then reject everything else. –  Patrick Mar 26 at 12:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.