☰

Verhindern Sie, dass PHP-Skripte E-Mails senden

tag-icon • tag-icon postfix spam
Verhindern Sie, dass PHP-Skripte E-Mails senden

Meine Frage betrifft das Verhindern des Sendens von E-Mails durch PHP-Skripte. Sie wurde als Duplikat einer anderen, allgemeineren Frage zur Serversicherheit markiert, aber darum geht es in dieser Frage nicht.

Nach einem langen und erbitterten Kampf gegen Hacker-Spamversender, die irgendwie betrügerische, base64-kodierte PHP-Dateien in verschiedene Webverzeichnisse auf meinem Debian-/Apache-/PHP-Server einschleusen (der erbitterte Kampf umfasste zunächst das Patchen vorhandener Skripte und das Ändern von FTP-Passwörtern, Webdienst-Passwörtern und MySQL-Passwörtern, dann das völlige Neuaufbauen der Sites, die Installation von Maldet – was das Problem eingedämmt, aber nicht vollständig beseitigt hat – und schließlich das vollständige Deaktivieren von Postfix durch Stoppen des Dienstes (ohne es jedoch zu deinstallieren) sowie das Blockieren des Datenverkehrs über Port 25 vom Server an der Firewall), habe ich immer noch Probleme.

Meine Probleme verschwanden viele Monate lang und der Server wurde laut mxtoolbox automatisch von den Blacklists entfernt. Aber heute habe ich eine E-Mail von mxtoolbox erhalten, in der steht, dass mein Server wieder von vielen Diensten auf die Blacklist gesetzt wurde. Ich verstehe nicht ganz, wie das möglich ist, da ich den ausgehenden Datenverkehr über Port 25 deaktiviert habe.

Wenn ein Problem auftritt, füllt sich mein Postfix-Mailq mit Hunderttausenden von E-Mails von einem bestimmten Webbenutzer auf meinem Server.

Meine Fragen sind folgende:

  1. Da ich den Port 25-Verkehr deaktiviert habe mit iptables -A OUTPUT -p tcp --dport 25 -j REJECT,Wie ist es möglich, dass mxtoolbox meldet, dass mein Server immer noch Spam versendet?? Wenn ich Mailq überprüfe, werden die E-Mails gesichert. Wenn ich Postfix starte, werden Elemente in Mailq nicht wie erwartet gesendet, und ich sehe (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)neben jedem Eintrag.

  2. Nachdem ich den Standort des RAT anhand der X-PHP-Originating-ScriptZeile in einer Spam-Mail im Mailq ermittelt habe, kann ich die betreffende Datei finden und zerstören, wodurch das Problem für 5 Tage bis hin zu vielen Monaten gelöst wird.Wie verhindere ich vollständig, dass ein PHP-Skript E-Mails sendet?Wenn ich disable_functions = mailin meine php.ini-Datei eingebe, ist mir bewusst, dass dies die Verwendung interner Funktionen verhindert, nicht jedoch benutzerdefinierter Funktionen, die ein Spammer ausnutzen könnte.

  3. Was mache ich sonst noch falsch?

Vorbehalt: Ich weiß, dass Nr. 2 mein Problem nicht an der Wurzel löst, aber nachdem ich mir über die letzten Jahre Ratschläge zu Herzen genommen und die Sicherheit meines Servers auf so viele Arten wie möglich verbessert habe, arbeite ich nun eher daran, „das Problem mit der E-Mail-Reputation in den Griff zu bekommen“, als „alle Sicherheitsprobleme zu lösen, Punkt“.

Dies ist eine Fortsetzung meinerletzte verwandte Fragehier auf ServerFault.

Antwort1

Sie haben die Wahl

  1. Postfix entfernen
  2. Entfernen Sie php-mail (Ubuntu/Debian-Paketname)

Spammer können jedoch weiterhin ihren eigenen SMTP-Code schreiben.

Überprüfen Sie, ob SMTP tatsächlich auf diese Weise blockiert ist

telnet alt4.gmail-smtp-in.l.google.com 25

Antwort2

Die Firewall-Kontrolle für Port 25 ist immer noch die beste Option. Sie können dann alle gültigen Benutzer anweisen, E-Mails über authentifizierte Server wie Mandrill oder andere über SMTP (TCP/587) zu senden oder E-Mail-APIs von ESPs von Drittanbietern zu verwenden.

Sie können weiterhin PHP-Code schreiben, der über Sockets eine direkte Verbindung zu MX-Servern herstellt, sofern Sie nicht den Firewall-Ansatz verwenden.

Sie können TCP/25 auch auf ein Catch-All-System umleiten, damit Sie überwachen können, wer kompromittiert oder missbraucht wird.

verwandte Informationen