WordPress gehackt – was tun, eine Schnellhilfe

bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.

Kommentare

  
  1. ad sagt:

    Danke für den tollen Artikel. 🙂

    Was ist denn an der readme.html so schützenswert?

    • @Ad: die Version von WordPress, die steht auch dort und die will ich nicht via Plugin sichern, dazu bräuchte ich Schreibrechte und müsste die .htacces anfassen, was ich via Plugin ingern machen wollte.

  2. Dirk sagt:

    Man soll also NACH einem erfolgreichen Angriff die Datenbank sichern, das System neu aufsetzen, und die korrumpierte Datenbank wieder einspielen?

    • @Dirk: natürlich im Vorfeld bereinigen und die options weg lassen, daher ist für Anfänger das ExportFile von WP einfacher, dass hat nicht so viel drin und ist weniger Empfindlich beim Editieren - habe es etwas ergänzt, vielleicht versteht man mich so besser

  3. Frank, schnell reagiert und treffend zusammengefasst.

    Die Frage von Martin ist ebenfalls berechtigt. Ich wollte am Wochenende einen Beitrag schreiben und WordPress-Nutzern den Tipp geben, die readme.html vom Server entfernen (wie du schon richtig sagtest wegen der WP-Versionsnummer). Daher hatte ich heute Vormittag einen Scan durch deutsche Blogs gemacht und festgestellt, dass in 94 % der Blogs die readme frei zugänglich ist.

    Du warst jetzt aber zuerst mit dem Schutz der Datei in der .htaccess 😉 Ob sich mein Post noch lohnt?

    • @Sergej: jeder Post lohnt, weil die Leute es immer wieder vergessen - ich habe hier zig Beiträge zum Thema und immer wieder sind es die gleichen Probleme. Ich denk nur, dass das Löschen nicht viel bringt, da ein Autoupdate die Datei wieder bringt und dann vergessen es die Leute. In der DE Edition muss man ebenso noch die liesmich.html beachten, die hatte ich hier auch vergessen.

  4. Wichtig ist auch: Den eigenen Rechner überprüfen. Darüber kommen die Angreifer oft an die Passwörter. Außerdem sollte man auch die Passwörter sämtlicher E-Mail-Konten ändern, damit der Einbrecher ›sich‹ kein frisches zuschicken lassen kann.
    Oh, und auch Backups können verseucht sein, denn der eigentliche Angriff kann schon eine Weile zurückliegen.

    Unter Website gehackt – und nun? biete ich auch ein Notfallpaket an, das man während der Wartungsarbeiten ersatzweise anbieten sollte.

  5. Ich lösche alle 3: license.txt, liesmich.html und readme.html - auch bei jedem Update. In die .htaccess packe ich die Schutzmechanismen für diese Dateien nicht rein, da .htaccess ja bei jedem Server-Request (Bilder, HTML etc.) aufgerufen wird, da kann schon die Performance proportional zum Umfang der Datei leiden, weil dort sich auch noch andere Dinge befinden. Da ist mir manuelles Löschen lieber.

    Bleibt aber jedem einzelnen überlassen, wie er sich schützt. Hauptsache er macht es. Unsere Sache ist, ihm die Möglichkeiten und Gefahren aufzuzeigen 😉

  6. Mariusz sagt:

    Wunderbarer Artikel! Das mit dem .htaccess kannte ich zwar schon, aber hier wird natuerlich eine elegante/ausfuehrliche Moeglichkeit angeboten. Werde das gleich mal umsetzen und testen.

    Der Einwand von Dirk ist aber zutreffend. Man sollte eher in regelmaessigen Abstaenden ein Backup ziehen (empfehle WP Backup; schickt alles per Mail). Dann geht man auch sicher, keine korrumpierten Daten zu importieren.

  7. @Mariusz
    Das ist so nicht ganz richtig.
    Es gab schon Fälle, wo der Virus direkt in die Datenbank geschrieben wurde. Deswegen versuche ich mit meinem AV-Plugin auch die Datenbank-Inhalte auf komische Dinge zu überprüfen.

  8. Heiner sagt:

    @Mariusz
    Sorry, ich bin Einsteiger bei WP. Meinst Du mit "WP Backup" das Plugin WP DB Backup? Kann ich damit alles sichern? DB, WP, Plusins etc.? Und auch wieder leicht einspielen?
    Eignet sich das Plugin auch für die regelmäßige, also tägliche Datensicherung?

    • @Heiner: nein, ich meine klassisch eine Sicherung der Datenbank, wie auch immer man die erstellt. Das angesprochene Plugin eignet sich aber dafür, erstellt auch regelmäßig ein Backup. Es gibt einige dieser Plugins, da muss man einfach mal suchen und das entsprechende wählen.

  9. Heiner sagt:

    Ganz vergessen! Vielen Dank für diesen Aufschlussreichen Artikel!!!

  10. Merle sagt:

    Schöner Artikel!
    Das mit dem .htaccess kenne ich zwar schon, aber Du hast es noch etwas schöner gelöst. Besteht nicht die Möglichkeit die angreifende IP herauszufinden und den Inhaber/User dann anzuzeigen?

  11. Theresa sagt:

    Ich lösch sowieso alle unwichten Datein.

  12. dot tilde dot sagt:

    immer diese bösen hacker.

    .~.

  13. Wolfgang sagt:

    Was nutzt das Entfernen der readme.html wenn im Seitenquelltext so etwas steht:

    meta name="generator" content="WordPress 2.9.2"

    • @Wolfgang: dies ist klar und wird unter anderem durch mein Plugin Secure WordPress verhindert, steht aber schon ausführlich in den verlinkten Artikeln.

  14. Lothar sagt:

    Sehr informativer Artikel, habe ich mir direkt ausgedruckt! Ich bin selber Blogger, aber noch blutiger Anfänger (nicht was die Themen über die ich schreibe betrifft), mit WP kenne ich mich noch nicht besonders gut aus.

  15. Mariusz sagt:

    @Sergej: Stimmt, bevor man ueberhaupt ein Backup einspielt sollte man die DB pruefen. Dein Plugin benutze ich auch und kann es nur empfehlen.
    @Heiner: Im Grunde ist es egal wie man Sichert. Ich hatte mit diesem Plugin gute Erfahrungen - auch beim Backup einspielen. WP und Plugins muess(t)en dann noch manuell gesichert werden.

  16. Ich würde auch die WP Versionsnummer aus dem Head entfernen

  17. Zum ›Verstecken‹ der Versionsnummer und gleichwertigen Psst-Aktionen: Security by Obscurity ist kein Sicherheitskonzept. Wer in eine Website einbrechen will, der probiert sowieso alle bekannten Exploits aus, ob er die dahinter stehende Software nun kennt oder nicht.

    Ich beobachte beispielsweise täglich Versuche, in Typo3 oder phpBB einzubrechen, auch wenn diese System überhaupt nicht vorhanden sind.

    Der einzige Effekt der versteckten Versionsangabe ist ein falsches Sicherheitsgefühl. Naja, und man spart ein paar Bytes beim Transport. 🙂

    Also handelt das bitte nicht unter Sicherheitsmaßnahmen ab, sondern bestenfalls unter Performance.

    • @Thomas: im Grunde stimmt das, aber da man bei OSS auch die Scheunentore dokumentiert, kann es schon ein Faktor sein, denn damit erkennt man explizit die Version mit der jeweiligen Lücke, wobei ich hier eher von alten Versionen ausgehe, die soll es geben 😉

  18. @Frank: Angriffe erfolgen durch Scripte. Kein Mensch nimmt sich die Zeit, im Quellcode oder im HTTP-Header nach einer bestimmten Version zu suchen. Ein veraltetes System ohne Kennzeichnung wird nicht seltener angegriffen als eines mit der Angabe. Das ist Wunschdenken, und davor sollte man ebenso dringlich warnen wie vor den Angreifern selbst.

    Was ich von Updateschlampen halte, schreibe ich hier lieber nicht … 😉

  19. @Thomas
    Ich sehe das ebenfalls anders, denn:

    Es laufen zig Crawler im Netz, die einfach nur an die Versionsnummer der WP-Instanz kommen wollen. Ja, so einfach, die wollen nicht mehr wissen als nur die reine Zahl. Eigentlich könnten diese Skripte auch gleich etwas Böses im Blog einrichten (zumindest versuchen), aber das würde länger dauern (kostet Zeit, Performance, Identität) und die meisten Exploits benötigen mehr als nur einen Befehl auszuführen, um erfolgreich einen "Virus" einzusetzen und ihn gekonnt zu verstecken. Auch braucht man fürs Einscannen der Seiten keinen Proxy oder andere Tarnmachnismen, was die Indexierung der potentiellen Opfer sehr schnell und effektiv macht.

    Solche Nummern werden erst gesammelt, dann gezielt - abhängig vom Ranking einer Seite und der Version (bekannte Lücken) - massenweise, aber wahlweise auch manuell angegriffen und nach Möglichkeit infiziert. Ein weiterer Crawler läuft ein Tag später drüber und schaut, ob die Infektion erfolgreich war und gewollte Ergebnisse sichtbar sind. Ist ein Virus gesetzt, vom Prüf-Crawler auch so bestätigt und wird irgendwann später vom Blog-Admin erkannt und beseitigt (z.B. manuell aus dem Theme-Template restlos entfernt), so kriegt der Crawler es mit und versucht erneut die gleiche Lücke auszunutzen, weil die WP-Version konstant geblieben ist.

    Jetzt fragt nicht, woher ich es weiß 😉

    Aber es gibt solche und andere Arten von Robots, die einem WordPress-Blog was antun wollen. Auch wenn ich meine Installationen vor einem Prozent der Angreifer schützen kann, ist mir die Mühe mit der Tarnung der Versionsnummern wert. Als alleinige Methode sicherlich kaum etwas wert, aber als Bestandteil eines Sicherheitspakets eine solide und berechtigte Ergänzung.

  20. Jetzt fragt nicht, woher ich es weiß

    Muß ich aber. 🙂

    Ich lasse mich gerne überzeugen, aber ich zweifle noch sehr.

    Um es mal aus der Perspektive des Programmierers zu schildern (ich habe in den letzten Monaten einige Crawler/Grabber geschrieben): cURL ist schnell; Proxys sind billig.
    Vom Zeitaufwand her ist der Zwischenschritt einer Vorkontrolle fast immer zu teuer.

    Wenn er doch gerechtfertigt sein sollte, dann bringt das Entfernen der WP-Kennung alleine gar nichts: Die Plugins sind ja alle mehr oder minder sichtbar, und anhand deren Kennung kann man die laufende WP-Version sehr genau eingrenzen.

    Wer routinemäßig in WP einbricht, kann vollautomatisiert eine Liste der 50 beliebtesten Plugins von wordpress.org samt ihren technischen Bedingungen pflegen – die Angaben stehen in genormten Feldern. Der freut sich womöglich über Leute, die sich sicher wähnen, weil sie die Versionsnummer ausblenden.

    (P.S.: Diese Textarea ist zu flach.)

    • @Thomas: nutze den +-Button in den Quicktags oberhalb des Textarea, dann kannst du es vergrößern - reicht dir das, oder zu umständlich?

  21. @Frank: Sorry, habe ich glatt übersehen. Der ist hier nur zwei Millimeter breit. 🙂

  22. Thomas, ich gebe meine Stellung wieder, die ich mir aus Erfahrung und dem Lesen ausländischer Blogs bilde. Manchmal sind es Gründe, die in deinen, meinen Augen nicht als rational klingen, sind aber so wie die sind.

    Und ich sagte ja, es gibt solche und solche Bots. Jedes davon hat scheinbar seine Berechtigung am "Markt" zu sein, sonst wären sie nicht unterwegs gewesen. Unsere Aufgabe als Entwickler ist es nicht zu hinterfragen, was der effektivere Weg wäre in einen Blog einzubrechen, sondern wie man die existente Gefahr reduziert.

    Schließlich hast du ja die Versionsnummer ebenfalls aus dem Blog-Quelltext verbannt.

  23. @Frank: Opera 10.10 und 10.50 nehmen das padding von 1px sehr genau. Oh, der IE auch. Allein in Firefox, der für Inputs noch kein ordentliches Boxmodell besitzt, sieht es benutzbar aus. Bei mir habe ich diese Buttons zugunsten einer automagisch mitwachsenden Textarea entsorgt.

  24. @Sergej Ich zeige die Version nicht, weil die Ausgabe nur die Zeit meiner Besucher vergeudet.

    Hielte ich sie für sicherheitsrelevant, so würde ich sie keinesfalls verstecken, sondern hochmogeln. Denn nur so könnte man einen hypothetisch existierenden Bot zum Abdrehen bewegen, der sich nur an dieser Nummer orientiert. Aber einen so dummen Bot gibt es vermutlich nicht … 🙂

  25. Hatte ich oben etwa "...in den Augen klingeln..." geschrieben? Nee, Franks Blog ist definitiv gehackt 😉

    Thomas, hochmogeln und somit die Statistik über die weltweite WordPress-Verbreitung fälschen? Das geht aber wirklich nicht 😉

  26. Bernd Ludwig sagt:

    Ich habe den Strato SiteGuard eingeschaltet, also Loggin, Schreiben, FTP usw. gesperrt. Nutzt das was? Normal dürfte ja nun keiner mehr was verändern können, oder?

  27. JUICEDaniel sagt:

    Krasse Diskussion hier, ist ja auf höchstem Niveau - sehr spannend, danke 🙂

  28. seo|kai sagt:

    Wie ich in meinem Artikel zum Thema Crap Hats geschrieben habe, ist es manchmal sehr schwer überhaupt zu merken, ob ein WordPress gehackt worden ist!

    Ein Blick in die Google Webmaster Tools kann viel Aufklärung leisten! "Abruf wie Googlebot" oder ausgehende Links und vorkommende Keywords...

    Denn ein schlauer Crap Hat wird versuchen unentdeckt zu bleiben!

  29. Rene sagt:

    Der Horror blieb mir bislang hoffentlich erspart. Genau sagen kann ich das garnicht denn ein seltsamen fall hatte ich als ich mein blog auf 1blu.de webspace liegen hatte. Aber leider sperrte 1blu den Space sofort und kündigte mich dann fristlos womit bis heute ungekärt ist was es nun wirklich war 🙁 Ich weiss nur soviel das eine Datei aufgetaucht sein soll auf dem Space die aber nicht von mir kam. Kurz darauf gab es dann aber auch ein WP Update.

  30. Ramona sagt:

    Mit den Anweisungen # protect wp-config.php
    "
    Order deny,allow
    deny from all

    # protect install.php

    Order Allow, Deny
    Deny from all
    Satisfy all
    "
    sperre ich mich aus: Internal Server Error.
    Sorry für diese Frage, aber wie geht es denn dann?

    • @Ramona: nimm den Teil raus
      # PROTECT wp-login.php with password on .htpasswd
      <files wp-login.php>
      AuthName "Admin-Bereich"
      AuthType Basic
      AuthUserFile /www/htdocs/w0123123/.htpasswd
      require valid-user
      %lt;/files>

      der fragt eine passwort-Datei ab, sichert daher den Admin-Bereich komplett ab, was gut ist aber in Sachen Usability bewertet werden soll.

© 2016, since 2005 bueltge.de [by:ltge.de] · Theme is built by ThemeShift