Sicherheitsbericht

Wechseln zu: Navigation, Suche

Hinweis: Sie sind auf den Seiten der Moodle 1.9 Dokumentation. Die Dokumentation der aktuellsten Moodle-Version finden Sie hier: Sicherheitsbericht.

Moodle1.8

Dieser Bericht gibt Ihnen eine Übersicht über die sicherheitsrelevanten Einstellungen Ihrer Moodle-Installation - hier sehen Sie sozusagen auf einem Blick, ob Ihr System unter Sicherheitsaspekten vernünftig konfiguriert ist. Der Bericht ist ab Moodle 1.8.9 bzw. 1.9.4 verfügbar.

Zugriff über Website-Administration > Berichte > Sicherheitsbericht

Sicherheitsbericht

Im einzelnen gibt der Bericht eine Übersicht über folgende sicherheitskritische Konfigurationseinstellungen:

  • register_globals
register_globals gilt als eine sehr unsichere Einstellung für PHP. Sie sollte deaktiviert sein, damit Ihr Moodle sicher betrieben werden kann. Diese Einstellung können Sie in der PHP-Konfigurationsdatei php.ini, in der Apache/IIS Konfigurationsdatei oder einer Datei .htaccess vornehmen. In PHP Version 5 ist diese Einstellung in der Standard-Installation deaktiviert.
  • Unsicheres dataroot
dataroot ist das Moodle-Datenverzeichnis, in dem Moodle hochgeladene Dateien ablegt. Dieses Verzeichnis sollte nicht über das Web erreichbar sein.
  • Anzeige von PHP-Fehlern
Wenn die PHP-Einstellung display_errors aktiviert ist, dann kann jeder Nutzer eine fehlerhafte URL eingeben, um z.B. Informationen über die Verzeichnisstruktur Ihres Moodle-Servers zu erhalten. Generell wird die Aktivierung dieser Einstellung auf produktiven Websites nicht empfohlen, weil die Fehlermeldungen u.U. sensible Informationen über Ihren Server preisgeben könnten. Setzen Sie also display_errors=off.
  • Ohne Authentifizierung
Das Plugin Ohne Authentifizierung erlaubt den Zugriff auf Ihre Moodle-Installation ohne jegliche Authentifizierung. Es ist daher nicht für produktive Moodle-Installationen gedacht. Deaktivieren Sie diese Funktion unbedingt, es sei denn Sie betreiben eine Testseite zu Entwicklungszwecken.
  • EMBED/OBJECT
Die uneingeschränkte Nutzung von EMBED/OBJECT ist äußerst gefährlich, weil alle registrierten Nutzer/innen einen XSS-Angriff gegen andere Server-Nutzer starten könnten. Diese Einstellung sollte auf produktiven Servern deaktiviert sein.
  • Mediafilter .swf
Die automatische Einbindung von swf-Dateien ist sehr gefährlich. Jeder registrierte Nutzer könnte damit eine XSS-Attacke gegen den Server auslösen. Diese Einstellung sollte auf produktiven Servern deaktiviert sein.
  • Offene Nutzerprofile
Nutzerprofile sollten nicht frei über das Web, d.h. ohne Authentifizierung, zugänglich sein - sowohl aus Datenschutzgründen als auch, um Spam zu vermeiden. Aktivieren Sie daher die Einstellungen Anmeldung notwendig (forcelogin) bzw. Anmeldung notwendig, um Profile sehen zu können (forceloginforprofiles) unter Website-Administration > Sicherheit > Website-Rechte.
  • Offen für Google
Die Einstellung Offen für Google erlaubt es Google und anderen Suchmaschinen, mit der Gastberechtigung alle offenen Kurse zu durchsuchen. Es ist nicht sinnvoll diese Funktion zu aktivieren, wenn der Gastzugang deaktiviert ist.
  • Passwortregeln
Es wird empfohlen, Passwortregeln festzulegen, denn oft ist es ziemlich einfach, über das Erraten von Kennwörtern einen unberechtigten Zugang zum System zu bekommen. Die Regeln sollten allerdings nicht zu kompliziert sein. Sehr strenge Regeln führen nämlich häufig dazu, dass Nutzer sich die Kennwörter nicht merken können, sie vergessen oder aufschreiben.
  • Kennwortverschlüsselung (Salt)
Die Verwendung eines Salts zur Kennwortverschlüsselung reduziert das Risiko des Kennwortdiebstahls erheblich.
  • E-Mail-Adressänderungen
Es wird empfohlen, eine E-Mail-Bestätigung einzufordern, wenn Nutzer/innen ihre E-Mail-Adresse im Nutzerprofil ändern. Falls diese Einstellung deaktiviert ist, könnten Spammer versuchen, den Webserver zum Versenden von Spam zu missbrauchen.
  • Sichere Cookies
Zusätzlich zur Aktivierung der Datenübertragung über https sollte auch die Funktion sichere Cookies aktiviert werden. Die permanente Umleitung von http nach https sollte ebenfalls eingerichtet werden.
  • Dateirechte für config.php
Es wird dringend empfohlen, nach der Installation von Moodle die Zugriffsrechte für die Moodle-Konfigurationsdatei config.php so zu setzen, dass der Webserver diese Datei nicht verändern kann. Bitte beachten Sie, dass dieser Schritt die Server-Sicherheit nicht entscheidend verbessert, aber er kann generelle Angriffe in ihrem Ausmaß begrenzen.
  • XSS - vetrauensvolle Nutzer
RISK_XSS bezeichnet alle bedenklichen Berechtigungen, die ausschließlich vertrauensvolle Nutzer ausführen dürfen. Stellen Sie sicher, dass die aufgelisteten Nutzer vertrauenswürdig sind - es sind diejenigen Nutzer Ihrer Moodle-Installation, die aufgrund ihrer Rollen und Rechte potentielle XSS-Angriffe z.B. in Forumsbeiträgen etc. vornehmen können.
  • Administratoren
Prüfen Sie die Liste der Nutzer, die in Ihrer Moodle-Installation die Administrator-Rolle.
  • Registrierte Nutzerrolle
Jeder angemeldete Nutzer hat zunächst Rechte entsprechend der Rolle, die mit der Einstellung Standardrolle für alle Nutzer/innen (defaultuserroleid) unter Website-Administration > Nutzer/innen > Zugriffsrechte > Nutzereigenschaften konfiguriert ist. Es wird geprüft, ob die Rechte für diese Rolle geeignet (sicher) definiert sind.
  • Gastrolle
Unter Website-Administration > Nutzer/innen > Zugriffsrechte > Nutzereigenschaften wählen Sie eine Rolle als Rolle für Gäste (guestroleid) aus. Es wird geprüft, ob diese Rolle geeignete (sichere) Rechte hat.
  • Rolle auf der Startseite
Unter Website-Administration > Startseite > Einstellungen wählen Sie eine Rolle als Standardrolle für Startseite aus. Es wird geprüft, ob diese Rolle geeignete (sichere) Rechte hat.
  • Standardrolle (global)
Unter Website-Administration > Nutzer/innen > Zugriffsrechte > Nutzereigenschaften wählen Sie eine Rolle als Standardrolle für Nutzer/innen in einem Kurs (defaultcourseroleid) aus. Es wird geprüft, ob diese Rolle geeignete (sichere) Rechte hat.
  • Standardrollen (für Kurse)
Jeder Kurs hat in den Kurseinstellungen eine Standardrolle für Nutzer definiert - i.d.R. ist dies die Teilnehmer-Rolle. Es wird geprüft, ob es Kurse gibt, in denen diese Standardrolle ungeeignet gewählt ist.

Siehe auch