Linux am Dienstag – Programm für den 29.4.2025

Diesmal bei Linux am Dienstag schauen wir uns mal Nvidia Treiberprobleme an und klappen das nächste Kapitel Advanced SSH auf.

Linux am Dienstag – Programm für den 29.4.2025

u.a. im Programm am 29.4.2025, ab 19 Uhr :

Linux – Advanced SSH – Restriktiver Zugriff (Marius)
Linux – Manjaro Update bringt neue Desktopversionen
Linux – Kritische Lücke in Tails
KI – Google zahlt Unsummen um seine KI Bots zu plazieren
KI – ChatGPT baut Exploit, was explizit nicht gehen sollte

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .
Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

aktuelle SSH Lücke verpflastern

Updaten ist immer gut wenn Sicherheitslücken geschlossen werden sollen, aber in der Realität kommt es vor, daß Dienste nicht immer (gleich) das Update bekommen, daß Sie benötigen.

aktuelle SSH Lücke verpflastern

Die aktuelle SSH Lücke wirft auf allen möglichen Geräten mit verwundbarer Version ein Problem auf, wenn dieses keine Updates erhält, denn ohne SSH kommt man nicht mehr auf dies Gerät drauf und davon hat keiner was. Solange das Gerät die SSH Schnittstelle ins LAN öffnet, mag ein Nicht-Patchen noch eine kalkulierbare Lösung sein.

Wenn das Gerät aber ins Netz zeigen muß, dann wäre es das Aus, wenn es kein Update gibt, oder gibts da doch was, was man machen könnte?

Das Qualsys Pflaster

Wenn Ihr Nachts um halb eins im Bett von der Lücke gehört hättet, hättet Ihr Euch auch den Qualsys Bericht dazu durchgelesen, der entscheidet dann darüber, ob man sich final hinlegen kann, oder ob eine Nachtschicht eingelegt werden muß.

In dem Bericht stand u.a. drin, daß man ca. 1 Woche hat, bis der Angreifer mit dem Angriff mal Erfolg haben wird. Darauf kann man sich leider nicht ausruhen, weil das nur ein Statistischer Wert ist, der zufällig auch schon beim ersten mal funktionieren kann.

Am Ende stand aber noch etwas anderes, nämlich daß man einfach „LoginGraceTime 0“ setzen kann, dann läuft der Angriff komplett ins Leere, dafür kauft man sich eine Pseudo-DOS Schwachstelle ein, spricht, Angreifer könnten beim rumprobieren die Leitung dicht machen, so daß es schwierig wird ins System einzuloggen. Natürlich ist das immer noch besser, als wenn jeder leidlich lästige Kleinkriminelle auf dem System Rootzugriff haben kann. PS: SSHD Neustart nicht vergessen 😉

Leider habe ich in keinem News- oder Blogbeitrag gelesen, daß es diese Möglichkeit gab.

Fedora hat’s mal wieder verpeilt

Ein bisschen enttäuscht war ich vom zeitlichen Verlauf der Fedora Updates von OpenSSH, denn die platzten mitten in Linux am Dienstag rein,was extrem verstörend war, weil die OpenSSH Patche selbst bereits seit 4 Wochen an die Distributionen übermittelt waren. Die Fedora Maintainer hatten mal wieder völlig verpeilt, ein CritPath Update einer schweren Sicherheitslücke zu verteilen. Nicht zum ersten mal, möchte ich betonen. Da muß man echt hinterher sein manchmal.

Link zur Lücke: CVE-2024-6387

Link zur Quelle: Qualsys Bericht

CNR: Hetzner Mailsperre umgehen

Wer eine neue Serverinstanz bei Hetzner aufzieht, der wird bemerken, daß er keine Emails versenden kann.

CNR: Hetzner Mailsperre umgehen

Hetzner sperrt ausgehenden Port 25 Verkehr an deren Firewall. Das ist eine Reaktion auf Menschen, die dort eine VM aus dem Boden stampfen und dann zum Spammen missbrauchen, aber nie vorhatten für die Instanz zu zahlen. Euch trifft das leider auch, außer Ihr habt beim Linux am Dienstag Advanced SSH Training teilgenommen 😀

In diesem Fall ist die Lösung für Euch einfach:

Wir tunneln uns SMTP einfach zu einem anderen Server!

Auf dem ZIELServer, also dem, der die Mails dann am Ende versenden soll, geben wir das ein:

ssh -NCTf -R 127.0.0.2:25:127.0.0.1:25 root@hetzner.vm

Natürlich darf auf dem Hetznerserver kein SMTP laufen, sonst können wir uns dort nicht ungestört auf Port 25 binden.

Wenn Ihr so Mails versendet, dann denkt an den SPF Eintrag, der muß dann nämlich mehr als nur „a mx“ enthalten. Ich empfehle die Methode aber ohnehin nur für Utilityserver. Wollte Ihr dort auch Mails empfangen, dann wirds mit dem Portbinden lustig 😉 Hier wär es dann besser, abhängig von der Mailserversoftware einen Smarthost mit einem nicht-Standart-Port zu benutzen, weil die sind von der Firewallsperre nicht betroffen.

SSH ist hier nur deutlich weniger Aufwand als so ein !=25 Smarthost.