![\"WP](\"https:\/\/bueltge.de\/wordpress-buch\/files\/2007\/07\/wordpress-login-1281.png\")
<\/p>\n<\/p>\n
Ein Thema, welches ich im Buch leider vernachl\u00e4ssigt habe, ist das Thema Sicherheit. Dieses Thema ist aber immer relevanter, gerade weil WordPress immer popul\u00e4rer wird und damit auch immer interessanter f\u00fcr Hacker und Andere, die sich unbefugt Zutritt zu einer Web-Applikationen geben wollen.<\/p>\n
Nicht zuletzt ist der Artikel also eine Aufforderung vieler Leser, die mir per E-Mail oder Online-Rezension, einen Hinweis darauf hinterlassen habe und denen ich mit diesem Artikel ein wenig helfen m\u00f6chte, ihre WordPress-Installation sicherer zu machen.<\/p>\n
Kurz & Knapp – so werde ich also im folgenden einige Tipps f\u00fcr ein sicheres Weblog mit WordPress geben.<\/p>\n
Sicherheit – einen Zustand, der frei von unvertretbaren Risiken der Beeintr\u00e4chtigung ist oder als gefahrenfrei angesehen wird.<\/p><\/blockquote>\n
Wikipedia<\/a><\/cite><\/p>\n
Aber Achtung, damit will und kann ich nicht die Eigenverantwortung des jeweiligen Administrators herabsetzen oder abnehmen. Das Thema wird immer wieder pr\u00e4sent sein und die Sicherheitsregeln werden sich \u00e4ndern. Nichtsdestotrotz kann man mit einigen wenigen Schritten die Installation recht sicher gestallten.<\/p>\n
\n
- \n
User-Name<\/h3>\n
Nach jeder Installation ist der Standard-User-Name des Administrators admin<\/em>. Diese Login-Name geh\u00f6rt als erstes ge\u00e4ndert. Dieser Login-Name ist bekannt und sorgt daf\u00fcr, dass eine unberechtigte Person nur noch an einem Wort t\u00fcfteln muss – dem Zugangspasswort. Mit einem eigenen Login-Namen erh\u00f6ht man die Sicherheit des Systems.<\/p>\n
Ist der Blog schon eine weile im Betrieb, so hat das Login sicher einiges an Daten – Artikel, Kommentare. Aber keine Angst, WordPress erlaub beim L\u00f6schen eines Users die \u00dcbernahme aller Daten auf einen anderen User.<\/p>\n
1.1. User ID<\/h4>\n
Wer sich nicht vor dem Zugriff und dem \u00c4ndern in der Datenbank scheut, dem sei das \u00c4ndern der ID zu empfehlen. Die Standard-IDs 1 und 2 werden am ehesten von Hackern genutzt.
\nAchtung, dazu muss dieuser_id<\/code> in den Tabellen_users<\/code> und_usermeta<\/code> gleich sein! Ebenso gilt es die Tabelle_posts<\/code>,_links<\/code> mit dem neuen ID zu versehen, Spaltepost_author<\/code>.
\nUPDATE `wp_users` SET `ID` = \u201c815\u2033 WHERE `wp_users`.`ID` = 1;<\/code>
\nUPDATE `wp_usermeta` SET `user_id` = '815' WHERE `wp_usermeta`.`user_id` = 1;<\/code>
\nUPDATE `wp_posts` SET `post_author` = '815' WHERE `wp_posts`.`post_author` = 1;<\/code>
\nUPDATE `wp_links` SET `link_owner` = '815' WHERE `wp_links`.`link_owner` = 1;<\/code><\/p>\nTipp<\/h4>\n
Ich habe das Plugin Search & Replace<\/a> erweitert und nun kann man mit einem Klick die User-Id und das User-Login einfach \u00e4ndern, Kenntnisse im Bereich SQL sind nicht erforderlich.<\/li>\n
- \n
Tabellen-Pr\u00e4fix<\/h3>\n
Der Tabellen-Pr\u00e4fix von WordPress ist im Standard
wp_<\/code>. Dieser ist in der wp-config.php<\/em> hinterlegt.<\/p>\nNeuinstallation<\/h4>\n
Bevor WordPress installiert wird, sollte dieser Pr\u00e4fix ge\u00e4ndert werden, in einen beliebigen Pr\u00e4fix, der nicht einfach auch das System schlie\u00dfen l\u00e4sst.
\nIn der Regel hat WordPress bei vielen Anwendern sicher eine eigene Datenbank und so muss der Pr\u00e4fix nicht auf das System schlie\u00dfen lassen.<\/p>\n\n\/\/ Wenn du verschiedene Pr\u00e4fixe benutzt kannst du innerhalb einer Datenbank\n\/\/ verschiedene WordPress Installationen betreiben\n$table_prefix = 'wp_'; \/\/ Nur Zahlen, Buchstaben und Unterstriche bitte!\n<\/code><\/pre>\n
$table_prefix = '08xyz15_'; \/\/ Nur Zahlen, Buchstaben und Unterstriche bitte!<\/code><\/p>\nBestehende Installation<\/h4>\n
Was nun aber, wenn das Blog schon aufgesetzt und in Betrieb ist. Auch dann empfiehlt sich die \u00c4nderung des Pr\u00e4fix in eine kryptische Variante.<\/p>\n
Nat\u00fcrlich muss auch dazu der Pr\u00e4fix in der wp-config.php<\/em> ge\u00e4ndert werden. Nun weis WordPress zwar, wie der neue Pr\u00e4fix lautet, aber die bestehenden Tabellen in der Datenbank haben diesen neuen Pr\u00e4fix noch nicht und das Blog kann somit nicht funktionieren.<\/p>\n
Mit Hilfe eines SQL-Kommandos ist aber auch dies recht schnell zu beheben. Dazu nutzt man am besten phpMyAdmin, welches bei vielen Webhostern vorinstalliert ist.
\nDie folgende SQL-Anweisung benennt die Tabelle links<\/em> um.
\nRENAME TABLE wp_links to 08xyz15_links;<\/code><\/p>\nDiese Anweisung f\u00fchrt man f\u00fcr jede bestehende Tabelle aus. Dabei hat WordPress, ab Version 2.3, im Standard 10 Tabellen: comments<\/em>, links<\/em>, options<\/em>, postmeta<\/em>, posts<\/em>, terms<\/em>, term_relationships<\/em>, term_taxonomy<\/em>, usermeta<\/em>, users<\/em>.<\/p>\n
\nRENAME TABLE wp_comments to 08xyz15_comments;\nRENAME TABLE wp_links to 08xyz15_links;\nRENAME TABLE wp_options to 08xyz15_options;\nRENAME TABLE wp_postmeta to 08xyz15_postmeta;\nRENAME TABLE wp_posts to 08xyz15_posts;\nRENAME TABLE wp_terms to 08xyz15_terms;\nRENAME TABLE wp_term_relationships to 08xyz15_term_relationships;\nRENAME TABLE wp_term_taxonomy to 08xyz15_term_taxonomy;\nRENAME TABLE wp_usermeta to 08xyz15_usermeta;\nRENAME TABLE wp_users to 08xyz15_users;\n<\/code><\/pre>\nIm Anschluss ist man nicht fertig! In den Tabellen options und usermeta m\u00fcssen noch 4 Felder ge\u00e4ndert werden. Dazu kann man folgenden Ql-Syntax nutzen.
\nUPDATE 08xyz15_options SET option_name = REPLACE(option_name, 'wp_', '08xyz15_');<\/code>
\nUPDATE 08xyz15_usermeta SET meta_key = REPLACE(meta_key, 'wp_', '08xyz15_');<\/code><\/p>\nSollte es aus irgendwelchen Gr\u00fcnden, z.B. ein Plugin, noch weitere Felder mit dem alten Pr\u00e4fix geben, dann kann man diese mit der folgenden Anweisung finden.
\nSELECT * FROM 08xyz15_options WHERE option_name LIKE 'wp_%';<\/code>
\nSELECT * FROM 08xyz15_usermeta WHERE meta_key LIKE 'wp_%';<\/code><\/p>\nHandelt es sich um eine Installation kleiner WordPress Version 2.3, dann m\u00fcssen folgenden 10 Tabellen ber\u00fccksichtigt werden: categories<\/em>, comments<\/em>, link2cat<\/em>, links<\/em>, options<\/em>, post2cat<\/em>, postmeta<\/em>, posts<\/em>, usermeta<\/em>, users<\/em>.<\/p>\n
Nat\u00fcrlich gibt es auch f\u00fcr diese Arbeit ein Plugin, welches einem Anwender die Arbeit erleichtert und die \u00c4ndern schnell durchf\u00fchrt: WP Prefix Table Changer<\/a>.<\/li>\n
- \n
Plugin Verzeichnis sch\u00fctzen<\/h3>\n
Das WordPress-Entwickler-Team empfiehlt die Sicherung durch einen einfachen Schutz, kopiere eine leere index.html<\/em> in das Plugin-Verzeichnis \/wp-content\/plugins\/<\/em>. Damit ist man auf der sicheren Seite, falls der Apache das Anzeigen von leeren Verzeichnissen zul\u00e4sst.<\/li>\n
- \n
WordPress Version verschleiern<\/h3>\n
WordPress hinterlegt in den Core-Daten die Version der Installation und der Datenbank. Bisher hat man in der Regel im Theme die Version eingepflegt. Diese dient lediglich statistischen Erhebungen, denn dar\u00fcber konnte man ein wenig die jeweils aktuell verf\u00fcgbaren Installationen recht einfach erkennen.<\/p>\n
Die Entwickler von WordPress empfehlen seit geraumer Zeit, dass man diesen Tag aus dem Theme entfernt um die Identifizierung zu erschweren. Dazu ist im Theme in der Regel die header.php<\/em> zu \u00e4ndern, in einigen Themes auch die index.php<\/em>.<\/p>\n
<meta name=\"generator\"\ncontent=\"WordPress <?php bloginfo('version'); ?>\" \/><\/pre>\nDie obige Zeile also entfernen.<\/p>\n
Allerdings sollte man nicht verschweigen, dass man trotzdem die Version von WordPress in der einen oder anderen Funktion ben\u00f6tigt und das man die Version beispielsweise im Feed auslesen kann. Einige Plugins beispielsweise greifen auf die Version zu und k\u00f6nnen so auf unterschiedliche Installationen reagieren. Die Version der WordPress-Installation und der Datenbank ist immer in \/wp-includes\/version.php<\/em> zu finden. Wer also die Version komplett verschleiern will, der \u00e4ndert den Eintrag in dieser Datei. Sollte es dann aber zu Problemen mit dem einen oder anderen Plugin oder Theme kommen, dann sollte man sich zumindest an diesen Eingriff erinnern.<\/p>\n
\n$wp_version = '2.2.3';\n\n$wp_db_version = 5183;\n<\/pre>\nEbenso ist darauf zu achten, nach jedem Update der Installation ist diese Datei wieder hergestellt.<\/p>\n
Mit dem L\u00f6schen bzw. \u00c4ndern des Eintrags funktioniert au\u00dferdem der automatische Hinweis auf eine neue Version und der Hinweis auf neue Plugin-Versionen, der seit WordPress Version 2.3.1 vorhanden ist, nicht mehr zuverl\u00e4ssig bzw. gar nicht.<\/p>\n
Tipp<\/h4>\n
Ich habe ein Plugin erstellt, was die Version von WordPress ersetzt, entweder mit einer Zufallszahl oder ab Version 2.4 wird der komplette Tag gel\u00f6scht. Damit werden keine Informationen nach au\u00dfen getragen und man muss nach einem WP-Update nicht die Core-Dateien \u00e4ndern.
\nWeitere Information und Download des Plugins sind auf meinem Privaten Blog im Artikel WordPress Version verschleiern (Plugin)<\/a> zu finden.<\/li>\n- \n
WordPress User-Logins reduzieren<\/h3>\n
Im Normalfall hat das Backend nur so viele User, wie man auch wirklich Personen hat, die im System arbeiten. Test-User oder \u00dcberbleibsel geh\u00f6ren gel\u00f6scht.
\nEin Augenmerk geh\u00f6rt den Rechten. Es ist zu \u00fcberpr\u00fcfen, welche Rechte jeder User hat und ob diese wirklich notwendig sind. Es ist kein Zeichen von Angst oder Geiz, wenn die Rechte der User eingeschr\u00e4nkt sind, auf die jeweiligen Anforderungen und Bed\u00fcrfnisse zugeschnitten.<\/p>\nEin Tipp<\/h4>\n
Mit Hilfe des Plugins
Role Manager<\/a><\/del> Members<\/a> lassen sich hervorragend Benutzerrechte erstellen. So lassen sich einfach und \u00fcbersichtlich entsprechend zugeschnittene Rollen f\u00fcr die jeweiligen Nutzer-Aufgaben erstellen, falls die Rollen im Standard nicht ausreichen.<\/li>\n- \n
WordPress aktualisieren<\/h3>\n
WordPress Core<\/h4>\n
Nicht zu letzt ist es wichtig, dass die Installation immer auf dem aktuellen Sicherheitsstand ist, das hei\u00dft: Spiele immer das aktuelle Release ein! Die aktuelle Release-Version sichert die Sicherheit von WordPress.
\nDas hei\u00dft nicht, dass man immer die aktuellste Version von WordPress installiert haben muss. Aber das aktuellste Release der verwendeten Version sollte eingespielt sein.<\/p>\nUm auf dem aktuellen Stand zu bleiben, bietet es sich an, den Feed von WordPress<\/a> zu abonnieren bzw. immer mal den Tellerrand des eigenen Blogs zu lesen, denn dort wird der Feed-Inhalt dargestellt.
\nAb der Version WP 2.3.1 weist das System darauf hin, dass es eine neue Revision\/ Version gibt. Wer den Zugriff nicht erm\u00f6glich will, der findet eine Reihe von Plugins im offiziellen Plugin-Verzeichnis<\/a>, die diese Verbindung unterbrechen.<\/p>\nWordPress Plugins<\/h4>\n
Gleiches gilt f\u00fcr Plugins. Plugins stellen neue Funktionalit\u00e4ten innerhalb des Systems und k\u00f6nnen damit neue Sicherheitsl\u00fccken einbringen. Vertraue nicht jedem Plugin und versuche die Plugins immer auf dem aktuellen Stand zu halten, auch wenn meist neue Versionen neue Funktionalit\u00e4ten einbringen.<\/p>\n
Im weiteren geh\u00f6ren nicht genutzte Plugins nicht in das laufende System. Werden sie nicht ben\u00f6tigt, dann geh\u00f6ren sie entfernt.<\/p>\n
WordPress Theme<\/h4>\n
Auch Themes k\u00f6nnen Sicherheitsprobleme aufweisen! Themes mit ihren Templates nutzen PHP-Funktionen und k\u00f6nnen neue Funktionen im Bauch haben. Damit k\u00f6nnen Sicherheitsl\u00fccken auftauchen. Es gilt also ebenfalls, auch Updates des Autors achten.<\/li>\n
- \n
WP Plugins minimieren<\/h3>\n
Wie schon im vorherigen Punkt erw\u00e4hnt, Plugins k\u00f6nnen neue Sicherheitsl\u00fccken in das System einbringen. Daher sollte immer die \u00dcberlegung gelten, muss es wirklich dieses Plugin sein. Bringt es Mehrwert und eventuell sollte man pr\u00fcfen, wie gut ist das Plugin. Nat\u00fcrlich ist es schwer, vor allem wenn man keine PHP-Kenntnisse hat, den Code zu inspizieren und damit ein eventuell bestehendes Problem zu finden. Aber trotzdem kann man ein wenig die Seriosit\u00e4t des Plugin-Autors pr\u00fcfen. Hat der Autor eine Anleitung zum Plugin, gibt es negative Schlagzeilen bzw. Blogeintr\u00e4ge und Kommentare und ist das Impressum des Autors gepflegt? Kleinigkeiten, die aber einiges \u00fcber den Autor und das Plugin aussagen k\u00f6nnen.<\/p>\n
\n
- Die Grundregel lautet jedoch: Verwende so wenig wie n\u00f6tig Plugins.<\/strong><\/li>\n
- Un die zweite Regel: Teste Plugins nicht im Live-System, ein Vorabtest in einer lokalen Installation kann viele Probleme verhindern.<\/strong><\/li>\n<\/ol>\n<\/li>\n
Auch der zweite Punkt hat wichtige Relevanz. Immer wieder holen sich User Problem und unn\u00f6tige Daten in ihr System. Viele Plugins ben\u00f6tigen Einstellungen, die in der Tabelle options<\/em> abgelegt werden. Diese Daten bleiben bei den meisten Plugins auch nach dem deaktivieren des Plugins in der Tabelle bestehen!<\/p>\n
- \n
Eingeschr\u00e4nkter Login auf wp-admin<\/em><\/h3>\n
Ist der Zugriff auf das Backend nur von einem oder wenigen Rechnern gesichert, so kann man den Zugriff einschr\u00e4nken und damit die Sicherheit weiter steigern. Der Zugriff ist einfach per .htaccess<\/em> zu beschr\u00e4nken. Information zu .htaccess<\/em> gibt es viele im Internet. Die Zugriffssperre k\u00f6nnte zum Beispiel f\u00fcr zwei IPs wie folgt aussehen.<\/p>\n
\nAuthUserFile \/dev\/null\nAuthGroupFile \/dev\/null\nAuthName \"Access Control\"\nAuthType Basic\nOrder deny,allow\nDeny from all\n# Whitelist IP Adresse\nAllow from 255.08.15.1\nAllow from 255.08.15.2\n<\/pre>\nDiese Syntax in eine leere Datei ablegen und die eigenen IPs hinterlegen und die Datei als .htaccess<\/em> speichern. Die Datei im Anschluss im Ordner \/wp-admin\/<\/em> ablegen.<\/p>\n
Ob man den Zugriff einschr\u00e4nken muss und will, das muss jeder Anwender selbst entscheiden.<\/p>\n
Aber es damit ist nat\u00fcrlich die sch\u00f6ne Funktionalit\u00e4t einer Web-Applikation dahin, von \u00fcberall auf das System zugreifen zu k\u00f6nnen.<\/p>\n
via Plugin<\/h4>\n
Alternativ kann man dies auch per Plugin realisieren, was einfacher und schneller f\u00fcr den Laien zu bewerkstelligen ist. Als Plugin dient das Login Lockdown Plugin<\/a> oder AskApache Password Protect<\/a>.<\/li>\n
- \n
Eingeschr\u00e4nkter Zugriff auf wp-content<\/em> und wp-includes<\/em><\/h3>\n
Mit Hilfe einer .htaccess<\/em> kann man ein ganze Reihe von Daten sch\u00fctzen. Mit Hilfe dieser Methode empfiehlt es sich den Zugriff nur auf bestimmte Datei-Formate, wie Bilder, Stylesheets und JavaScript zu beschr\u00e4nken.<\/p>\n
Order deny,allow\nDeny from all\n<Files ~ \".(xml|css|jpe?g|png|gif|js)$\">\nAllow from all\n<\/Files><\/pre>\nDer obige Syntax wird wieder in einer .htaccess<\/em> gespeichert und die Ordner \/wp-content\/<\/em> und \/wp-includes\/<\/em> kopiert. Die Datei-Endungen im Syntax m\u00fcssen nat\u00fcrlich angepasst werden, je nach dem, auf was f\u00fcr Dateien man zugreifen muss.<\/p>\n
Aufpassen<\/strong>, das eine oder andere Plugin ben\u00f6tigt den Zugriff auf php-Dateien. Daher den Syntax in dem Fall um
php<\/code> erweitern. Zumindest f\u00fcr die .htacces<\/em> in \/wp-content\/<\/em> empfiehlt sich die Aufnahme vonphp<\/code>. \u00c4hnlich verh\u00e4lt es sich, wenn man den Cache von WordPress aktiv hat, dann muss man den Zugriff auflock<\/code> erlauben.<\/p>\n\n# Allow only css,jpe*g,png,gif,js\nOrder deny,allow\nDeny from all\n<Files ~ \".(php|lock|xml|css|jpe?g|png|gif|js)$\">\nAllow from all\n<\/Files>\n<\/pre>\nIm weiteren ist darauf zu achten, dass man nur eine .htaccess<\/em>-Datei im Ordner hat. Sollte man also ebenfalls den Zugriff per .htaccess<\/em> aus Punkt 8 nutzen, so muss der Syntax in einer Datei untergebracht werden.<\/li>\n
- \n
Sch\u00fctze die wp-config.php<\/em><\/h3>\n
Ein weiterer Schutz ist der Zugriff auf die wp-config.php<\/em>, in der alle Daten zum einloggen in die Datenbank hinterlegt sind. Im Grunde gibt es diesen Zugriff nicht, aber mit dieser kleinen Erweiterung in der .htaccess<\/em> im root-Verzeichnis der Installation, geht man auf Nummer sicher.<\/p>\n
\n# protect wp-config.php\n<files wp-config.php>\nOrder deny,allow\nDeny from all\n<\/files>\n<\/pre>\nViele weitere Informationen dazu mit einigen Beispielen und Diskussionen findet man im zugeh\u00f6rigen Artikel<\/a> auf meinem privaten Blog.<\/li>\n
- \n
Sicherheit pr\u00fcfen<\/h3>\n
Das Team von BlogSecurity bietet die Online-Version des WP-Scanners<\/a> schon eine geraume Zeit an und aktualisiert diesen auch immer wieder.<\/p>\n
Nicht immer liegt es an den Dateien von WordPress, auch das Theme kann Sicherheitsl\u00fccken enthalten.<\/p>\n
Um das eigene Blog zu scannen, muss lediglich ein Kommentar in der header.php<\/em> bzw. index.php<\/em>, falls es keine header.php<\/em> gibt, hinterlegt werden.
\n<!-- wpscanner --><\/code><\/p>\nDer Scan ist kritisch zu sehen aber er hilft und erleichtert die Arbeit.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Ein Thema, welches ich im Buch leider vernachl\u00e4ssigt habe, ist das Thema Sicherheit. Dieses Thema ist aber immer relevanter, gerade weil WordPress immer popul\u00e4rer wird und damit auch immer interessanter f\u00fcr Hacker und Andere, die sich unbefugt Zutritt zu einer Web-Applikationen geben wollen. Nicht zuletzt ist der Artikel also eine Aufforderung vieler Leser, die mir… WordPress sicherer machen<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":813,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[17],"class_list":["post-114","post","type-post","status-publish","format-standard","hentry","category-mehrwert","tag-sicherheit","entry"],"_links":{"self":[{"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/posts\/114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/users\/813"}],"replies":[{"embeddable":true,"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/comments?post=114"}],"version-history":[{"count":0,"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/posts\/114\/revisions"}],"wp:attachment":[{"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/media?parent=114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/categories?post=114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bueltge.de\/wordpress-buch\/wp-json\/wp\/v2\/tags?post=114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}