WordPress absichern – Session auf dem WP Camp 2012 in Berlin

Die Zeiten ändern sich.

Dieser Beitrag scheint älter als 4 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet.

In zahlreichen Abenden und Wochenenden habe ich mich durch eine Masse von Sicherheitsartikeln gelesen und versucht aus der der Menge der Tipps diejenigen herauszufiltern, die wirklich gut sind. Einige Tipps kommen so häufig, dass ich sie nicht unter den Tisch fallen lassen konnte, obwohl deren Sinnhaftigkeit durchaus kontrovers diskutiert werden kann. Herausgekommen ist eine Best-Practice-Sammlung, die zudem zu manchem Snippet erklärt, wo die Probleme dieses Codes liegen. Da diese Slides als Session gehalten wurden, habe ich einige Anmerkungen darunter gemacht, die sehr wichtig sind, um die Tipps einordnen zu können. Zu 100% können Sie aber natürlich nicht den Vortrag ersetzen. Daher …

… bei Unklarheiten, Rückfragen oder auch Lob, nutzt gerne die Kommentare!

Ergänzende Hinweise zu den Folien:

  • Die drei größten Problemfelder:
    – Veraltete Software (laut Sucuri.net >70%)
    – schlechte Zugangsdaten/Passwörter
    – „echte“ Sicherheitslücken
  • Wer aus, aus welchen Gründen auch immer, auf einer WordPress-Version bleiben muss, kann mal schauen, ob das Hotfix-Plugin für diese Version Bugs behebt, die nach dem Realease bekannt wurden.
  • Sehr schlechte Passwörter (da in Angriffen genutzt) hat Wolfgang Pedain aus der Xing-WordPress-Gruppe mal zusammengetragen: http://it-effektiv.de/sicherheit
  • Entscheidend für die Sicherheit ist auch ein guter Hoster, der für PHP/MySQL (und anderes) schnell die Sicherheitsupdates einspielt, wenn dort Lücken gefunden wurden.
  • Der gesamte Block „Security through obscurity„, als alles zum Thema Präfix umbenennen, Usernamen verstecken, Versionsnummer verstecken, wp-content/wp-config verschieben, etc. ist KEIN tragfähiges Sicherheitskonzept, sondern nur eine kleine Möglichkeit sehr einfache Angriffe zu verhindern, die automatisiert abgefeuert werden. Wenn sich ein Hacker explizit mit einem Blog auseinandersetzt, dann sind die meisten dieser „Schutzmaßnahmen“ eher Ansporn als Sicherheitsmaßnahme. In der Session habe ich das hoffentlich deutlich genug betont. Ob sie gar keinen Nutzen haben oder eben diesen von mir erwähnten, kleinen Nutzen, muss jeder für sich entscheiden.

    Nicht ohne Grund hatte ich erwähnt, dass die Core-Entwickler alle Bugtickets zu diesem Thema auf „Won’t Fix“ stellen. Wer mehr Sicherheit möchte, nutzt ein gutes Passwort und sichert über die anderen vorgeschlagenen Wege ab.

  • Das Plugin „Search & Replace“ ändert aktuell bei der vordefinierten USER-ID-Änderung noch nicht die Tabelle „(prefix)_comments“. Frank weiß aber Bescheid und wollte das Plugin schnell aktualisieren.
  • SSL-verschlüsselter Login und Adminbereich ist leider aufgrund der Zeit zu kurz gekommen. Sinnvoll, wenn man ein Zertifikat erworben hat. Wie sinnvoll eine Konstruktion mit Shared-SSL-Lösungen ist, hätte ich gerne mit den Anwesenden diskutiert, aber dafür fehlte die Zeit. Und wie komplex das Thema merkte ich kurz vorher, als ich das Problem in der „Frag‘ den WordPress-Profi“ gestellt habe und auch dort auf die schnelle keine definitive Antwort gegeben werden konnte.
  • Ich befürchte, ich habe nicht überall erwähnt, wo die Snippets eingefügt werden müssen. Bei Unklarheiten einfach hier einen Kommentar schreiben. Ich trage das dann nach. Vielen Dank!
  • Zu den Zugriffsrechten sind wir nicht mehr gekommen. Kurzer Hinweis zu den Dateirechten: 755 für Verzeichnisse und 644 für Dateien ist kein Muss, sondern eine Faustregel. Je nach Server können andere Einstellungen besser sein und mehr Sicherheit bieten. Es gibt Plugins, die Dateirechte prüfen und Änderungen vorschlagen. Nicht blind übernehmen! Weniger Rechte können natürlich belassen werden, wenn der Blog so ohne Probleme auf dem Server läuft.
  • Zum Thema Backup möchte ich noch den kommerziellen Dienst Vaultpress ergänzen.
  • Zum Thema Monitoring: Google Webmaster Tools sind ein gutes, einfaches Tool, um über Probleme (Block wg. Malware zum Beispiel) informiert zu werden. Ersetzt natürlich nicht einen Datei-Komplett-Scan, aber sollte im Repertoire sein.
  • Zum Thema Online-Scanner: Wie jeder Virenscanner können auch diese Scanner nur Dinge entdecken, die es mal geschafft haben Blogs zu infizieren, also hinken sie systembedingt immer hinterher. Ein positiver/negativer Test ist also nie eine 100%ige Aussage, sondern zeigt nur den Weg auf oder liefert Informationen. Mehr nicht! Danach ist eigenes Denken und Handeln angesagt.

Ich freue mich über jede Kritik, Auseinandersetzung, Richtigstellung oder Ergänzung. Lob nehme ich auch … 😉

Nachtrag:
Die Plugins am Ende sind nicht alle getestet worden. Die Liste versteht sich eher als Startpunkt für die eigene Suche nach der individuell besten Lösung. Je nach Paranoia-Faktor und eigenen Entwickler-Kompetenzen…

8 Antworten auf WordPress absichern – Session auf dem WP Camp 2012 in Berlin

  1. Hallo Torsten,

    danke noch mal für den ausführlichen und doch leider viel zu kurzen Vortrag – ich will gar nicht wissen wieviel du dafür recherchiert hast 😉

    Der spannendsten Part waren die „fertigen“ URLs für den Admin User (ID=1) – wieder was gelernt…

  2. Auch von uns noch einmal vielen Dank für die sehr interessante Session!

  3. Also der Vortrag war auf jeden Fall super, aber viel zu kurz. Einen kleinen Teil der Infos habe ich schon mal gleich umgesetzt (Mail on Update). Klasse Beitrag.

  4. Pingback: WP Camp Nachbereitung “WordPress für Einsteiger” « EduPress

  5. Pingback: Mein WP Camp 2012 | Torsten Landsiedel

  6. Pingback: Clever Online Geld Verdienen - der Jahresrückblick 2012/2013!

  7. Pingback: Zusammenfassung WordPress und Sicherheit - WP Meetup Hamburg

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.