Cloud Station attacken wenn QC läuft?

[ottosykora]

auf einer alten, nicht produktiven Test DS
hatte ich heute einige Attacken 'auf CardDav' von weit weg, na ja das übliche, nach Autoblock hat es gleich gesperrt.

Nur: die DS steht in einem wahrscheinlich ziemlich gut gesperrtem Netz und hat keinen Zugang von aussen. Also wie gut gesperrt weiss ich nicht, aber es wird wird von Cisco betrieben und gewartet und besteht aus vielen Cisco Bauteilen. Es sind viele DS dort in Betrieb nebst anderen Servern.
Bei dieser ist nur etwas anders, ich experimentieren seit eingen Tagen mit Drive und dem ganzen Brimborium was dazu gehört, also Clients auf PC , Phone.
Damit die Clients funktionieren, musste ich also QC an dieser DS aufschalten, DDNS geht da nicht, ist nicht für normalos von aussen erreichbar.
Und obwohl ich die Drive Versuche innerhalb des Netzes gerne machen würde, geht dies nicht weil die Clients von Drive nur Domain und QC verwenden können, jedoch keine IP.

Drive Client ist online sobald ich den PC einschalte.
Wie was genau der Client auf Phone (Android) macht weiss ich nicht.

Jedenfalls gab es in der Nacht zwei versuchte Angriffe auf die DS. Zu der einen Zeit war der PC noch an, zu der anderen Zeit aus.

Ist es wirklich so dass jemand eine stehende QC Verbindung irgendwie verwenden kann und somit in das Netz bis an die DS kommt?

 

[blurrrr]

Sorry, aber "Nur: die DS steht in einem wahrscheinlich ziemlich gut gesperrtem Netz und hat keinen Zugang von aussen" ist irgendwie ... "wahrscheinlich" eher "geht so" und "Also wie gut gesperrt weiss ich nicht, aber es wird wird von Cisco betrieben und gewartet und besteht aus vielen Cisco Bauteilen.", also kann die CIA/NSA/FBI/etc schon mal mitlesen. Ausserdem wüsste ich nicht, dass Cisco auch Colocation/Serverhousing anbietet... Ich denke, ich irre, oder Du irrst, was das von "Cisco betrieben" angeht - lasse mich aber gern vom Gegenteil überzeugen

"Damit die Clients funktionieren, musste ich also QC an dieser DS aufschalten, DDNS geht da nicht, ist nicht für normalos von aussen erreichbar." - wenn es so "sicher" ist, nichts entsprechendes angelegt wurde, dürfte die DS dann auch "garnicht" raus. Weder so, noch so. Via Colocation/Housing solltest Du aber schon die Möglichkeit haben uneingeschränkt auf Dein Gerät zugreifen zu können. Wenn man "nett" ist, spannt man Dir noch eine anderweitige Firewall davor, ggf. public IP, oder internes Netz, wie auch immer, ist ja tendentiell alles möglich... (hier zumindestens geht sowas ).

Und ja - wenn nichts "dagegen" unternommen wird, kann man die Strecke von aussen bis zur Syno aufbohren. Deswegen ja auch "hole punching"-Mechanismus von QC (s.Whitepaper). Ich benutz den Mist nie, ich mache brav meine Freigaben und alles und jut ist

 

[ottosykora]

ja ich wollte nicht zu viel erklären
aber es ist so, es ist ein Netz welches von Cisco installiert und mit einem Vertrag gewartet wird. Und ja, die Schlaphüte können ziemlich sicher mit lesen falls es sie interessiert weil es sich um ein Meraki basiertes Netzwerk handelt.
An dem Netzwerk kann ich nichts tun, daran bin ich in keiner weise beteiligt, das geht mich so direkt auch nichts an. Bin drin mit mehreren Syno plaziert.
Ich kann mich zwar mit einem Cisco Meraki Security Appliance Gadget mit dem Netz verbinden, aber das nutzt mir nichts wenn ich auf einer der DS drive installieren und dazu die Clients testen will. Syno erlaubt bei den Cleints nur Domain oder QC. Also kommt hier nur QC in Frage.
Die DS darf raus, aber von aussen kann ich selber kein Zugang erstellen.

Mich hat nun einfach gewundert, warum ich nun heute in der Nacht 2 Versuche hatte, aber das Netz und die Syno ist so im Betrieb etwa 3 Jahre. Einziges was anders ist, seit ca 1 Woche versuche ich Drive zu entdecken und habe demnach Clients an PC und Android im Betrieb. Mit QC weil es sonst nichts gibt.
Ja, die heim DS hat Freigaben im Router und alles was es braucht, aber diejenigen welche in dem Arbeit Netz sind, die sind nur intern verwendbar oder via QC.


Darum die Frage. Wie immer zuerst sich fragen was ist anders in den letzten Tagen, was wurde geändert. Und das ist die Verwendung von Drive Client via QC.

 

[blurrrr]

"sind nur intern verwendbar oder via QC", sorry, aber da solltest Du Dein Netz-Design nochmal "ganz" stark überdenken... Anstatt endlos viel Kohle für so einen Cisco-managed-Mist auszugeben, solltest Du Dir vielleicht mal überlegen, dass Du zu einem Anbieter zu wechselst, mit dem Du auch über Dinge "reden" kannst (also wo auch abseits von "der Stange" Möglichkeiten gibt).

EDIT: Wenn es nur eine "DS" ist, passt die aber nicht ganz so gut in 19"-Racks im RZ... Ich weiss jetzt auch wieder, was dieses Meraki war... Dieses Cloudgelumpe, deswegen hat auch niemand meiner Bekannten (die Cisco-only-Ecke) sowas im Einsatz

EDIT2: Was QC angeht... wenn Du das kannst, können das andere übrigens auch, deswegen ist QC auch eher eine Lösung für Leute die "überhaupt keine" Ahnung haben und einfach nur "schnell" von aussen zugreifen wollen. Wenn man es "richtig" macht, nutzt man auch kein QC mehr, sondern einfach nur entsprechende Firewall-Regeln/Portweiterleitungen. Dein Domain-Problem würde sich auch lösen lassen, wenn man einen entsprechenden DNS-Server dazu hätte (z.B. auch einfach direkt auf der Syno selbst).

EDIT3: Ich muss einfach nochmal... Wer nutzt denn bitte eine "cloudmanaged" "Firewall"?!?

 

[ottosykora]

Ich kann nicht dafür, dass Syno diese Drive Clients nicht ganz einfach in einem internen Netz mit IP und fertig laufen lässt.

Ich kann mein Netz nicht überdenken, das ist nicht mein, das ist eine Einrichtung für schnelle Einsatztruppe welt weit.


Habe PM geschickt

Hat sich also für alle interessierten Erledigt. QC war nicht schuld, sonder ein Test mit Carddav und bei mir war auf der betreffenden DS auch Carddav Server installiert. Somit hat auch meine DS geantwortet.

Freigabe wurde geschlossen.