Tag Archives: SSH

aktuelle SSH Lücke verpflastern

Posted on by

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

Posted on by

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.

 

Remote Desktop: eigene Desktopsession mit XRDP

Posted on by

Im ersten Teil der Remote-Desktop Serie geht es um XRDP. Damit kann ein entfernter Benutzer eine eigenständige Desktopsession zum Server aufbauen. Andere Benutzer des gleichen Servers können parallel dazu eine eigene Verbindung aufbauen, ohne das sich die Benutzer in die Quere kommen. Allerdings darf ein User nur einmal eingeloggt sein.

Remote Desktop: eigene Desktopsession mit XRDP

Da es sich bei der Lösung um eine eigenständige Desktopumgebung abseits vom Monitor handelt, gibt es hier keine Probleme mit Waylanddesktops. XRDP bietet eine Xorg Verbindung ohne GPU Support an, was die Auswahl der eigentlichen Desktopumgebung einschränkt.

Die Installation

Debian & Ubuntu:

sudo apt-get update && sudo apt-get upgrade && sudo apt install xrdp

Fedora:

sudo dnf install xrdp-selinux xrdp

Die Desktopumgebung

Jetzt müssen wir uns für eine Desktopumgebung entscheiden, weil es bei RDP leider keine Vorauswahl seitens des Clienten gibt. Es bieten sich GPU unabhängige Desktops wie GNOME oder XFCE4 an. Zum Glück ist das total einfach:

echo „gnome“ > ~/.xsession

oder

echo „xfce4-session“ > ~/.xsession

Dies muß jeder Benutzer selbst machen oder durch den Superuseraccount regel lassen. Was nicht funktioniert ist Cinnamon, soweit ich das bisher erlebt habe.

Die Firewall öffnen

Da sich die eingesetzten Firewalls pro Distribution stark unterscheiden, hier einige Vorschläge:

Debian & Ubuntu: sudo ufw allow 3389/tcp
Fedora: sudo firewall-cmd –permanent –add-port=3389/tcp
IP-Tables: sudo iptables -A INPUT -j ACCEPT -m tcp -p tcp –dport 3389

Von Fedora abgesehen, müßtet Ihr die Regeln permanent hinzufügen z.B. also in /etc/sysconfig/iptables eintragen.

XRDP Starten

In einer Idealen Welt, würde man nun „systemctl enable –now xrdp“ ausführen und es geht. Da leben wir aber nicht 🙂

In /etc/xrdp/sesman.ini müßtet Ihr sicherstellen, daß folgendes so drinsteht:

[Xorg]
; Specify the path of non-suid Xorg executable. It might differ depending
; on your distribution and version. Find out the appropriate path for your
; environment. The typical path is known as follows:
;
; Fedora 26 or later : param=/usr/libexec/Xorg
; Debian 9 or later : param=/usr/lib/xorg/Xorg
; Ubuntu 16.04 or later : param=/usr/lib/xorg/Xorg
; Arch Linux : param=/usr/lib/Xorg
; CentOS 7 : param=/usr/bin/Xorg or param=Xorg
; CentOS 8 : param=/usr/libexec/Xorg
; FreeBSD (from 2022Q4) : param=/usr/local/libexec/Xorg
;
param=/usr/libexec/Xorg
; Leave the rest parameters as-is unless you understand what will happen.
param=-config
param=xrdp/xorg.conf
param=-noreset
param=-nolisten
param=tcp
param=-logfile
param=.xorgxrdp.%s.log

[Xvnc]
param=Xvnc
param=-bs
param=-nolisten
param=tcp
param=-localhost
param=-dpi
param=96

Damit erklärt sich auch, wieso es kein Waylandproblem mit XRDP gibt, es wird ja nicht benutzt 😉

Jetzt können wir das starten: systemctl enable –now xrdp

Mein Tip

… Ja, ich bin alt, ich schreibe Tip noch einem p :þ… können wir dann? Mein Tip für Euch: enabled es nicht per se.

Ihr könnt den Server auf 127.0.0.1 binden lassen, dann kommt Ihr nur per SSH-Tunnel oder lokal drauf. Letzteres wäre für ein „REMOTE“ Desktoptool ja eigentlich völlig unsinnig, aber es gibt Spezialfälle:

Wenn man z.B. Desktopprogramme für Spezialuser, wie einen spezialisierten Online-Bankingaccount, benutzen möchte, dann kann man sich per RDP einfach einloggen ohne den Benutzer wechseln zu müssen. Das kann z.b. auch nützlich sein, wenn man eine kleine Linux Internetshow betreibt und mit einem Nicht-Admin-User mal was zeigen will oder auch, um als Root mit einem Desktoptool etwas zu machen. Möglichkeiten dies zu verwenden gibt es viele.

Im Normalfall sollte man sich von außen auch nicht direkt per RDP einloggen können, sondern immer über einen sicheren SSH Tunnel gehen, denn RDP authentifiziert gegen PAM und das benutzt im Vergleich zu OpenSSH-Schlüsseln, schwache Passwörter als Schutz. Da ist ein OpenSSH-Schlüssel jederzeit vorzuziehen.

Vermeiden lässt sich eine direkte Erreichbarkeit nicht, wenn man im Netz einen Server betreibt, der für Benutzer per RDP erreichbar sein muß. XRDP kann hier insofern für etwas Sicherheit sorgen, wenn Rootzugriffe verboten sind. Aber auch im Netz kann ich allen Beteiligten nur dazu raten, z.b. auf VPNs zu setzen oder einen SSH-Tunnel zu nutzen. Bei den ganzen Kriminellen da draußen, muß man wirklich jede Schutzschicht aktivieren, die geht.