Tips for Hardening in Debian

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
debianuser4782
Beiträge: 196
Registriert: 11.03.2018 23:09:05

Tips for Hardening in Debian

Beitrag von debianuser4782 » 16.06.2021 15:31:58

Ein Paket, welches mich wegen seiner Einfachheit, Nachvollziehbarkeit und Modifizierbarkeit, auch für IT-Laien, begeistert, ist Debianhardening-runtime, welches die Härtungs-Tips vom Kernel Self Protection Project über Konfigurationsdateien in Debian mit der Installation dieses Paketes umsetzt.

Hier die nach der Installation eingefügten Konfigurationen:

Code: Alles auswählen

# nano /etc/default/grub.d/01_hardening.cfg
Mit der Ausgabe:

Code: Alles auswählen

# Linux command line options recommended by the KSPP
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#kernel_command_line_options
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt"

# Other interesting options are:
# - intel_iommu=on (sometimes intel_iommu=on,igfx_off) for enabing I/OMMU

# When done editing the file, rebuild grub configuration with: update-grub
Und:

Code: Alles auswählen

# nano /usr/lib/sysctl.d/10-hardening.conf
Mit der Ausgabe:

Code: Alles auswählen

# sysctl recommended by the KSPP
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#sysctls

# Try to keep kernel address exposures out of various /proc files (kallsyms, modules, etc).
kernel.kptr_restrict = 1

# Avoid kernel memory address exposures via dmesg.
kernel.dmesg_restrict = 1

# Block non-uid-0 profiling (needs distro patch, otherwise this is the same as "= 2")
kernel.perf_event_paranoid = 3

# Turn off kexec, even if it's built in.
kernel.kexec_load_disabled = 1

# ptrace hardening
# 1: Avoid non-ancestor ptrace access to running processes and their credentials.
# 2: Restrict ptrace access to processes with CAP_SYS_PTRACE
# 3: Completely disable ptrace
kernel.yama.ptrace_scope = 1

# Disable User Namespaces, as it opens up a large attack surface to unprivileged users.
# On Debian kernel.unprivileged_userns_clone is set to 0 by default as well
user.max_user_namespaces = 0

# Turn off unprivileged eBPF access.
kernel.unprivileged_bpf_disabled = 1

# Turn on BPF JIT hardening, if the JIT is enabled.
net.core.bpf_jit_harden = 2

# On x86_64 this adds some bits to userspace ASLR
# vm.mmap_rnd_bits=32

# If all relevant modules have been loaded in the initramfs (by listing them in
# /etc/initramfs/modules and rebuilding the initramfs with update-initramfs,
# one can completely disable modules loading with:
# kernel.modules_disable=1
Wer ähnlich einfach umzusetztende Härtungs-Methoden kennt, kann diese hier gerne benennen.

Auf die einfach umzusetztende Methode der Code-Reduzierung sei hier ebenfalls noch einmal kurz hingewiesen:
https://wiki.debian.org/ReduceDebian
viewtopic.php?f=12&t=178677&hilit=reduce+debian

Auditprogramme, wie Debianlynis, die selbst Härtungsvorschläge machen oder Benutzerhandbücher wie https://www.debian.org/doc/manuals/secu ... ex.de.html ordne ich eher dem Fortgeschrittenenbereich zu, nicht zuletzt, weil man hier selbst selektieren muss, was man umsetzen möchte.
An lynis möchte ich zudem kritisieren, dass man in dem von diesem Programm Ausgestellten Auditergebnis, dem "score", ein besseres Ergebnis erzielen kann, indem man gemäß der dortigen Vorschläge codegewaltige Software nachinstalliert. Dies steht meiner Meinung nach im Wiederspruch zu dem oben benannten Minimalisierungsgedanken und sollte von den Entwicklern von lynis kritischer betrachtet werden.
Zuletzt geändert von debianuser4782 am 12.12.2021 15:25:48, insgesamt 2-mal geändert.

fossonly
Beiträge: 23
Registriert: 10.06.2020 10:40:38

Re: Tips for Hardening in Debian

Beitrag von fossonly » 17.06.2021 11:20:10

Im Bezug auf die Systemhärtung, hast Du einen für mich eher umständlichen Weg gewählt. Denn über die Kernel-Parameter "systemd.volatile=yes" und "lockdown={integrity|confidentiality}", lässt sich in einem Rutsch weitaus mehr in Sachen Systemhärtung ereichen. Ersteres richtet auf Basis von Systemd, ein sogenanntes "stateless" System ein, welches sowohl gegen Modifikationen immun ist, als auch jedwede Veränderungen nach einem Neustart verwirft. Und letzteres aktiviert den Kernel-Lockdown im jeweiligen Modus, womit erhebliche wie auch systemweite Restriktionen einhergehen, die unter anderem auch den Nutzer Root empfindlich einschränken.

debianuser4782
Beiträge: 196
Registriert: 11.03.2018 23:09:05

Re: Tips for Hardening in Debian

Beitrag von debianuser4782 » 17.06.2021 22:36:41

Ich würde gerne Die von Dir genannten Kernel-Boot-Parameter via grub zusammen mit den von mir bereits gesetzten Parametern verwenden. Ist das möglich?
Wenn ich die von Dir genannten Parameter setze, bleiben dann meine bereits ebenfalls hierüber getätigten Änderungen am Linux-System bestehen?
Und kann ich neue Änderungen am Linux System vornehmen, indem ich den Parameter systemd.volatile=yes und/oder lockdown={integrity|confidentiality} durch zB Entfernung deaktiviere und das System reboote oder herunterfahre und wieder neu starte und dann am System ohne diese Parameter Veränerungen vornheme?
Ich frage, da mir nicht 100%ig klar ist, ob eines dieser Parameter oder beide zusammen mir einfach nur nach jedem Neustart ein "fabrikneues Linux" - ähnlich eines statischen Live-Boot-Linux-Systems - bescheren.
Da ich bereits UEFI aktiviert habe, welches bereits eine Art Kernel-Lockdown herbeiführt, sorgt der gesetzte Parameter lockdown={integrity|confidentiality} in diesem Fall für einen hierzu ergänzenden und weitergehenden Lockdown?
Ich sehe gerade, dass letzterer Parameter erst mit Linux-Kernel 5.4 (2019) eingeführt wurde und für mich daher erst in ein paar Wochen mit Bullseye realisierbar sein würde.

Erläuterungen habe ich bisher erst zum Parameter "systemd.volatile=yes" gefunden:
systemd-volatile-root.service is a service that replaces the root directory with a volatile memory file system ("tmpfs"), mounting the original (non-volatile) /usr/ inside it read-only. This way, vendor data from /usr/ is available as usual, but all configuration data in /etc/, all state data in /var/ and all other resources stored directly under the root directory are reset on boot and lost at shutdown, enabling fully stateless systems. This service is only enabled if full volatile mode is selected, for example by specifying "systemd.volatile=yes" on the kernel command line. This service runs only in the initial RAM disk ("initrd"), before the system transitions to the host's root directory. Note that this service is not used if "systemd.volatile=state" is used, as in that mode the root directory is non-volatile.https://www.man7.org/linux/man-pages/ma ... ice.8.html

Diese Ausführung ist für mich aber etwas zu knapp, weswegen meine obigen Fragen für mich bestehen bleiben.

fossonly
Beiträge: 23
Registriert: 10.06.2020 10:40:38

Re: Tips for Hardening in Debian

Beitrag von fossonly » 18.06.2021 01:24:10

debianuser4782 hat geschrieben: ↑ zum Beitrag ↑
17.06.2021 22:36:41
Ich würde gerne Die von Dir genannten Kernel-Boot-Parameter via grub zusammen mit den von mir bereits gesetzten Parametern verwenden. Ist das möglich?
Das ist zwar möglich, jedoch weitgehend überflüssig. Denn viele Kernel-Parameter die Du bereits nutzt, werden durch die Restriktionen seitens des Kernel-Lockdown bereits angewendet, womit diese praktisch obsolet werden. Zudem kommt, dass die Linux interne Hierarchie der Sicherheitsmechanismen definiert, dass der Kernel-Lockdown praktisch allem was davon berührt wird übergeordnet ist, womit sich logischerweise alles andere unterzuordnen hat. Anderweitige Kernel-Parameter die deinerseits gesetzt werden, wären somit unwirksam wenn sie mit den Kernel-Lockdown seitigen Restriktionen in Konflikt stehen.
Wenn ich die von Dir genannten Parameter setze, bleiben dann meine bereits ebenfalls hierüber getätigten Änderungen am Linux-System bestehen?
Nun wie bereits angegeben, kommt es auf den jeweiligen Fall an. Werden keine sicherheitstechnisch relevanten Kernel-Parameter gesetzt, die ggf. durch den Kernel-Lockdown gesetzte Restriktionen herabsetzen würden, dann sollte es diesbezüglich kein Problem geben.
Und kann ich neue Änderungen am Linux System vornehmen, indem ich den Parameter systemd.volatile=yes und/oder lockdown={integrity|confidentiality} durch zB Entfernung deaktiviere und das System reboote oder herunterfahre und wieder neu starte und dann am System ohne diese Parameter Veränerungen vornheme?
Natürlich ist das möglich. Dafür müsste nur "systemd.volatile=yes" entfernt werden. Übrigens bleibt /home grundsätzlich unberührt davon.
Da ich bereits UEFI aktiviert habe, welches bereits eine Art Kernel-Lockdown herbeiführt, sorgt der gesetzte Parameter lockdown={integrity|confidentiality} in diesem Fall für einen hierzu ergänzenden und weitergehenden Lockdown?
Die reine Nutzung eines UEFI, impliziert noch keine Art von Kernel-Lockdown. Hierfür müsste schon das UEFI seitige Secure-Boot aktiviert werden, was in der Vergangenheit jedoch mit zahlreichen Sicherheitslücken behaftet war. Nichtsdestotrotz erkennt der Linux-Kernel wenn Secure-Boot aktiviert wurde, und aktiviert seinerseits automatisch den Kernel-Lockdown, um die Bootphase im Anschluss weiter abzusichern.

mcb

Re: Tips for Hardening in Debian

Beitrag von mcb » 18.06.2021 22:57:45

Mit UEFI und Secureboot hat man auch teilweise Speicherschutz am Thunderb. (je nach Hardware).

Thunderspy - When Lightning Strikes Thrice Breaking Thunderbolt 3 Security:

https://thunderspy.io/

debianuser4782
Beiträge: 196
Registriert: 11.03.2018 23:09:05

Re: Tips for Hardening in Debian

Beitrag von debianuser4782 » 12.12.2021 15:08:11

Ich habe die obigen Konfigurationsdateien um die Vorschläge auf der Internetseite https://madaidans-insecurities.github.i ... ening.html erweitert.

Die Einträge in der Datei /etc/default/grub.d/01_hardening.cfg lauten bei mir nun:

Code: Alles auswählen

# Linux command line options recommended by the KSPP 
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#kernel_command_line_options
# Modifiziert nach den Vorschlägen auf https://madaidans-insecurities.github.io/guides/linux-hardening.html zur Veröffentlichung auf https://debianforum.de/forum/     
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT kaslr pti=on slab_nomerge page_poison=1
slub_debug=FPZ nosmt init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 vsyscall=none debugfs=off
oops=panic module.sig_enforce=1 lockdown=integrity lockdown=confidentiality mce=0 quiet loglevel=0
systemd.volatile=yes ipv6.disable=1"

# Other interesting options are:
# - intel_iommu=on (sometimes intel_iommu=on,igfx_off) for enabing I/OMMU

# When done editing the file, rebuild grub configuration with: update-grub
Der Einträge in der Datei /usr/lib/sysctl.d/10-hardening.conf lauten bei mir nun:

Code: Alles auswählen

# sysctl recommended by the KSPP
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#sysctls
# Modifiziert nach den Vorschlägen auf https://madaidans-insecurities.github.io/guides/linux-hardening.html zur Veröffentlichung auf https://debianforum.de/forum/

# If all relevant modules have been loaded in the initramfs (by listing them in
# /etc/initramfs/modules and rebuilding the initramfs with update-initramfs,
# one can completely disable modules loading with:
# kernel.modules_disable=1

# KERNEL SELF-PROTECTION

# Try to keep kernel address exposures out of various /proc files (kallsyms, modules, etc).
kernel.kptr_restrict = 2

# Avoid kernel memory address exposures via dmesg.
kernel.dmesg_restrict = 1

# Despite the value of dmesg_restrict , the kernel log will still be displayed in the
# console during boot. Malware that is able to record the screen during boot may
# be able to abuse this to gain higher privileges. This option prevents those
# information leaks. This must be used in combination with certain boot
# parameters described below to be fully effective.
kernel.printk=3 3 3 3

# eBPF exposes quite large attack surface. As such, it must be restricted. These
# sysctls restrict eBPF to the CAP_BPF capability ( CAP_SYS_ADMIN on kernel
# versions prior to 5.8) and enable JIT hardening techniques, such as constant
# blinding.
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2

# This restricts loading TTY line disciplines to the CAP_SYS_MODULE capability to
# prevent unprivileged attackers from loading vulnerable line disciplines with the
# TIOCSETD ioctl which has been abused in a number of exploits before.
dev.tty.ldisc_autoload=0

# The userfaultfd() syscall is often abused to exploit use-after-free flaws. Due
# to this, this sysctl is used to restrict this syscall to the CAP_SYS_PTRACE
# capability.
vm.unprivileged_userfaultfd=0

# Turn off kexec, even if it's built in.
kernel.kexec_load_disabled = 1

# The SysRq key exposes a lot of potentially dangerous debugging functionality
# to unprivileged users. Contrary to common assumptions, SysRq is not only an
# issue for physical attacks as it can also be triggered remotely. The value of this
# sysctl makes it so that a user can only use the secure attention key which will
# be necessary for accessing root securely. Alternatively, you can simply set the
# value to 0 to disable SysRq completely.
kernel.sysrq=4

# User namespaces are a feature in the kernel which aim to improve sandboxing
# and make it easily accessible for unprivileged users however, this feature
# exposes significant kernel attack surface for privilege escalation so this sysctl
# restricts the usage of user namespaces to the CAP_SYS_ADMIN capability. For
# unprivileged sandboxing, it is instead recommended to use a setuid binary with
# little attack surface to minimise the potential for privilege escalation. This topic
# is covered further in the sandboxing section.
# Be aware though that this sysctl only exists on certain Linux distributions as it
# requires a kernel patch. If your kernel does not include this patch, you can 
# alternatively disable user namespaces completely (including for root) by setting 
# user.max_user_namespaces=0.
kernel.unprivileged_userns_clone=0
user.max_user_namespaces=0

# Block non-uid-0 profiling (needs distro patch, otherwise this is the same as "= 2")
kernel.perf_event_paranoid = 3

# NETWORK

# USER SPACE

# ptrace is a system call that allows a program to alter and inspect another
# running process which allows attackers to trivially modify the memory of other
# running programs. This restricts usage of ptrace to only processes with the
# CAP_SYS_PTRACE capability. Alternatively, set the sysctl to 3 to disable ptrace
# entirely.
# 1: Avoid non-ancestor ptrace access to running processes and their credentials.
# 2: Restrict ptrace access to processes with CAP_SYS_PTRACE
# 3: Completely disable ptrace
kernel.yama.ptrace_scope=2

# On x86_64 this adds some bits to userspace ASLR
vm.mmap_rnd_bits=32
vm.mmap_rnd_compat_bits=16

# This only permits symlinks to be followed when outside of a world-writable
# sticky directory, when the owner of the symlink and follower match, or when the
# directory owner matches the symlink's owner. This also prevents hardlinks
# from being created by users that do not have read/write access to the source
# file. Both of these prevent many common TOCTOU races.
fs.protected_symlinks=1
fs.protected_hardlinks=1

# These prevent creating files in potentially attacker-controlled environments,
# such as world-writable directories, to make data spoofing attacks more difficult.
fs.protected_fifos=2
fs.protected_regular=2
Hinsichtlich der Einträge in /etc/default/grub.d/01_hardening.cfg stellte ich fest, dass sie eventuell mit (doppelten?) Einträgen in /etc/default/grub in der Zeile GRUB_CMDLINE_LINUX_DEFAULT="" konfligieren. Einige von mir gesetzten Einträge in /etc/default/grub wurden nach Systemstart vom System plötzlich nicht mehr umgesetzt, was ich erfuhr über die Ausgabe von:

Code: Alles auswählen

nano /proc/cmdline
Ich habe mich daher - auch der Übersichtlichkeit halber - dazu entschieden, alle Kernel-Boot-Paraemter in /etc/default/grub.d/01_hardening.cfg und nicht mehr in /etc/default/grubeinzutragen.
Bei den Vorschlägen auf der obigen Internetseite zu Einträgen in /usr/lib/sysctl.d/10-hardening.conf zur Härtung der Netzwerkeinstellungen habe ich mich zurückgehalten, da ich ausschließlich über virtuelle Maschinen das Internet benutze und auf dem Host vorerst alles bei den automatischen Voreinstellungen durch Debian bzw durch die installierten Pakete für qemu/kvm belasse. Letztere Komplexitätsschicht lässt vermutlich nicht zu, die vorgeschlagenen Konfigurationseinträge einfach per Copy&Paste in die Konfigurationsdatei zu übernehmen.

@mcb
Danke für den Tip

@fossonly
Ok, ich muss dann noch herausfinden, welche Änderungen genau der durch secure boot aktivierte kernel-lockdown bzw die Einträge lockdown={integrity|confidentiality} und systemd.volatile=yes am Linux-System vornehmen.
Wie ich Dich verstanden habe, werden meine individuell und manuell gesetzten Einträge - die stringenter sein können - möglicherweise durch weniger strenge Parameter - gesetzt durch secure boot bzw. lockdown={integrity|confidentiality} und/oder systemd.volatile=yes - lediglich verdrängt (oder umgekehrt). Soweit es derart klar hierarchisch bleibt und keine schwereren Konflikte eintreten können, kann ich damit leben, bis ich mehr weiß. In allen Fällen bliebe das System nämlich gehärtet.
Zumindest was die Modifizierungen durch das Paket Debianhardening-runtime angeht, vertraue ich darauf, dass der Maintainer um diese möglichen Hierarchiekonflikte - insbesondere bei eingeschaltetem secure boot - weiß.

Benutzeravatar
OrangeJuice
Beiträge: 616
Registriert: 12.06.2017 15:12:40

Re: Tips for Hardening in Debian

Beitrag von OrangeJuice » 31.08.2022 19:01:42

Ich habe das Paket vor kurzem installiert.
In den Logs erscheint nun ein Meldung, die wahrscheinlich auf die Einschränkung von namespaces beruht. Ich hoffe es ist okay, wenn ich das hier frage.

Code: Alles auswählen

journalctl -p err..alert

systemd[1]: Failed to start Daemon for power management.
systemd[1388]: upower.service: Failed to set up user namespacing: No space left on device
systemd[1388]: upower.service: Failed at step USER spawning /usr/libexec/upowerd: No space left on device
systemd[1]: Failed to start Daemon for power management.
Kann mir jemand sagen, was die Meldung bedeutet und welche Auswirkungen upower.service auf das System hat?
Bis jetzt habe ich nichts negative bemerkt. Für alle die auch das Paket installieren, Flatpak benötig anscheinend user_namspaces.

Benutzeravatar
OrangeJuice
Beiträge: 616
Registriert: 12.06.2017 15:12:40

Re: Tips for Hardening in Debian

Beitrag von OrangeJuice » 03.09.2022 19:47:07

Es muss doch an user-namespaces oder einer anderen Einstellung liegen. Ich hoffe mal, dass es mit der nächsten Debian Version nicht mehr auftritt.

debianuser4782
Beiträge: 196
Registriert: 11.03.2018 23:09:05

Re: Tips for Hardening in Debian

Beitrag von debianuser4782 » 15.09.2022 21:42:56

OrangeJuice hat geschrieben: ↑ zum Beitrag ↑
03.09.2022 19:47:07
Es muss doch an user-namespaces oder einer anderen Einstellung liegen. Ich hoffe mal, dass es mit der nächsten Debian Version nicht mehr auftritt.
Ein Auskommentieren von user.max_user_namespaces=0 in /usr/lib/sysctl.d/10-hardening.conf sollte funktionieren.
Erklärt wird dies folgendermaßen:

upower.service uses hardening features which do require user namespaces.
So if you disable those globally, this will indeed conflict.
You have two choices here:
- Allow user name spaces
- Disable the hardening features in upower.service which require user
name spaces

https://bugs.debian.org/cgi-bin/bugrepo ... bug=940933
https://de.wikipedia.org/wiki/UPower

Bei mir besteht das Problem bei Debianhardening-runtime, dass wenn ich den obigen Parameter in meiner qemu-kvm-vm mit debian11/KDE nicht auskommentiere, dass sich KDE nicht automatisch an die Größe des VM-Fensters anpasst (Konflikt mit Debianspice-vdagent?).
Zudem öffnet sich Debiandolphin bei einmaligem Mausklick auf das Starticon zeitlich sehr stark verzögert und bei mehrmaligem Mausklick stark zeitlich verzögert.

Da DEs viele miteinander verzahnte Programme beinhalten, ist es wahrscheinlich, dass es bei hardening-runtime hier zu Konflikten kommen kann. Bei minimalistischen debian-Installationen (zB bei Servern), ohne installiertem DE, verringert sich diese Wahrscheinlichkeit jedoch bzw. die Konflikte sind überschaubarer.

Benutzeravatar
OrangeJuice
Beiträge: 616
Registriert: 12.06.2017 15:12:40

Re: Tips for Hardening in Debian

Beitrag von OrangeJuice » 18.09.2022 11:06:23

debianuser4782 hat geschrieben: ↑ zum Beitrag ↑
15.09.2022 21:42:56
Ein Auskommentieren von user.max_user_namespaces=0 in /usr/lib/sysctl.d/10-hardening.conf sollte funktionieren.
Danke, dass du dir die Mühe gemacht hast!

Ich habe mir die upower.service angesehen. Kann man alle unter namespaces auskommentieren oder sollte man es besser lassen? Damit sind doch user-namespaces gemeint oder?

Ich habe es getestet, damit läuft upower wieder ohne Fehlermeldung.

Code: Alles auswählen

cat /lib/systemd/system/upower.service
...
# Namespaces
#PrivateUsers=yes
RestrictNamespaces=yes

Antworten