next »

[LeisureLarry]

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:

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 Announcement-Mailingliste dar�ber informieren und installiert ihn so schnell wie m�glich.

http://www.cmsmadesimple.org/support/mailing-lists

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]

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

[TeXnik]

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]

 

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]

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]

Hallo zusammen,

ich habe eine Frage zu:

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]

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]

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]

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

http://forum.cmsmadesimple.org/index.php/topic,40702.msg192897.html#msg192897

[cyberman]

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]

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]

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]

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]

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