Red Hat Enterprise Linux 8 Update Kurs-Notizen

• die Konfiguration von dnf liegt unter /etc/dnf/dnf.conf.
• die Repository-Konfigurationen liegen weiterhin unter /etc/yum.repos.d

# ls -l /etc/yum.repos.d/CentOS-*
-rw-r--r--. 1 root root  731 Jan  2 16:21 /etc/yum.repos.d/CentOS-AppStream.repo
-rw-r--r--. 1 root root  712 Jan  2 16:21 /etc/yum.repos.d/CentOS-Base.repo
-rw-r--r--. 1 root root  798 Jan  2 16:21 /etc/yum.repos.d/CentOS-centosplus.repo
-rw-r--r--. 1 root root 1043 Jan  2 16:21 /etc/yum.repos.d/CentOS-CR.repo
-rw-r--r--. 1 root root  668 Jan  2 16:21 /etc/yum.repos.d/CentOS-Debuginfo.repo
-rw-r--r--. 1 root root  756 Jan  2 16:21 /etc/yum.repos.d/CentOS-Extras.repo
-rw-r--r--. 1 root root  338 Jan  2 16:21 /etc/yum.repos.d/CentOS-fasttrack.repo
-rw-r--r--. 1 root root  738 Jan  2 16:21 /etc/yum.repos.d/CentOS-HA.repo
-rw-r--r--. 1 root root  928 Jan  2 16:21 /etc/yum.repos.d/CentOS-Media.repo
-rw-r--r--. 1 root root  736 Jan  2 16:21 /etc/yum.repos.d/CentOS-PowerTools.repo
-rw-r--r--. 1 root root 1382 Jan  2 16:21 /etc/yum.repos.d/CentOS-Sources.repo
-rw-r--r--. 1 root root   74 Jan  2 16:21 /etc/yum.repos.d/CentOS-Vault.repo

• Interessante Optionen:
  • gpgkey_dns_verification=yes Prüfe neue GPG Schlüssel gegen die im DNS abgelegten GPG-Schlüssel. Benötigt libunbound und einen DNSSEC fähigen DNS-Resolver (z.B. systemd-resolved oder unbound)
  • install_weak_deps=False nun unbedingt notwendige Abhängigkeiten installieren, keine Empfehlungen (weniger Software auf einem Server = weniger Komplexität)
  • protected_packages=<liste-von-paketnamen> Pakete die nie deinstalliert werden sollen. Kann alternativ auch unter /etc/dnf/protected.d/*.conf konfiguriert werden
  • ip_resolve=IPv4|IPv6 über welches Protokoll sollen Domainnamen aufgelöst werden. Notwendig, wenn IPv4 oder IPv6 nur lokal im Netzwerk verfügbar sind
  • proxy=http://proxy.name/ Download über Web-Proxy-Server
  • assumeyes=True keine Benutzerinteraktion, immer "YES" als Antwort auf Fragen annehmen (wenn dnf hauptsächlich von Skripten benutzt wird)

• aus den Repositories

# dnf install epel-release

• aus Dateien im Dateisystem

# curl -O dnf install http://mirror.centos.org/centos-8/8.1.1911/extras/x86_64/os/Packages/epel-release-8-5.el8.noarch.rpm
# dnf install epel-release-8-5.el8.noarch.rpm

• aus Dateien im Netz

dnf install http://mirror.centos.org/centos-8/8.1.1911/extras/x86_64/os/Packages/epel-release-8-5.el8.noarch.rpm

• nach Paketen suchen

# dnf search <suchausdruck>

• Beispielsuche

# dnf search "*golang*"
Last metadata expiration check: 0:25:35 ago on Sun 01 Mar 2020 10:17:51 PM CET.
========================================================== Name & Summary Matched: *golang* ==========================================================
golang-docs.noarch : Golang compiler docs
golang-bin.x86_64 : Golang core compiler tools
golang-src.noarch : Golang compiler source tree
golang-tests.noarch : Golang compiler tests for stdlib
golang-misc.noarch : Golang compiler miscellaneous sources
golang-race.x86_64 : Golang std library with -race enabled
=============================================================== Name Matched: *golang* ===============================================================
golang.x86_64 : The Go Programming Language
============================================================= Summary Matched: *golang* ==============================================================
go-srpm-macros.noarch : RPM macros for building Golang packages for various architectures

• Liste der anstehenden Updates inkl. der Änderungen

# dnf check-update --changelog

• Liste der Sicherheitsupdates

dnf updateinfo --security --sec-severity Important --list --available

• Upgrade des Systems

dnf upgrade

• Vollständiges Update des Systems (auch Downgrades und entfernen von nicht mehr verfügbaren Paketen)

# dnf distro-sync

• Minimales Update (nur Sicherheitsupdates, keine weiteren neuen Paketversionen)

# dnf upgrade-minimal

• Paket-Cache nach einer Installation / einem Update löschen (ggf. wichtig bei der Erstellung von VM/Container-Images)

# dnf clean packages

dnf downgrade <paketname-inkl-version>

dnf remove <paketname>

• Information über ein Paket abrufen

# dnf info hc-utils
Last metadata expiration check: 0:15:29 ago on Sun 01 Mar 2020 10:17:51 PM CET.
Installed Packages
Name         : hc-utils
Version      : 0.0.2
Release      : 1.el8
Architecture : noarch
Size         : 3.6 k
Source       : hc-utils-0.0.2-1.el8.src.rpm
Repository   : @System
From repo    : @commandline
Summary      : A set of utilities for Hetzner Cloud
URL          : https://github.com/hetznercloud/hc-utils
License      : MIT
Description  : hc-utils contains utilities to automatically configure
	     : Hetzner Cloud private network interfaces and block storage volumes

• alle installierten Pakete auflisten

# dnf list --installed

• Liste der installierten Pakete filtern

# dnf list --installed "python*"

• welches Paket installiert eine Datei/ein Programm

# dnf provides /usr/bin/gzip
Last metadata expiration check: 0:19:31 ago on Sun 01 Mar 2020 10:17:51 PM CET.
gzip-1.9-9.el8.x86_64 : The GNU data compression program
Repo        : @System
Matched from:
Filename    : /usr/bin/gzip

gzip-1.9-9.el8.x86_64 : The GNU data compression program
Repo        : BaseOS
Matched from:
Filename    : /usr/bin/gzip

• alle verfügbaren Paketgruppen auflisten

# dnf group list --available "*"

• Detailinformationen zu Gruppen anzeigen

# dnf -v group info "*"

• Gruppen-Pakete installieren

# dnf groupinstall "Virtualization Hypervisor"

• Liste der dnf Transaktionen (hier eine CentOS 8 Cloud Instanz bei Hetzner - Hetzner entfernt firewalld bei der Installation)

# dnf history
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     7 | install tmux emacs-nox   | 2020-03-01 21:50 | Install        |    8
     6 | update                   | 2020-03-01 21:45 | I, U           |  219 EE
     5 |                          | 2020-01-12 05:21 | Install        |    1
     4 |                          | 2020-01-12 05:21 | Install        |   30
     3 | -C -y remove firewalld - | 2020-01-12 05:20 | Removed        |   14 EE
     2 | -C -y remove linux-firmw | 2020-01-12 05:20 | Removed        |    1
     1 |                          | 2020-01-12 05:17 | Install        |  373 EE

• Details einer Transaktion

# dnf history info 4
Transaction ID : 4
Begin time     : Sun 12 Jan 2020 05:21:37 AM CET
Begin rpmdb    : 355:a37d783b17077e589ca25c5c49f1c3794c5e85ae
End time       : Sun 12 Jan 2020 05:21:42 AM CET (5 seconds)
End rpmdb      : 385:f407d6d2a43ae4232fc41ac28286cd4d17dcf41b
User           : root <root>
Return-Code    : Success
Releasever     : 8
Command Line   :
Packages Altered:
    Install cloud-init-18.5-1.el8.4.noarch                       @AppStream
    Install cloud-utils-growpart-0.29-2.el8.noarch               @AppStream
    Install python3-babel-2.5.1-3.el8.noarch                     @AppStream
    Install python3-jinja2-2.10.1-2.el8_0.noarch                 @AppStream
    Install python3-jsonpatch-1.21-2.el8.noarch                  @AppStream
[...]

• zu einem alten Transaktionsstand zurückkehren (Pakete der alten Versionen müssen noch verfügbar sein)

# dnf history rollback 5 | head -15
Last metadata expiration check: 0:10:05 ago on Sun 01 Mar 2020 10:17:51 PM CET.
Rollback to transaction 5, from Sun 12 Jan 2020 05:21:59 AM CET
  Undoing the following transactions: 6, 7, 8
    Upgraded NetworkManager-1:1.14.0-14.el8.x86_64                                    @@System
    Upgrade  NetworkManager-1:1.20.0-5.el8_1.x86_64                                   @BaseOS
    Upgraded NetworkManager-libnm-1:1.14.0-14.el8.x86_64                              @@System
    Upgrade  NetworkManager-libnm-1:1.20.0-5.el8_1.x86_64                             @BaseOS
    Upgraded NetworkManager-team-1:1.14.0-14.el8.x86_64                               @@System
    Upgrade  NetworkManager-team-1:1.20.0-5.el8_1.x86_64                              @BaseOS
    Upgraded NetworkManager-tui-1:1.14.0-14.el8.x86_64                                @@System
    Upgrade  NetworkManager-tui-1:1.20.0-5.el8_1.x86_64                               @BaseOS
    Install  alsa-lib-1.1.9-4.el8.x86_64                                              @AppStream
    Upgraded authselect-1.0-13.el8.x86_64                                             @@System
    Upgrade  authselect-1.1-2.el8.x86_64                                              @BaseOS
    Upgraded authselect-libs-1.0-13.el8.x86_64                                        @@System

• eine einzelne Transaktion rückgängig machen

# dnf history undo 5
Last metadata expiration check: 0:14:55 ago on Sun 01 Mar 2020 10:17:51 PM CET.
Undoing transaction 5, from Sun 12 Jan 2020 05:21:59 AM CET
    Install hc-utils-0.0.2-1.el8.noarch @@commandline
Dependencies resolved.
======================================================================================================================================================
 Package                           Architecture                    Version                               Repository                              Size
======================================================================================================================================================
Removing:
 hc-utils                          noarch                          0.0.2-1.el8                           @@commandline                          3.6 k

Transaction Summary
======================================================================================================================================================
Remove  1 Package

Freed space: 3.6 k
Is this ok [y/N]:

• Alias-Definitionen werden unter /etc/dnf/aliases.d/USER.conf abgelegt
• Liste der Alias-Definitionen

# dnf alias list

• neuen Alias definieren

# dnf alias add security-info="updateinfo --security --sec-severity Important --list --available"
# dnf security-info

• Alias löschen

# dnf alias delete security-info

• die DNF Shell erlaubt es, mehrere Aktionen in eine Transaktion zusammenzufassen und dann gebündelt auszuführen

# dnf shell
> install ruby
> remove emacs-nox
> ts
=======================================================================================================================================
 Package                                 Architecture              Version                           Repository                   Size
=======================================================================================================================================
Installing:
 ruby                                    x86_64                    2.6.5-124.fc31                    updates                      42 k
Installing dependencies:
 ruby-libs                               x86_64                    2.6.5-124.fc31                    updates                     3.0 M
 rubygem-irb                             noarch                    1.0.0-124.fc31                    updates                      64 k
 rubygem-json                            x86_64                    2.2.0-201.fc31                    fedora                       57 k
 rubygem-psych                           x86_64                    3.1.0-124.fc31                    updates                      51 k
 rubypick                                noarch                    1.1.1-11.fc31                     fedora                      9.8 k
Installing weak dependencies:
 rubygem-bigdecimal                      x86_64                    1.4.1-124.fc31                    updates                      57 k
 rubygem-did_you_mean                    noarch                    1.3.0-124.fc31                    updates                      37 k
 rubygem-io-console                      x86_64                    0.4.7-124.fc31                    updates                      22 k
 rubygem-openssl                         x86_64                    2.1.2-124.fc31                    updates                     154 k
 rubygem-rdoc                            noarch                    6.1.2-124.fc31                    updates                     408 k
 rubygems                                noarch                    3.0.3-124.fc31                    updates                     247 k
Removing:
 emacs-nox                               x86_64                    1:26.3-1.fc31                     @updates                     38 M
[...]
> run
=======================================================================================================================================
 Package                                 Architecture              Version                           Repository                   Size
=======================================================================================================================================
Installing:
 ruby                                    x86_64                    2.6.5-124.fc31                    updates                      42 k
Installing dependencies:
 ruby-libs                               x86_64                    2.6.5-124.fc31                    updates                     3.0 M
 rubygem-irb                             noarch                    1.0.0-124.fc31                    updates                      64 k
[...]
> exit
Leaving Shell
#

• Application Streams bieten unter Red Hat 8 / CentOS 8 dem Administrator die Möglichkeit, populäre Paket-Gruppe auf neue Versionsstände zu aktualisieren, während das Basis-Betriebssystem auf einem stabilen Versionsstand bleibt. Beispiele für Application Stream Anwendungen sind PostgreSQL, Ruby, Go, PHP etc.
• Red Hat Enterprise Linux 8 Application Streams Life Cycle https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle
• AppStream modules https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/package_manifest/index#AppStream-modules
• Alle verfügbaren Application Stream Module für ein Paket anzeigen

# dnf module list <paketname>

• Default-Version eines Pakets installieren

# dnf install @ruby

• Version eines installieren Pakets wechseln

# dnf module reset <paketname>
# dnf module enable <paketname>:<version>
# dnf install @<paketname>:<version>/<profile>

• Paket mit Version und Profil installieren

# dnf install @ruby:2.6/common
# ruby -v
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]

• anzeigen aller verfügbaren Repository-Quellen inkl. des Status (aktiviert / deaktiviert)

# dnf repolist all

• einige Quelltext-Pakete oder Entwicklerpakete sind in das PowerTools Repository gewechselt. Werden Quelltext-Pakete nicht gefunden, so kann es helfen dieses Repository anzuschalten

  dnf config-manager --set-enabled PowerTools
  

• Versionlock Plugin installieren

# dnf  install  'dnf-command(versionlock)'

• Versionssperre für ein Paket einschalten

# dnf versionlock add nginx
Letzte Prüfung auf abgelaufene Metadaten: vor 0:01:16 am Mo 02 Mär 2020 13:53:52 CET.
Versionssperre wird hinzugefügt zu: nginx-1:1.14.1-9.module_el8.0.0+184+e34fea82.*

• Liste der Versionslocks anzeigen

# dnf versionlock list
Letzte Prüfung auf abgelaufene Metadaten: vor 0:01:55 am Mo 02 Mär 2020 13:53:52 CET.
nginx-1:1.14.1-9.module_el8.0.0+184+e34fea82.*

• RedHat EL 8 / CentOS 8 kommt mit einem DNSSEC und DNS-over-TLS fähigen DNS Stub-Resolver.
• Dieser Stub-Resolver kann neben DNS auch Namensauflösung über
  • Multicast DNS (mDNS) und DNS Service Discovery (DNS-SD). Damit wird eine separate Implentation von mDNS/DNS-SD wie Avahi nicht mehr benötigt.
  • Namensauflösung über Link-Local-Multicast-Name-Resolution (LLMNR), eine serverloses Namensauflösungsprotokoll von Microsoft welches von Windows Systemen verwendet wird
• Beim Einsatz als Server oder in sicherheitskritischen Installationen sollten mDNS und LLMNR ausgeschaltet werden. Über diese Protokolle können Angreifer recht einfach und unbemerkt Rechnerkommunikation umleiten.
• Liste der von systemd-resolved unterstützen Protokolle

# resolvectl -p help
Known protocol types:
dns
llmnr
llmnr-ipv4
llmnr-ipv6
mdns
mdns-ipv4
mdns-ipv6

• systemd-resolvd horcht auf der IPv4-Loopback-Adresse 127.0.0.53 Port 53/TCP.
• anders als über die Datei /etc/resolv.conf welche immer systemweit Gültigkeit hat, kann per systemd-resolved die Namensauflösungskonfiguration pro Netzwerkschnittstelle individuell angepasst werden
• systemd-resolved bekommt die Konfiguration der DNS-Server von DHCP, DHCPv6, IPv6 Router-Advertisements und/oder manueller Konfiguration.
• Der Dienst systemd-resolved ist in einer Standard-Installation aktiv, wird aber nicht aktiv für die (DNS-) Namensauflösung benutzt, da in der Datei /etc/resolv.conf in der Regel die per DHCP / DHCPv6 verteilten DNS-Server eingetragen sind (oder manuell eingetragene DNS-Server dort verwendet werden).

# systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: disabled)
   Active: active (running) since Sat 2020-02-29 03:59:50 UTC; 16h ago
     Docs: man:systemd-resolved.service(8)
	   https://www.freedesktop.org/wiki/Software/systemd/resolved
	   https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
	   https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
 Main PID: 5850 (systemd-resolve)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4963)
   Memory: 3.8M
   CGroup: /system.slice/systemd-resolved.service
	   └─5850 /usr/lib/systemd/systemd-resolved

Feb 29 20:07:46 oe2.dane.onl systemd-resolved[5850]: DNSSEC validation failed for question _443._tcp.strotmann.de IN TLSA: no-signature

• Das Verwaltungs-Werkzeug für diesen Dienst heisst resolveclt (früher unter Fedora systemd-resolve)
• wird der Befehl resolvectl ohne Parameter aufgerufen, so wird die aktuelle Konfiguration ausgegeben

# resolvectl
Global
       LLMNR setting: yes
MulticastDNS setting: yes
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes
  Current DNS Server: 127.0.0.1
	 DNS Servers: 127.0.0.1
	  DNSSEC NTA: 10.in-addr.arpa
		      16.172.in-addr.arpa
		      168.192.in-addr.arpa
		      17.172.in-addr.arpa
		      18.172.in-addr.arpa
		      19.172.in-addr.arpa
		      20.172.in-addr.arpa
		      21.172.in-addr.arpa
		      22.172.in-addr.arpa
		      23.172.in-addr.arpa
		      24.172.in-addr.arpa
		      25.172.in-addr.arpa
		      26.172.in-addr.arpa
		      27.172.in-addr.arpa
		      28.172.in-addr.arpa
		      29.172.in-addr.arpa
		      30.172.in-addr.arpa
		      31.172.in-addr.arpa
		      corp
		      d.f.ip6.arpa
		      home
		      internal
		      intranet
		      lan
		      local
		      private
		      test

Link 9 (ip_vti0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 8 (vethf3dcc34d)
      Current Scopes: LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 6 (veth9bc877c5)
      Current Scopes: LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 2 (eth0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes
  Current DNS Server: 127.0.0.1
	 DNS Servers: 127.0.0.1
	  DNS Domain: ~.

• Mit resolvectl können Namensauflösungen über alle unterstützten Protokolle ausgeführt werden

# resolvectl query linuxhotel.de
linuxhotel.de: 2001:aa8:fffe:4::1:11%eth0
	       217.69.87.63%eth0

-- Information acquired via protocol DNS in 31.7ms.
-- Data is authenticated: yes

• Namensauflösung kann auf IPv4 Adressen beschränkt werden

# resolvectl -4 linuxhotel.de
linuxhotel.de: 217.69.87.63

-- Information acquired via protocol DNS in 84.6ms.
-- Data is authenticated: yes

• und auch auf IPv6 Adressen

# resolvectl -6 linuxhotel.de
linuxhotel.de: 2001:aa8:fffe:4::1:11

-- Information acquired via protocol DNS in 26.9ms.
-- Data is authenticated: yes

• Die Statistik gibt Information, wieviele Namensauflösungsanfragen bearbeitet wurden, und wieviel Antworten aus dem (lokalen) Cache kamen, und die Rate der DNSSEC validierten Antworten.

# resolvectl statistics
DNSSEC supported by current servers: yes

Transactions
Current Transactions: 0
  Total Transactions: 24

Cache
  Current Cache Size: 0
	  Cache Hits: 0
	Cache Misses: 12

DNSSEC Verdicts
	      Secure: 12
	    Insecure: 0
	       Bogus: 0
       Indeterminate: 0

• resolvectl hilft bei der Abfrage von speziellen DNS-Daten, wie DANE TLSA-Records, hier für eine Webseite

# resolvectl tlsa fedoraproject.org
_443._tcp.fedoraproject.org IN TLSA 0 0 1 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0
	-- Cert. usage: CA constraint
	-- Selector: Full Certificate
	-- Matching type: SHA-256

-- Information acquired via protocol DNS in 152.2ms.
-- Data is authenticated: yes

• ein DANE/TLSA Record für einen Mailserver

# resolvectl tlsa mail.strotmann.de:25
_25._tcp.mail.strotmann.de IN TLSA 3 1 1 713404932d32e8488c26acb3e7e03d67d3cd7e8cc5bee59d6c4a5ca8b4a2edd0
	-- Cert. usage: Domain-issued certificate
	-- Selector: SubjectPublicKeyInfo
	-- Matching type: SHA-256 # interface eth0

-- Information acquired via protocol DNS in 35.0ms.
-- Data is authenticated: yes

• Abfragen eines PGP/GPG Schlüssel aus dem Internet-DNS

# resolvectl openpgp cs@sys4.de

• Die Konfiguration von systemd-resolved liegt unter /etc/systemd/resolved.conf. Die auskommentierten Werte sind die Standard-Werte.

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=yes
#MulticastDNS=yes
#DNSSEC=allow-downgrade
#DNSOverTLS=no
#Cache=yes
#DNSStubListener=udp

• mit dem Befehl dig (aus dem Paket bind-utils) kann der Dienst direkt auf der Adresse 127.0.0.53 angefragt werden:

# dig @127.0.0.53 linuxhotel.de +dnssec +multi

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> @127.0.0.53 linuxhotel.de +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33479
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
;; QUESTION SECTION:
;linuxhotel.de.         IN A

;; ANSWER SECTION:
linuxhotel.de.          3045 IN A 217.69.87.63

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Feb 29 20:14:04 UTC 2020
;; MSG SIZE  rcvd: 58

• soll die Namensauflösung über systemd-resolved durchgeführt werden, so wird die DNS-Konfiguration im NetworkManager angepasst
• Netzwerkkonfigurationen des Netzwerkmanagers auflisten

# nmcli con show
NAME         UUID                                  TYPE      DEVICE
System eth0  5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ethernet  eth0
cni-podman0  9a94e636-33c3-49e7-bdc4-eea2c44fe2a2  bridge    cni-podman0

• DNS Konfiguration manuell auf die Loopback-Adressen (Unbound DNS-Resolver) festlegen

# nmcli con mod "System eth0" ipv4.ignore-auto-dns yes
# nmcli con mod "System eth0" ipv6.ignore-auto-dns yes
# nmcli con mod "System eth0" ipv4.dns "127.0.0.53"

• Networkmanager Konfiguration neu ausrollen

# nmcli con down "System eth0" && nmcli con up "System eth0"

• prüfen, das die Konfiguration erfolgreich übernommen wurde

# cat /etc/resolv.conf
nameserver 127.0.0.53

• systemd-resolved unterstützt opportunistisches DNS-over-TLS: unterstützt der eingestellte DNS-Server DNS-over-TLS wird dieses benutzt. Tritt ein Fehler bei der DNS-over-TLS Kommunikation auf, so schaltet systemd-resolved sofort und ohne Meldung an den Benutzer auf unverschlüsseltes DNS (UDP/TCP) um. In späteren Versionen von systemd-resolved soll ein strict Modus möglich sein.
• der/die DNS-Server für eine Schnittstelle kann temporär per resolvectl umgeschaltet werden, hier auf einen DNS-over-TLS Server:

resolvectl dnsovertls eth0 opportunistic
resolvectl dns eth0 5.45.107.88  # doh.defaultroutes.de

• Nach dem Umschalten auf DNS-over-TLS sollten TLS-verschlüsselte Verbindungen auf Port 853 sichtbar sein

tcpdump -i eth0 -v port 853

• unverschlüsselte Kommunikation auf Port 53 (UDP/TCP) sollte nun nicht mehr möglich sein.

tcpdump -i eth0 -v port 53

• Den Inhalt des systemd-resolved Cache in das Journal ausgeben (Achtung: dies können sehr viele Daten sein!)

pkill -USR1 resolve
journalctl -u systemd-resolved

• schalte die DNS-Auflösung per NetworkManager auf systemd-resolved um
• Konfiguriere die DNS-Server 46.182.19.48 bzw. 2a02:2970:1002::18 (Digitalcourage) in der resolved.conf als primäre DNS Server
• Teste die Namensauflösung für einige Domains
• Schalte DNSSEC-Validierung für systemd-resolved an, teste die Domains notes.defaultroutes.de, fail03.dnssec.works und dane.onl auf DNSSEC Validierung
• Schalte DNS-over-TLS für die DNS-Server ein. Prüfe mit tcpdump das keine DNS-Abfragen über Port 53 UDP/TCP laufen

• in der Datei /etc/fstab sind neue Optionen für Systemd verfügbar. Die Optionen x-systemd.requires und x-systemd.requires-mounts-for definieren Abhängigkeiten für Mount-Definitionen. Dies kann für Netzwerklaufwerke, Network-Based-Disk-Encryption, Stratis und andere Systeme verwendet werden

//host/share    /net/share        cifs   noauto,nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,workgroup=workgroup,credentials=/foo/credentials    0 0

• die Option x-systemd.mount-timeout kann benutzt werden um ein Timeout auf eine Mount-Operation zu definieren
• die Option x-systemd.device-bound kann benutzt werden um eine Mount-Operation an ein Gerät zu binden. So kann z.B. ein Dateisystem auf einer DVD/BlueRay/CD-ROM automatisch ausgehangen werden, wenn das Medium ausgeworfen wird
• die Optionen x-systemd.after und x-systemd.before können benutzt werden um explizit eine Reihenfolge der Mount-Aktion mit Systemd-Diensten oder Systemd-Mounts zu definieren
• die Option x-systemd.makefs bewirkt das die Partition immer vor dem Mouten mit einem neuen Dateisystem formatiert wird. Das Formatieren wird an eine Systemd-Unit systemd-makefs@.service delegiert.
• die Option x-systemd.growfs bewirkt das vor dem Einhängen das Dateisyste auf die Grösse des darunterliegenden Storage vergrössert wird (wenn möglich). Das Vergrössern des Dateisystemd wird an eine Systemd-Unit systemd-growfs@.service delegiert.

• ist der Einhängepunkt /efi vorhanden, so wird die EFI-Partition dort eingehangen (vorher /boot). Somit können die EFI-Daten besser von anderen Boot-Daten unter /boot getrennt verwaltet werden

• der neue Befehl systemd-mount funktioniert wie der raditionelle mount Befehl, beachtet aber weitere Abhängigkeiten. So kann systemd-mount sicherstellen, das vor dem Anhängen eines Wechseldatenträger ein Filesystemcheck ausgeführt wird

systemd-mount /dev/sda1 /mnt

• über die Option --owner kann der Benutzeraccount und die Benutzergruppe für ein Mount festgelegt werden
• der Subbefehl --list zeigt alle verfügbaren Mount-Geräte an:

# systemd-mount --list
NODE      PATH                   MODEL                   WWN                TYPE  LABEL                      UUID
/dev/dm-0 n/a                    n/a                     n/a                btrfs data                       c2e4db24-56ec-4de6-b5b7-aa19808bb8cf
/dev/sda1 pci-0000:00:1f.2-ata-1 Samsung_SSD_860_QVO_1TB 0x5002538e701bd174 vfat  EFI\x20System\x20Partition 0DD0-646B
/dev/sda2 pci-0000:00:1f.2-ata-1 Samsung_SSD_860_QVO_1TB 0x5002538e701bd174 ext4  n/a                        8ce223b7-7f02-4b03-8c0b-fd2ea2621adc
/dev/sda3 pci-0000:00:1f.2-ata-1 Samsung_SSD_860_QVO_1TB 0x5002538e701bd174 xfs   n/a                        fae4a7d8-f5e2-48dc-b889-e3a8e3a33bf5

• der Befehl systemd-umount kann benutzt werden, um Dateisysteme mit Abhängigkeiten (stoppen von Diensten, welche auf das Dateisystem zugreifen) auszuhängen

• Stratis is ein wrapper um Device-Mapper (DM), LVM und XFS um die Funktionen eines Volume-Managing-File-System (z.B. BTRFS oder ZFS) nachzubilden
• Stratis is derzeit ein Technology Preview. Es fehlen noch wichtige Eigenschaften wie Prüfsummen auf Daten und Metadaten
• Stratis Dokumentation bei Red Hat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_storage_devices/managing-layered-local-storage-with-stratis_managing-storage-devices
• Projekt Dokumentation: https://github.com/stratis-storage/stratis-docs
• Projekt Repository: https://github.com/stratis-storage
• Homepage: https://stratis-storage.github.io/

• VDO bietet Komprimierung, Thin-Provisioning und De-Duplication
• VDO kann zusammen mit LVM verwendet werden
• Einsatzgebiete:
  • VDO und Virtualisierung/Container
  • VDO und Netzwerklaufwerke
  • VDO und Verschlüsselung (erst Verschlüsselung, dann VDO)
• Kein Stratis auf VDO! (Thin auf Thin)
• Hauptspeicher: 1 GB Basis für VDO, dann 1 GB pro 1 TB Storage deduplication
• max 256TB Storage per VDO Volume
• Platzverbrauch auf VDO Volume für Deduplication Index (0.1% - 25%)

• LUKS Homepage https://gitlab.com/cryptsetup/cryptsetup/blob/master/README.md
• An easier way to manage disk decryption at boot with Red Hat Enterprise Linux using NBDE https://www.redhat.com/en/blog/easier-way-manage-disk-decryption-boot-red-hat-enterprise-linux-75-using-nbde
• Encrypting block devices using LUKS https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
• Using Network-Bound Disk Encryption https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening#network-bound-disk-encryption_configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption
• RFC 7516 - JSON Web Encryption (JWE) https://tools.ietf.org/html/rfc7516
• Clevis Projekt Repository https://github.com/latchset/clevis
• Tang Projekt Repository https://github.com/latchset/tang

• die KVM VM klonen und auf dem Klon den TANG Server installieren
• TANG Pakete installieren

dnf install tang policycoreutils-python-utils

• TANG Socket-Unit aktivieren und den Socket in der Konfiguration anpassen

systemctl enable tangd.socket
systemctl edit tangd.socket

• Wir möchten das unser TANG-Server auf Port 7500 horcht

[Socket]
ListenStream=
ListenStream=7500

• Port 7500 im SELinux und in der Firewall freischalten

semanage port -a -t tangd_port_t -p tcp 7500
firewall-cmd --zone=public --add-port=7500/tcp --permanent
firewall-cmd --reload

• Systemd-Konfigurationsänderungen laden und den TANG-Socket auf Port 7500 starten

systemctl daemon-reload
systemctl show tangd.socket -p Listen
systemctl start tangd.socket

• die TANG Schlüssel werden automatisch beim ersten Start erstellt und liegen unter /var/db/tang

ls -l /var/db/tang/

• Hashes der aktuellen Schlüssel des TANG-Servers anzeigen

# tang-show-keys 7500
McocO98JWjCSm7trnHKSCW6M9MQ
Xx6Fb3Jpg8Y9YV6hzkl5CrIxjc0

• falls notwendig (z.B. für einen Key-Rollover), können neue Schlüssel auf dem TANG Server erstellt werden

/usr/libexec/tangd-keygen /var/db/tang

• wir arbeiten auf der anderen VM. Dieser VM vier Megabyte Hauptspeicher geben.
• die Pakete für CLEVIS installieren

# dnf install clevis-luks clevis-dracut clevis

• Partition für die Verschlüsselung vorbereiten

[root@redhat8 cas]# parted /dev/vde
GNU Parted 3.2
Using /dev/vde
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: /dev/vdd: unrecognised disk label
Model: Virtio Block Device (virtblk)
Disk /dev/vde: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
(parted) mklabel gpt
(parted) mkpart
Partition name?  []? LUKS2
File system type?  [ext2]? XFS
Start? 4M
End? 100%
(parted) q
Information: You may need to update /etc/fstab.

• Verschlüsselung auf dem Laufwerk vde1 initialisieren. Das Laufwerk ist noch nicht voll-verschlüsselt, die Verschlüsselung ist vorbereitet. Wir können später das Laufwerk schon produktiv nutzen während die Verschlüsselung abgeschlossen wird. Dieser Prozess braucht Zufallszahlen, welche in einer VM möglicherweise nicht in ausreichender Menge vorhanden sind. Die Installation des Entropie-Gatherin-Daemon haveged (aus den EPEL Repositories) in der VM kann helfen

# dnf install epel-release
# dnf install haveged
# systemctl enable --now haveged
# cryptsetup reencrypt --encrypt --init-only --reduce-device-size 32M /dev/vde1

WARNING!
========
This will overwrite data on LUKS2-temp-4c8e4a91-2e8b-4fb8-8a9c-271331c3405f.new irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for LUKS2-temp-4c8e4a91-2e8b-4fb8-8a9c-271331c3405f.new:
Verify passphrase:

• Verschlüsselte Partition freischalten

# cryptsetup open /dev/vde1 vde1_encrypted
Enter passphrase for /dev/vde1:

• mit einem XFS-Dateisystem versehen und einhängen

# mkfs.xfs /dev/mapper/vde1_encrypted
# mkdir -p /mnt/vde1_encrypted
# mount /dev/mapper/vde1_encrypted /mnt/vde1_encrypted

• Verschlüsselung vorsetzen. Das Laufwerk kann währenddessen benutzt werden

# cryptsetup reencrypt --resume-only /dev/vde1

• Block-Geräte Ansicht des verschlüsselten Laufwerks

# lsblk
NAME               MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sr0                 11:0    1 1024M  0 rom
vda                252:0    0   20G  0 disk
|-vda1             252:1    0    1G  0 part  /boot
`-vda2             252:2    0   19G  0 part
  |-rhel-root      253:0    0   17G  0 lvm   /
  `-rhel-swap      253:1    0    2G  0 lvm   [SWAP]
vdb                252:16   0    1G  0 disk
vdc                252:32   0    1G  0 disk
vdd                252:64   0   20G  0 disk
vde                252:48   0    1G  0 disk
`-vde1             252:49   0 1019M  0 part
  `-vde1_encrypted 253:3    0  987M  0 crypt /mnt/vdd1_encrypted
`-vdo-test         253:2    0  100G  0 vdo

• das kleine Kommandozeilenprogramm jq (JSON Query) hilft bei der Anzeige der Schlüssel des TANG-Servers (nützlich bei der Fehlersuche). Wir fragen per HTTP-Protokoll die Schlüssel und Signaturen des TANG-Servers ab

# dnf -y install jq
# curl --silent http://<IP-des-TANG-Servers>:7500/adv/ | jq
{
  "payload": "eyJrZXlzIjpbeyJhbGciOiJFQ01SIiwiY3J2IjoiUC01MjEiLCJrZXlfb3BzIjpbImRlcml2ZUtleSJdLCJrdHkiOiJFQyIsIngiOiJBRDlZLVNfY2NFTlNJQ2VIMDRxQUwydUpMVE9CTXNQemhVSUpQQlRYQUlBMHlVWWtKQUtMWjQtM0NmbGVuTVVXQ2hzMGFkakhEV0Znbzc0WHphaFZ0bk41IiwieSI6IkFmWlJTeFVTN05XUUZGTmRQSzRkQXpDbFhlVEpGY1RWYkNyZG1pd2pzQWFqVk1KcHVaUDNqN210QlBUQVFCUW1weGs0aGJpaWtON09RX1I0NDlfWWpXeFUifSx7ImFsZyI6IkVDTVIiLCJjcnYiOiJQLTUyMSIsImtleV9vcHMiOlsiZGVyaXZlS2V5Il0sImt0eSI6IkVDIiwieCI6IkFCd3BFbEQwVkhOYVJIVjdIcFpGVzFPZkJsUnlzYVY2Q3JkZnBiYVdlMlNHaUgzalQ2OFhYLUM0eFF2RHZlMUhaa25uWkpZZlVXQ21RSGN3UkJEclNBTjkiLCJ5IjoiQUhTYlBUYnA3Q1AxRUpmOFp2MlNGZ09tTmF5SmNQN1pRMW1BV3RKWnNESXl3MUxxM0NmZk1TXzJiVWZnY3hsN19GekFsb3VZMTBqUmFKTU9zdGpnazJyZiJ9LHsiYWxnIjoiRVM1MTIiLCJjcnYiOiJQLTUyMSIsImtleV9vcHMiOlsidmVyaWZ5Il0sImt0eSI6IkVDIiwieCI6IkFPeWliZ1ozc2VUT3BDSkU0VDBMeXZwOU5EZWlBaWdtRmpCejNzRjBEZnJURHpiWUlnZHVfZFcxTy1NaDVETlFUVGlFMml3UU5yVWFiT1hZR1RNVVhBc2siLCJ5IjoiQVlURmR4M1EzeWc5ZEtWc0d5dkRhcXFlTmxFQXJiQTBhRnRpYVpkaHdIdmdBbzRtb2NGa0VGTnBlT2twSGR3OU9zaXhhMVAyZkxuVmpnaVJac2NiR3lfNyJ9LHsiYWxnIjoiRVM1MTIiLCJjcnYiOiJQLTUyMSIsImtleV9vcHMiOlsidmVyaWZ5Il0sImt0eSI6IkVDIiwieCI6IkFhNlUwZU1yXzNBRGR6aTlESmVTaDNSdEhpV3YtaTRuU2s3ZXo3ZXFQMkFLWVI5VW42WDMyeUhvMktTNy00LV8zZlVydC04T2g5WFlEam1YTjFBdE1YdWciLCJ5IjoiQVhpOTA0S0VqLUNFSjRvOWdHM0hpS1pfVm5uazJmQVpYMFBSMWhDMC1IbWs2MnJLOERyQ1daZi1tUVRSa0cyWWdrNWh1ZXUzaE90ZHI0bUREUHFVcXloXyJ9XX0",
  "signatures": [
    {
      "protected": "eyJhbGciOiJFUzUxMiIsImN0eSI6Imp3ay1zZXQranNvbiJ9",
      "signature": "AShqBVyGOKewGvGV2KCPGTn1XZTbNTiH7g6y_kNri5inq067ol8CQ4uWIcPmyYziL1RDeAh5Iq_zpn4QXoZYTI-9AR43Qegnqoc5fl5G58SCj88833MvpiQ6jYkmyFN4rpROkv5OHnfUwPKm5zEuciZM1XaGTuAAIW0RSBtUyTUychvz"
    },
    {
      "protected": "eyJhbGciOiJFUzUxMiIsImN0eSI6Imp3ay1zZXQranNvbiJ9",
      "signature": "APuddB0W1vWIh_RrTi3ohojj9NOKuAC8NUlqCQH5YNfwvWEAEzlL7pWAySmNgpnLSjisBrIlRwt8XqzfTKnRlinxAI-gqLEcZ1lAiysHxbsbDo6jIDEK09hMGw4O7USDRcYrRFteW2rTwr7e6b-qXC1kRT9q3KKjmvFw1JWRsUppoWWL"
    }
  ]
}

• nun binden wir die LUKS Verschlüsselung an den TANG-Server. Dabei wird der TANG-Schlüssel als weiterer Schlüssel dem verschlüsseltm Laufwerk hinzugefügt. Das Laufwerk lässt sich ohne Netzwerk noch mit der manuell vergebenen Passphrase entschlüsseln

# clevis luks bind -d /dev/vde1 tang '{"url":"http://<rechnername-oder-ip-des-tang-servers>:7500"}'
The advertisement contains the following signing keys:

McocO98JWjCSm7trnHKSCW6M9MQ
Xx6Fb3Jpg8Y9YV6hzkl5CrIxjc0

Do you wish to trust these keys? [ynYN] y
Enter existing LUKS password: XXXXXXXXXXX

Die Konfiguration des LUKS Volumes ausgaben

cryptsetup luksDump /dev/vde1

• Die clevis-luks-askpass Path-Aktivierungs-Unit aktivieren. Diese Path-Unit überwacht Passwort-Anfragen beim Systemstart und leitet diese an den TANG-Server weiter

systemctl enable clevis-luks-askpass.path

• Eintragen des verschlüsselten Volumes in die Datei /etc/crypttab. Wichtig ist hierbei die Option _netdev die dafür sorgt, das dieses Laufwerk erst eingebunden wird, wenn das Netzwerk verfügbar ist

# echo "vde1_encrypted   /dev/vde1 none _netdev" >> /etc/crypttab

• Eintragen des Dateisystems in die /etc/fstab, auch hier wird die Option _netdev angegeben

echo "/dev/mapper/vde1_encrypted  /mnt/vde1_encrypted     xfs   _netdev  0 0" >> /etc/fstab

• wir die Root-Partition des Linux verschlüsselt, so muss per dracut die INIT-Ramdisk des Linux-Systems neu erstellt werden, um sicherzustellen das die CLEVIS Komponenten schon beim Systemstart verfügbar sind

# dracut -fv --regenerate-all

• auf dem TANG-Server auf Port 7500 den Netzverkehr überwachen

# dnf -y install tcpdump
# tcpdump -v port 7500

• den NBDE Client neu booten, das verschlüsselte Laufwerk sollte automatisch eingehangen werden

• DNS Round-Robin (Achtung: funktioniert ggf. bei Maschinen mit IPv6 Stack nicht!)
• TCP-Load-Balancer (HAProxy, relayd)
• Clevis-Client an mehrere Tang-Server anmelden

# dnf install bcc bcc-tools python3-bcc

• die BCC Tools sind unter /usr/share/bcc/tools/ installiert, die meisten Tools sind per man Page dokumentiert (Name bcc-<tool>). Das Blog und das Buch von Brendan Gregg liefert weitere Informationen (siehe Referenzen).

ls -l /usr/share/bcc/tools/

• A brief introduction to XDP and eBPF https://blogs.igalia.com/dpino/2019/01/07/a-brief-introduction-to-xdp-and-ebpf/
• 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

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

• Vorteile von Journald Logging im Vergleich zu Syslog
  • mehr Struktur und Metadaten in den Meldungen
  • Datenbankabfrage nach Meldungen, einfache Korrelierung von Events über mehere Systeme
  • Transport über HTTPS/TLS, auch über Web-Proxies möglich
  • abgeschlossene (sealed = kryptografisch abgesichterte) Journal-Datenbanken
  • Pull oder Push

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

# dnf install systemd-journal-remote

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

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

• In der Firewall Port 19531 freischalten

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

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

• Building container images with Buildah https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/building-container-images-with-buildah_building-running-and-managing-containers
• Building, running, and managing containers https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index

• Mastering systemd: Securing and sandboxing applications and services: https://www.redhat.com/sysadmin/mastering-systemd
• The coredumpctl tool gained a new –directory= option to operate on journal files in a specific directory.
• The systemd-analyze tool gained a new "set-log-target" verb to change the logging target the system manager logs to dynamically during runtime. This is similar to how "systemd-analyze set-log-level" already changes the log level.
• There's a new system.conf setting DefaultTasksMax= to control the default TasksMax= setting for services and scopes running on the system. (TasksMax= is the primary setting that exposes the "pids" cgroup controller on systemd and was introduced in the previous systemd release.) The setting now defaults to 512, which means services that are not explicitly configured otherwise will only be able to create 512 processes or threads at maximum, from this version on. Note that this means that thread- or process-heavy services might need to be reconfigured to set TasksMax= to a higher value. It is sufficient to set TasksMax= in these specific unit files to a higher value, or even "infinity". Similar, there's now a logind.conf setting UserTasksMax= that defaults to 4096 and limits the total number of processes or tasks each user may own concurrently. nspawn containers also have the TasksMax= value set by default now, to 8192. Note that all of this only has an effect if the "pids" cgroup controller is enabled in the kernel. The general benefit of these changes should be a more robust and safer system, that provides a certain amount of per-service fork() bomb protection.
• A new service setting RuntimeMaxSec= has been added that may be used to specify a maximum runtime for a service. If the timeout is hit, the service is terminated and put into a failure state.
• A new service setting MemoryDenyWriteExecute= has been added, taking a boolean value. If turned on, a service may no longer create memory mappings that are writable and executable at the same time. This enhances security for services where this is enabled as it becomes harder to dynamically write and then execute memory in exploited service processes. This option has been enabled for all of systemd's own long-running services.
• The SystemCallFilter= unit file setting gained support for pre-defined, named system call filter sets. For example SystemCallFilter=@clock is now an effective way to make all clock changing-related system calls unavailable to a service. A number of similar pre-defined groups are defined. Writing system call filters for system services is simplified substantially with this new concept. Accordingly, all of systemd's own, long-running services now enable system call filtering based on this, by default.

# systemd-analyze syscall-filter
# man systemd.exec

• The InaccessableDirectories=, ReadOnlyDirectories= and ReadWriteDirectories= unit file settings have been renamed to InaccessablePaths=, ReadOnlyPaths= and ReadWritePaths= and may now be applied to all kinds of file nodes, and not just directories, with the exception of symlinks. Specifically these settings may now be used on block and character device nodes, UNIX sockets and FIFOS as well as regular files. The old names of these settings remain available for compatibility.
• In service units the various ExecXYZ= settings have been extended with an additional special character as first argument of the assigned value: if the character '+' is used the specified command line it will be run with full privileges, regardless of User=, Group=, CapabilityBoundingSet= and similar options. The effect is similar to the existing PermissionsStartOnly= option, but allows configuration of this concept for each executed command line independently.
• Services may be started with their own user namespace using the new boolean PrivateUsers= option. Only root, nobody, and the uid/gid under which the service is running are mapped. All other users are mapped to nobody.
• The new MemorySwapMax= option can be used to limit the maximum swap usage under the unified cgroup hierarchy.
• Support for dynamically creating users for the lifetime of a service has been added. If DynamicUser=yes is specified, user and group IDs will be allocated from the range 61184..65519 for the lifetime of the service. They can be resolved using the new nss-systemd.so NSS module. The module must be enabled in /etc/nsswitch.conf. Services started in this way have PrivateTmp= and RemoveIPC= enabled, so that any resources allocated by the service will be cleaned up when the service exits. They also have ProtectHome=read-only and ProtectSystem=strict enabled, so they are not able to make any permanent modifications to the system.
• The new ProtectKernelModules= option can be used to disable explicit load and unload operations of kernel modules by a service. In addition access to /usr/lib/modules is removed if this option is set.
• ProtectSystem= option gained a new value "strict", which causes the whole file system tree with the exception of /dev, /proc, and /sys, to be remounted read-only for a service.
• The new ProtectKernelTunables= option can be used to disable modification of configuration files in /sys and /proc by a service. Various directories and files are remounted read-only, so access is restricted even if the file permissions would allow it.
• The new ProtectControlGroups= option can be used to disable write access by a service to /sys/fs/cgroup.
• A new unit file option RestrictNamespaces= has been added that may be used to restrict access to the various process namespace types the Linux kernel provides. Specifically, it may be used to take away the right for a service unit to create additional file system, network, user, and other namespaces. This sandboxing option is particularly relevant due to the high amount of recently discovered namespacing related vulnerabilities in the kernel.
• systemd-analyze gained a new verb "syscall-filter" which shows which system call groups are defined for the SystemCallFilter= unit file setting, and which system calls they contain.
• Units gained new options StateDirectory=, CacheDirectory=, LogsDirectory= and ConfigurationDirectory= which are closely related to RuntimeDirectory= but manage per-service directories below /var/lib, /var/cache, /var/log and /etc. By making use of them it is possible to write unit files which when activated automatically gain properly owned service specific directories in these locations, thus making unit files self-contained and increasing compatibility with stateless systems and factory reset where /etc or /var are unpopulated at boot. Matching these new settings there's also StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=, ConfigurationDirectoryMode= for configuring the access mode of these directories. These settings are particularly useful in combination with DynamicUser=yes as they provide secure, properly-owned, writable, and stateful locations for storage, excluded from the sandbox that such services live in otherwise.
• A new TemporaryFileSystem= setting can be used to mask out part of the real file system tree with tmpfs mounts. This may be combined with BindPaths= and BindReadOnlyPaths= to hide files or directories not relevant to the unit, while still allowing some paths lower in the tree to be accessed. ProtectHome=tmpfs may now be used to hide user home and runtime directories from units, in a way that is mostly equivalent to "TemporaryFileSystem=/home /run/user /root".
• A new unit file setting PrivateMounts= has been added. It's a boolean option. If enabled the unit's processes are invoked in their own file system namespace. Note that this behaviour is also implied if any other file system namespacing options (such as PrivateTmp=, PrivateDevices=, ProtectSystem=, …) are used. This option is hence primarily useful for services that do not use any of the other file system namespacing options. One such service is systemd-udevd.service where this is now used by default.
• A new system.conf setting NoNewPrivileges= is now available which may be used to turn off acquisition of new privileges system-wide (i.e. set Linux' PR_{SETNONEWPRIVS} for PID 1 itself, and thus also for all its children). Note that turning this option on means setuid binaries and file system capabilities lose their special powers. While turning on this option is a big step towards a more secure system, doing so is likely to break numerous pre-existing UNIX tools, in particular su and sudo.

• der Dienst fapolicyd prüft beim Aufruf eines Binärprogramms, ob dieses Programm aus den Distributions-Repositories installiert wurde und die Prüfsumme (Hash) der Anwendungs-Programmdatei noch dem Wert in der RPM-Datenbank entspricht.
• wird ein Programm nicht in der RPM-Datenbank gefunden, oder ist die Prüfsumme unterschiedlich, so kann das Programm nicht ausgeführt werden
• über manuelle Regeln kann fapolicyd auch den Zugriff auf Daten-Dateien (inkl. Skripts) einschränken oder verbieten
• Projekthomepage: https://github.com/linux-application-whitelisting/fapolicyd
• Dokumentation: "Configuring and managing application whitelists" https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/security_hardening/index#configuring-and-managing-application-whitelists_security-hardening
• Den fapolicyd Dienst installieren

# dnf install fapolicyd

• Liste der zu überwachenden Dateisysteme / Mountpoint inder Datei /etc/fapolicyd/fapolicyd.mounts erstellen

/
/boot
/run

• den fapolicyd Dienst starten

# systemctl enable --now fapolicyd

• Versuch, FZF, den "command-line fuzzy finder" zu instalieren und zu benutzen (ein statisch gelinktes Go Program)

# dnf -y install tar
# curl -L -O https://github.com/junegunn/fzf-bin/releases/download/0.20.0/fzf-0.20.0-linux_amd64.tgz
# tar xvfz fzf-0.20.0-linux_amd64.tgz
# ls -l fzf
-rwxr-xr-x. 1 501 games 2952388 Dec 17 17:18 fzf
# ./fzf
-bash: ./fzf: Operation not permitted

• fapolicyd im Debug-Modus starten

# systemctl stop fapolicyd
# /usr/sbin/fapolicyd --permissive --debug

• getrlimit Rechte auf "process" Klassen - die SELinux Policy kann nun verhindern das ein Prozess die Prozesslimits eines anderen Prozesses ausliest
• SELinux Policies können nun Zugriffe per mmap auf Dateisystemobjekte wie Dateien, Verzeichnisse und Sockets kontrollieren
• SELinux unterstützt die Systemd Konfiguration No New Privileges. Diese Verhindert das ein Prozess per suid Bit auf einer Datei beim Start erweiterte Rechte bekommt
• neue SELinux Schalter (Booleans)
  • colord_usenfs
  • mysql_connecthttp
  • pdns_{cannetworkconnectdb}
  • ssh_usetcpd
  • sslh_{canbindanyport}
  • sslh_{canconnectanyport}
  • virt_usepcscd

• auf dem Cockpit Jumphost Cockpit-Dashboard installieren

dnf update
dnf install cockpit-dashboard

• neuen Server grafisch über die Web-UI hinzufügen
• auf dem Cockpit Jumphost SSH-Schlüssel erzeugen und eine Passphrase setzen

ssh-keygen -t ed25519

• öffentlicher SSH-Schlüssel vom Cockpit-Jumphost auf das Ziel-System kopieren

ssh-copy-id nutzer@192.168.1.233

• Cockpit auf dem Ziel-System installieren (muss nicht gestartet werden)

dnf install cockpit

• In der Cockpit-Web-UI unter Authentication den neuen SSH-Schlüssel importieren (dabei die Passphrase eingeben)
• das Ziel-System unter "Dashboard" dem Cockpit Jumphost hinzufügen
• das Ziel-System sollte nun im Cockpit Web-UI sichtbar und administrierbar sein

• erstellen der Verzeichnisse. /srv/etc-ro wird das untere (lower) nur-lese Verzeichnis. /srv/etc wird der Mount-Point für das vereinte Verzeichnis, /srv/overlayfs-work ist das Arbeitsverzeichnis des OverlayFS (muss auf dem gleichen Dateisystem liegen wie das obere Verzeichnis)

mkdir /srv/etc-ro
mkdir /srv/etc-rw
mkdir /srv/etc
mkdir /srv/overlayfs-work

• ein paar Daten in das untere (lower) Verzeichnis kopieren

cp -a /etc/* /srv/etc-ro/

• OverlayFS mounten

mount -t overlay overlay \
   -o lowerdir=/srv/etc-ro,upperdir=/srv/etc-rw,workdir=/srv/overlayfs-work \
   /srv/etc

• Verzeichnisse anschauen

ls -l /srv/etc
ls -l /srv/etc-rw
ls -l /srv/overlayfs-work

• eine Datei verändern

$EDITOR /srv/etc/motd

• Dateien in den Verzeichnissen anschauen

cat /srv/etc/motd
cat /srv/etc-ro/motd
cat /srv/etc-rw/motd

Finde heraus, wie sich die Schichten des OverlayFS bei den folgenden Dateisystem-Aktionen verhalten:

• was passiert, wenn eine Datei gelöscht wird?
• was passiert, wenn unter /srv/etc/ ein Verzeichnis erstellt wird?
• was passiert, wenn unter /srv/etc/ ein Verzeichnis gelöscht wird, welches in /srv/etc-ro existiert?
• was passiert, wenn ein Verzeichnis umbenannt wird?

• aus dem Basis-Debian Container-Verzeichnis erstellen wir ein Verzeichnis per OverlayFS, in dem wir nur die Änderungen für einen nginx Webserver speichern
• ein installiertes Debian-Root-Verzeichnis existiert schon in /srv/container/debian
• Verzeichnisse erstellen

mkdir /srv/container/debian-nginx
mkdir /srv/container/debian-nginx-work
mkdir /srv/container/debian-nginx-delta

• Dateisysteme mounten (hier umgebrochen, damit der Befehl auf die Seite passt)

mount -t overlay overlay -o lowerdir=/srv/container/debian, \
  upperdir=/srv/container/debian-nginx-delta, \
  workdir=/srv/container/debian-nginx-work /srv/container/debian-nginx

• Dateisysteme mounten (gleicher Befehl wie zuvor, nun aber alles in einer Zeile zum Kopieren über die Zwischenablage)

mount -t overlay overlay -o lowerdir=/srv/container/debian,upperdir=/srv/container/debian-nginx-delta,workdir=/srv/container/debian-nginx-work /srv/container/debian-nginx

• Container starten auf dem neuen OverlayFS starten

systemd-nspawn -bD /srv/container/debian-nginx

• den nginx Webserver installieren, anschalten und starten

apt update
apt upgrade
apt install nginx
systemctl enable --now nginx

• Container stoppen (im Container)

poweroff

• die OverlayFS Verzeichnisse anschauen

• OverlayFS funktioniert auch über Netzwerklaufwerke, solange die Netzwerklaufwerke das Erstellen von Character-Device-Dateien erlauben
• OverlayFS in der fstab. Die Option noauto,x-systemd.automount verhindert das Systemd das OverlayFS schon beim Systemstart einbindet. Die Option automount sorgt dafür, das das OverlayFS beim ersten Zugriff auf das Verzeichnis /merged eingehangen wird

overlay /merged overlay noauto,x-systemd.automount,lowerdir=/lower,upperdir=/upper,workdir=/work 0 0

• OverlayFS mit mehreren unteren (lower) Verzeichnissen. Wenn "upperdir" und "workdir" nicht angegeben werden, dann ist das Zielverzeichnis auch nur-lesbar.

mount -t overlay overlay -o lowerdir=/lower1:/lower2:/lower3 /merged

• LibreSwan, die IPSEC/IKE2 Implementierung in RedHat 8, unterstützt opportunistisches VPN mit Let's Encrypt Zertifikaten
• bei opportunistischem VPN wird erst eine VPN Verschlüsselung probiert, wenn diese nicht zustandekommt wird unverschlüsselt gesprochen
• bei dem opportunistischem Modus wird der Server von Client authentisiert, aber nicht der Client vom Server (ähnlich wie bei TLS/HTTPS)
• alternativ unterstützt LibreSwan auch ein Mesh-VPN mit Let's Encrypt Zertifikaten. Bei diesem Modus authentisieren sich beide Seiten per x509 Zertifikat.

• wir arbeiten im Internet auf der VM aXX.dane.onl via Cockpit (Port 9090)
• Benutzername nutzer, Passwort villa
• Installation der benötigten Softwarepakete

dnf install git socat libreswan bind-utils

• das ACME Zertifikat wird mit dem Shell-Skript acme.sh angefordert
• acme.sh per git aus dem Repository laden

git clone https://github.com/Neilpang/acme.sh

• acme.sh installieren

cd acme.sh
./acme.sh --install --cert-home /etc/tls --home /etc/acme

• Port 80 für die Kommunikation mit Let's Encrypt freischalten

# firewall-cmd --add-service="http" --permanent
# firewall-cmd --reload

• Test: ein Zertifikat für den Namen aXX.dane.onl per standalone Webservice anfordern (Port 80 auf dem Server muss frei sein)

cd ~
source ~/.bashrc
acme.sh  --issue  -d aXX.dane.onl  --standalone --cert-home /etc/tls
[Sat Feb 29 10:54:21 UTC 2020] Standalone mode.
[Sat Feb 29 10:54:21 UTC 2020] Single domain='aXX.dane.onl'
[Sat Feb 29 10:54:22 UTC 2020] Getting domain auth token for each domain
[Sat Feb 29 10:54:24 UTC 2020] Getting webroot for domain='aXX.dane.onl'
[Sat Feb 29 10:54:24 UTC 2020] Verifying: oe1.dane.onl
[Sat Feb 29 10:54:24 UTC 2020] Standalone mode server
[Sat Feb 29 10:54:28 UTC 2020] Success
[Sat Feb 29 10:54:28 UTC 2020] Verify finished, start to sign.
[Sat Feb 29 10:54:28 UTC 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/79357257/2482192265
[Sat Feb 29 10:54:29 UTC 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/03053523225ecddb768abe8381a834ef13e0
[Sat Feb 29 10:54:30 UTC 2020] Cert success.
-----BEGIN CERTIFICATE-----
MIIFTzCCBDegAwIBAgISAwU1IyJezdt2ir6Dgag07xPgMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDAyMjkwOTU0MjlaFw0y
[...]
VniqleXfkuSZFUzyLlQxmt1pjq8HERHQRGYzdy3LX/Rj35yJ/71gfy+K06BoL+sx
5pJdehKSelTtiOkZ+bP5kBCTs+DHbAs20x098bIBB1XWhyv/8vDKLb01GPJnArPL
YKBCbB00oKMfMpxKYRXVa6ejzAKNDhYmIgTYESZ8rKBtakHvRQI6WnLB0zunfHBE
66rLAVn7OKupPXRouN5e0IFRKA==
-----END CERTIFICATE-----
[Sat Feb 29 10:54:30 UTC 2020] Your cert is in  /etc/tls/aXX.dane.onl/aXX.dane.onl.cer
[Sat Feb 29 10:54:30 UTC 2020] Your cert key is in  /etc/tls/aXx.dane.onl/aXX.dane.onl.key
[Sat Feb 29 10:54:30 UTC 2020] The intermediate CA cert is in  /etc/tls/aXX.dane.onl/ca.cer
[Sat Feb 29 10:54:30 UTC 2020] And the full chain certs is there:  /etc/tls/aXX.dane.onl/fullchain.cer

• x509-Zertifikat in eine p12 Zertifikatsdatei wandeln

# openssl pkcs12 -export -inkey /etc/tls/aXX.dane.onl/aXX.dane.onl.key \
    -in /etc/tls/aXX.dane.onl/aXX.dane.onl.cer \
    -name aXX.dane.onl \
    -certfile /etc/tls/aXX.dane.onl/fullchain.cer \
    -out aXX.dane.onl.p12

• IPSec (NSS) Zertifikatsdatenbank erstellen

# ipsec initnss
Initializing NSS database

• die p12 Zertifikatsdatei in die Zertifikatsdatenbank von LibreSwan importieren

# ipsec import aXX.dane.onl.p12
Enter password for PKCS12 file:
pk12util: PKCS12 IMPORT SUCCESSFUL

• die Vorlage der Server-Konfigurationsdatei für opportunistische Verschlüsselung (OE = opportunistic encryption) kopieren

# cp /usr/share/doc/libreswan/examples/oe-letsencrypt-server.conf /etc/ipsec.d/

• die Konfigurationsdatei anpassen, den Namen des eigenen Servers eintragen

[...]
	leftcert=aXX.dane.onl
[...]

• IPSec Policy anpassen. Wir wollen das jede beliebige IP-Adresse (0.0.0.0/0) die Verbindung starten kann. Policy ist clear-or-private, d.h. wenn die Gegenstelle IPSec startet, dann wird verschlüsselt, ansonsten wird unverschlüssel kommuniziert

echo "0.0.0.0/0" >> /etc/ipsec.d/policies/clear-or-private

• IPSec (neu-) starten um die neue Konfiguration zu aktivieren

# systemctl enable --now ipsec

• IPSec Statusmeldungen anzeigen

journalctl -fu ipsec

• wir arbeiten im Internet auf der VM bXX.dane.onl via Cockpit (Port 9090)
• Pakete auf der Client-Seite installieren. Wir benutzen den DNS-Resolver Unbound, um lokale DNSSEC-Validierung zu bekommen

dnf install libreswan unbound

• Unbound aktivieren und starten

# systemctl enable --now unbound

• systemd-resolved antwortet auf die Anfragen zu den Namen _gateway (lokales Netzwerk-Gateway), localhost und den eigenen Hostnamen.

[root@centos-2gb-nbg1-1 ~]# dig @127.0.0.53 centos-2gb-nbg1-1 +short
127.0.0.1
[root@centos-2gb-nbg1-1 ~]# dig @127.0.0.53 _gateway +short
172.31.1.1

• systend-nspawn macht die Datei /etc/resolv.conf des Hosts per Bind-Mount im Container verfügbar. Der Container hat damit die gleiche DNS-Stub-Resolver Konfiguration wie der Host
• systemd-resolved erstellt dynamisch die DNS-Stub-Konfigurations-Datei /run/systemd/resolve/stub-resolv.conf. Um systemd-resolved als Systemd-Resolver zu benutzen kann die Datei /etc/resolv.conf ein (symbolischer-) Link auf diese Datei sein.

# cat  /run/systemd/resolve/stub-resolv.conf 
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53

• systemctl kill hat nun ein --fail Parameter. Damit gibt der Befehl einen Fehlercode zurück, wenn kein Prozess gekillt werden konnte (weil z.B. die Unit keinen Prozess gestartet hatte)
• Der Befehl systemctl exit (benutzt z.B. um Systemd-nspawn Container zu verlassen) nimmt nun optional einen Exit-Code als Rückgabewert.
• Zeit-Konfigurationsparameter in Unit-Dateien verstehe den Wert infinity. In RHEL7/CentOS 7 wurde der Wert 0 für "unendlich" benutzt. Der Wert 0 bedeutet nun "sofort".
• der Befehl systemctl revert setzt eine Unit auf den Auslieferungszustand zurück, alle manuellen Änderungen werden verworfen
• Die Unit-Optionen MemoryLimit und TasksMax können jetzt auch Prozentwerte entgegennehmen
• systemctl und systemd-run besitzen nun einen neuen Parameter --wait welcher die Befehle veranlasst, zu warten bis die gestartete Unit wieder beendet wurde
• Systemd-Units haben nun einen internen Zähler NRestarts welcher angibt, wie oft eine Unit automatisch neu gestartet wurde

# systemctl show -p NRestarts systemd-resolved
NRestarts=1

• systemd-analyze hat den Sub-Befehl cat-config, dieser Sub-Befehl gibt eine Systemd-Konfigurationsdatei inkl. aller drop-in Änderungen aus (so wie Systemd die Konfigurationsdatei "sieht"). Die Befehle systemd-tmpfiles und systemd-sysusers haben die ähnliche Option --cat-config bekommen

# systemd-analyze cat-config systemd/journald.conf

• Units mit Syntax-Fehlern in der Unit-Datei bekommen nun den Status bad-setting
• Programmnamen in der Option ExecStart in Unit-Dateien müssen nicht mehr mit vollem Pfad angegeben werden. Die Dateien werden in einem Systemd-internen Suchpfad gesucht. Dieser Pfad kann mittels systemd-path search-binaries-default abgefragt werden
• besitzt eine Unit-Datei Bindestriche/Minus im Dateinamen, so werden Drop-In Dateien hierarchisch gesucht. Heisst die Unit foo-bar-baz.service, so werden Drop-Ins in foo-bar-baz.service.d/*.conf (Default) und zusätzlich in "foo-bar-.service.d/*.conf und foo-.service.d/ gesucht.

• es gibt einen eigenen (EFI-)Bootloader in Systemd mit dem Namen systemd-boot (früher Gummiboot). Mit dem Befehl bootctl list kann die (EFI) Boot-Konfiguration ausgegeben werden.
• systemctl reboot --firmware-setup bootet den Rechner in das EFI Setup Programm
• systemctl reboot hat nun einen Schalter --message um eine Meldung an die angemeldeten Benutzer zu senden
• Wenn Systemd (PID 1) beim Systemstart bemerkt das das Systemdatum vor dem Release der Systemd-Version liegt, so wird das Datum auf das Systemd-Release-Datum gesetzt
• Über die Einstellung CtrlAltDelBurstAction in der Konfigurationsdatei /etc/systemd/system.conf kann definiert werden, was passiert wenn der Benutzer mehr als 7 mal innerhalb von 2 Sekunden die Tastenkombination Ctrl-Alt-Del drückt

• Timer-Units haben eine neue Einstellung RemainAfterElapse welche angibt, wie lange die Unit im System nach dem Beenden noch sichtbar sein soll (damit ein Benutzer den Status abfragen kann)
• Zeiten in Timer-Units können nun Intervalle mit den Zeichen ".." definieren. Beispiel: "4..7:10" veranlasst den Timer um 4:10, 5:10, 6:10 und 7:10 jeden Tag zu starten
• der Befehl timedatectl show gibt die Konfiguration des Dienstes systemd-timedated aus

# timedatectl show
Timezone=Europe/Berlin
LocalRTC=no
CanNTP=yes
NTP=yes
NTPSynchronized=yes
TimeUSec=Thu 2020-03-05 07:40:57 CET
RTCTimeUSec=Thu 2020-03-05 07:40:57 CET

• Es gibt nun Python Bindings für Systemd: https://github.com/systemd/python-systemd
• Mit dem Befehl systemd-socket-activate können Ad-Hoc Socket-Dienste erzeugt werden

systemd-socket-activate -l 2000 --inetd -a cat
systemd-socket-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd

• bei Socket-Units kann die Anzahl der Verbindungen von einer Quelle (IP-Adresse) limitiert werden: MaxConnectionsPerSource
• systemd-socket-proxyd hat den neuen Parameter --connections-max um die maximale Anzahl gleichzeitiger Verbindungen zu konfigurieren
• systemd-run hat nun die Parameter --pipe um die Ausgaben der Ad-Hoc Unit über Standard-Eingabe/Ausgabe/Fehler-Kanal an die Shell weiterzugeben. Damit können diese Systemd-Units in Shell-Pipelines verwendet werden

• systemd-socket-proxyd ist eine Socket-Proxy Komponente, um Daten zwischen IPv4, IPv6 und Unix-Domain-Sockets zu verbinden
• ermöglicht es, Programme, welche nur Unix-Domain-Sockets anbieten, über das Netzwerk anzusprechen (Sicherheit beachten, Zugriff einschränken, ggf. Verschlüsseln!)
• ermöglicht es, IPv4 auf IPv6 oder IPv6 af IPv4 umzusetzen
• kann Socket-Proxy-Lösungen mit netcat, nc oder socat ersetzen
• Aktivierung von systemd-socket-proxyd über eine Socket-Unit und eine Service-Unit
• Beispiel IPv4 auf IPv6 Umsetzung: der Webserver ist in einem IPv6-only Netwerk unter der Adresse 2001:db8::80 erreichbar. Der Socket-Proxy-Server nimmt Anfragen auf Port 80 auf der IPv4-Adresse 192.0.2.6 an und startet die Service-Unit welche per systemd-socket-proxyd die Verbindung an den IPv6-Webserver herstellt.
  • Socket Unit

[Socket]
ListenStream=192.0.2.6:80

[Install]
WantedBy=sockets.target

• Service Unit

[Unit]
Requires=web-ipv4-to-ipv6.socket
After=web-ipv4-to-ipv6.socket

[Service]
ExecStart=/usr/lib/systemd/systemd-socket-proxyd [2001:db8::80]:80
PrivateTmp=yes

• iptables ist fragmentiert, mehrere Kommandos mit sehr ähnlicher Funktion -> Code-Duplizität
  • iptables
  • ip6tables
  • arptables
  • ebtables
• nftables vereint diese Funktionen in einem Werkzeug

• bei iptables gibt es eine "Race-Condition"-Gefahr durch das Fehlen eines Regelsatz-Kompilers
  • iptables hat kein eigenes Konfigurationsformat für Firewall-Regeln
  • das Regelwerk wird über Aufrufe des iptables Kommandos aufgebaut.
• bei nftables können die Regeln in einer Regelsatz-Datei definiert und per Transaktion in den Kernel geladen werden

• iptables Regelwerke werden durch Shell-Scripte aufgebaut
  • erhöhte Komplexitaet für Firewall-Administratoren mit geringem Shell-Scripting-Wissen
• die Regel-Beschreibungsprache von nftables ist einfach(er) lesbar

• iptables-Firewall ist durch statische Kernel-Module für die Haupt-Funktionen und Erweiterungen implementiert
• Diese Module benutzen das gleiche Kernel-Framework (netfilter), duplizieren aber einen nicht unerheblichen Teil der Firewall-Funktionen in jedem Modul

• nftables implementiert die Firewall-Funktionalität durch eine generische Virtuelle-Maschine im Kernel
  • Die virtuelle Maschine wird von dem Kommandozeilen-Tool nft mit Bytecode geladen
  • Der Bytecode ist ein Repräsentation der Firewall-Regeln als ausführbares Programm für die nftables-VM
  • Der Bytecode wird ausserhalb des Kernels erzeugt und in die nftables-VM des Kernels geladen
  • Neue Firewall-Funktionen können so unabhähngig von der Kernel-Version realisiert werden

• nft verwaltet die nftables-Firewall.
• Anders als das iptables Kommando werden die Firewall-Regeln nicht durch Kommandozeilen-Parameter angegeben, sondern in der nftables-eigenen Beschreibungssprache für Firewall-Regeln.
  • Diese Beschreibungssprache funktioniert ein wenig wie eine kleine Programmiersprache.

• Neben Definitionen von Firewall-Regeln nimmt nft auch Befehle entgegen
  • löschen einer Regel
  • löschen des gesamten Regelsatzes
  • Export der aktiven Regeln in eine Datei

• nft kann Regeln aus einer Datei, von der Kommando-Zeile (Shell) oder in einem interaktiven Modus direkt vom der Tastatur einlesen.
• Da die Beschreibungssprache Zeichen beinhalten kann, welche in Unix-Shells besondere Bedeutungen haben, müssen diese Zeichen, oder besser der gesamte nft Befehlsteil, per Quoting vor dem Zugriff der Shell geschützt werden.

• Beispiel: Lesen der Firewall-Regeln aus einer Datei

# nft -f /etc/nftables/firewall.nft

• Beispiel: Eine Regel (IPv4, Tabelle "fw", Kette "input") hinzufügen

# nft "add rule ip fw input drop"

• Beispiel: eine interaktive nft Sitzung

# nft -ia
nft> list ruleset
table inet workstation-fw {
    chain input {
             type filter hook input priority 0;
    }
}
nft> add rule inet workstation-fw input tcp dport {ssh, http} accept
nft> list ruleset
table inet workstation-fw {
    chain input {
             type filter hook input priority 0;
             tcp dport { ssh, http} accept # handle 3
    }
}
nft> quit

• Der Befehl flush löscht Objekte aus der nftables Kernel-Firewall.
• Ein flush ruleset löscht die gesamten Firewall-Regeln.
• Ein flush ruleset sollte am Anfang eines nftables-Regelsatzes stehen:

# nft flush ruleset

• Über flush chain und flush table können Ketten und Tabellen gelöscht werden.

• Der Befehl add fügt die Regel immer am Ende der Kette an
• mit insert kann eine Regel an einer beliebigen Stelle der Kette eingefügt werden.
• Der Befehl delete löscht eine Regel aus einer Kette. Zum Löschen einer Regel wird das Handle der Regel benötigt, das Handle wird über den Kommandozeilenparameter -a ausgegeben:

# nft -a list ruleset
...
ip6 saddr 2001:db8::/64 # handle 15
...
# nft delete rule inet filter input handle 15

• Mittels nft monitor können Änderungen in der nftables-Firewall überwacht werden.
• Der Befehl schreibt Modifikationen im Regelsatz der Firewall als nft-Befehlszeilen (Alternativ als XML oder JSON) auf die Konsole:

# nft monitor
add table inet filter
add chain inet filter input { type filter hook input priority 0; }
add rule inet filter input iif lo accept
add rule inet filter input ct state established,related accept
add rule inet filter input ip6 daddr ff02::1010 udp dport ntp accept
add rule inet filter input ip6 daddr ff02::fb udp dport mdns accept
add rule inet filter input ip daddr 224.0.0.251 udp dport mdns accept
add rule inet filter input ip6 saddr & :: == :: udp dport dhcpv6-client accept
add rule inet filter input udp dport ipp accept
add rule inet filter input ip6 saddr & :: == :: icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert} accept
add rule inet filter input ip6 saddr & :: == :: icmpv6 type { echo-reply, echo-request, packet-too-big, destination-unreachable, time-exceeded, param-problem} accept
add rule inet filter input counter packets 0 bytes 0 log prefix "nftables drop: " drop

• die aus iptables bekannten Konzepte von Tabellen (Tables) und Ketten (Chains) finden sich auch in nftables wieder
• vordefinierten Tabellen (in iptables 'filter', 'nat' und 'mangle') gibt es im nftables nicht
• Auch die in iptables vorhandenen Ketten ('input', 'output', 'forward') sucht man vergebens
• nftables kommt ohne vordefinierte Tabellen und Ketten.
• Die vordefinierten Ketten in iptables sind ein Performance-Problem bei grossen Datenmengen, da Netzwerkpakete auch durch unbenutze, leere Ketten geschleusst werden.
  • Unter nftables sind nur Tabellen und Ketten aktiv, welche der Administrator definiert hat.

• In nftables sind Tabellen einfache Container für beliebige Ketten. Eine Tabelle muss einem Protokoll zugewiesen werden (ip = IPv4, arp, ip6 = IPv6, inet = IPv4 und IPv6, bridge).
• Die Tabellen können beliebige Namen haben, auch wenn in vielen Beispielen im Internet die aus iptables bekannten Namen verwendet werden.

• Bei den Ketten (Chains) unterscheidet man "base-chains" und "auxiliary chains".
• Bei den "base-chains" handelt es sich um Ketten, welche in den Paketfluss des Netfilter-Framework eingeklinkt werden.
  • Diese Ketten erhalten Netzwerkpakete aus den Zugriffspunkten (Hooks) des Linux-Kernels.
  • Diese Zugriffspunkte für eine Kette vom Typ "filter" heissen "input", "output" und "forward".
  • Die Konzepte sind von iptables übernommen worden, der Firewall-Administrator hat nun aber mehr Freiraum, die Ketten zu organisieren.

• Beispiel einer Tabelle mit zwei (leeren) "filter" Ketten, für "input" und "output":

table inet filter01 {
        chain input01 {
                type filter hook input priority 0;
        }
        chain output01 {
                type filter hook output priority 0;
        }
}

• Mit dem Schlüsselwort hook wird eine Kette mit den Linux-Kernel-Internen Schnittstellen des Netfilter-Frameworks verbunden.
• Eine Kette mit Verbindung zum den Kernel-Schnittstellen ist eine "base-chain".
• Zusätzlich zu den "base-chains" kann der Administrator noch beliebig weitere "auxiliary chains" erzeugen.
• Diese Chains erhalten nur Netzwerkpakete, wenn diese aus einer "base-chain" per goto oder jump Direktive an die "auxiliary chain" verteilt werden:

table inet filter01 {
        # auxiliary chain 
        chain link-local-aux01 {
                 counter packets 0 bytes 0 log prefix "link-local: " accept
                 # weitere Regeln für link-local IPv6 
                 [...]
        }
        # base chain
        chain input01 {
                type filter hook input priority 0;
                ip6 daddr fe80::/64 jump link-local-aux01
        }
        # base chain
        chain output01 {
                type filter hook output priority 0;
        }

}

• Eine Hauptaufgabe einer Firewall ist das Filtern von Netzwerkverkehr.
• Die nftables-Firewall bietet umfangreiche Möglichkeiten, Netzwerkpakete in Filterregeln auszuwählen:
  • nach Quell- und Ziel-Adressen
  • UDP- und TCP-Ports
  • Meta-Informationen wie
    • Netzwerk-Interfaces
    • Protokolle
    • Hardware-MAC-Adressen
    • VLAN-Informationen
    • Status einer IP-Verbindung (Connection-Tracking)

• In diesem Beispiel wird eine Regel der Firewall hinzugefügt.
• Gefiltert wird nach der IPv6-Zieladdresse daddr ff02::fb und dem UDP-Port dport mdns (Multicast-DNS):

# nft "add rule inet filter input ip6 daddr ff02::fb udp dport mdns accept"

• Eine Liste der Filter-Optionen findet sich in der man-Page zu nft.

• Am Ende einer Firewall-Regel wird das Urteil (Verdict) über eine Netzwerk-Verbindung getroffen, das sogennante Verdict-Statement.
• Es gibt entgültige Urteile, welche die Bearbeitung eines Netzwerkpaketes sofort beenden.
• Dazu zählen
  • accept (Paket passieren lassen)
  • drop (Paket ohne Rückmeldung an den Sender verwerfen) und
  • reject (mit Rückmeldung verwerfen).

• Bei reject kann optional die ICMP-Meldung spezifiziert werden, welche an den Sender des Paketes zurückgeliefert wird:

# nft "add rule inet filter input ip6 saddr 2001:db8::/64" \
      "reject with icmpv6 type admin-prohibited"

• Neben den entgültigen Urteilen kann eine Regel die Bearbeitung eines Paketes auch an anderen Stelle fortsetzen:
  • continue Bearbeitung des Paketes mit die nächsten Regel in der Kette
  • jump <chain> verzweigt die Bearbeitung wie ein Unterprogrammaufruf in eine andere Kette. Am Ende der neuen Kette wird die Bearbeitung in der ursprünglichen Kette weitergeführt.
  • goto <chain> wird direkt in eine andere Kette gesprungen, ohne das die Bearbeitung jemals wieder zurückkehrt.
  • queue verzweigt die Verarbeitung an ein externes Programm im Userspace.
  • return beendet die Bearbeitung der aktuellen Kette an dieser Stelle. Wird return in einer Kette der obersten Bearbeitungsebene verwendet, so wird das Paket durch die Firewall gelassen (identisch zu einem accept).

• Über das Befehlswort log werden Informationen zu dem gerade bearbeiteten Netzwerk-Paket in das Kernel-Log (und damit in den meisten Systemen auch in das System-Log) geschrieben.
• Der Befehl counter erzeugt einen Zähler für diese Firewall-Regel.

• Anders als bei iptables müssen Counter für Regeln explizit erzeugt werden. Dies hat Performance-Gründe, die Zähler werden nur dann mitgeführt, wenn der Administrator diese im Regelsatz angefordert hat.
• In dem Zähler werden die Anzahl der gefilterten Pakete und die Datenmenge in Bytes gezählt.
• Der Zähler wird beim Auflisten des Regelwerkes, z.B. mit list ruleset, ausgegeben.

• Die Position des Befehls log in der Regel wichtig:
  • Steht der Befehl vor der Filter-Bedingung, so wird ein Log-Eintrag für jedes Paket geschrieben, welches von dieser Regel gesehen wird, unabhängig ob die Regel danach aktiv wird oder nicht.
  • Steht jedoch der Befehl log nach der Filterbedingung, so wird der Log-Eintrag nur geschrieben, wenn die Filterbedingung zutrifft.

• Gleiches gilt für die Position des Befehls counter.

# schreibe einen Log-Eintrag für jedes Paket welches von dieser Regel gesehen wird
log tcp dport { 22, 80, 443 } ct state new accept
# schreibe einen Log-Eintrag nur wenn die Regel zutrifft
tcp dport { 22, 80, 443 } ct state new log counter accept

• Dem Befehl log kann mit dem Parameter prefix eine beliebige Zeichenkette mitgegeben werden.
• Diese Zeichenkette erscheint vor jeder Log-Meldung und wird benutzt, um Log-Einträge zu finden und zu filtern.

• Neben den Protokollen ip für IPv4 und ip6 für IPv6 unterstützt nftables auch das Pseudo-Protokoll inet für kombinierte IPv4- und IPv6-Filter.
• Anstatt z.B. Port 80 für einen Webserver in zwei getrennten Regeln für je IPv4 und IPv6 freizugeben, kann dies in nftables in nur einer Regel geschehen.
• Bei einem Server mit Dual-Stack und vielen Diensten kann dies das Regelwerk vereinfachen.

• Für das Protokoll inet muss eine eigene Tabelle mit Chains erstellt werden.

table inet filter {
    chain input { 
       ...
    }
}

• Die Tabelle mit dem Pseudo-Protokoll inet existiert paralell zu Tabellen mit IPv4- und IPv6-Regeln.
• Werden Tabellen mit dedizierten IPv4 und IPv6 Regeln genutzt, so müssen die Pakete sowohl in der inet Tabelle als auch in der jeweiligen Tabelle für das IP-Protokoll erlaubt werden.
• Um Fehler zu vermeiden, sollte entweder kombinierte inet Tabellen, oder protokoll-spezifische Tabellen benutzt werden, aber nicht beides.

• nftables bietet verschiedene Datenstrukturen, welche die Erstellung eines Regelwerkes vereinfachen:
  • Variablen
  • Intervalle
  • Sets
  • benannte und anonyme Maps
  • benannte und anonyme Dictionaries/Verdict-Maps

• Variablen erlauben symbolische Namen für Werte und IP-Adressen in einem nftables-Regelwerk.
• Variablen sind jeweils in der Umgebung sichtbar, in der sie definiert wurden (Table, Chain).

• Variablen werden über das Schlüsselwort define deklariert und mit einem Wert versehen.
• Im Regelwerk wird dann der Variablenname mit einem vorangestellem Dollar-Zeichen "$" verwendet, vergleichbar mit Variablen der Unix-Shell.

define lan_if = eth0
define DMZ-Dienste = { ssh, smtp, dns, http, https }
add rule inet filter input iif $lan_if tcp dport $DMZ-Dienste accept

• Intervalle in nftables sind Wertefolgen mit einem Start- und End-Wert. Intervalle werden z.B. für IP-Adresse-Bereiche und TCP/UDP-Port-Bereiche verwendet.

nft "add rule inet filter input ip6 daddr 2001:db8::0-2001:db8::1000 drop"
nft "add rule inet filter input tcp dport 0-1023 drop"

• Sets definieren eine Sammlung von Werten eines gleichen Typs.
• Ein Set wird durch geschweifte Klammern eingeleitet und die Elemente des Sets werden mit Komma getrennt.
• Beispiel: Ein anonymes Set mit Port-Nummern (Microsoft SMB/CIFS-Protokoll):

nft "add rule inet filter input udp dport { 137, 138, 139, 445 } reject" 

• Bei der Anlage eines benannten Sets muss nftables der Werte-Typ mitgeteilt werden.
• Eine (leider noch unvollständige) Liste der verfügbaren Werte-Typen ist in der nft man-Page aufgelistet:

nft "add set inet filter bogus { type ipv4_addr; }"
nft "add element inet filter bogus { 203.0.113.0; }"
nft "add element inet filter bogus { 203.0.113.1; }"
nft "add rule inet filter input ip saddr @bogus drop"
nft "list set inet filter bogus"

• Der letzte Befehl des Beispiel gibt den aktuellen Inhalt des benannten Sets bogus aus.

• Ein benanntes Set kann in einer Regel mit vorangestelltem "@" eingefügt werden.
• Eine Filterregel mit benanntem Set wird vom der nftables Virtuellen-Maschine schneller bearbeitet als eine Reihe von Einzel-Regeln.

• Maps und Dictionaries existieren in anonymen (statischen) und benannten Versionen.
• Die anonymen Versionen werden direkt in die Regel geschrieben und sind damit fester Bestandteil der Regel.
• Die Inhalte von anonymen Datenstrukturen können nicht zu einem späeteren Zeipunk geändert werden.

• Bei den benannten Maps und Dictionaries können die Inhalte nach dem Laden des Firewall-Regelwerkes noch angepasst werden.
• So können z.B. Programme wie fail2ban oder denyhost direkt mit der Firewall interagieren und IP-Adressen von Angreifern sperren.
• Oder eine Anti-Spam-Dienst kann das Einliefern von Spam-E-Mail über die IP-Adressen von identifizierten Spammern mittels einer Rate-Limit-Regel drosseln.

• Maps oder Data-Maps verbinden zwei Werte miteinander.
• Der Eingangswert wird in der Liste der Index-Werte der Map gesucht und der dort gespeicherte Wert wird an die Regel zurückgegeben.
• Eine Beispiel-Anwendung ist das Verzweigen auf verschiedene interne Server mit privaten Adressen per NAT, basierend auf der Port-Nummer des Dienstes:

# nft "add rule ip nat prerouting dnat" \
      "tcp dport map { 80 : 192.168.1.100, 8888 : 192.168.1.101 }"

• Verdict-Maps, auch Dictionaries genannt, verbinden einen Eingangswert des zu betrachtenen Pakets mit der Filter-Entscheidung einer Regel.
• Somit lassen sich für die verschiedenen Werte einers IP-Paketes automatisch unterschiedliche Aktionen auslösen.

• In diesem Beispiel werden die Ergebnisse einer Regel an die Quell-IPv4-Adresse des Netzwerk gebunden:

nft "add map inet filter aktion { type ipv4_addr : verdict; }"

nft "add element inet filter aktion" \
    "{ 192.0.2.80 : accept, 192.0.2.88 : drop, 192.0.2.99 : drop }"

nft "add rule inet filter input ip saddr vmap @aktion"

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

flush ruleset

define any = 0::0/0

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

                # accept any localhost traffic
                iif lo accept

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

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

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

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

                # DHCPv6
                ip6 saddr $any udp dport 546 accept

                # IPP (CUPS)
                udp dport 631 accept

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

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

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

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

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

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

• Sollte ICMP geblockt werden? http://shouldiblockicmp.com/

• "Port Knocking" beschreibt eine Sicherheitstechnik, bei der ein Port in einer Firewall erst geöffnet wird, nach dem der Client auf einen (oder mehreren) spezifischen Port(s) verbunden ("angeklopft") hat.
• im nachfolgenden Beispiel wird der Port für Secure Shell (SSH, Port 22) erst nach einer TCP Verbindung auf Port 6502 geöffnet. Nach 90 Sekunden wird der Port automatisch geschlossen.
• Alternativen zu TCP Ports für Port Knocking sind ICMP-Pakete mit speziellen (ungebräuchlichen) Parametern, Flags in IP-Headern, IPv6 Extension-Header oder spezielle Daten in UDP-Pakete auf einem geöffneten Port (z.B. DNS)
• in Datei /etc/nftables/inet-filter.nft

# Regelsatz löschen
flush ruleset

# Variable "any" definieren
define any = 0::0/0

table inet filter {
        # Set mit IPv4 Adressen und Timeout-Werten
        set allow_ssh4 {
                type ipv4_addr;
                flags timeout;
        }
        set allow_ssh6 {
                type ipv6_addr;
                flags timeout;
        }
        chain input {
                type filter hook input priority 0;
                policy accept;

                # alle Pakete auf dem Loopback Interface erlauben
                iif lo accept;

                # alle Pakete von bestehenden Verbindungen erlauben
                ct state established,related accept;

                # wird auf Port 6502 verbunden, so wird die Quell-IP-Adresse
                # in das Set "allow_ssh[4|6]" mit einem Timeout von 90 Sekunden aufgenommen
                ip  daddr  94.130.27.184         tcp dport 6502 log add @allow_ssh4 { ip  saddr timeout 90s } reject;
                ip6 daddr  2a01:4f8:c0c:7c3c::1  tcp dport 6502 log add @allow_ssh6 { ip6 saddr timeout 90s } reject;

                # erlaube SSH für alle Quell-IP-Adressen, welche in dem Set
                # "allow_ssh" gespeichert sind
                ip  saddr @allow_ssh4 tcp dport ssh log accept;
                ip6 saddr @allow_ssh6 tcp dport ssh log accept;

                # IPv6 neighbour discovery, notwendig für IPv6
                ip6 saddr $any icmpv6 type { nd-neighbor-solicit,
                                             nd-router-advert,
                                             nd-neighbor-advert }  accept

                # ICMPv6 essentielle Meldungen 
                ip6 saddr $any icmpv6 type { echo-reply,
                                             echo-request,
                                             packet-too-big,
                                             destination-unreachable,
                                             time-exceeded,
                                             parameter-problem } accept


                # alle anderen Pakete verwerfen
                log drop;
        }
}

• inet nftables Regeldatei unter /etc/sysconfig/nftables.conf freischalten

#
# This this will contain your nftables rules and
# is read by the systemd service when restarting
#
# These provide an iptables like set of filters
# (uncomment to include)
# include "/etc/nftables/bridge-filter.nft"
include "/etc/nftables/inet-filter.nft"
# include "/etc/nftables/ipv4-filter.nft"
# include "/etc/nftables/ipv4-mangle.nft"
# include "/etc/nftables/ipv4-nat.nft"
# include "/etc/nftables/ipv6-filter.nft"
# include "/etc/nftables/ipv6-mangle.nft"
# include "/etc/nftables/ipv6-nat.nft"

• nftables Unit (neu) starten

systemctl start nftables

• nftables Unit aktivieren

systemctl enable nftables

• Testen

telnet aXX.dane.onl 6502  # <-- anklopen
ssh aXX.dane.onl          # SSH funktioniert nach dem Anklopfen

• Manuell einen Eintrag für 1 Stunde in die Map eintragen

nft add element table inet filter allow_ssh4 { 192.0.2.22 timeout 3600 }

• Homepage https://firewalld.org
• nftables Backend für Firewalld https://firewalld.org/2018/07/nftables-backend
• nftables Firewall-Regelwerk Dokumentation: https://www.netfilter.org/projects/nftables/manpage.html
• FirewallD erstellt nun Regeln für die nftables Firewall, nicht für iptables
• iptables ist jedoch noch Bestandteil von RHEL8/CentOS8

• Unbound Konfiguration unter /etc/unbound/unbound.conf anpassen

# DNS-over-TLS Ports freischalten
interface: 0.0.0.0@853
interface: ::0@853
# Access Control Lists
access-control: 0.0.0.0/0 allow
access-control: 127.0.0.0/8 allow
access-control: ::0/0 allow
# DoT Konfiguration
tls-service-key: "/etc/tls/aXX.dane.onl/aXX.dane.onl.key"
tls-service-pem: "/etc/tls/aXX.dane.onl/aXX.dane.onl.cer"
tls-port: 853

• Unbound Konfiguration testen

unbound-checkconf

• Unbound neu starten

systemctl restart unbound

• Golang Entwicklungspakete installieren. Go-Programme sind statische Programme, die Programme können auf einem beliebigen 64bit Linux-Rechner kompiliert werden und dann auf den DoH-Server übertragen werden. Die Entwicklungsprogramme sollte nicht auf einem Produktions-Server im Internet liegen!

dnf install make git golang

• trustydns Quellcode aus Github laden, Fehlermeldung ignorieren

go get -d -u github.com/markdingo/trustydns

• trustydns übersetzen

cd /root/src/src/github.com/markdingo/trustydns
make updatepackages
make all
make install

• Resolver Konfiguration anlegen, so das trustydns den lokalen Unbound als Resolver benutzt

echo "nameserver 127.0.0.1" > /etc/unbound/resolv.conf

• DoH Server starten

trustydns-server -tls-cert /etc/tls/aXX.dane.onl/fullchain.cer \
      -tls-key /etc/tls/aXX.dane.onl/aXX.dane.onl.key \
      -c /etc/unbound/resolv.conf 

• DoH Server testen

# /usr/local/bin/trustydns-dig https://aXX.dane.onl/dns-query heise.de a   
;; opcode: QUERY, status: NOERROR, id: 65408
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;heise.de.      IN       A

;; ANSWER SECTION:
heise.de.       86400   IN      A       193.99.144.80

;; Query Time: 9ms/104ms
;; Final Server: https://aXX.dane.onl/dns-query
;; Tries: 1(queries) 1(servers)
;; Payload Size: 50

• auf dem Router und auf dem Laptop die Tor-Software installieren

apt install tor

• auf dem Laptop bei installiertem Tor-Dienst den Socksv5-Proxy im Browser auf Port 9050 einstellen
• Alternativ kann der Tor-Browser des Tor-Projekt installiert werden ( http://www.torproject.org ). Der Tor-Browser hat den Tor-Daemon schon eingebaut, dieser muss dann nicht extra installiert sein

• auf dem Router in der Tor-Konfiguration einen Onion Hidden-Service auf Localhost Port 8000 einrichten

$EDITOR /etc/tor/torrc
[...]
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:8000
[...]

• Tor neu starten

systemctl restart tor
systemctl status tor

• auf dem Router einen Webserver Service starten (einfacher Python Webserver auf Port 8000)

python -m SimpleHTTPServer

• auf dem Router den Onion-Namen herausfinden (Datei /var/lib/tor/hidden_service/hostname) und an einen der Teilnehmer weitergeben oder selbst im Firefox (bei eingeschaltetem Socks5-Proxy auf Port 9050)
• den Onion-Dienst mit diesem "Domain"-Namen ansprechen, per Socks-Proxy aus dem Firefox oder mit dem Tor-Browser

• einige Programme (wie ssh oder links) haben keinen Support für Socks5 Proxies
• mit dem Programm torify können Programm für Tor eingerichtet werden

torify links http://<onion-adresse>.onion

• Einige Server-Dienste schalten spezielle Admin-Funktionen frei, wenn der Server über eine Loopback-Adresse (127.0.0.1) angesprochen wird (z.B. der Apache Webserver –> https://www.heise.de/security/meldung/Apache-verpetzt-moeglicherweise-Tor-Hidden-Services-3090218.html). Bei Bennutzung als Tor-Dienst auf einer Loopback-Adresse sind diese Admin-Funktionen von aussen über das Tor-Netzwerk erreichbar. Lösung: den Dienst auf einer nicht-Loopback Adresse konfigurieren, oder die speziellen Admin-Funktionen in der Server-Konfiguration ausschalten.

• seit Version 0.3.5 der Tor-Software wird ein neues, sicheres Protokoll für die Onion-Services verwendet. Die Konfiguration der Authentisierung von Tor-Clients mit der Version 3 der Onion-Services wird im folgenden beschrieben

• DEF CON 27 Conference - Roger Dingledine - The Tor Censorship Arms Race The Next Chapter https://www.invidio.us/watch?v=ZB8ODpw_om8&feature=youtu.be
• HiddenService einrichten https://matt.traudt.xyz/p/FgbdRTFr.html
• Onion-Dienste des Tor-Projektes https://onion.torproject.org/
• Connecting to an authenticated Onion service https://github.com/AnarchoTechNYC/meta/wiki/Connecting-to-an-authenticated-Onion-service

• Installationsinformationen für Wireguard https://www.wireguard.com/install/
• Derzeit ist Wireguard noch nicht in den Linux-Kernel eingezogen, soll aber in Version ~5.6 in den Kernel kommen
• der Laptop ist unser Wireguard-Client
• auf dem Laptop und auf dem VPS Server im Internet das Wireguard Repository hinzufügen, Paketlisten updaten und Wireguard-Pakete installieren

echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable.list
printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' > /etc/apt/preferences.d/limit-unstable
apt update
apt upgrade
reboot
apt install wireguard linux-headers-$(uname -r)

• User-Mask für neue Dateien und Verzeichnisse setzen, ein Verzeichnis für die Wireguard-Dateien erstellen

umask 077
mkdir -p /etc/wireguard
cd /etc/wireguard

• einen privaten Schlüssel für den Wireguard-Dienst erstellen

wg genkey > private.key

• Wireguard-Interface erstellen

ip link add dev wg0 type wireguard

• IP-Adresse auf dem neuen Wireguard-Interface wg0 setzen

ip addr add 10.0.0.2/24 dev wg0

• Privaten Schlüssel in das wg0 Interface laden

wg set wg0 private-key ./private.key

• Interface wg0 aktivieren

ip link set wg0 up

• Konfiguration der Schnittstelle anzeigen

wg show wg0

• der Laptop ist unser VPN-Client
• Wireguard installieren. Wurde ein neuer Linux-Kernel installiert, dann nach der Installation von Wireguard den Rechner neu starten, denn die Wireguard-Kernel-Module wurden schon für die neue Kernel-Version gebaut

echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable.list
printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' > /etc/apt/preferences.d/limit-unstable
apt update
apt install wireguard

• Verzeichnis für die Wireguard-Dateien erstellen

umask 077
mkdir /etc/wireguard
cd /etc/wireguard

• einen privaten Schlüssel für den Wireguard-Dienst erstellen

wg genkey > private.key

• Wireguard-Interface erstellen

ip link add dev wg0 type wireguard

• IP-Adresse auf dem neuen Wireguard-Interface wg0 setzen

ip addr add 10.0.0.1/24 dev wg0

• Privaten Schlüssel in das wg0 Interface laden

wg set wg0 private-key ./private.key

• Interface wg0 aktivieren

ip link set wg0 up

• öffentlicher Schlüssel, erlaubte IP-Adressen und IP/Port des VPN-Servers eintragen

wg set wg0 peer <schlüssel> allowed-ips 0.0.0.0/0 endpoint <vpn-server>:<port>

• Konfiguration der Schnittstelle anzeigen

wg show wg0

• Konfiguration in die Konfigurationsdatei speichern

wg showconf wg0 > /etc/wireguard/wg0.conf
chmod 0600 /etc/wireguard/wg0.conf

• Konfigurationsdatei anpassen, Address einfügen und Abschnitt Peer

[Interface]
ListenPort = <port>
PrivateKey = <private-key>
Address = 10.0.0.1/24

[Peer]
PublicKey = <public-key-of-vpn-server>
AllowedIPs = 0.0.0.0/0
Endpoint = <ip-of-vpn-server>:<port>

• auf dem VPN-Server, die Wireguard-Configuration speichern

wg showconf wg0 > /etc/wireguard/wg0.conf
chmod 0600 /etc/wireguard/wg0.conf

• Konfigurationsdatei anpassen (Address und Abschnitt Peer)

[Interface]
ListenPort = <port>
PrivateKey = <private-key>
Address = 10.0.0.2/24

[Peer]
PublicKey = <public-key-of-client>
AllowedIPs = 10.0.0.1/32

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf

• auf dem VPN-Gateway

root@vm0X:/etc/wireguard# wg-quick down wg0
[#] ip link delete dev wg0
root@vm0X:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.0.1/32 dev wg0

• auf dem VPN-Client

root@router05:/etc/wireguard# wg-quick down wg0
[#] ip link delete dev wg0
root@router05:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0

• Ping vom VPN-Client Wireguard-IP zum VPN-Server

ping 10.0.0.2

• der DNS-Resolver des Linuxhotels ist über den Tunnel nicht erreichbar, daher müssen wir einen DNS-Resolver im Internet benuzten (oder, besser, einen eigenen DNS-Resolver auf dem VPN-Gateway-Server).

echo "nameserver 1.1.1.1" > /etc/resolv.conf

• Sichtbare IP-Adresse des Client mit und ohne Wireguard prüfen, z.B. per Firefox auf der Seite https://ripe.net
• Route zu einem Host im Internet per mtr testen, mit und ohne Wireguard
• Wireguard aktivieren, mtr auf einen Server im Internet laufen lassen. Dann von Ethernet (Kabel) auf WLAN umschalten, der mtr Trace darf nicht abbrechen, der Wireguard Tunnel überlebt das umschalten

apt install mtr
mtr -t google.com

• die folgenden Schritte sowohl auf dem VPN-Gateway, als auch auf dem Client ausführen
• manuell gestartetes Wireguard beenden

wg-quick down wg0

• Wireguard per Systemd aktivieren

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0
systemctl status wg-quick@wg0
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
   Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2019-05-06 16:18:02 EDT; 1s ago
     Docs: man:wg-quick(8)
	   man:wg(8)
	   https://www.wireguard.com/
	   https://www.wireguard.com/quickstart/
	   https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
	   https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8
  Process: 13492 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
 Main PID: 13492 (code=exited, status=0/SUCCESS)

May 06 16:18:02 router05 systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
May 06 16:18:02 router05 wg-quick[13492]: [#] ip link add wg0 type wireguard
May 06 16:18:02 router05 wg-quick[13492]: [#] wg setconf wg0 /dev/fd/63
May 06 16:18:02 router05 wg-quick[13492]: [#] ip address add 10.0.0.1/24 dev wg0
May 06 16:18:02 router05 wg-quick[13492]: [#] ip link set mtu 1420 up dev wg0
May 06 16:18:02 router05 wg-quick[13492]: [#] wg set wg0 fwmark 51820
May 06 16:18:02 router05 wg-quick[13492]: [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
May 06 16:18:02 router05 wg-quick[13492]: [#] ip -4 rule add not fwmark 51820 table 51820
May 06 16:18:02 router05 wg-quick[13492]: [#] ip -4 rule add table main suppress_prefixlength 0
May 06 16:18:02 router05 systemd[1]: Started WireGuard via wg-quick(8) for wg0.

• Alle Pakete (mit Aussnahme der Wireguard Pakete) sollen durch den VPN-Tunnel gesendet werden. Eine Split-Default-Route sorgt dafür, das wir die original Default-Route nicht verlieren

ip route add <ip-des-VPN-servers>/32 via 192.168.1.5 dev eth0
ip route add  0.0.0.0/1 via 10.0.0.2 dev wg0
ip route add  128.0.0.0/1 via 10.0.0.2 dev wg0

• Test

# tracepath google.com
 1?: [LOCALHOST]                                         pmtu 1420
 1:  10.0.0.2                                             15.453ms
 1:  10.0.0.2                                             15.446ms
 2:  no reply
 3:  45.63.118.33                                         18.164ms
 4:  no reply
 5:  ffm-b12-link.telia.net                               20.718ms
 6:  ffm-bb4-link.telia.net                               15.889ms
 7:  ffm-b1-link.telia.net                                16.062ms
 8:  google-ic-319727-ffm-b1.c.telia.net                  15.997ms asymm 10
[...]

• Routen löschen

ip r del 0.0.0.0/1 via 10.0.0.2 dev wg0
ip r del 128.0.0.0/1 via 10.0.0.2 dev wg0
ip r del <ip-des-vpn-servers> via 192.168.1.5 dev eth0

• Wireguard Interface ausschalten

ip link set dev wg0 down

• BoringTUN: Wireguard Implementation in Rust https://github.com/cloudflare/boringtun
• Route-based VPN on Linux with WireGuard https://vincent.bernat.ch/en/blog/2018-route-based-vpn-wireguard