Ähnliche Beiträge
- WordPress mehrsprachig nutzen - ein Lösungsvorschlag
- Einschränken der Daten-typen im WordPress Upload
- Trenne Logik von der Ausgabe, mittels Hooks in WordPress
- Optionen aus WordPress an JavaScripts übergeben #1
- WordPress, WPCron und die richtige Zeit
- XML zu Array mit PHP
Journal
- Trend. Meiner.
- WordPress mehrsprachig nutzen – ein Lösungsvorschlag
- Besser die Wahrheit?
- Einschränken der Daten-typen im WordPress Upload
- Trenne Logik von der Ausgabe, mittels Hooks in WordPress
Projekte
Abonniere die neusten Artikel via Sidebar
ein-/ausblenden
WordPress gehackt - was tun, eine Schnellhilfe
Anzeige
... die keinen Anspruch auf Vollständigkeit erhebt und mal eben dem einen oder anderen Leser dienen soll und getrieben aus gegebene Anlass. Das Hacken von Blogs ist keine Eigenart von WordPress Blogs - dies kann jedem CMS passieren. Ebenso kannst du dir nicht sicher sein, dass du nicht betroffen bist, nur weil du irgendein Plugin aktiv hast und weil du die aktuellste Version von WordPress fährst.
Wobei es hier keine Diskussion werden soll, ob WordPress mehr als andere Applikation betroffen ist oder anfälliger ist. Die Unterschiede sind weitreichend - Schwachstellen gehören zur Software und die meisten Standard-Tools sind nur für das Gewissen oder den Geldbeutel.
Es gibt verschiedene Erkennungsmerkmale, einige sollen helfen:
- Ein Problem nennt man Code Injection, Base 64 codierte Inhalte, meist PHP, in deine Dateien.
- Popups, Bilder, Frames, Links im Frontend
- Unbekannte Links im Source des Frontend
- HTML Code in den Tabelle
optionsvon WordPress - Rechte größer 644 sind ein Risiko und meist wollen viele Plugins 755
Folgende Links können helfen:
- WordPress sicher machen
- Sicherheit/WordPress absichern
- WordPress Templates sicherer machen
- WordPress Plugins für mehr Sicherheit
- sseq-lib (PHP security)
- 10 Schritte zum Schutz des Admin-Bereichs
- Schütze deine wp-config.php
- WordPress mit wenigen Kniffen vor Angriffen schützen
- Website gehackt – und nun?
Folgende Schritte sind anzuwenden, wenn das Blog gehackt wurde und man nur rudimentäre Kenntnisse in WordPress, PHP und mySQL hat. Alle mit dem nötigen Wissen werden gezielter vorgehen.
- Nutze die Export-Funktion von WordPress und sichere deine Inhalte damit
- Export der Datenbank-Inhalte und sichern
- Sichere die
wp-config.php - Sicherung des Ordners
wp-contentmit allen Inhalten - Prüfe die
wp-config.phpauf korrekten Inhalt und die Rechte auf dem Webspace, 644 reicht aus - Prüfe die Inhalte des Ordners
wp-content- plugins, themes, uploads - auf richtige Inhalte - Ändere alle Passwörter: WP Backend (besser neuen User anlegen und Inhalte übernehmen, so ändert sich die ID), FTP Zugang (Achte auf starke Passwörter)
- Ist die Datenbank das Problem, dann gilt es jede Tabelle zu überprüfen, insbesondere die Tabelle
options, beschränke dich vorerst auf die WP Standard-Tabellen - Installiere WordPress neu, mit einer neuen Datenbank
- Kopiere die Sicherung des gesäuberten Ordners
wp-contentauf die Neuinstallation - Importiere die Inhalte des bereinigten, falls nötig, WordPress Export-Files und hole so die Inhalte wieder rein (macht das Probleme, dann muss dies via dem SQL Export geschehen, welches du aber ohne die Tabelle
optionsimportieren solltest und bereinige auch dieses File - Überprüfe das Blog mit diversen Tools, nutze die Möglichkeiten, die die obige Artikel aufzeigen und nutze die Macht der
.htaccessund der RechtevergabeBeispiele der Sicherung in der
.htaccess# PROTECT wp-config.php <files wp-config.php> Order deny,allow deny from all </files> # 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 </files> # PROTECT readme.html <Files readme.html> Order Allow,Deny Deny from all Satisfy all </Files> # PROTECT liesmich.html für DE Edition <Files liesmich.html> Order Allow,Deny Deny from all Satisfy all </Files> # PROTECT install.php <Files install.php> Order Allow,Deny Deny from all Satisfy all </Files>
40 Kommentare zu „WordPress gehackt - was tun, eine Schnellhilfe“
Kommentar schreiben
Kommentar-Hilfe
händischer Spam:
Beachte die Kommentarregeln, jede Form von versuchtem Spam wird gelöscht. Warum und wieso steht in einem meiner Beiträge.
Bezug auf Textstellen:
Du kannst direkt bezug auf Textstellen im Beitrag nehmen. Dazu muss lediglich der Bereich im Artikel markiert werden; daraufhin erscheint ein Button, der den markierten Text in das Kommentarfeld übernimmt und als Zitat auszeichnet. Die Funktion ist nur bei aktivem JavaScript nutzbar.
xHTML:
Du kannst folgende Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <pre> <em> <strong> <strike> <ul> <ul> <li>
Achte darauf, wenn du Code im Kommentar hinterlegen willst, dann muss der Code maskiert sein. Dann wird er nicht interpretiert. Der Code muss mit Hilfe von HTML-Entities dargestellt werden, d.h. dass man z.B. < als < und > als > einfügt.
E-Mail-Benachrichtigung bei neuen Kommentaren ?
Wenn der Haken in der Checkbox gesetzt ist, dann wirst du über neue Kommentare vie E-Mail informiert. Der Versand erfolgt nur, wenn du die URL in der Bestätigungs-E-Mail genutzt hast oder schon Abonnent hier im Blog bist.
Kommentar erscheint nicht:
Alle Kommentare werden manuell geprüft, freigegeben und nach Möglichkeit beantwortet. Bitte um etwas Geduld und Nachsicht.
Identifikationsbilder (Avatare):
Auf Gravatar.com kann man sich mit seiner E-Mail-Adresse registrieren und ein Bild hochladen, dann erscheint dieses Gravatar hier und in vielen weiteren Blogs.
Spamschutz:
Das Kommentarformular ist mit einem Spamschutz ausgerüstet. Solltest du diesen Artikel ohne JavaScript besuchen und kommentieren wollen, so muss du die Frage beantworten und das jeweilige Wort in das Textfeld eingeben.
Das Weblog wird angetrieben von
16. April 2010 um 21:24
Danke für den tollen Artikel.
Was ist denn an der readme.html so schützenswert?
16. April 2010 um 21:30
@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.
16. April 2010 um 22:25
Man soll also NACH einem erfolgreichen Angriff die Datenbank sichern, das System neu aufsetzen, und die korrumpierte Datenbank wieder einspielen?
16. April 2010 um 23:09
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?
16. April 2010 um 23:28
@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
16. April 2010 um 23:30
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.
16. April 2010 um 23:30
@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.
16. April 2010 um 23:37
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
17. April 2010 um 03:41
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.
17. April 2010 um 09:26
@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.
17. April 2010 um 19:08
@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?
17. April 2010 um 19:09
Ganz vergessen! Vielen Dank für diesen Aufschlussreichen Artikel!!!
17. April 2010 um 22:12
@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.
17. April 2010 um 22:26
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?
18. April 2010 um 13:24
Ich lösch sowieso alle unwichten Datein.
18. April 2010 um 16:35
immer diese bösen hacker.
.~.
18. April 2010 um 17:18
Was nutzt das Entfernen der readme.html wenn im Seitenquelltext so etwas steht:
meta name="generator" content="WordPress 2.9.2"
18. April 2010 um 20:13
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.
19. April 2010 um 11:59
@Wolfgang: dies ist klar und wird unter anderem durch mein Plugin Secure WordPress verhindert, steht aber schon ausführlich in den verlinkten Artikeln.
19. April 2010 um 16:07
@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.
19. April 2010 um 17:24
Ich würde auch die WP Versionsnummer aus dem Head entfernen
19. April 2010 um 21:09
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.
19. April 2010 um 21:20
@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
19. April 2010 um 21:28
@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. April 2010 um 21:47
@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. April 2010 um 10:39
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.)
20. April 2010 um 11:27
@Thomas: nutze den +-Button in den Quicktags oberhalb des Textarea, dann kannst du es vergrößern - reicht dir das, oder zu umständlich?
20. April 2010 um 11:39
@Frank: Sorry, habe ich glatt übersehen. Der ist hier nur zwei Millimeter breit.
20. April 2010 um 11:40
nur 2mm - System und Browser? auch wenn ich ungern fixe, ich will seit min. einem Jahr einen Relaunch, aber keine zeit
20. April 2010 um 11:46
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.
20. April 2010 um 11:57
@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.
20. April 2010 um 14:44
@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 … :)
20. April 2010 um 15:34
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
20. April 2010 um 15:45
Zum Glück bin ich ja immer oben
23. April 2010 um 12:39
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?
28. April 2010 um 22:08
Krasse Diskussion hier, ist ja auf höchstem Niveau - sehr spannend, danke
17. Mai 2010 um 14:09
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!
22. Juni 2010 um 14:48
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.
28. September 2010 um 13:58
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?
29. September 2010 um 14:51
@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.