Die berühmten 10 Tipps zur Erhöhung der Sicherheit deines Blogs gibt es im Netz zuhauf. Sie sind besonders für Anfänger nicht immer leicht nachzuvollziehen. Deshalb habe ich mich bemüht eine möglichst einfache Anleitung zur Umsetzung wichtiger, zusätzlicher Sicherheitsmaßnahmen für deine WordPress-Installation zu verfassen. Sie orientiert sich am Arbeitsablaufs mit herunterladen, hochladen, installieren und konfigurieren von WordPress.
WordPress herunterladen
Du hast die aktuelle deutsche Version von WordPress hier heruntergeladen und im richtigen Ordner entpackt.
Drei Plugins herunterladen
Da du eh grad dabei bist lade dir noch drei wichtige Plugins herunter, um die Sicherheit deiner WP-Installation zu erhöhen, unkompliziert regelmäßige Backups deiner Datenbank zu bekommen und Spams abzuwehren.
- 1.) Limit Login Attempts
- Normalerweise hast du beliebig viele Versuche Nutzernamen und Passwort einzugeben. Bei Fehlversuchen wird dir sogar angezeigt ob Benutzernamen oder Passwort falsch sind. Mit diesem Plug-In wird die Anzahl der vergeblichen Login Versuche standardmäßig auf vier begrenzt, danach ist der Account für 20 Minuten gesperrt. Nach vier solcher Sperrungen erhöht sich die Zeit auf 24 Stunden. Außerdem wird nicht angezeigt ob Name oder Passwort falsch war.
- 2.) WP-DB-Backup
- Nach Aktivierung dieses Plugins könnt ihr es im Backend unter Werkzeuge – Backup für eure Zwecke konfigurieren. Sehr praktisch finde ich dort die Möglichkeit sich das DB-Backup z.B. einmal die Woche automatisch per E-Mail zusenden zu lassen. Diese Mail mit der angehängten Datenbank landet meiner Erfahrung nach oft im Junk-Mail-Ordner des E-Mail-Programmes. Deshalb solltet ihr den Absender dann in die Whitelist des E-Mail-Programmes eintragen (falls vorhanden).
- 3.) Antispam Bee
- Lässt du Kommentare zu ist ein Plugin wie Antispam Bee Pflicht. Das Antispam-Plugin Akismet befindet sich zwar schon standardmäßig in deinem Pluginordner, aber die Biene ist gut an die deutsche Rechtslage angepasst, was man von Akismet nicht gerade behaupten kann.
wp-config-sample-php umbenennen und anpassen
Öffnet diese Datei mit einem geeigneten Editor (notepad++ z.B.). Drei Dinge solltest du dort erledigen:
- 1.) Die Zugangsdaten zu deiner Datenbank eintragen
- Zeilen 18 – 24
- 2.) Gesalzene Passwörter eintragen
- Marschiere zu dieser Adresse. Markiere und kopiere alles was im Browserfenster steht:
- In der wp-config-sample.php siehst du in den Zeilen 44-51 folgendes:
- Markiere die Zeilen 44-51 und füge deine kopierten, gesalzenen Passwörter dort ein:
- 3.) Trage ein individuelles Tabellenpräfix ein
- Schau dir die Zeilen 56-62 an:
- Jede DB-Tabelle die WP erzeugt bekommt im Tabellennamen diese drei Zeichen automatisch vorangestellt (z.B. wp_commentmeta oder wp_posts) Wenn du versuchst zwei WP-Installationen in einer DB zu betreiben ist das grundsätzlich okay, haben beide aber den gleiche Tabellenpräfix hast du ein Problem, nämlich zwei zerschossene WP-Installationen.
- Deshalb gönne jeder deiner WP-Installationen ein eigenes Tabellenpräfix z.B.:
Ob eine Änderung des Tabellenpräfix auch aus Sicherheitsgründen sinnvoll ist kann ich hier nicht abschließend beantworten. Wenn ihr mögt schaut dazu euch diesen Beitrag an und folgt vor allem der damit verlinkten Xing-Diskussion.
Hast du die drei Punkte abgearbeitet speicherst du die wp-config-sample.php unter dem Namen wp-config.php im obersten Verzeichnis deines WP-Ordners ab.
WordPress-Version verschleiern
Normalerweise wird im Kopfbereich einer Seite standardmäßig die WordPress-Version mit ausgegeben. Lasst euch einmal den Quelltext anzeigen (Rechtsklick ins Browserfenster und entsprechenden Verweis wählen z.B. Seitenquelltext anzeigen) Ziemlich weit oben steht diese Zeile z.B.: <meta name="generator" content="WordPress 3.3.2" />
Das wollen wir Angreifern nicht unbedingt auf die Nase binden, also raus mit dieser Zeile.Öffnet dazu mit eurem Editor die functions.php eures Themes. Ihr findet sie unter wp-content – themes – deinThemename – functions.php.
Dort hängt ihr einfach diese beiden Zeilen an:
function no_generator() { return ''; }add_filter( 'the_generator', 'no_generator' );
Speichern und schließen und fertig. Das wars schon!
Eine leere index.php in den Ordner uploads legen
Sämtliche Fotos, Bilder, etc. die ihr hochladet werden standardmäßig im Ordner wp-content - uploads gespeichert. Dieser Ordner benötigt sehr weitgehende Rechte, damit dass mit dem Hochladen auch immer reibungslos klappt. Solche Rechte sind aber auch immer ein potentielles Sicherheitsrisiko.
Wir erstellen einen Ordner mit dem Namen uploads im Verzeichnis wp-content. Mit unserem Editor erzeugen wir eine neue Datei und speichern die unter dem Namen index.php im Ordner uploads ab. das ist alles. Ein unbefugter Eindringling rennt jetzt erst mal vor eine leere Datei, mit der er nichts anfangen kann.
Ihr ladet WordPress auf euren Server hoch installiert es und geht gleich mal ins Backend. Da wirst du nun verschiedene sicherheitsrelevante und somit wichtige Aktionen durchführen.
Limit Login Attempts, WP-DB-Backup und Antispam Bee aktivieren
Aktiviert sie und konfiguriert sie nach euren Wünschen. Ein DB-Backup könnt ihr euch ja gleich mal probehalber runterladen und abspeichern.
Neuen Benutzer anlegen und den Standardbenutzer löschen
Backend - Benutzer – Hinzufügen
Tragt unter Benutzernamen einen Namen (außer admin!) ein. Da der Benutzername oft auch zu Artikeln und Kommentaren, z.B. in der URL oben, mit angezeigt wird muss der nicht kompliziert sein. Gebt eine gültige E-Mail-Adresse an und schreibt ein starkes Passwort (mindestens 14 Zeichen, inkl. Groß/Kleinschreibung, Zahlen und Sonderzeichen!) in die entsprechenden Felder.
Achtung stellt als Rolle unbedingt "Administrator" ein und übernehmt keinesfalls das voreingestellte "Abonnent"!!
Meldet euch jetzt im Backend ab (oben rechts wo "Willkommen DeinName" steht). Meldet euch mit dem neuen Benutzer wieder an. Löscht den alten Benutzer und vergesst nicht alle Artikel u. Links zu übertragen.
Dann ruft ihr den neuen Benutzer auf (Bearbeiten).
Nehmt das Häkchen bei Werkzeugleiste - Werkzeuge für mich auf der Website anzeigen raus. Das mag überflüssig sein, aber ich traue dem Braten instinktiv nicht so recht. 
Tragt unter Vornamen und Spitzname euren öffentlichen Namen ein und seht zu, dass dieser auch bei Öffentlicher Name ausgewählt ist. Profil aktualisieren und fertig!
Zweiten Benutzer zum Artikelschreiben anlegen
Wenn ihr Artikel schreibt macht das nicht mit dem Benutzer, der Adminrechte hat, sondern legt dazu einen weiteren Benutzer an, dem ihr höchstens die Rolle Autor zuweist.
Sicher werdet ihr neben anderen Einstellungen im Backend auch noch dafür sorgen, dass WordPress sogenannte sprechende Links erzeugt. das wird unter Einstellungen – Permalinks erledigt. Infos dazu findest du auf dieser Seite.
Hat das geklappt solltest du dich daranmachen, die Dateirechte für zwei wichtige Dateien einzuschränken.
Dateirechte .htaccess und wp-config.php zurückschrauben
Um diese Rechte anzupassen werft ihr euer FTP-Programm ( z.B. Filezilla) an. Die beiden Dateien dümpeln im obersten Verzeichnis von WP vor sich hin.
Rechtsklickt auf eine Datei (hier .htaccess) im Serverfenster und wählt den entsprechenden Verweis:
Dann öffnet sich dieses Fenster:
Durch Anklicken der Kästchen erzeugt ihr den numerischen Wert 444:
Mit der gleichen Vorgehensweise ändert ihr die Dateiberechtigung der wp-config.php auf den numerischen Wert 444.
Zum Schluss noch ein paar Binsenweisheiten zum Thema WordPress und Sicherheit:
Eines der größten Sicherheitsprobleme von WP sind imho schlecht programmierte Plugins, die einem Angreifer Tür und Tor öffnen!
Deshalb:
a.) Das Offiziellen Plugin-Directory von WP kennt ihr vielleicht schon, aber die Plugins die dort angeboten werden solltet ihr kritisch bewerten, bevor ihr sie euch runterladet und installiert.
b.) Schaut deshalb und überhaupt was bekannte WP-Größen wie Frank Bültge, Sergej Müller, Perun, Toscho, Monika oder Heiko vom Code Styling Project so schreiben und empfehlen
c.) Nur so wenig Plugins wie unbedingt nötig installieren und nicht aktive Plugins löschen
d.) Wenn sich etwas mit Bordmitteln regeln lässt macht es und verzichtet auf ein Plugin
Überlegt euch gut welchem Benutzer ihr welche Rechte einräumt, ein Blog mit 84 Administratoren dürfte keine so gute Idee sein.
Zum bequemen neben die Tastatur legen stelle ich euch den Beitrag als Pdf-Datei in diesem Ordner zum Download zur Verfügung. Zusätzlich ist dort auch noch eine Checkliste zum hinlegen und abhaken dabei.
Lest bitte unbedingt die Kommentare zu diesem Artikel, dort steht mehr wissenswertes und auch kontroverses zur Sicherheit von WordPress.
Pingback: Sinnvolle Aktionen zur Sicherheit von Wordpress?? - Seite 2 - XHTMLforum
Servus!
Muss Dich jetzt einmal ein wenig ergänzen. Security through Obscurity bringt nicht viel. Und der Login-Name wird oft auch zu Artikeln od Kommentaren angezeigt, ist also wurscht. Lieber ein 14 Zeichen langes Pwt mit Sonderzeichen, etc. Und einen nicht Admin-Account zum Posten verwenden.
Punkto Repo und Downloadzahl: hab nur ein Plugin im Repo und das hat gerade mal 1,500 Downloads, ist aber mit Brief und Siegel zig mal besser programmiert, als andere mit einer Million. Denk nur mal an die Diskussion, die wir alle wegeb GD Star Ratings und dem Bewertungssystem des Autors geführt haben.
Und zum Repo noch: Ich traue dem Repo nicht weiter, als ich es werfen kann. Alle meine größeren Plugins findet man auf Github – wo zehn mal besserer Code sein zu Hause hat.
Moin Franz Josef,
ich hatte inständigst gehofft das jemand meckern würde, damit ich diesen Artikel zum besten aller modifizieren kann!
Deshalb danke ich dir ausdrücklich für deinen Kommentar!
Jetzt war ich so damit beschäftigt, den Artikel möglichst einfach zu halten und alles schön in den logischen Ablauf des Aufbaus einer WP-Installation zu integrieren, dass ich meine eigenen Artikel dazu vergesse….umpf….
Sicherheitslücke durch Gestaltungsmöglichkeit und
SiLü durch Ausgabe Loginname
Ich werde das prüfen und ggf. in den Artikel einbauen.
Außerdem passe ich die Binsenweisheiten zum Thema Plugins entsprechend an.
Wg. verschärftem Wochenende komme ich wahrscheinlich erst nächste Woche dazu es zu ändern, aber es wird 100%ig gemacht!
Über weitere Meckereien würde ich mich ebenfalls freuen, falls du oder jemand anderes Zeit und Muße hat! Ein diesbezüglicher Aufruf gehört auch noch ans Ende des Artikels, oder an den Anfang, mal schauen.
edit. Als kleinen Nachteil bei Github finde ich dass es für Anfänger eher sperrig ist. Wenn ich mich richtig erinnere gibt es zu den dort hingestellten Plugins nicht immer eine readme. Gibt es eine ist sie (fast) immer nur in Englisch (was den Jungen i.d.R. kein Problem bereitet) und leider oft genug so dürftig gehalten dass es für die nicht so Erfahrenen eher unverdaulich ist.
Persönlich ist es mir auch schon so gegangen: Es wurde auf Github verwiesen, ich marschiere hin und bin mit einem Haufen PHP’s nebst äußerst dürftiger readme konfrontiert. …..äh…..schön das wir drüber reden konnten…und unverrichteter Dinge ziehe ich von dannen.
Wenn man über Sicherheit spricht, dann bitte nur darüber. Hier fliegt mir zu viel durcheinander.
Backups sind sicher wichtig, um ein System wieder herzustellen, sie schützen aber nicht vor einem Einbruch. Und wie Franz-Josef schon geschrieben hat: Verschleiern sollte nicht Teil eines Sicherheitskonzeptes sein. Wenn ein System sicherer wird, indem man den Nutzernamen versteckt, dann ist es schon kaputt. (Und Spam ist ohnehin ein ganz separates Thema.)
Gleiches gilt für Directory-Listings: Bei einem normal eingestellten Server sind die völlig harmlos, die Schreibrechte hat man ja hoffentlich nur dem PHP-Prozess gegeben. Wer aber 777 einsetzt, wird auch mit einer index.php nicht sicherer. Dafür gibt es übrigens eine Direktive für die .htaccess, die man mit einem Fehlerdokument kombinieren kann:
Options -IndexesErrorDocument 403 /403.phpDas spart die überflüssigen Dateien. Was ist eigentlich so schlimm an einer frei zugänglichen .htaccess? Stehen darin deine Passwörter?
Gut ist der Tipp, Passwort-Tester auszusperren. Hier finde ich das Plugin Login LockDown am besten. Es sperrt nicht Konten, sondern IP-Adressen. Und genau das möchte man ja: Ich will doch nicht anderen Leuten das Recht einräumen, mein Konto sperren zu lassen. Das Ausblenden des Anmeldefehlers sollte man besser nicht gestatten, damit versaut man sich nur die Nutzerfreundlichkeit, ohne etwas Substantielles zu gewinnen.
Bei Plugins ist nicht die Quelle wichtig, sondern ob man den Code verstanden hat. Wer das nicht kann, sollte auch keine administrativen Rechte für eine Website haben. Das klingt vielleicht ein wenig hart, aber die Alternative ist eben, daß man früher oder später zwangsweise Schadcode installiert. Man kann die Gesetze der Statistik nicht mit einer Readme umgehen.
Moin Thomas,
danke für deine Antwort und deine Mühe!
Deine verlinkte Beispiel-.htaccess füge ich mit einer zusätzlichen Mahnung obigem Downloadordner hinzu, wenn das in Ordnung ist.
Ist es das nicht, genügt eine kurze Nachricht, dann ist sie wieder draußen.
Je mehr ich darüber lese oder Diskussionen und/oder Kommentare hier verfolge desto größer wird das Gestrüpp in dem man sich bewegt. Ich finde es schwer vernünftige Sicherheitstips zu geben, da die Meinungen darüber teilweise weit auseinandergehen.
Deshalb sind mir alle Meinungen dazu wichtig, wobei die aus kompetentem Munde sicher mehr Gewicht haben.
Meine Intention bei dem Artikel war keine absolute Sicherheitsstringenz, sondern etwas auch für Anfänger nachvollziehbares und leicht in den ganzen Install/Konfigprozeß von WP integrierbares.
Deshalb habe ich Änderungen der .htaccess auch mal außen vor gelassen. Dein Beispiel ist aber imho ein schöne Ergänzung des Artikels.
Wer versteht schon den Code von Plugins so ganz? Ich vielleicht ein ganz kleines bisschen (wenn ich mir mal viel Zeit nehme) aber die meisten sicher überhaupt nicht. Wer vollzieht schon den Code eines Plugins nach, oder besser gefragt: wer hat die Zeit dazu?
Das ich mir Schadcode installiere glaube ich jetzt mal eher nicht, da ich ziemlich versiert darin bin, um die Gesetze der Statistik drum rumzuschleichen.
Alle sprechen über die WP Sicherheit.
Kann mal jemand sich der FTP Sicherheit annehmen?
Ist das nicht die größte Sicherheitslücke, wenn man normales FTP verwendet?
Hierzu ein Artikel wäre echt hilfreich.
Klaus was du hier geschrieben hast kann ich nur unterstreichen und sag Dir Danke für die super leicht und toll erklärten Anweisungen mit Screenshots die mir am meisten helfen….”
ich habe fürs erste das Plugin Wordfence Security installiert das braucht aber viel Speicherplatz so wie es aussieht. Ich denke ich versuch mal deine Anleitungen. Zum Backup da hatte ich lange das Plugin das du empfiehlst und bin umgestiegen auf Backup move da bekommt man die Dateien wie bei einem FTP backup. Antispambee benutze ich schon lange.
Ich dank dir nochmal das du das so klar nachvollziebar erklärst denn Configphp und andere PHP Dateien zu verändern ist für Nichtprofis eher ein Not to do, ich hab schon zweimal mit schlechten Erklärungen eine Seite zerhauen…
Susanne
schön dass dir der Artikel geholfen hat!
An den Kommentaren, wie auch z.B. an meinem vorherigen Artikel, besonders mit der verlinkten Xing-Diskussion siehst du, was für ein weites Feld die Sicherheit ist und wie sich selbst Experten in so manchen Punkten überhaupt nicht einig sind.
Hi die WordPressverschleierung funktioniert nicht, ist da nen Fehler im Code.
Bei uns wird da nen Parse Error ausgegeben.
Hi, sorry bin grad erst aus dem Urlaub zurück.
Das habe ich vorher problemlos getestet. Hast du den Code vorher z.B. kurz in den Windowseditor hinein- und wieder -herauskopiert? Beim direkten Copy/Paste in die functions.php kann es zu Fehlern kommen, weil evtl. irgendwelche Formatierungen mit übertragen werden.
Wie sieht denn die Fehlermeldung genau aus?
Hab es an das Ende der function gesetzt und dann erscheint Parse error: parse error in C:xampphtdocswordpresswp-contentthemeseliministfunctions.php on line 461
Irgendwas scheint in der Syntax nicht zu stimmen. Wenn ich den Code irgendwo zwischen die function setze wird mir mein restlicher Code nur noch in grau ausgegeben (nutze Notepad++)
Der Fehler liegt in der Funktion
no_generator(), eines der beiden Anführungszeichen ist falsch. Man braucht diu Funktion eigentlich auch nicht hierfür, in WordPress gibt es__return_null(), das man als Callback verwenden könnte.Ah jetzt gehts, recht herzlichen Dank an Euch.
Thomas hat recht, es war mein Fehler!
Habs auch gleich geändert.
Hi Klaus,
was ist eigentlich mit dem pdf in wp-sicherheit-anfaenger.zip ?
kann man nicht mehr daownloaden.
gruss
ups….danke für den Hinweis, habe ich sofort korrigiert!
Pingback: Chat-Thread - Seite 2194 - XHTMLforum