News Sicherheitslücke in xz: Backdoor in Linux-Archivbibliothek macht Systeme angreifbar

[Termy]

Und meinen Server, den ich irgendwo gemietet habe, administriere ich dann per Telepathie?

VPN, Reverse Proxy u.ä. sind kein Begriff?

Auch wenn das VPN auf dem gleichen Server läuft bist du immer noch in einer bessere Situation als mit zig offen erreichbaren Diensten. Da brauchst du auch keinen extra Server für mieten

 

[Keylan]

auf manchen seiten wird direkt zu kompletter Neuinstallation des Systems geraten... Übertriebene Vorsichtsmaßnahme oder gerechtfertigt?

Manch Ärzte raten auch zur Chemotherapie...... ach das war nur für spezielle Krankheiten?

Liest du den Kontext auf diesen Seiten? Betreibst du eines der wenigen kompromittierbaren Systeme?
Wenn du das nicht weist, ist die Antwort mit 99.9% Wahrscheinlichkeit nein.

 

[aluis]

Dafür ein z.b. ein VPN einzurichten schafft nicht nur neue potentielle Lücken sondern

Immer noch besser als ein offener Port. Mit tls-auth kann ein Angreifer noch nicht mal raus finden, ob auf dem Server ein VPN lauscht. Selbstverständlich kommt der VPN Dienst in einen LXC Container.

man braucht trotzdem noch eine Schnittstelle um das VPN selbst warten zu können.

Habe ich noch nie in meinem Leben gebraucht. Der VPN- und SSH-Dienst wird ja durch ein Update nicht einfach beendet.

Und man braucht dann entsprechen auch einen zweiten Server

Seit 10 Jahren ist ein Container pro Anwendung State of the Art. Macht jeder professionelle Linuxadmin so.

 

[EdwinOdesseiron]

[...]
Seit 10 Jahren ist ein Container pro Anwendung State of the Art. Macht jeder professionelle Linuxadmin so.

Das ist Quatsch. Es kommt wie immer drauf an, nicht jeder macht DevOps
Vor allen Dingen vor 10 Jahren erst recht nicht

 

[aluis]

Es kommt wie immer drauf an, nicht jeder macht DevOps

Du musst doch kein DevOps sein um einen Linuxserver vernünftig einzurichten.

Kaum einer würde RDP ins Internet hängen. Warum es für vile bei SSH auf einmal kein Problem sein soll, kann ich nicht nachvollziehen.

 

[EdwinOdesseiron]

@aluis
Die professionellen Umgebungen die ich im Laufe der Zeit kennen gelernt habe, hängen nicht am Internet - aus Sicherheitsgründen.

 

[Gendra]

Kaum einer würde RDP ins Internet hängen. Warum es für vile bei SSH auf einmal kein Problem sein soll, kann ich nicht nachvollziehen.

Weil SSH explizit für diesen Einsatzzweck ausgelegt ist, anders als RDP wo explizit auch von MS davon abgeraten wird.
Klar kann man 10 Schichten davor hängen, tatsächlich ist aber SSH so verbreitet und geprüft, das wahrscheinlich jede VPN Lösung mehr Sicherheitslücken enthält als SSH selbst.

 

[pseudopseudonym]

Aber ich will ja nicht wissen wenn Linux auch seine 20% hätte Wird viele Milliarden Bugs und Sicherheits Lücken Auftauchen würden.

Wenn man nicht nur auf den klassischen Desktop guckt, ist Linux deutlich verbreiteter als Windows. Und das nicht nur als Spielelauncher, sondern z. B. auf Servern, auf den einiges an Daten liegt und verarbeitet wird.

 

[dr. lele]

Linux hat is jetzt ja nur wegen der fast nicht Verbreitung so wenig malware

So in Produktion bei den ganzen Webdiensten, die du mit Sicherheit auch nutzt, ist Linux Marktführer. YouTube, Google, Netflix läuft alles in der Cloud auf Linux Maschinen.

In welchem Browser bist du den unterwegs, dass der nicht Open source ist? Gibt ja eigentlich keinen außer Safari und das macht glaube ich keiner auf Windows 11.

Als Handy hast du dann ein iPhone?

Du bist echt der erste, der stolz und falsch behauptet keine Open source software zu benutzen. Weirder take, und offensichtlich hast du mit der Erstellung und dem Betrieb von Software wenig am Hut.

 

[Termy]

In welchem Browser bist du den unterwegs, dass der nicht Open source ist?

Chrome, Edge, Opera? Je nachdem ob man open source und FOSS gleich setzt auch Vivaldi.

Aber ja, keiner davon kommt ohne FOSS-Komponenten aus, auch Safari nicht

 

[Zornica]

Manch Ärzte raten auch zur Chemotherapie...... ach das war nur für spezielle Krankheiten?

Liest du den Kontext auf diesen Seiten? Betreibst du eines der wenigen kompromittierbaren Systeme?
Wenn du das nicht weist, ist die Antwort mit 99.9% Wahrscheinlichkeit nein.

und so ne unnötig hochnäsige Antwort war jetzt unbedingt nötig weil?
Ich würde wohl kaum Fragen wenn ich nicht ein entsprechendes System am laufen hätte + die jeweiligen Seiten entsprechend Kontext geben würden

 

[Keylan]

Ich würde wohl kaum Fragen wenn ich nicht ein entsprechendes System am laufen hätte

Dann hätte man das in der Frage als sehr relevantes Detail erwähnen sollen. Wenn dies wirklich gegeben ist, sollte es ja ohnehin nur eine Experimentelle Umgebung sein, aber ja, so ein System hätte nach aktuellem Kenntnisstand durch einen nicht ohne weiteres nachvollziehbaren Zugriff weiter Kompromittiert werden können.
Da kann also alles möglich mit sein, oder auch gar nichts, aber es ist eine Backdoor mit Potential zur Root-Shell.

 

[aluis]

das wahrscheinlich jede VPN Lösung mehr Sicherheitslücken enthält als SSH selbst.

Was durch die erwähnte Backdoor im Artikel widerlegt ist.

 

[nöörd]

Immer noch besser als ein offener Port. Mit tls-auth kann ein Angreifer noch nicht mal raus finden, ob auf dem Server ein VPN lauscht. Selbstverständlich kommt der VPN Dienst in einen LXC Container.

Je mehr Schichten umso mehr Sicherheit? Ist das die sogenannte layered security?

Was durch die erwähnte Backdoor im Artikel widerlegt ist.

Und ein VPN hätte hier wie genau Besserung gebracht?

 

[dr. lele]

Chrome, Edge, Opera? [...] Aber ja, keiner davon kommt ohne FOSS-Komponenten aus, auch Safari nicht

Darauf hab ich abgespielt Open Source Software ist ein elementarer Bestandteil von fast allen Computerdingen die wir so tun, und das finde ich auch sehr gut so.

 

[Gendra]

Was durch die erwähnte Backdoor im Artikel widerlegt ist.

Dann hast du den Artikel nicht richtig verstanden. Die Backdoor ist in der liblzma und nicht im SSHd. Lediglich der Payload der Lücke wird nur aktiv wenn er SSH findet.

Es wäre genauso möglich gewesen Es wäre naiv anzunehmen, dass nicht von anderen Accounts wie Dimitri85 oder McJohn nicht auch vergleichbare Backdoors in ähnlichen libs (gz?!) stecken die statt auf SSH auf nginx/Apache, Openvpn o.a. abzielen.
Wer einen Angriff so lange und präzise plant, der hat mehrere Pferde im Stall.

Diese Variante ist ja nur dadurch aufgefallen das sie in einem obskuren Szenario zu einem Performanceverlust geführt hat und der Anwender versucht hat zu debuggen.

 

[SheepShaver]

VPN, Reverse Proxy u.ä. sind kein Begriff?

Auch wenn das VPN auf dem gleichen Server läuft bist du immer noch in einer bessere Situation als mit zig offen erreichbaren Diensten. Da brauchst du auch keinen extra Server für mieten

Ein aktuell gehaltener SSH Zugriff (OHNE root) über ed25519 Key kann als sicher eingestuft werden.

 

[EdwinOdesseiron]

Vor allen Dingen mit den entsprechenden Sicherheitsvorkehrungen auf der Empfängerseite.

 

[SheepShaver]

Immer noch besser als ein offener Port. Mit tls-auth kann ein Angreifer noch nicht mal raus finden, ob auf dem Server ein VPN lauscht. Selbstverständlich kommt der VPN Dienst in einen LXC Container.

Security by Obscurity? Und Containerisierung ohne Hardening der Runtime bringt an der Stelle auch 0 zusätzliche Sicherheit.

 

[mibbio]

VPN, Reverse Proxy u.ä. sind kein Begriff?

Sind mir durchaus ein Begriff, nur inwiefern ist ein Reverse Proxy von Nutzen, wenn ich das Hostsystem administrieren will?

Auch wenn das VPN auf dem gleichen Server läuft bist du immer noch in einer bessere Situation als mit zig offen erreichbaren Diensten. Da brauchst du auch keinen extra Server für mieten

Wie kommst du jetzt auf "zig erreichbare Dienste", wo es doch bisher nur um den Zugang per SSH geht? Auf meinem Server läuft nur Nginx (für statische Inhalte und als Reverse Proxy für eine REST-API im Docker Container) und gelegentlich mal ein Minecraft-Server. Die beiden Dienste sollen ja von Außen erreichbar sein, sonst wären die recht sinnfrei.
Und inwiefern ein VPN-Dienst auf dem gleichen System jetzt irgendeinen Vorteil bringt gegenüber erreichbaren SSH-Server, erschließt sich mir auch nicht so ganz.