There’s nothing here we don’t already do or would require a custom kernel.
Also, Copperhead is not a good source anymore after they kicked out Daniel Micay and started scamming users.
I didn’t follow these developments. However, possibly these these
websites are still the same as created by Daniel Micay and never updated
since. Also, we’d use them as as inspiration (like from any source
anyway), and then independently verify all claims (before we make
changes on our side) not for face value.
I just wanted to point out in folder /etc/default/grub.d/40_kernel_hardening.cfg, there is this entry: “slab_debug=FZP”
Should it be “slub_debug=FZP” instead?
Sure thing! I have many same harden features on my host and see (on host) that the slab_nomerge setting is used together with slub_debug=FZP (and also page_poison=1)
I found an excellent write-up on Tails site in this documentation section
This guide has some interesting stuff although I’m not sure I’d trust someone to give an informed opinion on security when they’re using leetspeak and saying stuff like “S0rry. I barely use SELinux for reasons. The 1st one is I don’t trust NSA”.
There is some interesting anti-DDoS sysctl settings though which may be helpful.
Some of those sysctl settings are useful; I know Whonix has a lot of them by default. Also, Whonix’s iptables rules are great for stopping some attacks the author mentions without having to mess with memory page size and other performance-related setting
I lol’d at his h4ck0rz stuff to
cat /etc/default/grub.d/01_hardening.cfg
# 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
cat /usr/lib/sysctl.d/10-hardening.conf
# 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
No, it’s just stuff we’ve already enabled or unneeded things. Some of these options are defaults so I don’t know why they’re in this package.
kaslr
KASLR is enabled by default in Debian and most other distros.
kernel.perf_event_paranoid = 3
This is a default in Debian and requires a kernel patch so we can’t set it in security-misc for other distros since they might not have the patch.
user.max_user_namespaces = 0
Disabling user namespaces entirely will break many sandboxing applications and won’t give any benefit. User namespaces do add a lot of attack surface for privilege escalation but as Debian disables it for unprivileged users by default with a kernel patch, disabling them entirely is pointless.
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: