Das WordPress Plugin „contact-form-7“ offenbarte eine schwere Sicherheitslücke. Nicht schlimm, dachte ich. Schließlich benutze ich das Plugin nirgends. In meinen aktiven Blogs befindet es sich auch nicht unter den deaktivierten Plugins.
Heute erhielt ich Post von meinem Provider, der mich darauf hinwies, dass ich bei zwei Domains mal nach dem Rechten schauen sollte. Es seien dort Sicherheitslücken aufgetreten. Beide Domains hatte ich schon vor ein paar Jahren „stillgelegt“ bzw. deaktiviert. Normalerweise mache ich es so, dass ich die kompletten Dateien und die Datenbanken für die Domains lösche, wenn ich sie nicht mehr nutze. Jedenfalls nach einer gewissen Zeit, wenn es sich erwiesen hatte, dass ich sie nicht fortführen wollte.
In diesem Fall habe ich das nicht getan, sondern die URLs lediglich deaktiviert. Mir war nicht klar, dass dieses Vorgehen Hackern über existierende Sicherheitslücken trotz einer auf Serverebene vorgenommenen Deaktivierung weiterhin ein Angriffsziel bieten.
Heute habe ich die Löschungen vorgenommen und bin damit – hoffentlich – sicher vor solchen unliebsamen Überraschungen.
Vor einigen Jahren hatte ich in einem meiner Blogs einen Malwarebefall, der mich dazu veranlasste, diesen Blog komplett zu löschen und ein Backup einzuspielen.
Weil ich einmal dabei war, habe ich die „Pflege“ fortgeführt und folgende Domains gelöscht:
- hs23.de
- webshrek.de
- the60.de
- pos1tiv.de
- reiztext.de
- sensibussi.de
- watschblog.de
- blogkonzil.de
Ein paar andere habe ich behalten – aus alter Anhänglichkeit. Nicht deshalb, weil ich sie wieder zu reaktivieren gedenke.
Das wären:
- 2Bier.de
- Netzexil.de
Auf die Idee Domains über diesen Punkt im KAS zu deaktivieren bin ich noch gar nicht gekommen. Ich habe bei meinen 4 nicht benutzen Domains Weiterleitungen drin.
Dass es diese Möglichkeit im Kas gibt, darauf bin ich erst vielleicht vor ca. einem Jahr gestoßen. Vorher habe ich das entweder mit Umleitung gemacht oder ich habe den Blog gelöscht. Komisch, dass Hacker an Plugins rankommen, die auf einer „unerreichbaren“ Seite rumhängen. Finde ich.
Ich habe meine alten Domains längst ebenfalls ‚gelöscht‘. Ich hatte sie aber zuvor schon ‚entleert‘, indem ich lediglich eine schlichte weiße index-html im Verzeichnis gelassen habe.
Warum den alten Ballast mitschleppen? (Die eine von meinen drei ehemaligen Domains führt heute zu einer Server-Fehlermeldung irgendeines Providers, die andere – dyingeyes. – beherbergt heute irgendwelchen Online-Casino-Rotz und die dritte, die älteste von damals verweist überraschenderweise auf genau diesen Online-Casino-Rotz.
Aber es gibt wohl tatsächlich zig Millionen toter, veralteter Blogs da draußen, und viele von denen lassen sich wahrscheinlich wunderbar (bzw. deren Server) in kriminelle Botnetze einbinden – oder sie sind es längst…
Deswegen: Wenn man eine Domain unbedingt behalten will, dann alles vom Server räumen bis auf eine leere index.html.
Das waren Seiten, von denen ich nicht sicher war, ob ich sie später nochmal weiterführe. Wie gesagt, jetzt ist alles sauber. Aber wie kommen Hacker auf ein Plugin, das theoretisch doch gar nicht erreichbar ist? Dazu muss ich mal bei Allinkl nachfragen.
Nochmal zusammengefasst. Du hast eine WordPress Installation auf die eine Domain zeigt. Die Domain hast du wie oben beschrieben deaktiviert. Das soll für Hackerangriffe gut sein – unglaublich!!!
Ich glaube, das war ein Missverständnis. Dass die Deaktivierung gegen Hackerangriffe wirkt, hatte ich nur gedacht bzw. erwartet. Dass das trotzdem ein Ziel für Hacker sein kann, hat die Erfahrung ja nun gezeigt. Ich hätte halt die Daten löschen müssen oder – alternativ – die Themes und Plugins aktuell halten müssen, obwohl die Blogs gar nicht mehr aktiv waren.
Ich bin da jetzt auch kein Fachmann, aber die Verzeichnisse auf dem Server existierten ja noch. Und darin die Dateien der Wordpress-Installation. Also sind diese auch für Hacker zugänglich. Die gehen ja nicht unbedingt über die via DNS vermittelte Domain-Adresse (also http://…) auf die Server los.
Wie gesagt, der einzige sichere Schutz ist das Löschen aller kompromittierbaren Dateien im Serververzeichnis für die jeweilige Domain und am besten auch der zugehörigen Datenbank.
Wahrscheinlich hast du recht. Jetzt ist alles sauber/gelöscht.