githubixx.harden_linux

ansible-role-harden-linux

Diese Ansible-Rolle wurde hauptsächlich für meine Blog-Serie Kubernetes the not so hard way with Ansible - Harden the instances erstellt. Sie kann jedoch auch eigenständig verwendet werden, um Linux abzusichern. Sie bietet folgende Funktionen (einige sind optional):

Einen regulären/deploy Benutzer hinzufügen, der für die Verwaltung verwendet wird (z. B. für Ansible oder Anmeldung über SSH)
APT-Update-Intervalle anpassen
UFW-Firewall einrichten und standardmäßig nur SSH-Zugriff erlauben (Fügen Sie weitere Regeln/erlaubte Netzwerke hinzu, wenn Sie möchten)
Sicherheitseinstellungen in sysctl anpassen
sshd-Einstellungen anpassen, z. B. Passwortauthentifizierung für sshd deaktivieren, SSH-Zugriff als root deaktivieren und PermitTunnel für sshd deaktivieren
sshguard installieren und Whitelist anpassen
Root-Passwort ändern
Network Time Synchronization (NTP) installieren / konfigurieren, z. B. openntpd/ntp/systemd-timesyncd
Konfiguration von systemd-resolved ändern

Versionen

Ich versiegle jede Veröffentlichung und bemühe mich, die semantische Versionierung einzuhalten. Wenn Sie die Rolle verwenden möchten, empfehle ich, das neueste Tag zu überprüfen. Der Master-Branch ist in der Regel für die Entwicklung, während die Tags stabile Versionen kennzeichnen. Im Allgemeinen versuche ich jedoch auch, den Master-Branch gut in Schuss zu halten.

Changelog

Änderungshistorie:

Siehe das vollständige CHANGELOG.md

Aktuelle Änderungen:

v8.2.0

FEATURE
- Unterstützung für Ubuntu 24.04 hinzufügen

v8.1.0

ANDERE
- Kommentare zur Verwendung von mkpasswd statt ansible zur Erstellung des verschlüsselten Passworts aktualisieren
- Ubuntu: Autoremove-Task hinzufügen
- Github-Workflow aktualisieren
MOLECULE
- alvistack anstelle von generic Vagrant-Boxen verwenden
- Verschiedene IP-Adressen verwenden

v8.0.0

BRECHENDE/FUNKTION
- Einführung der Variablen harden_linux_deploy_group und harden_linux_deploy_group_gid. Beide sind optional. Aber mindestens harden_linux_deploy_group muss angegeben werden, wenn harden_linux_deploy_user ebenfalls gesetzt ist. Wenn harden_linux_deploy_group auf root gesetzt ist, wird nichts geändert.
- Wenn harden_linux_deploy_user auf root gesetzt ist, wird nichts geändert.
- harden_linux_deploy_user ist jetzt optional. Wenn nicht gesetzt, wird kein Benutzer eingerichtet. Alle Variablen, die mit harden_linux_deploy_user_ beginnen, werden nur verwendet, wenn harden_linux_deploy_user angegeben ist. Zusätzlich wurde die Variable harden_linux_deploy_user_home hinzugefügt. harden_linux_deploy_user_shell, harden_linux_deploy_user_home, harden_linux_deploy_user_uid und harden_linux_deploy_user_password sind jetzt optional. Das $HOME-Verzeichnis des harden_linux_deploy_user wird nur erstellt, wenn harden_linux_deploy_user_home gesetzt ist.
MOLECULE
- Test-Szenario aktualisieren, um die Änderungen an Benutzer/Gruppen anzupassen

Installation

Direkt von Github herunterladen (Wechseln Sie in das Ansible-Rollenverzeichnis, bevor Sie klonen. Sie können den Rollenpfad mit dem Befehl ansible-config dump | grep DEFAULT_ROLES_PATH ermitteln): git clone https://github.com/githubixx/ansible-role-harden-linux.git githubixx.harden_linux
Über den Befehl ansible-galaxy und direkt von Ansible Galaxy herunterladen: ansible-galaxy install role githubixx.harden_linux
Erstellen Sie eine requirements.yml-Datei mit folgendem Inhalt (dies wird die Rolle von Github herunterladen) und installieren Sie sie mit: ansible-galaxy role install -r requirements.yml (ändern Sie version, wenn nötig):

---
roles:
  - name: githubixx.harden_linux
    src: https://github.com/githubixx/ansible-role-harden-linux.git
    version: v8.1.0

Rollenvariablen

Die folgenden Variablen haben keine Standardwerte. Sie müssen sie entweder in einer Datei im Verzeichnis group_vars oder host_vars angeben. Zum Beispiel, wenn diese Einstellungen nur für einen spezifischen Host verwendet werden sollen, erstellen Sie eine Datei für diesen Host mit dem vollständigen Domänennamen (z. B. host_vars/your-server.example.tld) und fügen Sie die Variablen mit den richtigen Werten dort hinzu. Wenn Sie diese Variablen auf eine Host-Gruppe anwenden möchten, erstellen Sie eine Datei group_vars/your-group.yml, z. B. Ersetzen Sie your-group durch den Namen der Host-Gruppe, die Sie in der Ansible hosts-Datei erstellt haben (nicht zu verwechseln mit /etc/hosts...).

Wenn Sie das Passwort des root-Benutzers setzen oder ändern möchten, setzen Sie die Variable harden_linux_root_password. Dies ist optional. Es wird ein verschlüsseltes Passwort erwartet. Ansible verschlüsselt das Passwort nicht für Sie. Wie Sie ein verschlüsseltes Passwort erstellen, wird in den Ansible FAQs beschrieben. Unter Linux ist der folgende Befehl höchstwahrscheinlich der zuverlässigsten:

mkpasswd --method=sha-512

Um einen Benutzer zu installieren, der Befehle mit sudo ohne Passwort ausführen kann, setzen Sie die folgenden Variablen:

harden_linux_deploy_user: "a_username"
harden_linux_deploy_user_password: "a_password"
harden_linux_deploy_user_home: "/home/a_user"
harden_linux_deploy_user_uid: "9999"
harden_linux_deploy_user_gid: "9999"
harden_linux_deploy_user_shell: "/bin/bash"

harden_linux_deploy_user gibt den Benutzer an, den wir verwenden möchten, um sich auf dem Remote-Host anzumelden. Wie bereits erwähnt, deaktiviert die Rolle harden_linux aus gutem Grund die Anmeldung des Root-Benutzers über SSH. Daher ist ein anderer Benutzer erforderlich. Dieser Benutzer erhält "sudo"-Berechtigungen, die notwendig sind, damit Ansible (und/oder Sie selbst) seine Arbeit verrichten kann.

In harden_linux_deploy_user_password wird das verschlüsselte Passwort des Benutzers gespeichert. Dasselbe gilt für harden_linux_root_password bezüglich der Erstellung eines verschlüsselten Passworts.

Das $HOME-Verzeichnis des Benutzers wird in harden_linux_root_password festgelegt. Für UID und GID setzen Sie harden_linux_deploy_user_uid und harden_linux_deploy_user_gid. Hinweis: Wenn der Benutzer bereits existiert, aber ein anderes Home-Verzeichnis, UID und/oder GID hat, wird dies gemäß den obigen Einstellungen geändert! Dies gilt auch für harden_linux_deploy_user_shell, die die Shell angibt, die der Benutzer nach der Anmeldung verwenden sollte, z. B.

harden_linux_deploy_user_public_keys gibt eine Liste von öffentlichen SSH-Schlüsseldateien an, die Sie zum $HOME/.ssh/authorized_keys des Deploy-Benutzers auf dem Remote-Host hinzufügen möchten. Wenn Sie z. B. /home/deploy/.ssh/id_rsa.pub als Wert angeben, wird der Inhalt dieser lokalen Datei (die sich auf dem Ansible-Controller-Knoten befindet) zum $HOME/.ssh/authorized_keys des Deploy-Benutzers auf dem Remote-Host hinzugefügt.

harden_linux_optional_packages (vor Version v6.0.0 dieser Rolle hieß diese Variable harden_linux_required_packages) gibt zusätzliche/optionale Pakete an, die auf dem Remote-Host installiert werden sollen. Standardmäßig wird diese Variable nicht spezifiziert. Zum Beispiel:

harden_linux_optional_packages:
  - vim

Im Gegensatz zur vorherigen Variable wird harden_linux_absent_packages OS-Pakete auf dem Remote-Host deinstallieren. Standardmäßig wird diese Variable nicht spezifiziert. Zum Beispiel:

harden_linux_absent_packages:
  - vim

Die folgenden Variablen haben Standardwerte. Sie müssen diese nur ändern, wenn Sie einen anderen Wert für die Variable benötigen. Die Rolle ändert einige sshd-Einstellungen standardmäßig:

harden_linux_sshd_settings:
  "^PasswordAuthentication": "PasswordAuthentication no"  # Passwort-Authentifizierung deaktivieren
  "^PermitRootLogin": "PermitRootLogin no"                # SSH-Root-Anmeldung deaktivieren
  "^PermitTunnel": "PermitTunnel no"                      # Tunneling deaktivieren
  "^Port ": "Port 22"                                     # SSH-Port setzen

Persönlich ändere ich immer den Standard-SSH-Port, da viele Brute-Force-Angriffe gegen diesen Port stattfinden (aber natürlich kann ein Port-Scanner dies auch schnell feststellen). Wenn Sie die Port-Einstellung ändern möchten, können Sie dies tun, z. B.:

harden_linux_sshd_settings_user:
  "^Port ": "Port 22222"

(Bitte beachten Sie das Leerzeichen nach ^Port!). Das Playbook kombiniert die harden_linux_sshd_settings und harden_linux_sshd_settings_user, wobei die Einstellungen in harden_linux_sshd_settings_user Vorrang haben und die ^Port-Einstellung in harden_linux_sshd_settings überschreiben. Wie Sie vielleicht bemerkt haben, beginnen alle Schlüssel in harden_linux_sshd_settings und harden_linux_sshd_settings_user mit ^. Das liegt daran, dass es sich um einen regulären Ausdruck (regex) handelt. Eine der Playbook-Aufgaben sucht nach einer Zeile in /etc/ssh/sshd_config, z. B. ^Port (wobei ^ bedeutet "eine Zeile, die mit ... beginnt") und ersetzt die Zeile (wenn gefunden) durch z. B. Port 22222. So macht das Playbook sehr flexibel bei der Anpassung der Einstellungen in sshd_config (Sie können letztendlich jede Einstellung ersetzen). Sie werden dieses Muster auch bei anderen Aufgaben sehen. Daher gilt alles hier Genannte auch für solche Fälle.

Als Nächstes einige Standardeinstellungen für Firewall/iptables. Firewall/iptables-Regeln und -Einstellungen werden von UFW verwaltet:

harden_linux_ufw_defaults:
  "^IPV6": 'IPV6=yes'
  "^DEFAULT_INPUT_POLICY": 'DEFAULT_INPUT_POLICY="DROP"'
  "^DEFAULT_OUTPUT_POLICY": 'DEFAULT_OUTPUT_POLICY="ACCEPT"'
  "^DEFAULT_FORWARD_POLICY": 'DEFAULT_FORWARD_POLICY="DROP"'
  "^DEFAULT_APPLICATION_POLICY": 'DEFAULT_APPLICATION_POLICY="SKIP"'
  "^MANAGE_BUILTINS": 'MANAGE_BUILTINS=no'
  "^IPT_SYSCTL": 'IPT_SYSCTL=/etc/ufw/sysctl.conf'
  "^IPT_MODULES": 'IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_netbios_ns"'

Diese Einstellungen ändern im Wesentlichen die Werte in /etc/defaults/ufw. Um eine oder mehrere Standardeinstellungen zu überschreiben, können Sie dies tun, indem Sie denselben Schlüssel (der ein Regex ist) wie oben angeben, z. B. ^DEFAULT_FORWARD_POLICY und ihm einfach den neuen Wert zuweisen:

harden_linux_ufw_defaults_user:
  "^DEFAULT_FORWARD_POLICY": 'DEFAULT_FORWARD_POLICY="ACCEPT"'

Wie bereits erwähnt, wird dieses Playbook auch harden_linux_ufw_defaults und harden_linux_ufw_defaults_user kombinieren, wobei die Einstellungen in harden_linux_ufw_defaults_user Vorrang haben.

Als Nächstes können wir einige Firewall-Regeln mit harden_linux_ufw_rules angeben. Standardmäßig erlaubt es den SSH-Verkehr über Port 22, der das Protokoll tcp verwendet:

harden_linux_ufw_rules:
  - rule: "allow"
    to_port: "22"
    protocol: "tcp"

Die folgenden Parameter sind mit Standardwerten verfügbar (falls vorhanden):

rule (kein Standard)
interface (Standard '')
direction (Standard 'in')
from_ip (Standard 'any')
to_ip (Standard 'any')
from_port (Standard '')
to_port (Standard '')
protocol (Standard 'any')
log (Standard 'false')
delete (Standard 'false')

Eine Regel kann die Werte allow, deny, limit und reject haben. interface gibt das Interface für die Regel an. Die direction (in oder out), die für das interface verwendet wird, hängt vom Wert der Richtung ab. from_ip gibt die Quell-IP-Adresse an und from_port den Quellport. to_ip gibt die Ziel-IP-Adresse an und to_port den Zielport. protocol ist standardmäßig any. Mögliche Werte sind tcp, udp, ipv6, esp, ah, gre und igmp. log kann entweder false (Standard) oder true sein und gibt an, ob neue Verbindungen, die dieser Regel entsprechen, protokolliert werden sollen. delete gibt an, ob eine Regel gelöscht werden soll. Dies ist wichtig, wenn eine zuvor hinzugefügte Regel entfernt werden soll. Es reicht nicht aus, nur eine Regel aus harden_linux_ufw_rules zu entfernen! Sie müssen delete verwenden, um diese Regel zu löschen.

Sie können auch Hosts erlauben, in bestimmten Netzwerken zu kommunizieren (ohne Portbeschränkungen), z. B.:

harden_linux_ufw_allow_networks:
  - "10.3.0.0/24"
  - "10.200.0.0/16"

Als Nächstes ändert die harden_linux-Rolle auch einige Systemvariablen (sysctl.conf / proc-Dateisystem). Diese Einstellungen sind Empfehlungen von Google, die sie für ihre Google-Compute-Cloud-Betriebssystem-Images nutzen (siehe Google Cloud - Anforderungen zum Erstellen benutzerdefinierter Images und Importierte Images für Compute Engine konfigurieren). Dies sind die Standardeinstellungen (wenn Sie mit diesen Einstellungen zufrieden sind, müssen Sie nichts tun, ich empfehle jedoch, zu überprüfen, ob sie für Ihr Setup funktionieren):

harden_linux_sysctl_settings:
  "net.ipv4.tcp_syncookies": 1                    # Syn Flood-Schutz aktivieren
  "net.ipv4.conf.all.accept_source_route": 0      # Quellgeroutete Pakete ignorieren
  "net.ipv6.conf.all.accept_source_route": 0      # IPv6 - ICMP-Weiterleitungen ignorieren
  "net.ipv4.conf.default.accept_source_route": 0  # Quellgeroutete Pakete ignorieren
  "net.ipv6.conf.default.accept_source_route": 0  # IPv6 - Quellgeroutete Pakete ignorieren
  "net.ipv4.conf.all.accept_redirects": 0         # ICMP-Weiterleitungen ignorieren
  "net.ipv6.conf.all.accept_redirects": 0         # IPv6 - ICMP-Weiterleitungen ignorieren
  "net.ipv4.conf.default.accept_redirects": 0     # ICMP-Weiterleitungen ignorieren
  "net.ipv6.conf.default.accept_redirects": 0     # IPv6 - ICMP-Weiterleitungen ignorieren
  "net.ipv4.conf.all.secure_redirects": 1         # ICMP-Weiterleitungen von nicht als Gateway festgelegten Hosts ignorieren
  "net.ipv4.conf.default.secure_redirects": 1     # ICMP-Weiterleitungen von nicht als Gateway festgelegten Hosts ignorieren
  "net.ipv4.ip_forward": 0                        # Erlauben Sie keinen Verkehr zwischen Netzwerken oder fungieren Sie als Router
  "net.ipv6.conf.all.forwarding": 0               # IPv6 - Erlauben Sie keinen Verkehr zwischen Netzwerken oder fungieren Sie als Router
  "net.ipv4.conf.all.send_redirects": 0           # Erlauben Sie keinen Verkehr zwischen Netzwerken oder fungieren Sie als Router
  "net.ipv4.conf.default.send_redirects": 0       # Erlauben Sie keinen Verkehr zwischen Netzwerken oder fungieren Sie als Router
  "net.ipv4.conf.all.rp_filter": 1                # Reverse-Pfadfilterung - Schutz vor IP-Spoofing
  "net.ipv4.conf.default.rp_filter": 1            # Reverse-Pfadfilterung - Schutz vor IP-Spoofing
  "net.ipv4.icmp_echo_ignore_broadcasts": 1       # ICMP-Broadcasts ignorieren, um an Smurf-Angriffen nicht teilzunehmen
  "net.ipv4.icmp_ignore_bogus_error_responses": 1 # Schlechte ICMP-Fehlermeldungen ignorieren
  "net.ipv4.icmp_echo_ignore_all": 0              # Schlechte ICMP-Fehlermeldungen ignorieren
  "net.ipv4.conf.all.log_martians": 1             # Spoofed, quellenbasiert und umgeleitete Pakete protokollieren
  "net.ipv4.conf.default.log_martians": 1         # Spoofed, quellenbasiert und umgeleitete Pakete protokollieren
  "net.ipv4.tcp_rfc1337": 1                       # RFC 1337 Fix implementieren
  "kernel.randomize_va_space": 2                  # Adressen von mmap-Basis, Heap, Stack und VDSO-Seite randomisieren
  "fs.protected_hardlinks": 1                     # Schutz vor ToCToU-Rennen bieten
  "fs.protected_symlinks": 1                      # Schutz vor ToCToU-Rennen bieten
  "kernel.kptr_restrict": 1                       # Lokalisierung von Kernel-Adressen erschweren
  "kernel.perf_event_paranoid": 2                 # Perf nur root verfügbar machen

Sie können jede einzelne Einstellung überschreiben, z. B. indem Sie eine Variable namens harden_linux_sysctl_settings_user erstellen:

harden_linux_sysctl_settings_user:
  "net.ipv4.ip_forward": 1
  "net.ipv6.conf.default.forwarding": 1
  "net.ipv6.conf.all.forwarding": 1

Eine der Aufgaben im Playbook kombiniert harden_linux_sysctl_settings und harden_linux_sysctl_settings_user, wobei erneut die Einstellungen von harden_linux_sysctl_settings_user Vorrang haben. Weitere Informationen zu den Einstellungen finden Sie in der Datei defaults/main.yml der Rolle.

Wenn Sie das UFW-Logging aktivieren möchten, setzen Sie:

harden_linux_ufw_logging: 'on'

Mögliche Werte sind on, off, low, medium, high und full.

Als Nächstes kommen die "sshguard"-Einstellungen. "sshguard" schützt vor Brute-Force-Angriffen auf SSH. Um sich nicht für eine Weile selbst auszusperren, können Sie IPs oder IP-Bereiche zur Whitelist hinzufügen. Standardmäßig ist dies im Grunde nur "localhost":

harden_linux_sshguard_whitelist:
  - "127.0.0.0/8"
  - "::1/128"

Auch NTP-Pakete können installiert und konfiguriert werden. Dies ist optional. Standardmäßig empfehle ich, systemd-timesyncd zu verwenden. Sie können auch das NTP-Paket verwenden. Aber openntpd und systemd-timesyncd haben den Vorteil, dass sie standardmäßig an keinem Port lauschen. Wenn Sie nur die Uhr Ihres Hosts synchron halten möchten, ist dies absolut ausreichend. Die gleichzeitige Zeit auf all Ihren Hosts ist für einige Dienste entscheidend, z. B. für die Zertifikatsvalidierung, für etcd, Datenbanken, Kryptografie usw.

Gültige Optionen für harden_linux_ntp sind:

openntpd
ntp
systemd-timesyncd

openntpd und systemd-timesyncd haben den Vorteil, dass sie, wie bereits erwähnt, standardmäßig an keinem Port lauschen. Wenn Sie nur die Uhr Ihrer Hosts synchron halten möchten, sollte einer dieser beiden die Aufgabe erledigen. systemd-timesyncd ist bereits installiert, wenn eine Distribution systemd verwendet (was im Grunde für die meisten Linux-Distributionen heutzutage zutrifft). In diesem Fall sind keine zusätzlichen Pakete erforderlich. Um openntpd zu aktivieren, setzen Sie harden_linux_ntp entsprechend, z. B.:

harden_linux_ntp: "openntpd"

Einstellungen für openntpd, ntpd oder systemd-timesyncd (siehe nächster Absatz). Für weitere Optionen siehe die Man-Seite: man 5 ntpd.conf für ntp und openntpd sowie man 5 timesyncd.conf für systemd-timesyncd.

Der "Schlüssel" hier ist ein regulärer Ausdruck einer Einstellung, die Sie ersetzen möchten, und der Wert ist der Einstellungsname + der Einstellungswert. Beispielsweise möchten wir die Zeile servers 0.debian.pool.ntp.org durch servers 1.debian.pool.ntp.org ersetzen. Der Regex (der Schlüssel) wäre ^servers 0, was bedeutet:

"Suchen Sie nach einer Zeile in der Konfigurationsdatei, die mit server 0 beginnt, und ersetzen Sie die gesamte Zeile durch servers 1.debian.pool.ntp.org." Auf diese Weise kann jede Einstellung in der Konfigurationsdatei durch etwas anderes ersetzt werden. Einige Beispiele:

harden_linux_ntp_settings:
  "^servers 0": "servers 0.debian.pool.ntp.org"
  "^servers 1": "servers 1.debian.pool.ntp.org"
  "^servers 2": "servers 2.debian.pool.ntp.org"
  "^servers 3": "servers 3.debian.pool.ntp.org"

Bitte beachten Sie: systemd-timesyncd kommt mit angemessenen Standardwerten zur Kompilierzeit. Daher besteht normalerweise keine Notwendigkeit, die Konfiguration zu ändern (nicht einmal die NTP-Server). Die folgenden sind also nur Beispiele, aber Sie müssen harden_linux_ntp_settings für systemd-timesyncd nicht wirklich angeben.

Für systemd-timesyncd sieht die Konfigurationsdatei etwas anders aus. In diesem Fall wird eine systemd-Drop-in-Konfiguration für /etc/systemd/timesyncd.conf unter /etc/systemd/timesyncd.conf.d/ erstellt.

Beispiel für Debian:

harden_linux_ntp_settings:
  "^#NTP=": "NTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org"

Für Ubuntu:

harden_linux_ntp_settings:
  "^#NTP=": "NTP=ntp.ubuntu.com"

Für Archlinux:

harden_linux_ntp_settings:
  "^#NTP=": "NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org"

Mit harden_linux_files_to_delete kann eine Liste von Dateien angegeben werden, die auf dem Zielhost fehlen sollen, z. B.:

harden_linux_files_to_delete:
  - "/root/.pw"

Wenn systemd-resolved für die DNS- Auflösung verwendet wird, kann sein Verhalten mit harden_linux_systemd_resolved_settings angepasst werden. Standardmäßig wird diese Variable nicht festgelegt. Eine systemd-Drop-in-Konfiguration wird in /etc/systemd/resolved.conf.d/99-override.conf erstellt, und die angegebenen Einstellungen werden dort hinzugefügt.

Hinweis: Wenn eine Einstellung in /etc/systemd/resolved.conf bereits festgelegt ist (z. B. DNS=8.8.8.8), wird das Setzen von DNS=9.9.9.9 unten addiert. Das bedeutet, die endgültige Einstellung wird DNS=8.8.8.8 9.9.9.9 sein. Wenn Sie das nicht möchten, müssen Sie den Wert zuerst "unset" und dann den gewünschten Wert hinzufügen. Zum Beispiel:

harden_linux_systemd_resolved_settings:
  - DNS=
  - DNS=9.9.9.9

Während der Google-DNS-Server (8.8.8.8, 8.8.4.4) schnelle DNS-Suchvorgänge bietet, ist es natürlich eine andere Möglichkeit, dass Google Sie ausspionieren kann. Daher sollte die Verwendung anderer DNS-Server zumindest einen Gedanken wert sein. Aber es gibt noch einen weiteren Punkt, und das ist die Verschlüsselung von DNS-Anfragen. Eine Möglichkeit, die systemd-resolved unterstützt, ist DNSOverTLS. Quad9 (9.9.9.9/149.112.112.112) und Cloudflare (1.1.1.1/1.0.0.1) unterstützen DNSOverTLS.
Die folgenden systemd-resolved-Einstellungen konfigurieren Quad9 und Cloudflare-DNS für IPv4 und IPv6. Die Einstellung DNSOverTLS=opportunistic verwendet DNSOverTLS, wenn der DNS-Server dies unterstützt, und fällt auf reguläres unverschlüsseltes DNS zurück, wenn dies nicht unterstützt wird (siehe auch resolved.conf.5):

harden_linux_systemd_resolved_settings:
  - DNS=
  - DNS=9.9.9.9 1.1.1.1 2606:4700:4700::1111 2620:fe::fe
  - FallbackDNS=
  - FallbackDNS=149.112.112.112 1.0.0.1 2620:fe::9 2606:4700:4700::1001
  - DNSOverTLS=
  - DNSOverTLS=opportunistic

Außerdem kann das Cachverhalten des Paketmanagers beeinflusst werden. Zum Beispiel für Ubuntu:

# Auf "false" setzen, wenn der Paketcache nicht aktualisiert werden soll
harden_linux_ubuntu_update_cache: true

# Gültige Zeit des Paketcaches festlegen
harden_linux_ubuntu_cache_valid_time: 3600

Für Archlinux:

# Auf "false" setzen, wenn der Paketcache nicht aktualisiert werden soll
harden_linux_archlinux_update_cache: true

Beispiel Playbook

Wenn Sie die Rolle über ansible-galaxy install githubixx.harden_linux installiert haben, dann binden Sie die Rolle in Ihr Playbook wie in diesem Beispiel ein:

- hosts: webservers
  roles:
    - githubixx.harden_linux

Testen

Diese Rolle hat ein kleines Test-Setup, das mit Molecule, libvirt (vagrant-libvirt) und QEMU/KVM erstellt wird. Bitte lesen Sie meinen Blog-Beitrag Testing Ansible roles with Molecule, libvirt (vagrant-libvirt) and QEMU/KVM, um zu erfahren, wie Sie es einrichten. Die Testkonfiguration finden Sie hier.

Anschließend kann Molecule ausgeführt werden:

molecule converge

Dies richtet mehrere virtuelle Maschinen (VM) mit verschiedenen unterstützten Linux-Betriebssystemen ein und konfiguriert die Rolle harden_linux entsprechend. Ein kleiner Verifizierungsschritt ist ebenfalls enthalten: