ich höre von einigen Leuten, dass bei denen der Speicherverbrauch zu hoch sei. Ich setze mittlerweile mehr als 26 Plugins ein und auch die deutsche Sprachdatei und bei mir liegt der Speicherverbrauch bei 22,7mb (35%).

Könnte hier nicht evtl. die Servereinstellung oder z. B. der Einsatz der Versions-Verwaltung der Artikel eine Rolle spielen? Frage an die Server-Experten.

Nachtrag: habe jetzt die Antwort auf meine Frage gefunden.

Die Frage die mich am brennendsten interessieren würde, wie der Hack nämlich zustande kam, wird leider nicht beantwortet. Lag es daran das die betroffenen Blogs so "sichere" Passwörter wie "Schatzi" und "1234" verwendet haben? Dann kann man sich das Updaten gleich mal sparen. Genauso wie man sich in so einem Fall den .htaccess-Schutz schenken kann.
Oder sind die Angreifer (mal wieder) über eine Schwachstelle in WP in das System eingedrungen? Dann ist es irgendwie nur eine Frage der Zeit bis eine vergleichbare Schwachstelle auch in der neusten Version auftaucht und das Spiel von vorne los geht.

Ich habe so langsam das Gefühl das solche Angriffe vom WordPress-Team initiiert werden damit die Leute ja auch alle brav auf die neueste Version updaten und man sich um die älteren Versionen nicht mehr kümmern muss.

Der Artikel von Sergej mit den 10 Sicherheitsratschlägen ist lesens- und befolgenswert. Mit den richtigen Schutzmaßnahmen in der .htaccess-Datei kann man schon deutlich das Schutzniveau erhöhen.

Darüber hinaus werde ich mir das Sicherheitskapitel aus dem neuen Buch von Frank Bültge in Kürze durchlesen und so gut es geht umsetzen.

Ich bin der Meinung, dass man dann doch den Hoster wechseln sollte als Opfer einer Attacke zu werden. Aber du hast schon Recht, jeder entscheidet selbst. Finde ich nur schade.

was du in dem Zusammenhang nicht vergessen darfst ist z. B. die Tatsache, dass viele Hoster keinen Zugriff auf die .htaccess erlauben. Damit sind z B. viele Schutzmaßnahmen nicht möglich.

Und auch all-inkl bietet standardmäßig lediglich den Einsatz von SSL-Proxy (https://ssl-account.com/domain.de) damit kann man dann auch nicht den Admin-Bereich verschlüsseln … zumindest define('FORCE_SSL_ADMIN', true); erwartet https://www.domain.de. Hier müsste man schauen welche Möglichkeiten es noch gibt.

Ist vielleicht noch mal interessant zu erwähnen!

Ich hatte meinen Artikel mit den 10 Ratschlägen im eigenen Blog und bei Smashing Magazine veröffentlicht. Müsste doch jeder kennen oder? Aber nein, im Februar auf dem WordCamp hatten alle über den Artikel gelacht und als nutzlos betrachtet.

Aber das ist immer so: Sicherheitstipps ignorieren und später Stunden, Tage beim Restoren der Daten verbringen. Naja, aus Fehlern lernt man, hoffentlich.

danke für den Link. Mir persönlich wäre der einfache Weg zu brenzlig, aber ich bin auch kein Sicherheitsexperte.