Pflichtenheft aktuell (2)

[Alexander Dubielczyk]

Am Mit, 2003-05-21 um 21.22 schrieb Stephan Beyer:

Hallo Stephan,

> > Zum Thema Absicherung fällt mir noch ein, dass irgendwo vermerkt werden
> > sollte, dass alle Verbindungen die eine Passwortauthentifikation nötig
> > ist (z.B. Admin-Interface, Webmail-Client etc.) durch SSL gegen Sniffing
> > geschützt werden sollte.
> 
> ich kann mir kaum vorstellen, dass sich ein schueler in der schule
> so einen aufwand macht und ob sie ueberhaupt faehig dazu sind :)

Denkste. Ich hab mir das mal von zwei Schülern (Jhgst. 12) aus dem
Netzwerk-Team der Schule, die ich betreue, demonstrieren lassen.
Notebook mit ethereal und dsniff drauf an irgendeiner Netzwerkdose in
geswitchter Umgebung. Das hat nicht zwei Minuten gedauert den Switch so
zu verwirren, dass der nur noch wie ein dummer Hub gearbeitet hat und
alle Daten an alle Ports gingen. Danach war das Sniffen so einfach, dass
man es ohne weiteres jedem Mausschubser beibringen könnte. Du glaubst
nicht, wie schnell da die Passwörter von Websites (Webmail), POP etc.
ausspioniert sind. 

Zum Glück spielen die beiden halt auf der "richtigen" Seite. Aber warum
sollte es auch nicht mal anders kommen? Meine persönliche Konsequenz
war, bei der Erweiterung des Netzwerks nur noch entsprechend geschützte
Switches zu kaufen und soweit möglich SSL zu verwenden.

> also soviel ich weiss muesste ein sniffer ja auf dem server selbst laufen
> und fuer ein normaler schueler muesste dazu erstmal ne shell aufm server
> haben ... oder er ist geschickt, ueber cgis auf seiner homepage... ok,
> denkbar waer es... auf technischer eben ist das soviel ich weiss kaum
> aufwand (apt-get install apache-ssl, und diesen apache dann normal in
> /etc/apache-ssl/ konfiguerieren).
> 
> > > Laufwerk t als Tauschverzeichnis
> > [...]
> > 
> > Vielleicht wäre es besser hier eine Art Verfallsdatum für die Dateien
> > auf dem Tauschlaufwerk zu definieren. Z.B. Alles was älter als x Tage
> > ist wird gelöscht?!
> 
> von der sache her halte ich dieses vorgehen fuer sinnvoller, allerdings
> wuerde das technisch bedeuten, dass nicht nur einmal im monat ein cronjob
> durchlaufen muesste, der einfach nur loescht, sondern dass jeden tag ein
> cronjob durchlaufen muss, der von allen dateien auf t die mtime
> ueberprueft und dann entscheidet, ob er sie loeschen will... die frage
> ist, wie sehr will man so einen armen schulserver mit cronjobs belasten? :)
> 
> nun ja vorteile haette dieses vorgehen schon.. beispiel: ein lehrer schreibt
> am 30.4. eine lk (test) in medienkunde und die schueler muessen eine
> powerpoint praesentation "abgeben", naemlich am ende auf t legen... der
> lehrer will natuerlich zu hause kontrollieren, hat aber keine diskette
> mit, und muss eh weg (zb wegen hochzeitstag)... er denkt sich also
> "morgen ist auch noch ein tag" und da beginnt das problem mit dem
> jetzigen system: t ist am 1.5. geleert ;) mit dem von alexander
> vorgeschlagenen prinzip waeren die daten erst zb nach 14 tagen weg, und
> nur die. 

Ich sehe bei dem Verfahren die gleichen Vorteile wie Du, kann aber auch
Hans-Dietrichs Gegenargumente teilweise nachvollziehen. Vielleicht kann
man ein Standard-Verfahren benutzen und den Admin das andere als
Alternative auswählen lassen, wenn ihm der Standard nicht passt. Das
dürfte nicht so ein großer Aufwand sein.

Gruß,
		Alex


-- 

Alexander Dubielczyk <Alexander.Dubielczyk at gmx.de>

Public PGP/GPG Key: http://www.rep-intern.de/keys/alexdu.gpg
Key fingerprint = 61BA 2C78 3503 B7ED 9B00 61DA D8D8 6C8F 3F2B 1302