Senden von E-Mails und Eingrenzen des Skripts

755
Michal Sapsa

Ich verwende einen sehr alten Ubuntu-Server, der vor einiger Zeit ein Mail-Server war, der infiziert war. Leider läuft auf diesem Server eine Webseite. Einige Skripte / Seiten / Malware versuchen, viel Spam zu senden - ich weiß, weil / var / spool / postfix / maildrop sich ziemlich schnell füllt.

Ich dachte, dass das Ändern von php5 / cli / php.ini sendmail_path in etwas ungültiges dies aufhört. Leider tut es nicht (ich habe Apache neu geladen). Der Server ist so alt, dass selbst Iotop nicht funktioniert. (Benötigen Kernel + Pakete Upgrade, was nicht passieren wird).

Gibt es eine Möglichkeit, das Hauptproblem hier einzugrenzen? Gibt es eine Möglichkeit zu überprüfen, welche Datei versucht, Spam zu senden, damit ich sie löschen kann?

0

2 Antworten auf die Frage

1
BillThor

Ich vermute, es ist nicht Ihr Mailserver, der infiziert ist. Möglicherweise läuft auf dem Server ein Spambot, der die E-Mail direkt sendet. Wenn der Spam nicht in Ihren E-Mail-Protokollen aufgezeichnet wird, ist dies wahrscheinlich der Fall.

Die folgenden IP-Tabellenregeln verhindern, dass Spambots und Programme, die als andere Benutzer-ID ausgeführt werden, E-Mails senden. 

iptables -A OUTPUT --dport 25 -m owner --uid-owner XX -j ACCEPT # Where XX is the UID of the Email server iptables -A OUTPUT --dport 25 -j LOG --log-level 6 --log-prefix "Outgoing SMTP blocked:" iptables -S OUTPUT --dport 25 -j DROP

Sie können einen Befehl netstat einige Male als root ausführen, um zu sehen, welche Programme Nachrichten senden. Ich würde einen Befehl verwenden, etwa wie:

netstat -antp | grep :25

Es ist wichtig, Ihre Distribution auf dem neuesten Stand zu halten. Mit LTS können Sie alle 2 Jahre ein Versionsupgrade durchführen. Der normale Veröffentlichungszyklus ist alle 6 Monate. Ein Paket wie dieses unattended-upgradeskann Aktualisierungen anwenden, sobald sie verfügbar sind.

Der einzige Prozess, der verwendet wird: 25 ist Apache2 Michal Sapsa vor 9 Jahren 0
Ich fügte hinzu, dass iptables -A OUTPUT -p tcp --dport 25 -j DROP und INPUT gleich sind. netstat ist nicht sauber, dennoch kann ich die Datei nicht finden, die versucht, diese Mails zu senden. Von -j LOG aus sehe ich, dass mein Server versucht, eine Verbindung zu anderen Servern an Port 25 herzustellen. Ich möchte die Datei erhalten, die dies tut Michal Sapsa vor 9 Jahren 0
@MichalSapsa apache2 sollte keine Verbindung zu: 25 herstellen, es sei denn, es wird eine Verbindung zu einem Mail-Relay hergestellt. Normalerweise handelt es sich um localhost (127.0.0.1:25), es könnte jedoch für einen anderen Host konfiguriert werden. Möglicherweise hat jemand ein Skript in einem der Verzeichnisse des Webservers abgelegt, das zum Versenden von Spam verwendet wird. Wenn möglich, fahren Sie den Webserver herunter, bis Sie ihn gefunden haben. Die Protokolleinträge sollten anzeigen, dass Sie den Spambot jetzt blockieren. Er muss jedoch noch identifiziert und entfernt werden. BillThor vor 9 Jahren 0
0
Michal Sapsa

Vielen Dank an @BillThor. Vielen Dank und einige ähnliche Fragen hier bei Superuser. Ich schaffe das:

1) Deaktivieren Sie den Eingang und Ausgang von Port 25 (SMTP).

iptables -A OUTPUT -p tcp --dport 25 -j DROP iptables -A OUTPUT -p tcp --dport 25 -j LOG --log-level 6 --log-prefix "SMTP BLOCK:" iptables -A INPUT -p tcp --dport 25 -j DROP

2) Deaktivieren Sie jeden Imap / Courier / Pop / SMTP-Dienst auf dem Server (es handelt sich um einen alten Mail-Server.

3) Ich lade maldetect herunter, was mir sofort problematische Dateien wie img23141243.php.jpg oder img1321312.php.gif zeigte

Nach dem Bereinigen dieses alten Webserverkontos gibt es keine Verbindung zu apache2: 25 anywere. Überwachte dies mit Hilfe der Protokollierung aller ausgehenden Aktivitäten auf Port 25 und mit

netstat -antp | grep :25

4) Leider hat LMD nicht alle Malware auf dem Server gefunden, aber ich habe den HowToForge-Artikel verwendet, um den sendmail-Befehl an ein externes Skript umzuleiten, das jeden Versuch zum Versenden von Mails protokolliert, wobei der Pfad zum Ordner der infizierten Datei protokolliert wird. Dank dessen fand ich sql.php, das infiziert war.

Verwandte Probleme