Fangen wir erst mal mit dem inhaltlichen an:
Benno-007 schrieb:
Zu deinem letzten Posting:
Das lass ich daher mal lieber so, um ein neues/ das richtige PW vergeben zu lassen. Desweiteren ist diese Abfrage ja nicht garantiert, sowas kann sich auch mal ändern.
Ok, da kann ich nichts dagegen sagen. Problem Kann man natürlich nie 100% ausschließen - auch wenn ich das praktisch so noch nicht hatte.
Mir ging es halt darum, dass jeder Schritt, den man sich zum Aufbau der Verbindung sparen kann, mehr oder weniger gewonnene Zeit sein kann. Es kann aber auch so bleiben wie es ist.
Zu Reverse oder nicht Reverse:
VNC läuft überhaupt nicht unabhängig parallel von SSH. Wie in der Überschrift steht, läuft VNC ÜBER SSH. Es braucht also weder einen offenen Port für VNC noch ein Passwort. Es läuft sowieso alles über SSH. Das das nur zusätzliche Sicherheit sein soll, hab ich auch so geschrieben.
Ja gut... und wo besteht da der Unterschied zur Reverse-Variante? Die läuft auch über SSH. Und wenn der Viewer auf der Helfer-Seite beendet wird, geht in Regel der SSH-Tunnel zu und der VNC-Server auf Fremdrechner auch.
Ich will dabei genauso wenig wie Du ausschließen, dass der VNC-Server in Fehlerfällen mal noch ohne den Tunnel weiter läuft. Und dann hilft das Passwort bei der Reverse-Variante genaus gut oder schlecht, wie bei der normalen Variante.
Du hattest der Reverse-Variante weiter vorne vorgeworfen, dass bei Ihr der VNC-Server - der bei der normalen Variante genauso auf dem Fremdrechner läuft - ein besonderes Problem sei.
Und diesen Teil verstehe ich nicht - auch nicht nach Deinen Erklärungen jetzt.
Kurz: VNC wird über SSH getunnelt!
Bei Reverse wird doch genauso getunnelt.
Wenn du danach gehst, müsstest du auch im Wiki überall warnen: SSH, Portweiterleitung oder so.
Das Wiki liest im besten Fall der Helfer aber nicht der Hilfesuchende. Zumindest steht in Deinem HowTo nichts, dass man den Hilfesuchenden erst mal zur Lektüre ins Wiki schicken solle, bevor man irgendwo in dessen Netz herum konfiguriert.
Ein HowTo setzt die Einstiegshürde in die Materie noch mal weiter herab. Die Vorgehensweise ist ja im Prinzip jetzt schon aus dem Wiki herauszulesen - nicht aber unbedingt für Jedermann. Mit dem HowTo machst Du es möglich, dass Leute, die es sich bisher nicht aus dem Wiki ableiten konnten, einfach die vorgegebene Methode benutzen.
Und ich habe nach wie vor Bauchschmerzen, wenn ein Halb-Wissender einem Unwissenden an dessen Router herum konfiguriert und dann auch noch die eingerichtete Portweiterleitung aus Bequemlichkeit drin lässt.
Ob der dann Deiner Warnung in der Achtungbox genug Beachtung schenkt und dazu überhaupt in der Lage ist, steht dann auch noch nicht fest.
Ja, natürlich, man kann zwar auch ohne Dein HowTo nicht ausschließen, dass Halb-Wissende bei Unwissenden irgendwie herum pfuschen, aber Dein HowTo erweitert eben den Kreis diesbezüglich.
Aber die Gefahren sind für den Helfer in aller Regel viel besser zu beherrschen, als für den Hilfesuchenden.
Nein, siehe oben. Nun sind zwei verwundbar statt einer.
Die Gefahr ist nicht automatisch dadurch höher, dass zwei statt einer verwundbar sind. Sondern es kommt darauf an, wie die konkrete Gefahr ausgeht und wer sie wie beherrschen kann.
Anmerkung - von oben hier her kopiert:
Mit welcher Methode willst du denn als Helfer deinen PC absichern?
Kein Standard SSH-Port (kostet den Angreifer bisschen Zeit)
Eigene virtuelle Maschine für Fernhilfe, die per Snapshot gesichert ist und bei der der Snapshot nach Hilfs-Sitzung zurück gespielt wird. Die virtuelle Maschine läuft nur zum Zweck des Supports und nicht dauerhaft.
Wenn es die eigenen Gegebenheiten erlauben, steht diese VM in einem eigenen VLAN.
Kein Root-Login für SSH, nur die Gruppe ssh darf sich per SSH anmelden, Mitglieder der Gruppe ssh sind ausschließlich eingeschränkte Nutzer. Grad der Einschränkung ist dabei Geschmackssache.
Extrem lange und sichere Passwörter vor und nach dem Login des SSH-Nutzers. Während der Login-Dauer aus Gründen der Praktikabilität vorübergehend kürzeres aber immer noch komplexes Passwort. Man könnte jetzt noch, wenn man wollte, das Passwort für den SSH Nutzer in beliebigen Intervall ständig wechseln lassen per Skript.
Browsing-Funktionen und Netzwerkfunktionen im lokalen Netz für den Hilfsrechner weitest gehend einschränken.
...
Damit wird ein Angriff zwar nicht unmöglich, aber IMO hinsichtlich des Anwendungszweck schon so weit wie unmöglich oder zumindest sehr schwer. Ja, es gibt noch die Möglichkeit des Passwort-Glückstreffers, aber dann ist der Angreifer aber immer erst mal noch als eingeschränkter Nutzer im System.
Und das Lesen von Systemdateien wirst du nicht so einfach verhindern können.
Und was hat der Angreifer davon, wenn er die System-Dateien von einem System lesen kann, was keinerlei besonderen Informationen enthält? Gut er kann im Zweifel vielleicht Einblick erhalten, wie das System genau sicherheitstechnisch abgesichert ist, davon hat er aber die betreffenden Maßnahmen noch nicht umgangen.
Das hat also nichts mit Können zu tun, sondern dass lokaler Zugang nun mal immer nur mit einem gewissen Aufwand absicherbar ist.
Ich habe auch nirgendwo behauptet, dass das kein Mehraufwand bedeutet.
Und das ist dann nicht mehr einfach und mal eben schnell, also für Wiki/ Howto eher problematisch.
Man muss die Materie auch nicht unbedingt in einem HowTo behandeln - ich meine das jetzt insbesondere in Bezug auf die Fernhilfe. Was man im eigenen Veranwortungsbereich anstellt, bleibt einem selbst überlassen und kann auch nicht verhindert werden.
Und ein NAS läuft üblicherweise länger durch. Nicht immer, aber dann muss man sich informieren, was "ein Internet" ist. Ein Router war noch nie ein Sicherheitsmerkmal, das wurde nur immer großspurig so verkauft. Er hat auch nicht die Aufgabe, eine Firewall bezüglich offener Ports zu sein - auch wenn er vielleicht extra eine Firewall als solche integrieren kann.
Haben die meisten Router heute eine Firewall integriert, die zumindest hinsichtlich des schließen von Ports, so dass auf diese nicht einfach von außen zugegriffen werden kann auch ausreichend funktioniert.
Zwar hast Du Recht, dass das nicht besser ist, als Dienste hinter dem Router entweder gar nicht erst laufen zu lassen oder diese sicher zu konfigurieren, nur ändert das nichts daran, dass Du etwaig laufende Dienste oder falsch konfigurierte Dienste leichter unter Beschuss stellst, wenn Ports am Router geöffnet werden.
Und Punkt 2 ist dabei insbesondere ein Problem, weil das betreffende Netzwerk in den allermeisten Fällen nicht unter der Verantwortung und dem ständigen Zugriff des Helfers läuft. Oder müssen Freunde und Bekannte bei Dir jede Inbetriebnahme und Änderung an ihrem System von Dir als Helfer absegnen lassen? Und das bei Unwissenden sicherheitstechnisch nicht alles optimal konfiguriert ist, davon kann man heute schon fast mit Sicherheit ausgehen.
Wir erinnern uns bitte darin, dass das Prinzip der geschlossenen Ports - zu Recht - eine wesentliche Sicherheitsmaßgabe ist.
Eben. Ich hab keinen Router, prasselt alles auf mein Ubuntu ein und von dort wieder ab.
Dein bzw. Helfer Problem! Das nicht zu beherrschen rechtfertigt nicht das Abwälzen der Risiken auf den Hilfesuchenden, der es definitiv noch weniger beherrscht.
Es ist auch niemand zur Remote-Hilfe gezwungen. Im übrigen kannst Du persönlich es selbstverständlich auch damit halten und eine Einstellung dazu haben, wie Du willst. Problematisch wird es IMO aber da, wo man diese Einstellung als Quasi-Standard unter die Leute bringt.
Und die Einstellung, dass der Hilfesuchende das Risiko tragen soll, weil der Helfer nicht dazu bereit ist und das damit begründet, er leiste dafür ja umsonst Hilfe, finde ich als allgemeingültige Regel sehr fragwürdig.
Und um es noch mal deutlich zu machen: Meine Anmerkungen und beschriebenen Vorgehensweisen beziehen sich ausschließlich auf die Fernhilfe. Bei Zugriff von Außen auf den eigenen Herrschaftsbereich, kann und sollte man ruhig so vorgehen, wie von Dir beschrieben.
IMO sind das zwei Paar Schuhe.
Gruß,
Martin