Probleme im Schulnetz bei den Accounts
Hans-Dietrich Kirmse
hd.kirmse at gmx.de
Thu Mar 20 12:25:02 CET 2003
Hallo,
In der Hoffnung, das folgende Aussage ernst gemeint ist:
<zitat>
und darum versuchen wir auch Leute aus der Praxis
hinzuzuziehen, die uns sagen was benoetigt wird.
</zitat>
möchte ich hier mal die Probleme im Schulnetz bei den Accounts
(Anmeldeserver) aus meiner Sicht darstellen. Logischerweise nur
als Diskussionsgrundlage.
Einrichtung der Accounts:
=========================
jeder User erhält einen Account, der in Sonderfällen einzeln
angelegt werden kann, üblicherweise aber automatisch generiert
wird, natürlich klassenweise.
Standardmäßig wird das Login aus dem ersten Buchstaben des Vornamens
und aus dem Nachname gebildet. Dabei sind aber nur max.
??? ASCII-Zeichen möglich, sonst wird entsprechend gekürzt.
(Beispiel: Manfred Mustermann -> mmustermann).
Sollten Logins nach diesem Muster schon vergeben sein, wird
automatisch variiert (z.B. 2 Buchstaben vom Vornamen).
Dabei wird gleichzeitig ein Mailaccount generiert. Die Mailadresse
ergibt sich aus dem Login und der Schuldomain
(z.B. Manfred Mustermann <mmustermann at schuldomain.de> ).
Schüler gehören in die Gruppe entsprechend ihrer Klassenbezeichnung.
Alle Lehrer gehören in die Gruppe "lehrer".
zu erwartende Probleme
======================
1. Es wird ohne Account gearbeitet (z.B. mit eigenem Betriebssystem,
eigenem Rechner). Damit lassen sich alle Maßnahmen, die auf den
Arbeitsstationen eingerichtet sind problemlos entgehen.
2. Die generierten Passwörter sollen nicht erraten werden können.
war ein z.B. ein Problem beim Arktur, der beim Erstellen der
Accounts das Passwort gleich dem Login setzte, da insbesondere
in kleinen Klassen und bei fehlenden Schülern die Passwörter
kaum geändert wurden, war die Auflistung praktisch eine
öffentliche Passwortliste. Wenn aber individuelle Passwörter
generiert werden, dann ergibt sich bei Anlegen von mehreren
Klassen das nächste Problem.
3. Die generierten Passwörter müssen problemlos weitergegeben werden
können, auch für einen ganzen Jahrgang oder für die ganze Schule.
4. Es werden die Paßwörter viel zu lange verwendet.
5. Es werden ungeeignete Paßwörter gewählt.
6. Passwörter werden weitergegeben u.a.m.
7. Es werden Passwörter vergessen.
8. Passwörter von anderen Accounts werden durch "brute force"-Angriffe
in Erfahrung gebracht.
9. Passwörter von anderen Accounts werden durch Sniffen in Erfahrung
gebracht.
Maßnahmen/Lösungen
==================
zu 1. Es sollte die Nutzung aller Dienste nur mit Anmeldung möglich
sein. Das bedeutet insbesondere für die Nutzung des Proxys,
daß (auf Wunsch) die Anmeldung erzwungen werden kann.
zu 2. Das bedeutet insbsondere, das für die generierten Accounts
brauchbare (also zufällige) Paßwörter generiert werden. Es
verbietet sich die Initialisierung mit Standardpaßwörtern wie
"geheim" oder "passwort" bzw. nach dem Muster Passwort = Login.
zu 3. Denkbar wäre die Ausgabe als csv-Datei, damit diese in Daten-
banken zur Verwendung als Serienbrief importiert werden können.
zu 4. Die Schüler sollten eine einfache, aber sichere Möglichkeit
haben, ihr Passwort jederzeit ändern zu können. Wünschenswert
wäre ein Webinterface.
zu 5. Es sollte eine detaillierte Anleitung zur Erstellung brauchbarer
Passwörter bereitgestellt werden. Ebenso sollte eine Möglichkeit
vorhanden sein, die Qualität der Passwörter zu testen.
Falls gewünscht sollte die Möglichkeit bestehen, für Passwörter
verschiedene Restiktionen einzustellen (Mindestlänge, auch
numerische Zeichen, max. Anzahl von Anmeldeversuchen).
zu 6. Im Unterricht sollte eine einfache Kontrolle der Verwendung des
richtigen Logins möglich sein.
Denkbar wäre das Generieren einer Webseite, bei der alle
angemeldeten Nutzer und die betreffenden PCs aufgelistet werden.
Optional: wenn möglich sollte zusätzlich auch Mehrfachanmeldung
für Schüler unterbunden werden können. (mit LDAP?)
zu 7. Ausgewählte Lehrer (z.B. Informatiklehrer) erhalten die
Möglichkeit über ein Webinterface die Passwörter von Schülern
neu zu setzen.
zu 8. Gegen "Brute force"-Angriffe könnte m.E. die Beschränkung der
Anmeldeversuche einen wirksamen Beitrag leisten, z.B. max.
5 Fehlversuche.
zu 9. Es sollten nur solche Dienste genutzt werden, bei denen die
Übertragung der Passwörter verschlüsselt erfolgt.
Ich denke es ist klar, das die Punkte 1-7 dem Nutzungskonzept
entnommen sind, die Punkte 8 und 9 zum Sicherheitskonzept gehören.
Um den Vergleich mit Arktur zu wagen:
Punkt 1 nicht erfüllt, da der Anmeldezwang beim Proxy nicht
standardmäßig realisiert ist. allerdings sind 2 Lösungen an
verschiedenen Stellen beschrieben.
Punkt 2 seit ca. 2 Jahren realisiert.
Punkt 3 nicht sauber gelöst. Es gibt eine Anleitung, diese auf
Umwegen in Excel zu übernehmen.
Punkt 4 voll erfüllt.
Punkt 5 - verständliche Anleitung auf dem Webinterface vorhanden.
- Kontrollmöglichkeit nicht vorhanden. Ein bisher genutzter
externer Dienst wurde leider eingestellt.
- an Restriktionen ist nur die Vorgabe mind. 5 Zeichen.
leider ist die Passwortlänge auf max. 8 Zeichen begrenzt.
Punkt 6 im Orginal nicht gewährleistet.
Das Script smbstatus2html gewährleistet aber auf einfache Weise diese
Kontrolle, sofern man die Anmeldung am Fileserver erzwungen wird.
Eine vergleichbare Lösung für Linuxclients existiert nicht.
Punkt 7 ist gewährleistet. Leider gibt es hier m.E. einen Design-
fehler, weil diese Funktion an die sognannte Fachlehrershell geknüpft
ist. Diese hat Zugriff auf die Homeverzeichnisse der schüler, was
dem "Prinzips des kleinsten Privilegs" widerspricht. Lehrer haben
bei uns nicht in den Homeverzeichnissen der Schüler zu schnüffeln.
Da auch der Skolelinux-Server solche Ambitionen unterstützt die
Anmerkung, in die Schultaschen darf ein Lehrer ohne besonderen Anlaß
auch nicht einfach schauen. Also, das eine darf nicht das andere
bewirken oder voraussetzen.
Punkt 8 nicht erfüllt
Punkt 9 ist bei entsprechender Konfiguration (Nutzung von IMP mit SSL,
SSH, ...) durchaus möglich, wird aber noch nicht sauber realisiert
(Mail, die Webinterface laufen ncht standardmäßig mit SSL).
Das wären aus meiner Sicht (ohne Anspruch auf Vollständigkeit)
die Gedanken zum Problem der Accounts.
Um keine Mißverständnisse aufkommen zu lassen, es geht darum
was auftreten kann - nicht muß. Es kann (falls der Admin so will
bzw. die Situation es so zuläßt natürlich auch mit Computeraccounts
gearbeiten werden. Aber der Anforderungskatalog hat sich doch
am schlechtesten Fall zu orientieren, denn wenn der beherrscht werden
kann, dann kann man auch den besten Fall beherrschen.
Da ich wirklich erst einer reichlichen Woche (frühestens) dazu komme
selbst zu testen, wäre ich über einen Stand bzgl. Skolelinux
interessiert. an kontruktiven Meinungen sowieso.
/"\
Mit freundlichen Grüßen \ / ASCII ribbon campaign
Hans-Dietrich X against HTML mail
/ \ and postings
More information about the SAN
mailing list