Hope This Helps

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

Manchmal kann es vorkommen das unter Proxmox ein Node nur ein graues Ausrufezeichen zeigt. Das ist meistens auf einen Fehler mit dem Storage zurückzuführen. In meinem Fall hatte ich testweise den Proxmox Backup Server virtualisiert, das Storage kann dann beim booten nicht verbunden werden und sorgt für einen Fehler, daraus resultiert das graue Ausrufezeichen.

Ein Neustart des Dienstes pvestatd auf dem betroffenen Node hat den Fehler behoben und der Node wurde grün

systemctl restart pvestatd.service

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. 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.

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.

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/

Über Kernelparameter kann die Sicherheit des Systems noch etwas verbessert werden.
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

In einem diesem Artikel habe ich erklärt wie man mfa für ssh konfiguriert. Jedoch ist hier noch der Zugriff aus allen IP Ranges möglich (solange die FW nicht anderweitig konfiguriert ist).

Es gibt die Möglichkeit den Zugang in den den beiden Dateien /etc/hosts.allow und /etc/hosts.deny einzuschränken.

Ich gehe mal davon aus das das Netzwerk die Mask 192.168.10.0/24 verwendet. Um jetzt nur Rechner aus dem Netzbereich eine ssh Verbindung zu ermöglich trägt man in die Datei /etc/hosts.allow folgende Werte ein. Die Loopback Adressen sind aus Gründen der Kompatibilität mit aufgeführt.

sshd: 192.168.10.
sshd : localhost
sshd : 127.0.0.1
sshd : ::1

und in der Datei /etc/hosts.deny kann man Verbindungen die auf den ssh Deamon von allen anderen Adressen verbieten. Das erreicht man mit diesem Eintrag :

sshd: ALL