Zum Inhalt springen

Hardening/Linux: Unterschied zwischen den Versionen

Aus Foxwiki
Die Seite wurde neu angelegt: „== Debian 12 : System Härten - Allgemein == Geschrieben von Christopher Pope am Samstag, 26. August 2023 Einige der folgenden Einstellungen sind auch bereits in der Default Einstellung so. Da ich aber ein Set von Parametern für all meine Linux Systeme verwende setze ich diese nochmal explizit in einer config. Erstmal legen wir uns ein Backup der Default Config an {| class="wikitable" |1 |<code>sudo</code> <code>sysctl -a > /tmp/default_sysctl.txt</code>…“
 
DanielZorin (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
 
(31 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
== Debian 12 : System Härten - Allgemein ==
'''Hardening/Linux'''
Geschrieben von Christopher Pope am Samstag, 26. August 2023
Einige der folgenden Einstellungen sind auch bereits in der Default Einstellung so. Da ich aber ein Set von Parametern für all meine Linux Systeme verwende setze ich diese nochmal explizit in einer config. Erstmal legen wir uns ein Backup der Default Config an
{| class="wikitable"
|1
|<code>sudo</code> <code>sysctl -a > /tmp/default_sysctl.txt</code>
|}
dann legen wir die Datei /etc/sysctl.d/97_hard.conf an und kopieren folgende Zeilen rein.
Die Erklärung zu den jeweiligen Konfiguration kann unter dem Link in der Quellenangabe nachgelesen werden.


Auch hier gilt wieder die Einstellungen müssen zu der eingesetzten Software kompatible sein.
== [[Hardening/Linux/Kernel|Kernel-Hardening]] ==
{| class="wikitable"
|1


2
== Mount-Optionen ==
Härtung auf Dateisystemebene reduziert die Auswirkungen lokaler Angriffe und Fehlkonfigurationen.


3
* Separate Partitionen für Daten- und Systembereiche (z.B. ''/home'', ''/var'', ''/tmp'') vorsehen, sofern möglich
* Mount-Optionen wie ''nodev'', ''nosuid'' und ''noexec'' für geeignete Dateisysteme verwenden, um die Ausführung oder Nutzung bestimmter Objekttypen zu unterbinden
* Kritische Systempfade möglichst restriktiv einhängen (z.B. nur lesbar, sofern der Betriebsfall dies zulässt)


4
== [[Hardening/Linux/SSH|SSH-Hardening]] ==
[[SSH]] ist typischer Einstiegspunkt für Angriffe und sollte besonders restriktiv konfiguriert werden.


5
* Schlüsselbasierte Authentifizierung bevorzugen und Passwörter, wo möglich, deaktivieren
* Root-Login einschränken oder deaktivieren und administrative Zugriffe über dedizierte Benutzerkonten mit ''sudo'' abbilden
* Protokollversion, Kryptosuiten und erlaubte Authentifizierungsverfahren anhand aktueller Sicherheitsrichtlinien auswählen


6
== Firewall ==
Eine hostbasierte [[Firewall]] begrenzt eingehenden und ausgehenden Verkehr auf das notwendige Minimum.


7
* Default-Deny-Policy für eingehenden Verkehr, explizite Freigabe nur benötigter Ports und Protokolle
* Trennung von Verwaltungs-, Anwendungs- und Datenverkehr durch Zonen oder separate Regeln
* Regelwerk regelmäßig prüfen und an Änderungen der Dienste oder Topologie anpassen


8
== Mandatory Access Control (MAC) ==
MAC-Systeme ergänzen klassische Berechtigungen um kontextabhängige Richtlinien.


9
* Einsatz von [[AppArmor]], SELinux oder vergleichbaren Mechanismen zur Einschränkung von Prozessen auf das notwendige Minimum
* Profile für kritische Dienste definieren, testen und kontinuierlich pflegen
* Alarmierung und Logging von Policy-Verletzungen zur Erkennung fehlerhafter Konfigurationen nutzen


10
== Audit und Logging ==
Strukturiertes Logging unterstützt Erkennung, Analyse und Nachweis sicherheitsrelevanter Ereignisse.


11
* Zentrale Sammlung von System- und Anwendungslogs (z.B. [[Systemd/Journald|journald]], klassische Logfiles, Audit-Subsystem)
* Klare Aufbewahrungs- und Rotationsrichtlinien für Logs definieren
* Regelmäßige Auswertung und Korrelation von Meldungen (z.B. Anmeldefehler, Policy-Verstöße, Dienstabstürze)


12
== Rechtemanagement ==
Sauberes Identitäts- und Rechtemanagement reduziert das Risiko von Fehlbedienung und Missbrauch.


13
* Minimalprinzip für Berechtigungen umsetzen (Least Privilege)
* Trennung von administrativen und nichtadministrativen Konten
* Gruppenstrukturen und [[sudo]]-Regeln so gestalten, dass nachvollziehbare Verantwortlichkeiten entstehen


14
== Dienste ==
Jeder aktive Dienst erweitert die Angriffsfläche des Systems.


15
* Nicht benötigte Pakete, Dienste und Timer entfernen oder deaktivieren
* Nur notwendige Netzwerk-Listener bereitstellen; interne Dienste möglichst auf lokale Schnittstellen binden
* Standardkonfigurationen von Diensten prüfen und sicherheitsrelevante Parameter (z.B. TLS, Authentifizierung, Zugriffskontrolle) anpassen


16
== Physischer Zugriff ==
Physischer Zugriff ermöglicht oft das Umgehen logischer Schutzmechanismen.


17
* Einsatz von Datenträgerverschlüsselung für sensible Systeme und Datenbestände prüfen
|<code>kernel.kptr_restrict = 2</code>
* Bootloader-Konfiguration und Start von alternativen Medien kontrollieren
* Firmware-/UEFI-Einstellungen absichern und, wo sinnvoll, mit Passwörtern schützen


<code>kernel.dmesg_restrict = 1</code>
== Anwendungen und Container ==
Applikationen und Container sollten nicht nur funktional, sondern auch sicher integriert werden.


<code>kernel.unprivileged_bpf_disabled=1</code>
* Standardkonfigurationen von Anwendungen prüfen und auf minimale benötigte Funktionen reduzieren
* Container-Runtimes mit restriktiven Profilen (z.B. Namespaces, ''seccomp'', Capability-Reduktion) betreiben
* Abhängigkeiten und Images regelmäßig aktualisieren und auf bekannte Schwachstellen prüfen
* Zur Erhöhung der Sicherheit auf dem [[Docker]]-Host kann [[userns-remap]] eingesetzt werden


<code>net.core.bpf_jit_harden=2</code>
<noinclude>


<code>dev.tty.ldisc_autoload=0</code>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
=== Links ===
==== Weblinks ====
# https://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers
# https://www.kernel.org/doc/html/latest/admin-guide/sysctl/
# https://www.fb-pro.com/linux-haerten/
# https://www.kuketz-blog.de/linux-systemhaertung-basis-linux-haerten-teil2/
# https://netwrix.com/de/resources/guides/linux-hardening-security-best-practices


<code>vm.unprivileged_userfaultfd=0</code>
[[Kategorie:Debian]]
[[Kategorie:Hardening]]
[[Kategorie:Linux/Sicherheit]]


<code>kernel.kexec_load_disabled = 1</code>


<code>kernel.sysrq=4</code>
</noinclude>
 
<code>kernel.unprivileged_userns_clone=0</code>
 
<code>kernel.perf_event_paranoid = 3</code>
 
<code>kernel.yama.ptrace_scope=2</code>
 
<code>vm.mmap_rnd_bits=32</code>
 
<code>vm.mmap_rnd_compat_bits=16</code>
 
<code>fs.protected_symlinks=1</code>
 
<code>fs.protected_hardlinks=1</code>
 
<code>fs.protected_fifos=2</code>
 
<code>fs.protected_regular=2</code>
|}
Nach einem Neustart werden die Kernelparameter aktiv, wer nicht solange warten möchte kann diese mit
{| class="wikitable"
|1
|<code>service procps force-reload</code>
|}
sofort einlesen.
Quelle :
<nowiki>https://www.kernel.org/doc/html/latest/admin-guide/sysctl/</nowiki>
Kategorien: Client, Linux, Server
 
Tags für diesen Artikel: client, kernel, linux, parameter, security, server
 
Artikel mit ähnlichen Themen:
 
* xz-utils supply-chain attack : Scan nach Versionen
* Proxmox 8 : Clusternode hat graues Ausrufezeichen
* Debian 12 : ssh absichern mit port knocking
* Überprüfen von EoL (End of Life) Software
* Debian 12 : System Härten - Netzwerk

Aktuelle Version vom 17. Dezember 2025, 15:32 Uhr

Hardening/Linux

Kernel-Hardening

Mount-Optionen

Härtung auf Dateisystemebene reduziert die Auswirkungen lokaler Angriffe und Fehlkonfigurationen.

  • Separate Partitionen für Daten- und Systembereiche (z.B. /home, /var, /tmp) vorsehen, sofern möglich
  • Mount-Optionen wie nodev, nosuid und noexec für geeignete Dateisysteme verwenden, um die Ausführung oder Nutzung bestimmter Objekttypen zu unterbinden
  • Kritische Systempfade möglichst restriktiv einhängen (z.B. nur lesbar, sofern der Betriebsfall dies zulässt)

SSH-Hardening

SSH ist typischer Einstiegspunkt für Angriffe und sollte besonders restriktiv konfiguriert werden.

  • Schlüsselbasierte Authentifizierung bevorzugen und Passwörter, wo möglich, deaktivieren
  • Root-Login einschränken oder deaktivieren und administrative Zugriffe über dedizierte Benutzerkonten mit sudo abbilden
  • Protokollversion, Kryptosuiten und erlaubte Authentifizierungsverfahren anhand aktueller Sicherheitsrichtlinien auswählen

Firewall

Eine hostbasierte Firewall begrenzt eingehenden und ausgehenden Verkehr auf das notwendige Minimum.

  • Default-Deny-Policy für eingehenden Verkehr, explizite Freigabe nur benötigter Ports und Protokolle
  • Trennung von Verwaltungs-, Anwendungs- und Datenverkehr durch Zonen oder separate Regeln
  • Regelwerk regelmäßig prüfen und an Änderungen der Dienste oder Topologie anpassen

Mandatory Access Control (MAC)

MAC-Systeme ergänzen klassische Berechtigungen um kontextabhängige Richtlinien.

  • Einsatz von AppArmor, SELinux oder vergleichbaren Mechanismen zur Einschränkung von Prozessen auf das notwendige Minimum
  • Profile für kritische Dienste definieren, testen und kontinuierlich pflegen
  • Alarmierung und Logging von Policy-Verletzungen zur Erkennung fehlerhafter Konfigurationen nutzen

Audit und Logging

Strukturiertes Logging unterstützt Erkennung, Analyse und Nachweis sicherheitsrelevanter Ereignisse.

  • Zentrale Sammlung von System- und Anwendungslogs (z.B. journald, klassische Logfiles, Audit-Subsystem)
  • Klare Aufbewahrungs- und Rotationsrichtlinien für Logs definieren
  • Regelmäßige Auswertung und Korrelation von Meldungen (z.B. Anmeldefehler, Policy-Verstöße, Dienstabstürze)

Rechtemanagement

Sauberes Identitäts- und Rechtemanagement reduziert das Risiko von Fehlbedienung und Missbrauch.

  • Minimalprinzip für Berechtigungen umsetzen (Least Privilege)
  • Trennung von administrativen und nichtadministrativen Konten
  • Gruppenstrukturen und sudo-Regeln so gestalten, dass nachvollziehbare Verantwortlichkeiten entstehen

Dienste

Jeder aktive Dienst erweitert die Angriffsfläche des Systems.

  • Nicht benötigte Pakete, Dienste und Timer entfernen oder deaktivieren
  • Nur notwendige Netzwerk-Listener bereitstellen; interne Dienste möglichst auf lokale Schnittstellen binden
  • Standardkonfigurationen von Diensten prüfen und sicherheitsrelevante Parameter (z.B. TLS, Authentifizierung, Zugriffskontrolle) anpassen

Physischer Zugriff

Physischer Zugriff ermöglicht oft das Umgehen logischer Schutzmechanismen.

  • Einsatz von Datenträgerverschlüsselung für sensible Systeme und Datenbestände prüfen
  • Bootloader-Konfiguration und Start von alternativen Medien kontrollieren
  • Firmware-/UEFI-Einstellungen absichern und, wo sinnvoll, mit Passwörtern schützen

Anwendungen und Container

Applikationen und Container sollten nicht nur funktional, sondern auch sicher integriert werden.

  • Standardkonfigurationen von Anwendungen prüfen und auf minimale benötigte Funktionen reduzieren
  • Container-Runtimes mit restriktiven Profilen (z.B. Namespaces, seccomp, Capability-Reduktion) betreiben
  • Abhängigkeiten und Images regelmäßig aktualisieren und auf bekannte Schwachstellen prüfen
  • Zur Erhöhung der Sicherheit auf dem Docker-Host kann userns-remap eingesetzt werden


Anhang

Siehe auch

Links

Weblinks

  1. https://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers
  2. https://www.kernel.org/doc/html/latest/admin-guide/sysctl/
  3. https://www.fb-pro.com/linux-haerten/
  4. https://www.kuketz-blog.de/linux-systemhaertung-basis-linux-haerten-teil2/
  5. https://netwrix.com/de/resources/guides/linux-hardening-security-best-practices