News Terrapin-Angriff: Fast 11 Millionen online erreichbare SSH-Server sind anfällig

[Salamimander]

Das sicherste ist Port-Knocking mit einer custom Sequenz und dann vpn oder ssh. Mein ssh lauscht auch nur innerhalb des VPNs… (für den Notfall habe ich noch Remote VNC über meinen Provider)

 

[mae]

Port 22 ist natürlich geschlossen - wenn ich wirklich von außen den Server ansteuern möchte, verbinde ich mich per VPN (z.B. Wireguard) in das Netzwerk und greife dann über Port 22 intern drauf zu.

Und dann hast Du eine Luecke im VPN. Ist damit wirklich etwas gewonnen? Ssh macht eine verschluesselte Verbindung mit Authentifizierung ueber einen private key. Das ist so sicher wie eine verschluesselte Verbindung ueber ein VPN. Klar, Luecken kommen vor, anderswo aber auch.

 

[aid0nex]

Und dann hast Du eine Luecke im VPN.

Inwiefern macht das meinen VPN unsicherer, oder sogar "lückenhaft", wenn sich in diesem Netzwerk zu dem der VPN Zugriff bietet auch ein Server befindet? Deine Aussage macht für mich wenig Sinn.

Ssh macht eine verschluesselte Verbindung mit Authentifizierung ueber einen private key. Das ist so sicher wie eine verschluesselte Verbindung ueber ein VPN.

Das Prinzip musst du mir nicht erklären, danke. Stell dir vor, mein VPN nutzt ebenfalls Public Key Authentication, genauso wie mein Server per SSH. Es ist also DOPPELT per Public Key abgesichert, es müsste eine Schwachstelle im Wireguard und im SSH Protokoll geben (oder BEIDE Private Keys bekannt werden) damit die Verbindung unsicher ist. Von außen betrachtet ist das eine Tunnel-in-Tunnel-Verbindung.

Ergänzung (4. Januar 2024)

Mehr noch wird SSH über Tunneling durchaus auch als Quasi-VPN verwendet.

Ja, das beobachte ich tatsächlich auch in meinem beruflichen Kontext, das ist üblich - aber nicht von außen über das Internet erreichbar sondern immer nur im internen Firmenkontext. Der Rechner muss also überhaupt erstmal per VPN (bei uns OpenVPN / Cisco Anyconnect) mit dem Intranet verbunden sein. Da ist KEINE Kiste von außen per SSH ansteuerbar!

 

[xpad.c]

Den SSH-Dienst sollte man dann aber zumindest manuell neustartet, sofern apt das nicht selber macht*. Ansonsten bleibt bis zum nächsten Reboot erstmal weiter die bereits laufende, alte Version aktiv.

* dürfte apt eher nicht machen, da im Moment des Neustart des Dienstes ja auch gerade aktive Sitzungen abbrechen.

Macht es aber (post-install mit offensichtlichen Ausgaben), und wie oben schon von anderen angemerkt, sind laufende Sitzungen davon nicht betroffen.

xpad

 

[ownagi]

@aid0nex: Sehe in einem offenen SSH-Zugang eigentlich wenig Probleme.
Viele Webhoster bieten das an und ich wüsste nicht, wieso das besonders kritisch sein sollte.
Kommt natürlich immer auf den Kontext und die sonstige Umgebung an. Für einen einzelnen Webserver würde ich allerdings nicht extra ein VPN aufsetzen und bezahlen wollen, da bleibe ich lieber beim Standard.
Mein Port- bzw. IPv4->IPv6-Mapper ist per SSH im Netz frei zugänglich, mein eigentlicher Server daheim dagegen nicht, da ist nur 443 offen ... bzw. nichtmal dort, sondern nur beim davorgeschalteten Reverse-Proxy.

 

[Bob.Dig]

Das ist so sicher wie eine verschluesselte Verbindung ueber ein VPN.

Nope, WireGuard handelt nix aus, ist hochmodern und hat zahlreiche weitere Sicherheitsfeatures fest integriert.

Ergänzung (4. Januar 2024)

allerdings nicht extra ein VPN aufsetzen und bezahlen wollen,

Wieso bezahlen?

Ich hab tatsächlich Port 22 nur für feste IPs offen oder hinter einer Sense, die das auch für DDNS-Adressen machen kann. Ist trotzdem alles schon gepatcht.

 

[up.whatever]

Falls ja verstehe ich dei Aufregung und diesen Artikel nicht.

Ich auch nicht, das ist viel Wind um eine fast schon unbedeutende Kleinigkeit. Dennoch schreit das halbe Internet blind nach Patches, als hätte man eine unauthenticated remote code execution...

 

[KitKat::new()]

hätten die Security Kollegen mir sofort den Kopf abgesägt

Mit welcher Begründung?

Serverzugriff via SSH ohne VPN ist Standard bei Servern sh. z.B. https://docs.hetzner.com/cloud/servers/getting-started/connecting-to-the-server/ https://learn.microsoft.com/en-us/azure/virtual-machines/windows/connect-ssh https://www.linode.com/docs/guides/connect-to-server-over-ssh-on-linux/p

 

[holdes]

SSH und viele aus Deutschland? Wenn da mal nicht einige Linux aka Enigma Receiver dabei sind, welche keine Updates mehr bekommen aber von ihren Besitzern durchgenattet wurden .

 

[busta1]

Mit welcher Begründung?

Serverzugriff via SSH ohne VPN ist Standard bei Servern sh.

Auch bei einem Cloud Provider bist du für die Sicherheit verantwortlich. Du solltest dort ebenso eine Firewall, und sofern nicht sowieso schon mit dem Firmennetzwerk per VPN oder MPLS verbunden, ein VPN Gateway deployen und dann musst du auch dort Port 22 nicht aus dem Internet erreichbar machen. Bequemer ist es natürlich trotzdem. Macht man in Firmennetzwerken aber einfach nicht.

 

[KitKat::new()]

Auch bei einem Cloud Provider bist du für die Sicherheit verantwortlich.

Inwiefern ist das eine Antwort auf meine Frage?
Sicherheit hat man auch mit SSH.

musst du auch dort Port 22 nicht aus dem Internet erreichbar machen.

Es geht ja nicht ums müssen, sondern ums nicht sollen. Und Port 22 alleine kann ich ja alleine schon vermeiden indem ich die Konfiguration vom SSH Server ändere (sofern der Port irgendein Problem darstellen eürde ;-) )

 

[ReactivateMe347]

Es geht ja nicht ums müssen, sondern ums nicht sollen. Und Port 22 alleine kann ich ja alleine schon vermeiden indem ich die Konfiguration vom SSH Server ändere (sofern der Port irgendein Problem darstellen eürde ;-) )

Nichts gegen die zusätzliche Security by Obscurity, aber man kann problemlos IPv4 komplett scannen, da hilft auch ein anderer Port nicht.
Klar, man hat sicher weniger Datenverkehr, wenn man nen hohen Port nutzt, aber sicherer wird es dadurch nicht.

Ergänzung (5. Januar 2024)

Nope, WireGuard handelt nix aus, ist hochmodern und hat zahlreiche weitere Sicherheitsfeatures fest integriert.

Wenn es wirklich nichts aushandeln, dann bin ich gespannt, wie das in 20 Jahren aussieht. Kann mir nicht vorstellen, dass WireGuard nicht vorsieht, die Krypton auszutauschen.

Das man nichts unsicheres aushandeln kann, dafür ist der Server verantwortlich. Der Admin muss da immer zwischen kompatibeilitat und Sicherheit abwägen. Wenn Terrapin so problematisch wäre, wie es dargestellt wird, dann sollte der Server die Verbindung ohne diese Erweiterungen einfach verweigern - dann hat man keine Downgrade-Möglichkeit mehr.

 

[aid0nex]

Mit welcher Begründung?

Serverzugriff via SSH ohne VPN ist Standard bei Servern sh. z.B. https://docs.hetzner.com/cloud/servers/getting-started/connecting-to-the-server/ https://learn.microsoft.com/en-us/azure/virtual-machines/windows/connect-ssh https://www.linode.com/docs/guides/connect-to-server-over-ssh-on-linux/p

Ganz ehrlich - ich kann's dir nicht ganz genau sagen. Das ist so Usus bei uns in der Firma (DAX Konzern btw.) und auch eine Security Anforderung, die ich zu erfüllen und nicht zu hinterfragen habe. Deshalb habe ich es privat bisher auch immer so gemacht. Mir fällt auch kein Grund ein nicht den Weg der doppelten Absicherung zu gehen. Doppelt hält besser..? Ein Sicherheitsmechanismus der greift ist gut, zwei sind besser.

Ergänzung (5. Januar 2024)

@aid0nex: Sehe in einem offenen SSH-Zugang eigentlich wenig Probleme.
Viele Webhoster bieten das an und ich wüsste nicht, wieso das besonders kritisch sein sollte.

Naja sieht man doch - eine Lücke in SSH, einmal der Key geleaked und zack sind Tür und Tor offen. Durch den VPN hat man noch eine zweite Absicherung, eine zweite Sicherheitsbarriere.

 

[Bob.Dig]

Wenn es wirklich nichts aushandeln, dann bin ich gespannt, wie das in 20 Jahren aussieht.

Ich ebenfalls. Vermutlich wird es einfach ein WireGuard 2.0 geben, welches beide Seiten sprechen müssen, einen Fallback wird es nicht geben.

 

[foofoobar]

Wo kein Code da keine Fehler.

Das ist eine bewusste Designentscheidung möglichst wenig auszuhandeln, wenig Modi zu implementieren und wenig State zu haben.

 

[pseudopseudonym]

SSH und viele aus Deutschland?

Warum nicht?

 

[ownagi]

Wieso bezahlen?

Rede von einzelnen, extern gehosteten Servern, da bekomme ich den VPN zusätzlich zu meinem Server nicht geschenkt.
Intern bzw. im Firmennetz oder auch bei massig gemieteten/extern betriebenen Systemen sieht das natürlich anders aus.

 

[TomH22]

Ganz ehrlich - ich kann's dir nicht ganz genau sagen. Das ist so Usus bei uns in der Firma (DAX Konzern btw.) und auch eine Security Anforderung, die ich zu erfüllen und nicht zu hinterfragen habe.

Ihr redet von sehr unterschiedlichen Sachen. Klar, wenn es um Server in einem Firmennetz geht, ist das Vorschalten eines VPN Stand der Technik und hat neben Sicheheitsaspekten auch den Vorteil, dass es viel einfacher zu managen ist (keine Portweiterleitungen, etc).

Die Mehrzahl der offenen SSH Server sind Cloud Server die sowieso eine öffentliche IP haben, etwa die typischen Webhoster wie Strato, Hetzner, usw.
Dort wird ssh als Standard für den Shell Zugang genutzt. Paralell gibt es dann immer noch ein Weg zum Upload des Content, z.B. ftps, sftp, usw.

Das geht alles über die öffentlichen IPs des Servers. In der Regel stellt der öffentliche Webserver in diesen Fällen die größere Angriffsfläche dar, besonders wenn dort notorisch anfällige CMS Systeme laufen, oder selbstgebastelter PHP Code.

Diese Dienste gibt es ja teilweise schon für 1 EUR pro Monat, die sollen einfach benutzbar und billig sein, maximale Sicherheit ist da sowieso nicht das Ziel.

Abgesehen davon gilt aber ssh als Protokoll, dass man im öffentlichen Internet sicher verwenden kann, die „technische“ Sicherheit ist vergleichbar mit gängigen VPN Protokollen.

 

[Donnerkind]

Inwiefern macht das meinen VPN unsicherer, oder sogar "lückenhaft", wenn sich in diesem Netzwerk zu dem der VPN Zugriff bietet auch ein Server befindet? Deine Aussage macht für mich wenig Sinn.

@mae sprach hypotetisch für den Fall, dass dein VPN mal ne Schwachstelle haben sollte. Insofern ist es im Vergleich zu ssh nicht schlechter, aber auch kaum besser.

Was natürlich eine Schwachstelle für öffentliche SSH-Server ist: Benutzer admin und Passwort admin.

 

[ReactivateMe347]

Ich ebenfalls. Vermutlich wird es einfach ein WireGuard 2.0 geben, welches beide Seiten sprechen müssen, einen Fallback wird es nicht geben.

Krass, scheint echt zu stimmen. Sprich sobald einer der Algorithmen tot ist, ist WireGuard hinfällig, kein Patchen möglich. Krass.