OpenVPN - Wozu brauch ich das? Wie geht das?

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Atticus:

    Ich hatte mit meiner Antwort schon angefangen, als zwischenzeitlich die Antwort von __deets__ kam. Ich sende es aber trotzden ...

    Der Port UDP 161 wird standardmäßig für das Simple Network Management Protocol verwendet. Wie du aus dem verlinkten Artikel erkennst, ist das ein Protokoll, welches zur Überwachung und Steuerung von Netzwerkelementen dient. Allerdings kann dieses Protokoll auch missbraucht werden, weshalb dein Provider bei einem Endnutzer diesen Port sicherheitshalber sperrt.

    Die Lösung deines Problems hat __deets__ ja beschrieben: einfach einen anderen Port für den Tunnel wählen. Am besten einen, der nicht für eine bestimmte Verwendung spezifiziert ist.


    MfG Peter

  • Die Lösung deines Problems hat __deets__ ja beschrieben: einfach einen anderen Port für den Tunnel wählen. Am besten einen, der nicht für eine bestimmte Verwendung spezifiziert ist.

    Ist es wirklich so, dass UM/VF einen lauschenden OpenVPN-Server nicht von einem lauschenden snmpd-daemon unterscheiden kann? Denn die haben ja geschrieben:

    Zitat


    Auf Ihrem Endgerät ist ein offener SNMP Dienst aktiv

    ... und es gibt ja tools, mit denen man einen offenen snmpd genau identifizieren kann.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das kommt drauf an, wie ausgefeilt deren heuristik ist. Meines Erachtens hat kein PI SNMP einfach laufen. Das wäre also schon ein extra Service + eine zu breite Portweiterleitung. Kann natürlich sein, aber wissen kann das nur der TE.

  • "Wir konnten in den letzten Tagen feststellen, dass ein von Ihnen verwendetes internetfähiges Endgerät ein Sicherheitsproblem darstellt. Auf Ihrem Endgerät ist ein offener SNMP Dienst aktiv."

    Hat sich eigentlich schon mal jemand die Frage gestellt, wenn 'die' von außerhalb einen angeblich offenen Dienst auf einen Gerät hinter dem Router und innerhalb des privaten Netzes feststellen können, was die sonst noch alles in diesem privaten Netz und der dort betriebenen Hardware feststellen können? Ohne mich jetzt tiefer damit befasst zu haben, war mein erster Eindruck 'Entsetzen' bezogen auf die digital-private Integrität.

  • ?‍♂️ Nichts dieser Art lässt sich aus der Problembeschreibung folgern. Außer der Aluhut sitzt wieder bis über die Nase, und stört die Atmung. ‚Die‘ stellen nur Verkehr vom Router auf UDP161 fest. Das war es. Das der TE im Rahmen seiner VPN Konfiguration eine Portweiterleitung getätigt hat, ist normal und notwendig. Und wenig überraschend kann der Provider feststellen, dass auf solchen Ports Verkehr stattfindet.

  • Wobei es ja schon Provider/Verträge gibt bei denen man keinen Zugriff auf den gestellten Router hat beispielsweise und monatlich extra für WLAN zahlen muss, sonst schalten die das ab. Das finde ich auch von der Sicherheit/Privatsphäre her bedenklich, denn man hat da an zentraler Stelle ein fremdes Gerät in seinem Netzwerk stehen, das nicht nur das sieht was ins Internet geht, sondern auch Zugriff auf rein lokalen Datenverkehr hat der durch den Router geleitet wird. So ganz ohne Aluhut würde ich mich dabei unwohl fühlen.

    “Dawn, n.: The time when men of reason go to bed.” — Ambrose Bierce, “The Devil's Dictionary”

  • __blackjack__ Keine Frage. Dieses Problem besteht aber grundsaetztlich, und ist durch diese Geschichte ja in keiner weise plausibler oder belegbarer geworden. Frei nach Occams Rasierer ist die hier geschilderte Situation voellig ohne unlautere Eingriffe in die digitale Privatsphaere erklaerbar. Bei *mir* waere das sogar eine vertrauensbildende Massnahme, denn ein durch Fehlkonfiguration entstandenes Leck zu melden ist ein Dienst an mir. Siehe auch die aktuelle c't'. Man kann natuerlich immer noch einen draufsetzen und sagen "aber das haben die nur gemacht, um mich in Sicherheit zu wiegen", und dann ist auch irgendwie nur noch Achselzucken ;)

  • Ja so etwas passiert eben, wenn man einen gemäß Liste der von der IANA standardisierten Ports für eine andere Anwendung "missbraucht". Noch dazu, wenn dieser Port bzw. dessen Verwendung als "offiziell" bezeichnet ist.

    Selbstverständlich ist dieses nicht verboten, aber wenn man dies macht, muss man eben mit solchen Effekten rechnen.

    BTW:

    Ich finde es gut, wenn ein Provider bei unüblicherweise geöffneten Ports oder auch auf bestimmten unüblichen Traffic angemessen reagiert. Bspw., wenn er den Benutzer eines Internetzuganges darauf hinweist, dass überdurchschnittlicher Traffic auf :25 erkannt wurde, was auf das Wirken eines Schadprogrammes hinweist, welches als SPAM-Bot arbeitet, usw.

    Wichtig sehe ich dabei die beiden Begriffe angemessen und überdurchschnittlich. Ob das sofortige "Dichtmachen" eines bestimmten Ports angemessen ist, wage ich zu bezweiflen. IMHO hätte ein Hinweis mit einer Frist zur Klärung auch schon gereicht.

  • Auch eine interessante Frage ist ob man den Provider dazu bewegen kann diese Sperre wieder aufzuheben.

    Gleich sperren finde ich übrigens angemessen. Denn der Anteil von Kunden bei denen so etwas Ergebnis einer Schadsoftware ist, dürfte *deutlich* höher sein als der Anteil der absichtlich einen SMTP-Server aufsetzt und den nach aussen verfügbar macht.

    “Dawn, n.: The time when men of reason go to bed.” — Ambrose Bierce, “The Devil's Dictionary”

  • Ohne dass ihr gleich Schnappatmung bekommt: Euer ISP bekommt von euch alles* mit - zum Beispiel welche Seiten ihr im Internet besucht, welche Mailserver ihr benutzt und ja über welchen Port ihr Traffic abwickelt. (* = siehe mögliche Maßnahmen weiter unten).

    Das ist unabhängig davon, ob euer Router vom ISP gemanagt wird. Das sind einfach eure DNS-Anfragen, die Serveraufrufe u.ä., die der ISP durchleitet und daher kennt. Wer das nicht will, sollte z.B. schauen, dass er den DNS-Traffic verschlüsselt*.

    Dass der Provider auf von ihm gemanagte Router zugreifen kann, ist auch bekannt. Nicht nur WLAN ein- und ausschalten, die Firmware updaten (oder auch nicht), theoretisch ist da „alles“ möglich, weil die Schnittstellen, über die das läuft m.w. nicht OpenSource gestellt sind. Theoretisch kann der einen Port aufmachen, euch irgendwas unterschieben und den Port wieder schließen, ohne dass das jemand mit bekommt.

    Wer das nicht will: Nachdem es keinen Routerzwang mehr gibt, ein einfaches Kabelmodem nehmen, und dahinter einen eigenen Router* setzen. Auf den hat der ISP keinen Zugriff.

    Auch einen VPN-Provider zu nutzen* kann helfen, den ISP raus zu nehmen - nur rutscht der VPN-Provider eures Vertrauens (hat er das wirklich verdient ?) in die gleiche Rolle. Der sieht dann eben auch alles, was über seinen Server läuft.

    Im vorliegenden Fall hat der ISP einfach nur seinen Job gemacht: Er hat auf einem ungewöhnlichen, weil bei Privatanwendern selten genutzten Port, der für einen latent unsicheren Dienst steht, Datenverkehr festgestellt. Die wahrscheinliche Erklärung dafür ist eine Schadsoftware beim Kunden, die mit ihrem ControlServer spricht. Das wird durch die Portsperrung unterbunden. Ich denke man sperrt, um Schaden abzuwenden - ein legitimer Betreiber wird sich ja melden und erklären, was Sache ist.

    Das empfehle ich auch in diesem Fall: Vodafone anrufen oder per Mail informieren. Sonst kommt der Anschluß dort auf den Index. Außerdem sollte man wirklich die unteren Ports in Ruhe lassen, und den eigenen VPN-Zugang in die hohen 5-stelligen Bereiche legen.

  • Die wahrscheinliche Erklärung dafür ist eine Schadsoftware beim Kunden, die mit ihrem ControlServer spricht.

    Aber warum sollte der Programmierer dieser Schadsoftware, gerade den UDP-Port 161 als source-Port programmiert haben? Evtl. war das auch Absicht, damit das ziemlich schnell bemerkt wird. ;)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!