Loading
Loading

benutzerfreun.de

Infos für Website-Konzepter und Usability-Freunde

Website-Hacks abwehren für Dummies – Newsletter 8/2015

Wir alle bekommen Spam. Jeden Tag, nicht zu knapp. Es kostet Zeit, diese ganzen Werbeschreiben für Potenzmittel, Partyzelte, Versicherungen, Casinos, Gartenmöbel und Pornobildchen auszusortieren. Und Spaß macht das auch nicht.
Bei mir sind es jeden Tag zwischen 30 und 100 Mails, an schlimmen Tagen noch mehr. Daran hat man sich gewöhnt, das gehört dazu, wenn man eine Website betreibt.

Screenshot Phishing-Mail
So plump sehen Phishing-Mails immer seltener aus. Die Datei ist „sicher pdf“? Ja, dann öffnet man sie doch gerne…

Mich hat das kürzlich aber fast 10 Stunden gekostet – und viele, viele Nerven. Grund war nicht nur der Spam. Grund war auch eine Mischung aus schlechter Usability, schlechtem Support und Unwissen meinerseits.

Um Ihnen so eine Erfahrung zu ersparen, erzähle ich die kleine Geschichte, wie meine Site gehackt wurde.

1. Akt: Irgend etwas stimmt nicht

Die Geschichte begann langsam und unspektakulär. Beim Aussortieren der Spam-Mails fiel mir auf, dass immer mehr dabei waren, die wie ein Rückläufer vom Server aussahen.

Screenshot Mail-Rückläufer Spam
So fing alles an – mit solchen Mails, die ich angeblich verschickt habe.

Nach zwei, drei Tagen wurden diese Mails immer mehr. Irgendwann dämmerte mir, dass diese Mails anders waren als der übliche Spam: Es waren tatsächlich Rückläufer vom Server. Also Meldungen von fremden Mailservern, dass Nachrichten, die ich vermeintlich verschickt hatte, nicht zugestellt werden konnten. Und zwar aus dem Grund, weil es Spam-Mails waren. Diese wurden von der Mailadresse wordpress@benutzerfreun.de aus verschickt. Andere Menschen bekamen also Mails mit Links zu Porno-Sites mit meiner Mailadresse als Absender.

Ersteinmal kein Grund zur Panik. Denn der Hauptgrund dafür, warum es überhaupt so viel Spam gibt, ist, dass sich Absenderadressen sehr einfach fälschen lassen. Jeder, der Google bedienen kann und ein paar Stunden Zeit hat, kann das lernen. Und dagegen lässt sich systembedingt nichts tun. Um das zu verhindern, muss man die zugrundeliegende Technik der Mailserver ändern – was geplant ist, aber bis das endlich mal umgesetzt wird, müssen wir damit leben.

Wenn Sie irgendwo im Internet jemals eine Mailadresse veröffentlicht haben, dann wird wahrscheinlich auch Spam mit dieser Adresse als Absender verschickt. Wie gesagt, da können wir derzeit nichts gegen tun. Es gibt Automatismen, die sammeln wahllos Mailadressen aus dem Web und geben die an Spammer weiter. Als potenzielle Empfänger und als potenzielle Absender von Spam.

Und sogar, wenn Sie Ihre Adresse nicht veröffentlicht haben, sind Sie nicht sicher. So ist es in meinem Fall: Die Adresse wordpress@benutzerfreun.de gibt es gar nicht. wordpress@… ist eine Standardadresse, die WordPress für Nachrichten an Nutzer verwendet, wenn man keine andere angibt.

Ich hätte mich also zurücklehnen können und mir denken: “Tja, nicht schön, aber da kann man nichts machen.” Das habe ich auch getan. Für ein paar Stunden.

Irgendwann kam ich aber auf die folgenschwere Idee, das Thema weiterzuverfolgen. Was war, wenn die Mails doch von meinem Server kamen? Wenn mein WordPress hinter meinem Rücken Spam-Mails verschickt? Das ließ mir keine Ruhe.

Also habe ich mir die Mail-Logs meines Providers angesehen. Und bekam einen gewaltigen Schreck.

Screenshot Maillog mit Spam
Maillog-mit-Spam So sehen die Maillogs aus – wer nicht weiß, was das ist, der muss ganz schön rätseln.

Denn hier gab es einen Eintrag mit genau der Spam-Mail, die ich gerade bekommen hatte! Das war der Beweis, mein Server verschickt Spam!

Zu Ihrer Beruhigung: Die Mailadressen der Newsletter-Empfänger liegen nicht auf diesem Server. Selbst wenn die Site gehackt werden sollte, kann der im schlimmsten Fall genutzt werden, um darüber Mails an Adressen zu verschicken, welche der Hacker mitbringt. Die Empfängerlisten der Newsletter sind dort gar nicht vorhanden, können also auch nicht als Spam-Ziel genutzt werden.

2. Akt: Hektische Betriebsamkeit – der Website-Hack

Ich ging also zu meiner WordPress-Site. Das Sicherheits-PlugIn meldete: keine Gefahr! Alles OK.

Es war auf dem neuesten Stand, für ein anders PlugIn gab es ein Update. Dieses flugs installiert, das Sicherheits-PlugIn nochmal alles prüfen lassen – wieder Entwarnung.

Vielleicht war ich ja Opfer einer so neuen Schwachstelle, dass es für diese noch keine Lösung gab? Also nach den Symptomen gegoogelt. Unübersehbare Treffermengen. Das Problem, dass Spam vom eigenen Server verschickt wird, ist extrem weit verbreitet. Aber für meinen speziellen Fall war nichts dabei.

Also habe ich mir die Dateien auf dem Server angesehen. Hier konnte ich nichts Verdächtiges finden – alle Dateien, die dort waren, sollten da sein und die üblichen Verdächtigen, also php- und andere Skript-Files sahen in Ordnung aus.

Sicherheitshalber habe ich dann noch drei alternative Sicherheits-PlugIns für WordPress installiert. Die sahen auch sehr gut aus, ließen sich gut konfigurieren und – fanden beide ebenfalls nichts.

Bei der Webrecherche hatte ich eine vielversprechende Spur gefunden: PHP (die Skriptsprache, mit der WordPress läuft) kann Mails verschicken. Und wenn man das so einstellt, schreibt diese Funktion versteckt in die Mail, wo genau auf dem Server sie aufgerufen wurde.

Meine Idee also: Wenn ich diese Funktion aktivieren könnte, dann würden die nächsten Mails, die mein Server verschickt, mir verraten, welches Skript das veranlasst hat. Und damit hätte ich die Schwachstelle gefunden.

Also wandte ich mich an den E-Mail-Support meines Hosters – denn ich selbst habe keinen Zugriff auf diese Einstellung. Ein weiterer fataler Fehler.

Bisher war ich immer recht zufrieden mit diesem Anbieter, aber diesmal war ich an einen Supportmitarbeiter geraten, der immer nur mit ein, zwei Sätzen auf meine Fragen antworte. Ich hatte den Eindruck, mehr als fünfzehn Sekunden kann ihn die jeweilige Antwort nicht gekostet haben.

Nachdem da nichts voran ging, versuchte ich parallel, das Problem zu lösen.

Warum ist es dramatisch, wenn Sie Spam verschicken?

Der erste Grund ist ein moralischer: Sie sollten keinen Spam verschicken und auch nicht zulassen, dass Ihre Server dazu missbraucht werden.

Außerdem kann es Ihrer Reputation sehr schaden, wenn andere Spam-Mails von Ihnen bekommen. Das heißt, dass die Empfänger der Mails schlecht von ihnen denken. Aber auch die Mailserver. Denn es gibt Listen, auf denen Spam-Versender verzeichnet werden. Landen Sie einmal auf solch einer Liste, dann werden Sie sich schwer tun, überhaupt noch Mails zu verschicken.

Und schließlich können Sie auch juristisch belangt werden. Auch wenn Sie selbst gar keinen Spam verschicken, aber Ihre Site so schlecht absichern, dass andere darüber Spam verschicken.

Weiter mit den Lösungsversuchen

Ich begann also ein Großreinemachen auf dem Server. Sah in alle Verzeichnisse und in sehr, sehr viele Script-Dateien. Löschte alles, was nicht unbedingt nötig war. Kontrollierte Zugriffsrechte für Ordner und Dateien, machte Updates für alles, was sich updaten ließ.

Schließlich habe ich mich noch eingelesen ins die Details des Maliprotokolls. Eine sehr interessante Lektüre – ich habe zum Beispiel gelernt, dass man Mails erstellen kann, indem man mit einem Terminalprogramm direkt Textnachrichten mit einem Mailserver austauscht. Sozusagen ein Chat mit einem Server, der dann daraus eine E-Mail bastelt und auf den Weg schickt. Nicht, dass mir dieses Wissen irgendwie weitergeholfen hätte. Aber ich verstehe jetzt ganz gut, warum das System E-Mail so anfällig für Manipulationen ist.

Das alles dauerte Stunden, und alle paar Minuten sah ich ins Maillog. Alle zehn bis fünfzehn Minuten tauchte dort eine neue Spam-Mail auf. Meine ganzen Bemühungen waren umsonst.

Und schließlich stellte ich die Malifunktion von WordPress ab.

3. Akt: Auflösung & Katharsis

Meine Sicherheit wuchs: Auf meinem Server gab es kein Problem. Innerhalb von WordPress sicher nicht, das war relativ schnell klar. Und nachdem ich in jeden Winkel der Verzeichnisse gesehen hatte, war ich mir auch relativ sicher, dass es sonst nichts geben konnte, was in einem Bereich lag, zu dem ich selbst Zugang habe.

Auflösung brachte letztlich der zähe Mailverkehr mit dem Support. Gefühlt lief die Mail-Unterhaltung so ab (mit je ein paar Stunden Verzögerung dazwischen, bis die Antwort kam):

Ich: Von meinem Server bei Ihnen aus wird Spam verschickt. Können Sie mir die PHP-Funktion xy aktivieren, damit ich sehen kann, wo der herkommt?
Support: Sie haben keinen Zugriff auf diese Konfiguration.
Ich: Das weiß ich, können Sie mir die aktivieren?
Support: Nein.
Ich: Können Sie mir dann sagen, woher die Mails verschickt wurden?
Support: Das steht im Header.
Ich: Da haben Sie einen Header. Und?
Support: Die Mail kam vom Mailserver, der die Mail nicht zugestellt hat, weil sie Spam ist.
Ich: Ja, das ist ja das Problem! Wie kann ich es lösen?
Support: Gar nicht.
Ich: Sie könnten mich ruhig etwas unterstützen, wenn von einem Ihrer Server Spam verschickt wird!
Support: Die Mail wurde nicht von unserem Server verschickt.
Ich: Aber sehen Sie doch mal in das Mailprotokoll! Da ist alles voll von Spam-Mails, die über meine Server verschickt wurden!
Support: Da sind keine ausgehenden Spam-Mails drin.
Ich: ????
Support: Da sind keine ausgehenden Spam-Mails drin.
Ich: Nehmen wir mal die Zeile mit der Mail vom x.x.2015, x Uhr y, ist das ist keine Mail, die über meinen Server verschickt wurde?
Support: Das ist eine eingehende Mail.
Ich: Heißt das, dass mein Server keine Spam-Mails verschickt?
Support: Ja.

Screenshot Icon Maillog
Dieses Icon bedeutet keineswegs, dass diese Mail hinaus ging.

Nach 26 Stunden hatte ich also die Antwort, die man mir sofort hätte geben können: Die Icons im Mailprotokoll mit dem blauen Pfeil nach links heißen nicht, dass dies ausgehende Mails sind. Sie heißen vielmehr, dass danach die Angaben zum Server folgen, von dem eine eingehende Mail stammt.

Hätte ich also verstanden, wie das Mailpotokoll zu lesen ist, hätte ich gemerkt, was los war.

Nochmal das Geschehen in Kurzform für alle, die genauso lange brauchen wie ich:

  1. Ein Spammer hat festgestellt, dass benutzerfreun.de mit WordPress läuft.
  2. Er hat die Standard-Adresse wordpress@benutzerfreun.de als gefälschte Absenderadresse für seine Mailkampagnen eingesetzt.
  3. Diese Mails hat er von irgend einem Server aus (vermutlich von vielen gehackten Accounts aus) an eine Liste mit vermutlich Millionen von Empfängern verschickt.
  4. Die meisten dieser Mails werden von den Mailservern blockiert worden sein.
  5. Ein paar wenige Server meinten, den Absender informieren zu müssen, dass die Mails nicht ankommen, weil sie als Spam klassifiziert wurden.
  6. Nachdem als Absenderadresse der Spam-Mails meine Adresse genannt war, kamen diese Benachrichtigungen zu mir.

Das war der ganze Zauber. Ein alltäglicher Vorgang, leider. Aber wer es nicht weiß, und wer die kryptischen Icons seines Maliprotokolls falsch interpretiert, der kommt zu den falschen Schlüssen. Und denkt, er müsste bzw. könnte dagegen etwas tun.

Mein persönliches Fazit:
Nicht schlecht ist, dass ich jetzt einen blitzblank aufgeräumten Server habe. Und ein vertieftes Wissen um Mailprotokolle, Header und Serverdetails, was ich gar nicht zwingend haben wollte. Außerdem vier bestens laufende Sicherheits-PlugIns in meiner WordPress-Installation. Und ein mehrfach abgesichertes Wissen, wie man eine Site vor Hackerangriffen schützen kann.

Nachspiel 1: Checkliste für eine sichere Site

Von diesem Wissen sollen Sie profitieren, hier also meine gesammelten Empfehlungen für Ihren Server:

  1. Ein sicheres Passwort verwenden für den Ftp-Zugang und alle anderen Zugänge (wie zum CMS/Wordpress etc…) – für alle Nutzer. (Was ist ein sicheres Passwort? Mehr dazu im PDF Auf einen Kaffee mit… sicheren Passwörtern.)
  2. Aktuellste Software. Wenn Sie selbst irgendeine Software installiert haben (wie etwa WordPress, PlugIns o.Ä.), dann sorgen Sie dafür, dass sie immer auf dem aktuellsten Stand ist. Immer wieder werden Schwachstellen bekannt, welche meist schnell durch ein Update gesichert werden.
  3. Abgesichertes eigenes System. Über Ihren eigenen PC kann Schadsoftware auf Ihren Server kommen. Unter Windows ist ein Virenscanner Pflicht, unter Mac und Linux sollten die Firewall- und Sicherheitseinstellungen zumindest nicht von der standardmäßigen Stufe herabgesetzt werden.
  4. Sicherheits-Erweiterung für das CMS. Nutzen Sie WordPress, gibt es etliche sehr gute PlugIns, die das System deutlich sicherer machen. Wollen Sie das nicht oder gibt es für Ihr System nichts dergleichen, engagieren Sie einen Profi, der Ihren Server absichert.

Nachspiel 2: Was tun, wenn die Website gehackt wurde

Dass eine Site gehackt wird, kommt leider immer wieder vor. Mit Websites ist es nicht anders als mit Haustüren: Wer wirklich will, kommt überall rein, es ist alles eine Frage des richtigen Werkzeugs und des Aufwands.

Je attraktiver das Innen, desto besser sollten Sie es schützen. Aber wer eine heruntergekommene Hütte hat und die Haustüre offen stehen lässt, der ist auch vor bösen Buben nicht sicher.

Hatten Sie weniger Glück als ich und wurde Ihre Site tatsächlich gehackt, dann gehen Sie so vor:

  1. Ruhe bewahren. Löschen Sie nichts unüberlegt. Sie machen damit vielleicht alles nur noch schlimmer.
  2. Nehmen Sie sich in jedem Fall die Zeit, aktuelle Backups zu machen. Bringen Sie diese aber nicht durcheinander mit den älteren – denn in den aktuellen Backups steckt mit großer Sicherheit die Schadsoftware. Die aktuellen Backups sind wichtig, weil Sie im Zuge der Aufräumarbeiten einiges löschen werden. Oder weil Sie zurückgehen zu einer Vorversion Ihrer Site – alle neuen Inhalte sind dann verloren.
  3. Nehmen Sie Ihre Site offline. Verbreiten Sie Schadsoftware oder Spam, dann müssen Sie das stoppen. Aus Gründen der Moral, des Rechts und des Reputationsschutzes. Achten Sie auf den korrekten Status Ihres Servers, der muss 503 sein, was Suchmaschinen z.B. anzeigt, dass die Site nur vorübergehend offline ist.
  4. Informieren Sie Nutzer über Twitter, Facebook oder welche Kanäle Sie sonst nutzen, dass die Site für ein paar Stunden nicht erreichbar sein wird.
  5. Haben Sie Seiten identifiziert, die Schadcode enthalten, löschen Sie diese aus den Google Webmaster Tools. Das verhindert, dass diese Seiten als Treffer angezeigt werden.
  6. Finden Sie das Einfallstor. Das ist leichter gesagt als getan. Aber nur, wenn Sie wissen, wie die Hacker sich Zugang verschafft haben, können Sie das in Zukunft verhindern. Außerdem wissen Sie dann, wo Sie nach Schäden suchen müssen.
  7. Benachrichtigen Sie alle Betroffenen. Das ist Ihr Hoster, das sind andere, die ebenfalls Sites, Inhalte oder Services auf Ihrem Server laufen lassen. Und das können Personen sein, deren Daten kopiert, verändert oder gelöscht wurden.
  8. Beheben Sie den Schaden. Am besten, indem Sie ein Backup einspielen von einem Zeitpunkt, an dem nachweislich alles in Ordnung war.
  9. Ändern Sie alle Passwörter, Schlüssel und Ähnliches (wie die Salt-Schlüssel von WordPress).

Mehr Tipps für den Fall der Fälle finden Sie hier: My site’s been hacked – now what?
Und wo Sie schon dabei sind, sorgen Sie dafür, dass Ihre Passwörter sicher sind: Auf einen Kaffee mit… sicheren Passwörtern

Haben Sie noch schmerzhafte Erfahrungen gemacht in dem Bereich und etwas davon gelernt? Dann freue ich mich über Kommentare!

Zum Kommentar-Feld
Reaktion(en) (2)
Dieter Reggentin • vor4 Jahren

Vielen Dank für die ausführliche Darstellung Ihrer Erfahrung. Ähnliches widerfuhr mir vor einem Jahr (dabei war allerdings die komplette WordPress Installation wiederholt infiziert) - meine Sommerferien waren futsch. Zwei Fragen habe ich noch: 1. wer ist der Hoster mit dem netten Support? Und 2. von welchen Sicherheitsplugins reden Sie?

antworten
Jens Jacobsen • vor4 Jahren

Hallo Herr Reggentin, danke für den Kommentar. Der Hoster (mit dem ich bisher wie erwähnt recht zufrieden war, und vielleicht ist meine Erfahrung ja nur ein Einzelfall) ist Hetzner. Aber die UI seiner Website-Verwaltung ist definitiv überarbeitungswürdig. Als Sicherheitsplugins empfehlen kann ich:

Das vierte ist eher optional und als Zusatz-Schutz zu sehen, weil es die wichtige Funktion nicht mitbringt, den Login nach einer festgelegten Anzahl von Fehlversuchen zu sperren. Welches von den drei anderen man nimmt, ist Geschmacksache, für mich sehen die alle sehr gut aus.

antworten

Ich freue mich über Ihre Anmerkungen & Fragen.

By Daniele Zedda • 18 February

← PREV POST

By Daniele Zedda • 18 February

NEXT POST → 34
Share on