Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#1 20. September 2010 17:36

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

HowTo: CMS/made simple absichern

Obwohl CMS/ms im Vergleich zu anderen Systemen relativ wenigen (erfolgreichen) Hacker-Angriffen ausgesetzt ist, gehören die nachfolgend aufgeführten Maßnahmen zur Absicherung des Systems zum Pflichtprogramm eines JEDEN verantwortungsbewusst arbeitenden Webseiten-Betreibers:

0. Übersicht

1. Während der Installation
1.1 Administrator-Name und -Passwort
1.2 Datenbank-Präfix

2. Nach der Installation
2.1 Verzeichnis /install löschen
2.2 CMS/ms-seitige Voreinstellungen ändern
2.2.1 Name des Administrationsverzeichnisses
2.2.2 Zusätzlicher Schutz für das Admin-Verzeichnis
2.2.3 Hinweise auf das eingesetzte CMS entfernen
2.2.3.1 CMS/ms-Tags entfernen, die auf die Verwendung des CMS schließen lassen
2.2.3.2 Verräterische Meta-Informationen löschen
2.3 Zugriffsberechtigungen für Verzeichnisse und Dateien
2.3.1 Die Datei config.php
2.3.2 Verzeichnis-Zugriffe für /lib und /tmp beschränken
2.3.3 Schutz weiterer Verzeichnisse
2.3.4 Die Datei .htaccess
2.4 ModulManager deinstallieren

3. Weitere serverseitige Maßnahmen
3.1 Serverseitige Fehlermeldungen deaktivieren
3.2 Deaktivierung sicherheitsrelevanter Servereinstellungen
3.3 Ausgabe der PHP-Version verhindern
3.4 Inhalt der robots.txt
3.5 Hackversuche unterbinden
3.6 Böswillige Spider aussperren

4. Schutzmaßnahmen für die laufende Bearbeitung
4.1 Namen der Webseiten-Autoren
4.2 Email-Adressen verschleiern
4.3 Weitere persönliche Daten schützen
4.4 Prüfsummen des Systems erstellen

1. Während der Installation:

1.1 Administrator-Name und -Passwort

Wähle für den Administrator-Zugang einen möglichst nicht zu erratenden Namen und Passwort. Für Passwörter tabu sind:

- einzelnen Wörter oder Zahlenfolgen (wie etwa admin, administrator oder abcde / 12345 o.ä.)
- persönlichen Informationen (Vor-/Nachnamen, Geburtsdaten oder Ort des Firmensitz des Webseiten-Besitzers o.ä.)
- ein einfaches Wort rückwärts schreiben
- dasselbe Passwort für mehrere Seiten nutzen

Stattdessen sollte das Passwort sollte MINDESTENS acht Zeichen lang sein (12-16 Zeichen sind ideal), aus Groß- UND Kleinbuchstaben bestehen sowie Zahlen und Sonderzeichen enthalten (idealerweise mittendrin). Mit besonders langen Passwörter (Passphrasen) lässt sich die Sicherheit noch einmal erhöhen, siehe

http://aktuell.de.selfhtml.org/artikel/ … /index.htm

In Tim Bormanns Blog gibt es hierzu einen kurzen Artikel - diese Informationen solltet ihr sehr ernst nehmen. Habt ihr keine Idee für ein sicheres Passwort, findet ihr bei einschlägigen Passwort-Generatoren im Web Unterstützung.

Gleiches gilt auch für jeden weiteren Benutzer, den ihr später in der Administration angelegt wink.

1.2 Datenbank-Präfix

Bei der Installation wird das Datenbank-Präfix "cms_" vorgegeben. Dies solltet ihr NICHT verwenden, sondern Euch wie auch beim Passwort ein anderes, schwer zu erratendes Präfix ausdenken.

Wie man in einer bestehenden Installation das Datenbank-Präfix ändert, könnt ihr in diesem Beitrag nachlesen. Anschließend müssen noch die Indizes korrigiert werden - wie das geht, lest ihr hier.

2. Nach der Installation:

2.1 Verzeichnis /install löschen

Direkt nach Abschluß der Installation und Funktionskontrolle solltet ihr unbedingt das Verzeichnis /install löschen (nicht nur umbenennen). Böswillige Besucher könnten damit eure gesamte Webseite zerstören.

2.2 CMS/ms-seitige Voreinstellungen ändern

Nach dem Motto "Security by Obscurity" (frei übersetzt Sicherheit durch Geheimniskrämerei) solltet ihr diverse Voreinstellungen von CMS/ms ändern:

2.2.1 Name des Administrationsverzeichnisses

Voreingestellt ist /admin und nicht sonderlich schwer zu erraten. Bezüglich des Namens gilt das gleiche wie das beim Benutzernamen und Passwort Gesagte - auch das Admin-Verzeichnis sollte einen anderen, schwer zu erratenden Namen (zum Beispiel "h2dSg8fsX") bekommen.

Anschließend muss die config.php um folgenden Eintrag ergänzt, oder falls bereits vorhanden, wie folgt geändert werden:

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

Wie bei jeder Änderung an der config.php sollte anschließend der CMS/ms-interne Zwischenspeicher gelöscht werden.

2.2.2 Zusätzlicher Schutz für das Admin-Verzeichnis

Der neue Admin-Ordner sollte anschließend mit einem zusätzlichen .htpasswd/.htaccess-Schutz versehen werden.

Bei einigen Providern gibt es dafür Optionen in deren Backend. Anderenfalls findet man auch hierzu Hilfe im Web.

Damit verhindert ihr auch, dass das Admin-Verzeichnis von Suchmaschinen indiziert wird.

Außerdem solltet ihr zu Beginn der .htaccess Datei für euren Admin-Ordner noch dies einfügen

ErrorDocument 401 "Unauthorized Access"
RewriteEngine off

Warum? Das sagt euch @owr wink

2.2.3 Hinweise auf das eingesetzte CMS entfernen

2.2.3.1 CMS/ms-Tags entfernen, die auf die Verwendung des CMS schließen lassen

Bei den in CMS/ms mitgelieferten Templates werden im Footer die Tags {cms_version} und {cms_versionname} eingesetzt, um Nummer und Name eurer installierten CMS/ms-Installation ausgeben.

Aus Sicherheitsgründen sollten auf einer Webseite weder diese Informationen noch sonst irgend eine Information ausgegeben werden, die darauf schließen lässt, dass CMS/made simple für die Erstellung der Webseite eingesetzt wird.

Den nach Informationen suchenden Gast interessiert das CMS meist wenig bis überhaupt nicht. Vielmehr liefert ihr mit diesen Informationen potentiellen Angreifern genau die Informationen, die sie benötigen, um nach potentiellen Schwachstellen zu suchen.

2.2.3.2 Verräterische Meta-Informationen löschen

Für CMS/ms findet sich voreingestellt im Quellcode im Header der Meta-Tag:

<meta name="Generator" content="CMS Made Simple - Copyright (C) 2004-15 Ted Kulp. All rights reserved." />

Auch hier gilt das unter Punkt 2.2.3.1 gesagte - unnötig und verräterisch!

Dieser Eintrag sollte daher in der Webseiten-Administration über die Registerkarte "Globale Einstellungen" im Textbereich "Globale Metadaten" entfernt werden.

2.3 Zugriffsberechtigungen für Verzeichnisse und Dateien

2.3.1 Die Datei config.php

Reduziert die Berechtigung der config.php, dass nur noch minimale Rechte darauf bestehen, mindestens also chmod 444). Noch besser wäre 400 - siehe dazu http://www.cmsmadesimple.de/forum/viewt … 3149#p3149

Ergänzend sollte der externe Zugriff mit dem nachfolgenden Eintrag in der .htaccess ausgeschlossen werden:

# BEGIN Optional settings
# Deny access to config.php and CHANGELOG.txt
<Files ~ "config.php|CHANGELOG.txt">
order allow,deny
deny from all
</Files>
# END Optional Settings

Damit wird externer Zugriff auf die CMS/ms-Konfigurationsdatei (und die Datei CHANGELOG.txt, in der Informationen zur installierten CMS/ms-Version enthalten sind) verhindert.

2.3.2 Verzeichnis-Zugriffe für /lib und /tmp beschränken

Falls noch nicht vorhanden erstellt für euer /lib-Verzeichnis eine neue .htaccess-Datei mit folgendem Inhalt:

Order allow,deny
<FilesMatch ".*\.css|.*\.js|.*\.gif|.*\jpe?g|editor.php|thumbs.php|images.php|editorFrame.php$">
	Order deny,allow
</FilesMatch>

In euer /tmp-Verzeichnis solltet ihr (falls noch nicht vorhanden) eine .htaccess mit folgendem Inhalt einfügen:

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

da es keine Notwendigkeit gibt, in diesem Verzeichnis php-Dateien aufrufen zu dürfen.

2.3.3 Schutz weiterer Verzeichnisse

In der aktuellen CMS/ms-Version sind  in den nachfolgenden Ordner schon .htaccess-Dateien enthalten:

/doc
/images
/plugins
/uploads

Prüfe, ob in diesen die nachfolgenden Anweisungen enthalten sind:

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

2.3.4 Die Datei .htaccess

Was für die Systemdateien gilt, sollte auch auf die Datei .htaccess selbst angewendet werden, praktisch also so

# Zugriff auf .htaccess und .htpasswd verbieten, falls in Benutzung
<FilesMatch "(\.htaccess)">
  Order deny,allow
  Deny from all
</FilesMatch>

2.4 ModulManager deinstallieren

Abgesehen davon, dass es bei Verwendung des ModulManagers unter Umständen Berechtigungsprobleme geben kann (nicht muss), wird vom Einsatz des ModulManagers abgeraten, da dieser volle Schreibrechte auf das Verzeichnis /modules einfordert.

Anstatt dessen sollten die Archive für neue Module direkt aus dem Forge geladen, mittels FTP o.ä. auf den Server eingespielt und dann manuell installiert werden. Damit benötigt das /modules[-Verzeichnis nur noch chmod 755 und ihr habt eine potentielle Sicherheitslücke weniger.

Hinweis: Wegen der Verzeichnisrechte (chmod 755) kommt unter "Erweiterungen > Module" die (vermeintliche) Fehlermeldung "Der Modul-Ordner ist schreibgeschützt." - das ist aber voll in Ordnung!

3. Weitere serverseitige Maßnahmen

Über eine .htaccess-Datei im Wurzelverzeichnis eurer CMS/msMS-Installation lassen serverseitig weitere Vorkehrungen treffen.

So findet ihr im /doc-Verzeichnis ein Muster für eine .htaccess-Datei mit dem Namen htaccess.txt. Kopiert diese Datei in den Hauptordner eurer Installation und benennt sie entsprechend um (".htaccess").

3.1 Serverseitige Fehlermeldungen deaktivieren

Fehlermeldungen müssen in produktiven Systemen grundsätzlich vermieden werden, da man daraus ggf. bestimmte Rückschlüsse auf die eingesetzte Systemumgebung (und damit mögliche Sicherheitslücken) ziehen kann.

Mit den folgenden Einträgen aus der htaccess-Vorlage lassen sich sämtliche PHP-Fehlermeldungen unterdrücken:

# To prevent E_STRICT problems with PHP 5.3+ you can uncomment the following lines
# Note: These settings should only be enabled for production sites!
php_flag display_startup_errors 0
php_flag display_errors 0
php_flag html_errors 0
php_value docref_root 0
php_value docref_ext 0

Hinweis: Diese Einträge in der .htaccess können nur etwas bewirken, wenn diese Änderungsmöglichkeiten durch den Betreiber des Servers "freigegeben" wurden.

Anderenfalls kann es unter Umständen zu einer solchen Fehlermeldung kommen

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log

Falls dies auftritt, könnt ihr alternativ versuchen, die PHP-Fehlermeldungen mit diesem Eintrag

in der config.php zu unterdrücken (ist nicht perfekt, da die config.php gelegentlich vom CMS/ms-Aktualisierungsassistenten neu geschrieben wird und dieser Eintrag dabei verloren gehen kann).

3.2 Deaktivierung sicherheitsrelevanter Servereinstellungen

In der Muster .htaccess findet sich auch folgender Code:

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

Entfernt hier jeweils das Kommentarzeichen "#" vor Options -Indexes und ServerSignature Off.

Mit dem ersten Eintrag wird der Server angewiesen, den Besuchern NICHT die Inhalte der Verzeichnisse aufzulisten, falls diese keine darstellbaren Dateien (html o.ä.) enthalten. Der zweite Eintrag sorgt dafür, dass keine Versionsinformationen zum verwendeten Server ausgegeben werden.

3.3 Ausgabe der PHP-Version verhindern

Trotzdem ist es möglich, dass im Header Informationen zur verwendeten PHP-Version mitgesandt werden. Dies lässt sich mit folgendem Eintrag in der .htaccess deaktivieren:

# X-Powered-By aus dem Header entfernen
<IfModule mod_headers.c>
Header unset X-Powered-By
</IfModule>

3.4 Inhalt der robots.txt

Im /doc Verzeichnis findet ihr auch ein Muster für eine Datei robots.txt, die ebenfalls ins Wurzelverzeichnis kopiert werden muss. Mittels dieser können Suchmaschinen-Bots und -Spider angewiesen werden, bestimmte Verzeichnisse zu indizieren oder auch nicht.

Jedoch solltet ihr die Pfadangabe zum Admin-Ordner aus der robots.txt entfernen. Dies verhindert eine Indizierung der Admin-URL, aber ohne zu zeigen, wie diese lautet (die Datei robots.txt für JEDEN lesbar).

3.5 Hackversuche unterbinden

Bekannte Hack-Versuche lassen sich mittels folgender Ergänzung der .htaccess-Datei aussperren:

Options +FollowSymLinks
# Keine  URL based exploits zulassen
RedirectMatch 403 \[

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]
# Blockiert sonstige verdächtige Skripte
RewriteCond %{QUERY_STRING} ^[^=]*$ [OR]
RewriteCond %{QUERY_STRING} %2d|\- [OR]
RewriteCond %{QUERY_STRING} .*'.* [OR]
RewriteCond %{QUERY_STRING} .*%27.* [OR]
RewriteCond %{QUERY_STRING} .*".* [OR]
RewriteCond %{QUERY_STRING} .*%22.* [OR]
RewriteCond %{QUERY_STRING} .*`.* [OR]
RewriteCond %{QUERY_STRING} .*%60.* [OR]
RewriteCond %{QUERY_STRING} .*%25.* [OR]
RewriteCond %{QUERY_STRING} .*echr.* [OR]
RewriteCond %{QUERY_STRING} .*esystem.* [OR]
RewriteCond %{QUERY_STRING} .*passthru.* [OR]
RewriteCond %{QUERY_STRING} .*wget.*
RewriteRule ^.* - [F,L]

# Double slashes in allen URLs verbieten
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /(([^/\ ]+/)*)/+([^\ ]*)
RewriteRule ^ /%1%3 [L,R=301]

3.6 Böswillige Spider aussperren

Was mit den Hackern funktioniert, funktioniert auch mit böswilligen Spidern und Spambots - mit folgendem Eintrag

# Spambots nach User_agent aussperren
Options +FollowSymLinks
RewriteEngine On
 
# Rewriting gegen boese Bots
RewriteCond %{HTTP_USER_AGENT} ^Alexibot [OR]
RewriteCond %{HTTP_USER_AGENT} ^asterias [OR]
RewriteCond %{HTTP_USER_AGENT} ^BackDoorBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Black [OR]
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^BlowFish [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^BotALot [OR]
RewriteCond %{HTTP_USER_AGENT} ^BuiltBotTough [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bullseye [OR]
RewriteCond %{HTTP_USER_AGENT} ^BunnySlippers [OR]
RewriteCond %{HTTP_USER_AGENT} ^Cegbfeieh [OR]
RewriteCond %{HTTP_USER_AGENT} ^CheeseBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^CherryPicker [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Convera [OR]
RewriteCond %{HTTP_USER_AGENT} ^CopyRightCheck [OR]
RewriteCond %{HTTP_USER_AGENT} ^cosmos [OR]
RewriteCond %{HTTP_USER_AGENT} ^Crescent [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DataFountains [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DittoSpyder [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Email [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^Extractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Foobot [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Global\ Confusion [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^hloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} ^httplib [OR]
RewriteCond %{HTTP_USER_AGENT} ^ia_archiver [OR]
RewriteCond %{HTTP_USER_AGENT} ^IBM_Planetwide [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR] 
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^Indy\ Library [OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^Jakarta [OR]
RewriteCond %{HTTP_USER_AGENT} ^JennyBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Kenjin [OR]
RewriteCond %{HTTP_USER_AGENT} ^Keyword [OR]
RewriteCond %{HTTP_USER_AGENT} ^LexiBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^libWeb [OR]
RewriteCond %{HTTP_USER_AGENT} ^lwp [OR]
RewriteCond %{HTTP_USER_AGENT} ^Lynx [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mata [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft.URL [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIIxpc [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^moget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^NICErsPRO [OR]
RewriteCond %{HTTP_USER_AGENT} ^NPBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^Openfind [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^ProPowerBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^ProWebWalker [OR]
RewriteCond %{HTTP_USER_AGENT} ^QueryN [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^RepoMonkey [OR]
RewriteCond %{HTTP_USER_AGENT} ^RMA [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SlySearch [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^Snoopy [OR]
RewriteCond %{HTTP_USER_AGENT} ^SpankBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^spanner [OR]
RewriteCond %{HTTP_USER_AGENT} ^Super [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR] 
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^suzuran [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^Telesoft [OR]
RewriteCond %{HTTP_USER_AGENT} ^The.Intraformant [OR]
RewriteCond %{HTTP_USER_AGENT} ^TheNomad [OR]
RewriteCond %{HTTP_USER_AGENT} ^TightTwatBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Titan [OR]
RewriteCond %{HTTP_USER_AGENT} ^turingos [OR]
RewriteCond %{HTTP_USER_AGENT} ^TurnitinBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^URLy.Warning [OR]
RewriteCond %{HTTP_USER_AGENT} ^VCI [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^web [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^www [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*Whacker.*$ [OR] 
RewriteCond %{HTTP_USER_AGENT} ^.*FileHound.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*TurnitinBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*JoBo.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*adressendeutschland.*$ [OR]

# die etwas gefaehrlicheren Regeln, weil komplexer und vielleicht zu viel verboten wird
RewriteCond %{HTTP_USER_AGENT} collect [NC,OR]
RewriteCond %{HTTP_USER_AGENT} crawl [NC,OR]
RewriteCond %{HTTP_USER_AGENT} download [NC,OR]
RewriteCond %{HTTP_USER_AGENT} francis [NC,OR]
RewriteCond %{HTTP_USER_AGENT} grabb [NC,OR]
RewriteCond %{HTTP_USER_AGENT} harvest [NC,OR]
RewriteCond %{HTTP_USER_AGENT} httrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} larbin [NC,OR]
RewriteCond %{HTTP_USER_AGENT} leech [NC,OR]
RewriteCond %{HTTP_USER_AGENT} libwww [NC,OR]
RewriteCond %{HTTP_USER_AGENT} majestic [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ng-search [NC,OR]
RewriteCond %{HTTP_USER_AGENT} nutch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} offline [NC,OR]
RewriteCond %{HTTP_USER_AGENT} omni [NC,OR]
RewriteCond %{HTTP_USER_AGENT} robot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} sohu [NC,OR]
RewriteCond %{HTTP_USER_AGENT} suck [NC,OR]

# gefaelschte Browserkennungen, die normale User vorgaukeln sollen
RewriteCond %{HTTP_USER_AGENT} ^MSIE\ 6.0 [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla\/4\.0\ (compatible;\ MSIE\ 6\.0;\ Win32) [OR] 
RewriteCond %{HTTP_USER_AGENT} MSIE\ 6.0b
RewriteRule ^.* - [F,L]
4. Schutzmaßnahmen für die laufende Bearbeitung

Auch in der laufenden Nutzung von CMS/ms sind verschiedene Sicherheitsmaßnahmen zu beachten:

4.1 Namen der Webseiten-Autoren

In News-Beiträge oder sonstigen Daten auf der Webseite, bei denen ein Besucher den Anmelde-Namen des Erstellers sieht, sollten auf keinen Fall mit einem Benutzer erstellt werden, der gleichzeitig Administrator ist! Legt dafür einen gesonderten Benutzer mit eingeschränkten Rechten an.

Für das News-Modul lässt sich die Anzeige beispielsweise ändern, indem man im Template anstatt $author (=Anmelde-Name) die Variable $authorname (= Realname) zur Anzeige des Namens des Erstellers verwendet.

4.2 Email-Adressen verschleiern

Sämtliche Email-Adressen sollten gegen den Zugriff von Spam-Bots geschützt werden. Smarty hat hierfür mit dem {mailto} Tag bereits geeignetes Werkzeug an Bord.

Email:{mailto address='test@beispiel.de' encode='hex'}</a>

4.3 Weitere persönliche Daten schützen

Zusätzlich lassen sich auch andere persönliche Daten wie zum Beispiel Telefonnummern) wie folgt schützen:

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

4.4 Prüfsummen des Systems erstellen

Es kommt immer wieder mal vor, dass ein System gehackt wird.

Um hier schneller problembehaftete Dateien erkennen zu können, bietet CMS/ms das Erstellen von Prüfsummen an. Zu erreichen ist diese Funktion in der Administration über "Webseiten-Einstellungen > Systemprüfung > Prüfsummen-Datei erstellen".

Dabei wird für jede Datei im System (einschließlich des /uploads-verzeichnisses) eine Prüfsumme erstellt und anschließend eine Protokoll-Datei zum Download angeboten.

Diese Datei solltet ihr gut aufbewahren, denn sie kann für eine spätere Prüfung auf der benannten Seite auch wieder hochgeladen werden. Im Sinne der Sicherheit des Systems sollte diese Datei nach jeder Bearbeitung erstellt werden, bei der Dateien im System geändert und/oder hinzugefügt wurden.

Dieser Beitrag erhebt keinen Anspruch auf Vollständigkeit cool . Habt ihr einen Hinweis, der hier erscheinen sollte, fügt einfach eine Antwort an.

Beitrag geändert von Andynium (22. November 2017 22:05)

Offline

#2 01. Februar 2011 20:07

LeisureLarry
Gast

Re: HowTo: CMS/made simple absichern

@cyberman:
Danke für das Retten des Beitrags. Könntest Du bitte bei Punkt 11 die URL auf den Beitrag hier im Forum ändern?
http://www.cmsmadesimple.de/forum/viewtopic.php?id=323

Danke
LeisureLarry (interiete.net)

#3 01. Februar 2011 21:39

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.927
Webseite

Re: HowTo: CMS/made simple absichern

Hab den Link angepasst. Danke für den Hinweis.


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#4 05. Februar 2011 02:59

NaN
Moderator
Ort: Halle (Saale)
Registriert: 09. November 2010
Beiträge: 4.435

Re: HowTo: CMS/made simple absichern

cyberman schrieb:

[*]Reduziert die Berechtigung der config.php so, dass nur noch Leserechte bestehen (chmod 444).[/*]

Das stellt aber nur einen sehr bedingten Schutz dar.
444 bedeutet, dass die config.php von JEDEM lesbar ist.

Besser wäre es, die config.php mit den Rechten 400 zu sichern.
Das bedeutet, dass sie nur vom Eigentümer gelesen werden kann.
Dazu muss der Eigentümer aber der PHP User - d.h. der Webserver - sein.

D.h. wer die Möglichkeit hat, mit CHOWN die Eigentumsrechte einer Datei zu ändern, sollte für die config.php den PHP User als Eigentümer und CHMOD 400 wählen. Somit kann die Datei nur noch vom Server selbst gelesen werden.
(Bei Änderungen an der config.php muss man aber vor dem Upload der geänderten Datei die Besitzrechte wieder auf den FTP User und CHMOD auf 600 ändern. Sonst kann man die Datei nicht überschreiben.)

Das hat den Vorteil, dass selbst wenn das FTP Passwort geknackt wurde, der Angreifer nicht via FTP auf die config.php zugreifen kann.

Der beste Schutz ist aber immer noch via .htaccess.


Module: GBFilePicker, AdvancedContent
Sicherheit: Beispiel .htaccess-Datei
CMSms 1.12 unter PHP 7:
cmsms-1.12.3.zip (inoffiziell - komplett inkl. Installer)
CMSms 1.12 unter PHP 8:
cmsms-1.12.4.zip (inoffiziell - komplett inkl. Installer)

Offline

#5 05. Februar 2011 08:14

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Danke für den Hinweis - hab das erste Posting bearbeitet.

Offline

#6 10. Februar 2011 16:16

LeisureLarry
Gast

Re: HowTo: CMS/made simple absichern

Das mit CHMOD 400 stimmt natürlich grundsätzlich, aber meine Anleitung bezog sich in der ursprünglichen Form alleinig auf Webspace und da wird man die Möglichkeit normalerweise nicht haben.

#7 10. Februar 2011 21:03

NaN
Moderator
Ort: Halle (Saale)
Registriert: 09. November 2010
Beiträge: 4.435

Re: HowTo: CMS/made simple absichern

Stimmt schon, aber ich meinte nicht CHOWN via ssh sondern über eine Funktion des Providers.

Es kommt auf den Provider bzw. das Paket an. Manche bieten einen Web-FTP Service an. Und dort hat man oftmals auch CHOWN zur Verfügung. Man hat dann lediglich die Möglichkeit, aus einem Dropdown den FTP User oder den Server für eine Datei oder ein Verzeichnis (bei Bedarf auch rekursiv) auszuwählen.

Allerdings ist dann, wenn das FTP Passwort geknackt wurde, sowieso Schicht im Schacht. Dann kann der Angreifer auch selbst über das Web-FTP zuschlagen.

Also immer schön auf die Passwörter achten.

Die meisten Provider bieten FTP Zugriff auch via SFTP oder TLS an.
Wer also FileZilla o.ä. verwendet, sollte unbedingt die verschlüsselten Protokolle verwenden.
(Bei den Web-FTP Zugängen nutzen die Provider sowieso schon https von Haus aus - kenne zumindest keinen, der das nicht macht. Und wenn doch, dann ist das kein Provider bei dem ich meine Seite betreiben möchte.)

Zum Thema SSL möchte ich noch kurz die URL- und Verzeichniseinstellungen meiner config.php vorstellen.
Wer also https zur Verfügung hat, kann auch sein Backend via SSL schützen:

EDIT:
Der obige Code ändert die root-URL zur Laufzeit. Das ist nicht gut, weil die root-URL auch für's Frontend gilt. Alle Links, die man beim Arbeiten im Backend auf Seiten oder Bilder setzt, bekommen dann die SSL URL. Das ist natürlich nicht immer gewollt.
Seit Version 1.10 gibt es für das Backend die Einstellung $config['admin_url']. Somit kann man dem Backend unabhängig von der Root-URL eine SSL URL geben.

Beitrag geändert von NaN (03. Juli 2014 07:29)


Module: GBFilePicker, AdvancedContent
Sicherheit: Beispiel .htaccess-Datei
CMSms 1.12 unter PHP 7:
cmsms-1.12.3.zip (inoffiziell - komplett inkl. Installer)
CMSms 1.12 unter PHP 8:
cmsms-1.12.4.zip (inoffiziell - komplett inkl. Installer)

Offline

#8 11. Februar 2011 15:26

X-TREM
probiert CMS/ms aus
Registriert: 17. Dezember 2010
Beiträge: 95
Webseite

Re: HowTo: CMS/made simple absichern

Ich hatte das diese Woche mal angewandt. Als ich dann aber Seiten ändern wollte, ging mein TinyMCE nicht mehr! Ursache ist das hier gewesen:

# 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

CMS 1.8.2
TinyMCE 2.7.3

Jemand gleiche Erfahrungen?

Beitrag geändert von X-TREM (11. Februar 2011 16:02)

Offline

#9 11. Februar 2011 15:30

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.927
Webseite

Re: HowTo: CMS/made simple absichern

Du musst das .htaccess noch um diese Zeile ergänzen:

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

(nach dem ersten Teil des deny auf die config.php)


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#10 20. Mai 2013 12:23

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Hab mal das Aussperren böswilliger Spider (Punkt 8 im ersten Beitrag) überarbeitet / ergänzt.

Danke Arvixe

http://blog.arvixe.com/prevent-maliciou … -htaccess/

Offline

#11 11. März 2014 21:10

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Hab mal die htaccess Listen zu Punkt 7 und 8 aktualisiert.

Offline

#12 02. Juli 2014 14:18

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Dem Thema neuen Absatz 6 hinsichtlich "X-Powered-By" hinzugefügt.

Offline

#13 24. November 2014 23:30

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Fehler im Parameter zu Punkt 16 geändert - der Dank geht an Dancer62.

Offline

#14 10. Dezember 2014 23:22

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

War bislang der Meinung, dass es zum Standard eines Webseiten-Admins gehört, das /install Verzeichnis einer online verfügbaren Software (nicht nur CMSMS) zu löschen. Offenbar aber nicht.

Habe daher einen Punkt 0. Verzeichnis /install löschen hinzugefügt - hat durch eine gerade bekannt gewordene Sicherheitslücke eine eigene Brisanz, siehe securityfocus.com/archive/1/534172

Offline

#15 10. Dezember 2014 07:52

Henk1060
Server-Pate
Registriert: 12. August 2011
Beiträge: 632

Re: HowTo: CMS/made simple absichern

Danke für den Hinweis und das Rundmail.
Aber eigentlich Hausverstand das man diesen ordner Löscht.

Offline

#16 10. Dezember 2014 21:35

Cherry
arbeitet mit CMS/ms
Registriert: 15. Dezember 2010
Beiträge: 529

Re: HowTo: CMS/made simple absichern

Die Liste unter Punkt 9 macht bei meinen Seiten Probleme. Jetzt habe ich sie mal durch nen htaccess Checker prüfen lassen  und es sieht so aus, als wenn Leerstellen im User-Agent und "/" Zeichen maskiert werden müssen.

Demnach müßte die Liste so aussehen:

# Spambots nach User_agent aussperren
Options +FollowSymLinks
RewriteEngine On
 
# Rewriting gegen boese Bots
RewriteCond %{HTTP_USER_AGENT} ^Alexibot [OR]
RewriteCond %{HTTP_USER_AGENT} ^asterias [OR]
RewriteCond %{HTTP_USER_AGENT} ^BackDoorBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Black [OR]
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^BlowFish [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^BotALot [OR]
RewriteCond %{HTTP_USER_AGENT} ^BuiltBotTough [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bullseye [OR]
RewriteCond %{HTTP_USER_AGENT} ^BunnySlippers [OR]
RewriteCond %{HTTP_USER_AGENT} ^Cegbfeieh [OR]
RewriteCond %{HTTP_USER_AGENT} ^CheeseBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^CherryPicker [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Convera [OR]
RewriteCond %{HTTP_USER_AGENT} ^CopyRightCheck [OR]
RewriteCond %{HTTP_USER_AGENT} ^cosmos [OR]
RewriteCond %{HTTP_USER_AGENT} ^Crescent [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DataFountains [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DittoSpyder [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Email [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^Extractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Foobot [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Global\ Confusion [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^hloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} ^httplib [OR]
RewriteCond %{HTTP_USER_AGENT} ^ia_archiver [OR]
RewriteCond %{HTTP_USER_AGENT} ^IBM_Planetwide [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR] 
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^Indy\ Library [OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^Jakarta [OR]
RewriteCond %{HTTP_USER_AGENT} ^JennyBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Kenjin [OR]
RewriteCond %{HTTP_USER_AGENT} ^Keyword [OR]
RewriteCond %{HTTP_USER_AGENT} ^LexiBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^libWeb [OR]
RewriteCond %{HTTP_USER_AGENT} ^lwp [OR]
RewriteCond %{HTTP_USER_AGENT} ^Lynx [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mata [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft.URL [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIIxpc [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^moget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^NICErsPRO [OR]
RewriteCond %{HTTP_USER_AGENT} ^NPBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^Openfind [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^ProPowerBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^ProWebWalker [OR]
RewriteCond %{HTTP_USER_AGENT} ^QueryN [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^RepoMonkey [OR]
RewriteCond %{HTTP_USER_AGENT} ^RMA [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SlySearch [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^Snoopy [OR]
RewriteCond %{HTTP_USER_AGENT} ^SpankBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^spanner [OR]
RewriteCond %{HTTP_USER_AGENT} ^Super [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR] 
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^suzuran [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^Telesoft [OR]
RewriteCond %{HTTP_USER_AGENT} ^The.Intraformant [OR]
RewriteCond %{HTTP_USER_AGENT} ^TheNomad [OR]
RewriteCond %{HTTP_USER_AGENT} ^TightTwatBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Titan [OR]
RewriteCond %{HTTP_USER_AGENT} ^turingos [OR]
RewriteCond %{HTTP_USER_AGENT} ^TurnitinBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^URLy.Warning [OR]
RewriteCond %{HTTP_USER_AGENT} ^VCI [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^web [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^www [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*Whacker.*$ [OR] 
RewriteCond %{HTTP_USER_AGENT} ^.*FileHound.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*TurnitinBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*JoBo.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*adressendeutschland.*$ [OR]

# die etwas gefaehrlicheren Regeln, weil komplexer und vielleicht zu viel verboten wird
RewriteCond %{HTTP_USER_AGENT} collect [NC,OR]
RewriteCond %{HTTP_USER_AGENT} crawl [NC,OR]
RewriteCond %{HTTP_USER_AGENT} download [NC,OR]
RewriteCond %{HTTP_USER_AGENT} francis [NC,OR]
RewriteCond %{HTTP_USER_AGENT} grabb [NC,OR]
RewriteCond %{HTTP_USER_AGENT} harvest [NC,OR]
RewriteCond %{HTTP_USER_AGENT} httrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} larbin [NC,OR]
RewriteCond %{HTTP_USER_AGENT} leech [NC,OR]
RewriteCond %{HTTP_USER_AGENT} libwww [NC,OR]
RewriteCond %{HTTP_USER_AGENT} majestic [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ng-search [NC,OR]
RewriteCond %{HTTP_USER_AGENT} nutch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} offline [NC,OR]
RewriteCond %{HTTP_USER_AGENT} omni [NC,OR]
RewriteCond %{HTTP_USER_AGENT} robot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} sohu [NC,OR]
RewriteCond %{HTTP_USER_AGENT} suck [NC,OR]

# gefaelschte Browserkennungen, die normale User vorgaukeln sollen
RewriteCond %{HTTP_USER_AGENT} ^MSIE\ 6.0 [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla\/4\.0\ (compatible;\ MSIE\ 6\.0;\ Win32) [OR] 
RewriteCond %{HTTP_USER_AGENT} MSIE\ 6.0b
RewriteRule ^.* - [F,L]

Offline

#17 08. Januar 2015 07:09

Dancer62
Server-Pate
Ort: 26345 Bockhorn, Niedersachsen
Registriert: 08. November 2013
Beiträge: 414

Re: HowTo: CMS/made simple absichern

cyberman schrieb:

4. Inhalt der robots.txt

Die Angabe zum Admin-Ordner sollte komplett aus der robots.txt in eurem CMS-Hauptordner gelöscht werden. Dies verhindert eine Indizierung der Admin-URL, aber ohne zu zeigen, wie diese lautet (die robots.txt für JEDEN lesbar).

Das Problem dabei ist allerdings, dass ich ohne jegliche Angabe (=Nennung) des Admin-Ordners den robots nicht sagen kann, dass sie diesen Ordner nicht indizieren sollen. Gemäß Standard gibt es nur ein "Disallow", aber kein "Allow". Demzufolge müsste meine Anweisung in der robots.txt lauten

Damit hätte ich aber wiederum einen Hinweis auf den Namen des Admin-Verzeichnisses (nein, es heisst bei mir nicht wirklich so  wink ). Lasse ich den Eintrag aber weg, so wird der Ordner aufgrund des fehlenden Eintrags dann allerdings indiziert... sad .

"Was tun ?", sprach Zeus, "die Götter sind besoffen und kotzen den Olymp voll...big_smile (frei nach Friedrich Schiller's "Die Teilung der Erde")


Man ist so alt, wie man sich fühlt...

Offline

#18 08. Januar 2015 09:48

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Zur Antwort zitier ich mich einfach mal selbst wink

cyberman schrieb:

3. Zusätzlicher Schutz für das /admin-Verzeichnis

Der neue Admin-Ordner sollte anschließend mit einem zusätzlichen .htpasswd/.htaccess-Schutz versehen werden.

Damit wird dann auch nix indiziert.

Offline

#19 16. Februar 2015 22:21

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Punkt 6 - Deaktivierung diverser sicherheitsrelevanter Servereinstellungen - umgeschrieben und erweitert.

Offline

#20 05. April 2015 06:44

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Da das Thema mittlerweile relativ komplex geworden ist, hab ich es neu strukturiert und eine Übersicht sowie diverse Ergänzungen eingefügt.

Offline

#21 23. Mai 2015 20:26

hibr01
hat von CMS/ms gehört
Registriert: 06. Mai 2015
Beiträge: 5

Re: HowTo: CMS/made simple absichern

@cyberman: Super Zusammenfassung. Bei Pkt. 3.6 sind aber im Listing noch einige Leerzeichen unmaskiert (Cherry hat das erwähnt). Führt bei mir zu einem 500er Fehler.

htaccess Checker Test Results:

Line	Content / Reason
35	RewriteCond %{HTTP_USER_AGENT} ^Express WebPictures [OR]
	RewriteCond: bad flag delimiters
43	RewriteCond %{HTTP_USER_AGENT} ^Global Confusion [NC,OR]
	RewriteCond: bad flag delimiters
56	RewriteCond %{HTTP_USER_AGENT} ^Indy Library [OR]
	RewriteCond: bad flag delimiters
58	RewriteCond %{HTTP_USER_AGENT} ^Internet Ninja [OR]
	RewriteCond: bad flag delimiters
73	RewriteCond %{HTTP_USER_AGENT} ^MIDown tool [OR]
	RewriteCond: bad flag delimiters
92	RewriteCond %{HTTP_USER_AGENT} ^Papa Foto [OR]
	RewriteCond: bad flag delimiters
175	RewriteCond %{HTTP_USER_AGENT} ^MSIE 6.0 [OR]
	RewriteCond: bad flag delimiters
176	RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4.0 (compatible; MSIE 6.0; Win32) [OR]
	RewriteCond: bad flag delimiters
177	RewriteCond %{HTTP_USER_AGENT} MSIE 6.0b
	RewriteCond: bad flag delimiters

Thx, Hani

Offline

#22 02. Juni 2015 12:09

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Upps, ist mir doch im Alltagsgeschäft glatt durchgerutscht - habs nun geändert.

@Cherry - danke für deine Überarbeitung
@hibr01 - danke für den Hinweis wink

Offline

#23 16. September 2015 13:02

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

Aus gegebenen Anlässen - trotz aller Absicherungen kann es passieren, dass mal eine Seite gehackt wurde,

"Was tun?" spricht Zeus, "die Welt ist weggegeben" (frei nach Schiller)

Was jetzt auf euch zukommt, bedeutet eine ganze Ecke Arbeit. Wie die Arbeit in diesem Fall konkret aussieht, hat @nockenfell hier

http://www.cmsmadesimple.de/forum/viewt … 536#p14536

chronologisch für euch festgehalten (gilt natürlich nicht nur bei Malware wink).

Offline

#24 16. September 2015 13:06

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.927
Webseite

Re: HowTo: CMS/made simple absichern

Hab gleich meinen Beitrag noch ein wenig aktualisiert.


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#25 16. September 2015 16:41

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: HowTo: CMS/made simple absichern

nockenfell schrieb:

Hab gleich meinen Beitrag noch ein wenig aktualisiert.

Prima, danke dir - genau genommen müsste man auch noch die Modul-Inhalte/-Templates kontrollieren.

Offline