Durch die E-Mail-Aufforderung wird die Datenschutzerklärung für mich obsolet.
Warum das? Die Datenschutzerklärung gilt doch unabhängig vom Kommunikationsweg.
Beiträge von frank_m
-
-
Kommt drauf an. Wie hast du den Server denn konfiguriert in Bezug auf seine Host-ID? Was Zufälliges oder EUI-64? Dann könnte die IP stabil bleiben.
-
* Ich bekomme die Zusicherung, dass die übermittelten Daten nach der Verifikation gelöscht werden.
Das sollte schon aus der Datenschutzerklärung hervorgehen.
-
Daher sollte Netcup am besten auf einen entsprechenden Dienstleister setzen (an sich ist das Bild ja nachvollziehbar - sonst müssten die Daten ja nicht mal gestohlen sein => Man kann sie sich auch einfach ausdenken).
Und dem vertraut ihr die Daten an, aber netcup nicht?
Dazu kommt: Es gibt ein sicheres Verfahren, wo zusätzlich noch ein Pin gebraucht wird: Die AusweisApp2 (durch den Pin wird Diebstahl verhindert und es wird verifiziert, dass die Daten echt und korrekt sind)
Und das ist datenschutzrechtlich unbedenklicher, als ein Foto?
Irgendwo fehlt mir hier die Verhältnismäßigkeit.
-
Wie soll netcup denn verifizieren, ob jemand einfach nur die Daten eines gestohlenen Ausweises benutzt hat?
Hier widersprechen sich mal wieder zwei Gesetze: Der Datenschutz und die Identifizierungspflicht im Netz, gerade als Dienstbetreiber. Üblicherweise ist es so, dass die Daten erhoben werden dürfen, wenn andere Gesetze es fordern.
-
Diese Aufforderung ist m.b.M. eine grundsätzliche Verletzung der DSGVO als auch der EU-DSGVO
Warum?
Die DSGVO verbietet nicht grundsätzlich die Erhebung personenbezogener Daten. Man braucht lediglich einen guten Grund dazu. Wenn es in diesem Fall die Identifizierung unterstützt, lässt sich das problemlos begründen.
Viele denken, mit der DSGVO darf man nichts mehr. Das ist ein Irrtum. Man darf lediglich nicht leichtfertig Daten erfassen, verarbeiten oder speichern. Aber wenn man es für den Prozess braucht, ist es nach wie vor kein Problem.
-
genau das möchte ich mitlerweile, da ein teil meiner services nicht über http/https laufen wofür der npm kein nutzen hätte, der npm soll für meine http/s relevanten sachen dienen
Ah, ok. Dann muss man sich aber das gesamte Setup noch mal ansehen. In dem Fall macht es meines Erachtens keinen Sinn mehr mit 2 NPMs zu arbeiten.
Ich möchte ein teil der Services - nehmen wir mal als Beispiel irgend einen Voice/Gameserver durch den VPS über wireguard leiten.
Ja, genau das hab ich hier schon mal irgendwo beschrieben. In Kürze: VPN Tunnel aufbauen, Heimnetz durchrouten und per iptables Portweiterleitungen bzw. Portöffnungen auf dem Server einrichten.
Es ist noch kein Meister vom Himmel gefallen, ich möchte hier aber nicht mein Meister in dem Thema machen sondern mein Ziel erreichen und dabei auch das eine oder andere an Wissen / Erfahrung mitnehmen.
Genau das meine ich ja. Nur: Wenn du nach einer Wireguard Anleitung für 5 Jährige suchst, findest du nicht die Information, die du brauchst. Wie gesagt, Wireguard setzt IP Routing Know How voraus. Grundsätzlich. In nahezu jeder Anleitung sind irgendwelche Post-Up oder Pre-Down Regeln, und kein Mensch erklärt dir, wofür die im Detail sind. Das musst du einfach vorher wissen, und das Wissen findest du nicht in Wireguard Anleitungen. Wäre auch blöd, denn 90% der Leute, die die Wireguard Anleitung lesen, kennen das schon. Nur die verbleibenden 10% müssen es noch lernen. Es ist besser, die 10% befassen sich mit speziellen Artikeln, als wenn 90% was lesen müssen, was sie nicht interessiert, was qualitativ am Ende auch noch deutlich schlechter ist, als ein spezieller Artikel.
ich persönlich rechne es mir zumindest schon einmal hoch an, dass ich es zumindest selbst versuche/veruscht habe und auch nach Unterstützung frage.
Ich hätte es dir noch deutlich höher angerechnet, wenn du vorab die Suche bemüht hättest und in deiner Nachfrage schon konkret auf Aspekte vorhandener Anleitungen eingegangen wärst. Denn die gibt es, hier im Forum und bei Google.
Dabei muss es auch nichtmal ein 1:1 Guide zum stupiden nachbauen sein,
Den gibt es eh nicht, und zwar nie. Deshalb sage ich immer: Anleitung lesen, verstehen, auf die eigene Situation adaptieren, umsetzen. Nicht einfach nachbauen, denn dass man exakt die Anforderungen des Artikels hat, ist praktisch ausgeschlossen. Selbst wenn das mit dem NAT noch richtig ist: Warum gibt es IPv6 Regeln, wenn es keine IPv6 Adressen im Tunnel gibt? Und wenn es dann offene Fragen und Unklarheiten gibt, dann sucht man da weiter. Erst wenn man nichts mehr findet, dann sucht man Unterstützung, aber das kannst du mir für diese Fragen noch nicht erzählen, dass es dazu nichts mehr gibt. Ich kann es deshalb mit Sicherheit behaupten, weil ich selber diverse Male was zu solchen Fällen geschrieben habe, bei verschiedenen Gelegenheiten (nicht nur in Foren).
Ich würde jetzt nicht eine 400Seiten Lektüre über Grundlagen von IP Routing durchforsten müssen um an mein Ziel zu kommen, wenn oberflächliches Verständnis und dann - ggfls durch einen Schubbs in die richtige Richtung , das AHA Erlebnis von selbst kommt, wie bereits erwähnt möchte ich hier kein Master machen sondern schlicht und ergreifend mein Ziel erleichtern, solltest du also empfehlenswerte Informationen für mich haben , Zitate, Links bin ich dem allerdings auch nicht abgeneigt.
Deshalb schrieb ich auch "Grundlagen".
und ob ich auf dem VPS Wireguard als allowed 0.0.0.0/0 mache - da der ja alle Anfragen akzeptieren soll?
Nein, da bestimmt nicht. Wenn, dann auf der anderen Seite.
"Lern zuerst XYZ " Bevor du da dran gehst ist ja gut und schön, aber alles andere als "Freundlich",
Du musst es so oder so lernen. Es ist völlig egal, ob ich es hier schreibe, oder ob du es dir aus einer anderen Anleitung holst. Nur dass die andere Anleitung mit Sicherheit deutlich besser ist, als ich es hier in der Schnelle zusammenschreiben könnte.
Du suchst nach dem Schubser? Der Schubser ist: Befasse dich mit den Grundlagen IP Routing. Das ist genau das, was du für dein AHA Erlebnis brauchst. Die Wireguard Konfiguraton an sich ist ok. Du schubst nur die falschen IPs durch die Gegend. Und nein, das kann ich dir nicht Schritt für Schritt vorgeben, denn welche Netze du wohin routen musst, hängt von der Systemkonfiguration, vor allem von Docker, ab. Das musst du dir wohl oder Übel selber erarbeiten.
-
Du willst ja nicht den Internetverkehr durchs VPN schicken, sondern den NPM erreichen. Also ist kein NAT nötig. Die Allowed IPs auf Client Seite beinhalten ja auch nur das Transportnetz (das ist richtig), also gibt es gar nichts, was genatted werden könnte.
Du brauchst keine Wireguard Anleitung, du brauchst Grundlagen IP Routing. Jede Wireguard Anleitung setzt das voraus.
-
warum sind da NAT Regeln? Die machen doch gar keinen Sinn.
-
AllowedIPs = 0.0.0.0/0, ::/0
Du leitest die IPv6 Default Route auf VPN, nutzt aber kein IPv6 im Tunnel. Das kann gefährlich sein.
Muss denn wirklich der gesamte Internet-Traffic übers VPN getunnelt werden?
-
Ich habe nicht nach Lücken gesucht, ich würde nicht ohne Erlaubnis auf deinen Server zugreifen und danach suchen, damit macht man sich wahrscheinlich strafbar.
Vermutlich nicht, solange keine kriminelle Absicht dahintersteckt, niemand zu Schaden kommt und die Untersuchung im Vordergrund steht. Vor einigen Jahren hat ein c't Redakteur mal eine CD mit Hackertools und Anleitungen dazu veröffentlicht und sich anschließend selbst angezeigt. Das Verfahren wurde eingestellt: Keine kriminelle Absicht.
-
Einen Gegenbeweis kann man nur liefern, wenn davor ein Beweis geliefert wurde. Und das haben Sie nicht.
Falsche Herangehensweise bei einer Risikoanalyse. Der Beweis, dass die Lücken da sind, ist vorhanden, das sind die offiziellen CVE Listen. Der Gegenbeweis muss erbracht werden, dass sie beseitigt oder deaktiviert wurden, und zwar für jede einzelne. Nicht nur für die wichtigsten, die oben verlinkt sind, sondern für alle gut 500. Solange der Beweis nicht erbracht ist, muss man davon ausgehen, dass sie aktiv sind und ausgenutzt werden können.
Aufgrund der Art und Weise wie die Lücken funktionieren würden, falls sie überhaupt existieren, ist nicht davon auszugehen, dass sie genutzt werden können.
Berühmte letzte Worte.
Die Sache mit NetBIOS hingegen kann nicht funktionieren, das hatte ich aber auch schon geschrieben und Sie haben es zitiert..
NetBIOS sind auch nur ne Handvoll Lücken von den 500.
Welcher Webserver wird benutzt? IIS? Und FTP Server? Filezilla? Sind noch mal 250 Lücken extra.
-
Sparen Sie sich bitte Ihre Beleidigungen. Ihr Kommentar, dass ich überhaupt keine Ahnung habe und wahnsinnig sei, können Sie sich nach Ihrer Aussage, dass alle Sicherheitslücken aus der Liste auf meinen Server zutreffen würden, nicht mehr leisten.
Die Lücken sind aktiv auf deinem Server, vor allem die erwähnten Client Lücken. Bin gespannt, wie du den Gegenbeweis anbringen willst.
-
Meines Wissens zählt aber nicht die Anzahl der Cores des VPS/RS, sondern die Anzahl der Cores des Host-Systems für Lizenz. Im Falle eines AMD 7702 bräuchte man also eine Lizenz, die für 64 Cores gültig ist, bei den neuen G11 Servern sogar 84 cores.
-
3. Eintrag: Aktualisierungsproblem im DNS-Zwischenspeicher. Der Server ist weitgehend passiv und macht nur in den seltensten Situationen überhaupt eine DNS-Abfrage.
4. Eintrag: Problem mit WINS-Server. NetBIOS ist bei mir deaktiviert.
5. Eintrag: Lücke in WinHTTP. Der Server surft allerdings nicht im Internet, sodass die Lücke genutzt werden könnte.
Zu meinem Leidwesen hast du durch diesen Beitrag noch mal dokumentiert, dass du leider von der Materie überhaupt keine Ahnung hast. Alles drei sind Lücken im Client System von Windows. Dafür musst du keinen Server ins Netz stellen, diese Schwachstellen kann man allein dadurch ausnutzen, dass der Server aufs Internet zugreift. Das sind genau die Lücken, von denen es oben hieß, dass nicht mal eine Linux Firewall vor dem Server gegen alle Schwachstellen schützen kann.
LASS ES! Es ist absoluter Wahnsinn, diesen Server direkt im Internet zu betreiben.
-
Vor allen möglichen Lücken schützt das natürlich auch nicht, aber sicherer als aktuell wäre es auf alle Fälle.
Es gibt auch genug Lücken im Client Code von Windows 2000, ..., HTTP Client, DNS, LDAP. Das System sollte gar nicht mehr ins Internet.
-
Du hast die verlinkten CVE Listen gesehen? Das sind alles Sicherheitsslücken auf deinem Server. JEDE EINZELNE. Und um deine Worte zu benutzen: sie werden sehr gut funktionieren, leider. Genug konkrete Hinweise?
-
"Funktioniert" finde ich niedlich in dem Zusammenhang.
Davon werden die meisten auf deinem Server "funktionieren". Und das sind nur die mit hoher Wertung. Es gibt noch 500 mehr.
-
Wenn ich Ahnung hätte würde ich nicht den ganzen Tag versuchen.
Dann ist ein vServer das falsche Versuchsobjekt. Denn wenn hier was schief geht und dein Server gehackt wird, dann leidest nicht nur du darunter, sondern auch alle anderen Netcup Kunden, weil die IPs auf Blacklisten landen. Schau dich im Forum um, es ist voll mit Beiträgen rund um verschiedene Listen. Ganz davon abgesehen kommen die Schadensersatzforderungen dann auf dich zu, und das ist schnell mal eine 5-stellige Summe.
Nur für deine Einordnung: Auf eine öffentliche IP prasselt in etwa eine Attacke pro Sekunde (!) ein: Portscans, Applikationsangriffe, usw. Dazu kommt: Allein das RDP Protokoll in Windows hat 300 (!) ungepatchte Sicherheitslücken, die eine sofortige Übernahme des Servers erlauben. Nach der Installation hast du allenfalls wenige Minuten, dann ist er erledigt, wenn du keine speziellen Gegenmaßnahmen ergreifst.
Deshalb schließe ich mit der Empfehlung von Exception an. Nimm dir eine VM und übe. Und generell auch für später: Ein Windows Client Betriebssystem ist denkbar ungeeignet als Server, und die Lizenzen von Microsoft geben es auch nicht her. Illegal ist es also auch noch, was du vorhast.
-
Du bist dir sicher, du weißt, was du da tust? Das ist ein Reg Key, kein Kommando. Hast du überhaupt die Regedit geöffnet?
Hast du eine Ahnung, wie schwierig es ist, einen Windows Server abzusichern? Wenn du nicht mal in der Lage bist, einen Registry Key zu ändern, dann würde ich dir dingend empfehlen, es sein zu lassen.
