WordPress sicherer machen

WP Login

Ein Thema, welches ich im Buch leider vernachlässigt habe, ist das Thema Sicherheit. Dieses Thema ist aber immer relevanter, gerade weil WordPress immer populärer wird und damit auch immer interessanter für 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 per E-Mail oder Online-Rezension, einen Hinweis darauf hinterlassen habe und denen ich mit diesem Artikel ein wenig helfen möchte, ihre WordPress-Installation sicherer zu machen.

Kurz & Knapp – so werde ich also im folgenden einige Tipps für ein sicheres Weblog mit WordPress geben.

Sicherheit – einen Zustand, der frei von unvertretbaren Risiken der Beeinträchtigung ist oder als gefahrenfrei angesehen wird.

Wikipedia

Aber Achtung, damit will und kann ich nicht die Eigenverantwortung des jeweiligen Administrators herabsetzen oder abnehmen. Das Thema wird immer wieder präsent sein und die Sicherheitsregeln werden sich ändern. Nichtsdestotrotz kann man mit einigen wenigen Schritten die Installation recht sicher gestallten.

  1. User-Name

    Nach jeder Installation ist der Standard-User-Name des Administrators admin. Diese Login-Name gehört als erstes geändert. Dieser Login-Name ist bekannt und sorgt dafür, dass eine unberechtigte Person nur noch an einem Wort tüfteln muss – dem Zugangspasswort. Mit einem eigenen Login-Namen erhöht man die Sicherheit des Systems.

    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öschen eines Users die Übernahme aller Daten auf einen anderen User.

    1.1. User ID

    Wer sich nicht vor dem Zugriff und dem Ändern in der Datenbank scheut, dem sei das Ändern der ID zu empfehlen. Die Standard-IDs 1 und 2 werden am ehesten von Hackern genutzt.
    Achtung, dazu muss die user_id in den Tabellen _users und _usermeta gleich sein! Ebenso gilt es die Tabelle _posts, _links mit dem neuen ID zu versehen, Spalte post_author.
    UPDATE `wp_users` SET `ID` = “815″ WHERE `wp_users`.`ID` = 1;
    UPDATE `wp_usermeta` SET `user_id` = '815' WHERE `wp_usermeta`.`user_id` = 1;
    UPDATE `wp_posts` SET `post_author` = '815' WHERE `wp_posts`.`post_author` = 1;
    UPDATE `wp_links` SET `link_owner` = '815' WHERE `wp_links`.`link_owner` = 1;

    Tipp

    Ich habe das Plugin Search & Replace erweitert und nun kann man mit einem Klick die User-Id und das User-Login einfach ändern, Kenntnisse im Bereich SQL sind nicht erforderlich.

  2. Tabellen-Präfix

    Der Tabellen-Präfix von WordPress ist im Standard wp_. Dieser ist in der wp-config.php hinterlegt.

    Neuinstallation

    Bevor WordPress installiert wird, sollte dieser Präfix geändert werden, in einen beliebigen Präfix, der nicht einfach auch das System schließen lässt.
    In der Regel hat WordPress bei vielen Anwendern sicher eine eigene Datenbank und so muss der Präfix nicht auf das System schließen lassen.

    
    // Wenn du verschiedene Präfixe benutzt kannst du innerhalb einer Datenbank
    // verschiedene WordPress Installationen betreiben
    $table_prefix  = 'wp_';   // Nur Zahlen, Buchstaben und Unterstriche bitte!
    

    $table_prefix = '08xyz15_'; // Nur Zahlen, Buchstaben und Unterstriche bitte!

    Bestehende Installation

    Was nun aber, wenn das Blog schon aufgesetzt und in Betrieb ist. Auch dann empfiehlt sich die Änderung des Präfix in eine kryptische Variante.

    Natürlich muss auch dazu der Präfix in der wp-config.php geändert werden. Nun weis WordPress zwar, wie der neue Präfix lautet, aber die bestehenden Tabellen in der Datenbank haben diesen neuen Präfix noch nicht und das Blog kann somit nicht funktionieren.

    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.
    Die folgende SQL-Anweisung benennt die Tabelle links um.
    RENAME TABLE wp_links to 08xyz15_links;

    Diese Anweisung führt man für jede bestehende Tabelle aus. Dabei hat WordPress, ab Version 2.3, im Standard 10 Tabellen: comments, links, options, postmeta, posts, terms, term_relationships, term_taxonomy, usermeta, users.

    
    RENAME TABLE wp_comments to 08xyz15_comments;
    RENAME TABLE wp_links to 08xyz15_links;
    RENAME TABLE wp_options to 08xyz15_options;
    RENAME TABLE wp_postmeta to 08xyz15_postmeta;
    RENAME TABLE wp_posts to 08xyz15_posts;
    RENAME TABLE wp_terms to 08xyz15_terms;
    RENAME TABLE wp_term_relationships to 08xyz15_term_relationships;
    RENAME TABLE wp_term_taxonomy to 08xyz15_term_taxonomy;
    RENAME TABLE wp_usermeta to 08xyz15_usermeta;
    RENAME TABLE wp_users to 08xyz15_users;
    

    Im Anschluss ist man nicht fertig! In den Tabellen options und usermeta müssen noch 4 Felder geändert werden. Dazu kann man folgenden Ql-Syntax nutzen.
    UPDATE 08xyz15_options SET option_name = REPLACE(option_name, 'wp_', '08xyz15_');
    UPDATE 08xyz15_usermeta SET meta_key = REPLACE(meta_key, 'wp_', '08xyz15_');

    Sollte es aus irgendwelchen Gründen, z.B. ein Plugin, noch weitere Felder mit dem alten Präfix geben, dann kann man diese mit der folgenden Anweisung finden.
    SELECT * FROM 08xyz15_options WHERE option_name LIKE 'wp_%';
    SELECT * FROM 08xyz15_usermeta WHERE meta_key LIKE 'wp_%';

    Handelt es sich um eine Installation kleiner WordPress Version 2.3, dann müssen folgenden 10 Tabellen berücksichtigt werden: categories, comments, link2cat, links, options, post2cat, postmeta, posts, usermeta, users.

    Natürlich gibt es auch für diese Arbeit ein Plugin, welches einem Anwender die Arbeit erleichtert und die Ändern schnell durchführt: WP Prefix Table Changer.

  3. Plugin Verzeichnis schützen

    Das WordPress-Entwickler-Team empfiehlt die Sicherung durch einen einfachen Schutz, kopiere eine leere index.html in das Plugin-Verzeichnis /wp-content/plugins/. Damit ist man auf der sicheren Seite, falls der Apache das Anzeigen von leeren Verzeichnissen zulässt.

  4. WordPress Version verschleiern

    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über konnte man ein wenig die jeweils aktuell verfügbaren Installationen recht einfach erkennen.

    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 zu ändern, in einigen Themes auch die index.php.

    <meta name="generator"
    content="WordPress <?php bloginfo('version'); ?>" />

    Die obige Zeile also entfernen.

    Allerdings sollte man nicht verschweigen, dass man trotzdem die Version von WordPress in der einen oder anderen Funktion benötigt und das man die Version beispielsweise im Feed auslesen kann. Einige Plugins beispielsweise greifen auf die Version zu und können so auf unterschiedliche Installationen reagieren. Die Version der WordPress-Installation und der Datenbank ist immer in /wp-includes/version.php zu finden. Wer also die Version komplett verschleiern will, der ändert 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.

    $wp_version = '2.2.3';
    
    $wp_db_version = 5183;
    

    Ebenso ist darauf zu achten, nach jedem Update der Installation ist diese Datei wieder hergestellt.

    Mit dem Löschen bzw. Ändern des Eintrags funktioniert außerdem 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ässig bzw. gar nicht.

    Tipp

    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öscht. Damit werden keine Informationen nach außen getragen und man muss nach einem WP-Update nicht die Core-Dateien ändern.
    Weitere Information und Download des Plugins sind auf meinem Privaten Blog im Artikel WordPress Version verschleiern (Plugin) zu finden.

  5. WordPress User-Logins reduzieren

    Im Normalfall hat das Backend nur so viele User, wie man auch wirklich Personen hat, die im System arbeiten. Test-User oder Überbleibsel gehören gelöscht.
    Ein Augenmerk gehört den Rechten. Es ist zu überprüfen, 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änkt sind, auf die jeweiligen Anforderungen und Bedürfnisse zugeschnitten.

    Ein Tipp

    Mit Hilfe des Plugins Role Manager Members lassen sich hervorragend Benutzerrechte erstellen. So lassen sich einfach und übersichtlich entsprechend zugeschnittene Rollen für die jeweiligen Nutzer-Aufgaben erstellen, falls die Rollen im Standard nicht ausreichen.

  6. WordPress aktualisieren

    WordPress Core

    Nicht zu letzt ist es wichtig, dass die Installation immer auf dem aktuellen Sicherheitsstand ist, das heißt: Spiele immer das aktuelle Release ein! Die aktuelle Release-Version sichert die Sicherheit von WordPress.
    Das heißt nicht, dass man immer die aktuellste Version von WordPress installiert haben muss. Aber das aktuellste Release der verwendeten Version sollte eingespielt sein.

    Um auf dem aktuellen Stand zu bleiben, bietet es sich an, den Feed von WordPress zu abonnieren bzw. immer mal den Tellerrand des eigenen Blogs zu lesen, denn dort wird der Feed-Inhalt dargestellt.
    Ab der Version WP 2.3.1 weist das System darauf hin, dass es eine neue Revision/ Version gibt. Wer den Zugriff nicht ermöglich will, der findet eine Reihe von Plugins im offiziellen Plugin-Verzeichnis, die diese Verbindung unterbrechen.

    WordPress Plugins

    Gleiches gilt für Plugins. Plugins stellen neue Funktionalitäten innerhalb des Systems und können damit neue Sicherheitslücken einbringen. Vertraue nicht jedem Plugin und versuche die Plugins immer auf dem aktuellen Stand zu halten, auch wenn meist neue Versionen neue Funktionalitäten einbringen.

    Im weiteren gehören nicht genutzte Plugins nicht in das laufende System. Werden sie nicht benötigt, dann gehören sie entfernt.

    WordPress Theme

    Auch Themes können Sicherheitsprobleme aufweisen! Themes mit ihren Templates nutzen PHP-Funktionen und können neue Funktionen im Bauch haben. Damit können Sicherheitslücken auftauchen. Es gilt also ebenfalls, auch Updates des Autors achten.

  7. WP Plugins minimieren

    Wie schon im vorherigen Punkt erwähnt, Plugins können neue Sicherheitslücken in das System einbringen. Daher sollte immer die Überlegung gelten, muss es wirklich dieses Plugin sein. Bringt es Mehrwert und eventuell sollte man prüfen, wie gut ist das Plugin. Natürlich 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ät des Plugin-Autors prüfen. Hat der Autor eine Anleitung zum Plugin, gibt es negative Schlagzeilen bzw. Blogeinträge und Kommentare und ist das Impressum des Autors gepflegt? Kleinigkeiten, die aber einiges über den Autor und das Plugin aussagen können.

    1. Die Grundregel lautet jedoch: Verwende so wenig wie nötig Plugins.
    2. Un die zweite Regel: Teste Plugins nicht im Live-System, ein Vorabtest in einer lokalen Installation kann viele Probleme verhindern.
  8. Auch der zweite Punkt hat wichtige Relevanz. Immer wieder holen sich User Problem und unnötige Daten in ihr System. Viele Plugins benötigen Einstellungen, die in der Tabelle options abgelegt werden. Diese Daten bleiben bei den meisten Plugins auch nach dem deaktivieren des Plugins in der Tabelle bestehen!

  9. Eingeschränkter Login auf wp-admin

    Ist der Zugriff auf das Backend nur von einem oder wenigen Rechnern gesichert, so kann man den Zugriff einschränken und damit die Sicherheit weiter steigern. Der Zugriff ist einfach per .htaccess zu beschränken. Information zu .htaccess gibt es viele im Internet. Die Zugriffssperre könnte zum Beispiel für zwei IPs wie folgt aussehen.

    AuthUserFile /dev/null
    AuthGroupFile /dev/null
    AuthName "Access Control"
    AuthType Basic
    Order deny,allow
    Deny from all
    # Whitelist IP Adresse
    Allow from 255.08.15.1
    Allow from 255.08.15.2
    

    Diese Syntax in eine leere Datei ablegen und die eigenen IPs hinterlegen und die Datei als .htaccess speichern. Die Datei im Anschluss im Ordner /wp-admin/ ablegen.

    Ob man den Zugriff einschränken muss und will, das muss jeder Anwender selbst entscheiden.

    Aber es damit ist natürlich die schöne Funktionalität einer Web-Applikation dahin, von überall auf das System zugreifen zu können.

    via Plugin

    Alternativ kann man dies auch per Plugin realisieren, was einfacher und schneller für den Laien zu bewerkstelligen ist. Als Plugin dient das Login Lockdown Plugin oder AskApache Password Protect.

  10. Eingeschränkter Zugriff auf wp-content und wp-includes

    Mit Hilfe einer .htaccess kann man ein ganze Reihe von Daten schützen. Mit Hilfe dieser Methode empfiehlt es sich den Zugriff nur auf bestimmte Datei-Formate, wie Bilder, Stylesheets und JavaScript zu beschränken.

    Order deny,allow
    Deny from all
    <Files ~ ".(xml|css|jpe?g|png|gif|js)$">
    Allow from all
    </Files>

    Der obige Syntax wird wieder in einer .htaccess gespeichert und die Ordner /wp-content/ und /wp-includes/ kopiert. Die Datei-Endungen im Syntax müssen natürlich angepasst werden, je nach dem, auf was für Dateien man zugreifen muss.

    Aufpassen, das eine oder andere Plugin benötigt den Zugriff auf php-Dateien. Daher den Syntax in dem Fall um php erweitern. Zumindest für die .htacces in /wp-content/ empfiehlt sich die Aufnahme von php. Ähnlich verhält es sich, wenn man den Cache von WordPress aktiv hat, dann muss man den Zugriff auf lock erlauben.

    # Allow only css,jpe*g,png,gif,js
    Order deny,allow
    Deny from all
    <Files ~ ".(php|lock|xml|css|jpe?g|png|gif|js)$">
    Allow from all
    </Files>
    

    Im weiteren ist darauf zu achten, dass man nur eine .htaccess-Datei im Ordner hat. Sollte man also ebenfalls den Zugriff per .htaccess aus Punkt 8 nutzen, so muss der Syntax in einer Datei untergebracht werden.

  11. Schütze die wp-config.php

    Ein weiterer Schutz ist der Zugriff auf die wp-config.php, 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 im root-Verzeichnis der Installation, geht man auf Nummer sicher.

    # protect wp-config.php
    <files wp-config.php>
    Order deny,allow
    Deny from all
    </files>
    

    Viele weitere Informationen dazu mit einigen Beispielen und Diskussionen findet man im zugehörigen Artikel auf meinem privaten Blog.

  12. Sicherheit prüfen

    Das Team von BlogSecurity bietet die Online-Version des WP-Scanners schon eine geraume Zeit an und aktualisiert diesen auch immer wieder.

    Nicht immer liegt es an den Dateien von WordPress, auch das Theme kann Sicherheitslücken enthalten.

    Um das eigene Blog zu scannen, muss lediglich ein Kommentar in der header.php bzw. index.php, falls es keine header.php gibt, hinterlegt werden.
    <!-- wpscanner -->

    Der Scan ist kritisch zu sehen aber er hilft und erleichtert die Arbeit.

Veröffentlicht am
Kategorisiert in Mehrwert Verschlagwortet mit

Von Frank Bültge

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.

116 Kommentare

  1. Zu Punkt 4:

    Das Herausnehmen der entsprechenden Variablen (bzw. des PHP-Kommandos) aus der header.php reicht leider nicht!

    Und in keiner Anleitung bezüglich der Absicherung von WP habe ich bisher eine ordentliche Anleitung zu diesem Punkt gefunden, was mich eigentlich ziemlich ärgert. Denn:

    Man muss die entsprechende Info-Zeile auch aus jeder einzelnen der sechs Feed-Dateien entfernen (liegen alle in /wp-includes).

    Wer aber nicht in Kerndateien außerhalb des Themes manuell schrauben will, muss die Versionsnummer in version.php auf eine sinnlose Nummer ändern, also „faken“, um seine WP-Version zu verheimlichen.

    Ich kann nicht beweisen, dass es Bots gibt, die in Feeds nach der WP-Version schnüffeln, aber jemand, der seine „böse“ Software bestimmte WP-Versionen angreifen lassen will, wäre inkompetent, wenn er es nicht täte.

  2. @Boris: das ist klar, steht auch explizit im Artikel drin. Ebenso weise ich aber darauf hin, dass wenn man die Versionsnummer ändert bzw. löscht andere Probleme nicht auszuschließen sind.

    Allerdings sollte man nicht verschweigen, dass man trotzdem die Version von WordPress in der einen oder anderen Funktion benötigt und das man die Version beispielsweise im Feed auslesen kann.

  3. Pingback: mmyNews
  4. Ups? Hatte ich das tatsächlich überlesen? Dann flugs ein „Sorry“ nachgereicht!

    Ich hatte da so eine leicht verärgerte Anwandlung, weil mir schon ein paar Abhandlungen zum „Abhärten“ von WP untergekommen sind, die selbst diese einfache Erkenntnis der Versionsnummer in den Feeds vernachlässigt haben.

    Ich nehme jedenfalls die Mühe auf mich, die WP-Versionsangabe in der header.php und in den Feed-Dateien manuell herauszunehmen.

    Der Adminbereich bleibt verschont davon, und deswegen funktioniert die Versions-Updatebenachrichtigung weiterhin problemlos.

  5. hallo

    wie kommen wir denn zu einer lösung das die versions nummer nach aussen nicht mehr gebraucht wird.

    die versions nummer kann von mir aus in einer config datei oder der db stehen, aber von aussen sichbar muss ja nicht sein 😉

  6. @Boris: ab der kommenden Version von WordPress kann man den ‚Generator‘-Tag per Plugin deaktivieren, habe mal eines erstellt und in meiner WP 2.5 Install klappt das recht gut.
    Damit wird es sicher einfacher.
    WP baut einen Hook ein um diesen Punkt anzusprechen.

  7. Danke Frank,
    in dieser Zusammenstellung und Vollständigkeit inkl. Erläuterungen ein Pflichtbookmark. Einige der Punkte waren mir neu.
    So kann jeder selbst entscheiden und abwägen, wie weit man gehen will.

  8. Hallo!
    Danke für diese ausführliche Liste.
    Ich habe noch die ein oder andere Frage… und auch Anmerkung zu den Punkten. Es scheint mir — ohne unhöflich sein zu wollen — als ob hier zum Teil etwas zwanghaft Lösungen gesucht wo nicht wirklich welche Nötig wären oder die nicht wirklich helfen/lösen.

    – „admin“-Username: Ein sicheres Passwort sollte doch völlig ausreichen… Es sollte IMO eher heißen: Suche ein sicheres Passwort aus — das gilt nämlich für alle User. Schließlich kann man in den meisten Themes den Usernamen auch irgendwo lesen.
    – Tabellen-Präfix: Ich verstehe nicht, in wie weit das die Sicherheit erhöht?
    – Plugin-Verzeichnis: Ja, sollte IMO im Core sein die silent-index-php.
    – WordPress-Version: Die header.php zu ändern ist IMO einer der praxisnahsten Tipps. Aber irgend etwas dafür zu hacken oder zu installieren, ist zu viel des Guten. Dann lieber auf WP 2.4/2.5 warten.
    – Rechte: Auch der Tipp trifft doch für 99,5% der Bloguser nicht zu. Was soll den da passieren? Wo soll die Gefahr sein?
    – WP+Plugins aktualisieren: IMO wohl der wichtigste Tipp. Dann hat man auch das Versionsproblem nicht!
    – WP-Theme: Hier würde mich interessieren, worauf genau man achten muss…
    – Pluginanzahl minimieren: Auch wichtig, sich das bewusst zu machen. Und auch der Grund, warum ich für kleine Probleme wie die Versionsnummer kein extra Plugin haben möchte.
    – wp-admin Einschränken: Das hilft uns doch bei normalen Internetverbindungen ohne statische IP nicht weiter, oder?
    – Der Tipp klingt interessant aber auch danach, dass einige Test-Arbeit nötig ist um sicherzustellen, dass danach alles funktioniert… Und wenn ich PHP-Dateien frei gebe, bringt das ganze IMO gar nichts mehr, da dann auch schadhafter Code wie gehackte Formmailer ja problemlos arbeiten können.
    Würde die .htaccess-Datei für die Ordner dann auch für Unterordner gelten?
    – wp-config schützen: Das verstehe ich nicht. Wenn die Datei nicht in Gefahr ist, warum sollte ich sie schützen? Oder gibt es einen bekannten Weg, sie anzugreifen?
    • wp Scanner: Was daran genau ist kritisch zu sehen?

    VG

  9. @Tobias:
    „admin“-Username: nein, reicht nicht. admin ist der Standard-User und damit mehr oder weniger bekannt. Das macht es dem Angreifer leichter. Mit einem anderen Usernamen erhöht es die Sicherheit.

    Präfix: ist der Präfix im Standard, dann ist auch das dem Angreifer ein leichtes Spiel, denn so haben wes die meisten und wieder ein Punkt, den der Angreifer nicht herausfinden muss.

    Jede Version hat andere Lücken, die bekannt sind. Gibt man die Version nach außen bekannt, dann kann der Angreifer auf diese Lücken setzten und sie ausnutzen. Gilt vor allem für Installationen, die nicht immer das aktuelle Update haben.
    Hacken ist nicht mehr notwendig, ich habe ein Plugin dafür erstellt: https://bueltge.de/wordpress-version-verschleiern-plugin/602/

    Rechte: möglich, aber es gibt eine Reihe von Usern in Installationen, die keinen Mehrwert haben und sie reduzieren die Sicherheit, denn wieder steht ein Username und Passwort bereit um in das Blog zu kommen.

    WP-Theme: Dazu den WP-Scanner nutzen, der prüft das Theme.

    wp-admin einschränken: richtig, deshalb ist es nicht für jeden nutzbar, erhöht aber, wenn man es so mag, die Sicherheit

    Gilt auch für die Unterordner, wenn keine weitere .htaccess dort hinterlegt ist.

    Es gibt mit einigen Tricks die Möglichkeit, wenn der Server es erlaubt, php auszulesen. Daher auf Nummer Sicher gehen.

    wp-scanner: ist nur ein Tool, er schlägt auch manchmal an, wenn es nicht erforderlich ist. Das weis man dann aber, denn man kennt ja sein Theme.

    * Nochmal der Hinweis. Sicherheit ist in erster Linie nur so weit sicher, wenn es so ist, dass man auch noch arbeiten kann.

    Ich hoffe, dass du so in kurzer Form die Punkte besser verstehst?

  10. Hallo Frank!

    Frage zu admin: Was heißt den Standard-User admin ändern? Er ist eben ein VORDEFINIERTER User und man kann ihn doch nicht löschen oder ändern! Wie kann ein anderer User die Beiträge von admin übernehmen??? Verstehe ich nicht!

    Servus
    Leo

  11. @Leo: genau – vordefiniert und damit ist der Benutzername allen anderen ebenso bekannt.
    Man kann ihn löschen, einfach einen neuen User anlegen, Admin-Rechte vergeben und dann mit den neuen User einloggen und den User Admin löschen.
    Alle Einträge etc. des „Admin“ sind dabei zu übernehmen. Diese Option erfolgt, wenn man den User „Admin“ auf löschen setzt.
    LG Frank

  12. Sind ja wirklich alles sehr gute (Sinn machende) und vor allem leicht umzusetzende Tipps. Danke Frank. Macht neugierig auf Dein Buch.

  13. Danke Frank, aber ich stehe schon vor dem ersten Problem. Bei Punkt 2 habe ich alles richtig gemacht, jedoch lässt mich WordPress nicht mehr einloggen und bringt mir die Meldung das ich nicht genügend Rechte habe. Weißt du was das sein könnte? (ich habs vorläufig wieder zurückgebastelt)

    Gruß

  14. WP ist das Gruselkabinett der OSWelt… Leude lernt coden!!!

    Es ist total sinnlos über Sicherheit zu diskutieren, wenn unter
    der Haube nur Schrott ist…

    1. schafft diese albernen php-mixed-templates ab
    2. führt eine saubere Architektur ein
    3. schafft ein richtiges Plugin-Interface
    4. ein zentrales plugin-repository
    (nur reviewed plugins können noch über Backend geladen werden)
    5. saubere Verzeichnisstruktur/Backend abtrennen
    usw…

    Ich kann WP niemandem empfehlen, der auch in Zukunft noch
    ruhig schlafen möchte.

  15. @Walter: zu diesem Thema gibt es ja schon die eine oder andere Diskussion im Netz und für alle, die mit WP nicht zufrieden sind, stehen genügend Alternativen zur Verfügung. In diesem Sinne soll das hier keine Diskussion sein, sondern lediglich einige Punkte, die das System WP sicherer machen.

  16. Pingback: WebBizBlog
  17. Hallo, zu Punkt 9. – Eingeschränkter Zugriff auf wp-content und wp-includes habe ich noch die Ergänzung, daß php-Dateien auch für das Verzeichnis wp-includes freigegeben werden müssen, da sonst der WYSIWYG-Editor nicht mehr funktioniert.

  18. Vielen Dank für die ausführliche Beschreibung zur Änderung des Präfix in einem bestehenden Blog!

  19. In wie fern ist die Nutzung des WP-Scanners kritisch zu sehen? Kann dieser mittels des Plugins die Userdaten auslesen? Warum muss man überhaupt erst ein Plugin installieren um den nutzen zu können?

  20. Danke für die tollen Security-Tipps! Habe jetzt mal den Großteil umgesetzt… funktioniert alles soweit problemlos – nur: seit ich auch die Änderungen in der DB gemacht habe (anderer Präfix, andere admin-id) bekomme ich beim Klick auf den „Dashboard-Link“ im Admin immer eine leere Seite. Nach dem Login funktioniert’s, direkter Aufruf von /wp-admin geht auch, aber /wp-admin/admin.php?page=index.php führt zu keiner Ausgabe… irgendwelche Ideen an was das liegen könnte?

  21. @Viktor: kritisch in dem Zusammenhang, dass auch Meldungen kommen, die aufgrund des Themes implementiert sind. Hat man das Theme aber selber geschrieben und mit PHP gearbeitet, dann kann schonmal die Meldung nicht stimmen, führt aber dazu, dass man selber nochmal prüft.

  22. kritisch in dem Zusammenhang, dass auch Meldungen kommen, die aufgrund des Themes implementiert sind. Hat man das Theme aber selber geschrieben und mit PHP gearbeitet, dann kann schonmal die Meldung nicht stimmen, führt aber dazu, dass man selber nochmal prüft.

  23. In wie fern ist die Nutzung des WP-Scanners kritisch zu sehen? Kann dieser mittels des Plugins die Userdaten auslesen? Warum muss man überhaupt erst ein Plugin installieren um den nutzen zu können?

  24. @hikaye: Zur ersten Frage habe ich den anderen Antworten schon Stellung genommen. Ein Plugin ist für den Scanner nicht nötig, es erleichtert lediglich die Nutzung für unbedarfte Nutzer.

  25. Danke für die tollen Security-Tipps! Habe jetzt mal den Großteil umgesetzt… funktioniert alles soweit problemlos – nur: seit ich auch die Änderungen in der DB gemacht habe (anderer Präfix, andere admin-id) bekomme ich beim Klick auf den “Dashboard-Link” im Admin immer eine leere Seite. Nach dem Login funktioniert’s, direkter Aufruf von /wp-admin geht auch, aber /wp-admin/admin.php?page=index.php führt zu keiner Ausgabe… irgendwelche Ideen an was das liegen könnte?

  26. Danke Frank, aber ich stehe schon vor dem ersten Problem. Bei Punkt 2 habe ich alles richtig gemacht, jedoch lässt mich WordPress nicht mehr einloggen und bringt mir die Meldung das ich nicht genügend Rechte habe. Weißt du was das sein könnte? (ich habs vorläufig wieder zurückgebastelt)

  27. @dizi izle: ja, du musst unbedingt die letzten 3 Absätze in Punkt 2 beachten. Die Verknüpfung stimmt dann nicht. Manchmal muss man auch noch nach weiteren Feldern suchen, eventuell hat ein Plugin ein Feld mit dem alten Präfix angelegt.

  28. Danle für deine ausführliche Liste. Ich bin schockiert, wieviel man machen muss, damit WordPress einigermaßen sicher wird…da muss man es sich ja 2 mal überlegen, nicht ein eigenes System zu programmieren.

  29. Pingback:  | Securebase.at
  30. über die Sicherheit fast mehr sorgen machen muss als alles andere. Dazu habe ich gerade ein nettes Tutorial gefunden, welches ich gerade durchrocke. Es beinhaltet schon viele, wichtige, Schritte. Dazu werde

  31. Vielen Dank für die guten Tipps, damit bist Du in meinen Bookmarks gelandet. Ich weiß zwar nicht ob es wirklich so viele Idioten gibt, die sich einen Spaß draus machen Blogs zu hacken, aber schaden kann es sicher nicht, das Ding ein bisschen sicherer zu machen.

  32. diesem Blog-Beitrag zu dem WordPress-Buch von Frank Bültge gibt der Autor 11 Tipps, wie eine WordPress-Installation sicherer gemacht werden

  33. Danke für deine hilfreichen Tipps. Ich hoffe, wir werden auch in Zukunft noch weitere Postings erhalten. (was ist mit bueltge.de los ? ..) Den HInweis mit der wp-config habe ich gleich umgesetzt.

  34. Leider werden immer neue Lücken im WordPress gefunden wie aktuell das full path disclosure mit dem man die Admins ausperren kann.
    Trotzdem ist meiner Meinung nach WordPress einer der besten Blogsysteme.

    1. Vielen Dank für die hilfreichen Infos! Ich habe gestern mit WordPress begonnen und mich mit Deiner Hilfe dem Thema Sicherheit gut widmen können.

  35. Danke für deine hilfreichen Tipps. Ich hoffe, wir werden auch in Zukunft noch weitere Postings erhalten. (was ist mit bueltge.de los ? ..) Den HInweis mit der wp-config habe ich gleich umgesetzt.

  36. Cool, danke! In wenigen Minuten konnte ich einige der Vorschläge umsetzen und die Seite sicherer machen. Nur der Link zum WP Scanner scheint nicht mehr zu gehen.

Kommentare sind geschlossen.