Moien
Das Berliner Amtsgericht hat eine … interessante Auslegung des Datenschutzes gefunden ( http://www.heise.de/newsticker/meldung/96781 ). Kurzfassung: Als Serverbetreiber darf man die IP eines Users nicht mehr mitloggen.
Wie genau soll ich nun Vollt***el die brute-force meinen ssh-Zugang beackern abwehren ? Für einen Tag die IP wegfiltern darf ich ja nicht mehr. Die Routingtabelle könnte ja als Log aufgefasst werden…
Und eine Musterklageschrift haben die Jungs auch online. Nett.
cu
Hi,
Das Berliner Amtsgericht hat eine … interessante Auslegung
des Datenschutzes gefunden (
http://www.heise.de/newsticker/meldung/96781 ). Kurzfassung:
Als Serverbetreiber darf man die IP eines Users nicht mehr
mitloggen.
nein, als Behörde … wer (außer heise) sagt, daß Dich das betrifft?
Hat eventuell mal Jemand einen Link zu einem Datenschutzgesetz, das sich nicht ausschließlich auf Behörden bezieht? Habe ich nämlich noch nicht gesehen, würde ich aber gern mal.
Gruß, Rainer
Hy,
Hmm, soll das nun ne Sammelklage gegen wer-weiss-was werden? Zum Glück ist gerade unser Freiherr ja gerade hinter Gittern… aber es gibt ja leider sooo viele Trittbrettfahrer…
Das heisst also das unser Überwachungsstaat alla 1984 sich nun selbst ins Knie geschossen hat? Lustig.
gruß
h.
P.S.: das heisst ich brauche wieder meine ach so gefährlichen Hackertools alla TCPDump & Co um das verhindern zu können wieder? huch…
Moien
wer (außer heise) sagt, daß Dich das betrifft?
Es geht den Leuten um das TMG §15, Absätze 1 und 4. Betroffen sind laut TMG §2 Ansatz 1:
ist Diensteanbieter jede natürliche oder juristische Person, die eigene oder fremde Telemedien zur Nutzung bereithält oder den Zugang zur Nutzung vermittelt
Oder anders ausdrückt: jeder Serverbetreiber in Deutschland.
Hat eventuell mal Jemand einen Link zu einem
Datenschutzgesetz, das sich nicht ausschließlich auf Behörden
bezieht?
Es ging nie um Behören, es ging immer ums TMG: http://bundesrecht.juris.de/tmg/index.html
Habe ich nämlich noch nicht gesehen, würde ich aber
gern mal.
Warrnung, trocken.
cu
Moien
Hmm, soll das nun ne Sammelklage gegen wer-weiss-was werden?
Think bigger: google.de ? Mircosoft.de ? WGA ?
Das heisst also das unser Überwachungsstaat alla 1984 sich nun
selbst ins Knie geschossen hat? Lustig.
Wenn man keine IPs aufzeichen darf werden u.a. User von Downloadseiten a la rapidshare unangreifbar. Das Urteil hat richtig Sprengkraft. Und das Landsgericht hat es auch schon durchgewunken: http://www.telemedicus.info/urteile/Allgemeines-Pers…
Kann man jemand die nachfolgenden Instanzen drchchecken ? Ich weiss nicht wie man die durchsucht…
P.S.: das heisst ich brauche wieder meine ach so gefährlichen
Hackertools alla TCPDump & Co um das verhindern zu können
wieder?
Solange sie die IP nicht speichern …
cu
Hi,
wer (außer heise) sagt, daß Dich das betrifft?
Es geht den Leuten um das TMG §15, Absätze 1 und 4. Betroffen
sind laut TMG §2 Ansatz 1:
ist Diensteanbieter jede natürliche oder juristische
Person, die eigene oder fremde Telemedien zur Nutzung
bereithält oder den Zugang zur Nutzung vermitteltOder anders ausdrückt: jeder Serverbetreiber in Deutschland.
OK.
Hat eventuell mal Jemand einen Link zu einem
Datenschutzgesetz, das sich nicht ausschließlich auf Behörden
bezieht?Es ging nie um Behören, es ging immer ums TMG:
http://bundesrecht.juris.de/tmg/index.html
Danke!
Habe ich nämlich noch nicht gesehen, würde ich aber
gern mal.Warrnung, trocken.
Das macht nichts, ich lese so etwas gern. 
Ich mache mir lieber mein eigenes Bild, als Interpretationen zu lesen.
… Ja, Du hast Recht, das sieht nicht hübsch aus. Ich habe bisher immer mit ‚Datenschutz‘ danach gesucht und nicht gefunden …
Gruß, Rainer
Hi,
P.S.: das heisst ich brauche wieder meine ach so gefährlichen
Hackertools alla TCPDump & Co um das verhindern zu können
wieder?Solange sie die IP nicht speichern …
Auch ein normaler Webserver ohne Logging speichert die IP-Adresse (im RAM).
Aber: SSH ist sicher kein Telemedium, insofern darfst Du selbstmurmelnd weiterhin mit Blacklists blocken. Das Telemedien bewegen sich ausschliesslich auf den Layern 5-7, alles darunter ist technisch gesehen von dem Urteil überhaupt nicht betroffen.
Gruß,
Malte
Mulibwanji,
Wie genau soll ich nun Vollt***el die brute-force meinen
ssh-Zugang beackern abwehren ?
Indem Du die brute-force-anfällige Passwortmethode zugunsten von RSA keys
einfach ganz abschaltest. Dann brauchst Du Dir keine Sorgen mehr machen und
kannst auf das Logging verzichten.
Gruß
Fritze
Hallo.
Kurzfassung:
Als Serverbetreiber darf man die IP eines Users nicht mehr
mitloggen.
Als Vergleich: http://www.Dr-Bahr.com/news_det_20071001132413.html
„(…)Zum einen ist es das erste und einzige Urteil, das in diesem Umfang die IP-Speicherung verbietet. (…)“
mfg M.L.
Indem Du die brute-force-anfällige Passwortmethode zugunsten
von RSA keys
einfach ganz abschaltest. Dann brauchst Du Dir keine Sorgen
mehr machen und
kannst auf das Logging verzichten.
Soso! Und wie machst du das auf einer Uni, wo die Leute sich über ssh einloggen können? Und lässt dich das kalt, wenn zig Versuche von einer IP von Taiwan kommen? Und was, wenn systematisch nach Schwachstellen am SSH-Server selbst gesucht wird? Oder was machst du, wenn plötzlich tausende SYN-Pakete auf Port 22 kommen?
Antwort: Rate-Limiting kann einige Probleme ein wenig bis sehr gut abschwächen!
mfg.
Hi,
P.S.: das heisst ich brauche wieder meine ach so gefährlichen
Hackertools alla TCPDump & Co um das verhindern zu können
wieder?Solange sie die IP nicht speichern …
Auch ein normaler Webserver ohne Logging speichert die
IP-Adresse (im RAM).
Das war mir schon klar. Nur TCPdump & Co verstossen (falls das Bestand hat) nur inzwischen gegen 2 Gesetze. Das wird so langsam sehr seltsam.
Aber: SSH ist sicher kein Telemedium, insofern darfst Du
selbstmurmelnd weiterhin mit Blacklists blocken.Das
Telemedien bewegen sich ausschliesslich auf den Layern 5-7,
alles darunter ist technisch gesehen von dem Urteil überhaupt
nicht betroffen.
uhm… Aber SSH ist doch in der TCP-Anwendungsschicht (entspricht 5-7 OSI/ISO) ? SSL sollte teifer liegen, aber damit hab ich kein Problem.
http://de.wikipedia.org/wiki/Transportprotokoll#Anwe…
cu
Moien
Indem Du die brute-force-anfällige Passwortmethode zugunsten
von RSA keys einfach ganz abschaltest.
Dann müsste ich meine RSA-Keys per USB-Stick mitnehmen und unterwegs in Internetcafes auslesen lassen. Auf gar keinen Fall. Ich werde nicht einem Fremden meine RSA-Keys geben.
Login und Passwort ist kein Problem, der Server akzeptiert jedes Passwort eh nur 1x.
cu
Hallo,
Soso! Und wie machst du das auf einer Uni, wo die Leute sich
über ssh einloggen können?
Die Frage verstehe ich nicht. Jeder User verwaltet seine eigenen
Schlüssel (unter /home//.ssh). Er muss sich zum Generieren der
Schlüssel einmalig lokal anmelden. Das ist kein Problem.
Und lässt dich das kalt, wenn zig Versuche von einer IP von Taiwan
kommen?
Ja.
Und was, wenn systematisch nach Schwachstellen am SSH-Server
selbst gesucht wird?
Dagegen ist ohnehin kein Kraut gewachsen. Es hilft, SSH/SSL Pakete
aktuell zu halten und eine sinnvolle (restriktive) Konfiguration z.B.
das deaktivieren von SSL v1
Oder was machst du, wenn plötzlich tausende SYN-Pakete
auf Port 22 kommen?
Ich nutze SYN cookies.
Gruß
Fritze
Mulibwanji
Dann müsste ich meine RSA-Keys per USB-Stick mitnehmen und
unterwegs in Internetcafes auslesen lassen. Auf gar keinen
Fall. Ich werde nicht einem Fremden meine RSA-Keys geben.
Aber Dein Passwort, oder was? Ich arbeite nicht von Internetcafes
aus, aber wenn ich es täte, fände ich die RSA-Key Methode keinesfalls
unsicherer, als die Passwortmethode.
Login und Passwort ist kein Problem, der Server akzeptiert
jedes Passwort eh nur 1x.
Dann kannst Du auch neue Schlüssel generieren lassen. Wo ist das
Problem? Nach wie vor sind Passworte (auch wenn sie nur 1x gelten)
erheblich leichter zu knacken, als RSA Schlüssel.
Gruß
Fritze
Aber: SSH ist sicher kein Telemedium, insofern darfst Du
selbstmurmelnd weiterhin mit Blacklists blocken.Das
Telemedien bewegen sich ausschliesslich auf den Layern 5-7,
alles darunter ist technisch gesehen von dem Urteil überhaupt
nicht betroffen.uhm… Aber SSH ist doch in der TCP-Anwendungsschicht
(entspricht 5-7 OSI/ISO) ? SSL sollte teifer liegen, aber
damit hab ich kein Problem.
Wenn ein Paketfilter die Zahl der Verbindungsversuche auf TCP/22 misst und ggf. IPs ab einem bestimmten Maß aussperrt, dann bewegt er sich bestenfalls auf Layer 4 (ISO/OSI). SSH ist ohnehin kein Telemedium, weshalb der Layer dabei sogar egal ist.
Das ist zumindest meine technische Auffassung, ob ein Richter das evtl. anders sieht…
Gruß,
Malte
Moien
Login und Passwort ist kein Problem, der Server akzeptiert
jedes Passwort eh nur 1x.Dann kannst Du auch neue Schlüssel generieren lassen.
Der Server hat eine Liste von mindestens 250 Passwörter und stell nach jedem Login automatisch auf das nächste um. Ich könnte völlig gefahrlos meine letzten 50 Passwörter, Loginnamen und die IP offen legen. Aber wenn ich den RSA-Schlüssel neu generieren lasse müsste ich den neuen Schüssel auch wieder transferieren (Oder glaubst du ich latsch nach jedem Login ins RZ und bespiel den Stick neu ?). Die Schlüssel auf Vorrat anlegen ist auch so eine Sache: man kann die bei laufendem Server nicht austauschen. D.h. alle eingelogten Leute würden rausfliegen wenn einer aus logt. Das würde im Moment 15 Leute treffen.
Dann kommt der nächst Scherz: eines meiner Terminals (Palm PDA) kann nicht per RSA-Key einlogen. Laut Anleitung geht es, aber der Schlüssel kommt nie korrekt an.
cu
Mulibwanji
Die Schlüssel auf Vorrat anlegen ist auch so eine Sache:
man kann die bei laufendem Server nicht austauschen.
D.h. alle eingelogten Leute würden rausfliegen wenn
einer aus logt. Das würde im Moment 15 Leute treffen.
Wie kommst Du denn darauf? Die Schlüssel sind für jeden User
individuell angefertigt (wie sollte das auch sonst gehen) und können
selbstversändlich jederzeit ausgetauscht werden, ohne das es den
Betrieb anderer User stören würde. Von „rausfliegen“ kann keine Rede
sein. Es ist auch kein Problem, mehrere Schlüssel „auf Vorrat“ zu
generieren und entsprechend zu hinterlegen. Man kann auch das Löschen
eines Schlüssels nach einmaliger Nutzung durchführen.
Dann kommt der nächst Scherz: eines meiner Terminals (Palm
PDA) kann nicht per RSA-Key einlogen. Laut Anleitung geht es,
aber der Schlüssel kommt nie korrekt an.
Das ist ein Bug Deiner Software und kein prinzipbedingtes Problem bei
der Nutzung von RSA Schlüsseln.
Aber Du gehst ein wenig an der Praxis vorbei. Kaum jemand wird
ernsthaft über einen öffentlichen PC seine Server administrieren oder
sich auf dem heimischen Rechner einloggen. Dafür hat man ein Notebook
oder sonst ein eigenes Gerät mit WLAN Fähigkeit. Dann ist die RSA-Key
Methode in öffentlichen Plätzen besonders geeignet, da einem niemand
beim Eintippen des Passwortes über die Schulter gucken kann.
Gruß
Fritze
Wie früher auch
Aus der Begründung:
Als Entscheidungsgrundlage führten die Richter vor allem
das Telemediengesetz (TMG) an. Laut der seit März geltenden
Regelung dürfen Betreiber von Internetdiensten keine personenbezogenen
Daten auf Vorrat speichern. Dazu gehört insbesondere die
Aufzeichnung des Nutzungsverhaltens mitsamt IP-Adresse oder
Login-Namen. Herangezogen werden dürfen die Daten allein für
temporäre Abwicklungszwecke wie eine Abrechnung.
Sorry, aber ich würde ein Mitloggen für einen begrenzten Zeitraum (sagen wir mal: 24 Stunden, danach dürften Angreifer eh eine neue IP haben) zum Schutze vor Brute-Force-Attacken durchaus als „temporären Abwicklungszweck“ bezeichnen. Und diese Auffassung im Ernstfall auch vor Gericht vertreten.
Aber erst mal gilt: Wo klein Kläger, da kein Richter.
Du loggst ja auch zunächst mal keine personenbezogenen Daten oder Nutzerverhalten, sondern nur Einlog-Versuche, und das hauptsächlich von Unerwünschten.
Diese Regelung würde ich erstmal ignorieren.
Wie genau soll ich nun Vollt***el die brute-force meinen
ssh-Zugang beackern abwehren ? Für einen Tag die IP wegfiltern
darf ich ja nicht mehr. Die Routingtabelle könnte ja als Log
aufgefasst werden…
So wie bisher auch. Bei dem Urteil ging es um die Sammlung von IP-Adressen, die beim Zugriff auf einen öffentlich angebotenen Webserver mitprotokolliert werden. Sofern du deinen ssh-Zugang nicht öffentlich als Dienstleistung auspreist, handelt es sich um zwei qualitativ völlig unterschiedliche Dinge.
Ein Gericht verpflichtet einen Taxifahrer, auch Schwarze zu befördern. Siehst du dich als Auto-Normalfahrbraucher zukünftig verpflichtet, jeden Anhalter mitzunehmen, sofern er Schwarz ist?
Gruss
Schorsch
Moien
So wie bisher auch. Bei dem Urteil ging es um die Sammlung von
IP-Adressen, die beim Zugriff auf einen öffentlich angebotenen
Webserver mitprotokolliert werden. Sofern du deinen ssh-Zugang
nicht öffentlich als Dienstleistung auspreist
Ich start nethack auf dem Server und lass Leute spielen? Oder der Server stell eine Verwaltungskonsole für virtuelle www-Server zur Verfügung?
Das TMG macht da verflucht wenig Unterschiede.
cu