Dafür habe ich jetzt die Lösung gefunden: Ich schreibe die Artikel dann, wenn ich Zeit und Lust habe und setze das Veröffentlichungsdatum auf ein Datum in der Zukunft. Diese Funktion gibt es schon viel länger, aber irgendwie habe ich sie nie wirklich wahrgenommen und ihren Nutzen erkannt… und nun habe ich sie bereits mehrfach angewandt! Das ist wirklich klasse! Aber, dass mir das nicht früher in den Sinn gekommen ist… *kopfschüttel*

Beim Wechsel des Farbschemas habe ich mir natürlich nicht die Arbeit gemacht und alle RGB-Werte manuell geändert…

Skript zum Permutieren des Farbschemas eines Stylesheets

Dieses Pythonskript permutiert die in einem Stylesheet vorhandenen RGB-Werte (RGB-Werte spezifizieren den Anteil von Rot, Grün und Blau einer Farbe) in alle Kombinationen von 3 Elementen. Damit bleiben bei den meisten Kombinationen die Relationen zwischen den Farben erhalten und ein unkomplizierter Wechsel zu einer anderen “Grundfarbe” ist möglich.

Download generateColorPermutations.py.zip

Das Skript wird folgendermaßen aufgerufen: [python] generateColorPermutations.py <file.css>

Die Ausgabe der nach verschiedenen Kombinationen permutierten Stylesheets erfolgt in einen Ordner, der nach der Eingabedatei benannt ist. Bei einem Stylesheet mit dem Namen robertnitsch.de.css also in einen Ordner robertnitsch.de.css/. Darin befinden sich später die Dateien robertnitsch.de_111.css, robertnitsch.de_112.css usw. Der Ordner wird automatisch angelegt, falls nicht vorhanden.

Wie das Skript arbeitet ist relativ unwichtig für den Anwender, den ja nur die Ergebnisse interessieren. Man sollte einfach mal die Ergebnisse austesten, wenn man das Farbschema wechseln möchte. Man wird bestimmt das ein oder andere neue Farbschema finden, das etwas hermacht. Alle, die wissen wollen, wie das Skript arbeitet, werden sich das Skript ansehen müssen.

Aus diesem Grund habe ich jetzt das Plugin “Bad Behavior” (http://www.bad-behavior.ioerror.us/) in Betrieb genommen. Eventuell schaue ich mir dessen Code mal an und beschreibe, wie es im Detail funktioniert.

Ansonsten hoffe ich, dass noch alles wie gewohnt funktioniert… und natürlich hoffe ich auch, dass unschuldige Benutzer nicht fälschlicherweise als Spammer “erkannt” werden.

• Nutzen
• /wp-admin passwortschützen
• Absoluten Serverpfad ermitteln
• Benutzerdatei anlegen
• Passwörter verschlüsseln
• Benutzerdatei fertigstellen
• /wp-include Ordner schützen
• Abschließende Hinweise
• Weblinks

Dieser Eintrag handelt von WordPress. Genauer gesagt geht es darum WordPress mit sogenannten .htaccess-Dateien abzusichern. .htaccess-Dateien können allerlei Regeln beinhalten, die bestimmen wie mit Dateianfragen umgegangen werden soll. Es gibt viele Beispiele, was man mit .htaccess alles anstellen kann, z.B.:

- Verzeichnisse für bestimmte IPs, IP-Bereiche oder für jeden zu sperren
- Verzeichnisse mit einem Passwort schützen (es können mehrere Benutzernamen definiert werden, mit denen man zugreifen darf!)
- alle diese Regeln können natürlich auch auf bestimmte Ordner/Dateien begrenzt werden

Uns geht es aber hauptsächlich darum,

- das /wp-admin Verzeichnis mit einem Passwortschutz zu versehen. Doppelter Schutz!
- das /wp-include Verzeichnis für den Zugriff von außen komplett zu sperren (nur .php-Dateien sollen gesperrt werden)

Nutzen:

Damit kann man einem “bösartigen” Besucher das “Leben” durchaus erschweren. Denn: ohne Zugriff auf den /wp-admin Ordner bekommt man nicht mal den normalen Admin-Login von WordPress zu Gesicht. Falls es also Sicherheitslücken im Loginskript gibt, so ist man aufs Erste geschützt, auch ohne sofort ein Update einspielen zu müssen (was man natürlich trotzdem tun sollte!!). An den Login kommt man ja nur durch einen vorherigen Login heran (.htaccess ist bereits seit vielen Jahren erprobt und gilt als sehr sicher – im Gegensatz zu den meisten PHP-Skripts).
Das /wp-include Verzeichnis ist für den normalen Benutzer sowieso nicht von Bedeutung. Es gibt aber durchaus Techniken, mit denen ein “Hacker” Sicherheitslücken innerhalb der .php-Dateien in diesem Verzeichnis aufspüren und ggf. ausnutzen kann. Wir verbieten aber gleich sofort den gesamten Zugriff und schließen damit weitere Sicherheitslücken aus.

/wp-admin passwortschützen:

Jetzt wollen wir mal loslegen. Zuerst müssen wir das /wp-admin Verzeichnis mit einem Passwort versehen. Dazu erstellen wir eine Datei mit dem Namen .htaccess und folgendem Inhalt:

AuthType Basic
AuthName “WordPress Administration”
AuthUserFile /absoluter/serverpfad/zurbenutzerdatei/.htaccess_wordpress
require valid-user

Diese Datei muss jetzt in das /wp-admin Verzeichnis hochgeladen werden.

Erklärung:
In der ersten Zeile wird der Passwortschutz “eingeleitet”. In der zweiten Zeile wird dem geschützten Bereich ein Name gegeben. Die dritte Zeile ist wichtig! Hier muss der absolute (Server-)Pfad zur Benutzerdatei angegeben werden.

Absoluten Serverpfad ermitteln:

Der absolute Serverpfad kann relativ leicht ermittelt werden. Man muss eine Datei mit dem Namen pfad.php und folgendem Inhalt erstellen, in das WordPress-Verzeichnis hochladen und dann mit dem Browser aufrufen:

<?php echo "Der absolute Pfad zu diesem Verzeichnis ist: ".$_SERVER['DOCUMENT_ROOT']; ?>

Benutzerdatei anlegen:

Die Benutzerdatei sollte man in ein Verzeichnis legen, das nicht über die Domain zugreifbar ist. Am besten wäre das Verzeichnis, das eine Ebene über der WordPress-Installation liegt. Noch besser wäre das “allerhöchste” Verzeichnis.

Die Benutzerdatei beinhaltet alle Benutzer mit den dazugehörigen Passwörtern. Das Schema für ihren Inhalt lautet folgendermaßen:

benutzername:passwort
hans:nadine1987
joerg:petra1976

(Die Passwörter, die hier beispielhaft gezeigt werden, sind natürlich keine Musterpasswörter. Sie sind weit davon entfernt, sicher zu sein.)

Also pro Zeile ein Benutzer. Benutzer und Passwort werden durch einen Doppelpunkt getrennt.

Passwörter verschlüsseln:

Es fällt außerdem sofort auf, dass die Passwörter hier im Klartext lesbar sind. Gelingt es einem Hacker doch einmal, den Webspace oder den ganzen Server zu hacken, so wird er auch an diese Passwörter gelangen. Das kann man jedoch mit einer sogenannten Einweg-Verschlüsselung unterbinden.

Dazu benötigen wir noch ein Skript mit dem Namen crypt.php und diesem Inhalt:

<?php
    if(!empty($_GET['text']))
    {
        $text=$_GET['text'];
 
        echo 'crypt('.htmlspecialchars($text).') = '.crypt($_GET['text']);
    }
    else
    {
        echo 'This script encrypts strings with the crypt()-function. e.g.: "crypt.php?text=<thestringyouwanttoencrypt>"';
    }
 
    echo '&copy; www.robertnitsch.de';
?>

Dieses Skript kann dann ebenfalls auf den Webspace hochgeladen und über den Browser aufgerufen werden. Zum Beispiel wird http://www.domain.tld/wordpress/crypt.php?text=test den verschlüsselten Wert von “test” berechnen. Dieser sieht zum Beispiel so aus:

$1$Udvw2Yfc$XGUZ6EZFvTC/.9r9.99yX1

Offensichtlich ist das ganz schönes Kauderwelsch. Diese Verschlüsselung kann man auch nicht rückgängig machen.

Wir tragen die verschlüsselten Passwörter genauso ein wie die nicht verschlüsselten, z.B.:

test-user:$1$Udvw2Yfc$XGUZ6EZFvTC/.9r9.99yX1

Auf diese Weise ist auch unsere Benutzerdatei einigermaßen sicher.
Hinweis:
Das Mischen von verschlüsselten und nicht verschlüsselten Passwörtern in derselben Benutzerdatei ist nicht möglich. Entweder es sind alle Passwörter verschlüsselt oder gar keines.

Benutzerdatei fertigstellen:

Die Benutzerdatei muss jetzt noch angelegt werden – wir waren ja wegen der Verschlüsselung noch nicht soweit. Der Dateiname sollte .htaccess_wordpress sein. Wie bereits beschrieben müssen die Benutzernamen und jeweils mit einem Doppelpunkt davon getrennt die Passwörter eingetragen werden. Unbedingt vorher mit crypt verschlüsseln (wie oben beschrieben)! Der absolute Pfad zu der Benutzerdatei musst jetzt noch in der .htaccess-Datei eingetragen werden – falls noch nicht geschehen. Ggf. müssen wir die .htaccess-Datei neu hochladen, damit die Änderung des absoluten Pfades überhaupt wirksam werden kann.

Ab jetzt sollte bei jedem Zugriff auf das /wp-admin Verzeichnis eine Passwortabfrage erscheinen. Wenn alles klappt, dann fahren wir jetzt mit dem Absichern des /wp-include Verzeichnisses fort.

/wp-include Ordner schützen:

Wir erstellen eine weitere Datei “.htaccess” mit dem folgenden Inhalt:

# alle PHP-Dateien fuer den Zugriff von außen sperren
<FilesMatch \.php$>
Order deny,allow
deny from all
</FilesMatch>
 
# tinymce (der what-you-see-is-what-you-get-editor beim schreiben von eintraegen)
# muss zugaenglich sein
<FilesMatch ^tiny_mce>
allow from all
</FilesMatch>
<FilesMatch ^wp\-mce>
allow from all
</FilesMatch>

Wir speichern diese Datei im /wp-include Verzeichnis. Danach ist auch dieses Verzeichnis sicher und wir sind eigentlich fertig.

Abschließende Hinweise:

Bei manchen Anbietern sind diverse Funktionen von .htaccess nicht verfügbar oder gesperrt. In diesem Fall wird ein “Internal Server Error” mit dem Fehlercode 500 auftreten.
Wenn Syntaxfehler oder ähnliche Fehler in den .htaccess-Dateien vorhanden sind, dann wird beim Zugriff auf das entsprechende Verzeichnis bzw. auf die entsprechende Datei ebenfalls ein “Internal Server Error” mit dem Fehlercode 500 auftreten.
Falls unerwartete Probleme auftreten könnt ihr gerne die Kommentar-Funktion nutzen und somit Hilfe einholen.

Wenn etwas partout nicht funktionieren will kann die .htaccess-Datei problemlos wieder vom Webspace entfernt werden. Die Regeln werden damit sofort außer Kraft gesetzt. (Möglicherweise müsst ihr noch euren Browsercache leeren!)

Weblinks:

SelfHTML: .htaccess – Server-Reaktionen kontrollieren
PC-Projekt: .htaccess – Dateien einsetzen
SoftwareGuide: .htaccess und Mod-Rewrite für CMS und Blog

Ich wäre selbst wirklich nicht mehr darauf gekommen: die Dateirechte beim Hochladen mit WordPress werden falsch bzw. unzureichend gesetzt. Das heißt konkret: wenn man Dateien mit WordPress hochlädt, dann stattet WordPress diese Dateien mit falschen bzw. unzureichenden Zugriffsrechten aus. Eine Änderung in WordPress’ Code hat den Fehler jetzt aber hoffentlich behoben. Das möchte ich in diesem Beitrag auch gleich ausprobieren.

Wenn ihr den folgenden Screenshot ansehen könnt (in Vollbildansicht), dann funktioniert es ja:

Falls ihr da draußen das selbe Problem habt, wie ich es hatte, dann sei euch folgendes nahe gelegt: domainfactory Supportforum – Upload Rechte WordPress

Dort wird genau beschrieben welche Dateien ihr wie bearbeiten müsst, damit WordPress die Dateien richtig hochlädt. Vielleicht hilft es euch ja.