Über RSSlounge gab es kürzlich bereits etwas zu lesen – werden die aktiven Leser mitbekommen haben. Da ging es um das deaktivieren der mod_rewrite-Abfrage vom Script. Da ich mich für die Materie sehr interessiere, checkte ich über das Wochenende ein paar Dateien des Scriptes aus und schaute mir die Funktionsweisen an. Dabei viel mir eine Sache auf, die absolut gravierend ist und an die man stets denken sollte, wenn man das Tool in der aktuellen Version (1.7) einsetzt.

Diverse Verzeichnisse sind mit einer .htaccess-File geschützt, welche, man glaubt es kaum, für den Apache konstruiert wurde und auf die Nginx nicht ohne weiteres ansprechen kann. Der beste Punkt kommt jetzt – wenn man Nginx nutzt, greift keine .htaccess, und wenn man wichtige Dateien (z.B. die config.ini) nicht gesperrt hat, so kann diese jeder herunterladen und mit etwas Glück das Teil hacken. Ich staunte also nicht schlecht als ich die File selbst herunterladen konnte, sie mit entsprechendem Tool öffnen konnte und meine Datenbank-Daten sah. Zum Glück grenze ich immer alles schön auf eine DB pro Script ein – macht aber nicht jeder. Sollte es schon länger her sein, empfiehlt es sich die Datenabnk zu checken und ggf. zu löschen und eine neue anzulegen. Über den OMPL-Export und späteren Import gehen keine Feeds verloren.

Stellt sich die Frage, wie man auch ohne .htaccess die Ordner sperren kann UND welche es denn überhaupt sind.
So gehen wir vor:

find . | grep .htaccess
./library/.htaccess
./data/logs/.htaccess
./data/cache/.htaccess
./config/.htaccess
./application/.htaccess
./updates/.htaccess

Beachten: Man muss für diese Aktion im Root des Scriptes befindlich sein oder den Pfad (.) ändern.
Die zu sperrenden Verzeichnisse bekommen wir in der Ausgabe aufgelistet. Nun geht es daran, jedes einzelne in der Nginx-Konfiguration zu sperren. Meine Nginx-vHost-Konfig befindet sich in “/etc/nginx/sites-enabled/”.
Im  “server {“-Bereich muss für jedes Verzeichnis folgendes eingefügt werden:

location /verzeichnis {
        deny all;
}

Das Wort “verzeichnis” muss mit dem jeweiligen Pfad ersetzt werden. Ist das getan den Nginx mittels “/etc/init.d/nginx reload” die Konfigurationen neuladen lassen und testen ob alles Funktioniert. Also die entsprechenden Verzeichnisse und Files testweise aufrufen.
Wenn alles funktioniert bekommt ihr einen 403 – klingt komisch, ist aber in dem Fall so. :D