Martin Uecker <[EMAIL PROTECTED]> writes: >> Mir ist ein offenes Netz mit geregeltem Monitoring lieber als ein >> geschlossenes ohne. > > Warum sollte sich das ausschlie�en?
Hast Du irgendeine Idee, wie man ein offenes Netz (d.h. keine Reglementierung der Endger�te, jeder kann alles senden, einschlie�lich der Kennung des Nachbarn) anderweitig in den Griff bekommt? Entweder man kann den Mi�brauch im voraus verhindern (das widerspricht den Charakter der Offenheit), oder man steuert im Nachhinein gegen, wenn etwas aus dem Ruder gelaufen ist (das braucht irgendwelche Aufzeichnungen, insbesondere wenn man vor der Sperre des Kunden noch mal einen Menschen dr�berschauen lassen will). > Die meisten Admins scheinen mir kaum Probleme damit zu haben, > alles m�gliche zu loggen, wenn es ihnen bei der Arbeit hilft. Die meisten Logs werden nie angeschaut. Typische Server-Software (Apache, Exim, INN), loggt einfach ziemlich viel, wenn sie aus der Schachtel f�llt, unabh�ngig vom wirklichen Bedarf. Die Leute, die die Logs wirklich brauchen, k�nnen auch recht genau beschreiben, was sie haben wollen �ber welchen Zeitraum, und dann kann man sich auch schnell auf einen vern�nftigen Rahmen einigen. (Insbesondere wenn man ihnen die Skripte f�r die Anonymisierung schreibt -- Datenreduzierung ist h�ufig einfach zus�tzlicher Aufwand mit sehr niedriger Priorit�t.) Unangenehm sind nur diejenigen, die die Logs praktisch niemals nutzen und folglich auch nicht wissen k�nnen, was wirklich drinsteht und ob es �berhaupt bei der Arbeit hilft. Sie neigen dazu, den Logs eine magische Macht �ber Fehler (und Nutzer?) zuzuschreiben und behaupten steif und fest, da� sie die Daten in nicht anonymisierter Form �ber sehr lange Zeitr�ume aufbewahren m�ssen. > Kann ich irgendwie auch nachvollziehen. Kann ich �brigens auch > bei der Polizei. Nur in beiden F�llen wird das �berwachen nicht > mehr als notwendiges �bel angesehen, sondern ist zum selbst- > verst�ndlichen Hilfsmittel geworden, dessen Minimierung > �berhaupt nicht mehr angestrebt wird. Es gibt schon einen gewissen Unterschied: Bei polizeilichen �berwachungsma�nahmen habe ich erst einmal eine Person, gegen die sich die Ma�nahme richtet. Bei Flow-Daten sind die Personen dahinter erstmal v�llig uninteressant. Man mu� zwar leider einen Menschen bitten, das Problem abzustellen, aber ob der der Verantwortliche ist oder nur zuf�llig jemand, der das Problem irgendwie aus der Welt schafft, ist an der Stelle v�llig egal. Anders wird es, wenn man wirklich Nutzungsrichtlinien durchsetzen will, z.B. in Unternehmen und Beh�rden. Dann wird es sicherlich unangenehm, aber datenschutzrechtlich wegen des Innenverh�ltnisses eher unbedenklich. 8-) >> > Genausowenig wie der Terror eines Osama bin Laden >> > rechtfertigen auch regelm��ige DoS-Angriffe nicht die >> > vollst�ndige �berwachung aller Kommunikation in diesem >> > Staat. >> >> Es geht nicht um DoS, sondern darum, da� ziemliche viele Menschen ihre >> privaten Daten per Wurm ins Netz blasen. Diese Menschen brauchen >> Hilfe. > > Dazu mu� man nicht jeden Flow aufzeichnen. Das �ndert �berhaupt nichts an der Bewertung der Flow-Daten. HTTP-Traffic f�r typische Web-Angebote (mit vielen kleinen Bildchen) besteht immer noch aus so vielen Flows, da� die IP-Adressen der angesteurten Server auch dann noch mit sehr hoher Wahrscheinlichkeit auftauchen, selbst wenn man nur einen kleinen Teil der Flows speichert. Falls das Sampling vor der Flow-Erzeugung geschieht (vgl. Sampled Netflow von Cisco) sieht das vielleicht anders aus, -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, netscape.net, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
