moodle Sicherheit Best Practise

Moodle Sicherheit Best Practise

von

Warum die Absicherung Ihrer Moodle‑Instanz jetzt Priorität hat

Moodle ist der Kern vieler Lernumgebungen. Genau deshalb ist die Plattform ein attraktives Ziel für Angriffe: schwache Konfigurationen, unsichere Plugins, veraltete Software oder frei zugängliche Entwicklungsdateien. Dieser Leitfaden bündelt Best Practise für mehr Sicherheit – pragmatisch, umsetzbar und ohne esoterische Empfehlungen. Sie stärken damit die Vertraulichkeit, Integrität und Verfügbarkeit Ihrer Lernplattform.

Architektur und Updates: das Fundament der Sicherheit

Sicherheit beginnt vor der Weboberfläche. Ein paar Grundsätze, die konsistent Wirkung zeigen:

  • Halten Sie Betriebssystem, Webserver, PHP, Datenbank und Moodle selbst kontinuierlich aktuell. Planen Sie Wartungsfenster und ein abgestuftes Deployment (Staging vor Produktion) ein.
  • Minimieren Sie die Angriffsfläche: Nur notwendige Dienste laufen lassen, Admin-Oberflächen hinter VPN oder IP‑Allowlist. Reverse Proxy oder WAF kann helfen, bösartige Requests früh zu filtern.
  • Reduzieren Sie Komplexität: Weniger Zusatzmodule bedeuten weniger Risiko. Installieren Sie nur Plugins aus vertrauenswürdigen Quellen und prüfen Sie sie vorab in einer Testumgebung. Für die sichere Integration externer Konferenzsysteme finden Sie konkrete Hinweise in unserem Beitrag BigBlueButton in Moodle integrieren – sicher einrichten.

Ein praktischer Schritt für Update-Planung: Ermitteln Sie schnell die aktuell eingesetzte Moodle‑Version und Abhängigkeiten. Wie das geht, zeigt unser Quick‑Tipp: Moodle‑Version schnell ermitteln.

Webserver-Härtung: HTTPS, Header, Request‑Filter

  • Erzwingen Sie durchgehend HTTPS mit einem gültigen Zertifikat und aktivieren Sie HSTS (HTTP Strict Transport Security), damit Browser nur noch verschlüsselt zugreifen.
  • Setzen Sie sichere HTTP‑Header (z. B. Content Security Policy, X‑Content‑Type‑Options, Referrer‑Policy), um Skript‑Injection, MIME‑Sniffing oder unnötige Datenweitergabe zu begrenzen.
  • Filtern Sie Requests: Blocklisten für bekannte Entwicklungs‑ und Testpfade verhindern, dass sensible Dateien ausgeliefert werden.

Beispiel: .htaccess‑Regeln für sensible Pfade und Dateien

Wenn Ihre Moodle‑Instanz über Apache mit .htaccess arbeitet, können Sie den Zugriff auf Entwicklungsdateien und Metadaten unterbinden. Die folgenden Regeln blockieren typische Targets wie .git, .env, Tests, Readme/Upgrade‑Hinweise und bestimmte XML‑Artefakte:

<IfModule mod_rewrite.c>
RewriteEngine On

# ---- sensible versteckte Dateien (.git, .env, etc.) ----
RewriteRule (?i)^\.git(/|$) - [R=404,L]
RewriteRule (?i)^\.github(/|$) - [R=404,L]
RewriteRule (?i)^\.env$ - [R=404,L]
RewriteRule (?i)^\.stylelintrc$ - [R=404,L]
RewriteRule (?i)^\.upgradenotes.*$ - [R=404,L]

# ---- sensible Einzeldateien ----
RewriteRule (?i)^.*(composer\.json|composer\.lock)$ - [R=404,L]
RewriteRule (?i)^admin/environment\.xml$ - [R=404,L]
RewriteRule (?i)^lib/db/install\.xml$ - [R=404,L]
RewriteRule (?i)^mod/.+/db/install\.xml$ - [R=404,L]
RewriteRule (?i)^.*phpunit\.xml(\.dist)?$ - [R=404,L]
RewriteRule (?i)^lib/classes/?$ - [R=404,L]

# ---- README / Upgrade / Hinweisdateien ----
# (alle Ebenen, auch tief verschachtelte Pfade)
RewriteRule (?i).*/?(readme(_moodle)?\.txt|readme\.md)$ - [R=404,L]
RewriteRule (?i).*/?(upgrade(\.txt)?|upgrading(-current)?\.md)$ - [R=404,L]

# ---- Tests & Entwicklungsverzeichnisse ----
RewriteRule (?i).*/?(tests|behat|fixtures)(/|$) - [R=404,L]
</IfModule>
Moodle Sicherheit Pfade

Testen Sie Änderungen zuerst in einer Staging‑Umgebung. Falls Sie Nginx nutzen, setzen Sie äquivalente location‑Blöcke. Ziel bleibt identisch: Entwicklungsartefakte, Meta‑ und Testdateien dürfen nicht über HTTP erreichbar sein.

Dateisystem, Berechtigungen und Moodle‑Datenverzeichnis

  • Trennen Sie Code und Daten konsequent: Das Moodle‑Datenverzeichnis (dataroot) gehört außerhalb des Webroots. Der Webserver darf es lesen und schreiben, der PHP‑Code darf nicht direkt via URL erreichbar sein.
  • Prinzip der minimalen Rechte: Der Webserver‑User benötigt im Code‑Verzeichnis nur Leserechte (bis auf empfohlene Upload/Temp‑Pfade), das Datenverzeichnis ist schreibbar. Beispiel unter Linux:
# Beispiel: Webserver-User www-data, Pfade anpassen!
sudo chown -R www-data:www-data /var/moodledata
sudo find /var/www/moodle -type f -exec chmod 640 {} \;
sudo find /var/www/moodle -type d -exec chmod 750 {} \;
  • Deaktivieren Sie Directory Listings und blockieren Sie direkte Zugriffe auf interne Ordner (Cache, Temp, Lokalisierungen), sofern nicht bereits durch die Anwendung geregelt.

Authentifizierung: SSO, starke Passwörter und Session‑Sicherheit

  • Nutzen Sie zentrale Identitäten via OAuth2/OpenID Connect und erzwingen Sie Multi‑Faktor‑Authentifizierung in Ihrem IdP. Eine sichere, praxiserprobte Anbindung zeigt unser Beitrag Moodle SSO mit OAuth2 und Nextcloud Service einrichten.
  • Setzen Sie Password Policies (Länge, Komplexität, Ablauf), begrenzen Sie Login‑Versuche und verwenden Sie Captcha/Rate‑Limiting für öffentlich zugängliche Formulare.
  • Erzwingen Sie sichere Sessions nur über HTTPS, mit Secure‑ und SameSite‑Cookies. Trennen Sie Admin‑Zugänge technisch (z. B. IP‑Filter/VPN) und organisatorisch (Rollen, Vier‑Augen‑Prinzip bei kritischen Änderungen).

Betriebsprozesse: Cron, Backups, Wiederherstellung

  • Cron nur per CLI: Führen Sie Moodle‑Cronjobs per System‑Cron/Timer und CLI‑PHP aus, nicht über öffentlich erreichbare URLs. So verringern Sie Missbrauchsmöglichkeiten und stabilisieren Laufzeiten.
  • Backups als Routine: Sichern Sie Datenbank, moodledata und Konfiguration regelmäßig, verschlüsselt und versioniert. Definieren Sie Aufbewahrungszeiträume und testen Sie Wiederherstellungen in festgelegten Abständen. Ohne Restore‑Test ist kein Backup verlässlich.
  • Abhängigkeiten einbeziehen: Dokumentieren Sie PHP‑Extensions, Mail‑Gateway, externe Speicher/Objekt‑Storage und Integrationen (z. B. Videokonferenzen). Nur vollständige Wiederherstellungsketten verhindern lange Ausfälle.

Monitoring, Protokolle und Abwehr

  • Überwachen Sie Verfügbarkeit, Latenz, Fehler‑Raten, Cron‑Erfolg, Plattenplatz sowie TLS‑Zertifikat‑Gültigkeit. Alarme müssen priorisiert und testbar sein.
  • Aktivieren und sammeln Sie Logdaten (Webserver, PHP, Anwendung). Definieren Sie Schwellenwerte für auffällige Anmeldeversuche, 4xx/5xx‑Spitzen oder ungewöhnliche Request‑Muster.
  • Setzen Sie IP‑Blockaden/Delay bei Brute‑Force‑Muster ein (z. B. mit Fail2ban auf Webserver‑Logs). Ergänzend helfen Geo‑IP‑Filter, wenn Ihr Nutzerkreis regional begrenzt ist.
  • Minimieren Sie Plugin‑Risiken: Halten Sie Erweiterungen aktuell, entfernen Sie ungenutzte Module und prüfen Sie Changelogs vor jedem Update. Bei Integrationen wie Webkonferenz‑Plugins gelten dieselben Prinzipien – Details zur sicheren Einrichtung liefert der oben verlinkte BigBlueButton‑Artikel.

Konfigurationshygiene: kleine Maßnahmen, große Wirkung

  • Deaktivieren Sie Debug‑Ausgaben in Produktion. Fehler gehören ins Log, nicht in den Browser.
  • Validieren Sie Uploads streng (Dateitypen, Größe, Virenscan). Beschränken Sie Ausführungsrechte in Upload‑Verzeichnissen.
  • Nutzen Sie Konfigurationsmanagement (Git, sichere Secrets‑Verwaltung) und vermeiden Sie hartkodierte Zugangsdaten. Produktions‑Secrets gehören nicht ins Repository.

Wenn Sie eine bestehende Instanz sicher nachhärten möchten oder eine neue Lernumgebung aufsetzen, unterstützen wir Sie auf Wunsch pragmatisch – von der Architektur bis zum Betrieb. Einen Überblick zu unseren Leistungen rund um Moodle finden Sie auf der Seite ADMIN INTELLIGENCE – Moodle. Weitere praxisnahe Beiträge – von SSO‑Integration bis zur sicheren Videokonferenz‑Anbindung – lesen Sie fortlaufend in unserem Blog unter blog.admin-intelligence.de. Benötigen Sie Unterstützung bei der Umsetzung oder einem Security‑Review, erreichen Sie uns unkompliziert über die Kontaktseite.