Liebe Moodle-Freunde
Unsere Schüler behaupten, mit einem "Sniffer" die Moodle-Passwörter innerhalb des internen Schulnetzes lesen zu können.
Dadurch könnten z.B. Schüler die Lehrerpasswörter bekommen und ihre Bewertungen ändern.
Was kann man dagegen tun ?
Gibt es die Möglichkeit, per https auf Moodle zuzugreifen ?
Viele Grüße aus Düsseldorf
Horst
Hallo Horst,
mit meinem rudimentären EDV-Wissen kann ich dir folgendes mitteilen:
In diesem Sinne: Viel Erfolg!
Dag
mit meinem rudimentären EDV-Wissen kann ich dir folgendes mitteilen:
- Wenn kein SSL (=https) verwendet wird, werden die Kommunikationsinhalte im Klartext übermittelt. Vgl. normales POP3 und SMTP.
- ob ein Sniffen erfolgreich sein kann, hängt wohl auch von der verwendeten Hardware bei euch ab (Hub oder Switch) ...
- ob ein Sniffen erfolgreich sein kann, hängt wohl auch von der verwendeten Hardware bei euch ab (Hub oder Switch) ...
- Wichtig: Bevor die nächsten Schritte angegangen werden, sollte geprüft werden, ob der Server / der Hoster überhaupt die SSL-Anforderungen erfüllen kann / will.
- Du kannst in deinem Moodle-System
- die ganze Kommunikation schützen, was aber zu Ressourcenproblemen führen kann. Außerdem wird es bei einer derartigen Änderung noch Folgeaufgaben bezüglich der internen Links usw. geben.
- nur das Login mit SSL-Verschlüsselung schützen. Dies stellst du als Admin ein.
- Bezüglich des SSL-Zertifikates gibt es die Unterscheidung zwischen
- "privaten", selbst erzeugten - hier bekommen die TN eine Fehlermeldung, es ist aber kostenfrei und die Kommunikation nicht "abhörbar".
- "öffentlichen" von einer berechtigten Zertifizierungsstelle, nicht kostenfrei, mit der Folge, dass keine man-in-the-middle-Angriffe möglich sein sollten.
In diesem Sinne: Viel Erfolg!
Dag
Hallo Horst,
ein paar Ergänzungen zu Dag, dessen Aussagen ich voll unterschreiben kann:
a) Selbstsigniertes Zertifikat
Mit einem Netzwerksniffer kann ich im Schulnetzwerk noch ganz andere Dinge erlauschen, die wesentlich interessanter als ein Moodlepasswort sein dürften. Solange der Schulswitch nicht VLAN-fähig ist (dann steht da Cisco o.ä. drauf), dürfte es zudem eigentlich egal sein, ob es ein Hub oder Switch ist. Das ist ein grundsätzliches Problem. Es ist genauso grundsätzlich wie die Tatsache, dass viele Anwender zu simplen Passworten neigen, die ich in endlicher Zeit bruteforcen kann. Sicherheit ist ein sehr, sehr komplexes Thema.
Klartextprotokolle (z.B. POP3, SMTP, FTP) existieren m.E. deswegen noch, weil sie bequem sind - nicht weil sie sicher sind.
ein paar Ergänzungen zu Dag, dessen Aussagen ich voll unterschreiben kann:
a) Selbstsigniertes Zertifikat
Davon würde ich dringend abraten. Moderne Browser (FF3, IE7) bringen in diesem Fall derartige Alarmmeldungen, dass selbst unbedarfte Anwender davon sicher eingeschüchtert werden. Es gibt sehr günstige Zertifikate z.B. unter http://www.psw.net. Da reicht das kleinste (15,- Euro/pro Jahr) vollends aus. Es wird von nahezu allen modernen Browsern problemlos gefressen.
b) Login via https
Ohne sorgfältige Vorbereitung ist das ein Garant für einen unfreiwilligen Ausflug in die Datenbank. Stellt man das einfach so mal um, ist man u.U. komplett ausgesperrt.
c) Ressourcenbeanspruchung
SSL geht hauptsächlich auf die CPU, die auch bei Moodle unter Vollast (70-80 aktive Clients) auf einem meiner betreuten Server nie ernsthaft gefordert war. Mit meinem Lieblingswebserver lighttpd konnte ich nur 5%-10% mehr CPU-Last im Vergleich zu Verbindungen ohne SSL "messen".
Wir werden das an unserer Schule mit einem SSL-Proxy lösen (also alles verschlüsseln), der transparent auf vierschiedene lokale Domains durchleitet und noch weitere Vorteile mit sich bringt (z.B. Schutz des Backends vor Anfragen durch Caching).
Warum ich mit diesem technischen Mist jetzt komme:
Viele Provider bieten einen SSL-Proxy von Hause aus an - fragen kostet ja nichts.
Gruß,
Maik
b) Login via https
Ohne sorgfältige Vorbereitung ist das ein Garant für einen unfreiwilligen Ausflug in die Datenbank. Stellt man das einfach so mal um, ist man u.U. komplett ausgesperrt.
c) Ressourcenbeanspruchung
SSL geht hauptsächlich auf die CPU, die auch bei Moodle unter Vollast (70-80 aktive Clients) auf einem meiner betreuten Server nie ernsthaft gefordert war. Mit meinem Lieblingswebserver lighttpd konnte ich nur 5%-10% mehr CPU-Last im Vergleich zu Verbindungen ohne SSL "messen".
Wir werden das an unserer Schule mit einem SSL-Proxy lösen (also alles verschlüsseln), der transparent auf vierschiedene lokale Domains durchleitet und noch weitere Vorteile mit sich bringt (z.B. Schutz des Backends vor Anfragen durch Caching).
Warum ich mit diesem technischen Mist jetzt komme:
Viele Provider bieten einen SSL-Proxy von Hause aus an - fragen kostet ja nichts.
Gruß,
Maik
HTTPS und Moodle sind bei uns Standard in Lernumgebungen.
Wir setzen nur "sichere Zertifikate" ein, denn Prüfungen sind kein "Spass".
Firefox = problemlos
IE kann oft schimpfen
ABER "lauschen" gibts keines mehr!
Peter Sereinigg
Wir setzen nur "sichere Zertifikate" ein, denn Prüfungen sind kein "Spass".
Firefox = problemlos
IE kann oft schimpfen
ABER "lauschen" gibts keines mehr!
Peter Sereinigg