Internes

Und täglich grüßt das Murmeltier

Leute, ich bin es leid. Zum wiederholten Male ist das Bestatterweblog.de Ziel einer Malware-Attacke geworden. Ihr werdet es zum Teil selbst gesehen haben, immer wieder tauchen Casino-Beiträge auf.

Ich bin machtlos dagegen. Ich habe alles, aber wirklich alles versucht, um der Sache Herr zu werden. Aber letztlich hat nichts gefruchtet.

Ich möchte mich in aller Form bei Euch, meine lieben Leserinnen und Leser, dafür entschuldigen, dass hier immer wieder dieser Müll angezeigt wird. Es tut mir wirklich leid.

Werbung

Jede Maßnahme, die ich versuche, bringt für einige Tage, manchmal ein bis zwei Wochen Erfolg. Dann finden die Angreifer wieder neue Schlupflöcher und die Schei*e ist wieder da.
Ich hatte ja schon ein paar Mal davon berichtet und einige von Euch haben mir auch sehr gute Tipps gegeben, was man alles noch tun kann und was sie in solchen Fällen taten, täten oder tun.
Soweit praktikabel habe ich diese Ratschläge auch umgesetzt. Darüberhinaus habe ich einen Ar*ch voll Geld für Sicherheitssoftware ausgegeben.
Alle Plugins, die man sonst so kostenlos von der Stange bekommt, wurden durch eigens für das Bestatterweblog geschriebene, sichere Varianten ersetzt. Es wurde eine Zwei-Faktor-Verifizierung eingerichtet.
Die komplette Installation des Blogs auf dem Server wird rund um die Uhr von Monitoring-Programmen überwacht.
Unnötige Funktionen wurden (teilweise bis auf weiteres, teils auf Dauer) abgeschaltet. Deshalb gibt es bis auf weiteres auch keine Newsletter(-Funktionen) mehr.

Die Attacken sehe ich, wenn ich Glück habe, indem ich feststelle, dass in die WordPress-Installation fremde Files hochgeladen wurden. Diese heißen immer so ähnlich wie echte Dateien, sind aber stets ungewöhnlich groß.
Mittels eines Tools konnte ich feststellen, dass diese Files einen Filemanager enthalten, der es dem Angreifer erlaubt:

– beliebige Dateien hochzuladen
– direkt in die Datenbank zu schreiben
– sämtliche Veränderungen vor angemeldeten Usern/Admins zu verstecken
– nach Belieben neue Admins in WordPress anzulegen
– die Sicherheitssoftware einfach abzuschalten

Ich weiß nicht, was ich noch machen soll!

Die Folge ist immer ähnlich, aber nicht immer gleich. Für den Leser tauchen halt diese unsäglich blöden Casino-Beiträge auf.
Hinter den Kulissen sieht das immer wieder ein bisschen anders aus, jeweils angepasst an die hier ja immer schärfer werdenden Sicherheitsmaßnahmen.

Anfangs wurden Listen mit Tausenden von Casino-Beiträgen hochgeladen und mittels einer gefälschten Sitemap mit den echten Beiträgen verlinkt.
Dann wurden nur noch die Verlinkungen erzeugt, sodass alle Verweise vom Bestatterweblog auf solche Inhalte führten.
Mehrere Male wurden tatsächlich bis zu 20.000 Casino-Artikel in die Datenbank hochgeladen.

Backups helfen hier nur begrenzt, denn das Bestatterweblog schreibe ich jetzt schon 20 Jahre für Euch und es sind weit über 10.000 Artikel und über 150.000 Kommentare in der Datenbank. Das alles zu sichern, ist mit den üblichen Programmen wie Updraft & Co. kaum möglich, die brechen regelmäßig ab.
Geglückte Backups sind auch nur ein Glücksspiel, denn zwischen Infiltration und Ausführung des Angriffs liegen oft viele Tage und es ist ohne weiteres nicht herauszufinden, welches Backup man safe einspielen könnte.

Was bleibt: Ich muss händisch die gesamte WordPress-Installation durchgehen und Dateivergleiche anstellen. Das Gleiche gilt für Plugins und Themes. Dann muss ich ebenfalls händisch die bis zu 20.000 Dreckseinträge löschen.
An umfangreiche Datenbankoperationen, mit denen man das evtl. in einem Rutsch machen könnte, traue ich mich nicht ran. Mir ist das Risiko zu groß, das schöne Blog zu zerschießen.
Also nutze ich hierfür ein Delete-Plugin, mit dem ich aber immer nur maximal 400 Beiträge auf einmal löschen kann, was dann in eine „Syphillis-Arbeit“ ausartet.

Wenn irgendeiner von Euch noch irgendeine Idee hat…. Ich bin für jede Hilfe dankbar!

Euer
Peter

Bildquellen:
  • hamster: Peter Wilhelm KI


Ich habe noch einmal die wichtigsten Schlagwörter (Hashtags) dieses Artikels für Sie zusammengestellt, damit Sie sich besser orientieren können:

Schlagwörter: ,

Rubrik INTERNES

In dieser Rubrik finden Sie alles über interne Vorgänge und Sachverhalte dieses Weblogs. Das Bestatterweblog.de ist die größte Ratgeberplattform zum Thema Bestattung und Trauer und bringt darüberhinaus immer wieder unterhaltsame Geschichten.

Lesezeit ca.: 5 Minuten | Tippfehler melden | Peter Wilhelm: © 17. Juli 2024

Hilfeaufruf vom Bestatterweblog

Das Bestatterweblog leistet wertvolle journalistische Arbeit und bietet gute Unterhaltung. Heute bittet das Bestatterweblog um Ihre Hilfe. Es fehlen in diesem Jahr noch über € 7.500,- um den Server, IT, Redaktion und um die anderen Kosten zu decken. Bitte beschenken Sie uns mit einer Spende, sonst müssen wir in Zukunft die meisten Artikel kostenpflichtig bereitstellen. Das wäre schade, auch weil das weitere unkreative Arbeiten erfordert, die wir zeitlich kaum stemmen wollen. Vielen Dank!




Lesen Sie doch auch:


Abonnieren
Benachrichtige mich bei
14 Kommentare
Inline Feedbacks
Alle Kommentare anzeigen
Frank
5 Monate zuvor

Ohne Details ist es natürlich schwierig konkret zu helfen, ich weiß auch nicht, was meine Mitleser alles an Tipps gegeben haben, deshalb wird sich einiges sicher wiederholen: Du hast eine 13 Jahre alte jQuery Bibliothek eingebunden (1.7.2, aktuell ist 3.7.1), die Cross-Site Scripting Attacken ermöglicht. Das ist zwar nicht Ursache deines Problems, aber ich vermute, dass unter der Oberfläche noch weitere alte und potentiell angreifbare Software steckt. „eigens für das Bestatterweblog geschriebene, sichere Varianten“ von WordPress Plugins hört sich erstmal ganz toll an, ist aber nicht zwingend richtig. Wenn du Pech hast ist gerade eines dieser Plugins Einfallstor für Schadsoftware – nur bekommst du davon unter Umständen nichts mit. Denn während Sicherheitslücken in etablierten Plugins zwar massenhaft ausgenutzt werden, können sie dadurch eben auch schnell erkannt und geschlossen werden (=> an regelmäßige Updates denken!). Eine genaue Analyse der Log-Dateien kann Aufschluss darüber geben, wie die Angreifer ins System kommen (beispielsweise erfolgreiche Login-Versuche von ausländischen IP-Adressen.) Zwei-Faktor-Verifizierung für was? WordPress? Es gibt noch andere Einfallstore als nur das Blog selbst. Wie sieht es beispielsweise mit dem… Weiterlesen »

Frank
Reply to  Peter Wilhelm
5 Monate zuvor

Dedizierter Server ist schon mal gut, dann hast du sämtliche Freiheiten.

Maßnahmen die ich als erstes Durchführen würde:

SSH per Passwort verbieten und stattdessen die Verbindung per SSH-Key aufbauen

FTP komplett abschalten (Dateien Übertragung geht genauso gut und deutlich sicherer über SSH [zum Beispiel mit dem Tool WinSCP])

Starke Passwörter (und damit meine ich sowas: cjm3jw}+gtvHZHm{{NfE) für sämtliche Logins verwenden (Email, WordPress, Server, etc.)

Den Standardlogin unter /wp-admin/ bzw. /wp-login.php verstecken:
https://raidboxes.io/blog/security/hide-wordpress-admin/

Logins nur von bestimmten IP-Adressen erlauben (geht auch für IP-Bereiche, wenn du eine dynamische IP-Adresse hast)
https://www.netz-gaenger.de/blog/wordpress-tutorials/wordpress-login-nach-ip-adresse-erlauben-oder-sperren/

Frank
Reply to  Peter Wilhelm
5 Monate zuvor

Dynamische IPs sind immer etwas kompliziert und mit einem VPN Anbieter noch ein bisschen komplizierter. Außerdem: je größer der freigebende Adressbereich, desto größer auch wieder die Gefahr eines unautorisierten Zugriffs. Von daher ist eine feste IP schon sinnvoll.

In den Server Logs (je nach Serverkonfiguration beispielsweise unter /var/log/apache2/other_vhosts_access.log) wirst du wahrscheinlich zahlreiche Zugriffsversuche auf diverse weitverbreitete Login Seiten finden. Wenn beispielsweise beim Aufruf der Seite https://bestatterweblog.de/wp-login.php durch eine indische IP-Adresse der Rückgabewert 200 geliefert wird, dann ist das im Falle eines geleakten Passworts oder einer Wörterbuchattacke problematisch. Auf die selbe Art und Weise wird nach bekannten Schwachstellen in WordPress-Plugins gesucht oder Login Seiten für Plesk/webmail/ftp etc. auf gut Glück durchprobiert.

Mit einer festen IP kannst du Ports zu bestimmten Diensten (FTP, Email) und für bestimmte Seiten (login.php) für unbekannte IPs sperren. (beispielsweise mit iptables und .htaccess).

Carsten
Reply to  Peter Wilhelm
5 Monate zuvor

Hallo Peter,

von Frank hast du ja schon einige und gute Hinweise erhalten. Deshalb nur kurz zum Thema SSH Client unter Mac OS. Ich habe gute Erfahrungen mit Cyberduck (https://cyberduck.io/) gemacht.

Sieht etwas anders aus als WinSCP, hat aber die gleichen notwendigen Funktionen.

Carsten
Reply to  Peter Wilhelm
5 Monate zuvor

Ich weiß nicht, ob du da schon Unterstützung hast oder hier von der Fanbase bekommst, aber am Ende kann ich dir anbieten, das technische Setup gemeinsam mit dir genauer anzuschauen.

Du kennst mich nicht, da ich nur „stiller“ Leser deines Blogs bin und wir uns vor gefühlt 15 Jahren mal in Forchheim bei einer deiner Lesungen gesehen haben (ich habe noch das signierte Buch von dir 🙂 ), aber anbieten kann ich es mal. Natürlich nicht Vollzeit, aber mich als Leser nerven die falschen Postings ebenso und vielleicht kann ich meinen Beitrag dazu geben.

Sag einfach Bescheid und ich melde mich per Mail bei dir.

Frank
Reply to  Peter Wilhelm
5 Monate zuvor

Ach und das wichtigste fast vergessen, weil eigentlich selbstverständlich: Regelmäßige Sicherheitsupdates des Servers!

https://www.starline.de/magazin/technische-artikel/automatische-sicherheitsupdates-unter-linux-aktivieren

Christian
5 Monate zuvor

Frank und Carsten haben ja schon einige gute Hinweise gegeben – die Loganalyse ist ein guter Start, um rauszufinden, wie die Angreifer vorgehen.

Einen Punkt würde ich noch ergänzen: API-Zugriffe via xmlrpc.php. Falls Du die nicht brauchst, kannst Du z. B. per .htaccess den Zugriff darauf sperren. (Die Datei löschen hilft begrenzt – beim nächsten WordPress-Update wird sie wieder angelegt.)

Apropos WordPress-Update: Bitte automatische Updates aktivieren – die Angreifer nutzen neue Sicherheitslücken recht schnell aus.

Ansonsten bleibt noch die Option, WordPress komplett zu ersetzen. Statische Site-Generatoren wie Hugo oder Jekyll lösen die Sicherheitsprobleme sehr konsequent, weil nur noch fertige HTML-Dateien auf den Server (bzw. ins Document Root) kopiert werden. Allerdings haben die bauartbedingt 😉 keine Kommentarfunktion – die müsstest Du dann nachrüsten. Ich habe das noch nicht gebraucht, aber mit einer Google-Suche nach „Jekyll comments“ bzw. „Hugo comments“ müsstest Du weiterkommen.

Name
4 Monate zuvor

Mein erster Gedanke war, warum hat der User, unter dem das Blog läuft, eigentlich Schreibrechte am eigenen Code. Für einige wenige Verzeichnisse wie für hochgeladene Bilder, ok, aber doch nicht alles. Hier würde man einen zweiten vHost erstellen unter anderem User, und nur wenn das Blog über diesen vHost aufgerufen wird, darf der Admin z. B. Updates/Addons etc. installieren – aber nie da, wo der normale Besucher renkommt. Diesen Admin-vHost würde man dann z. B. nur von 127.0.0.1 erreichbar machen und man selbst greift dann über einen SSH-Tunnel zu. Mag auf den ersten Blick alles überwältigend klingen, ist aber sehr abgehangen.

Name
Reply to  Peter Wilhelm
4 Monate zuvor

Nö, so war das nicht gemeint – ich weiß durchaus, dass die gelebte Realität nicht dem Idealzustand nahekommt. Auch berufliche Kenntnisse sind kein Allheilmittel – je größer die Reichweite, je weiter oben im Ranking, desto härter wird angeklopft. Ich kann dir gern ein paar Anstöße/Stichwörter/Hinweise (ich will da nicht von vornherein zuviel versprechen) geben, ich betreibe beruflich IT-Infrastruktur auf Linux-Basis und habe immer auch einen Blick auf Sicherheit, Überprüfbarkeit, Wiederherstellbarkeit. Zumindest kann ich eine andere Sicht auf die Dinge liefern. Eine funktionierende EMail-Adresse ist hinterlassen, m. W. hattest du deine telefonische Erreichbarkeit ja aufgegeben.
Viele Grüße




Rechtliches


14
0
Was sind Deine Gedanken dazu? Kommentiere bittex