Linux Server Sicherheit Kursnotizen September/November 2025

• OpenPGP ist ein IETF Internet Standard für Dateiverschlüsselung. Der aktuelle Standard ist RFC 9580 https://datatracker.ietf.org/doc/html/rfc9580

• GnuPG ist eine vollständige und kostenlose Implementierung des OpenPGP-Standards gemäß RFC 4880 (auch bekannt als PGP). Mit GnuPG können Sie Ihre Daten und Ihre Kommunikation verschlüsseln und signieren. Es verfügt über ein vielseitiges Schlüsselverwaltungssystem sowie Zugriffsmodule für alle Arten von Verzeichnissen öffentlicher Schlüssel. GnuPG, auch bekannt als GPG, ist ein Befehlszeilentool mit Funktionen zur einfachen Integration in andere Anwendungen. Es steht eine Vielzahl von Frontend-Anwendungen und Bibliotheken zur Verfügung. GnuPG bietet außerdem Unterstützung für S/MIME und Secure Shell (ssh). In den letzten Jahren hat sich GnuPGP vom IETF OpenPGP Standard entfernt, GnuPGP unterstützt nur den älteren RFC 4880, nicht jedoch den neueren Standard RFC 9580. Webseite: https://gnupg.org

• Sequoia-PGP ist eine Implementation des OpenPGP-Standards in der Programmiersprache RUST

  Webseite: https://sequoia-pgp.org/

• Ein einfaches, modernes und sicheres Verschlüsselungstool (und eine Go-Bibliothek) mit kleinen expliziten Schlüsseln, ohne Konfigurationsoptionen und mit UNIX-ähnlicher Kombinierbarkeit: https://age-encryption.org

• XCA dient zum Erstellen und Verwalten von X.509-Zertifikaten, Zertifikatsanforderungen, privaten RSA-, DSA- und EC-Schlüsseln, Smartcards und CRLs. Alle Zertifizierungsstellen können rekursiv Unterzertifizierungsstellen signieren. Diese Zertifikatsketten werden übersichtlich dargestellt. Für eine einfache unternehmensweite Nutzung gibt es anpassbare Vorlagen, die für die Erstellung von Zertifikaten oder Anforderungen verwendet werden können.
• Kurz: X.509 graphisch und nachvollziehbar ;-)
• Webseite: https://www.hohnstaedt.de/xca/

• Prüfen, ob eine Debian Installations-CD/DVD "original" ist, d.h. vom Debian-Release Team stammt:
• CD-Rom ISO Image laden

wget https://debian.inf.tu-dresden.de/debian-cd/13.1.0/amd64/iso-cd/debian-13.1.0-amd64-netinst.iso

• SHA256 Fingerabdruck der Datei errechnen

openssl dgst -sha256 < debian-13.1.0-amd64-netinst.iso

• Datei mit den Hash-Prüfsummen laden

wget https://debian.inf.tu-dresden.de/debian-cd/13.1.0/amd64/iso-cd/SHA256SUMS

• Hash der ISO-Datei mit dem Hash in der Prüfsummendatei vergleichen
• Nun prüfen wir, ob die Datei mit den Hash-Prüfsummen original ist. Dabei wird die digitale Signatur (mittels GnuPG) über die Datei mit den SHA256-Hashes geprüft. Wir laden die Signatur der Hash-Prüfsummen vom Download-Server:

wget https://debian.inf.tu-dresden.de/debian-cd/13.1.0/amd64/iso-cd/SHA256SUMS.sign

• Releases der Debian-Distribution werden mit extra Schlüsseln des Debian-Release-Teams signiert. Wenn wir direkt versuchen, die Signatur auf der Datei zu prüfen, so bekommen wir einen Fehler, da wir den öffentlichen Schlüssel (ID DF9B9C49EAA9298432589D76DA87E80D6294BE9B) des Debian-Release-Teams nicht in unserem GPG-Schlüsselbund haben:

debian$ gpg --verify SHA256SUMS.sign SHA256SUMS
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: Signature made Sat Sep  6 21:54:28 2025 UTC
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Can't check signature: No public key

• Um die Signaturen prüfen zu können, importieren wir den Debian CD Signatur-Schlüssel in den eigenen GPG-Schlüsselring.

# sudo apt -y install dirmngr
# gpg  --keyserver keyring.debian.org --recv-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: key DA87E80D6294BE9B: public key "Debian CD signing key <debian-cd@lists.debian.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

• Fingerabdruck des Schlüssels anzeigen und mit den Daten auf https://www.debian.org/CD/verify.html abgleichen

gpg --finger  DF9B9C49EAA9298432589D76DA87E80D6294BE9B

• Signature auf der Prüfsummendatei prüfen

# gpg --verify SHA256SUMS.sign SHA256SUMS
gpg: Signature made Sat Sep  6 21:54:28 2025 UTC
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Good signature from "Debian CD signing key <debian-cd@lists.debian.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

• Um dem CD-ROM Image vertrauen zu können, sollten alle Prüfsummen und Signaturen stimmen.

• Die Debian-GPG Schlüssel zum verifizieren von Software-Paketen liegen im Verzeichnis /etc/apt/trusted.gpg.d/

• https://wiki.debian.org/SecureApt
• https://keyring.debian.org/
• https://ftp-master.debian.org/keys.html
• https://launchpad.net/debian/+source/debian-archive-keyring/+changelog
• https://debian-handbook.info/browse/stable/sect.package-authentication.html

• Debian Pakete sind über eine Signatur-Kette geschützt (anders als RPM Pakete bei RedHat/CentOS/Fedora, welche direkt durch eine GPG-Signatur geschützt sind)
• Die Hash-Prüfsummen der Debian-Pakete sind in den Paketlisten-Dateien hinterlegt (z.B. main/Contents-amd64). Die Hash-Prüfsummen der Paketlisten sind in der Release Datei hinterlegt, und diese Datei ist mit den GPG-Schlüssel des Debian-Release-Teams unterschrieben.
• Um nun ein beliebiges Debian-Paket zu prüfen
  • Errechne die SHA256 Prüfsumme des Pakets
  • Vergleiche diese Prüfsumme mit der Prüfsumme in der Paketliste der Architektur
  • Errechne die SHA256-Prüfsumme der Paketlisten Datei.

  wget https://debian.inf.tu-dresden.de/debian/dists/Debian13.1/main/binary-amd64/Packages.gz
  openssl dgst -sha256 < Packages.gz
  zcat Packages.gz | less
  

  • Lade die aktuelle Release-Datei für die Debian-Version:

  $ wget https://debian.inf.tu-dresden.de/debian/dists/Debian13.1/Release
  $ wget https://debian.inf.tu-dresden.de/debian/dists/Debian13.1/Release.gpg
  

  • Importiere die (öffentlichen) GPG-Schlüssel des Debian-Release Teams. Hat man keine (vertrauenswürdige Debian-Installation), so findet man die Schlüssel unter https://ftp-master.debian.org/keys.html

  $ gpg --import /etc/apt/trusted.gpg.d/debian-archive-*
  

  • Als letzter Schritt werden die Signaturen auf der Release-Datei geprüft

  gpg --verify Release.gpg Release
  

  • Alle Schritte dieser Prüfung müssen erfolgreich abgeschlossen sein, um der Installationsdatei (DEB-Paket) vertrauen zu können. Diese Prüfung wird von den Debian-Paketmanager-Programmen (apt, apt-get, aptitude, debootstrap) automatisch durchgeführt.

• Am Beispiel des offiziellen NGINX Repositories (neue NGINX Versionen, welche nicht in der Basis-Debian Distro enthalten sind)
• Lange Key-ID == Fingerprint des Schlüssels
• Key-ID mit Installations-Informationen auf der (TLS-gesicherten) NGINX Webseite abgleichen (https://nginx.org/en/linux_packages.html#Debian)

# sudo -s
# apt update
# apt -y install apt-transport-https ca-certificates
# curl -fsSL https://nginx.org/keys/nginx_signing.key > /etc/apt/trusted.gpg.d/nginx-signing-key.asc
# gpg --show-keys --with-fingerprint /etc/apt/trusted.gpg.d/nginx-signing-key.asc
pub   rsa4096 2024-05-29 [SC]
      8540 A6F1 8833 A80E 9C16  53A4 2FD2 1310 B49F 6B46
uid                      nginx signing key <signing-key-2@nginx.com>

pub   rsa2048 2011-08-19 [SC] [expires: 2027-05-24]
      573B FD6B 3D8F BC64 1079  A6AB ABF5 BD82 7BD9 BF62
uid                      nginx signing key <signing-key@nginx.com>

pub   rsa4096 2024-05-29 [SC]
      9E9B E90E ACBC DE69 FE9B  204C BCDC D8A3 8D88 A2B3
uid                      nginx signing key <signing-key-3@nginx.com>

• Es sollte der volle Fingerabdruck der Schlüssels ausgegeben werden (mit der NGINX Webseite vergleichen https://nginx.org/en/pgp_keys.html).
• NGINX Repository hinzufügen

# echo "deb http://nginx.org/packages/debian trixie nginx" > /etc/apt/sources.list.d/nginx.list

• NGINX installieren und starten

# apt update
Hit:1 http://nginx.org/packages/debian trixie InRelease
[...]
# apt install nginx
Installing:
  nginx

Installing dependencies:
  logrotate

Summary:
  Upgrading: 0, Installing: 2, Removing: 0, Not Upgrading: 0
  Download size: 1104 kB
  Space needed: 3797 kB / 6419 MB available
  Continue? [Y/n]
Get:1 http://nginx.org/packages/debian trixie/nginx amd64 nginx amd64 1.28.0-1~trixie [1042 kB]
Get:2 file:/etc/apt/mirrors/debian.list Mirrorlist [39 B]
Get:3 http://mirrors.digitalocean.com/debian trixie/main amd64 logrotate amd64 3.22.0-1 [62.0 kB]
Fetched 1104 kB in 0s (9442 kB/s)
Selecting previously unselected package logrotate.
(Reading database ... 49651 files and directories currently installed.)
Preparing to unpack .../logrotate_3.22.0-1_amd64.deb ...
Unpacking logrotate (3.22.0-1) ...
Selecting previously unselected package nginx.
Preparing to unpack .../nginx_1.28.0-1~trixie_amd64.deb ...
----------------------------------------------------------------------

Thanks for using nginx!

Please find the official documentation for nginx here:
 * https://nginx.org/en/docs/

Please subscribe to nginx-announce mailing list to get
the most important news about nginx:
 * https://nginx.org/en/support.html

Commercial subscriptions for nginx are available on:
 * https://nginx.com/products/

----------------------------------------------------------------------
Unpacking nginx (1.28.0-1~trixie) ...
Setting up logrotate (3.22.0-1) ...
Created symlink '/etc/systemd/system/timers.target.wants/logrotate.timer' → '/usr/lib/systemd/system/logrotate.ti
mer'.
logrotate.service is a disabled or a static unit, not starting it.
Setting up nginx (1.28.0-1~trixie) ...
Created symlink '/etc/systemd/system/multi-user.target.wants/nginx.service' → '/usr/lib/systemd/system/nginx.serv
ice'.
Processing triggers for man-db (2.13.1-1) ...
# systemctl start nginx
# systemctl status nginx

Der Linux-Kernel bietet einige Sicherheitfunktionen, welche zur Zeit der Übersetzung des Kernels aus den Quellen angeschaltet werden können. Einige dieser Funktionen haben negative Auswirkungen auf die Ausführungsgeschwindigkeit des Systems, so das diese Funktionen nicht in allen Distributionen gesetzt sind. In den Klammern sind die jeweiligen Konfigurationsnamen aufgeführt. In einem Linux-System können diese Namen in der Kernel-Konfigurationsdatei geprüft werden. Beispiel:

zcat /proc/config.gz | grep CONFIG_SECURITY_DMESG_RESTRICT

oder, wenn /proc/config.gz nicht vorhanden.

cat  /boot/config-$(uname -r) | grep CONFIG_SECURITY_DMESG_RESTRICT

• 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://web.archive.org/web/20190302014002/https://capsule8.com/blog/millions-of-binaries-later-a-look-into-linux-hardening-in-the-wild/

• 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

sysctl -a

• Permanente sysctl Einstellungen in /etc/sysctl.conf

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

• In der Datei /etc/pam.d/common-password 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 ist eine neue Schlüsselableitungsfunktion für Passwörter vom OpenWall Projekt. Es basiert auf scrypt (RFC 7914) von Colin Percival (früherer Sicherheitleiter des FreeBSD Projektes). Es schützt besser vor Brute-Force Angriffen als SHA512 und andere Schlüsselableitungsfunktionen.
• 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+, RHEL 9+, Kali Linux 2021.1+ und Ubuntu 22.04+. 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.
    • erst bei einer Passwortänderung mittels passwd wir der neue Yescrypt-Hash erzeugt
  • Beispiel Debian 10 SHA512 Hash in der /etc/shadow

  nutzer:$6$NtILOHbh$SZ1pFZKkJj/xqtrxqtSBrkOgRWQmXfv4tJhwlCfNkL7V4ft8G6eyLkVhxmvAs6DQsPuAmRqB7WVfJHMB5w0340:16442:0:99999:7:::
  

  • Beispiel Debian 11 Yescrypt Hash in der /etc/shadow

  nutzer:$y$j9T$YhVeKuFhMSSA91rR4FhwT/$9YTuWLhjyf1oqcPMoEkJFqSL.6YMRMQVMGaIgWIJyq9:18868:0:99999:7:::
  

  • Yescrypt in Debian 11 https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#pam-default-password
  • Yescrypt Informationen https://www.openwall.com/yescrypt/
  • yescrypt Dokumentation: https://github.com/openwall/yescrypt/blob/main/README

• 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 gleich zu halten.

ENCRYPT_METHOD SHA512
SHA_CRYPT_MIN_ROUNDS 1000000
SHA_CRYPT_MAX_ROUNDS 1000000

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

• Auch das BSI verabschiedet sich vom präventivem,regelmäßigen Passwort-Wechsel: https://www.heise.de/news/Passwoerter-BSI-verabschiedet-sich-vom-praeventiven-Passwort-Wechsel-4652481.html

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

visudo -f /etc/sudoers.d/apt-term-cat
----
user ALL=(root) /bin/cat /var/log/apt/term.log
----
user$ 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 Logdatei /var/log/dpkg.log unter den Benutzerberechtigungen des Benutzers root mit den Programm less ohne Eingabe eines Passworts anzuschauen (Dokumentation der Datei sudoers anschauen mit man sudoers)
• Der folgende Befehl sollte als Benutzer user ohne Eingabe eines Passworts funktionieren

  sudo less /var/log/dpkg.log
  

visudo -f /etc/sudoers.d/log-message-view
------
...
user  ALL=(root) NOPASSWD: /usr/bin/less /var/log/dpkg.log
...

• in einem anderen Terminal/Tmux-Fenster, teste sudo als Benutzer user

user$ sudo less /var/log/dpkg.log # <--- sollte ohne Eingabe des Passwort angezeigt werden
user$ sudo less /etc/shadow       # <--- darf nicht ohne Eingabe des Passwort angezeigt werden

• gibt es mit dieser Konfiguration ein Sicherheitsproblem?

• Ja - less und viele andere Programme können Unterprogramme aufrufen (z.B. eine Shell), welche dann mit root-Rechten läuft
• Lösung: NOEXEC:

user  ALL=(root) NOEXEC: /usr/bin/more /var/log/messages
user  ALL=(root) NOEXEC: /usr/bin/more /var/log/boot.log

• Benutzer user soll die Datei /etc/rsyslog.conf editieren dürfen
• in der Datei /etc/sudoers

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

• Eine Gruppe in sudo berechtigen

visudo -f /etc/sudoers.d/admins
%sudo  ALL=(ALL) NOPASSWD: ALL

• Priviligierte Shells-Sessions mit sudo

sudo -s # entspricht su
sudo -i # entspricht su -

     # 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

• 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

• user darf root werden

user ALL=(root) ALL

• Benutze sudo als Benutzer user um eine interaktive Shell zu bekommen

user$ sudo -i

• 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/

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

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

• Sudo for blue teams: how to control and log better https://www.sudo.ws/posts/2022/05/sudo-for-blue-teams-how-to-control-and-log-better/

• Lese die Man-Page zu doas
• Erstelle eine doas.conf Konfiguration (eine Zeile reicht) welche …
  • … es dem Benutzer user erlaubt Programme unter dem Benutzer root auszuführen
  • … der Benutzer nach der Eingabe des Passworts für einige Zeit den Befehl doas ohne weitere Eingabe des Passworts benutzen kann

• Inhalt der Datei /etc/doas.conf

permit persist user as root

• Units unter anderer uid/gid laufen lassen
• Zugriff auf Verzeichnisse beschränken
• Prozesslimits setzen
• Neue Systemd-Unit anlegen

systemctl edit --full --force simplehttp.service

• Inhalt der Systemd-Unit für einen einfachen Webserver auf Port 8080

[Unit]
Description=Python HTTP Server (do not use in production)

[Service]
Type=simple
Restart=on-failure
ExecStart=/usr/bin/python3 -m http.server 8080

# Namespace Spielereien
WorkingDirectory=/usr/share/doc
ReadOnlyDirectories=/proc /sys
InaccessibleDirectories=/var/log
PrivateTmp=yes

ProtectSystem=strict
ProtectHome=read-only

# Limits
# darf nicht forken
#LimitNPROC=1
# darf nicht ins fs schreiben
#LimitFSIZE=0

# laeuft als root. Capabilities
# entziehen
#CapabilityBoundingSet=~cap_chown,cap_net_raw
# setzen
#CapabilityBoundingSet=cap_net_raw
CapabilityBoundingSet=cap_net_bind_service

# laeuft als user. Capabilities
#User=gabi
#Group=users
DynamicUser=yes
AmbientCapabilities=cap_net_bind_service

• Erstelle die Systemd-Unit, starte den Dienst und teste den Webserver mit einem Browser auf http://serverXX.dane.onl:8080/

• 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
  

• System-Härtung von Systemd-Units unter Debian 13 (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
  

• Das Setzen von SUID- und SGID-Bits auf Dateien ist nicht erlaubt

  RestrictSUIDSGID=yes
  

• Maximaler Speicherverbrauch dieser Anwendung, muss ggf. an die Anwendung 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/Dateisystem

  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) – Beispiel für einen DNS-Server:

  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

• Ergänze die System-Unit für nginx.service mittels systemctl edit nginx.service um die oben genannten Sicherheits-Erweiterungen. Prüfe die Sicherheitswertung mit systemd-analyze security nginx.service 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

journalctl

• 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 (Default: 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=820ff0-19141a-983adc-229fdf/1dd3e0-35a4e900
  PASS: /var/log/journal/ab2fd7fc1dcf4914aedf7f14c2455bd5/system@0bfd1906769645fd8b567188f6017621-00000000000046e7-00063ff3f5276215.journal
  PASS: /var/log/journal/ab2fd7fc1dcf4914aedf7f14c2455bd5/system@0bfd1906769645fd8b567188f6017621-0000000000000001-00063fe08037565f.journal
  PASS: /var/log/journal/ab2fd7fc1dcf4914aedf7f14c2455bd5/system@0bfd1906769645fd8b567188f6017621-00000000000090b5-00063fff6aa89596.journal
  PASS: /var/log/journal/ab2fd7fc1dcf4914aedf7f14c2455bd5/system.journal
  PASS: /var/log/journal/ab2fd7fc1dcf4914aedf7f14c2455bd5/user-1000.journal
  

• 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

# apt install systemd-journal-remote

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

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

• 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)

• Wir arbeiten als Benutzer user, nicht als root
• Verezichnis für lokale Programmdateien anlegen

  $ cd /home/user
  $ mkdir -p /home/user/.local/bin
  

• Umgebungsvariable des Suchpfades für Programmdateien anpassen

  $ export PATH=/home/user/.local/bin:$PATH
  

• Das checksec.sh Verzeichnis über das angelegte Verzeichnis mounten

  $ sudo mount --bind /home/user/checksec.sh /home/user/.local/bin
  

• Prüfen das checksec.bash nun direkt gefunden wird

  $ which checksec.bash
  /home/user/.local/bin/checksec.bash
  

• Checksec aufrufen

  $ checksec.bash --kernel
  

• Bind-Mount mit Option noexec neu anhängen

  $ sudo mount -o noexec --bind -o remount /home/user/checksec.sh/ /home/user/.local/bin/
  

• checksec.bash ist nun nicht mehr ausführbar

  $ checksec.bash
  bash: /home/user/.local/bin/checksec.bash: Permission denied
  

• Stress erzeugen

apt install stress-ng
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 +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 und Controll-Groups entfernen

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

• Controll-Group-Daten können bei durch Systemd gestartete Prozesse im laufenden Betrieb angepasst werden

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

systemd-run stress-ng -c 3
systemd-run stress-ng -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/accounting.conf
-----
DefaultCPUAccounting=yes
DefaultIOAccounting=yes
DefaultBlockIOAccounting=yes
DefaultMemoryAccounting=yes
DefaultTasksAccounting=yes

• BlockIO… gilt als deprecated. Deshalb fehlt die Directive.

systemd-analyze cat-config /etc/systemd/system.conf   # pruefen

• Nicht alle Dateisysteme unterstützen alle erweiterten Attribute (EA). Unter Linux unterstützen die ext2/ext3/ext4/btrfs-Dateisysteme und das XFS-Dateisystem einige der EAs. Die Man-Page zum Dateisystemformat gibt Auskunft über die EA Unterstützung (z.B. man ext4).
• Anzeigen der erweiterten Attribute: lsattr
• Ändern der erweiterten Attribute: chattr
• Sicherheit von erweiterten Attribute (EA) unter Linux im Vergleich zu BSD: unter BSD können die Sicherheitsrelevanten EA (append, immutable) vom Benutzer root nur im Single-User Module (ohne Netzwerk) gelöscht werden. Unter Linux kann root die EA zu jedem Zeitpunkt entfernen!

• Installiere das Modul pam_warn.so fuer die Facility auth (zusätzlich session) in PAM-Dienst sshd
• Melde dich per ssh oder über das Web-Portal als Benutzer user an
• Prüfe die Syslog/Journal Ausgabe

• In Datei /etc/pam.d/sshd (ans Ende hinter allen @include)

auth       optional   pam_warn.so
session    optional   pam_warn.so

• Die neuen Log-Einträgen mit journalctl -f --grep pam_warn oder journalctl -f --facility=authpriv prüfen
• Als user einloggen

• 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 sshd konfiguriert, wirkt sich aber nicht aus (Datei /etc/pam.d/sshd)
• Lese die Man-Pages der PAM-Module für den Dienst sshd der auth-Funktionen, finde heraus, welches Modul das Login aller Nicht-Root-Benutzer verweigern kann, und wann es sich auswirkt.
• Aktiviere diese Funktion und teste diese aus. Versuche Dich mit dem normalen Benutzer per SSH über das Loopback-Interface anzumelden:

ssh user@localhost

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

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

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

• 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

apt install libpam-oath oathtool

• 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

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

• Beispiel: Passwort in HEX-Zahl umrechnen:

echo "secret" | od -x
0000000 6573 7263 0a74
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 - user

• 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 Einsatzgeniete:
  • Wegwerfbare Gast-Zugänge einrichten
  • Automatisches mit-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 Programme installieren

apt install auditd audispd-plugins

• Audit-Daemon Konfiguration anpassen (Grössen-Werte in MB)

$EDITOR /etc/audit/auditd.conf
----
space_left=4000
admin_space_left=2000
num_logs=10
max_log_file=<max-groesse-der-log-datei>
max_log_file_action=rotate

• Audit-Dämon anschalten (so dass er bei einem Restart neu gestartet wird) und prüfen das der Prozess läuft

systemctl enable --now auditd
systemctl status auditd

• Eine Audit-Policy erstellen

$EDITOR /etc/audit/rules.d/audit.rules

• Eine Beispiel-Policy:

## First rule - delete all
-D

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

## This determine how long to wait in burst of events
--backlog_wait_time 0

## Set failure mode to syslog
-f 1

# audit_time_rules - Record attempts to alter time through adjtime
-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules

# audit_time_rules - Record attempts to alter time through settimeofday
-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules

# audit_time_rules - Record Attempts to Alter Time Through stime
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules

# audit_time_rules - Record Attempts to Alter Time Through clock_settime
-a always,exit -F arch=b64 -S clock_settime -k audit_time_rules

# Record Attempts to Alter the localtime File
-w /etc/localtime -p wa -k audit_time_rules

# Record Events that Modify User/Group Information
# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

# Record Events that Modify the System's Network Environment
# audit_network_modifications
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k audit_network_modifications
-w /etc/issue -p wa -k audit_network_modifications
-w /etc/issue.net -p wa -k audit_network_modifications
-w /etc/hosts -p wa -k audit_network_modifications

#Record Events that Modify the System's Mandatory Access Controls
-w /etc/selinux/ -p wa -k MAC-policy

#Record Events that Modify the System's Discretionary Access Controls - chmod
-a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chmod  -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - chown
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - fchmod
-a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - fchmodat
-a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - fchown
-a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - fchownat
-a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - fremovexattr
-a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - fsetxattr
-a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - lchown
-a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - lremovexattr
-a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - lsetxattr
-a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - removexattr
-a always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Events that Modify the System's Discretionary Access Controls - setxattr
-a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

#Record Attempts to Alter Logon and Logout Events
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins

#Record Attempts to Alter Process and Session Initiation Information
-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session

#Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access

#Ensure auditd Collects Information on the Use of Privileged Commands
#
#  Find setuid / setgid programs then modify and uncomment the line below.
#
##  sudo find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
#
# -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged

#Ensure auditd Collects Information on Exporting to Media (successful)
-a always,exit -F arch=b64 -S mount -F auid>=500 -F auid!=4294967295 -k export

#Ensure auditd Collects File Deletion Events by User
-a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete

#Ensure auditd Collects System Administrator Actions
-w /etc/sudoers -p wa -k actions

#Ensure auditd Collects Information on Kernel Module Loading and Unloading
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

#Make the auditd Configuration Immutable
-e 2

• Die Policy kompilieren und prüfen

  augenrules --check
  

• die neue Policydatei in den Kernel laden

  augenrules --load
  

• aktive Regeln auflisten

  auditctl -l
  

• Status des Audit-Subsystems anzeigen

  # auditctl -s
  enabled 2
  failure 1
  pid 12901
  rate_limit 0
  backlog_limit 8192
  lost 0
  backlog 0
  backlog_wait_time 0
  loginuid_immutable 0 unlocked
  

• Alle Audit-Einträge zum Thema "sudo" zeigen

  ausearch -i -x sudo
  

• Report über fehlgeschlagende Anmeldeversuche

  ausearch -m USER_AUTH,USER_ACCT --success no
  

• Alle Audit-Meldungen für Benutzer UID 1000

  ausearch -ua 1000 -i
  

• Fehlgeschlagende Syscalls seit gestern

  ausearch --start yesterday --end now -m SYSCALL -sv no -i
  

• Zusammenfassung des Audit-Log

aureport

• Grafische Auswertung von Audit-Logs

$ sudo apt install graphviz gnuplot git
$ git clone https://github.com/cstrotm/audit-visualize
$ cd audit-visualize
$ chmod +x ./mkgraph
$ chmod +x ./mkbar

• Grafische Reports erstellen

$ sudo aureport -s -i --summary  | bash ./mkbar syscall
$ sudo aureport -f -i --summary --failed | bash ./mkbar failed-access
$ sudo aureport -e -i --summary | egrep -vi '(syscall|change)'
$ sudo aureport -e -i --summary | egrep -vi '(syscall|change)' | bash ./mkbar events2

• Syscall Benutzung von Programmen

$ sudo aureport -s -i | awk '/^[0-9]/ { printf "%s %s\n", $6, $4 }' | sort | uniq | bash ./mkgraph
Gzipping graph...
Graph was written to gr.png

• Welcher Benutzer führt welche Programme aus?

sudo aureport -u -i | awk '/^[0-9]/ { printf "%s %s\n", $4, $7 }' | sort | uniq | bash ./mkgraph

• Wer greift auf welche Dateien zu?

sudo aureport -f -i | awk '/^[0-9]/ { printf "%s %s\n", $8, $4 }' | sort | uniq | bash ./mkgraph

• Webseite: https://www.cisecurity.org/cis-benchmarks/

• Installation des Programms fscrypt zur Verwaltung von verschlüsselten Dateisystem-Onjekten:

  # apt install fscrypt
  

• fscrypt initialisieren

  # fscrypt setup
  

• Die ext4 Funktion "Verschlüsselung" im Dateisystem auf /dev/vda1 anschalten

  # tune2fs -O encrypt /dev/vda1
  

• Einen neuen Schlüssel dem Linux-Session-Keyring hinzufügen und dem Verzeichnis /encrypted/test zuordnen

  # mkdir -p /encrypted/test
  # fscrypt encrypt /encrypted/test/
  The following protector sources are available:
  1 - Your login passphrase (pam_passphrase)
  2 - A custom passphrase (custom_passphrase)
  3 - A raw 256-bit key (raw_key)
  Enter the source number for the new protector [2 - custom_passphrase]:
  Enter a name for the new protector: villa
  Enter custom passphrase for protector "villa":
  Confirm passphrase:
  "/encrypted/test/" is now encrypted, unlocked, and ready for use.
  

• Daten in das verschlüsselte Verzeichnis kopieren und die erweiterten BSD-Attribute der Dateien anzeigen. Es sollten die Attribute ---------E----e---- /encrypted/test/passwd erscheinen (E = encrypted, e = Datei mit "Extents", siehe auch man chattr)

  # cp /etc/passwd /encrypted/test
  # lsattr /encrypted/test
  ---------E----e------- /encrypted/test/passwd
  

• Dateisystem Schlüssel verwerfen (Dateien sind nicht mehr im Klartext sichtbar)

  # fscrypt lock /encrypted/test
  "/encrypted/test" is now locked.
  # ls -l /encrypted/test
  total 4
  -rw-r--r-- 1 root root 1684 Oct  1 14:17 2O2l3me829NsM_VbXeGiQaK5ANzWpC5stIA7XK7xIO3qAeskZ8CR_w
  

• LUKS Tools und LVM installieren

apt install cryptsetup lvm2

• Neues Physisches Volume in /dev/sda5 erstellen

# pvcreate /dev/sda5
  Physical volume "/dev/sda5" successfully created.

• Eine neue Volumegroup erstellen

# vgcreate crypt_vg /dev/sda5
  Volume group "crypt_vg" successfully created

• ein neues logisches Volume im LVM erstellen (in der Volumegroup crypt_vg):

lvcreate --size 500M --name crypt crypt_vg

• Ein verschlüsseltes Laufwerk auf dem LV erstellen

cryptsetup --verbose --verify-passphrase luksFormat \
    /dev/mapper/crypt_vg-crypt

• Das verschlüsselte Laufwerk im Linux-Device-Mapper anmelden

cryptsetup luksOpen /dev/mapper/crypt_vg-crypt crypt

• An dieser Stelle muss das neue Laufwerk nun im Device-Mapper auftauchen

ls -l /dev/mapper/crypt

• Das 'crypt' Laufwerk formatieren (hier ext4, andere Dateisysteme und SWAP sind möglich)

mkfs.ext4 /dev/mapper/crypt

• Ein leeres Verzeichnis anlegen und das neue Dateisystem dort mounten:

mkdir /crypt
mount /dev/mapper/crypt /crypt

• Das Dateisystem auf dem verschlüsselten Laufwerk mit Test-Daten füllen

# cp -a /etc /crypt/

• Konfigurationsdatei für verschlüsselte Laufwerke anlegen

$EDITOR /etc/crypttab

• Eintrag für unser verschlüsseltes Laufwerk

crypt /dev/mapper/crypt_vg-crypt  none luks,timeout=180

• Eintrag in der /etc/fstab

/dev/mapper/crypt     /crypt    ext4    defaults  0 0

• Partition in der /etc/fstab eintragen, Reboot testen

• LUKS Tools und LVM installieren

apt install cryptsetup lvm2

• Container-Datei erstellen (hier 100MB)

# dd if=/dev/urandom of=geheim.img bs=100M count=1 iflag=fullblock
1+0 records in
1+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.736483 s, 142 MB/s

• Loopback-Gerät mit Container-Datei verbinden

# losetup /dev/loop0 geheim.img

• Ein verschlüsseltes Laufwerk auf dem Loopback-Gerät erstellen

# cryptsetup --verbose --verify-passphrase luksFormat /dev/loop0

WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /root/geheim.img:
Verify passphrase:
Key slot 0 created.
Command successful.

• Das verschlüsselte Laufwerk im Linux-Device-Mapper anmelden

cryptsetup luksOpen /dev/loop0 crypt

• An dieser Stelle muss das neue Laufwerk nun im Device-Mapper auftauchen

ls -l /dev/mapper/crypt

• Das 'crypt' Laufwerk formatieren (hier ext4, andere Dateisysteme und SWAP sind möglich)

mkfs.ext4 /dev/mapper/crypt

• Ein leeres Verzeichnis anlegen und das neue Dateisystem dort mounten:

mkdir /crypt
mount /dev/mapper/crypt /crypt

• Das Dateisystem auf dem verschlüsselten Laufwerk mit Test-Daten füllen

# cp -a /etc /crypt/

• Konfigurationsdatei für verschlüsselte Laufwerke anlegen

$EDITOR /etc/crypttab

• Eintrag für ein verschlüsseltes Laufwerk in der /etc/crypttab

crypt /dev/mapper/crypt_vg-crypt  none luks,timeout=180

• Eintrag in der /etc/fstab

/dev/mapper/crypt     /crypt    ext4    defaults  0 0

• gocryptfs verwendet eine dateibasierte Verschlüsselung, die als mountbares FUSE-Dateisystem implementiert ist. Jede Datei in gocryptfs wird als eine entsprechende verschlüsselte Datei auf der Festplatte gespeichert. Die verschlüsselten Dateien können in jedem Ordner auf der Festplatte, einem USB-Stick oder sogar im Netzwerklaufwerk (CIFS/Samba, NFS, Nextcloud, Dropbox etc) gespeichert werden.
• Ein Vorteil der dateibasierten Verschlüsselung gegenüber der Festplattenverschlüsselung (Blockverschlüsselung wie dm-crypt) besteht darin, dass verschlüsselte Dateien mit Standardtools wie Nextcloud-Desktop oder rsync effizient synchronisiert werden können. Außerdem ist die Größe des verschlüsselten Dateisystems dynamisch und nur durch den verfügbaren Speicherplatz begrenzt.
• goCryptFS Webseite: https://nuetzlich.net/gocryptfs/

• Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248
• GitHub - s-macke/CoverFS: Zero-knowledge client-side encrypted network filesystem
• Speeding up Linux disk encryption
• fscrypt Quelldateien und Anleitung: https://github.com/google/fscrypt

• Spezifikation: https://www.first.org/cvss/specification-document

• Die Europäische CVE-Datenbank, betreut von der ENISA, ist eine Alternative zur US-CVE Datenbank https://euvd.enisa.europa.eu/

• OpenCVE = OpenSource Vulnerability Management Platform
  • Eine Plattform zur Filterung und Verwaltung von Sicherheitsmeldungen in Unternehmen und Organisationen
• https://www.opencve.io/, Source: https://github.com/opencve/opencve

• Personen und Rollen für die Bearbeitung eines Sicherheitsvorfalls benennen, Zuständigkeiten schriftlich dokumentieren.
• Kontaktadressen von Forensikern/Strafverfolgungsbehörden besorgen und bereithalten.
• Datei security.txt auf im Internet sichtbaren Servern ausrollen und aktuell halten (https://securitytxt.org/, RFC 9116 "A File Format to Aid in Security Vulnerability Disclosure").
• PGP/GPG/SMIME Schlüssel erstellen und aktuell halten. E-Mail-Verschlüsselung regelmässig benutzen, um Übung im Umgang mit verschlüsselter E-Mail zubehalten.
• Alternative Kommunikationswege (Mastodon, externes E-Mail-System, externer Web-Server) vorbereiten. Kunden über diese alternativen Kommunikationswege informieren!
• Forensik Live-Linux-CD-ROM/USB-Stick bereithalten und regelmässig üben (1/2 jährlich).
• Erstellen von Platten-Images üben.
• Ersatz-Hardware vorhalten (Festplatten, SSD), Speicherplatz für Platten-Images reservieren und getrennt von der übrigen IT Infrastruktur bereitstellen.
• Beutel für manipulationssichere Beweissicherung bestellen und "vor Ort" bereithalten (z.B. Rechnerraum, Rechenzentrum).
• Hardware-RAID meiden (Alternativen: Software RAID - DM-RAID, btrfs, zfs). Hardware-RAID macht die forensische Untersuchung von Festplatten schwierig, da die Forensiker über die gleiche RAID-Hardware verfügen müssen (= Zeitverlust im Notfall).
• Minimale-Installationen benutzen. Minimale Installationen des Betriebssystems und der Anwendungen verringern die Anzahl von Dateien welche bei einem Sicherheitsvorfall untersucht werden müssen.
• Datensparsamkeit - nur Daten, die nicht gespeichert werden, können nicht mißbraucht werden -> Datenhaltung kostet.
• Incident-Modus für die IT-Systeme definieren –> welche Teile der IT können im Fall eines Angriffs ohne starke Auswirkungen auf den Betrieb ausgeschaltet oder abgeschottet werden?
• Incident-Modus automatisiert per Configuration-Management System anschalten –> Testen
• Bei erkannten Angriffen 4 Augen-Prinzip beachten, nicht alleine arbeiten!

• Wenn die eigene Kommunikationsstruktur (z.B. E-Mail) betroffen ist, die alternativen Kommunikationswege benutzen (Mastodon, extern gehostete Website), Atlassian Statuspage https://www.atlassian.com/software/statuspage etc)
• Dokumentierte Notfall-Prozedur zur Kunden-Kommunikation vorhalten und vorab an das Incident-Team verteilen

• VM Snapshots erstellen (per GPG signieren)
• Von einem Forensik-Linux booten (Kali-Linux, Deft o.ä.)
• Revisionssichere Images (dcfldd, aff4) erstellen http://www.osforensics.com/tools/create-disk-images.html
• Images sofort nach der Erstellung per GPG signieren (mit externer Signaturdatei)
• Erst Platten-Images erstellen, dann System analysieren (Log-Dateien etc. anschauen).
• Festplatten ausbauen und durch fabrikneue Platten ersetzen, Festplatten mit kompromittiertem Daten versiegeln (lassen)
• Analyse des Einbruches auf den Read-Only-Dateisystem-Images (nicht auf den echten Platten, die echten Platten sind ein Beweismittel und dürfen nach der Versiegelung nicht angefasst werden)

• Server komplett neu aufsetzen (Docker container via dockerfile neu bauen, Foreman/Ansible/Salt etc, VM Templates)
• Festplatte(n) austauschen
• Nur Daten ohne ausführbare Teile (Maschinencode, Java, .NET, Python pyc, PHP, Scripte etc) zurückspielen
  • Bei der Einrichtung der Server schon auf eine Trennung von System, Anwendungen und Daten achten!
• Scripte neu erstellen, von einem bekannt sauberen Backup zurückspielen oder einzeln per Pair-Review (2 Personen Review) prüfen

• rhash ist ein Werkzeug zum schnellen Erstellen einer Hash-Datenbank von Dateien in einem Linux-System
• rhash eignet sich als Ad-Hoc Werkzeug beim arbeiten an einem Incident
• rhash Installation

apt install rhash

• Datenbank mit den Hash-Werten erstellen (Hash=SHA3/Keccak mit 224 bit, Datenbankformat wie bei BSD)

rhash -r --sha3-224 --bsd /etc -o hash.lst

• Datenbank anschauen

less hash.lst

• Datenbank sichern (in Produktionsumgebung)

scp hash.lst benutzer@sicherer-server.example.com

• Dateien gegen die Datenbank prüfen

rhash -r -c --bsd hash.lst

• Die Benutzer-Authentisierungsdateien durch Anlegen eines neuen Benutzers ändern

adduser intruder

• nochmal Dateien gegen die Datenbank prüfen

rhash -r -c --bsd hash.lst

• Nur die "nicht-OK" Dateien anzeigen

rhash --skip-ok -r -c --bsd hash.lst

• AIDE ist eine populäre Software um Einbrüche in Linux-Systemen zu erkennen
  • AIDE erstellt eine Datenbank mit kryptografischen Hashes der Dateien eines Linux-Systems
  • Nach Änderungen am System (z.B. Einspielen von Updates, Änderungen an den Konfigurationsdateien) muss die Datenbank neu aufgebaut werden
  • AIDE ist eine Implementierung der Idee hinter der kommerziellen Software "Tripwire"
  • AIDE benötigt vergleichsweise viel CPU und Hauptspeicher
  • AIDE sichert in der Standard-Konfiguration Dateihashes mittels vieler verschiede Hash-Algorithmen. Dies verbraucht viel Zeit und CPU-Leistung. Es wird daher empfohlen die Anzahl Hashes auf ein bis zwei zu beschränken.

• Samhain ist ein host-basierte Intrusion Detection System
  • Neben Änderungen an wichtigen Systemdateien überwacht Samhain das System auf ungewöhnliche Meldungen in den Log-Dateien, versteckten Prozessen, neuen geöffneten Netzwerk-Ports und vieles mehr
  • Dabei ist Samhain recht sparsam mit den Systemressourcen (Speicher, CPU)
  • Samhain ist Open-Source (Programmierer: Dr. Rainer Wichmann)
  • mehrere Server mit Samhain können mittels einer zentralen Web-Oberfläche (Beltane) überwacht und verwaltet werden. Beltane ist kommerzielle Software und nicht Open-Source.

• 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

apt install build-essential

• 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);

  if (child_pid < 0) {
    printf("Es konnte kein namespace erzeugt werden (Fehler %d)\n", child_pid);
    return 1;
  }

  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

• Docker bietet gegenüber dem Betrieb von klassischen Linux-Installationen (auf „bare Metal“ oder virtualisiert) einige Vorteile:
  • Anwendungen werden voneinander isoliert. Selbst die Bestandteile einer Anwendung (z.B. LAMP - Linux/Apache/MySQL/PHP) können in eigene Docker-Container ausgelagert und voneinander isoliert werden.
  • die Rechte einer Anwendung im Docker-Container kann per Seccomp-bpf und Linux-Capabilities beschränkt werden
  • die Sicht auf den Netzwerkstack kann für Anwendungen eingeschränkt werden (Admin-Netzwerk für Anwendungen nicht sichtbar)
  • Docker unterstützt ein Implementations-Design, bei dem Anwendungs-Programme und Daten getrennt gehalten werden (Anwendungen in Container-Images, Daten in Speicher-Volumes ausserhalb der Container)
  • Über Dockerfiles sind die Container jederzeit reproduzierbar. Bei einem Einbruch in einen Docker-Container kann dieser zu Beweiszwecken eingefroren werden und durch ein neues, sauberes Container-Image ersetzt werden
  • Docker-Container werden nicht per Software-Update aktualisiert, sondern durch ein neues Container-Image mit aktueller Software ersetzt. Hierdurch kann sich ein (auch bisher unbemerkter) Einbrecher nicht im System festsetzen
• Nachteile:
  • die Isolierung von Anwendungen durch Linux-Container-Virtualisierung ist nicht so stark und vollständig wie bei einer Voll-Virtualisierung (VMWare, HyperV, VirtualBox). Linux-Container können jedoch innerhalb einer Voll-Virtualisierung eingesetzt werden und somit werden die Vorteile beider Systeme genutzt
  • Anwendungs-Installationen müssen angepasst werden, um Programme und Daten sauber zu trennen
  • Docker erhöht die Komplexität der Installation
  • Docker-Verwaltungswerkzeuge (Kubernetes etc) erhöhen die Komplexität und haben ggf. eigene Sicherheitsprobleme

• Docker installieren und starten

apt install docker.io
usermod -aG docker <username>

• Docker testen

docker run hello-world

• Docker Image herunterladen

# docker pull almalinux
# docker images

• Ein Alma-Linux (eine weitere freie Distribution von Red Hat Enterprise Linux) mit Bash starten

# docker run --name=application1 -it almalinux /bin/bash
docker# dnf update -y
docker# dnf install -y procps httpd
docker# dnf clean all
docker# exit
# docker ps -a

• Mit laufendem Docker Container verbinden

docker attach application1

• Docker Container Statistiken anzeigen

# docker top <container>
# docker stats <container1> <container2> ...

• Einen weiteren Prozess im Docker Container ausfuehren

# docker exec -d <container> touch /etc/new-config
# docker exec -t -i <container> /bin/sh

• Docker Container stoppen

# docker stop application1

• Docker bei Applikations-Ende automatisch neu starten

docker run --restart=always
docker run --restart=on-failure:5

• Docker Container Konfiguration anzeigen -> siehe Go Template wie man nach Konfiguration-Informationen filtern kann https://golang.org/pkg/text/template/

docker inspect <container>
docker inspect --format '{{ .NetworkSettings.IPAddress }}' <container>

• Docker Container im Hintergrund (-d) starten

docker run --name <name> -d <image> <command>

• Ausgaben der Anwendung im Docker Container anschauen

docker logs <container>
docker logs -f <container>
docker logs --tail -f <container>
docker logs --tail 50 <container>

• Docker Log-Ausgaben können mittels eigener log drivers auf andere Ziele umgelenkt werden(json-file, syslog, none, …)

docker run --log-driver="syslog" ...

• Ein Docker Image aus einem Dockerfile (Docker-Image Bauanleitung) erstellen

mkdir -p docker-work
cd docker-work
$EDITOR Dockerfile
-----
# Debian with nginx
# Version 1
FROM debian:latest

MAINTAINER Linuxhotel Trainer

# Update image
RUN apt update
# Add httpd package. procps and iproute are only added to investigate the image later.
RUN apt -y install nginx
RUN echo container.example.com > /etc/hostname

# Create an index.html file
RUN bash -c 'echo "Your Web server test on Debian Docker Container is successful." >> /var/www/html/index.html'
# create a nginx start-command
CMD ["nginx", "-g", "daemon off;"]
------
docker build -t debian-nginx --no-cache .
docker run -d -t --name=deb-nginx1 -p 8080:80 debian-nginx

• Volumes

docker run -v <local-dir>:<container-dir>[:ro] ...

• Volumes im Dockerfile definieren. Hierdurch werden Volumes beim Erstellen des Containers ausserhalb des Containers erstellt (unter /var/lib/docker/... auf dem Linux-Host) und in den Container eingebunden

# Dockerfile
[...]
VOLUME /data
VOLUME /var/www/html

• installiere ein Image mit dem 'Caddy' Webserver (https://caddyserver.com) aus der Docker Hub Registry (abiosoft/caddy). Caddy ist ein in der Sprache go geschriebener Webserver, welcher automatisch TLS/x509 Zertifikate von Let's Encrypt besorgt und aktualisiert.
• starte einen Container aus dem Image, verbinde Port 2015 vom Container auf einen freien Port auf dem Host
• teste die Caddy-Webseite mit dem Firefox auf dem Laptop http://<ip-des-Laptop>:<port>
• starte eine Shell im Caddy-Webserver Container per docker exec. Suche das Verzeichnis mit den HTML-Dateien.
  • stoppe den Container, lösche den Container (docker rm)
  • erstelle ein leeres Verzeichnis auf dem Container-Host (Laptop) unter /srv/websites/html. Erstelle eine einfache HTML-Datei index.html in diesem Verzeichnis.
  • starte einen neuen Container, verbinde das Verzeichnis /srv/websites/html vom Container-Host in den Container (Parameter -v, siehe oben).
  • Teste den Webserver mit dem Firefox Browser
  • Ändere die Datei index.html unter /srv/websites/html, teste das die Änderungen im Browser sichtbar sind
  • erstelle einen neuen NGINX Container (auf Basis des NGINX Dockerfiles oben in der Anleitung), bei dem das Verzeichnis /srv/websites/html in den Webroot des NGINX-Webservers gemappt wird (Achtung: anderen Port als für den Caddy-Webserver benutzen. Beide Webserver-Container sollten zur gleichen Zeit aktiv sind)
  • Einige Befehle zum Probieren (als Benutzer root auf dem Host)

docker logs <container>   # Anzeige der Logausgaben des Hauptprozesses
docker top <container>    # Anzeige der Prozesse im Container
docker stats <container>  # Anzeige der vom Container benutzten Resourcen

• Docker Image History anschauen

docker images
docker history <image-name>

• Docker Image(s) in eine Datei sichern. Metadaten und Schichten bleiben erhalten

docker save -o mydockerapp.tar <image-name> [<image-name2>]

• Docker-Image aus einer Datei laden (welche mit docker save erstellt wurde)

docker load -i mydockerapp.tar

• Docker Container exportieren (nur das Dateisystem wird exportiert, die Schichten/Layer verschwinden)

docker ps -a
docker export -o mydockerapp.tar <container-name>
xz -v mydockerapp.tar

• Docker Container vom Tarball importieren

xzcat mydockerapp.tar.xz | docker import - <image-name>

• Docker Container in ein Image umwandeln (z.B. für forensische Analyse)

docker commit <container-ID> <image-name>

• Docker Registry als Docker-Container starten. Die Docker Registry benutzt Port 5000/tcp.

docker run -d -p 5000:5000 registry

• Ein Docker Image "taggen"

docker images
docker tag <images-id> localhost:5000/debian-nginx:01

• Image in die Registry laden (push)

docker push localhost:5000/debian-nginx:01

• Docker Image lokal löschen (Achtung: Docker Images können erst gelöscht werden, wenn keine aktiven under inaktiven Container dieses Image benuzten. Ggf. müssen erst die auf diese Images basierenden Container per docker rm <container> gelöscht werden)

docker rmi localhost:5000/debian-nginx:01
docker rmi debian:latest
docker images

• Image aus der lokalen Registy (neu) laden

docker pull localhost:5000/debian-nginx:01

• wenn die Kommunikation zwischen Registry und Docker-Client nicht über die Loopback-Schnittstellen läuft (nicht localhost), dann muss diese Kommunikation mit TLS/SSL abgesichert sein. Dazu muss auf der Registry ein x509 Zertifikat installiert werden. Optionen:
  • von Let's Encrypt ein x509 Zertifikat besorgen und einbauen. Da Let's Encrypt Zertifkate nur 3 Monate gültig sind, sollte dieser Prozess automatisiert und überwacht sein
  • ein x509 Zertifikat von einer Zertifizierungsstelle (CA) kaufen
  • Option ohne TLS: per SSH einen Tunnel von Port 5000 des Clients auf Port 5000 des Registry-Hosts aufbauen und den Docker-Client gegen den „localhost“ Port laufen lassen. Bonus: per Systemd-Socket-Activation auf dem Client kann der SSH-Tunnel automatisch aufgebaut werden.
• Liste der Images in einer lokalen Registry laden und anzeigen

curl -X GET http://localhost:5000/v2/_catalog | python -m json.tool

• Top ten most popular docker images each contain at least 30 vulnerabilities (Februar 2019): https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/

• keine SUID Programme im Container
• keinen "echten" Benutzer "root" (UID0) im Container (Capabilities benutzen)
• Anwendungen im Container nicht unter einem Root-Account betreiben
• Capabilities sparsam einsetzen (kein CAP_SYS_ADMIN)
• Dateien in /tmp sind keine Daten, nicht von extern mounten
• Programme (im Container) und Daten (ausserhalb des Containers) trennen
• sensitive Programme read-only in den Container mappen/mounten
• Container auf bekannte Sicherheitslücken der im Container benutzen Software überwachen
• Container oft und regelmässig auffrischen

• Beispiel-Regelwerk (generisch, muss ggf. für die eigene Repository angepasst werden)

 -w /etc/docker -k docker
-w /etc/docker/key.json -k docker
-w /etc/docker/daemon.json -k docker
-w /etc/docker/certs.d -k docker
-w /etc/sysconfig/docker -k docker
-w /etc/sysconfig/docker-network -k docker
-w /etc/sysconfig/docker-storage -k docker
-w /etc/sysconfig/docker-storage-setup -k docker
-w /usr/lib/systemd/system/docker.service -k docker
-w /usr/bin/docker-containerd -k docker
-w /usr/bin/docker-containerd-current -k docker
-w /usr/bin/docker-containerd-shim -k docker
-w /usr/bin/docker-containerd-shim-current -k docker
-w /usr/bin/docker -k docker
-w /usr/bin/docker-current -k docker
-w /usr/bin/docker-ctr-current -k docker
-w /usr/bin/dockerd -k docker
-w /usr/bin/dockerd-current -k docker
-w /usr/bin/container-storage-setup -k docker
-w /var/lib/docker -k docker
-w /var/run/docker.sock -k docker

• in der Datei /etc/sysconfig/docker

dockerd --tlsverify ...

• in der Datei /etc/sysconfig/docker

dockerd --userns-remap=default ...

• in der Datei /etc/sysconfig/docker

dockerd --disable-legacy-registry ...

• in der Datei /etc/sysconfig/docker, Format --default-ulimit <ulimit-spec>=<soft-limit>:<hard-limit>
• Information ueber ULIMIT Schluesselwoerter in /etc/security/limits.conf
• Default-Ulimit setzen

dockerd --default-ulimit nofile=50:150 --default-ulimit nproc=10:20

• Ulimit fuer einzelnen Container

docker run --ulimit nofile=20:50 ...

docker run -u dockeruser -d ...

• Docker Container mit beschraenkten Capabilities starten

docker run --cap-drop=all --cap-add [notwendige capabilities] ...

• Capabilities eines Prozesses in einem Docker Container herausfinden am Beispiel des nginx Webservers

 # Prozess-ID des nginx Prozesses herausfinden
docker exec $(docker ps -q) pgrep -a nginx
# Capabilities der Prozess-ID 1 (nginx) abfragen
docker exec $(docker ps -q) cat /proc/1/status | grep CapEff | awk '{print $NF}'
00000000a80425fb
# Capabilties dekodieren und Docker-Parameter ausgeben
capsh --decode=00000000a80425fb | echo "--cap-drop=all --cap-add={$(sed -e 's/.*=//' -e 's/cap_//g')}"
--cap-drop=all --cap-add={chown,dac_override,fowner,fsetid,kill,setgid,setuid,setpcap,net_bind_service,net_raw,sys_chroot,mknod,audit_write,setfcap}

• Die Capabilities unter –cap-add pruefen und ggf. einschraenken

• die Datei /etc/localtime im Container Read-Only setzen, verhindert, das die Zeitzone im Container veraendert wird

docker run -v /etc/localtime:/etc/localtime:ro

Docker Parameter	Beschreibung
–cpu-period	Laenge der CPU CFS (Completely Fair Scheduler) Zeitscheibe
–cpu-quota	CPU CFS (Completely Fair Scheduler) quota
–cpuset-cpus	Container an CPUs binden (0-3, 0,1).
–cpuset-mems	Container an Speicher-Nodes binden (0-3, 0,1) nur fuer NUMA Maschinen
–kernel-memory	Kernel Speicher-Limit
-m, –memory	Speicher Limit
–memory-reservation	Limit fuer Speicherreservierungen (Virtueller noch nicht benutzer Speicher)
–memory-swap	Vollstaendiges Speicherlimit (memory + swap), '-1' schaltet virtuellen Speicher (SWAP) aus

• Das Root-Dateisystem im Container „nur-lesend“ einbinden

docker run --read-only ...

• Container Volume nur-lesend einbinden

docker run -v /volume:ro ...

• Pfade des Hosts nur-lesend in den Container einbinden

docker run -v /srv/container/name:/srv:ro ...

Für Linux-Sicherheits-Module (LSM) auf Label Basis (Role Based Access Control, RBAC) kann der Benutzer, die Rolle, der Tyoe und der Level für einen Container festgelegt werden. LSM funktionieren nicht innerhalb von Containers, sondern nur für einen gesamten Container.

docker run --security-opt=[label=user:USER]

• Docker mit AppArmor Profilen benutzen https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor
• Docker Default AppArmor Profil: https://docs.docker.com/engine/security/apparmor/ https://github.com/docker/labs/tree/master/security/apparmor

• LWN A seccomp overview https://lwn.net/Articles/656307/
• Default Docker Seccomp Profile https://github.com/moby/moby/blob/master/profiles/seccomp/default.json
• Linux x86_64 syscall Tabelle https://filippo.io/linux-syscall-table/

  man syscalls
  

• Docker Container mit eigenem Seccomp Profil starten:

  docker run --security-opt=[seccomp=/pfad/zur/eignen/seccomo-profile.json]
  

• Gefahr eines Rowhammer Angriffs auf Speicherbereiche über VM/Containergrenzen https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_tuning_and_optimization_guide/chap-ksm

# systemctl status ksm
● ksm.service - Kernel Samepage Merging
   Loaded: loaded (/usr/lib/systemd/system/ksm.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mi 2017-10-25 19:20:35 CEST; 13h ago
  Process: 777 ExecStart=/usr/libexec/ksmctl start (code=exited, status=0/SUCCESS)
 Main PID: 777 (code=exited, status=0/SUCCESS)
    Tasks: 0
   Memory: 0B
   CGroup: /system.slice/ksm.service

Okt 25 19:20:35 notebook51 systemd[1]: Starting Kernel Samepage Merging...
Okt 25 19:20:35 notebook51 systemd[1]: Started Kernel Samepage Merging.

• Rowhammer Angriff: https://de.wikipedia.org/wiki/Rowhammer
• Attacking a co-hosted VM: A hacker, a hammer and two memory modules https://thisissecurity.stormshield.com/2017/10/19/attacking-co-hosted-vm-hacker-hammer-two-memory-modules/
• KSM ausschalten (mehrere Optionen)

# /usr/libexec/ksmctl stop
# echo 0 > /sys/kernel/mm/ksm/run
# systemctl disable ksm
# systemctl disable ksmtuned
# echo 2 > /sys/kernel/mm/ksm/run

• das mbox Programm bietet eine einfache, simple sandbox mittels CGroups und Namespaces. mbox kann benutzt werden um die Ausführung von unbekannten Programmen (Scripts, Binärprogramme) einzuschränken und zu überwachen https://github.com/tsgates/mbox

• https://github.com/omegaup/minijail
• https://lwn.net/Articles/700557/

• Docker nachimplementiert in 100 Zeilen Bash
• https://github.com/p8952/bocker

• Bei der ersten Verbindung zu einem neuen SSH-Server wird der Fingerprint des Servers angezeigt
  • Um "Machine-in-the-Middle" (MitM) Angriffe zu vermeiden sollte dieser Fingerabdruck geprüft werden
• SSH Fingerprint eines Schlüssels auf einem Server anzeigen (zur Prüfung eines ersten Logins)

ssh-keygen -l -f /etc/ssh/ssh_host_<algorithm>_key.pub

• Alternativ zur manuellen Prüfung der Server-Fingerabdrücke können diese im DNS abgelegt werden
  • SSH-Clients können den Fingerabdruck aus dem DNS laden und automatisch prüfen
• Beispiel SSHFP-Records

# dig sshfp smtp3.strotmann.de
smtp3.strotmann.de.     1800    IN      SSHFP   1 1 BE915F185EE68A333BDF3B700BB1259A690D2D62
smtp3.strotmann.de.     1800    IN      SSHFP   3 2 C791A1F8A0AD41D3F85FF9D30E5CDFFB8821D513E7BEE8AD328DF65F 3D07D25C
smtp3.strotmann.de.     1800    IN      SSHFP   3 1 F545E655EF7C6F0B3328C611352AD822A7F5B419
smtp3.strotmann.de.     1800    IN      SSHFP   1 2 AFCFB9EE88E5C0AE6108061AFC8DBD9ED39301FB2DF2D77E674693F3 59BADE00

• SSH Fingerprint im DNS hinterlegen (DNSSEC Absicherung empohlen!). SSHFP Records erstellen (auf dem Server, je ein Aufruf pro Schlüssel-Type (RSA, ECDSA, ED25519 …):

ssh-keygen -r <hostname> -f /etc/ssh/ssh_host_<algorithm>_key.pub

• SSH-Client für die Prüfung des SSH-Fingerabdrucks in DNS konfigurieren

ssh -o "VerifyHostKeyDNS ask" <hostname>

• in SSH-Config Datei übernehmen

$EDITOR ~/.ssh/config
----
HOST *
  VerifyHostKeyDNS ask

• Test ohne SSHFP Prüfung

ssh host.example.com
The authenticity of host 'host.example.com (2001:db8:2b6:0:ba27:ebff:fe12:30db)' can't be established.
ECDSA key fingerprint is SHA256:ue1FlRUMmkPNhgFE55yqnnFl58FOlMnDGheCxQn2tWg.
Matching host key fingerprint found in DNS.
ECDSA key fingerprint is MD5:2e:a1:3c:94:d0:cb:ed:85:67:2e:7a:85:1c:bc:f3:70.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

• mit VerifyHostKeyDNS yes gesetzt

ssh -v <host>
[...]
debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
[...]

• Wenn OpenSSH Probleme hat, die DNSSEC Authentizität der SSHFP zu prüfen, muss ggf. EDNS in der Resolver-Konfiguration des Linux eingeschaltet werden (der OpenSSH-Client verifiziert SSHFP-Records im DNS via DNSSEC, und die DNSSEC-Signaturen sind oft grösser 512 Byte und bedingen die EDNS(0)-Erweiterung des DNS welche DNS-Antworten bis 4K erlauben). Die übrige DNS-Infrastruktur muss auch DNSSEC agnostisch sein, d.h. DNSSEC Daten unverändert durchleiten.

$EDITOR /etc/resolv.conf
----
[...]
options edns0

• In vielen SSH-Installationen werden die IP-Adressen oder Domain-Namen der Ziel-Server in der Datei known_hosts in Klartext abgelegt
  • Dies ist problematisch wenn die SSH-Konfiguration von einem Angreifer geklaut wird: der Angreifer weiss daher sofort auf welchen Server die geklauten privaten Schlüssel benutzt werden können
• Bestehende known_hosts Datei hashen

ssh-keygen -H -f .ssh/known_hosts
rm .ssh/known_hosts.old

• SSH-Client-Konfiguration anpassen, so das neue Einträge gehashed werden. In der Datei .ssh/config

[...]
HashKnownHosts yes
[...]

• in dieser Übung arbeiten wir als Benutzer und als Administrator. Lege mit dem Übungs-Partner die Rolle fest (Benutzer oder Administrator) und führe die Übung durch. Danach wechselt die Rolle.
• Administrator: lege einen Benutzeraccount für den Kollegen/Kollegin vor/hinter Dir im Kurs an (Passwort und Benutzername absprechen)
• Administrator: OpenSSH Server installieren (wenn nicht schon geschehen)

sudo apt install openssh-server

• Benutzer: Teste aus, dass Du Dich auf dem System des Übungs-Partners einloggen kannst. Bei der ersten Kontaktaufnahme wird der Fingerprint des Servers angezeigt. Dieser Fingerprint kann über den Administrator des Servers angefragt werden.

user: ssh user@serverXX.dane.onl

• Benutzer: nach dem Test wieder aus dem fernen Rechner ausloggen
• Benutzer: als normaler Benutzer (user, nicht root) einen neuen SSH-Schlüssel erstellen (4096 RSA). Eine Passphrase vergeben.

user$ ssh-keygen -b 4096

• Benutzer: den öffentlichen Schlüssel per SSH auf den fernen Rechner übertragen:

user$ ssh-copy-id user@serverYY.dane.onl

• Es empfiehlt sich, die Schlüssel mit ssh-copy-id -i .ssh/... zu begrenzen
• Benutzer: Alternativ die Datei ~/.ssh/id_rsa.pub vom eigenen Rechner auf den fernen Rechner übertragen (z.B. per E-Mail senden) und den Administrator bitten, den eigenen Schlüssel in die Datei .ssh/authorized_keys einzutragen.
• Administrator: Nun sind die Schlüssel ausgetauscht, und wir können Anmeldung per Passwort auf dem Server-System abschalten. Als root Benutzer:

• Die Passphrase auf einem privaten SSH-Schlüssel kann belienig geändert werden:

ssh-keygen -p -f .ssh/id_ed25519

• Der SSH-Agent speichert die Passphrases der Schlüssel auf dem Client im Hauptspeicher. Hierdurch muss die Passphrase für Schlüssel nicht bei jeder Verbindung neu eingegeben werden.
• SSH-Agent starten (wird normalerweise in der Benutzer-Sitzung gestartet, z.B. über ".profile" oder systemd --user)

#entweder in der aktiven Shell
eval $(ssh-agent)
#oder als prefix-Befehl
ssh-agent tmux #oder bash

• Die privaten SSH-Schlüssel dem SSH-Agent hinzufügen

ssh-add
ssh-add <Schlüssel-Datei>

• Fingerprints aller Schlüssel im Agent anzeigen

ssh-add -l

• Alle Schlüssel im Agent anzeigen

ssh-add -L

• Agent sperren/entsperren

ssh-add -x
ssh-add -X

• Schlüssel im SSH-Agent löschen

ssh-agent -D

• Agent-Funktion an einem Jumphost weitergeben. Nun kann sich der Benutzer vom Jumphost mit Schlüssel an weiteren SSH-Servern anmelden

ssh -A <jumphost>

• Sicherheits-Probleme mit Agent-Forwarding!
  • https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/
  • https://michael.stapelberg.de/Artikel/ssh-conditional-tunneling
• Agent forwarding (ssh -A user@serverYY.dane.onl) kann von einem Angreifer auf dem "Jumphost" abgefangen werden (Socket zum Agent im /tmp-Verzeichnis des Jumphost).

• Über SSH Tunnel können beliebige Ports über die SSH Verbindung geleitet werden
• Praktische Illustration zu local und remote tunnels: (Quelle: https://iximiuz.com/ssh-tunnels/ssh-tunnels.png)
• Tunnel von Port 80 auf dem Server (serverYY) zu Port 8080 auf dem Client über serverXX

ssh -L 8080:serverYY:80 user@serverXX
ssh -L 8080:datenbank:80 user@serverXX

• Rückwärts-Tunnel: vom Ziel-System zurück auf den Client. Dieses Beispiel öffnet einen Tunnel von localhost:8000 auf dem Zielsystem auf Port 8000 des SSH-Clients

ssh -R 8000:serverXX:8000 user@serverXX

• Socks-Proxy Forwarding (Web-Browsen durch den Tunnel), im Browser die Socks-Proxy Konfiguration auf 127.0.0.1 Port 8080 setzen

ssh -CD 127.0.0.1:8080 nutzer@server

• OpenSSH hat in früherern Versionen standardmässig Schlüssel mit dem RSA-SHA1 Algorithmus erzeugt. Dieser Algorithmus gilt inzwischen als unsicher und werden bald mit einer neuen Version von OpenSSH nicht mehr unterstützt
  • Daher sollten Benutzer von OpenSSH testen, ob sie noch RSA-SHA1 Schlüssel benutzen und diese ggf. durch neue Schlüssel austauschen
  • Test mit RSA-SHA1 abgeschaltet. Klappt die Anmeldung, so wird ein anderer Schlüssel benutzt. Schlägt die Anmeldung fehlt, so sollte ein neuer Schlüssel für diesen Benutzer erstellt werden:

    ssh -oHostKeyAlgorithms=-ssh-rsa user@host
    

  • Gibt es die folgende Fehlermeldung, dann benutzt der Server noch alte RSA-SHA1 Schlüssel und diese Schlüssel sind in der lokalen known-hosts Datei eingetragen:

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
    It is also possible that a host key has just been changed.
    The fingerprint for the ECDSA key sent by the remote host is
    SHA256:/7MPZYXQhPQ0uwZaupxxUC0EDU7I2D+s8OQCLtN69rE.
    Please contact your system administrator.
    Add correct host key in /home/nutzer/.ssh/known_hosts to get rid of this message.
    Offending RSA key in /home/nutzer/.ssh/known_hosts:157
    ECDSA host key for ssh-host.example.com has changed and you have requested strict checking.
    Host key verification failed.
    

  • Der Server-Betreiber sollte den alten RSA-SHA1 Schlüssel vom Server entfernen
  • Der Benutzer sollte den Hash-Eintrag des RSA-SHA1 aus der Datei known-hosts entfernen und dann den Hash des neuen Schlüssels mit dem Betreiber des Servers (oder via DNS, siehe unten) abgleichen
• Empfohlene SSH Schlüssel-Algorithmen
  • RFC 8332 - RSA SHA-2 signature algorithms rsa-sha2-256/512.
  • RFC 5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer (ecdsa-sha2-nistp256/384/521)
  • RFC 8709 - Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol
• Informationen: OpenSSH 8.3 released (and ssh-rsa deprecation notice)

• Bei komplexen SSH-Konfigurationen ist es hilfreich, die SSH-Parameter pro Ziel-System in der lokalen SSH-Konfigurationsdatei für den Benutzer abzulegen. Fast alle Kommandozeilen-Optionen des SSH-Clients können in dieser Konfigurationsdatei festgelegt werden (siehe man ssh).
• Beispiel einer lokalen SSH-Konfigurationsdatei für einen Benutzer. Datei ~/.ssh/config

Host zielhost                                          # symbolischer Name
        Hostname zielhost.example.com                  # echter DNS-Name
	User user                                      # Standard Benutzer
	Compression yes                                # gzip Kompression an
	VerifyHostKeyDNS yes                           # Host-Key per DNS prüfen
	Port 65123                                     # SSH läuft auf diesem Port
	ProxyJump jumphost.example.com                 # Verbindung über Jumphost

• Der Konfigurationsparameter VisualHostKey in der Datei /.ssh/config zeigt eine visuelle Darstellung des Schlüssel-Hash jedes Ziel- und Jump-Host Servers an

VisualHostKey yes

• pam_ssh.so – per SSH Key Passphrase anmelden und Schlüssel in den Agent laden
• pam_sshauth.so – lokale Anmeldung durch erfolgreiche SSH-Anmeldung an einen fernen SSH Server –> E-Mail mit Beispielkonfiguration

–> E-Mail wenn Loesung fuer ssh_pam auf dem Server

• installiere pam_ssh

apt install libpam-ssh

• prüfe, ob sich schon SSH-Schlüssel unter /home/user/.ssh/ befinden. Wenn nicht, einen SSH-Schlüssel erstellen per ssh-keygen und für den Schlüssel eine Passphrase vergeben. Diese Passphrase sollte nicht das normale Benutzerpasswort sein.
• Konfiguriere pam_ssh als sufficient PAM-Modul für das grafische Login (Datei /etc/pam.d/gdm-password =, Facility =auth)
• Konfiguriere pam_ssh als optional PAM-Modul in /etc/pam.d/common-session (Facility session)
• Die grafische GUI verlassen und an der GUI eine Anmeldung per SSH-Passphrase versuchen
• Prüfen das der SSH-Agent gestartet ist und den/die Schlüssel geladen hat

ssh-add -l

• Socks-Proxy Forwarding (Web-Browsen durch den Tunnel), im Browser die Socks-Proxy Konfiguration auf 127.0.0.1 Port 8080 setzen
  • Option -C schaltet Kompression der Daten im Tunnel ein
  • Option -D schaltet den Socks-Proxy für den SSH-Tunnel ein

ssh -C -D 127.0.0.1:8080 nutzer@server

• A tilde (~) after an Enter is the escape sequence of SSH
• ~~ Tilde senden
• ~. SSH-Verbindung sofort stoppen
• ~<Ctrl-Z> SSH Sitzung in den Hintergrund senden (mit fg wieder in den Vordergrund holen)
• ~& SSH als 'daemon' in den Hintergrund senden und vom Terminal ablösen
• ~? Hilfe anzeigen.
• ~R neuen Sitzungschlüssel aushandeln
• ~C SSH Komandozeile anzeigen (kann benutzt werden um neue Tunnel in schon bestehende Verbindungen einzubauen)
• ~# bestehende SSH-Tunnel anzeigen

command="foobar" ssh-rsa AAAAB3Nza… calls "foobar" and only "foobar" upon every login with this key
from="computer" ssh-rsa AAAAB3Nza… allows access with this key only from the host "computer".

• Authorized-Keys via FUSE und DNS http://jpmens.net/2012/12/18/ssh-public-keys-on-a-dns-fuse/
• Authorized-Keys per TXT-Record im DNS (ohne FUSE) https://blog.cloudflare.com/flexible-secure-ssh-with-dnssec/

• Eine Gruppe für die CHROOT SSH Benutzer erstellen

groupadd sshusers
useradd -m -s /bin/bash -g sshusers sshguy
passwd sshguy

• Wir erzeugen ein neues root Verzeichnis, das chroot-Verzeichnis

mkdir -p /var/ssh-chroot/{dev,etc,lib,lib64,usr,bin,home}
mkdir -p /var/ssh-chroot/usr/bin
chown root: /var/ssh-chroot

• Die Gerätedatei /dev/null anlegen

mknod -m 666 /var/ssh-chroot/dev/null c 1 3

• Das Heimverzeichnis des Benutzers in das chroot kopieren

cp -R /home/sshguy /var/ssh-chroot/home/
chown -R sshguy /var/ssh-chroot/home/

• Wir kopieren einige Dateien aus /etc in das Verzeichnis etc innerhalb des chroot

cd /var/ssh-chroot/etc
cp /etc/ld.so.cache /etc/ld.so.conf /etc/nsswitch.conf /etc/resolv.conf .

• Der Benutzer soll bash und ls ausführen können, also kommen diese Dateien in die chroot

cd ../bin
cp /bin/ls /bin/bash .

• Für jedes Programm im chroot müssen wir nun die dynamischen Bibliotheken in das chroot Verzeichnis kopieren. Der ldd Befehl listet alle Bibliotheken

ldd /bin/ls
ldd /bin/bash

• Wir haben ein Skript, welches die Bibliotheken für ein Programm in das chroot kopiert:

mkdir ~/bin
$EDITOR ~/bin/l2chroot
----
#!/bin/bash
# Use this script to copy shared (libs) files to Apache/Lighttpd chrooted
# jail server.
# ----------------------------------------------------------------------------
# Written by nixCraft <http://www.cyberciti.biz/tips/>
# (c) 2006 nixCraft under GNU GPL v2.0+
# + Added ld-linux support
# + Added error checking support
# ------------------------------------------------------------------------------
# See url for usage:
# http://www.cyberciti.biz/tips/howto-setup-lighttpd-php-mysql-chrooted-jail.html
# -------------------------------------------------------------------------------
# Set CHROOT directory name
BASE="/var/ssh-chroot"

[ ! -d $BASE ] && mkdir -p $BASE || :

# iggy ld-linux* file as it is not shared one
FILES="$(ldd $1 | awk '{ print $3 }' |egrep -v ^'\(')"

echo "Copying shared files/libs to $BASE..."
for i in $FILES
do
  d="$(dirname $i)"
  [ ! -d $BASE$d ] && mkdir -p $BASE$d || :
  /bin/cp $i $BASE$d
done

# copy /lib/ld-linux* or /lib64/ld-linux* to $BASE/$sldlsubdir
# get ld-linux full file location
sldl="$(ldd $1 | grep 'ld-linux' | awk '{ print $1}')"
# now get sub-dir
sldlsubdir="$(dirname $sldl)"

if [ ! -f $BASE$sldl ];
then
  echo "Copying $sldl $BASE$sldlsubdir..."
  /bin/cp $sldl $BASE$sldlsubdir
else
  :
fi

• Script ausführbar machen

chmod +x ~/bin/l2chroot

• Das Script benutzen, um die Bibliotheken in das chroot zu kopieren

l2chroot /var/ssh-chroot/bin/ls
l2chroot /var/ssh-chroot/bin/bash

• Prüfen, das Bibliotheks-Dateien kopiert wurden

ls -l /var/ssh-chroot/lib64
ls -l /var/ssh-chroot/lib/x86_64-linux-gnu/

• Einen Hardlink für BASH in /usr/bin im chroot erstellen

ln bin/bash usr/bin/

• Manueller Test der chroot Umgebung:

chroot /var/ssh-chroot/ /bin/bash

• Chroot für die Gruppe sshusers in der SSH-Konfiguration einrichten (Konfiguration am Ende der Datei anfügen)

$EDITOR /etc/ssh/sshd_config
----
Match group sshusers
          ChrootDirectory /var/ssh-chroot/
          X11Forwarding no
          AllowTcpForwarding no
	   PasswordAuthentication yes
----

• SSH-Daemon neu starten

systemctl restart sshd

• Ausprobieren:

ssh sshguy@localhost

• Fertig!

• Encrypt and decrypt a file using SSH keys https://www.bjornjohansen.com/encrypt-file-using-ssh-key

https://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly.html https://github.com/ThomasHabets/simple-tpm-pk11

• Original von Jan-Piet Mens mit Benachrichtigung via MQTT: https://jpmens.net/2018/03/25/alerting-on-ssh-logins/
• zentralisierte Benachrichtigung bei SSH-Logins auf einem Rechner der eigenen IT-Infrastruktur. Kommunikation zwischen SSH-Server und zentraler Monitoring-Instatnz über leichtgewichtiges UDP, E-Mail Kommunikationsparameter werden zentral verwaltet.
• Quellcode des hare Programms (PAM-Modul für die SSH-Server)

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <netdb.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <memory.h>
#include <sys/socket.h>

/*
 * hare.c (C)2018 by Jan-Piet Mens <jp@mens.de>
 */

#define PORTNO  8035

#define env(K)  ( getenv(K) ? getenv(K) : "<unknown>" )

int main(int argc, char **argv)
{
        struct sockaddr_in servaddr;
        unsigned long addr;
        int sockfd;
        char *host = argv[1], buf[BUFSIZ], myhostname[BUFSIZ];
        char *pamtype = env("PAM_TYPE");        /* Linux */
        char *pamsm = env("PAM_SM_FUNC");       /* FreeBSD https://www.freebsd.org/cgi/man.cgi?query=pam_exec */

        if (strcmp(pamtype, "open_session") != 0 && strcmp(pamsm, "pam_sm_open_session") != 0) {
                fprintf(stderr, "Neither PAM open_session nor pam_sm_open_session detected\n");
                return 0;
        }

        if (argc != 2) {
                fprintf(stderr, "Usage: %s address\n", *argv);
                exit(2);
        }

        if (gethostname(myhostname, sizeof(myhostname)) != 0)
                strcpy(myhostname, "?");

        snprintf(buf, sizeof(buf), "%s login to %s from %s via %s",
                env("PAM_USER"),
                myhostname,
                env("PAM_RHOST"),
                env("PAM_SERVICE"));

        addr = inet_addr(host);

        memset(&servaddr, 0, sizeof(servaddr));
        servaddr.sin_family = AF_INET;
        servaddr.sin_port = htons(PORTNO);
        memcpy((void *)&servaddr.sin_addr, (void *)&addr, sizeof(addr));

        sockfd = socket(AF_INET, SOCK_DGRAM, 0);

        if (sendto(sockfd, (void *)buf, strlen(buf), 0, (struct sockaddr *) &servaddr, sizeof(servaddr)) < 0) {
                perror("sendto");
        }
        return (0);
}

• Übersetzen und Installieren des hare Programms (ggf. das Paket gcc und build-essential installieren)

gcc -O2 -o hare hare.c
sudo cp hare /usr/local/sbin

• das hare Programm in die PAM-Konfiguration /etc/pam.d/sshd eintragen. Ziel-IP ist der Server des Trainers (192.168.1.241)

[...]
session    optional     pam_exec.so /usr/local/sbin/hare <ip-des-hare-servers>
[...]

• der zentrale Python-Server /usr/local/bin/hared.py, mit der Funktion pro SSH-Login eine Benachrichtigungs-Mail zu versenden (läuft auf dem Server des Trainers)

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import socket
import json
import smtplib, ssl
import random
import string
import datetime

__author__    = 'Jan-Piet Mens <jp()mens.de> / Carsten Strotmann <carsten()strotmann.de>'

myhostname     = "debian.example.com" # Domain-Name des E-Mail Senders (diese Maschine)
smtp_server    = "mail.example.com" # Name of the Mail-Server
smtp_port      = "587"  # SMTP with STARTTLS
sender_email   = "servernotification@example.com"
receiver_email = "admin@example.com"
smtp_user      = "admin"
smtp_password  = "secret"

server_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server_socket.bind(('', 8035))

while True:
    message, address = server_socket.recvfrom(1024)
    host, port = address

    data = {
        'host' : host,
        'msg'  : message,
    }

    js = json.dumps(str(data))
    # print(js)


    message = "To: <{}>\n".format(receiver_email)
    message = message + "From: <{}>\n".format(sender_email)
    message = message + "Message-Id: <{}@example.com>\n".format(''.join(random.choices(string.ascii_uppercase + string.digits, k=10)))
    time = datetime.datetime.now()
    message = message + "Date: {} \n".format(time.strftime('%d %b %Y  %H:%M:%S %z'))
    message = message + "Subject: SSH Login to {}\n\n".format(data["host"])
    message = message + "SSH Login into {} detected, Message: {}".format(data["host"], data["msg"])

    # Create a secure SSL context
    context = ssl.create_default_context()
    # if the TLS certificate of the mail server does not match
    # the mail servers hostname or domain-name, disable hostname checking
    # context.check_hostname = False
    server = smtplib.SMTP()
    # Try to log in to server and send email
    try:
        server.connect(smtp_server,smtp_port)      # Connect to the server
        server.ehlo(myhostname)                    # Send EHLO
        server.starttls(context=context)           # TLS Secure the connection
        server.ehlo(myhostname)                    # Another EHLO, now TLS secured
        server.login(smtp_user, smtp_password)     # Login to the server

        server.sendmail(sender_email, receiver_email, message) # send the mail
    except Exception as e:
        # Print any error messages to stdout
        print("Error: ", e)
    finally:
        if (server):
            server.quit()

• Quellen
  • SSH Security https://stribika.github.io/2015/01/04/secure-secure-shell.html
  • Secure Secure Shell Wiki: https://github.com/stribika/stribika.github.io/wiki/Secure-Secure-Shell
• SSH Server Konfiguration öffnen

$EDITOR /etc/ssh/sshd_config

• Nur Protokoll Version 2 erlauben

Protocol 2

• Sichere Schlüssel-Austausch-Verfahren

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

• neue DH Moduli für "diffie-hellman-group-exchange-sha256" (Achtung, dauert lange!) Hintergründe unter http://weakdh.org

ssh-keygen -G /etc/ssh/moduli.all -b 4096
ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
mv /etc/ssh/moduli.safe /etc/ssh/moduli
rm /etc/ssh/moduli.all
# Bei SELinux Systemen
chcon -v --type=etc_t /etc/ssh/moduli

• EC-ED25519-Kurve Schlüssel bevorzugen

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

• Sichere symmetrische Verschlüsselungs-Algorithmen

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

• Sichere Message-Authenication-Codes (MAC)

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

• Host-Keys neu erzeugen (Achtung: Clients werden Warnungen bekommen, Kunden und Kollegen informieren!)

cd /etc/ssh
rm ssh_host_*key*
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
# rsa-sha2-512
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

• Nach dem Erstellen neuer Schlüssel den SSH Server neu starten

systemctl restart sshd

• SSH Client Parameter testen

ssh -Q cipher
ssh -Q cipher-auth
ssh -Q mac
ssh -Q kex
ssh -Q key

• Jetzt nochmal per SSH auf dem fernen Rechner einloggen, -v Zeigt die Kommunikationsparameter an

user$ ssh -v nutzer@serverYY.dane.onl

• Hier sollte jetzt eine Warnung ausgegeben worden sein, da die Host-Schlüssel nicht mehr mit den Fingerprints in der known_hosts Datei übereinstimmen. Den Admin des fernen Servers fragen, ob er die Schlüssel auf dem Rechner neu erstellt hat. Wenn der Admin dies bestätigt, dann er Texteditor den alten Fingerprint aus der ~/.ssh/known_hosts Datei löschen.
• SSH Client ~/.ssh/config

VerifyHostKeyDNS yes
VisualHostKey yes

• (Basic) SSH Keys Part 1: Simple setup + ProxyJump http://bad.network/basic-ssh-keys-part-1-simple-setup-proxyjump.html
• (Basic) SSH Keys Part 2: Agent forwarding, Adding Keys http://bad.network/basic-ssh-keys-part-2-agent-forwarding-adding-keys.html
• Using a U2F/FIDO key with OpenSSH https://xosc.org/u2fandssh.html
• Cryptographic Signing using ssh-keygen(1) with a FIDO Authenticator https://undeadly.org/cgi?action=article;sid=20201016053038
• SCP - Familiar, Simple, Insecure, and Slow https://goteleport.com/blog/scp-familiar-simple-insecure-slow/
• OpenSSH 9.0 Release Notes

  This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default.

  • https://www.openssh.com/txt/release-9.0

• ShellCheck ist ein Programm welches Sicherheits-Probleme (und andere Probleme) in Shell-Skripten meldet

apt install shellcheck

• Ein Shell-Skript laden

wget https://raw.githubusercontent.com/menandmice-services/dns-resolver-monitoring/refs/heads/master/dnsresolver-check.sh

• Dieses Shell-Skript prüfen

shellcheck dnsresolver-check.sh 

• Ausgabe

In dnsresolver-check.sh line 58:
    echo -n " $@ "
              ^-- SC2145 (error): Argument mixes string and array. Use * or separate argument.


In dnsresolver-check.sh line 86:
            local FILE=$(readlink -m "${BASH_SOURCE[1]}")
                  ^--^ SC2155 (warning): Declare and assign separately to avoid masking return values.


In dnsresolver-check.sh line 98:
    [[ $STEP_OK -eq 0 ]]  && echo_success || echo_failure
                          ^-- SC2015 (info): Note that A && B || C is not if-then-else. C may run when A is true.
[...]
For more information:
  https://www.shellcheck.net/wiki/SC2145 -- Argument mixes string and array. ...
  https://www.shellcheck.net/wiki/SC2155 -- Declare and assign separately to ...
  https://www.shellcheck.net/wiki/SC2015 -- Note that A && B || C is not if-t...

• https://moldstud.com/articles/p-shell-scripting-security-how-to-protect-your-scripts-from-vulnerabilities
• https://developer.apple.com/library/archive/documentation/OpenSource/Conceptual/ShellScripting/ShellScriptSecurity/ShellScriptSecurity.html
• https://github.com/koalaman/shellcheck#user-content-installing

• BCC ist die BPF Compiler Collection, eine Sammlung von Tools und eBPF Programmen

  

• BCC Programme sind abhängig von der jeweiligen Kernel-Version und müssen daher auf der Maschine mit Hilfe der aktuellen Kernel-Header kompiliert werden. Das Kompilieren geschied im Hintergrund beim Aufruf des Wrapper-Scripts.

# apt install bpfcc-tools bpfcc-lua bpftrace python3-bpfcc
# apt install linux-headers-$(uname -r)

• Unter Debian enden alle BCC Programme auf -bpfcc:

  # ls -l /usr/sbin/*bpfcc
  -rwxr-xr-x 1 root root 34536 Feb  4  2019 /usr/sbin/argdist-bpfcc
  -rwxr-xr-x 1 root root  1648 Feb  4  2019 /usr/sbin/bashreadline-bpfcc
  -rwxr-xr-x 1 root root  4231 Feb  4  2019 /usr/sbin/biolatency-bpfcc
  -rwxr-xr-x 1 root root  5066 Feb  4  2019 /usr/sbin/biosnoop-bpfcc
  -rwxr-xr-x 1 root root  6387 Feb  4  2019 /usr/sbin/biotop-bpfcc
  -rwxr-xr-x 1 root root  1721 Feb  4  2019 /usr/sbin/bitesize-bpfcc
  -rwxr-xr-x 1 root root  2453 Feb  4  2019 /usr/sbin/bpflist-bpfcc
  -rwxr-xr-x 1 root root  6339 Feb  4  2019 /usr/sbin/btrfsdist-bpfcc
  -rwxr-xr-x 1 root root 10101 Feb  4  2019 /usr/sbin/btrfsslower-bpfcc
  -rwxr-xr-x 1 root root  4674 Feb  4  2019 /usr/sbin/cachestat-bpfcc
  [...]
  

• Im folgenden werden einige BCC Tools vorgestellt, welche für die Sicherheit von Linux-Servern interessant sind

• bpftrace ist eine kleine Programmiersprache (ähnlich wie awk), welche es Administratoren ermöglicht, kleine eBPF Scripts zu schreiben
  • Homepage https://bpftrace.org/
  • Github Source Repository https://github.com/iovisor/bpftrace
• Histogram-Daten werden in der Regel nach dem Beenden des Script mit CTRL+C ausgegeben
• Unter Debian liegen die mitgelieferten bpftrace Programme unterhalb von /usr/sbin/ und haben die Dateiendung .bt (für bpftrace)

# ls /usr/sbin/*.bt
/usr/sbin/bashreadline.bt  /usr/sbin/execsnoop.bt       /usr/sbin/pidpersec.bt  /usr/sbin/tcpconnect.bt
/usr/sbin/biolatency.bt    /usr/sbin/gethostlatency.bt  /usr/sbin/runqlat.bt    /usr/sbin/tcpdrop.bt
/usr/sbin/biosnoop.bt      /usr/sbin/killsnoop.bt       /usr/sbin/runqlen.bt    /usr/sbin/tcpretrans.bt
/usr/sbin/bitesize.bt      /usr/sbin/loads.bt           /usr/sbin/statsnoop.bt  /usr/sbin/vfscount.bt
/usr/sbin/capable.bt       /usr/sbin/mdflush.bt         /usr/sbin/syncsnoop.bt  /usr/sbin/vfsstat.bt
/usr/sbin/cpuwalk.bt       /usr/sbin/oomkill.bt         /usr/sbin/syscount.bt   /usr/sbin/writeback.bt
/usr/sbin/dcsnoop.bt       /usr/sbin/opensnoop.bt       /usr/sbin/tcpaccept.bt  /usr/sbin/xfsdist.bt

• Beispiel eines bpftrace Scriptes

# cat /usr/sbin/syscount.bt
#!/usr/bin/env bpftrace
/*
 * syscount.bt  Count system callls.
 *              For Linux, uses bpftrace, eBPF.
 *
 * This is a bpftrace version of the bcc tool of the same name.
 * The bcc versions translates syscall IDs to their names, and this version
 * currently does not. Syscall IDs can be listed by "ausyscall --dump".
 *
 * Copyright 2018 Netflix, Inc.
 * Licensed under the Apache License, Version 2.0 (the "License")
 *
 * 13-Sep-2018  Brendan Gregg   Created this.
 */

BEGIN
{
        printf("Counting syscalls... Hit Ctrl-C to end.\n");
        // ausyscall --dump | awk 'NR > 1 { printf("\t@sysname[%d] = \"%s\";\n", $1, $2); }'
}

tracepoint:raw_syscalls:sys_enter
{
        @syscall[args->id] = count();
        @process[comm] = count();
}

END
{
        printf("\nTop 10 syscalls IDs:\n");
        print(@syscall, 10);
        clear(@syscall);

        printf("\nTop 10 processes:\n");
        print(@process, 10);
        clear(@process);
}

• A brief introduction to XDP and eBPF https://blogs.igalia.com/dpino/2019/01/07/a-brief-introduction-to-xdp-and-ebpf/
• Dive into BPF: a list of reading material https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/
• A curated list of awesome projects related to eBPF: https://github.com/zoidbergwill/awesome-ebpf
• BPF, eBPF, XDP and Bpfilter… What are These Things and What do They Mean for the Enterprise? https://www.netronome.com/blog/bpf-ebpf-xdp-and-bpfilter-what-are-these-things-and-what-do-they-mean-enterprise/
• BCC Tutorial https://github.com/iovisor/bcc/blob/master/docs/tutorial.md
• Learn eBPF Tracing: Tutorial and Examples http://www.brendangregg.com/blog/2019-01-01/learn-ebpf-tracing.html
• Network debugging with eBPF (RHEL 8) https://developers.redhat.com/blog/2018/12/03/network-debugging-with-ebpf/
• Using eBPF for network traffic analysis https://www.ntop.org/wp-content/uploads/2018/10/Sabella.pdf
• BCC Referenz: https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md
• eBPF Summit 2021:
  • Tag 1: https://www.youtube.com/watch?v=Kp3PHPuFkaA
  • Tag 2: https://www.youtube.com/watch?v=ZNtVedFsD-k
• eBPF Foundation https://ebpf.io/
• Comparing SystemTap and bpftrace https://lwn.net/Articles/852112/
• nsjail | A light-weight process isolation tool, making use of Linux namespaces and seccomp-bpf syscall filters (with help of the kafel bpf language)
• How io_uring and eBPF Will Revolutionize Programming in Linux – The New Stack
• Auch in eBPF kann es Sicherheits-Fehler geben Zero Day Initiative — CVE-2020-8835: Linux Kernel Privilege Escalation via Improper eBPF Program Verification
• boopkit - Linux eBPF backdoor over TCP. Spawn reverse shells, RCE, on prior privileged access. https://github.com/kris-nova/boopkit
• BPFDoor — an active Chinese global surveillance tool https://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896?gi=bd3c470d93a8
• hBPF = eBPF in hardware (An extended Berkley Packet Filter CPU written entirely in Python3 for PC and FPGA) https://github.com/rprinz08/hBPF

• https://ebpf.linux-sicherheit.org/