HowTo: CMSms Sicherheit ab Version 1.6.6

LeisureLarry · **Posted:** Tue Nov 03, 2009 3:15 pm

Da meine beiden alten Sicherheitsbeiträge so gut angekommen ist und wir inzwischen bei Version 1.6.6 angekommen sind, möchte ich nun einen aktualisierten Beitrag starten (ohne den letzten Stand für V1.4.1 zu verlieren).

Schritt 1 (Stand 18.11.2009):

Denkt Euch ein sicheres Admin-Kennwort aus und benutzt sinnvoller Weise nicht den Benutzernamen admin, administrator oder den Benutzernamen aus diesem bzw. anderen Foren. Ein einigermaßen sicheres Kennwort enthält Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen. Es sollte eine Länge von mindestens 8 Zeichen haben.

http://aktuell.de.selfhtml.org/artikel/gedanken/passwort/index.htm

Tim Bormann hat in seinem Blog einen kurzen Artikel zu dem Thema Passwort-Sicherheit und Passwort-Erstellung veröffentlicht. Nehmt Euch die dortigen Informationen zu Herzen.

Schritt 2:

Umbenennen des Ordners admin per FTP und Anpassung Eurer config.php. ACHTUNG: Man benötigt Schreibrechte für die config.php, also beispielsweise chmod 666.

Code:

$config['admin_dir'] = 'xyz';

Ergänzung: Löscht die Angabe zum Admin-Ordner komplett aus Eurer robots.txt in Eurem CMS-Hauptordner. Verseht besser den neuen Admin-Ordner mit einem zusätzlichen .htpasswd/.htaccess-Schutz. Dies verhindert ebenfalls eine Indexierung der Admin-URL, aber ohne jedem zu zeigen wie sie ist (Stichwort robots.txt für jeden Besucher lesbar).

Schritt 3:

Nur noch Leserechte auf die config.php erteilen. Per FTP den chmod der config.php beispielsweise auf 444 ändern.

Schritt 4:

In Eurer .htaccess-Datei im Hauptordner Eures CMSms befindet sich nachfolgender Code.
Hinweis: Die Datei ist nur vorhanden bei Nutzung von Pretty-URLs, eine Vorlage befindet sich in der Datei htaccess.txt im doc-Ordner.

Code:

# (this is important, so uncomment if your host permit)
#Options -Indexes
#ServerSignature Off

Nehmt wie empfohlen das Kommentarzeichen # vor Options und ServerSignature weg.

Ergänzt nach diesem Code noch den nachfolgenden Bereich.

Code:

# BEGIN Optional settings

# Deny access to config.php and CHANGELOG.txt
# The former can be useful if php ever breaks or dies
# Use with caution, this may break other functions of CMSms that use a config.php
# file.  This may also break other programs you have running under your CMSms
# install that use config.php.  You may need to add another .htaccess file to those
# directories to specifically allow config.php.
<Files ~ "config.php|CHANGELOG.txt">
order allow,deny
deny from all
</Files>

# END Optional Settings

Schritt 5:

Sperrt diverse Hack-Möglichkeiten und auch noch gleich die bekanntesten Spam-Bots mittels .htaccess aus.

Code:

# unterbindet, das fremde Seiten geladen werden
RewriteCond %{QUERY_STRING} ^(.*)=http://(.*) [OR]
# blockiert libwww (Ausgangspunkt für diverse Hackversuche)
RewriteCond %{HTTP_USER_AGENT} ^libwww [OR]
# Blockiert Skripte, die versuchen, base64 encodierten Unsinn via URL zu versenden
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Blockiert Skripte, die einen a ********** Tag in der URL enthalten
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Blockiert Skripte, die versuchen, PHP GLOBALS Variablen via URL zu verändern
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Blockiert Skripte, die versuchen, eine _REQUEST Variable via URL zu verändern
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Spambots nach User_agent aussperren
RewriteCond %{HTTP_USER_AGENT} ^.*Whacker.*$ [OR] 
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR] 
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR] 
RewriteCond %{HTTP_USER_AGENT} ^.*FileHound.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*TurnitinBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*JoBo.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*adressendeutschland.*$
RewriteRule ^.* - [F]

Hinweis: Fügt den Code in Euer .htaccess im CMS-Hauptordner direkt unter RewriteBase ein.

Schritt 6:

Erstellt eine neue .htaccess-Datei für Euer lib-Verzeichnis.

Code:

order deny,allow
deny from all
<Files ~ ".*\.css|.*\.js|.*\.gif|.*\jpe?g|editor.php|thumbs.php|images.php|xajax.js|xajax_uncompressed.js|editorFrame.php$">
Order deny,allow
Allow from all
</Files>

Ergänzung: Ich bräuchte eine Rückmeldung, wo es hiermit eventuell noch Probleme gibt.

Erstellt danach eine neue .htaccess-Datei für Euer tmp-Verzeichnis.

Code:

# To deny PHPs
<Files ~ "\.(php|php3|php4|php5|phtml|pl|cgi)$">
  order deny,allow                                                                              
  deny from all
</Files>

Anmerkung: Es gibt keine Notwendigkeit in diesem Verzeichnis php-Dateien aufrufen zu dürfen.

Schritt 7:

In aktuellen CMSms Versionen ab 1.4.1 sind schon .htaccess-Dateien für die nachfolgenden Ordner enthalten:
/doc
/images
/plugins
/uploads

Bitte überprüft, ob sich diese mit nachfolgenden Inhalt auf Eurem Server befinden:

Code:

# To deny PHPs
<Files ~ "\.(php|php3|php4|php5|phtml|pl|cgi)$">                                                                              
  order deny,allow                                                                                                            
  deny from all                                                                                                               
</Files>  

Schritt 8:

Deinstalliert und löscht den Modul-Manager und installiert statt dessen lieber Eure Module mittels FTP. Denn dann benötigt Euer modules-Verzeichnis nur noch den chmod 755. Gleiches gilt eventuell für den Theme-Manager, keine Ahnung wo der Dateien hinspeichert, da er bei mir sofort runtergeflogen ist.

Anmerkung: Wegen der Verzeichnisrechte (chmod 755) kommt die Fehlermeldung "Der Modul-Ordner ist schreibgeschützt." unter "Erweiterungen >> Module" und dies ist auch gut so!

Schritt 9 (Stand 18.08.2010):

Vermeidet die Benutzung des Tags {cms_version}. Oder wenn Ihr es wie ich als Werbung anseht, immer den aktuellsten Release-Stand installiert zu haben, dann habt ihn auch immer installiert, d.h. lasst Euch beispielsweise mittels Newsletter (ganz oben auf der Download-Seite) darüber informieren und installiert ihn so schnell wie möglich.

Schritt 10 (Danke NaN):

Im FileManager-Modul vor CMSms V1.2.5 waren größere Sicherheitslücken. Aktuellere Versionen enthalten den kritischen Code nicht mehr. Überprüft ob dieser problematische Code wirklich bei Euch nicht mehr auf dem Server ist! Geht hierzu in den Ordner modules/FileManager/postlet und seht Euch die Dateigröße bzw. den Inhalt der postlet.jar an. Zeigt Windows bei der Größe 1 KB an oder ist die Datei komplett leer, so solltet Ihr den aktuellen Stand auf dem Server installiert haben.

Schritt 11 (Danke cyberman):

Benutzt nicht das Standard Datenbank Prefix cms_, sondern denkt Euch etwas eigenes aus. Für alle, die in einer bestehenden Installation das Prefix ändern wollen, soll hier ein Hinweis auf meinen entsprechenden Beitrag reichen.

Schritt 12 (Danke TeXnik):

Postet News-Beiträge oder sonstige Daten, bei denen ein Besucher den Ersteller sieht auf keinen Fall mit einem admin-Benutzer! Legt einen gesonderten Benutzer mit eingeschränkten Rechten für solche Sachen an oder ändert die Anzeige (das Template) des News-Moduls beispielsweise so, daß anstatt $author die Variable $authorname zur Anzeige des Erstellers benutzt wird.

Anhang:

Verschleiert Eure Email-Adresse gegenüber Spam-Bots mittels Smarty.

Code:

E-Mail: <a href="{cms_selflink href="kontakt"}">{'test@example.com'|escape:'mail'|escape:'hexentity'}</a>

ACHTUNG: Keine Ahnung wie Tiny oder FCK darauf reagieren, da ich meinen Inhalt direkt über HTML-Eingaben pflege. Zusätzlich sollte man überlegen, ob man nicht auch andere persönliche Daten so schützen will (beispielsweise Telefonnummer).

Code:

Telefon: {'NUMMER'|escape:'hexentity'}

cyberman · **Posted:** Wed Nov 04, 2009 6:26 am

Danke, dass du dich auch weiterhin darum kümmerst!

TeXnik · **Posted:** Sat Nov 07, 2009 9:13 am

All die Sachen hatte ich implementiert, dennoch wurde irgendwie ein Scriptvirus installiert. Dieser befiel aber nur Dateien mit dem Namen index*.*, log*.* und auth*.*

Zur Vorsicht wechsele ich jetzt in kurzen Abständen die Passwörter, auch für den FTP-Zugang. Seitdem ist bisher jedenfalls Ruhe.
Zum Glück kann ich meinen Webspace auch als Laufwerk (webdrive) ansprechen und dadurch auch von Zeit zu Zeit einen Virescanner darauf loslassen.
Ich benutze jetzt auch Keepass um mir schöne lange Namen fürs Adminverzeichnis erzeugen zu lassen, neben den PW. Und in der portable Version mit PortableApps ist das Programm auch nur selten am Rechner. Dadurch wird die Wahrscheinlichkeit, das solche daten ausgelesen werden schon stark verringert.

Kann man diese Dateien noch besonders schützen? Müssen in all den Modulen die vielen index.html sein, manche enthalten ja gar keinen Code oder nur einen Dummy.

NaN · **Posted:** Sat Nov 07, 2009 1:38 pm

TeXnik wrote:

Müssen in all den Modulen die vielen index.html sein, manche enthalten ja gar keinen Code oder nur einen Dummy.

Eben drum.
Diese Dateien sind Dummys und dürfen nichts enthalten. Sie dienen der Sicherheit.
Die meisten Webserver sind von Haus aus so eingestellt, dass, wenn ich in der Adresse ein Verzeichnis angebe, nach einer index.html gesucht wird. Ist diese nicht vorhanden, wird der Inhalt des Verzeichnisses aufgelistet. Das sollte vermieden werden. Sieht erstens nicht schön aus und stellt zweitens ein Risiko dar, da so sich jemand sehr genau darüber informieren könnte, was so alles auf dem Server ist.

Um das zu vermeiden gibt es die Möglichkeit in der .htaccess Datei das Auflisten der Verzeichnisse generell zu verbieten:

Code:

Options -Indexes

Falls kein .htaccess zur Verfügung steht oder man die Anweisung "Options -Indexes" nicht verwenden kann (oder vergessen hat), dann wird bei Ordnern, in denen der User normalerweise nichts zu suchen hat, einfach diese index.html ausgegeben.
D.h. ohne index.html und ohne "Options -Indexes" könnte ich mit "domain.de/modules" mir den Inhalt des Modulordners bzw. des jeweiligen Moduls direkt im Browser anschauen.

Also lass die index.html Dateien lieber wo sie sind. Wenn außenstehende keine Schreibrechte auf diese Verzeichnisse haben, kann da auch nichts weiter passieren.

Wenn der FTP Zugang geknackt wurde, dann kannst Du da leider nichts mehr dagegen tun, als das Passwort zu ändern.
Denn jeder, der erstmal auf dem Webspace Zugriff hat, kann dort hochladen was er will, unabhängig davon, was Du sonstwo eingestellt hast. Dagegen gibt es leider keine Sicherheitsvorkehrungen mehr.

nockenfell · **Posted:** Wed Nov 11, 2009 7:54 pm

LeisureLarry wrote:

Code:

<Files ~ "config.php|CHANGELOG.txt">
order allow,deny
deny from all
</Files>

# END Optional Settings

Diese Einstellung kollidiert mit dem TinyMCE. Der will sich nicht mehr anzeigen. Die Konfiguration des TinyMCE ist in der Datei tinyconfig.php abgespeichert. Darauf wird nun der Zugriff verweigert, da config.php darin vorkommt.

Ich habe dies mal so gelöst:

Code:

<Files ~ "config.php|CHANGELOG.txt">
order allow,deny
deny from all
</Files>

<Files ~ "tinyconfig.php">
order allow,deny
allow from all
</Files>

Wahrscheinlich gibt es eleganteren Code. Da ich mich mit den .htaccess Files nicht zu gut auskenne, habe ich ihn noch nicht gefunden. Ev weiss einer von euch hier besseren Rat.

yogi62 · **Joined:** Tue Jul 31, 2007 10:29 am **Posts:** 10

Hallo zusammen,

ich habe eine Frage zu:

Quote:

Schritt 3:
Nur noch Leserechte auf die config.php erteilen. Per FTP den chmod der config.php beispielsweise auf 444 ändern.

Macht es Sinn, die config.php auf 440 zu setzen oder gibt es da Abhängigkeiten, die es erfordern, allen die Leserechte zu geben?
Wir diskutieren hier gerade die Möglichkeit, dass sich ein User mit Zugang zum Server(nicht admin, nicht Gruppe) u. U. die config.php ansehen kann. Passwort, Benutzername usw. stehen da doch im Klartext drin.
Auf unserem Server liegen etliche Webseiten, somit auch unendlich viele verschiedene User, die sich auf dem Server anmelden können. Man unterstellt ja nichts Böses, aber ...

Wer kann da Licht ins Dunkel bringen?

Gruss, yogi

LeisureLarry · **Posted:** Fri Nov 20, 2009 9:27 am

Da kommt es leider sehr stark auf die Servereinrichtung an, deswegen habe ich auch nur beispielsweise geschreiben. Bei manchen Servern reicht 400, bei anderen braucht man 440 und auf manchen läuft CMSms nur mit 444 (da würde ich aber schnellstens abhauen). Ich würde halt möglichst ausprobieren, wie weit ich die Rechte wegnehmen kann und das dann benutzen.

LeisureLarry (interiete.net)

yogi62 · **Joined:** Tue Jul 31, 2007 10:29 am **Posts:** 10

Danke für die schnelle Antwort. Wir testen das.

Macht es Sinn, Deine Aussage mit in das User Handbook, Schnellstart-Anleitung/Schritt 5 - Erstellen der Konfigurationsdatei aufzunehmen?

Gruss, yogi

cyberman · **Posted:** Mon Jan 18, 2010 11:51 am

Die (theoretisch) möglichen Verzeichnis-Berechtigungen hat @NaN im folgenden etwas näher untersucht

http://forum.cmsmadesimple.org/index.ph ... #msg192897

cyberman · **Posted:** Tue Feb 09, 2010 11:59 am

Ein Thema, was zwar selbstverständlich sein sollte, aber hier in der Form noch nicht thematisiert wurde, ist natürlich die regelmäßige Erstellung von (lokalen) Backups (sowohl der Datenbank als auch der Dateien). Ganz nach dem Motto, Vorbeugen ist besser als nach hinten fallen :) - wenn die Daten erst einmal überschrieben sind, isses zu spät.

Außerdem kann über die Systemprüfung (Menü "Administrator > Systemprüfung") die Integrität der CMSms-Dateien geprüft werden ... Voraussetzung ist allerdings, dass man diese Funktion auch nutzt, natürlich vor einem Crash.

cyberman · **Posted:** Fri Feb 26, 2010 11:57 am

Mit der Version 1.6.7 wurde eine Sicherheitslücke geschlossen, mittels derer externe Dateien eingebettet werden konnten (im Beispiel waren .ini-Dateien verwendet).

Mit einem Eintrag in die htaccess sollte sich dies verhindern lassen

Code:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?meine-domain\.de(/.*)?$ [NC]
RewriteRule \.(ini|INI|iNI|inI|Ini|INi|iNi)$ - [F]

webap · **Joined:** Thu Mar 04, 2010 1:41 pm **Posts:** 2

Hallo Leute,

verwende zwar noch Version 1.5.2 aber auch bei der Beschreibung ab Version 1.4 kommt der gleiche Fehler.

Also ich bin beim absichern und erstelle aus der vorhandenen htaccess.txt Datei ein "richtige" htaccess mit den änderungen wie beschrieben. Leider bekomme ich immer einen 500 Internal Server Error wenn ich diese Online haben. Wenn ich sie wegnehme vom Server läuft alles normal.

Ich weiss jetzt nicht ob es was mit der config.php einstellung zu tun haben kann, oder ist das auszuschliessen? Anbei meine Datei

Code:

# Attempt to override some php settings, these settings may be helpful on some hosts if your
# default configuration does not meet CMS's minimum requirements, and your host
# has given your account appropriate permissions
#php_value upload_max_filesize "10M"
#php_value session_save_path "tmp/cache"
AllowOverride All
#php_flag magic_quotes_gpc Off
#php_flag register_globals Off
#php_flag session.use_trans_sid Off

# (this is important, so uncomment if your host permit)
Options -Indexes
ServerSignature Off

# BEGIN Optional settings

# Deny access to config.php and CHANGELOG.txt
# The former can be useful if php ever breaks or dies
# Use with caution, this may break other functions of CMSms that use a config.php
# file.  This may also break other programs you have running under your CMSms
# install that use config.php.  You may need to add another .htaccess file to those
# directories to specifically allow config.php.
<Files ~ "config.php|CHANGELOG.txt">
order allow,deny
deny from all
</Files>

# END Optional Settings

#
Options +FollowSymLinks
#
<IfModule mod_rewrite.c>
RewriteEngine on
#
# unterbindet, das fremde Seiten geladen werden
RewriteCond %{QUERY_STRING} ^(.*)=http://(.*) [OR]
# blockiert libwww (Ausgangspunkt für diverse Hackversuche)
RewriteCond %{HTTP_USER_AGENT} ^libwww [OR]
# Blockiert Skripte, die versuchen, base64 encodierten Unsinn via URL zu versenden
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Blockiert Skripte, die einen a ********** Tag in der URL enthalten
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Blockiert Skripte, die versuchen, PHP GLOBALS Variablen via URL zu verändern
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Blockiert Skripte, die versuchen, eine _REQUEST Variable via URL zu verändern
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Spambots nach User_agent aussperren
RewriteCond %{HTTP_USER_AGENT} ^.*Whacker.*$ [OR] 
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR] 
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR] 
RewriteCond %{HTTP_USER_AGENT} ^.*FileHound.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*TurnitinBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*JoBo.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*adressendeutschland.*$
RewriteRule ^.* - [F]
#
#Sub-dir e.g: /cmsms
RewriteBase /
#
# 301 Redirect all requests that don't contain a dot or trailing slash to
# include a trailing slash
RewriteCond %{REQUEST_URI} !/$
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*) %{REQUEST_URI}/ [R=301,L]
# Rewrites urls in the form of /parent/child/
# but only rewrites if the requested URL is not a file or directory
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]+)/(.*)$ index.php?page=$2&hl=$1 [QSA]
</IfModule>

Hat der Fehler mit der Datei selbst oder einer Servereinstellung zu tun?

Danke

Rolf · **Posted:** Thu Mar 04, 2010 2:31 pm

Quote:

Leider bekomme ich immer einen 500 Internal Server Error wenn ich diese Online haben. Wenn ich sie wegnehme vom Server läuft alles normal.

Versuchen Sie,
#Options +FollowSymLinks

Gruss, Rolf

webap · **Joined:** Thu Mar 04, 2010 1:41 pm **Posts:** 2

Hallo, danke für die Antwort.

habe aber auch schon eine andere getestes, das selbe. Nur ohne Inhalt nimm er sie.

jetzt verwende ich diese

Code:

# BEGIN Optional settings

# Turns off directory browsing
# not absolutely essential, but keeps people from snooping around without 
# needing empty index.html files everywhere
Options -Indexes

# Deny access to config.php
# This can be useful if php ever breaks or dies
# Use with caution, this may break other functions of CMSms that use a config.php
# file. This may also break other programs you have running under your CMSms
# install that use config.php. You may need to add another .htaccess file to those
# directories to specifically allow config.php.
<Files "config.php">
order allow,deny
deny from all
</Files>

# Sets your 403 error document
# not absolutely essential to have, 
# or you may already have error pages defined elsewhere
ErrorDocument 403 /forbidden403.shtml

# No sense advertising what we are running
ServerSignature Off

# END Optional Settings

# BEGIN CMSMS and Rewrite Rules
# Make sure you have Options FollowSymLinks
# and Allow on

RewriteEngine On

# Might be needed in a subdirectory
#RewriteBase /

# URL Filtering helps stop some hack attempts
#IF the URI contains a "http:"
RewriteCond %{QUERY_STRING} http: [OR]
#OR if the URI contains a "["
RewriteCond %{QUERY_STRING} [ [OR]
#OR if the URI contains a "]"
RewriteCond %{QUERY_STRING} ] [OR]
#OR if the URI contains a "<script>"
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
#OR script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
#OR any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2}) 
RewriteRule ^.*$ - [F,L] 
# END Filtering

# CMSMS Rewriting
# Set assume mod_rewrite to true in config.php and clear CMSMS cache
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?page=$1 [QSA]
# END CMSMS

# END Rewrite rules

cyberman · **Posted:** Thu Apr 15, 2010 11:03 am

LeisureLarry wrote:

Schritt 5:

Sperrt diverse Hack-Möglichkeiten und auch noch gleich die bekanntesten Spam-Bots mittels .htaccess aus.

Eine erweiterte Liste zum Aussperren von Hackversuchen wurden gerade hier gepostet

http://forum.cmsmadesimple.org/index.ph ... #msg205006

Aber Achtung - speziell bei Shared Hosting Angeboten kann es sein, dass der eine oder andere Eintrag nicht funktionieren bzw. nicht möglich ist.

HowTo: CMSms Sicherheit ab Version 1.6.6

Who is online