3
OpenVPN Server erhält seit Jahreswechsel tausende unbekannte Verbindungsversuche
Liebe Community!
Dank Eurer Hilfe konnte ich am Beginn der Coronakrise, im März 2020, einen (recht einfachen, aber stabilen) OpenVPN Server auf einem dd-wrt Gerät einrichten. Vielen Dank noch einmal für diese Hilfe gerade in der schwierigen Phase der Pandemie.
Zur kurzen Erklärung: Der OpenVPN Server (dd-wrt) wird hinter einem normalen DSL-Router betrieben, auf welchem eine Portweiterleitung eingerichtet ist. Die Anfragen zum Port 1194 werden also zum OpenVPN Server einfach durchgereicht und dort von ihm behandelt. Mir ist klar, dass dadurch beim Port 1194 ein "Loch" in die Firewall des DSL-Routers gebohrt wird und dass das nicht die 100% eleganteste Lösung ist, aber an sich sollte das so weit einmal passen; oder? Immerhin wird diese Lösung tausendfach verwendet...
So weit, so gut.
Es gab über die Jahre immer wieder einmal "routinemäßige" merkwürdige Verbindungsversuche von unbekannten IPs aus aller Welt, sich auf den OpenVPN zu verbinden die natürlich nicht erfolgreich waren. Diese habe ich im Logbuch verfolgt. Dazu habe ich gelesen, dass es offenbar ganz normal sei, dass im Fall, dass eine IP öffentlich über einen Port erreichbar ist, eben auch Anfragen über OpenVPN kommen werden. Das hat mich noch nicht sonderlich beunruhigt, waren halt offenbar Bots oder whatever.
Allerdings ist mir nun im Logbuch aufgefallen, dass diese Anfragen (fast genau) seit dem Jahreswechsel rapide gestiegen sind. Und zwar so viel, dass an mehreren Tagen zahlreiche IP Adressen stundenlang ununterbrochen versuchen, sich zum VPN-Server zu verbinden. Wenngleich immer erfolglos (TLS handshake failed). Das ergibt auch einige hundert (wenn nicht gar tausend) entsprechende Logbucheinträge.
Dazu möchte ich nun an Euch die Frage richten: Muss ich mir Sorgen machen? Hat es jemand hier darauf abgesehen, in unser System "einzubrechen", oder sind das DDoS Attacken? Was würdet Ihr empfehlen? Soll ich versuchen, die IP-Adressen zu blocken bzw nur bestimmte IP-Adressen als VPN-Clients zuzulassen (mit den iptables am dd-wrt bin ich damals gescheitert, dass nur bestimmte IPs zugreifen können...), oder besteht grundsätzlich kein Grund zur Sorge, solange die Zertifikate sicher verwahrt sind? Wir sind ein sehr, sehr kleiner (unbedeutender) Familienbetrieb, bei dem ich die IT der Eltern (so weit es geht) manage.
Tausend Dank im Voraus für Eure erneute (kompetente) Hilfe und Ratschläge.
Alles Liebe aus Österreich!
Dank Eurer Hilfe konnte ich am Beginn der Coronakrise, im März 2020, einen (recht einfachen, aber stabilen) OpenVPN Server auf einem dd-wrt Gerät einrichten. Vielen Dank noch einmal für diese Hilfe gerade in der schwierigen Phase der Pandemie.
Zur kurzen Erklärung: Der OpenVPN Server (dd-wrt) wird hinter einem normalen DSL-Router betrieben, auf welchem eine Portweiterleitung eingerichtet ist. Die Anfragen zum Port 1194 werden also zum OpenVPN Server einfach durchgereicht und dort von ihm behandelt. Mir ist klar, dass dadurch beim Port 1194 ein "Loch" in die Firewall des DSL-Routers gebohrt wird und dass das nicht die 100% eleganteste Lösung ist, aber an sich sollte das so weit einmal passen; oder? Immerhin wird diese Lösung tausendfach verwendet...
So weit, so gut.
Es gab über die Jahre immer wieder einmal "routinemäßige" merkwürdige Verbindungsversuche von unbekannten IPs aus aller Welt, sich auf den OpenVPN zu verbinden die natürlich nicht erfolgreich waren. Diese habe ich im Logbuch verfolgt. Dazu habe ich gelesen, dass es offenbar ganz normal sei, dass im Fall, dass eine IP öffentlich über einen Port erreichbar ist, eben auch Anfragen über OpenVPN kommen werden. Das hat mich noch nicht sonderlich beunruhigt, waren halt offenbar Bots oder whatever.
Allerdings ist mir nun im Logbuch aufgefallen, dass diese Anfragen (fast genau) seit dem Jahreswechsel rapide gestiegen sind. Und zwar so viel, dass an mehreren Tagen zahlreiche IP Adressen stundenlang ununterbrochen versuchen, sich zum VPN-Server zu verbinden. Wenngleich immer erfolglos (TLS handshake failed). Das ergibt auch einige hundert (wenn nicht gar tausend) entsprechende Logbucheinträge.
Dazu möchte ich nun an Euch die Frage richten: Muss ich mir Sorgen machen? Hat es jemand hier darauf abgesehen, in unser System "einzubrechen", oder sind das DDoS Attacken? Was würdet Ihr empfehlen? Soll ich versuchen, die IP-Adressen zu blocken bzw nur bestimmte IP-Adressen als VPN-Clients zuzulassen (mit den iptables am dd-wrt bin ich damals gescheitert, dass nur bestimmte IPs zugreifen können...), oder besteht grundsätzlich kein Grund zur Sorge, solange die Zertifikate sicher verwahrt sind? Wir sind ein sehr, sehr kleiner (unbedeutender) Familienbetrieb, bei dem ich die IT der Eltern (so weit es geht) manage.
Tausend Dank im Voraus für Eure erneute (kompetente) Hilfe und Ratschläge.
Alles Liebe aus Österreich!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1848888671
Url: https://administrator.de/forum/openvpn-server-erhaelt-seit-jahreswechsel-tausende-unbekannte-verbindungsversuche-1848888671.html
Ausgedruckt am: 08.01.2025 um 04:01 Uhr
3 Kommentare
Neuester Kommentar
Ich kann jetzt nichts dergleichen auf meinen Systemen erkennen - ABER:
Um genau diesen Bot-Traffic zu blockieren, arbeite ich auf meinen OpenVPN-Installationen mit einem zusätzlichen Static-Key (von OpenVPN auch TA-Key genannt).
Dieser Schlüssel wird sowohl beim Server als auch auf allen Clients hinterlegt, sämtlicher Datenverkehr wird bereits ab dem ersten Datenpaket mit diesem Schlüssel digital signiert. Der Server redet nur mit ordentlich signierten Clients und ignoriert alle anderen Pakete.
https://openvpn.net/community-resources/hardening-openvpn-security/
(Abschnitt "tls-auth")
Ein Bot scheitert damit schon an der ersten Hürde: Er kann keine signierten Pakete an den Server schicken, die der Server auch "versteht". Oder anders gesagt: Ein Client muss nicht mehr einen sondern zwei Schlüssel haben, um sich am Server anmelden zu können.
Um genau diesen Bot-Traffic zu blockieren, arbeite ich auf meinen OpenVPN-Installationen mit einem zusätzlichen Static-Key (von OpenVPN auch TA-Key genannt).
Dieser Schlüssel wird sowohl beim Server als auch auf allen Clients hinterlegt, sämtlicher Datenverkehr wird bereits ab dem ersten Datenpaket mit diesem Schlüssel digital signiert. Der Server redet nur mit ordentlich signierten Clients und ignoriert alle anderen Pakete.
https://openvpn.net/community-resources/hardening-openvpn-security/
(Abschnitt "tls-auth")
Ein Bot scheitert damit schon an der ersten Hürde: Er kann keine signierten Pakete an den Server schicken, die der Server auch "versteht". Oder anders gesagt: Ein Client muss nicht mehr einen sondern zwei Schlüssel haben, um sich am Server anmelden zu können.
2
Hallo,
ich fahre VPN grundsätzlich auf Linux-Systemen. Unter Anderem, um in Fällen wie diesen fail2ban zu etablieren.
Vielleicht gibt es das auch für DD-WRT?
Gruß,
Jörg
ich fahre VPN grundsätzlich auf Linux-Systemen. Unter Anderem, um in Fällen wie diesen fail2ban zu etablieren.
Vielleicht gibt es das auch für DD-WRT?
Gruß,
Jörg
1Zitat von @LordGurke:
Ich kann jetzt nichts dergleichen auf meinen Systemen erkennen - ABER:
Um genau diesen Bot-Traffic zu blockieren, arbeite ich auf meinen OpenVPN-Installationen mit einem zusätzlichen Static-Key (von OpenVPN auch TA-Key genannt).
Dieser Schlüssel wird sowohl beim Server als auch auf allen Clients hinterlegt, sämtlicher Datenverkehr wird bereits ab dem ersten Datenpaket mit diesem Schlüssel digital signiert. Der Server redet nur mit ordentlich signierten Clients und ignoriert alle anderen Pakete.
https://openvpn.net/community-resources/hardening-openvpn-security/
(Abschnitt "tls-auth")
Ein Bot scheitert damit schon an der ersten Hürde: Er kann keine signierten Pakete an den Server schicken, die der Server auch "versteht". Oder anders gesagt: Ein Client muss nicht mehr einen sondern zwei Schlüssel haben, um sich am Server anmelden zu können.
Ich kann jetzt nichts dergleichen auf meinen Systemen erkennen - ABER:
Um genau diesen Bot-Traffic zu blockieren, arbeite ich auf meinen OpenVPN-Installationen mit einem zusätzlichen Static-Key (von OpenVPN auch TA-Key genannt).
Dieser Schlüssel wird sowohl beim Server als auch auf allen Clients hinterlegt, sämtlicher Datenverkehr wird bereits ab dem ersten Datenpaket mit diesem Schlüssel digital signiert. Der Server redet nur mit ordentlich signierten Clients und ignoriert alle anderen Pakete.
https://openvpn.net/community-resources/hardening-openvpn-security/
(Abschnitt "tls-auth")
Ein Bot scheitert damit schon an der ersten Hürde: Er kann keine signierten Pakete an den Server schicken, die der Server auch "versteht". Oder anders gesagt: Ein Client muss nicht mehr einen sondern zwei Schlüssel haben, um sich am Server anmelden zu können.
Vielen, vielen Dank! Genau so etwas habe ich gesucht. Dank Deiner Hilfe habe ich jetzt tls-crypt (statt tls-auth, was offenbar "nur" für ältere Versionen empfohlen wird?) erfolgreich aktiviert und nun wird zusätzlich mittels eines statischen Schlüssels signiert. Dein Artikel beschreibt genau das Phänomen, das ich zu verhindern suchte: Bot-Anfragen etc. gleich vorweg abzuschneiden, ohne, dass ernsthaft mit diesen kommuniziert wird.
Mir ist in den Logs jedoch aufgefallen, dass dennoch ein fehlerhafter Anmeldungsversuch von einem meiner clients vermerkt wird, wenn dieser versucht, sich ohne statischem ta.key zu verbinden ("tls-crypt unwrap error: packet too short; TLS Error: tls-crypt unwrapping failed from [AF_INET]...."). Also "ganz 100% unkommunikativ" bleibt der Server dennoch nicht, und ich sehe weiterhin erfolglose Verbindungsversuche, wenn jemand ohne tls-crypt versucht, sich zu verbinden; aber der "Aufwand" des Servers mit dem Bot wird auf ein Minimum reduziert, sehe ich das richtig?
Liebe Grüße und noch einmal herzlichen Dank für die punktgenaue Antwort und Hilfe.
