xz-utils supply-chain attack : Scan nach Versionen

Leider wurde heute ein cve für die xz-utils veröffentlicht. Hier wurde eine supply-chain attack durchgeführt und schadhafter Code eingeschleust.
https://www.tenable.com/blog/frequently-asked-questions-cve-2024-3094-supply-chain-backdoor-in-xz-utils

Ich hab dann meine Server durch gescannt nach verwundbaren Versionen. Hier das ansible-playbook dazu.
---
- name: Scan for xz-utils and output Version
  hosts: all
  become: true
  gather_facts: true
  tasks:
    - name: Get Packages
      ansible.builtin.package_facts:
        manager: apt
      register: packages
    - name: scan for xz-utils
      ansible.builtin.set_fact:
        xz_ver: "{{ packages.ansible_facts.packages['xz-utils'][0].version }}"
    - name: ouput Package Version
      ansible.builtin.debug: 
        var: xz_ver

Der Output sieht dann so aus :
TASK [ouput Package Version] ******************
 ok: [HOSTNAME] => { "xz_ver": "5.4.1-0.2" }
 ...

Links:
https://www.tenable.com/cve/CVE-2024-3094
https://lists.debian.org/debian-security-announce/2024/msg00057.html
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

Debian 12 : ssh absichern mit port knocking

Eins Vorweg Port Knocking ist kein 100% Schutz für den ssh Dienst , eine saubere Konfiguration ist notwendig. Was man aber damit erreicht ist das Portscanner diesen Port als nicht offen sehen. Somit hat man schon mal einen Teil der Angriffe weggefiltert. Hat der Angreifer jedoch die Möglichkeit den Traffic zwischen Client und Server mitzuschneiden kommt er früher oder später auf die Sequenz und kann den Port öffnen.
Verwendet hier keine fortlaufende Ports und mischt am besten die Protokolle.Wenn ein Portscan auf den Server ausgeführt wird ist sonst die Gefahr zu groß das durch Zufall die Sequenz getroffen wird.
Ich habe das einfach mal aus Interesse eingerichtet und getestet, und es funktioniert ;-)

Installation von knockd (Server und Client)
apt install knockd
Installation von iptables (Server)
apt install iptables iptables-persistent
Konfiguration des knockd (Server)

Die Konfiguration des knock Daemon (knockd) wird in der Datei /etc/knockd.conf und /etc/default/knockd durchgeführt.

In der Datei /etc/default/knockd ändern wir die Startart und definieren die KNOCKD_OPTS.
...
START_KNOCKD=1
KNOCKD_OPTS="-i enp0s3"
enp0s3 ist hier der Networkinterface Name.
START_KNOCKD=1 sorgt dafür das der Daemon beim Systemstart mit gestartet wird.

Jetzt kümmern wir uns um die Datei /etc/knockd.conf und schließen die Konfiguration ab.
[options]
        logfile = /var/log/knockd.log

[openSSH]
        sequence    = 8000,7000,9000,2123:udp
        seq_timeout = 5
        command     = /usr/sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,7000,8000,2123:udp
        seq_timeout = 5
        command     = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn
Alle Konfigurationsmöglichkeiten kann man sich mit man knockd anschauen (und es gibt viele). Für das Beispiel hier verwende ich eine rudimentäre Konfiguration. Die Ports die unter Sequenz (sequence) angegeben sind muss man nacheinander "anklopfen" dann wird das command ausgeführt. Hier sieht man das iptables den Client auf den SSH Port freigibt. Und eben wieder entfernt wenn die Sequenz für closeSSH übergeben wird.
Nachdem die Konfiguration abgeschlossen ist muss der Dienst aktiviert und gestartet werden.
systemctl enable knockd && systemctl start knockd
Jetzt bereiten wir die Firewall für den Einsatz vor. Hiermit erstellen wir eine Regel das vorhandene Verbindungen nicht getrennt werden
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
in der folgenden Regel verbieten wir die Connection auf den Port 22
iptables -A INPUT -p tcp --destination-port 22 -j DROP
jetzt wird das ganze noch gespeichert das es einen reboot überlebt
iptables-save > /etc/iptables/rules.v4
Wenn ihr euch jetzt den Server einmal mit nmap anschaut, natürlich von einem anderen Client, ist der Port geschlossen.

Ruft man jetzt knock auf dem Client mit der richtigen Sequenz auf wird der Port geöffnet
knock SERVERIP 8000 7000 9000 2123:udp
das kann man auch wieder schön mit nmap ermitteln.


Im Logfile von knockd sieht das ganze dann so aus. Im ersten Block wurde die Sequenz richtig angegeben und somit der Client zugelassen. Im zweiten Block wurde die Sequenz richtig angegeben und der Port wurde wieder geschlossen.

Debian 12 : System Härten - Allgemein

Einige der folgenden Einstellungen sind auch bereits in der Default Einstellung so. Da ich aber ein Set von Parametern für all meine Linux Systeme verwende setze ich diese nochmal explizit in einer config. Erstmal legen wir uns ein Backup der Default Config an
sudo sysctl -a > /tmp/default_sysctl.txt
dann legen wir die Datei /etc/sysctl.d/97_hard.conf an und kopieren folgende Zeilen rein.
Die Erklärung zu den jeweiligen Konfiguration kann unter dem Link in der Quellenangabe nachgelesen werden.
Auch hier gilt wieder die Einstellungen müssen zu der eingesetzten Software kompatible sein.
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2
dev.tty.ldisc_autoload=0
vm.unprivileged_userfaultfd=0
kernel.kexec_load_disabled = 1
kernel.sysrq=4
kernel.unprivileged_userns_clone=0
kernel.perf_event_paranoid = 3
kernel.yama.ptrace_scope=2
vm.mmap_rnd_bits=32
vm.mmap_rnd_compat_bits=16
fs.protected_symlinks=1
fs.protected_hardlinks=1
fs.protected_fifos=2
fs.protected_regular=2
Nach einem Neustart werden die Kernelparameter aktiv, wer nicht solange warten möchte kann diese mit
service procps force-reload
sofort einlesen.
Quelle :
https://www.kernel.org/doc/html/latest/admin-guide/sysctl/

Debian 12 : System Härten - Netzwerk

Über Kernelparameter kann die Sicherheit des Systems noch etwas verbessert werden.
Wichtig ist das die Einstellungen zu der eingesetzten Software passen !
Ein OpenVPN Server z.B. würde mit den folgenden Einstellungen nicht laufen. Ein Apache Webserver hingegen schon.
Erstmal legen wir uns ein Backup der Default Config an
sudo sysctl -a > /tmp/default_sysctl.txt
dann legt man diese Datei an (sollte sie nicht bereits existieren) /etc/sysctl.d/98_ip.conf und fügt diese Zeilen ein.
net.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv4.conf.all.log_martians=1
net.ipv4.conf.default.log_martians=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv6.conf.all.forwarding=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.all.accept_ra=1
net.ipv6.conf.default.accept_ra=1
Nach einem Neustart werden die Kernelparameter aktiv, wer nicht solange warten möchte kann diese mit
service procps force-reload
sofort einlesen. Hier kann nachgelesen werden was hier überhaupt konfiguriert wurde. ip-sysctl.txt

Debian 12 : MFA für ssh/su/sudo aktivieren

Unter Windows ist es recht einfach einen MFA Schutz zu realisieren. Hier haben wir Windows Hello oder das Azure AD das uns das abnimmt.
Für den Mac gibt es TouchID aber für Linux muss man hier selbst etwas bauen.

Installation des benötigten Pakets
apt install libpam-google-authenticator -y
Konfigurieren von libpam-google-authenticator
google-authenticator
Jetzt kommen einige Fragen zur Konfiguration
Do you want authentication tokens to be time-based (y/n) y
An dieser Stelle wird der QR Code Angezeigt, dieser kann kann jetzt gescannt werden und in der Authenticator App deiner Wahl eingepflegt werden. Und dann gehts weiter mit folgenden Fragen
Do you want me to update your "/chris/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) n

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

Jetzt ist die Konfiguration abgeschlossen. Der Zeitpunkt ist gekommen in der wir die zu sichernden Dienste konfigurieren.
Hier als Beispiel ssh

Öffnen der Datei /etc/pam.d/common-auth und das PAM Modul aktivieren.
Dazu diese Zeilen einfügen in der config einfügen.
# google mfa
auth required pam_google_authenticator.so nullok
Nachdem alle User die Konfiguration durchlaufen haben muss nullok aus der Zeile entfernt werden. Das sorgt dafür das nur noch User mit MFA eine Authentifizierung möglich ist.


Und jetzt noch die Datei /etc/ssh/sshd_config anpassen.
KbdInteractiveAuthentication yes
UsePAM yes
Jetzt noch den sshd Service neu starten und wir müssen uns mit einem MFA Token anmelden.
systemctl restart sshd


Noch sicherer wäre das ganze wenn man das Login auf pubkey umstellt. Hierzu muss VOR der Einrichtung ein Pubkey erzeugt und hinzugefügt werden. Dann kann man in der Datei /etc/pam.d/sshd den Part @include common-auth auskommentieren (# davor) und danach die Zeilen einfügen.
# google mfa
auth required pam_google_authenticator.so
Hintergrund ist das wir hier das common-auth modul deaktivieren , dieses ist für die Passwort Anmeldung zuständig. Wechseln wir auf das Pubkey Verfahren wird dieses Modul nicht mehr angezogen , was die Einstellung die oben erwähnt wurde deaktivert.

Da wir die Einstellungen im common-auth Modul setzen sind alle Dienste davon betroffen die dieses verwenden. d.h. jetzt sind alle Dienste über MFA abgesichert die dieses PAM Modul verwenden.

[ PROXMOX ] - Debian 11 schlechte Performance beim SSH Login

Ich habe festgestellt das wenn man einen LXC mit Debian 11 auf einem Proxmox laufen lässt, die Performance auf ssh ziemlich schlecht ist. Auch sudo dauert ziemlich lange (wenn man es verwendet)

Das liegt am Service systemd-logind wenn man diesen deaktiviert hat man wieder die gewohnte Performance.

Um zu verifizieren ob es an diesem Service liegt , grept einfach mal nach 'org.freedesktop.login1' in der Datei /var/log/auth.log
grep 'org.freedesktop.login1' /var/log/auth.log
wenn ihr dort Einträge findet, die wie folgt aussehen, liegt es vermutlich an diesem Dienst.
Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Problem wird dann mit diesen Befehl behoben (muss als root ausgeführt werden)
systemctl mask systemd-logind && pam-auth-update
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)