Wie dumm ist die Welt? Oder sind wir es selbst?

[tiermutter]

Moin zusammen,

in unserem Umfeld (oftmals via Chat) werden oftmals ja ziemlich dumme "Verbrechen" bezüglich Sicherheit geteilt...

Im QNAP Forum gab es heute erst das Thema "Remotezugriff", für den offensichtlich doch (entgegen meinem bisherigen Verständnis) http und ssh Port für unbestimmte Zeit öffentlich zugänglich gemacht werden müssen:


Ein Nogo wie ich finde... ob das noch erforderlich ist, ist aber noch unklar...

Umso doller habe ich meinen Kopf geschüttelt, als ich folgenden Hinweis bei GMX las, als ich mich vergebens in einen alten Mailaccount einloggen wollte:


Jo, einfach mal alles im Browser speichern...

Stelle ich mich hier irgendwie an und es gibt gar keine Sicherheitsrisiken dadurch?

Welcher "Blödsinn" ist euch so zu Ohren gekommen?

 

[Barungar]

@tiermutter Ich lese das nicht so, dass die Ports öffentlich gemacht werden müssen. Ich lese das so, dass ich in meiner Firewall den Port 22 und 443 meines NAS für die Quell-IP 54.87.130.75 (helpdesk.qnap.com) freigeben soll. Vermutlich ist helpdesk.qnap.com ein Jump-Host von dem aus QNAP alle Supporte kooridiniert. Damit gebe ich perse erstmal nur einen Host im Internet frei... ist zwar immer noch eine Freigabem aber öffentlich würde ich die nicht nennen.

Ich höre bei "Sicherheitstipps" meisten reflexartig sofort weg, weil ich mir den Käse nicht anhören will.

 

[tiermutter]

Oh man... Wie einfach. Ich habe mir echt den Kopf darüber zerbrochen, was diese Adresse da zu suchen hat. Ich bin nicht auf die Idee gekommen, dass das die Quelle darstellen soll, auch nicht im englischen Text. Ja das macht das sehr viel geschmeidiger, auch wenn die Masse sicherlich nicht derart restriktiert, wenn es erforderlich wird.

 

[FSC830]

Jetzt bin ich aber auch am überlegen: ich halte den deutschen Text schon mal für falsch!
Wenn die Ports VON helpdesk.qnap.com auf sein müssen, muss QNAP das regeln .
Wenn die Ports FÜR helpdesk.qnap.com auf sein müssen, dann ist es meine Firewall, die ich einstellen muss.

Ich habe schon länger keine Fritz mehr, konnte man dort IP Bereiche vorgeben, die zugreifen dürfen!?

Gruss

 

[blurrrr]

Von -> Quelle -> eingehend, aber über die konkrete Formulierung lässt sich sicherlich streiten

Ich habe schon länger keine Fritz mehr, konnte man dort IP Bereiche vorgeben, die zugreifen dürfen!?

Nein, aber mit der NAS-Firewall geht das sicherlich (hoffe ich)

 

[FSC830]

Gibt aber nicht für jedes NAS (bzw. QTS) die Firewall. Dann bleibt nur klassisch die IP Security des NAS.
Aber alleine schon das öffnen der Ports auf dem Router ist für mich ein No-go. Zumal das tagelang so bleiben muss bis der Support irgendwann mal die Zeit und zugreift.
Die letzten Aufforderungen für den Zugriff habe ich mit Hinweis auf Sicherheitsbedenken abgelehnt und eine Teamviewer Session verwiesen.
Dann ging es sogar auch mal ohne Remotezugriff (das war das QuTScloud Lizenzthema).

Gruss

 

[Barungar]

Ich habe schon länger keine Fritz mehr, konnte man dort IP Bereiche vorgeben, die zugreifen dürfen!?

Nein, da ist die Fritz!Box in der Tat zu blöde für; da kann man sowas nicht einschränken. Aber idealer Weise sollte die Fritz!Box ja nicht die einzige Firewall sein. Die Fritz!Box ist sozusagen das Gartentörchen, danach kommt erst die richtige Firewall (sozusagen die "Haustür").

Nein, aber mit der NAS-Firewall geht das sicherlich (hoffe ich)

Ja, die QFirewall könnte das zum Beispiel.

 

[FSC830]

Ich denke bei > 90% der Fritzbox User kommt nach dem Gartentörchen direkt das Wohnzimmer und nicht noch die verschliessbare Haustür.
Es wäre schön, wenn es anders wäre, aber irgendwie sagt mir mein Bauchgefühl das es nicht so ist.

Gruss

 

[tiermutter]

nehmen wir das...

Aber idealer Weise sollte die Fritz!Box ja nicht die einzige Firewall sein

und das...

auch wenn die Masse sicherlich nicht derart restriktiert

... kommt da für die breite Masse doch wieder ein massives Sicherheitsproblem raus.

... QuFirewall? Na wenn es da mal nicht schon zu spät ist.

Offen bleibt trotzdem, ob das heute WIRKLICH noch erforderlich ist. Ich meine ich habe das von mindestens einem User anders erfahren, nämlich "QNAP NAS baut Verbindung zu QNAP Server auf und darüber läuft es dann wenn man in Taiwan Zeit hat".

 

[Barungar]

Ich habe nochmal den initialen Text von oben zitiert.

Offen bleibt trotzdem, ob das heute WIRKLICH noch erforderlich ist. Ich meine ich habe das von mindestens einem User anders erfahren, nämlich "QNAP NAS baut Verbindung zu QNAP Server auf und darüber läuft es dann wenn man in Taiwan Zeit hat".

Wenn ich mir das jetzt durchlese, wäre auch diese Variante denkbar. Dass der Verbindungsausbau also vom NAS aus ausgeht, demnach würde diese Anmerkung bedeuten, dass es dem NAS erlaubt sei muss aus seinem Netz (über eventuelle Firewalls hinweg) Verbindungen zu den Ports 22 und 443 von helpdesk.qnap.com öffnen zu dürfen. Ich hatte noch nie eine Fernwartung von/mir QNAP. Aber es wäre mal interessant zu wissen, ob nicht in der Tat, wenn man im Helpdesk Tool die notwendigen Einstellungen macht, die Verbindungen vom NAS ausgehend sind.

 

[tiermutter]

Verbindungen zu den Ports 22 und 443 von helpdesk.qnap.com öffnen zu dürfen

Also ausgehende Verbindungen entsprechend erlauben... das würde ja sämtliche Rahmen der Ottonormalverbraucher sprengen! Das mag ich echt direkt ausschließen.

Aber es wäre mal interessant zu wissen

Ja allerdings...
Und macht man dann v4, v6, oder beides? Also wenn solch eine Forderung Bestand haben soll, dann muss sie auch ordentlich definiert sein.
Ach, 22 und 443 UDP, oder doch ICMP?

 

[Barungar]

@tiermutter Ich denke nicht, dass das die Skills von Otto, dem Normalverbraucher, sprengen würde. Weil unser Otto hat seine Fritz!Box ausgepackt, eingesteckt und feiert seit dem, dass er online ist. Und in den Werkseinstellungen lässt die Fritz!Box, wie sicher auch 99% aller Consumer Router, alles raus. Was die Erklärung, wiederrum nur für diese Leute notwendig macht, die an Ihrer Firewall rumkonfiguriert haben, frei nach dem Motto: "Mein NAS braucht nicht mit dem Internet zu sprechen!!"

Ganz im Gegenteil macht diese Taktik, dass nämlich das NAS, nach dem Aktivieren des Remote Supports, eine Verbindung zum QNAP-Server helpdesk.qnap.com aufbaut, das Bild absolut rund. Andersfalls müssten sie nämlich allen Ottonormalverbrauchern der Welt erklären, wie diese Ports auf der kleinen, komischen Box neben dem Telefon-/Kabelanschluss freigeben, damit der Support sich auf dem NAS einloggen kann. So sagen sie nur: "Starten sie die Remote Unterstützung aus der Helpdesk App auf ihrem NAS." Da muss man sich nicht mit den ganzen SOHO-Routern rumschlagen.

Wir werden es so schnell nicht erfahren, weil Otto, der QNAP auf sein NAS lässt, wird sicher nicht wissen was ein tcpdump ist oder wie netstat arbeitet.

 

[Tommes]

Vielleicht steckt dahinter ja die gleiche Technologie, welche Synology für QuickConnect nutzt. Synology beschreibt QuickConnect so...

Zitat aus der Online DSM-Hilfe (DSM 6.2)...

QuickConnect ermöglicht Client-Anwendungen, über das Internet eine Verbindung mit Ihrem Synology NAS herzustellen, ohne dass Sie Portweiterleitungsregeln einstellen müssen.

In dem dazugehörigen White Paper ist dabei von "hole punching" die Rede...

Zitat aus dem White Paper zu QickConnect...

QuickConnect Hole Punching
If no direct connection can be established, the client will attempt to establish a virtual tunnel between the client and the NAS via QuickConnect to allow a temporary direct link for data transmission. This technology allows the server and the client to experience Internet synchronization performance very similar to connecting via WAN IP/DDNS without physically having such an environment.

Hole punching works by initiating a virtual tunnel from the client to the NAS with the aid of the QuickConnect Server.

1. The NAS sends out a request to the QuickConnect Server, and keeps the hole, a random external port punched by the request on the NAT in front of the NAS, open to receive a hole punching request.
2. Similarly, the client sends out a request to the QuickConnect Server to create another hole on the NAT in front of the client.
3. The QuickConnect Server will deliver the hole information of the NAS to the client and vice versa.
4. The NAS will try to establish a connection to the client through the punched hole on the client side.
5. Once the client receives the hole punching request from the NAS, a hole punching response is sent back to the NAS via the punched hole on the NAS side.
6. If the hole punching response arrives at the NAS, a virtual tunnel is successfully created.

 

[Barungar]

@Tommes Ja, in diese Richtung könnte es gehen... Das Prinzip in beiden Fällen ist es den Verbindungsaufbau zum NAS zu verlagern, da wie gesagt 99% aller SOHO-Router Verbindungen von innen nach außen immer erlauben.

 

[Mavalok2]

Ich denke auch, dass hier die Verbindung von Innen nach Außen geht. Habe dies vor Jahren mal in der Firma versucht. Da konnte die App keine Verbindung aufbauen, klar ist in der Firma alles gesperrt. Nicht dass ich vor hatte, hier fremde Leute auf den Firmensystemen herumtanzen zu lassen. Würde mir nie in den Sinn kommen jemanden nicht überwacht auf die Systeme zu lassen. Wollte einfach wissen, ob meine Richtlinien so etwas auch abdichten.

 

[blurrrr]

Naja, bei allem was raus geht, ist i.d.R. auch eine eingehende Antwort erlaubt und genau das ist der Knackpunkt bei der von Synology beschriebenen hole-"pushing"-Methode. Das hat auch nix mehr mit uPnP und derlei zu tun und flitzt somit durch jeden SOHO-Router. Dafür läuft die initiale Verbindung aber auch über den Hersteller. Oftmals wird danach versucht eine eigene (direkte) Verbindung zwischen Gerät und Client zu etablieren, schlägt das aber fehl, wird dann einfach weiter über den Hersteller abgewickelt.

Hat noch keiner von euch QNAP-Usern mal die Pakete auf dem NAS diesbezüglich mitgeschnitten? Falls nicht, müsste man ja jetzt wieder @tiermutter ranziehen (hat da schon gut Erfahrung drin ). Mitschneiden, aktivieren, ein paar Sekunden warten, wieder deaktvieren, Mitschnitt stoppen. Alternativ einfach via Portmirror via Switch am lokalen Rechner mitschneiden (und ggf. auch direkt auf die NAS-IP filtern). Dann weiss man jedenfalls was Sache ist. Alternativ stellt QNAP da ggf. auch ein Support-Dokument zur Verfügung (keine Ahnung), wo der Kommunikationsaufbau beschrieben ist. Die Dinger werden ja mitunter auch in größeren Firmen eingesetzt und da sind die Netzwerkstrukturen nicht mehr mit denen, von Privatleuten zu vergleichen (und die Kisten kommen normalerweise "so" eh nicht raus).

 

[tiermutter]

Afaik kann man das so einfach nicht starten, das geht glaube ich nur mit einer entsprechenden ID die man bei Bedarf im Ticket mitgeteilt bekommt... Kann ich mir aber nochmal genauer anschauen.

 

[Confluencer]

Hach das gute alte Port-Punching bzw STUN. Im Grunde ist es ein Highjacken von NAT Sessions mit Hilfe eines Reflektor-Servers der dem jeweils anderen Client die Destination IP: PORT das Gegenüber unterjubelt, die es für die Antwortpakete der NAT Session erwartet, um sie dann an das richtige Ziel im LAN weiter zu verteilen.

Das ursprünglich Skype hat das schon im Jahr 2003 gemacht. Es war bei Admins nicht sonderlich beliebt, da gut angebunden Firmenrechnern oft unfreiwillig zu Supernodes wurde, die quasi das Rückrat von Skype gebildet haben. Deren eigene Infrastruktur bestand damals nur aus den Bootstrapping-Servern, die einem Client die nächsten Supernodes bekannt gegeben hat, sofern es (noch) keine gültigen kannte, damit er den Einstieg in das Peer2Peer-Netz findet und dann Teil dessen werden konnte.

Würde mich wundern, wenn Teamviewer kein STUN verwenden würde.

 

[EOL60]

Das ist ein uebliches Verfahren. Von draussen komt man nicht rein - aber von innen baut man eine Connection auf und die andere Seite kann dann ganz einfach antworten. Das wird u.A. auch gerne bei Ueberwachunskameras genutzt. Die HandyApp connected sich zum Server mit einer UUID, der sucht seine existierende Connection zu der UUID (die Kamera hat sich damit angemeldet) und kann somit zeigen was die Kamera sieht. Alles ganz ohne irgendwelche Port- oder UPnP Freigaben.