Meine Postfix-Installation sendet Spam. wie man es aufhält?

Seit einigen Tagen sendet mein Web- / Mailserver (Centos 6.4) Spam-Mails, und nur das Beenden des Postfix-Dienstes macht dem ein Ende.

SMPT ist so eingerichtet, dass nur Verbindungen über SSL und unter Verwendung von Benutzername / pwd akzeptiert werden. Und ich habe bereits das Passwort des (vermuteten) infizierten E-Mail-Kontos geändert.

E-Mail wurde über iRedMail eingerichtet.

Jede Hilfe, um dies zu identifizieren und zu stoppen, ist mehr als willkommen!

HINZUGEFÜGT: Einige Protokollauszüge:

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))

Ein Mailheader eines unzustellbaren Berichts:

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
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>

configuration postfix filter

— Borniet
quelle

Bitte fügen Sie die entsprechenden Header einer der Spam-Mails hinzu. Das wird im Allgemeinen alles sein, was damit beginnt Received.

— Jenny D

Vielen Dank, aber können Sie bitte die Header aus einer der Spam-E-Mails hinzufügen? Die Protokolle zeigen, dass Ihr Server versucht, den Spam zu senden. Sie zeigen nicht, woher er kommt. Deshalb werden die Header in der E-Mail benötigt.

— Jenny D

Einige Mailheader hinzugefügt!

— Borniet

Die von Ihnen angegebenen E-Mail-Header stammen aus einer Bounce-Nachricht und nicht aus einer Spam-Nachricht. Sie zeigen nur die Informationen des Systems an, das die E-Mail abgelehnt hat. Wir benötigen die Informationen aus einer der E-Mails, die von Ihrem System ausgehen, und nicht die, die darauf zurückkommen.

— Jenny D

Sie benötigen die ausgehenden Header nicht. Suchen Sie einfach in Ihrem Protokoll nach (zum Beispiel) 4E81026038und überprüfen Sie, wie und von wem postfix es erhalten hat.

— Shadur

Antworten:

Pravin bietet einige gute allgemeine Punkte, geht jedoch auf keinen von ihnen wirklich ein und geht nicht auf Ihre wahrscheinlichen tatsächlichen Probleme ein.

Zunächst müssen Sie herausfinden, wie Postfix diese Nachrichten empfängt und warum sie weitergeleitet werden (die beiden Fragen hängen sehr wahrscheinlich zusammen).

Der beste Weg, dies zu tun, besteht darin, die Nachrichten-ID einer der Nachrichten zu überprüfen und dann die mail.logDatei nach allen diesbezüglichen Protokolleinträgen zu durchsuchen . Dies wird Ihnen zumindest sagen, woher die Nachricht kam und was Postfix damit gemacht hat, bis es seine Pflege verlassen hat und in die Welt weitergegangen ist. Hier ist ein (redigierter) Beispielauszug:

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

Dies sagt mir Folgendes:

Die Nachricht kam von foo.bar.com, einem Server mit der IP-Adresse 1.2.3.4, der sich selbst foo.bar.com nennt
(Impliziert durch das Fehlen von Warnungen) Laut Vorwärts- und Rückwärts-DNS stimmt diese Adresse tatsächlich mit diesem Namen überein.
Die Nachricht war für einen benannten Benutzer gedacht fred@someplace.else, der vom Server als akzeptable Zieladresse eingestuft wurde.
Gemäß seiner Konfiguration hat der Mailserver die Nachricht 127.0.0.1:10024zur weiteren Verarbeitung über (unseren Spam- / Virenfilter) weitergeleitet.
Der Filter sagte: "Okay, ich werde dies als Nachricht mit der ID 6EA115E038F in die Warteschlange stellen und von hier aus verarbeiten."
Nachdem der Hauptserver diese Bestätigung erhalten hatte, erklärte er dies für erledigt und entfernte die ursprüngliche Nachricht aus der Warteschlange.

Sobald Sie wissen, wie die Nachricht in das System gelangt ist, können Sie herausfinden, wo das Problem liegt.

Wenn es von einem anderen Ort stammt und vollständig an einen anderen Ort weitergeleitet wurde, fungiert Postfix derzeit als offenes Relais. Dies ist sehr, sehr schlecht und Sie sollten Ihre smtpd_recipient_restrictionsund smtpd_client_restrictionsEinstellungen in verschärfen /etc/postfix/main.cf.
Wenn es von kam localhost, ist es sehr wahrscheinlich, dass der eine oder andere Webhosting-Benutzer mit einem PHP-Skript kompromittiert wurde, das bei Bedarf Spam versendet. Verwenden Sie den findBefehl, um nach .php-Dateien zu suchen, die kürzlich hinzugefügt oder geändert wurden, und überprüfen Sie dann alle verdächtigen Namen.

Alles, was spezifischer ist, hängt zu sehr vom Ergebnis der obigen Untersuchung ab, so dass es sinnlos ist, zu versuchen, dies näher zu erläutern. Ich überlasse Ihnen die allgemeinere Ermahnung, Postgrey zumindest zum frühestmöglichen Zeitpunkt zu installieren und zu konfigurieren .

— Shadur
quelle

Danke Shadur, deine Tipps führen zur Lösung! Es befindet sich irgendwo in einer der WordPress-Installationen auf meinem Server. Ich versuche immer noch herauszufinden, was / wo genau, aber das Mail-Problem ist gelöst und die Website befindet sich in Quarantäne! So danke!

— Borniet

Hinweis: Sie können Postfix so konfigurieren, dass bestimmten Benutzern der E-Mail-Zugriff verweigert wird. Unter der Annahme , dass Ihr Web - Hosting - Service setuids zu jedem Eigentümer individuellen Website, lassen würden Sie funktionieren die Website laufen zu bleiben , während noch Ihre E - Mails zu schützen - obwohl , ob Sie eine bekannte kompromittierten Website zulassen mögen , auf bleiben läuft alle in erster Linie ist ein Urteil Anruf.

— Shadur

Danke, das ist sicher ein nützlicher Tipp! In dieser speziellen Ausgabe entscheide ich mich jedoch dafür, die Website offline zu lassen, bis sie sich als sauber erwiesen hat!

— Borniet

@borniet Best Practice auf jeden Fall.

— Shadur

Lassen Sie PHP die E-Mails über Ihre lokale Postfix-Installation senden und nicht direkt im Internet oder über den Webhosting-Host.
Bitte überprüfen Sie alle PHP-Skript auslösenden Mails.
Lassen Sie den Mailserver sein HELO (EHLO) mit seinem korrekten FQDN senden
Konfigurieren Sie Ihren Server nicht als Open Relay.
Implementieren Sie die DKIM-Signatur ausgehender E-Mails
Veröffentlichen Sie einen SPF-Eintrag für Ihre Domain, der angibt, dass Ihr Server ein legitimer Absenderhost für Ihre Domain ist
Fügen Sie Ihren Server zu DNSWL.ORG hinzu

— pravin09
quelle

Beginnen wir mit dem Anfang: Lassen Sie PHP die E-Mails über Ihre lokale Postfix-Installation senden und nicht direkt im Internet oder über den Webhosting-Host. Bitte überprüfen Sie alle PHP-Skript auslösenden Mails. Wie mache ich das?

— Borniet

Ersteres ist nicht möglich - jedes PHP-Skript kann einen Server angeben, der beim Senden von E-Mails verwendet werden soll - und letzteres würde eine manuelle Überprüfung jedes PHP-Skripts auf Ihrem Server beinhalten.

— Shadur

@ Shadur du könntest. Iptables ermöglicht den Abgleich basierend auf dem sendenden Benutzer. Sie können einen ALLOW"Postfix" -Benutzer in Port 25 einfügen und dann alles andere ablehnen.

— Patrick