Aus verschiedenen Gründen habe ich mich bisher gesträubt, Wordpress in einem größeren produktiven Umfeld einzusetzen. In den Error-Logdateien der diversen von mir betreuten Kundenwebserver fallen die automatischen Scans der Script-Kiddies auf, die systemmatisch überall nach Wordpress-URLs suchen (auch auf statischen Websites :-). Der große Martkanteil (>20%) und die Menge an darauf aufsetzenden weiterführenden Produkten haben mich dann aber doch neugierig gemacht und da ich ein wenig Zeit hatte, habe ich eine kleine Testsite auf Wordpress umgestellt.

Installation

Die Installation war extrem einfach. DNS-Eintrag, Datenbank anlegen, Apache aktivieren, Software uploaden, das Passwort eintragen, eine handvoll Fragen beantworten und man war beim "spaßigen" Teil der Arbeit: dem Layout und den Inhalten. Alle Standard-Einstellungen sahen sehr plausibel aus und es gabe keine unnötigen Plugins.

Meine Vorurteile haben mich dann noch zu den folgenden Anpassungen getrieben:

• der Cron wird exteren ausgelöst und nicht über die Besucher
• das Plugin Wordfence schien mir sinnvoll
• das Plugin WP Update Notifier macht mich auf notwendige Updates aufmerksam
• Nicht benutzte Themes wurden gelöscht

Die Installation und der erst Eindruck waren durchweg positiv. ;-)

Die Testsite war und ist sehr unbekannt. Selbst inklusive aller Robots hat sie nur knapp zehntausend Visits und unter 200.000 Hits je Monat. Wenn man die Robots rausrechnet, bleiben weniger als einhundert Besucher übrig. In den ersten Tagen nach dem Relaunch hat sich der Traffic um mehr als 10% vergrößert. Leider aber nicht die Anzahl der echten Besucher. Offensichtlich wurde die neue Wordpress-Installation sofort gefunden und von den Werkzeugen abgeklopft. Das Wordfence-Plugin in der freien Version wird mehrmals täglich ausgelöst und sperrt IP-Adressen. Die Sorgen bzgl. der Sicherheit scheinen also bregründet zu sein.

Zusammenspiel mit ModSecurity

Bei meinen Webservern setzte ich systemweit das ModSecurity ein. Dieses Server Plugin filtert in verschiedenen Stufen die Anfragen ist stellt quasi eine einfache der Applikation vorgelagerte "Web Application Firewall" (WAF) dar. Die wesentlichen Regeln basieren auf den Empfehlungen des OWASP (The Open Web Application Security Project).

Während Installation und Test hatte ich ModSecurity für die Site deaktiviert. Nach der Reaktivierung gab es erst einmal eine lange Liste von Fehlern und das Administrationsinterface der Site war nicht mehr erreichbar. Eine kurze Querprüfung bei Google ergab, dass das Zusammenspiel mit ModSecurity scheinbar ein häufigeres Problem ist. Den dortigen Antworten traue ich aber nur bedingt, da diese weite Teile von ModSecurity für die Wordpress-Installation einfach deaktivieren. Dies stellt meiner Meinung nach keine wirklich gute Lösung dar. Diesmal gibt es also keine einfache Lösung bei Google... :-(

Abschweifung: Menschliche Schwächen

Das Googlen nach den Problemen mit ModSecurity zeigte aber eine grundlegende Schwäche von
Wordpress:da die Installation so einfach ist, ist nur noch ein geringes Fachwissen notwendig und die
 Vorgaben/Empfehlungen/Regeln der erfahreneren Administratoren werden nur als lästig empfunden.
In vielen Blog-Antworten war ein Unwillen gegen die scheinbare Gängelung mit Sicherheitsvorgaben
spürbar. Wordpress sollte so einfach laufen, wie eine App auf dem Smartphone.

Das ist kein Fehler von Wordpress, sondern eine menschliche Schwäche der Webmaster:
man hat es geschafft eine tolle Software zu installieren,
man hat ein geniales Deisgn,
man hat Texte geschrieben
und die ersten Besucher kommen.
...
 Da will man nicht wirklich auf die Probleme oder Risiken aufmerksam gemacht werden.
Die Idee, die problematischen Regeln einfach komplett für die Site lahmzulegen liegt nahe.

Notwendige Anpassungen von ModSecurity

Gerade bei Sprachen mit Umlauten oder anderen Sonderzeichen ist die OWASP-Regel 981173 ein bekannter "Problemfall", der viele Fehlalarme ("False Positives") verursacht. Die Regel im Detail

/etc/modsecurity/base_rules/modsecurity_crs_41_sql_injection_attacks.conf:
       SecRule ARGS_NAMES|ARGS|XML:/*
       "([\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;\"\'\´\â\â\`\<\>].*?){4,}"   
       "phase:2,t:none,t:urlDecodeUni,block,id:'981173',rev:'2',
       ver:'OWASP_CRS/2.2.7',maturity:'9',accuracy:'8',
       msg:'Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded',
       capture, logdata:'Matched Data: %{TX.1} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',
       tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',
       setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},
       setvar:tx.sql_injection_score=+1,setvar:'tx.msg=%{rule.msg}',
       setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RESTRICTED_SQLI_CHARS-%{matched_var_name}=%{tx.0}"

Diese Regel erzeugt bei einem eingeloggten Administrator für Fehler beim Laden des Stylesheets und der anderen eingebunden Objekte ("Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded").

Zur Lösung habe ich in der Konfiguration des VirtualHosts des Apache folgende Sonderregel für Wordpress aufgenommen:

    # mod_security
  <IfDefine SECURITY>
      <Location /wp-admin>
            SecRuleRemoveById 981173
      </Location>
   </IfDefine>

Dadurch war der Administrationszugang auch mit aktiviertem ModSecurity vollständig nutzbar.

Fazit

Die Installation und die Bedienung von Wordpress ist sehr einfach. Man erhält schnell und ohne viele Fragen eine repräsentative Website.

Da die CMS-Software automatisch als Wordpress erkannt werden kann, steht die Website sehr schnell unter dem automatischen Störfeuer der Hacker. Wenn eine Sicherheitslücke vorhanden sein sollte, wird diese schnell ausgenutzt werden. Daher muss man auf den Regelbetrieb achten und eventuelle Sicherheitsupdates/-patche zeitnah einspielen. Dies ist bei Wordpress vielleicht ein klein wenig wichtiger als bei anderen CMS. Als Freiberufler würde ich mindestens einen um den Faktor 5 erhöhten Wartungsaufwand abschätzen.

Wird Wordpress mein neues Lieblings-Content-Management-System? Eher nicht. Ich habe gar kein Problem damit, eine Wordpress-Installation im Kundenauftrag zu warten oder zu betreiben. Ich persönlich investiere aber lieber ein wenig mehr Zeit in die Installation und spare dafür beim Aufwand für Wartung und Betrieb.

-