Die letzten Tagen war ich intensiv damit beschäftigt, etwaige Sicherheitslücken (in meinem Mailserver) ausfindig zu machen, denn mein System/der Mailserver wird wahrscheinlich missbraucht.
Hinweis: Dieser Beitrag richtet sich eher an technisch versierten Menschen, die sich (etwas) mit Linux, Server und Co. auskennen.
Seit einiger Zeit hält mich ein „Hacker” in Schacht, weil er Spammails in Form von Phishing versendet. Darin wird erläutert, dass eine Überprüfung des Bankkunden erforderlich sei und das in regelmäßigen Abständen nun geschehen wird.
Bisher nichts spektakuläres, richtig, jedoch wurde als Absenderadresse meine „Serverdomain” benutzt. Für die Haupt-IP-Adresse meines Servers habe ich eine Domain, die zeitgleich als Hostname greift und auch für den Mailserver als MX-Eintrag gilt. Nun hat man diese Domain als Absender der Phishing-Mails genutzt, sodass es für den Empfänger aussieht, als hätte ich die Emails versendet.
Darauf aufmerksam geworden bin ich, weil ich fortlaufend von irgendeiner arabischen Firma automatische Emails von deren Mailserver erhalten habe, dass die Email nicht angenommen wurde, weil entweder das Postfach nicht erreichbar war oder das Postfach gar nicht mehr existiert. Im Anhang war dann meine angeblich versendete Email.
Im ersten Moment war ich ratlos. Wieso versende „ich” (angeblich) solche Phishing-Emails und vor allem, wieso teilt mir ein arabischer Mailserver solche Fehlermeldungen mit. Im zweiten Moment war mir dann eigentlich ziemlich klar, dass hier Email-Spoofing betrieben wird. Jemand fälscht die Adresse des Absenders und gibt sich somit als jemand anders aus. Etwaige Fehlermeldungen werden dann logischerweise dem „Opfer” zugestellt, dessen Email-Adresse benutzt wird.
Daraufhin habe ich dann eingehende Emails von dem Mailserver blockiert und hab den Inhaber kontaktiert, dass mit seinem Server Blödsinn betrieben wird (bis dato noch keine Rückmeldung).
Auszug der mail.log: „Nov 4 14:39:52 xxxxxxxxxxxx postfix/smtpd[6519]: NOQUEUE: reject: RCPT from shaggy.sofcongroup.com[87.101.204.227]: 554 5.7.1 <shaggy.sofcongroup.com[87.101.204.227]>: Client host rejected: STOP SPAM; from=<> to=<xxxx@xxxxxxxxxxxx.xxx> proto=SMTP helo=<mail.sofcongroup.com>”
Im späteren Verlauf habe ich dann zusätzliche Emails (Rejects) von Mailservern wie GMX, WEB und Co. erhalten, weil der Empfänger nicht mehr existiert. In der Zwischenzeit habe ich auch mittlerweile Antworten auf die Phishing-Mails erhalten, dass ich doch ein Betrüger sei und Co. – ja, es antworten echt Menschen auf Phishing-Mails, hätte ich wirklich nie gedacht.
Mein Favorit: „Respekt. Rechtschreibfehler au Masse und noch einen OVH-Server nutzen? Na viel Spaß demnächst”
Ich hab mir dann auch mal die Mühe gemacht und auf allen menschlichen Antworten die Rückmeldung gegeben, dass ich es nicht war, Email-Spoofing betrieben wird und einfach nur der Absender gefälscht wurde. Vergleichbar mit, dass jemand ein Brief verfasst, als Absender einfach irgendeine andere Adresse auf dem Umschlag schreibt und abschickt.
So paranoid wie ich manchmal bin, wollte ich trotzdem zu einhundert Prozent selbst feststellen, dass nicht doch mein Mailserver übernommen wurde. Beispielsweise durch irgendein Script, der die PHP-Mail-Funktion nutzt. Daher hatte ich nun (php)sendmail verändert, sodass nicht nur in einem separaten Log angezeigt wird, wenn eine PHP-Mail versendet wurde, sondern auch automatisch in der Email-Header steht, welche PHP-Datei dafür verantwortlich ist.
PHP-Mail-Send-Log: „2016–11-02T23:46:59+0100 sendmail-wrapper called www-data from /home/www/domain.tld/”
Email-Header: „X‑PHP-Originating-Script: 0:mailtest.php”
Sollte also irgendein Script dafür verantwortlich sein, dass diese Emails verfasst wird, werde ich es mit dieser Methode auf jeden Fall herausfinden. Einen Open-Relay-Mailserver betreibe ich logischerweise nicht, sodass ich das ausschließen kann. Wie man so etwas nun einrichtet, zeige ich euch nun.
Unter „/usr/lib” gibt es die Datei namens „sendmail” und unter „/usr/local/bin” die Datei namens „phpsendmail”. Beide sollte man irgendwo als Backup abspeichern, alternativ am Ende ein Unterstrich und/oder ähnliches hinzufügen. Anschließend die Datei nochmal erstellen, folgendes einfügen und abspeichern:
#!/bin/sh
TODAY=‘date ‑Iseconds‘
echo $TODAY sendmail-wrapper called $USER from $PWD »/tmp/mail.send
(echo X‑Additional-Header: $(dirname $PWD);cat) | /usr/lib/sendmail-real „$@”
Hinweis: Ich beziehe mich hier auf einer Debian 8.5 Installation mit php5-fpm (nginx) und HHVM. Möglicherweise heißen die Dateien bei einem anders oder es existiert nur eine Datei. Mein Vorgehen ist so, dass im Log nicht nur der PHP-Mailversand von php5-fpm protokolliert wird, sondern auch der über HHVM.
Nachdem man das getan hat, wird der PHP-Mailer so (zusätzlich) eingesetzt, dass nicht nur der Versand eines PHP-Mails unter „/tmp/mail.send” protokolliert wurde, sondern in der versendete Email auch noch einen „X‑PHP-Originating-Script”-Hinweis gesetzt wird. Beides beinhaltet den Dateinamen, der für den PHP-Mailversand verantwortlich ist.
Möchte man dies irgendwann nicht mehr nutzen, kann die zwei Dateien einfach löschen und die alten, zuvor umbenannten Dateien wieder in den Originalnamen umbenennen (in meinem Fall einfach den Unterstrich am Ende entfernen).
Das war mir persönlich aber noch nicht genug, sodass ich noch auf das „maldetect”-Paket gestoßen bin. Dieses Paket überprüft vorhandene Dateien nach Malware und Co., auf Wunsch auch regelmäßig. Leider ist das Paket aber nicht direkt für Debian verfügbar, sodass man hier etwas tricksen muss.
Im Downloadbereich von uns findet ihr die Datei namens „malewaredetect.sh”, die man einfach nur downloaden und ausführen („./malewaredetect.sh”) muss. Das Script übernimmt alles andere wie das Herunterladen des Pakets, die richtige Installation und was sonst noch anfällt, damit das Paket auf Debian läuft.
Mit „/usr/local/maldetect/maldet ‑b ‑a /home/” kann man beispielsweise eine komplette Überprüfung des Home-Ordners starten. Den aktuellen Zustand und den Verlauf kann man mit „tailf /usr/local/maldetect/event_log” überprüfen.
Auch die Suche hat bei mir nichts ergeben, sodass ich nicht nur einhundert prozentig sicher bin, dass mein System sauber ist, sondern etwas mehr. Eigentlich war es mir schon von Anfang an klar, dass ich nicht der Übeltäter bin/sein kann, aber ein mulmiges Gefühl blieb mir trotzdem.
Zwar hat die Aktion mich nun viele Stunden gekostet, die ich in meiner Freizeit geopfert und nicht für den Blog benutzt habe, aber immerhin habe ich so schon mal vorgesorgt im Zweifelsfalle und dieser Beitrag ist sogar dadurch entstanden. Vielleicht ist dieser ja früher oder später für irgendjemand nützlich. Wer weiß.
