Damit WordPress von außen nicht oder nur schwer gehackt werden kann, gibt es ja so einige Tricks und Kniffe, um WordPress sicherer zu machen. Die Sicherheit geht vor, kaum ein Blogger dürfte daran interessiert sein seinen Blog den Hackern zum Fraß vorzuwerfen. Heute möchte ich mich dem Kapitel Datenbank Sicherheit widmen, denn auch hier können wir ein paar Dinge tun, um unseren WordPress Blog sicherer zu machen, ihn vor Angreifern zu schützen.
Gerade die WordPress Datenbank ist unser höchstes Gut, also sind die paar Tricks und Kniffe die es gibt, um die Sicherheit der Datenbank hochzusetzen, in meinen Augen ein absolutes Muss für jeden WordPress Blogger.
Der ein oder andere mag sich ja vielleicht denken, dass regelmäßige Backups schon genug des Guten ist. Nur bringt auch der beste Backup nicht sonderlich viel, wenn Hacker in die Datenbank schreiben und das erst sehr viel später bemerkt wird. Also sollte schon im Vorfeld für die Datenbank Sicherheit einiges getan werden.
Um unsere WordPress Datenbank sicherer zu machen greifen wir direkt an der Tabelle ein sowie am Admin User und seiner ID.
WordPress Tabelle
Schon bei der Neuinstallation eines Blogs empfiehlt es sich der WordPress Tabelle einen anderen Tabellen-Präfix als den Standard wp_ zu geben. Dazu muss der gewünschte table_prefix Eintrag in der wp-config.php bei der Neuinstallation einfach nur entsprechend eingetragen bzw. vom Standard weg geändert werden.
Wer das bei seiner Neuinstallation verpasst hat kann den WordPress Tabellen Präfix auch im Nachhinein ändern. Hierfür gibt es das Plugin WP Prefix Changer sowie auch die manuelle Anleitung von Frank Bueltge, die im Abschnitt Tabellen-Präfix seines Artikels WordPress sicherer machen zu finden ist.
WordPress Admin User
Auch der Standard WordPress User admin ist ein beliebtes Ziel von Hackern. Aus diesem Grund sollte schon von Anfang an ein anderer Name als admin für diesen User gewählt werden und so unterbunden werden, dass jemand anderer als der Administrator selbst, sich mit diesem Nutzernamen einloggen kann. Ein Hacker braucht hier zum Beispiel nur noch das Passwort herauszubekommen und schon hat er freien Zutritt auf den gesamten WordPress Blog.
Aber der User hat nicht nur einen Namen, sondern auch eine User ID. Viele ändern ja schon bei der Neuinstallation den Namen beziehungsweise legen einen neuen User mit Administrationsrechten an und löschen den Standard Admin User. Der erste User hat die ID 1 und der zweite User die ID 2. Findige Hacker nutzen nun also gerade diese beiden IDs, um sich Zutritt zum WordPress Blog zu verschaffen.
Eine User ID Änderung ist aber nicht ganz so einfach möglich, da bedarf es schon manuelles Hand anlegen an der Datenbank beziehungsweise das Plugin Search & Replace, welches in diesem Bereich aber auch mit Sorgfalt und Bedacht angewendet werden sollte.
Da die User ID an mehreren Stellen in der WordPress Datenbank benötigt wird, muss sie natürlich auch an diesen überall geändert werden. Die user_id betrifft die Tabellen _users, _usermeta, _posts, _comments und _links. Wer direkt an der Datenbank eingreift muss noch darauf achten, jeweils den richtigen Tabellen-Präfix zu verwenden. Nachfolgend der Code, den ich von Frank Bültges oben bereits erwähntem Beitrag habe. Ich verwende dabei den Beispiel-Tabellen-Präfix prefix und ändere die User-Id des Admins mit der User-ID 1 in die User-ID 4711. Dies soll natürlich nur als Beispielcode dienen und keinesfalls in gleicher Weise übernommen, sondern an die eigenen Einstellungen angepasst und mit einer neuen Wunsch-ID versehen werden:
UPDATE `prefix_users` SET `ID` = '4711' WHERE `prefix_users`.`ID` = 1;
UPDATE `prefix_usermeta` SET `user_id` = '4711' WHERE `prefix_usermeta`.`user_id` = 1;
UPDATE `prefix_posts` SET `post_author` = '4711' WHERE `prefix_posts`.`post_author` = 1;
UPDATE `prefix_links` SET `link_owner` = '4711' WHERE `prefix_links`.`link_owner` = 1;
UPDATE `prefix_comments` SET `user_id` = '4711' WHERE `prefix_comments`.`user_id` = 1;Vor jeder Änderung an der Datenbank sollte diese natürlich gesichert werden!
- WordPress sicherer machen – wp-config.php Sicherheitsschlüssel - Bei dem ein oder anderen Blogger liegt die Erstinstallation von WordPress ja schon eine Weile zurück und wer hat in der Zwischenzeit daran gedacht, die Sicherheitsschlüssel in der...
- Einträge in die wp-config.php um WordPress etwas schneller zu machen - Wie ja bereits vor Kurzem erwähnt, gibt es ein paar Konstanten, die man in die wp-config.php eintragen kann, um WordPress etwas schneller zu machen. Ein kleiner Aufwand, der...
- .htaccess Passwortschutz für wp-admin - Der ein oder andere von Euch, der sich das neue Feature der Google Webmastertools – Website Leistung – zu Gemüte geführt hat, mag sich vielleicht schon gefragt haben:...
- PHP Cache Script für einzelne WordPress Datenbank Abfragen - Ein einfaches PHP Script, welches den Cache für einzelne WordPress Datenbank Abfragen ermöglicht, und zudem manuell an diversen Stellen des Themes einzupflegen ist, stellt die Lösung zur Reduzierung...
- WordPress Blog auf eine neue Domain umziehen - Da ich genau das ja gerade erst für Michaela gemacht habe und mir der neue Artikel von Andreas ToDo Liste – Umzug eines WordPress Blogs auf eine neue...
- Anzahl der gesamten Beiträge und Kommentare aus der Datenbank auslesen - Um die Anzahl der gesamten Beiträge und/oder der Kommentare in seinem Blog anzuzeigen nutzt der ein oder andere WordPress Blogger ein Plugin. Da WordPress relativ einfach selbst an...
- WordPress 404 Seiten deaktivieren, auf die Startseite umleiten - In den WordPress Themes gibt es mit der Datei 404.php die Möglichkeit, individuelle 404 Seiten zu erstellen und diese beispielsweise mit einem Suchformular auszustatten. Ebenso gibt es einen...
- Robots Meta Plugin durch manuelle und erweiterte WordPress Funktionen ersetzen - Ein weiteres Plugin, welches bei mir nun nicht mehr zum Einsatz kommt ist das Robots Meta Plugin vom Pluginentwickler Joost de Valk. Stattdessen greife ich auf einfache manuelle...
Hallo Tanja,
vielen Dank für diesen Tipp!
Kleine Anmerkung, um den Code etwas zu vereinfachen:
Die Hochkommata um die ID, in deinem Beispiel ’4711′ werden hier nicht benötigt, da es sich hier um einen Integer-Wert handelt und dieser muss nicht wie bei char oder varchar beispielsweise in Hochkommata gesetzt werden, sonder kann direkt in die Datenbank geschrieben werden.
Viele Grüße!
Stefan
Danke für die Tipps. Das Tabellen-Präfix habe ich Gott sei Dank gleich von vornherein verändert – hat bei mir auch ohne Probleme geklappt.
Viele Grüße
Ah, ich hasse den Prefix Changer. Der benennt nicht alles um. Man darf anschließend immer wieder die Datenbank betreten, um die restlichen Stücken zu bereinigen
Als mir das das erste Mal passiert ist, bin ich fast in einen Schock gefallen. Aber mittlerweile hab ich mich eingespielt und kenne das Prozedere.
Aber wenns um Hacking geht, ist wordpress ziemlich anfällig, da hast du recht. Überall werden Benutzernamen etc. gespeichert. Ich hab z.B. meinen Admin umbenannt, dann aber die Admin-Comments mit Hilfe dem Benutzernamen hervorgehoben. Great, da war mein Benutzername wieder bekannt
Na glücklichweise gibt es dafür ja bereits andere Wege.
Nichtsdestotrotz surfe ich immernoch auf der 1 dahin
Ich finde es eigentlich so ganz gut, man weiß sofort seine ID, aber wie du sagst, dummerweise kennen auch die anderen diese
Haha, siehst du es geht allen beim ersten Mal so. Da kann man sich auch gleich mit der Datenbank auseinandersetzen.
Guter Artikel, so laufen meine Blogs seit eh und je, auch wegen dem Artikel auf cywhale.de, zwar wurde er lange nicht Aktualisiert aber, man kann den großteil noch übernehmen.
@Stefan: Oh… Danke… Ich bin froh wenn ich eigenes angepasste sql queries überhaupt zum laufen bringe. Das Ganze ist nicht so wirklich meine Welt
@Jasmina: Wenn wir selbst was tun können um das Ganze etwas sicherer zu machen, dann finde ich, dass wir das auch in die Hand nehmen sollten. Ist ja auch gar nicht so schwer
@Anne: So nen Prefix Changer habe ich noch nie benutzt. Ich ändere den Präfix ja immer gleich bei jeder Neuinstallation.
Admin-Kommentare hervorheben mache ich via CSS und PHP Abfrage. Die sollte eigentlich kein Mensch sehen können, oder?
@Noxed: Man tut was man kann um das Ganze etwas sicherer zu machen
Nein, sollte nicht, aber ich hatte für die php-Abfrage die user_ID verwandt und diese als Class wiedergeben lassen
PPPP Douchebag! Im Augenblick frage ich jetzt den userNamen ab, aber eigentlich sollte ich endlich mal komplett auf den neuen loop umstellen, dann bräuchte ich auch nicht mehr diese ganzen “Hacks”
Meine Prefixe muss ich allerdings alle nachträglich changen, da ich die WordPress-Installationen immer durch meinen Anbieter durchführen lasse. Aber ist ja auch kein Problem, mittlerweile geht es relativ fix, diese zu ändern. Aber das erste Mal bin ich wirklich mit den Nerven zusammengebrochen. Damals hatte ich solchen Respekt vor der Datenbank. Ich kann allen nur empfehlen, sich eine Datenbank auf dem Rechner oder noch besser in einem virtuellen System zu erstellen und dort mal richtig drin rumzuspielen. So lernt man am besten damit umzugehen.
@Anne: ups… schwerer Fehler
Ich fange den comment_author ab (in manchen Blogs auch die email Adresse) und nehme dann natürlich auch eine eigene Klasse, aber die benenne ich natürlich nicht nach der ID. Übrigens nutze ich überall auch den alten Loop, der gefällt mir für die diversen “Sparifankerl” die ich so veranstalte in meinen Themes, wesentlich besser.
Deine Empfehlung mit der Datenbank kann ich auch nur unterstützen. Mir ging es früher ähnlich und mittlerweile greife ich dort auch beherzt hin. Und wenn ich nicht weiß wie warum oder was, oder gerade ein Plugin am entwickeln bin… Testsystem
Nur “Schwerer Fehler?!” Ich hör Euch doch bis hierhin lachen
Ich würd sagen, damit hab ich nicht unbedingt viel Verstand bewiesen, besonders wo ich an anderer Stelle, meinen eh nicht oft besuchten Blog bis zum Umfallen schütze. Aber jede Burg hat nun mal ihre Schwachstelle. Meist nur nicht so offensichtlich! 
@Anne: Nö, ich lache nicht. Würde das eher unter “Künstlerpech” ablegen und das kann doch wirklich jedem passieren
Ich habe oft auch ziemlich quere Gedankengänge, so dass man vor lauter Detailblick das Wesentliche gerade nicht erkennt. “Den Wald vor lauter Bäumen nicht mehr sehen” oder so könnte man das doch auch nennen, oder?
Ja, genauso ist es. Aber ich wuenschte wirklich, ich koennte dem irgendwie entgegenwirken. Einmal einen Gedanken von Anfang an zu Ende gedacht und es wuerde mir soviel Aerger und Zeit ersparen. Gerade im Bereich WordPress, wo ich wirklich vorsichtiger sein sollte, weil ich nicht den Durchblick, um mir groessere Fehler zu erlauben, bin ich meist am oberflaechlichsten. Das macht mich schon irgendwie nachdenklich!
@Anne: Ich würde mal salopp sagen “thats live”… oder liege ich falsch damit? Die meisten Flüchtigkeitsfehler passieren uns doch gerade bei Dingen, bei denen wir uns wirklich sehr gut konzentrieren wollen…
Guter Artikel, werde ich mir zur Brust nehmen, wenn ich umstelle.
Macht es Sinn, zunächst auf der Testumgebung zu basteln?
(Bevor man sich alles zerschießt).
Feierabendgrüße
Erdbeere
@Erdbeere: Diese Datenbankänderung habe ich gleich live gemacht. Eine Datenbanksicherung vorher ist aber in jedem Fall Pflicht, so dass man für den Fall der Fälle auch schnell mal wieder zurück wechseln kann (hier gehts aber auch mit dem umdrehen der SQL Befehle).
Probleme kann es eigentlich nur geben wenn ein Plugin die User ID greift und damit was in die Datenbank schreibt. So was muss natürlich mit berücksichtigt werden.
Aber wenn Du Dich sicherer fühlst, dann nimm die Testumgebung. Für solche Dinge hat man sie ja auch
Danke liebe Tanja, entscheide mich erst einmal für die Sicherheitsvariante. Als Programmierer-Neuling, die bessere Wahl
Erdbeergruß am Montag
@Erdbeere: Wichtig ist, dass Du Dich dabei auch sicher fühlst