Linux Server Sicherheit Kursnotizen September 2024 (Rocky Linux 9)

• In der Datei /etc/pam.d/system-auth wird die Stärke der Benutzer-Passwörter angepasst. Eine Änderung in dieser Datei wirkt sich nur auf alle neu gesetzten Passwörter aus, alle schon vorher vergebenen Passwörter bleiben mit der vorherigen Einstellung bestehen. D.h. nach einer Änderung dieses Parameters sollten wichtige Passwörter neu vergeben werden.

[...]
password    [success=1 default=ignore]    pam_unix.so obscure sha512 rounds=1000000
[...]

• yescrypt Passwörter werten das Feld logarithmisch aus und speichern anders ab

[...]
password    [success=1 default=ignore]    pam_unix.so obscure yescrypt rounds=11
[...]

• yescrypt mit der Spezifikation yescrypt v2 ist weit verbreitet und das Standard-Passwort-Hashing-Schema für aktuelle Versionen der wichtigsten Distributionen wie Debian 11, Fedora 35+, Kali Linux 2021.1+ und Ubuntu 22.04+. Außerdem wird es von Fedora 29+ und RHEL 9+ unterstützt. Dennoch unterstützen viele Standard-Tools yescrypt noch nicht.
  • Beim Update von Linux Distributionen werden die Passwörter nicht neu mit den besseren Algorithmen gehashed (das geht technisch nicht, da das Original-Passwort nicht vorliegt). Um die Vorteile der neuen Passwort-Hashing-Algorithmen wie yescrypt benutzen zu können, müssen die Passwörter neu gesetzt werden.
• yescrypt Dokumentation: https://github.com/openwall/yescrypt/blob/main/README

• Unix/Linux Systeme erlauben Gruppenpasswörter. Ein Gruppenpasswort erlaubt es einem oder mehreren Benutzern temporär die Gruppenzugehörigkeit zu wechseln, ohne permanentes Mitglied einer Gruppe zu sein
• Ein Benutzer kann mittels des Befehls newgrp die Gruppenzugehörigkeit wechseln
• Die Gruppenpasswörter werden mit dem Befehl gpasswd gesetzt und verwaltet
• Gruppenpasswörter werden in den Dateien /etc/group und /etc/gshadow gespeichert. /etc/group enthält Gruppeninformationen und /etc/gshadow enthält das Passwort (als Hash)
• Die Sicherheit der Gruppenpasswörter werden in der Datei /etc/login.defs festgelegt. Wenn Gruppenpasswörter benutzt werden, wird empfolen diese Werte mit der PAM-Konfiguration für Account-Passwörter gleich zu halten.

ENCRYPT_METHOD SHA512
SHA_CRYPT_MIN_ROUNDS 500000
SHA_CRYPT_MAX_ROUNDS 1000000

• Das Programm sudo (oder ähnlichen Erweiterungen des Linux-Systems) kann die Gruppenpasswörter ersetzen und bietet in der Regel eine bessere Kontrolle über die Rechteerweiterungen der Benutzer und ist daher den Gruppenpasswörtern vorzuziehen

• Die Benutzerinformationen für die Passwortanmeldung unter Unix/Linux werden in der Datei /etc/shadow gespeichert

• Der Befehl sudo löscht oder ersetzt kritische Umgebungs-Variablen, welche (bekannte) Auswirkungen auf die Sicherheit von Kommandos und Programmen haben.
• Der Befehl sudo -V zeigt an, welche Umgebungsvariablen entfernt, geprüft oder neu gesetzt werden:

# sudo -V
[...]
Ignore '.' in $PATH
[...]
Always set $HOME to the target user's home directory
[...]
Environment variables to check for safety:
        TZ
        TERM
        LINGUAS
        LC_*
        LANGUAGE
        LANG
        COLORTERM
Environment variables to remove:
        *=()*
        RUBYOPT
        RUBYLIB
        PYTHONUSERBASE
        PYTHONINSPECT
        PYTHONPATH
        PYTHONHOME
        TMPPREFIX
        ZDOTDIR
        READNULLCMD
        NULLCMD
        FPATH
        PERL5DB
        PERL5OPT
        PERL5LIB
        PERLLIB
        PERLIO_DEBUG
        JAVA_TOOL_OPTIONS
        SHELLOPTS
        BASHOPTS
        GLOBIGNORE
        PS4
        BASH_ENV
        ENV
        TERMCAP
        TERMPATH
        TERMINFO_DIRS
        TERMINFO
        _RLD*
        LD_*
        PATH_LOCALE
        NLSPATH
        HOSTALIASES
        RES_OPTIONS
        LOCALDOMAIN
        CDPATH
        IFS
Environment variables to preserve:
        XAUTHORITY
        _XKB_CHARSET
        LINGUAS
        LANGUAGE
        LC_ALL
        LC_TIME
        LC_TELEPHONE
        LC_PAPER
        LC_NUMERIC
        LC_NAME
        LC_MONETARY
        LC_MESSAGES
        LC_MEASUREMENT
        LC_IDENTIFICATION
        LC_COLLATE
        LC_CTYPE
        LC_ADDRESS
        LANG
        USERNAME
        QTDIR
        PS2
        PS1
        MAIL
        LS_COLORS
        KDEDIR
        HISTSIZE
        HOSTNAME
        DISPLAY
        COLORS
[...]

• Befehl cat auf die Datei /var/log/kdump.log für Benutzer user

visudo -f /etc/sudoers.d/kdump-cat
----
user ALL=(root) /bin/cat /var/log/kdump.log
----
nutzerXX$ sudo -l

• sudo -l Zeigt die sudo-Konfiguration und die erlaubten Befehle eines sudo-Benutzers an.

• Erstelle eine sudo Konfiguration, um es dem Benutzer user zu erlauben, die Logdateien /var/log/messages und /var/log/kdump.log unter den Benutzerberechtigungen des Benutzers root mit den Programmen more und less anzuschauen

visudo -f /etc/sudoers.d/log-message-view
------
...
user  ALL=(root) /usr/bin/more /var/log/messages
user  ALL=(root) /usr/bin/more /var/log/kdump.log
user  ALL=(root) /usr/bin/less /var/log/messages
user  ALL=(root) /usr/bin/less /var/log/kdump.log
...

• In der sudo Konfigurationen können Alias Definitionen die Komplexität der Konfiguration verringern. Aliase erlauben es mehrere Rechner, Benutzer oder Kommandos hinter einem sprechendem Namen zusammenzufassen

     # User alias specification
     User_Alias      FULLTIMERS = millert, mikef, dowdy
     User_Alias      PARTTIMERS = bostley, jwfox, crawl
     User_Alias      WEBMASTERS = will, wendy, wim

     # Runas alias specification
     Runas_Alias     OP = root, operator
     Runas_Alias     DB = oracle, sybase
     Runas_Alias     ADMINGRP = adm, oper

     # Host alias specification
     Host_Alias      SPARC = bigtime, eclipse, moet, anchor :\
                     LINUX = grolsch, dandelion, black :\
                     LINUX_ARM = widget, thalamus, foobar :\
                     LINUX_PPC64 = boa, nag, python
     Host_Alias      CUNETS = 128.138.0.0/255.255.0.0
     Host_Alias      CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0
     Host_Alias      SERVERS = master, mail, www, ns
     Host_Alias      CDROM = orion, perseus, hercules

     # Cmnd alias specification
     Cmnd_Alias      KILL = /usr/bin/kill, /usr/bin/pkill
     Cmnd_Alias      PRINTING = /usr/sbin/lpc, /usr/bin/lprm
     Cmnd_Alias      SHUTDOWN = /usr/sbin/shutdown
     Cmnd_Alias      HALT = /usr/sbin/halt
     Cmnd_Alias      REBOOT = /usr/sbin/reboot
     Cmnd_Alias      SHELLS = /usr/bin/sh, /usr/bin/zsh, /bin/bash

FULLTIMERS  SPARC=(OP) KILL
WEBMASTERS  LINUX=(:ADMINGRP) SHELLS

• Benutzer user soll die Datei /etc/rsyslog.conf editieren dürfen. Diese Datei darf nur mit Rechten des Benutzers root geschrieben werden. Bei der Benutzung von sudoedit wird die Datei unter Root-Rechten in eine temporäre Datei kopiert und die Datei wird mit einem Editor unter den Rechten des Benutzers geöffnet. Herbei werden die Sicherheitsrisiken durch die Ausführung von komplexen Editoren wie vim oder emacs (z.B. Shell-Funktionen der Editoren) vermieden
• In der Datei /etc/sudoers

visudo
----
user ALL= sudoedit /etc/rsyslog.conf
----
sudoedit /etc/rsyslog.conf

• Die Funktion sudoreplay erlaubt es die Ein-und Ausgabe einer Sudo-Sitzung mitzuschneiden und zu einem späteren Zeitpunkt wieder abzuspielen.
• Füge die folgenden Konfigurationszeilen in die /etc/sudoers Datei ein

Defaults log_output
Defaults!/usr/bin/sudoreplay !log_output
Defaults!/sbin/reboot !log_output

• nutzerXX darf root werden

nutzerXX ALL=(root) ALL

• Benutze sudo als nutzerXX um eine interaktive Shell zu bekommen

nutzerXX$ sudo -s

• ein paar Befehle ausführen, die Ausgaben produzieren
• die sudo Root-Shell wieder verlassen
• (im Terminal als Benutzer root) Aufgezeichnete Sitzungen auflisten

sudoreplay -l

• aufgezeichnete sudo Sitzung abspielen

sudoreplay <TSID>

• Verzeichnis der sudo Aufzeichnungen:

ls -l /var/log/sudo-io/

• In der sudo Konfigurationsdatei können Programme mittels eines kryptografischen Hash gesichert werden. Das sudo Programm prüft vor einem Aufruf mit sudo ob der Hash der Programmdatei noch mit dem in der Konfiguration hinterlegten Wert übereinstimmt und verhindert bei einem Unterschied die Ausführung des Befehls
• Mit dieser Funktion lässt sich eine einfache Intrustion-Detection (z.B. zum Aufspüren von Root-Kits) implementieren. Jedoch müssen nach jedem Update des Systems ggf. die Hashes in der Sudo-Konfigurationsdatei aktualisiert werden

openssl dgst -sha256 /usr/bin/passwd
SHA256(/usr/bin/passwd)= a92b1b6fb52549ed23b12b32356c6a424d77bcf21bfcfbd32d48e12615785270
visudo
----
nutzerXX ALL= sha256:a92b1b6fb52... /usr/bin/passwd
----

• Sudo kann ein eingegebenes Passwort für eine bestimmte Zeit im Speicher zwischenspeichern. Hierdurch werden wiederholte Passwort-Eingaben bei mehreren Sudo-Befehlen vermieden.
• Das Caching-Verhalten von sudo kann in der Sudo-Konfigurationsdatei eingestellt werden:

Defaults passwd_tries=5, passwd_timeout=2
Defaults timestamp_timeout=0 # Disable password caching
Defaults timestamp_timeout=5 # 5 Minuten password caching (default)

• sudo kann Befehle ohne die Eingabe eines Passworts ausführen. Dies ist speziell für automatische Skripte welche z.B. via SSH ausgeführt werden interessant.

nutzer ALL=(dba) NOPASSWD: /opt/oracle/bin/befehl

• Passwortlose sudo Befehle können ein Sicherheitsrisiko sein und sollten auf bestimmte Befehle begrenzt werden. Automatisch via SSH ausgeführte sudo Befehle sollten auch auf der SSH-Seite durch ACLs begrenzt werden (siehe Kapitel zu ssh).

• Einige Linux-Distributionen (z.B. SUSE Linux) verlangen bei der Benutzung von sudo das Passwort dies Ziel-Accounts (z.B. root) anstatt des Passwort des Quell-Accounts (des Benutzers).

Defaults targetpw

• In dieser Konfiguration arbeitet sudo funktionell ähnlich wie der su Befehl

• Es gibt ein PAM-Modul, welches allen normalen Benutzern die Anmeldung am System verweigert. Nur der root Benutzer darf sich dann anmelden.
• Dieses PAM-Modul ist schon für den Dienst login konfiguriert, aber nicht aktiv (Datei /etc/pam.d/login)
• Lese die Man-Pages der PAM-Module für den Dienst login der account-Funktionen, finde heraus, welches Modul das Login aller Nicht-Root-Benutzer verweigern kann, und wie es aktiviert wird.
• Aktiviere diese Funktion und teste diese aus. Wechsle mit STRG+ALT+F2 auf die Text-Konsole und versuche Dich dort mit dem normalen Benutzer anzumelden. Alternativ: Anmeldung per SSH über das Loopback-Interface:

ssh user@localhost

• Wie kann einem normalen Benutzer der Grund für den Fehlschlag des Anmeldeversuches mitgeteilt werden?

• Das gesuchte Modul heist pam_nologin.so, aktiviert durch die Datei /etc/nologin:

echo 'Heute kein Login möglich! Wartungsarbeiten bis Dienstag!' > /etc/nologin

• Bei RedHat EL System befindet sich das OATH Modul in den EPEL Repositories (Extra Pakets for Enterprise Linux). Das EPEL Repository kann über das Paket epel-release aktiviert werden (ggf. Richtlinien zur Installation von Programmen aus externen Quellen beachten)

dnf install epel-release

• RFC 4226 HOTP: An HMAC-Based One-Time Password Algorithm (https://tools.ietf.org/html/rfc4226)
• Alternative: RFC 6238 "TOTP: Time-Based One-Time Password Algorithm"
• Token-Software als App für viele Mobiltelefone verfügbar
• Pakete installieren

dnf install pam_oath oathtool

• Wir erstellen einen neuen Benutzer, an welchem wir die Funktion testen können

root$ adduser -m nutzer
root$ passwd nutzer

• pam_oath in die PAM Konfiguration aufnehmen (hier für den su Befehl). window=5 gibt ein Fenster von 5 Passwörtern aus der Liste an, welche akzeptiert werden.

$EDITOR /etc/pam.d/su
-----
#%PAM-1.0
auth            sufficient      pam_rootok.so
auth            requisite       pam_oath.so usersfile=/etc/oath/users.oath window=5
-----

• OATH Benutzerdatei anlegen inkl. Seed-Werte um den Startwert zu setzen

mkdir /etc/oath
$EDITOR /etc/oath/users.oath
-----
HOTP nutzer   - <hex-secret>
HOTP nutzerYY - 0102030405

• Beispiel: Passwort in HEX-Zahl (Seed) umrechnen:

echo "villa" | od -x
0000000 6976 6c6c 0a61
0000006

• Benutzerrechte setzen

chmod 000 /etc/oath/users.oath
chown root: /etc/oath/users.oath

• Eine Reihe (5 Stück) von Passwörter zum Test erstellen

oathtool -w 5 <hex-secret>

• Anmeldung ausprobieren als "user", eines der Passwörter aus der Liste probieren

su - nutzer

• Wer ein Smart-Phone hat, mal im App-Store nach "OATH" suchen, eines OATH-Token Programm installieren und konfigurieren

• PAM Duress (https://github.com/nuvious/pam-duress) ist ein interessantes PM-Modul welches es dem Benutzer erlaubt, alternative Passwörter im PAM zu hinterlegen. Diese Passwörter sind jeweils mit einen Shell-Skript verbunden. Wird eines der "Duress" Passwörter statt dem "normalen" Benutzerpasswort eingegeben, so wird das dazugehörige Script ausgeführt.
• Beschreibung der Einsatzszenatrien von der Projekt-Webseite

  Diese Funktion könnte genutzt werden, um jemandem, der unter [Zwang] zur Eingabe eines Kennworts gezwungen wird, die Möglichkeit zu geben, ein Kennwort einzugeben, das den Zugang gewährt, aber im Hintergrund Skripte ausführt, um sensible Daten zu bereinigen, Verbindungen zu anderen Netzwerken zu schließen, um lateral movement einzuschränken, und/oder eine Benachrichtigung oder einen Alarm zu senden (möglicherweise mit detaillierten Informationen wie Standort, sichtbaren WLAN-Hotspots, einem Bild von der Kamera, einem Link zu einem Stream vom Mikrofon usw.). Es kann sogar einen Prozess starten, um das Modul pam_duress zu entfernen, damit der Bedrohungsakteur nicht sehen kann, ob das PAM-Duress verfügbar war.

• Weitere Einsatzgebiete:
  • Wegwerfbare Gast-Zugänge einrichten
  • Automatisches protokollieren einer Sitzung per "sudo" beim Login einschalten
  • MacOS "Find-my-Mac" nachbauen (gestohlene Rechner orten)

• Understanding the effects of PAM module results ('controls' in PAM jargon) https://utcc.utoronto.ca/~cks/space/blog/sysadmin/PAMModuleResultsEffects
• A Linux PAM setup and the problem of stopping authentication https://utcc.utoronto.ca/~cks/space/blog/linux/PAMStackingAndStopping
• TOTP authenticator implement as a terminal tool https://github.com/MinaOTP/MinaOTP-Shell
• Minimal TOTP generator in 20 lines of Python https://github.com/susam/mintotp
• Using a Yubikey as a touchless, magic unlock key for Linux https://kliu.io/post/yubico-magic-unlock/
• Windows Hello™ style facial authentication for Linux https://github.com/boltgolt/howdy

• Audit-Subsystem anschalten

audit=[0|1]

• wenn audit nicht gesetzt ist, dann wir das Audit-Subsystem erst mit dem Starten des Audit-Daemon auditd aktiv
• Wert 0 – Audit-Subsystem ist ausgeschaltet
• Wert 1 – Audit-Subsystem wird sofort aktiv, der Kernel sammelt Audit Informationen und übergibt diese an den Audit-Daemon, sobald dieser gestartet ist

apparmor=[0|1]

• AppArmor an/ausschalten

• SELinux an/ausschalten

selinux=[0|1]

• SELinux Regeln durchsetzen (enforcing)

enforcing=[0|1]

• Wert 0 = SELinux im permissive Modus
• Wert 1 = SELinux im enforcing Modus

module.sig_enforce

• wenn gesetzt, können nur Kernel-Module mit einer gültigen Signatur geladen werden

noexec=[on|off]

• bei 32bit PAE Kerneln, schaltet Schreibschutz auf Daten-Speicherseiten an

no_file_caps

• Schaltet die Datei-Capabilities aus

nomodule

• es können keine Module nachgeladen werden

panic=<timeout>

• Wert > 0 - Sekunden bis zum Reboot
• Wert = 0 - kein Reboot (* aus Sicherheitsgründen empfohlen)
• Wert < 0 - sofortiger Reboot

• Übersicht- sysctl Parameter-Tuning: https://klaver.it/linux/sysctl.conf

sysctl -a

• Permanente sysctl Einstellungen in /etc/sysctl.conf.d

kernel.randomize_va_space = 2

# Restrict core dumps
fs.suid_dumpable = 0

# Hide exposed kernel pointers
kernel.kptr_restrict = 1

#Prevent SYN attack, enable SYNcookies (they will kick-in when the max_syn_backlog reached)
# use iptables synproxy
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_max_syn_backlog = 4096

# Disables packet forwarding
net.ipv4.ip_forward = 0
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.default.forwarding = 0
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.default.forwarding = 0

# Disables IP source routing
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.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Enable IP spoofing protection, turn on source route verification
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Disable ICMP Redirect Acceptance
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# Enable Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Don't relay bootp
net.ipv4.conf.all.bootp_relay = 0

# Don't proxy arp for anyone
net.ipv4.conf.all.proxy_arp = 0

# Enable ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Enable bad error message Protection
net.ipv4.icmp_ignore_bogus_error_responses = 1

• Empfehlungen für Linux-Server mit dynamischer (SLAAC) Adressen-Konfiguration
• Bei Servern mit statischer Adressen-Konfigurationen können viele IPv6 Funktionen ausgeschaltet werden, um die Angriffsfläche zu verringern. Siehe https://ernw.de/download/ERNW_Guide_to_Securely_Configure_Linux_Servers_For_IPv6_v1_0.pdf

net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.all.accept_ra_mtu = 1
net.ipv6.conf.all.accept_ra_rtr_pref = 1
net.ipv6.conf.all.accept_ra_rtr_pref = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_untracked_na = 0
net.ipv6.conf.all.addr_gen_mode = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.enhanced_dad = 1
net.ipv6.conf.all.max_addresses = 4
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.all.mtu = 1280
net.ipv6.conf.all.optimistic_dad = 0
net.ipv6.conf.all.suppress_frag_ndisc = 1

net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.default.accept_ra_mtu = 1
net.ipv6.conf.default.accept_ra_rtr_pref = 1
net.ipv6.conf.default.accept_ra_rtr_pref = 1
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_untracked_na = 0
net.ipv6.conf.default.addr_gen_mode = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.enhanced_dad = 1
net.ipv6.conf.default.max_addresses = 4
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.default.mtu = 1280
net.ipv6.conf.default.optimistic_dad = 0
net.ipv6.conf.default.suppress_frag_ndisc = 1

net.ipv6.icmp.ratelimit = 1000
net.ipv6.icmp.ratemask = 0-1,3-127

net.ipv6.ip6frag_high_thresh = 4194304
net.ipv6.ip6frag_low_thresh = 3145728
net.ipv6.ip6frag_secret_interval = 0
net.ipv6.ip6frag_time = 60

net.ipv6.route.max_size = 4096
net.ipv6.route.min_adv_mss = 1220
net.ipv6.route.mtu_expires = 600

• eBPF ist die extended Berkeley Packet Filter virtuelle Maschine im Linux Kernel
• XDP (eXpress Data Path) ist eine eBPF Schnittstelle zum Netzwerkstack
• BCC ist die BPF Compiler Collection, eine Sammlung von Tools und eBPF Programmen
• eBPF ist eine Weiterentwicklung der originalen Berkeley Packet Filter Technologie https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

• eBPF erlaubt es dem Benutzer, Programme im Betriebssystem-Kern innerhalb einer Sandbox auszuführen
  • eBPF ermöglicht es, die Funktionen des Betriebssystem-Kerns sicher und effizient zu erweitern, ohne den Quell-Code des Kernels ändern oder Module laden zu müssen
  • eBPF Programme können Netzwerk-Pakete (und andere Datenstrukturen) innerhalb des Linux-Kernels überwachen und verändern
  • eBPF Programme sind keine Kernel Module, es ist nicht notwendig ein Kernel-Entwickler zu sein um eBPF benutzen zu können
    • Wissen über Programmierung in der Sprache "C" ist jedoch von Vorteil

• Einsatzgebiete für eBPF
  • Netzwerk Sicherheit (erweiterte Firewall Funktionen)
  • Host / Container Security
  • Forensische Analyse laufender Prozesse
  • Fehlerdiagnose
  • Geschwindigkeitsmessungen
  • Rootkits? Backdoors im Kernel oder in Netzwerkkarten?

• eBPF ist in modernen Linux Systemen verfügbar (ab Kernel 3.18+) und wird derzeit von Microsoft auf das Windows Betriebssystem portiert
  • Blog Post "Making eBPF work on Windows" https://cloudblogs.microsoft.com/opensource/2021/05/10/making-ebpf-work-on-windows/

• Der originale BSD Packet Filter (BPF) wurde von Steven McCanne und Van Jacobson am Lawrence Berkeley Laboratory entwickelt (https://www.tcpdump.org/papers/bpf-usenix93.pdf)
  • BPF wurde auf fast alle Unix/Linux Systeme und viele non-Unix Betriebssysteme portiert (z.B. Windows, BeOS/Haiku, OS/2 …)
  • BPF ist die Basis-Technologie hinter bekannten Netzwerk-Sniffing Werkzeugen wie tcpdump und Wireshark

• Ein BPF-Filter (z.B. für tcpdump) wird in einen Bytecode für die BPF virtuelle Maschine im Linux-Kernel übersetzt und in den Kernel geladen
  • Das Betriebssystem ruft das BPF-Programm für jedes Netzwerk-Paket auf, welches den Netzwerk-Stack durchläuft
  • Nur Pakete, welche auf den Filter-Ausdruck passen, werden an das Programm im Userspace weitergeleitet (der tcpdump Prozess in dieses Beispiel)
  • BPF reduziert die Menge der Daten, welche zwischen dem Kernel und dem Userspace ausgetauscht werden müssen

tcpdump kann angewiesen werden den BPF Quellcode des tcpdump Filters auszugeben:

# tcpdump -d port 53 and host 1.1.1.1
Warning: assuming Ethernet
(000) ldh      [12]
(001) jeq      #0x86dd          jt 19   jf 2
(002) jeq      #0x800           jt 3    jf 19
(003) ldb      [23]
(004) jeq      #0x84            jt 7    jf 5
(005) jeq      #0x6             jt 7    jf 6
(006) jeq      #0x11            jt 7    jf 19
(007) ldh      [20]
(008) jset     #0x1fff          jt 19   jf 9
(009) ldxb     4*([14]&0xf)
(010) ldh      [x + 14]
(011) jeq      #0x35            jt 14   jf 12
(012) ldh      [x + 16]
(013) jeq      #0x35            jt 14   jf 19
(014) ld       [26]
(015) jeq      #0x1010101       jt 18   jf 16
(016) ld       [30]
(017) jeq      #0x1010101       jt 18   jf 19
(018) ret      #262144
(019) ret      #0

• Während BPF (heute auch cBPF = classic BPF genannt) Netzwerk Pakete im Betriebssystem-Kern filtert, kann eBPF auf weitere Kernel-Datenstrukturen Filter anwenden und Programm-Code ausführen:
  • Kernel Systemcalls
  • Kernel Tracepoints
  • Kernel Funktionen
  • Userspace Tracepoints
  • Userspace Funktionen

• Die erste Version von eBPF wurde im Linux Kernel 3.18 eingeführt
  • Neue Kernel Versionen bringen weitere, neue eBPF Funktionen
  • Linux Distributionen (Red Hat/Canonical/Suse) haben zum Teil eBPF Funktionen auf ältere LTS/EL Kernel Versionen zurückportiert
  • Eine Übersicht der eBPF Funktionen nach Linux Kernel Version aufgeschlüsselt: https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md

• mit diesem kleinen Beispielprogramm wird gezeigt, das Linux-Container mit nur einem Systemaufruf erzeugt werden.
• Quelle: https://blog.lizzie.io/linux-containers-in-500-loc.html
• C-Compiler und Entwicklungs-Tools installieren

dnf install gcc make

• Unser Ausgangs-C-Programm: Leeres Verzeichnis anlegen und die leere Quelltextdatei im Editor öffnen

cd /usr/src
mkdir namespaces
cd namespaces
$EDITOR namespaces.c
----
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>

#define STACK_SIZE (1024 * 1024)

static char child_stack[STACK_SIZE];
char* const child_args[] = {
  "/bin/bash",
  NULL
};

int child_main(void* arg)
{
  printf("Namespace aktiv\n");
  execv(child_args[0], child_args);
  printf("Ooops\n");
  return 1;
}

int main()
{
  printf("Namespace wird erzeugt\n");
  int child_pid = clone(child_main, child_stack+STACK_SIZE, \
   CLONE_NEWUTS | CLONE_NEWIPC | SIGCHLD, NULL);
  waitpid(child_pid, NULL, 0);
  printf("Namespace beendet\n");
  return 0;
}

----

• Programm übersetzen

gcc -o namespaces namespaces.c

• Programm ausführen

./namespaces

• Den Namespace mit exit verlassen, dann einen Process-Namespace zum Programm hinzufügen

...
 int child_pid = clone(child_main, child_stack+STACK_SIZE, \
   CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWPID | SIGCHLD, NULL);
...

• Neu übersetzen und ausführen (im Namespace das Proc-Dateisystem neu mounten um die Prozess-Isolierung via top oder ps zu sehen: mount -t proc proc /proc

gcc -o namespaces namespaces.c

• Namespace via exit beenden und das proc Dateisystem auf dem Host neu mounten mount -t proc proc /proc
• Einen Netzwerk-Namespace hinzufügen

...
  int child_pid = clone(child_main, child_stack+STACK_SIZE, \
   CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWPID |  CLONE_NEWNET | SIGCHLD, NULL);
...

• Die Netzwerkconfiguration im Namespace mit ip oder ifconfig anschauen

• Netzwerk Namespace netns1 erzeugen

# ip netns add netns1
# ip netns list

• Befehl im Netzwerk-Namespace ausführen

# ip netns exec netns1 ip link list
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

• Loopback ist "down", ein ping geht nicht

# ip netns exec netns1 ping 127.0.0.1
connect: Network is unreachable

• Nun bringen wir das Loopback-Interface "up"

# ip netns exec netns1 ip link set dev lo up
# ip netns exec netns1 ping 127.0.0.1

• Wir erstellen nun virtuelle Netzwerkschnittstellen

# ip link add veth0 type veth peer name veth1
# ip link

• Netzwerkschnittstelle veth1 wird in den Netzwerk-Namespace netns1 verschoben

# ip link set veth1 netns netns1  # auch physische NICs koennen in Namespaces verschoben werden
# ip link

• Wir konfigurieren ein IP-Adresse auf veth1 im Namespace

# ip netns exec netns1 ip addr add 10.1.1.1/24 dev veth1
# ip netns exec netns1 ip link set dev dev veth1 up
# ip netns exec netns1 ip a
# ping 10.1.1.1  # ping in den Namespace geht jetzt noch nicht!

• Eine IP-Adresse auf dem veth0 auf dem Linux-Host konfigurieren

ip addr add 10.1.1.2/24 dev veth0
ip link set dev veth0 up

• Ping von aussen in den Namespace geht jetzt!

# ping 10.1.1.1

• Ping aus den Namespace nach draussen sollte auch gehen

ip netns exec netns1 ping 10.1.1.2

• Der Namespace hat eine eigene Routing-Tabelle und eine eigene Netfilter-Firewall

ip netns exec netns1 ip route show
ip netns exec netns1 iptables -L

• Namespace wieder löschen

ip netns delete netns1

• mit dem Programm unshare können die einzelnen Namespaces separat erstellt und eingeschaltet werden. Wird kein zu startendes Programm angegeben, so wird die Standard-Shell des Systems mit den neuen Namespaces gestartet. Beispiel: ein Namespace mit privatem Netzwerk, Mount- und Prozess-ID- Namespace:

  # unshare -n -p -f --mount-proc
  

• Container mit Benutzer root, welcher nicht root auf dem Host ist

  sudo unshare --map-root-user --user sh
  

• Jedes Linux mit Systemd bietet mächtige Container-Verwaltungs-Werkzeuge mit
• systemd-nspawn arbeitet neben Image-Dateien für Container auch mit installieren Linux-Root-Dateien in einem beliebigen Verzeichnis auf dem Container-Host-System
  • Damit ist es sehr einfach, ein Container-System aufzusetzen und Dateien zwischen dem Container-Host und dem Linux im Container auszutauschen
• In diesem Kapitel installieren wir als Beispiel ein Rocky-Linux (eine freie Red Hat Enterprise Linux Distribution) in einem Verzeichnis unter Rocky-Linux 9
  • Andere Linux-Distributionen wie Ubuntu, Suse, Arch-Linux, Alpine-Linux oder Debian-Versionen wären auch möglich
  • Wichig ist das die Dateien im Container-Verzeichnis für die CPU-Architektur des Container-Hosts übersetzt wurden und die Programme keinen neueren Kernel benötigen (keine neuen System-Calls)
• Systemd-Container Werkzeuge installieren

  dnf install systemd-container
  

• Wir erstellen ein Verzeichnis für den neuen Container

mkdir -p /srv/container/rocky-linux8

• Initialisieren eine neue RPM-Instanz im Container-Verzeichnis (bei Debian mit debboostrap, bei SUSE mit RPM und zypper)

rpm --root /srv/container/rocky-linux8 --initdb

• Das Basis-Paket für Rocky-Linux laden

curl -O https://ftp.plusline.net/rockylinux/8/BaseOS/x86_64/os/Packages/r/rocky-release-8.10-1.9.el8.noarch.rpm
curl -O https://ftp.plusline.net/rockylinux/8/BaseOS/x86_64/os/Packages/r/rocky-repos-8.10-1.9.el8.noarch.rpm
rpm --nodeps --root /srv/container/rocky-linux8 -ivh rocky-repos-8.10-1.9.el8.noarch.rpm rocky-release-8.10-1.9.el8.noarch.rpm

• Das Rocky-Linux Basis-System installieren

dnf -y --nogpg --releasever=8 --installroot=/srv/container/rocky-linux8 \
  install systemd passwd dnf procps-ng iproute tmux rocky-gpg-keys
echo 8 > /srv/container/rocky-linux8/etc/dnf/vars/releasever

• Eine Shell im Container starten

systemd-nspawn -D  /srv/container/rocky-linux8

• Root-Passwort setzen und neuen Benutzer anlegen

-bash-4.2$ passwd
-bash-4.2$ adduser -m user
-bash-4.2$ passwd user

• RPM Datenbank im Container neu aufbauen

-bash-4.2$ rpmdb --rebuilddb

• Shell im Container verlassen

-bash-4.2# exit

• Auf dem Rocky-Linux 9 System Port 80 (http) in der Firewall öffnen

firewall-cmd --add-port=80/tcp --permanent
firewall-cmd --reload

• Container booten

systemd-nspawn -bD  /srv/container/rocky-linux8

• Weitere Software im Container installieren (hier den Apache Webserver)

dnf install httpd

• Anwendung im Rocky Linux Container starten (prüfen das kein andere Prozess auf dem Container-Host die Ports 80 und/oder 443 belegt)

systemctl enable --now httpd

• Der Apache Webserver innerhalb des Rocky Linux Containers sollte nun vom Browser unter http://selinuxXXX.linux-sicherheit.org erreichbar sein.
• Container stoppen (im Container eingeben)

conainter# poweroff

• Container mit privatem Netzwerk-Namespace starten:

systemd-nspawn -bD  /srv/container/rocky-linux8 --private-network

Container mit eigener (virtuellen) Netzwerkkarte (neue MAC-Adresse). eth0 ist der Name der physischen Netzwerkschnittstelle des Container-Hosts.

systemd-nspawn --network-macvlan=eth0 -M rocky01 \
  -bD /srv/container/rocky-linux8
container# ip links
container# dhclient mv-eth0
container# ip address show
container# ping 1.1.1.1

• Systemd-Befehle um einen Container vom Host aus zu kontrollieren

machinectl list
machinectl status rocky01
machinectl terminate rocky01
machinectl kill rocky01

• Per nsenter mit dem Container verbinden (es wird eine Prozess-ID eines Container-Prozesses benötigt!)

nsenter -m -u -i -n -p -t <pid-im-container> /bin/bash

• Firejail ist eine leichtgewichtige Sandbox für Linux-Programme auf Basis von Linux-Namespaces, secomp-bpf und der Linux-Firewall
  • Firejail wurde ursprünglich für die Absicherung des Firefox-Browsers erstellt, kann heuter auch für die Absicherung vieler andere Programme benutzt werden
  • Der Fokus von Firejail liegt auf Desktop-Linux-Programmen, jedoch kann Firejail auf auch Linux-Servern eingesetzt werden
• Homepage https://firejail.wordpress.com/
• Quellcode https://github.com/netblue30/firejail
• Moderne Versionen von Firejail unterstützen die Absicherung der DNS Namensauflösung mittels DNS-over-HTTPS und DNS-over-TLS mit dem FDNS Projekt https://firejaildns.wordpress.com/
• Firejail installieren

  dnf install firejail
  

• Den Konsolen-Webbrowser links installieren (als Beispielprogramm)

# dnf install links

• Einen im Linux System existierenden unprivilegierten Benutzer (z.B. user, nutzer etc., ggf. den Benutzer neu anlegen) in der Datei /etc/firejail/firejail.users eintragen (Die Datei ggf. anlegen, pro Benutzer eine Zeile), um die Benutzung von firejail durch diesen Benutzer zu erlauben
• Zum unprivilegierten Benutzer wechseln

# su - user

• Für den Benutzer das Verzeichnis .ssh (SSH Schlüssel und Konfiguration) erstellen. Firejail sichert dieses Verzeichnis gesondert ab, so das Programme ohne spezielle Firejail-Rechte (wie das ssh Programm) auf die Inhalte dieses Verzeichnisses nicht zugreifen können

$ cd ~
$ mkdir .ssh
$ chmod 600 .ssh

• Test von Firejail: wir starten eine Bash-Shell kontrolliert von Firejail

# firejail bash

• Teste die folgenden Aktionen in der Firejail-Bash:
  • Prozessliste auflisten
  • Programm top starten
  • Zeige die Datei .bash_history an (wenn die Datei noch nicht existiert dann die Bash einmal verlassen und wieder neu mit firejail bash starten)
  • Wechsle in das Verzeichnis .ssh
  • Liste alle Dateien im Heimverzeichnis mit ls -la und vergleiche mit der Ausgabe ohne Firejail. Was fällt auf?
• Firejail bash verlassen
• Firejail mit einem Browser (hier links)
  • Den Browser links im Jail starten (als unprivilegierter Benutzer)

    # su - nutzer
    $ firejail links https://notes.defaultroutes.de
    

  • Die Webseite des Trainings per Taste d (Download) sichern, danach den Browser links mit der Taste q verlassen
    • Wo ist die Datei gespeichert worden?
• Erstelle im Heimverzeichnis des Benutzers ein Verzeichnis mit den Namen Downloads

  $ mkdir ~/Downloads
  

• Starte links nochmals via firejail, speichere die Trainings-Webseite im Verzeichnis Downloads. Nach dem Beenden des Browsers ist die Datei dort zu finden
• Starte den Browser mit einer Datei-System-URL des Heimverzeichnisses links file://. mit und ohne FireJail. Welche Unterschiede gibt es?
• Erstelle (als Benutzer root) einen symbolischen Link von /usr/bin/firejail zu /usr/local/bin/links
  • Wird Firejail über einen solchen Symlink aufgerufen, so startet es das Programm mit dem Namen unter der Kontrolle von Firejail. Der Benutzer kann daher das Programm "direkt" aufrufen, ohne den Befehl firejail voranstellen zu müssen

    $ ln -s /usr/bin/firejail /usr/local/bin/links
    

• Firejail kann automatisiert für unterstützte Programme solche Wrapper-Links installieren. Die Wrapper-Links überlagern die Programm-Namen von schützenswerten Linux-Anwendungen.

$ sudo firecfg

• Firejail Programme überwachen (in einem separaten Terminal starten und dann z.B. links starten)

firejail --top

• Im System verfügbare Firejail Profile auflisten

ls /etc/firejail

• Stress erzeugen

stress-ng --cpu $(($(nproc)*2)) &
pgrep -alf stress-ng

• CGroup manuell anlegen und kontrollieren

cd /sys/fs/cgroup
mkdir stressgroup
cd stressgroup
cat cgroup.controllers
cat cgroup.type
cat cgroup.subtree_control

• Neue Untergruppen anlegen und kontrollieren

mkdir stress1 stress2
ls -l stress1
cat stress1/cgroup.type
cat stress1/cgroup.controllers

• Controller vererben

echo +io +cpu > cgroup.subtree_control
ls -l stress1

• Alle Prozesse in die Gruppe stress1 legen.

cd stress1
pgrep stress-ng | while read pid; do echo $pid > cgroup.procs; done

• Schrittweise Last auf die Gruppe stress2 verteilen. top beobachten. Weiter bis ca. Gleichstand erreicht ist.

cd ../stress2
echo <pid> > cgroup.procs

• Kontrolle mit weight. top beobachten

echo 10 > cpu.weight

• In der anderen Gruppe mit harten Limits (CPU=100%) begrenzen

cd ../stress1
cat cpu.max
echo 100000 100000 > cpu.max

• Alle Prozesse beenden

pkill stress-ng
rmdir stress1 stress2
cd ..
rmdir stressgroup

systemd-run stress -c 3
systemd-run stress -c 3
systemctl show run-r<UUID>.service
systemctl set-property run-r<UUID>.service CPUWeight=33
systemctl set-property run-r<UUID>.service CPUQuota=100
systemd-run --on-active=20 -p CPUQuota=50% stress-ng --cpu 4

$EDITOR /etc/systemd/system.conf.d/override-accounting.conf
-----
DefaultCPUAccounting=yes
DefaultIOAccounting=yes
DefaultBlockIOAccounting=yes
DefaultMemoryAccounting=yes
DefaultTasksAccounting=yes

systemctl set-property --runtime cups.service CPUQuota=10%
systemctl cat cups.service

• Units unter anderer uid/gid laufen lassen
• Zugriff auf Verzeichnisse beschränken
• Prozesslimits setzen

$EDITOR /etc/systemd/system/simplehttp.service

[Unit]
Description=HTTP Server

[Service]
Type=simple
Restart=on-failure

User=karl
Group=users

WorkingDirectory=/usr/share/doc
ReadOnlyDirectories=/var
InaccessibleDirectories=/home /etc/ssh
LimitNPROC=1  #darf nicht forken
LimitFSIZE=0  #darf keine Files schreiben

ExecStart=/bin/python3 -m http.server 8000

• System-Härtung von Systemd-Units unter RedHat EL 8 (und kompatiblen Systemen) im Abschnitt [service]
• Dokumentation: https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
• Nur 64bit Programme ausführen, 32bit i686 ist nicht erlaubt

  Personality=x86-64
  LockPersonality=yes
  SystemCallArchitectures=x86-64
  

• Berechtigungsmaske für neue Dateien

  UMask=077
  

  RestrictSUIDSGID=yes
  

• Maximaler Speicherverbrauch dieser Anwendung, muss ggf. angepasst werden

  MemoryMax=2G
  

• Maximale Anzahl von Prozessen/Threads in dieser Anwendung

  TasksMax=20
  

• Anwendung darf keine Namespaces/Container erstellen

  RestrictNamespaces=yes
  

  • Anwendung darf die Echtzeit-Einstellungen nicht ändern

  RestrictRealtime=yes
  

• Daten dürfen nicht ausgeführt werden (muss ggf. bei Java Just-in-Time Compiler ausgeschaltet werden)

  MemoryDenyWriteExecute=yes
  

• Anwendung darf sich keine neuen Rechte verschaffen

  NoNewPrivileges=yes
  

• Anwendung hat eine private Sicht auf die Gerätedateien unter /dev

  PrivateDevices=yes
  

• Anwendung darf nur auf Standard-Geräte zugreifen

  DevicePolicy=closed
  

• Anwendung bekommt ein privates /tmp Verzeichnis

  PrivateTmp=yes
  

• Prozess kann keine neuen Dateisysteme global mounten

  PrivateMounts=yes
  

• Anwendung kann keine Änderungen an den CGroups vornehmen

  ProtectControlGroups=yes
  

• Anwendung bekommt eine private Kopie der Heimverzeichnisse (/home /root /run)

  ProtectHome=yes
  

• Anwendung kann keine Kernel-Module laden/entladen

  ProtectKernelModules=yes
  

• Anwendung kann keine Kernel-Parameter ändern

  ProtectKernelTunables=yes
  

• Anwendung kann keine Systemdateien ändern

  ProtectSystem=yes
  

• Prozess darf den Hostnamen nicht ändern

  ProtectHostname=yes
  

• Prozess bekommt einen leeren Network-Namespace und kann keine Netzwerkdaten (ausser privates Loopback) senden und empfangen

  PrivateNetwork=yes
  

• Anwendung kann nur Verbindungen mittels dieser Protokolle aufbauen

  RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
  

• Anwendung kann Syscalls aus diesen Anwendungsbereichen nicht benutzen

  SystemCallFilter=~@clock @debug @module @mount @raw-io @reboot @swap @cpu-emulation @obsolete
  

• Anwendung bekommt die folgenden Capabilities entzogen

  CapabilityBoundingSet=~CAP_SETPCAP CAP_SYS_ADMIN CAP_SYS_PTRACE CAP_CHOWN CAP_FSETID CAP_SETFCAP CAP_(DAC_OVERWRITE CAP_FOWNER CAP_IPC_OWNER
  CapabilityBoundingSet=~CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_TIME CAP_AUDIT_CONTROL CAP_KILL CAP_MKNOD CAP_NET_BROADCAST CAP_NET_RAW
  CapabilityBoundingSet=~CAP_SYS_NICE CAP_MAC_ADMIN CAP_MAC_OVERRIDE CAP_BPF CAP_SYS_BOOT CAP_LINUX_IMMUTABLE CAP_IPC_LOCK
  CapabilityBoundingSet=~CAP_BLOCK_SUSPEND CAP_LEASE CAP_SYS_PACCT CAP_SYS_TTY_CONFIG CAP_WAKE_ALARM
  

• Die Anwendung darf sich nur an bestimmte TCP/UDP-Sockets binden (Ports für eingehenden Netzwerk-Verkehr öffnen)

  SocketBindDeny=any
  SocketBindAllow=53     # DNS
  SocketBindAllow=953    # RNDC
  SocketBindAllow=853    # DNS-over-TLS
  

• Systemd kann (mit der Hilfe von eBPF Programmen – siehe Kapitel eBPF) IPv4 und IPv6 Pakete auf der Prozess/Unit Ebene filtern:

  IPAddressDeny=any
  IPAddressAllow=172.16.1.0/24 192.168.178.64/27 192.0.2.22 100.64.2.53
  

• Die Firewall filtert sowohl eingehende- als auch ausgehende Pakete
  • Bei eingehenden Paketen wird die Quell-IP-Adresse mit der Allow-Liste verglichen
  • Bei ausgehenden Paketen wird die Ziel-IP-Adresse mit der Allow-Liste verglichen
  • Alle Adressen welche nicht explizit per Deny-Liste geblockt werden sind erlaubt

• Der Befehl systemd-analyze security listet alle im System definierten Systemd-Units mit einer Sicherheitsbewertung basierend auf den Beschränkungen der Service-Unit
• Der Befehl systemd-analyze security <unit.service> listet eine Übersicht der meisten sicherheitsrelevanten Systemd-Unit-Einstellungen einer Service-Unit

  $ systemd-analyze security sshd
  

• Ergänze die System-Unit für rsyslog.service mittels systemctl edit rsyslog.service um die oben genannten Sicherheits-Erweiterungen. Prüfe die Sicherheitswertung mit systemd-analyze security und stelle sicher, das der Dienst weiterhin startet

• http://0pointer.de/blog/projects/journalctl.html

• /var/log/journal/<machine-id> ← persistent
• /run/log/journal/<machine-id> ← dynamisch

Die machine-id steht in /etc/machine-id und wird automatisch generiert oder mit systemd-machine-id-setup erzeugt. Das Verzeichnis /var/log/journal muss vorhanden sein; systemd-journald loggt andernfalls nur temporär (Datenbank in einer TMPFS-Ramdisk).

• Alle Journalmeldungen anzeigen

journalclt

• An das Ende der Logdaten springen

journalctl -e

• Datei verfolgen (wie tail -f) inkl. allen Metadaten und Catalog-Meldungen

journalctl -f -a -x

• Log-Einträge eines bestimmten Dienstes anzeigen

journalctl _SYSTEMD_UNIT=ssh.service
journalctl -u ssh.service
journalctl /usr/sbin/sshd

• Kernel Meldungen (Alternative zu dmesg) anzeigen

journalctl -k

• Alle Felder der Log-Einträge aufschlüsseln (optional als JSON ausgeben)

journalctl -o verbose
journalctl -o json-pretty

(alle Felder, die mit '_' beginnen, sind interne Felder und werden intern vom journald gesetzt und nicht vom Client. Somit sind sie nicht leicht manipulierbar.)

• Alle Log-Meldungen seit dem letztem Boot

journalctl -b

• Alle Log-Meldungen in einem bestimmten Zeitraum

journalctl --since "2020-01-10" --until "2020-01-24 12:00"

• Log-Meldungen ab einem bestimmten Log-Level

journalctl -p 4
journalctl -p warning

• Log-Meldungen aus der Shell in das Journal schreiben

ls | systemd-cat

• Größe der Journal-Datenbank beschränken: in der Datei /etc/systemd/journald.conf:

SystemMaxUse=100M
SystemKeepFree=1G

• Forward Secure Sealing (FSS) ist eine Funktion im Journal, die dazu dient, Manipulationen von Protokolldateien zu erkennen. Da Angreifer oft versuchen, ihre Aktionen zu verbergen, indem sie Einträge in den Protokolldateien ändern oder löschen, bietet FSS den Administratoren einen Mechanismus, um solche unautorisierten Änderungen zu erkennen.
• Um FSS Benutzen zu können muss das Journal persistent sein

  # mkdir /var/log/journal
  # systemctl restart systemd-journald
  # journalctl --flush
  

• FSS Schlüssel erstellen: FSS benötigt zwei kryptografische Schlüssel
  • Sealing-Schlüssel: Erzeugt Signaturen für die Journal-Einträge
  • Verifikation-Schlüssel: Wird benutzt um die Signaturen des Journal zu prüfen
  • Der Sealing-Schlüssel wird pro Interval neu aus dem vorherigen Schlüssel erzeugt. Der Verifikation-Schlüssel muss dabei nicht erneuert werden. Innerhalb des Interval-Zeitraums kann ein Angreifer den aktuellen Sealing-Schlüssel im Dateisystem finden und zur Manipulation des Journals benutzen. Erst nach dem Erzeugen eines neuen Sealing-Schlüssels ist der vorherige Schlüssel nicht mehr verfügbar und die Journal-Einträge geschützt. Das Sealing-Interval sollte daher möglich kurz gewählt werden.

    # journalctl --setup-keys
    Generating seed...
    Generating key pair...
    Generating sealing key...
    Unable to set file attribute 0x1 on n/a, ignoring: Operation not supported
    Unable to set file attribute 0x800000 on n/a, ignoring: Operation not supported
    
    New keys have been generated for host selinux015/a7f85404d5a54e2392d6a92fa98be15a.
    
    The secret sealing key has been written to the following local file.
    This key file is automatically updated when the sealing key is advanced.
    It should not be used on multiple hosts.
    
            /var/log/journal/a7f85404d5a54e2392d6a92fa98be15a/fss
    
    The sealing key is automatically changed every 15min.
    
    Please write down the following secret verification key. It should be stored
    in a safe location and should not be saved locally on disk.
    
            436e17-ca6a3d-4310a2-345c98/1d48b1-35a4e900
    

  • Der Verifikation-Key muss vom Admin sicher archiviert werden, um hiermit später das Journal prüfen zu können
  • Optionen beim Erstellen der FSS-Schlüssel
    • --interval=10s Key-Roatation Intervall 9Default: 15 Minuten). Innerhalb dieses Intervall kann ein Angreifer die Logs manipulieren. Kleinere Interval-Zeiträume sind sicherer, verbrauchen aber mehr CPU-Ressourcen da häufiger neue Schlüssel generiert werden
    • --force Erzwingt die Neu-generierung eines FSS Schlüsselpaars
• Journal-Integrität prüfen:

  # journalctl --verify --verify-key=436e17-ca6a3d-4310a2-345c98/1d48b1-35a4e900
  PASS: /run/log/journal/775cf97f988e76f6b34b3904c5817b52/system@2526700792cb4433a4e10ad6e6dedfcf-000000000000d6db-000622e580c48a69.journal
  3e86c0: Data object references invalid entry at 1147f70
  File corruption detected at /var/log/journal/a7f85404d5a54e2392d6a92fa98be15a/system.journal:1147e60 (of 25165824 bytes, 72%).
  FAIL: /var/log/journal/a7f85404d5a54e2392d6a92fa98be15a/system.journal (Bad message)
  

• Journal FSS Dokumentation:
  • https://lwn.net/Articles/512895/
  • Practical Secure Logging: Seekable Sequential Key Generators ( Giorgia Azzurra Marson and Bertram Poettering ) https://eprint.iacr.org/2013/397
  • Secure Logging in between Theory and Practice: Security Analysis of the Implementation of Forward Secure Log Sealing in Journald (Felix Dörre and Astrid Ottenhues) https://eprint.iacr.org/2023/867.pdf

• die Journal-Einstellungen systemd.journald.max_level_console, systemd.journald.max_level_store, systemd.journald.max_level_syslog, systemd.journald.max_level_kmsg, systemd.journald.max_level_wall können über die Kernel-Kommandozeile übergeben werden und sind aktiv, wenn das Journal in der Init-Ramdisk gestartet wird (und die Journal-Konfigurarionsdatei noch nicht gelesen wurde).
• Maximale Anzahl von Journal-Datenbank-Dateien: in der Konfiguration /etc/systemd/journal.conf kann konfiguriert werden, wieviel archivierte Journal-Datenbank-Dateien der Journal-Daemon vorhalten soll. Der Standardwert ist 100. Dieser Wert kann über die Einstellungen SystemMaxFiles und RuntimeMaxFiles angepasst werden. Mit dem Befehl journalctl --vacuum-files können alle alten Journal-Datenbanken bis auf die im Befehl angegebene Anzahl gelöscht werden.
• Der Befehl journalctl --sync sort dafür das der Journal-Daemon alle noch im Speicher befindlichen Meldungen in die Datenbank im Dateisystem schreibt
• Wird beim Befehl journalctl als Selektor ein Gerätepfad angegeben, so gibt der Befehl auch Meldungen der Eltern-Geräte-Treiber aus (z.B. des SATA-Kontrollers, wenn eine SATA-Platte angegeben wird)
• Mit dem Parameter journalctl --root kann ein Journal aus einem alternativen Root-Verzeichnis (z.B. Container) gelesen werden. In den Verzeichnis muss kein Journal-Dienst gestartet sein (d.h. bei einem Container muss der Container nicht gestartet sein)
• Mit der Option --grep=<suchbegriff> kann die Ausgabe von journalctl auf einen beliebigen Suchbegriff gefiltert werden. Diese Filterung geschied im Journal-Daemon und ist effizienter als eine nachträgliche Filterung mit grep auf der Kommandozeile

• Dateisystem-Platzverbrauch des Systemd-Journals abfragen

# journalctl --disk-usage
Archived and active journals take up 4.0G in the file system.

• Journal-Datenbank verkleinern

# journalctl --vacuum-size=500M
# journalctl --disk-usage
Archived and active journals take up 488.1M in the file system.

• Mit dem Dienst systemd-journal-gatewayd kann das Journal eines Rechners nach aussen über das Netzwerk exportiert werden. Die Daten werden über HTTP- oder HTTPS-Protokoll ausgeliefert. Für HTTPS muss ein x509-Zertifikat hinterlegt werden.
• Paket für Journal-Logging über Netzwerk installieren. Das Paket systemd-journal-remote beinhaltet den systemd-journal-gatewayd Dienst

# dnf install systemd-journal-remote

• Dienst-Socket starten. Der Socket horcht auf Port 19531/TCP:

# systemctl enable --now systemd-journal-gatewayd.socket

• In der Firewall Port 19531 freischalten

# firewall-cmd --add-port=19531/tcp --permanent
# firewall-cmd --reload

• System-Reboot oder Rechte auf /var/log/journal für Gruppe systemd-journal setzen (z.B. via systemd-tmpfiles --create)
• Per Browser auf http://<rechnername>:19531/ ist nun das Journal über ein Web-GUI abfragbar (Achtung: es gibt keine Benutzer-Authentisierung!)
• Journal-Einträge können auch über HTTP-Kommandozeilen Programme wie curl oder wget abgerufen werden

# curl 'http://<rechnername-oder-ip>:19531/entries?follow'

• Dabei können die Einträge auch auf Journal-Felder gefiltert werden

curl 'http://<rechnername-oder-ip>:19531/entries?follow&_COMM=sshd'

• systemd-journal-gatewayd ist die Gegenstelle zu einem zentralen Journal im Pull Modus

• Das Journal kann in zwei verschiedenen Modi über das Netzwerk transportiert werden: Pull-Modus (zentraler Server holt die Daten von den zu überwachenden Rechnern) oder Push-Modus (zu überwachende Rechner senden aktiv die Daten zum zentralen Journal-Server)

• Das Linux Audit Subsystem erlaubt es dem Betreiber eines Linux Systems, ein fein-granulares Audit-Logging für System-Ereignisse festzulegen
  • Ereignisse von Linux-Security-Modulen (LSM) wie AppArmor oder SELinux
  • Ereignisse von sicherheitsrelevanten Anwendugen (SSH, Login-Programm)
  • Ereignisse welche von beliebigen Anwendungen ausgelöst werden und in der Audit-Subsystem Richtlinien-Konfiguration hinterlegt wurden (z.B. Systemcalls, Dateizugriffe, Netzwerk-Aktivitäten)

• CIS Benchmark Webseite: https://downloads.cisecurity.org/
• A Linux Auditd rule set mapped to MITRE's Attack Framework https://github.com/bfuzzy1/auditd-attack
• Enhanced AuditD (Audit Daemon) rules for Linux systems, HIPAA & HITRUST compliance https://github.com/gnxsecurity/enhanced-auditd-rules
• An auditd ruleset for monitoring linux servers https://github.com/benjaminkoffel/auditd-rules
• UnderstandingAuditdRules - This is an overview of writing auditd rules for linux https://github.com/clevelandjosh/UnderstandingAuditdRules

# cat /sys/kernel/security/lsm
lockdown,capability,yama,tomoyo,bpf

• YAMA sammelt Sicherheitsfunktionen aus Linux-Kernel-Sicherheitspatches, welche nicht in eine der anderen Linux-Sicherheits-Module passen
• in aktuellen Linux-Kerneln bietet mit YAMA einen Schutz gegen ptrace (ptrace_scope), d.h. das ein Prozess den Speicher und die Ausführung eines anderen Prozesses überwachen kann (diese Funktion wird für die Benutzung von Debuggern bei der Programmentwicklung benötigt). Auf Produktions-Serversystemen ist diese Funktion oft nicht benötigt.
• Werte für ptrace_scope

  Wert	Beschreibung
  0	normales Verhalten, jeder Prozess und Benutzer kann andere Prozesse überwachen
  1	ein Prozess kann nur einen eigenen Kind-Prozess überwachen
  2	nur ein Systemadministrator mit CAP_SYS_PTRACE kann Prozesse überwachen
  3	keine Überwachen von Prozessen mittels ptrace möglich, diese Einstellung kann im laufenden System nicht überschrieben werden

• LoadPin ist seit Kernel 4.7 Bestandteil von Linux
• LoadPin gewährleistet das alle Kernel-Daten (Module, Firmware-Blobs etc) vom gleichen, read-only Datei-System gelesen werden.
• LoadPin verhindert Angriffe auf den Kernel durch bösartige Kernel-Module (z.B. Root-Kits)
• Dokumentation: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/LSM/LoadPin.rst

• Das SafeSetID Modul überwacht die Benutzung der SetUID/SetGID Syscalls (UID oder GID eines Prozesses ändern, z.B. via su oder sudo oder per SetUID-Bit in den Dateisystemrechten) und prüft die Benutztung gegen eine systemweite Whitelist
  • Mittels SafeSetID können Prozesse die Capability CAP_SETUID/CAP_SETGID benutzen um von einem unpriviligierten Benutzeraccount in einen anderen zu wechseln (um Rechte abzugeben), ohne das diese Programme die Rechte ausweiten können oder sogar Root- Rechte erlangen können
  • Die Whitelist wird als Text-Datei mit je einer Regel pro Zeile in das securityfs Pseudo-Dateisystem unter dem Pfad safesetid/uid_allowlist_policy (für UID Übergänge) und safesetid/gid_allowlist_policy (für GID Übergänge) geschrieben
  • Das Format jedes Eintrages ist <ausgangs-UID>:<neue-UID>\n
• Dokumentation: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/LSM/SafeSetID.rst

• Das Lockdown Modul beschränkt bestimmte Funktionen des Linux Kernels (Laden von unsignierten Modulen, PTRACE, eBPF, Hibernation = Speicherinhalte auf Datenträger schreiben, Zugriffe auf spezielle Gerätedateien unter /dev, Kernel perf Schnittstellen, ACPI-Tabellen …)
  • Lockdown kann per Kernel-Commandozeile aktiviert werden: Parameter lockdown=
  • Nachträglich kann Lockdown über das Pseudo-Dateisystem unter /sys/kernel/security/lockdown ein- oder aus-geschaltet werden
  • Lockdown kennt zwei Modi
    • integrity - Funktionen sind ausgeschaltet, welche den laufenden Kernel verändern können
    • confidentiality - Funktionen aus dem Modus integrity sind ausgeschaltet, plus Funktionen über welche sensible Daten aus dem Kernel ausgelesen werden können (z.B. Zugriffe auf /dev/mem)
• Lockdown LSM ist seit Kernel 5.4 verfügbar
• Lockdown Status ausgeben (hier none, Modi integrity und confidentiality sind möglich)

  # cat /sys/kernel/security/lockdown
  [none] integrity confidentiality
  

• Links
  • Lockdown as a security module
  • Linux kernel lockdown, integrity, and confidentiality

• Landlock ist ein LSM welches Prozessen erlaubt, die eigenen Dateisystem-Rechte (und die Rechte von Kind-Prozessen) über die Unix-Dateisystemrechte hinaus einzuschränken.
  • Da die Landlock Rechte-Einschränkungen vererbt werden, können auch Supervisor Programme erstellt werden, um Kind-Prozesse zu beschränken, ohne diese Kind-Prozesse im Quellcode ändern zu müssen
  • Landlock ist von der Idee vergleichbar mit dem OpenBSD pledge Mechanismus, wirkt jedoch nur auf Dateisystemrechte (pledge wirkt auf verschiedenen Syscall-Gruppen)
• Seit Kernel 5.13 verfügbar
• Dokumentation: https://landlock.io/
• Kernel Dokumentation: https://www.kernel.org/doc/html/latest/security/landlock.html

• TOMOYO LSM kann zur Analyse eines Linux-Systems, oder zur Implementation einer Sicherheitrichtlinie für das Linux-System verwendet werden
• TOMOYO beschränkt Linux-Prozesse auf Basis des Dateisystem-Pfads und der Prozess-Hierarchy ("Domain" in der TOMOYO Terminology, hat aber keinen Zusammenhang mit DNS, dem Domain-Name-System)
• TOMOYO fasst einen oder mehrere Prozesse zu einer Domain zusammen
  • Jede Domain wird über ein Profil reglementiert
  • Es können 255 unterschiedliche Profile im TOMOYO LSM definiert werden
  • Jedes Profil kann unabhängig von anderen Profilen in einem von 3 Modi verwendet werden
    • Learning: Syscall-Aufrufe und Dateisystem-Interaktionen werden protokolliert und in das Profil aufgenommen (Erstellung eines Baseline-Profils für eine Prozess-Gruppe/Domain)
    • Permissive: Verstösse gegen die Policy werden protokolliert, aber nicht durchgesetzt
    • Enforcing: Verstösse gegen die Policy werden aktiv verhindert und protokolliert
• Kernel-Dokumentation: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/LSM/tomoyo.rst
• Handbuch: https://tomoyo.osdn.jp/2.6/index.html.en
• TOMOYO kann alternativ auch als Linux-Kernel-Modul geladen werden (dann ist es kein LSM, sondern kann zusätzlich zu anderen Major-LSMs benutzt werden)

• SMACK ist ein Mandatory Access Controll System im Linux Kernel, welches im Vergleich zu SELinux weniger komplex ist
• SMACK ist seit Kernel 2.6.25 Teil des Linux-Kernels
• SMACK wird heute hauptsächlich in Linux-Systemen von IoT-Geräten und in Automotive-Anwendungen verwendet (z.B. im Tizen OS von Samsung)
  • Wie auch SELinux arbeitet SMACK auch mit Sicherheits-Label auf Basis von erweiterten Attributen in den Linux-Dateisystemen
    • Es ist möglich SMACK in mittels der eingebauten Sicherheitspolicy auch ohne erweiterte Attribute zu betreiben, dann kann die Sicherheitsrichtlinie jedoch nicht angepasst werden
  • SMACK bindet Sicherheitslabel beim Empfang an IP-Pakete
    • Die Sicherheitsrichtlinie kann benutzt werden, um die Kommunikation von Anwendungen auf bestimmte IP-Adressen oder Netzwerke zu beschränken
    • Diese Funktion von SMACK kann zu Performance-Verlusten bei der Netzwerkkommunikation führen, wenn SMACK im Kernel aktiv ist
• SMACK Kernek Dokumentation
• Heise iX: SMACK im Linux Kernel

• SELinux (Security-Enhanced Linux; engl. „sicherheitsverbessertes Linux“) ist eine Erweiterung des Linux-Kernels. Es implementiert die Zugriffskontrollen auf Ressourcen im Sinne von Mandatory Access Control. SELinux wurde von der NSA für eigene Bedürfnisse entwickelt und wird von dem Linux-Distributor Red Hat gepflegt.
• SELinux ist Open-Source-Software und setzt sich aus einem Kernel-Modul, Hilfsprogramme und aus zahlreichen Erweiterungen für Systemprogramme zusammen.
• Kernbestandteil von SELinux sind die Policies, welche sehr detailliert beschreiben, welche Zugriffe (Dateisystem, Syscalls, Netzwerk) einem Prozess oder einem Benutzer erlaubt sind.
• SELinux kann mit verschiedenen Policy-Einstellungen betrieben werden:
  • full - alle Ressourcen und Anwendungen im Linux-System sind von der SELinux Policy abgedeckt. Dies ist sehr aufwändig und wird von den Linux-Distributionen nicht angeboten
  • targeted - SELinux Policies existieren für kritische Komponenten im Linux-System (z.B. Systemd, Webserver, Mailserver etc). Nur diese Komponenten sind von SELinux abgesichert, alle anderen Komponenten befinden sich im unconfined Modus und werden von SELinux nicht beschränkt. Die Linux-Distributionen bieten Policies für den targeted Modus an.

• Erstelle ein Verzeichnis für HTML Seiten unter /srv/websites
• Erstelle in dem Verzeichnis eine einfache index.html Datei
• Ändere die Konfigration des Apache Webservers (siehe vorherige Aufgabe) so das der Document-Root auf das Verzeichnis /srv/websites zeigt
• Starte den Apache Webserver neu und teste ob die Webseite ausgeliefert wird (sollte nicht)
• Prüfe die SELinux Meldungen im Audit-Log mit ausearch -m avc -i -ts recent
• Benuzte den Befehl semanage fcontext (MAN-Page lesen) um die SELinux-Label httpd_sys_content_t für das Verzeichnis /srv/websites zu definieren
• Benutze den Befehl restorecon um den Dateien unter /srv/website mit neuen SELinux Label zu versehen
• Erstelle eine neue HTML-Datei unter /srv/websites, prüfe das SELinux Context-Label dieser neuen Datei mit ls -lZ
• Teste das die Webseiten nun korrekt ausgeliefert werden

• Es ist möglich einzelne SELinux Module in einen permissive Modus zu versetzten
  • In diesem Modus wird die SELinux Policy für dieses Modul nicht mehr vom Kernel durchgesetzt
  • Verstösse gegen die Policy werden jedoch weiterhin im Audit-Log protokolliert
• Ein Modul (hier httpd_t für Apache oder NGINX Webserver) in den permissive Modus setzen

semanage permissive -a httpd_t

• Alle Module auflisten, welche im permissive Modus laufen

# semanage permissive -l

• Permissive Modus von einem Modul entfernen

semanage permissive -d httpd_t

• Permissive Modus von allen Modulen entfernen

semanage permissive -D

• Andere Web-Server (Apache/NGINX etc) stoppen
• Für die Dauer dieser Übung die Firewall deaktivieren

systemctl stop firewalld

• Entwickler von SELinux-Policies können bestimmte Regeln vom Auditing ausschliessen
  • Um übermässiges Logging im Audit-Log zu vermeiden
  • Verstösse gegen SELinux-Regeln, welche mit donotaudit markiert sind, werden nicht im Audit-Log vermerkt
  • Bei der Entwicklung von neuen SELinux Policies kann dies stören, denn hier möchte man im Audit-Log ein möglichst vollständiges Bild aller Verstösse bekommen
  • Die donotaudit Regeln in der SELinux-Richtline ausschalten

    # semodule -DB
    

  • Um die donotaudit Regel wieder zu aktivieren

    # semodule -B
    

• Einführung in nftables

• Das nachfolgende nftable-Regelwerk kann als Grundlage für eine Host-Firewall für eine Linux-Workstation benutzt werden.
• Gefiltert werden die eingehenden IPv4- und IPv6-Verbindungen.
• Gängige Dienste auf einer Linux-Workstation wie Internet Printing Protocol (IPP/Cups) und Multicast-DNS werden erlaubt:

flush ruleset

define any = 0::0/0

table inet filter {
        chain input {
                type filter hook input priority 0;

                # accept any localhost traffic
                iif lo accept

                # accept traffic originated from us
                ct state established,related accept

                # activate the following line to accept common local services
                #tcp dport { 22, 80, 443 } ct state new accept

                # NTP multicast
                ip6 daddr ff02::1010 udp dport 123 accept

                # mDNS (avahi)
                ip6 daddr ff02::fb udp dport 5353 accept
                ip  daddr 224.0.0.251 udp dport 5353 accept

                # DHCPv6
                ip6 saddr $any udp dport 546 accept

                # IPP (CUPS)
                udp dport 631 accept

                # Accept neighbour discovery otherwise IPv6 connectivity breaks.
                ip6 saddr $any icmpv6 type { nd-neighbor-solicit,  nd-router-advert, nd-neighbor-advert }  accept

                # Accept essential icmpv6
                # nft cannot parse "param-problem" (icmpv6 type 4)
                ip6 saddr $any icmpv6 type { echo-reply, echo-request, packet-too-big, destination-unreachable, time-exceeded, 4 } accept

                # count and drop any other traffic
                counter log prefix "nftables drop: " drop
        }
}

• Nachfolgend ein nftables-Regelwerk für eine einfache Firewall mit DMZ-, WAN- und LAN-Schittstelle. In der DMZ befinden sich die Server mit Web und E-Mail.
• In der Postrouting-Kette werden alle Pakete aus dem LAN-Segment, welche die Firewall in Richtung Internet (WAN) verlassen, per Masquerading-NAT auf die IPv4-Adresse der WAN-Netzwerkschnittelle umgeschrieben.

#!/usr/bin/nft -f
flush ruleset
define mgt_if = eth0
define wan_if = eth1
define lan_if = eth3
define dmz_if = eth2
define any_v6  = 0::0/0

table inet gateway-fw {
        chain forward {
                type filter hook forward priority 0
                # accept established traffic
                ct state established,related accept
                # allow all outgoing traffic from LAN
                iif $lan_if accept
                # access to services in the DMZ
                oif $dmz_if tcp dport { http, https, smtp, imap, imaps } counter accept
                # Accept essential icmpv6
                # nft cannot parse "param-problem" (icmpv6 type 4)
                ip6 saddr $any_v6 icmpv6 type { echo-reply, echo-request, packet-too-big, destination-unreachable, time-exceeded, 4 } accept
                # reject everything else
                counter log reject
       }
       chain input {
                type filter hook input priority 0
                iif lo accept
                iif $mgt_if tcp dport ssh accept
                ip6 saddr $any_v6 icmpv6 type { nd-neighbor-solicit,  nd-router-advert, nd-neighbor-advert }  accept
                ip6 saddr $any_v6 icmpv6 type { echo-reply, echo-request, packet-too-big, destination-unreachable, time-exceeded, 4 } accept
                counter log reject
       }
}
table ip nat {
        chain prerouting {
                type nat hook prerouting priority 0
        }
        chain postrouting {
                type nat hook postrouting priority 0
                oif $wan_if log masquerade
        }
}

• Stoppe die Firewall-Management-Software firewalld. Der Befehl nft list ruleset sollte ein leeres nft Regelwerk zurückgeben

  # systemctl stop firewalld
  # nft list ruleset
  

• Erstelle eine Host-Firewall in der Datei /etc/nftables.conf, welche nur folgende Zugriffe erlaubt
  • ICMP Echo-Request/Echo-Reply
  • Port 80 (HTTP), Port 443 (HTTPS) und 22 (SSH)
• Starte einen Python-Webserver als Benutzer root auf Port 80

python3 -m http.server 80

• Installiere nmap

dnf install nmap

• Scanne per nmap nach offenen Ports der VM Deines Nachbarn einmal mit nftables Firewall aktiv, einmal ohne eingeschaltete nftables Firewall auf der VM des Nachbarn. Gibt es Unterschiede in der Ausgabe?

nmap -v -sT selinuxXXX.linux-sicherheit.org

• Teste bei eingeschalteter Firewall auf dem Rechner des Nachbarn, ob die Website/Verzeichnlis-Listing auf dem Webserver des Nachbarn vom Browser erreichbar ist.

• Starte den Python Webserver auf Port 8000

python3 -m http.server 8000

• Erstelle eine redirect oder dnat Destination-NAT Regel (Tabelle nat, Chain prerouting), welche Zugriffe auf Port 80 des Rechners auf Port 8000 umleitet: Nftables Dokumentation: man nftables
• Teste dieses Regelwerk mit einem Browser vom einem anderen Rechner, der Browser sollte auf Port 80 den Webserver erreichen können

#!/usr/sbin/nft -f

flush ruleset

table ip filter {
        chain input {
                type filter hook input priority 0;
		policy accept;

                iif lo accept

		icmp type { echo-reply, echo-request } accept
                ct state established,related accept
                tcp dport { ssh, http, https } ct state new accept

		counter log prefix "nftables drop: " drop
        }
}

• Regelwerk nach Änderungen neu laden

systemctl restart nftables

• aktives Regelwerk inkl. der Zähler anzeigen

nft list ruleset

• Log-Meldungen erscheinen im Syslog (/var/log/messages) und im Journal

journalctl | grep nftables
grep nftables /var/log/messages

#!/usr/sbin/nft -f

flush ruleset

table ip nat {
	chain prerouting {
		type nat hook prerouting priority 0;
		tcp dport 80 redirect to 8000
	}
	chain postrouting {
		type nat hook postrouting priority 0;
	}

}

table ip filter {
	chain input {
		type filter hook input priority 0;
		policy accept;

		iif lo accept

		icmp type { echo-reply, echo-request } accept
		ct state established,related accept
		tcp dport { ssh, http, https, 8000 } ct state new accept

		counter log prefix "nftables drop: " drop
	}
}

• Bekannte negative oder bösartige Log-Meldung verfolgen und abstellen
• Bekannt gutartige Log-Meldungen (welche nicht abgestellt werden können) ausfiltern (granular, nicht überfiltern, Vorsicht bei RegExps)

• Liste von Log-Informationen aus RHEL Systemen welche in SIEM-Systemen überwacht werden sollten
  • Kernel-Log (via Systemd-Journal)
    • Firewall
    • Kernel Modul Laden/Entladen
    • Hardware Fehler
    • Abnormale Prozess-Zustände (oomkiller, crashes)
    • Kernel-Panics
    • Kernel-Updates (Geänderte Kernel-Versionen)
    • Dateisystem Mounts
    • Uhrzeit Änderungen/Drifts
• Audit-Log (via auditd)
  • SELinux AVC Events
  • Zugriffe auf sensitive Daten (private Schlüssel, DNS-Resolver Konfiguration, Kernel-Dateien, SUID-Bit Dateien etc) - benötigt eine Audit-Subsystem Regel-Datei
  • Login-Informationen (Benutzer-Anmeldungen/Anmelde-Versuche)
  • Rechte-Erweiterungen (su=/=sudo)
• Systemd-Journal
  • Dienst systemd-journald
  • Dienst chronyd
  • DHCPv4/DHCPv6 Events (NetworkManager, systemd-networkd)
  • Dienst auditd
  • Dienst kdump
  • Dienst ldconfig
  • Dienst sshd
  • Dienst systemd-udevd

• RELRO - RELocation Read-Only
• PIE - Position Independent Executable
• ASLR - Address Space Layout Randomization
• Fortify Source - Array Bounds-Checks etc.
• Stack protector/StackCanary - Stack Canary
• NX-No-Execute - Daten im Speicher als nicht ausführbar (NX=no execute) markieren

• Hintergrund-Informationen zu diesen Sicherheitsfunktionen: Notes on Build Hardening (December 15, 2018) https://blog.erratasec.com/2018/12/notes-on-build-hardening.html
• Studie von Sicherheitsfunktionen in Linux-Distributionen: Millions of Binaries Later: a Look Into Linux Hardening in the Wild (February 28, 2019) https://capsule8.com/blog/millions-of-binaries-later-a-look-into-linux-hardening-in-the-wild/