HowTo: CMSms Sicherheit ab Version 1.4.1

[LeisureLarry]

Da mein alter Sicherheitsbeitrag so gut angekommen ist und sich mit dem Update auf Version 1.4 bzw. 1.4.1 ein paar Änderungen ergeben haben, möchte ich nun einen aktualisierten Beitrag starten (ohne den alten Beitrag zu verlieren).

Schritt 1 (Stand 13.03.2008):

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 eventuell sogar Sonderzeichen. Es sollte eine Länge von mindestens 8 Zeichen haben.

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

Falls Ihr keine Idee für ein sicheres Kennwort haben solltet, so lasst Euch eines auf der nachfolgenden Website vorschlagen. Leider werden hierbei keine Sonderzeichen verwendet, weswegen die Kennwörter bei den beiden nachfolgenden Kennwortprüfungen nicht immer gut abschneiden!

https://www.passpub.com/mnemonic.php

Wer einer Website zur Erstellung nicht traut, kann auch ein entsprechendes Programm herunterladen. Das nachfolgend verlinkte Windows-Tool hört sich beispielsweise ganz brauchbar an:

http://www.gaijin.at/dlpg.php

Eine Prüfung Eures Kennworts bietet beispielsweise das Anmeldeformular eines Google-Kontos oder Microsofts Password checker. Gebt einfach Euer Kennwort ein und nehmt Euch die Angabe zur Passwortstärke zu Herzen, sofern diese nicht 'Strong' bzw. 'Best' ist. 100 Prozent sicher ist Euer Kennwort aber selbst dann nicht, ein Knacken dauert halt nur extrem lang.

https://www.google.com/accounts/NewAccount?service=analytics&hl=de
http://www.microsoft.com/protect/yourself/password/checker.mspx

Einen Hinweis darauf wie diese Prüfungen funktionieren, bietet eine Aufgabenstellung der Microsoft 'Winter Scripting Games 2008'.

http://www.microsoft.com/technet/scriptcenter/funzone/games/games08/deu/aevent5.mspx

Hinweis: Ich habe die Angaben mal als Kommentar zu diesem Beitrag hinzugefügt, damit sie nicht verloren gehen.

Schritt 2 (Stand 21.02.2008):

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: Select all

$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:

Ergänzt die .htaccess-Datei im Hauptordner Eures CMS und fügt den nachfolgenden Code ganz am Anfang ein.

Code: Select all

# 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>

# No sense advertising what we are running
ServerSignature Off

# END Optional Settings

Schritt 5 (Stand 21.02.2008):

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

Code: Select all

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

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

Schritt 6 (Stand 08.09.2008):

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

Code: Select all

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

Anmerkung: Keine Ahnung wie bei den jüngsten Fällen php-Dateien in dem tmp-Ordner erstellt werden konnten. Aber da es keine Notwendigkeit gibt sie dort ausführen zu können, verbieten wir dies einfach einmal.

Schritt 7 (Stand 08.09.2008):

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: Select all

# 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:

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

Code: Select all

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: Select all

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

Schritt 10:

Sperrt die bekanntesten Spam-Bots mittels .htaccess aus.

Code: Select all

# 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 RewriteEngine on ein.

Schritt 11:

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 12 (NEU, 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 13 (NEU, Danke NaN):

Das Java-Applett des FileManagers welches in den CMSms-Versionen vor 1.2.5 ein großes Sicherheitsrisiko darstellte, muss von Hand vom Server gelöscht werden, da es beim Update weiterhin auf dem Server bleibt. Auch wenn der neue FileManager diese Funktionen nicht mehr unterstützt, könnten gewiefte Bösewichte diese Dateien weiterhin ausnutzen.

Deswegen den Ordner modules/FileManager/postlet komplett auf Eurem Server/Webspace löschen!

[Andiministrator]

Oft ist auch das Speichern von Zugangsdaten ein Sicherheitsrisiko, bei einigen Kunden kleben diese sogar im Klartext am Monitor.

Besser ist da der Einsatz ein Passwort-Safe-Tools wie KeePass:
http://de.wikipedia.org/wiki/KeePass

Das erstellt bei Bedarf auch gleich Passwörter und zeigt deren Sicherheit an.

[LeisureLarry]

Stimme ich Dir voll und ganz zu und wie schon im alten Beitrag geschrieben, sind ganz besonders die Damen dieser Welt schon mit etwas Schokolade bestechlich

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

Grüße aus Nürnberg
LeisureLarry (interiete.net)

[NaN]

Noch ein Hinweis zum Thema Update:

Ein Update allein reicht leider nicht aus, um Sicherheitslücken zu schließen.

1.) Das Java-Applett des FileManagers welches in den CMSms-Versionen vor 1.2.5 ein großes Sicherheitsrisiko
      darstellte, muss von Hand vom Server gelöscht werden, da es beim Update weiterhin auf dem Server bleibt.
      Auch wenn der neue FileManager diese Funktionen nicht mehr unterstützt, könnten gewiefte Bösewichte diese
      Dateien weiterhin ausnutzen.
      (Den Ordner modules/FileManager/postlet komplett löschen!)

2.) VOR jedem Update prüfen, ob Sicherheitslücken nicht bereits ausgenutzt wurden.
      Falls Dateien mit schadhaftem Code über irgendeine Sicherheitslücke auf den Server geladen wurden,
      bringt auch ein Update nichts, da diese Dateien dann ebenfalls weiterhin verfügbar sind.

[cyberman]

Bin gerade noch auf eine Sache gestoßen, mit der sich die Sicherheit speziell gegen SQL-Injektionen erhöhen lässt, und zwar ein individueller Prefix für die Datenbank.

Warum sollten der Präfix geändert werden?

Standardmäßig geht der Installationsassistent Präfix "cms_" aus. Das Problem ist, das dieser bekannt ist und dadurch SQL-Injektionen  erleichtert, falls ein Angreifer eine Lücke auf der Webseite findet. Es ist einfacher, auf die Datenbank zuzugreifen, wenn man den vollen Tabellennamen kennt bzw erraten kann. Eine Änderung des Präfixes erschwert es dem Angreifer deutlich, darauf zugreifen zu können.

[nockenfell]

Danke für den Hinweis. Ohne daran zu denken, hatte ich den Prefix bei meiner DB bereits geändert. 

[LeisureLarry]

Habe mich heute mal ein wenig schlau gemacht, wie man im Nachhinein das Prefix ändern kann. Die meisten Suchergebnisse spuckten Lösungen für Wordpress aus, wie beispielsweise die manuelle Variante oder ein sehr gutes Plugin für Wordpress von Philipp Heinze.

Da mir die manuelle Variante zu mühselig war und ich für CMSms nichts ähnliches finden konnte, habe ich selber mal was zusammengestrickt. Hier nun für alle die noch das Standard Prefix haben ein kleines Helferein, welches die Umstellung erheblich erleichtert.

http://cms.interiete.net/prefix-cms-ms.html (Benutzung auf eigen Gefahr, Backups nicht vergessen)

Grüße aus Nürnberg
LeisureLarry (interiete.net)

[cyberman]

Sehr schönes Arbeiten - ich mag Leute, die mitdenken - Danke Jan !!!

[cyberman]

Wieder mal eine Ergänzung für die .htacess

1. unterbindet, das fremde Seiten geladen werden

Code: Select all

RewriteCond %{QUERY_STRING} ^(.*)=http://(.*) [OR]

2. blockiert libwww (Ausgangspunkt für diverse Hackversuche)

Code: Select all

RewriteCond %{HTTP_USER_AGENT} ^libwww [OR]

und hier noch eine paar Ideen aus der Joomla!-Ecke

# Blockiert Skripte, die versuchen, base64 encodierten Unsinn via URL zu versenden

Code: Select all

RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]

# Blockiert Skripte, die einen a ********** Tag in der URL enthalten

Code: Select all

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

# Blockiert Skripte, die versuchen, PHP GLOBALS Variablen via URL zu verändern

Code: Select all

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

# Blockiert Skripte, die versuchen, eine _REQUEST Variable via URL zu verändern

Code: Select all

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]

[Andiministrator]

Danke. Habs bei mir gleich eingebaut. Funktioniert ohne Probleme.

[nockenfell]

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

Code: Select all

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

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

Ajax hat nach der Ergänzung des .htaccess protestiert. Es könne die Datei /lib/xajax/xajax_js/xajax.js nicht mehr laden. (Braucht es zum Speichern und die Vorschau)

Ich habe das .htaccess nun folgendermassen angepasst:

Code: Select all

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>

Danach habe ich keine Fehlermeldung mehr bekommen.

[crossi]

Hallo allerseits,

Vermeidet die Benutzung des Tags {cms_version}.

dann sollte man aber auch /doc/CHANGELOG.txt loeschen bzw. die .htaccess dort um |txt erweitern.

Gruss Torsten

[Andiministrator]

Ich habe bei mir gleich den gesamten /doc Ordner gelöscht.

[vyana.violet]

Erstmal ein gutes neues Jahr an Euch alle.
Habe gestern "endlich" mein CMS von 1.2.3. auf 1.5.1 upgedatet. Lief soweit auch alles ohne Probleme. Als ich mir dann aber die Seite anschaute, wurden keine Bilder mehr angezeigt. Daraufhin bin ich hier im Forum auf die Suche nach der Lösung gegangen.
Und sie eigentlich auch gefunden. Diese .htaccess datei mit ihren Eintragungen und die Einstellung meines Providers in der php.ini war schuld daran. Mir wurde beim Update auch angezeigt, dass die Funktion "allow url fopen" auf off steht..."fopen: Wenn auf Ihrem Host die Funktion "allow url fopen" deaktiviert ist, können Sie nicht über das FTP- oder HTTP-Protokoll auf URL-Objekte zugreifen"

Nachdem ich nun die htaccess-datei (sie liegt im Ordner uploads) umbenannt habe (wollte sie nicht gleich löschen) wurden alle Bilder wieder angezeit.

Wie ich aber hier nun gelesen habe, ist diese Datei ja eigentlich zur Sicherheit da.....und der Provider wird den php.ini Eintrag sicherlich nicht ändern..... was kann ich tun?  Muss ich überhaupt was tun oder ist mit der fopen deaktvierung auch schon eine gewisse Sicherheit erreicht?

[nockenfell]

Füge folgenden Text in das .htaccess File ein:

Code: Select all

php_flag allow_url_fopen on

Falls das nicht funktioniert, musst du deinen Provider für den entsprechenden Code kontaktieren.