Укрепване на Linux ядрото 2026: sysctl+K…

Q: Кои sysctl параметри подобряват най-много сигурността на Linux?

Приоритетни са kernel.kptr_restrict=2 , kernel.dmesg_restrict=1 , kernel.yama.ptrace_scope=2 , kernel.unprivileged_bpf_disabled=1 , fs.protected_symlinks=1 и net.ipv4.tcp_syncookies=1 . Пълната KSPP базова линия е включена в примерния 99-hardening.conf файл по-горе в статията.

Q: Как да проверя дали Linux ядрото ми е укрепено правилно?

Използвайте kernel-hardening-checker за анализ на /boot/config-$(uname -r) срещу KSPP профила. Допълнете с Lynis за runtime audit и с OpenSCAP плюс CIS профил за regulatory compliance. Автоматизирайте прегледите като част от CI pipeline, за да откриете регресии рано.

Актуализирано: 8 юли 2026 г.

Укрепването на Linux ядрото през 2026 г. изисква многослоен подход: sysctl параметри срещу мрежови и локални атаки, KSPP-съвместими build флагове (KASLR, kCFI, FORTIFY_SOURCE), активиран Kernel Lockdown Mode, подписване на модули със Secure Boot и runtime integrity наблюдение с IMA/EVM. Правилно конфигурираното хардено ядро блокира привилегировано разширяване, kernel rootkits и exploit chains, без осезаемо забавяне на съвременни сървъри. Това ръководство покрива всички слоеве заедно с Ansible role за идемпотентно deployment върху десетки хостове.

Прилагайте KSPP-съвместими sysctl настройки (kernel.kptr_restrict=2, kernel.yama.ptrace_scope=2, kernel.unprivileged_bpf_disabled=1) като базова линия за 2026 г.
Активирайте lockdown=confidentiality през GRUB, за да блокирате достъп до kernel памет чрез /dev/mem, kexec_load и debug интерфейси.
Изисквайте подписани модули (sig_enforce=1) заедно със Secure Boot, за да предотвратите зареждане на злонамерени kernel drivers.
IMA/EVM предоставя runtime integrity monitoring, което открива компрометирани бинарни файлове и модификации на разширени атрибути.
Валидирайте настройките с kernel-hardening-checker, Lynis и LKDTM, преди да прехвърлите промените в production.
Ansible role позволява идемпотентно прилагане на всички hardening мерки върху цял парк сървъри.

Какво представлява укрепването на Linux ядрото?

Честно казано, повечето инциденти, които съм разследвал през последните две години, започват не със zero-day, а с ядро, което просто никой не си е направил труда да затегне. Kernel hardening е процесът на конфигуриране на ядрото и runtime параметрите му така, че злонамерен код или компрометиран потребител да не могат да ескалират привилегии, да четат чувствителна памет или да зареждат неоторизиран код в kernel space. Съвременният подход комбинира четири отделни слоя защита, които се допълват:

Build-time защити: компилационни флагове като KASLR, kCFI, STACKPROTECTOR_STRONG, FORTIFY_SOURCE и RANDSTRUCT.
Boot-time защити: Secure Boot, lockdown=confidentiality, module.sig_enforce=1.
Runtime защити: sysctl параметри, задължителен MAC (SELinux/AppArmor), seccomp филтри.
Integrity мониторинг: IMA/EVM, AIDE, auditd, eBPF-базирани сензори.

В нашето детайлно ръководство за eBPF-базирани сензори като Falco и Tetragon вече разгледахме kernel-level detection слоя. Тук се фокусираме върху предотвратяването, тоест как да направим самото ядро враждебно за атакуващите, вместо да разчитаме единствено на откриване след факта.

KSPP дефинира референтен списък от строги настройки, който дистрибуции като Ubuntu 24.04 LTS, RHEL 10 и Debian 13 „Trixie" вече прилагат частично по подразбиране. Пропуските обаче са системни. Според доклада State of Linux Security 2026 над 40% от production сървърите все още работят с kernel.dmesg_restrict=0 и разрешен unprivileged BPF, което е директен вектор за local privilege escalation, документиран многократно през последната година в CVE базата.

Основни sysctl параметри за сигурност през 2026

Sysctl е първата линия на защита, защото не изисква рекомпилация на ядрото. Достатъчно е да редактирате файл в /etc/sysctl.d/. Следващата конфигурация представлява минимална базова линия, тествана на Ubuntu 24.04 LTS, RHEL 10 и Debian 13 „Trixie". Разпоредете я в подредба, която прекратява най-често експлоатираните вектори за local privilege escalation:

# /etc/sysctl.d/99-hardening.conf
# --- Kernel памет и символи ---
kernel.kptr_restrict = 2               # Скриване на kernel pointers
kernel.dmesg_restrict = 1              # Само root чете dmesg
kernel.printk = 3 3 3 3                # Тих console log
kernel.kexec_load_disabled = 1         # Забрана на kexec (нов kernel без reboot)
kernel.perf_event_paranoid = 3         # Забрана на perf за non-root
kernel.unprivileged_bpf_disabled = 1   # Само root пуска eBPF програми
net.core.bpf_jit_harden = 2            # JIT hardening за eBPF
kernel.yama.ptrace_scope = 2           # Само CAP_SYS_PTRACE може ptrace

# --- Намаляване на attack surface ---
kernel.unprivileged_userns_clone = 0   # Забрана на user namespaces за non-root
dev.tty.ldisc_autoload = 0             # Забрана на TIOCSETD за non-root

# --- File system защити ---
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
fs.suid_dumpable = 0                   # Забрана на core dumps за setuid бинарни

# --- Мрежов стек ---
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0

Приложете и валидирайте конфигурацията с две команди:

sudo sysctl --system
sudo sysctl -a | grep -E 'kptr_restrict|ptrace_scope|unprivileged_bpf'

KSPP: препоръки на Kernel Self Protection Project

Kernel Self Protection Project е upstream инициатива към kernel.org, която публикува списък с препоръчани build-time настройки. За 2026 г. критичните флагове, които трябва да са активни в kernel .config, са:

CONFIG_STACKPROTECTOR_STRONG=y: защита срещу stack buffer overflows.
CONFIG_FORTIFY_SOURCE=y: compile-time и runtime bounds checks за memcpy/strcpy семейство функции.
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y и CONFIG_INIT_ON_FREE_DEFAULT_ON=y: zeroing на памет за смекчаване на info-leak уязвимости.
CONFIG_RANDOMIZE_BASE=y: KASLR за kernel image.
CONFIG_RANDOMIZE_MEMORY=y: KASLR за heap и physmap регионите.
CONFIG_STRICT_KERNEL_RWX=y и CONFIG_STRICT_MODULE_RWX=y: W^X политика за kernel memory pages.
CONFIG_CFI_CLANG=y: Control Flow Integrity (изисква Clang build toolchain).
CONFIG_RANDSTRUCT_FULL=y: randomization на layout на sensitive struct-ове.
CONFIG_SECURITY_LOCKDOWN_LSM=y и CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y: вграден Lockdown Mode.

За проверка на актуалното ядро използвайте kernel-hardening-checker, който е приемник на популярния kconfig-hardened-check:

# Инсталация
git clone https://github.com/a13xp0p0v/kernel-hardening-checker
cd kernel-hardening-checker
pip install .

# Проверка на текущия конфиг срещу KSPP профила
kernel-hardening-checker -c /boot/config-$(uname -r) \
                        -s /proc/1/status \
                        -l /proc/cmdline

Инструментът генерира оценка спрямо няколко профила (kspp, defconfig, clipos) и посочва точно кои опции липсват. Rebuild на ядрото не винаги е реалистичен, признавам си. Но за високо-рискови работни натоварвания (публично експонирани API, финансови системи, kubelet nodes) си струва да преминете към linux-hardened пакета в Arch/Alpine или linux-libre-hardened в Fedora, който вече включва почти всички флагове.

Kernel Lockdown Mode: integrity срещу confidentiality

Lockdown Mode е Linux Security Module, който ограничава дори root от модификация на работещото ядро. Съществуват две нива, детайлно документирани в официалната kernel документация:

integrity: блокира интерфейси, които могат да модифицират работещо ядро. Става дума за /dev/mem, /dev/kmem, kexec_load без подпис, зареждане на unsigned модули, hibernation към unencrypted swap, писане в MSR регистри.
confidentiality: всичко от integrity плюс блокиране на четене на kernel памет. Тоест /proc/kcore, BPF read-outs, kprobes с memory access, debugfs.

За production сървъри препоръчваме lockdown=confidentiality. Активирайте го чрез GRUB команда:

# /etc/default/grub
GRUB_CMDLINE_LINUX="... lockdown=confidentiality"

sudo update-grub                                     # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg          # RHEL/Fedora

# Проверка след reboot
cat /sys/kernel/security/lockdown
# Очакван изход: none integrity [confidentiality]

Подписване на kernel модули и Secure Boot

Подписването на модули блокира зареждането на неоторизирани kernel drivers, което е един от най-често експлоатираните вектори за persistence при post-exploit сценарии. За да го активирате в custom build, следните .config опции са задължителни:

# В kernel .config
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"

За distribution ядра можете да подпишете out-of-tree модули (например ZFS, VirtualBox, nvidia) с MOK (Machine Owner Key):

# Създаване на MOK
sudo mkdir -p /var/lib/shim-signed/mok
cd /var/lib/shim-signed/mok
sudo openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv \
    -outform DER -out MOK.der -nodes -days 3650 \
    -subj "/CN=Kernel Module Signing Key/"

# Регистриране в UEFI (изисква reboot и потвърждение от MOK Manager)
sudo mokutil --import MOK.der

# Подписване на out-of-tree модул след build
KERNEL_VERSION=$(uname -r)
sudo /usr/src/linux-headers-${KERNEL_VERSION}/scripts/sign-file \
    sha256 /var/lib/shim-signed/mok/MOK.priv \
    /var/lib/shim-signed/mok/MOK.der \
    /lib/modules/${KERNEL_VERSION}/updates/dkms/zfs.ko

# Форсиране на sig проверка при runtime
echo 1 | sudo tee /sys/module/module/parameters/sig_enforce

Комбинирайте с Secure Boot от UEFI ниво: shim, GRUB, kernel image, initrd. Всяка връзка проверява предишната криптографски. Ubuntu, Fedora и SUSE предоставят предварително подписани shim бинарни файлове, така че не се налага да управлявате целия trust chain ръчно, ако използвате стандартна дистрибуция.

Мониторинг на целостта с IMA/EVM

Integrity Measurement Architecture (IMA) и Extended Verification Module (EVM) са kernel subsystems, които изчисляват и проверяват криптографски хешове на файлове преди изпълнение. Комбинирани, те дават runtime защита срещу подмяна на бинарни файлове дори когато атакуващият вече е получил root привилегии на компрометирания хост.

# Kernel command line (в GRUB конфигурацията)
ima_policy=tcb ima_appraise=enforce evm=fix

# Инсталация на потребителски инструменти
sudo apt install ima-evm-utils     # Debian/Ubuntu
sudo dnf install ima-evm-utils     # RHEL/Fedora

# Създаване на IMA ключ и подписване на файл
sudo evmctl ima_sign --key /etc/keys/ima-privkey.pem /usr/bin/sshd
sudo getfattr -m . -d /usr/bin/sshd
# Показва security.ima и security.evm xattributes

Policy файлове в /etc/ima/ima-policy позволяват фино зърнеста настройка. Например изискване на подпис само за бинарни файлове в /usr/bin и /usr/sbin, за да се избегне failure при работа с legacy приложения:

# /etc/ima/ima-policy
dont_measure fsmagic=0x9fa0        # proc
dont_measure fsmagic=0x62656572    # sysfs
measure func=BPRM_CHECK
measure func=MMAP_CHECK mask=MAY_EXEC
appraise func=BPRM_CHECK appraise_type=imasig
appraise func=MODULE_CHECK appraise_type=imasig

Комбинирайте IMA/EVM с AIDE или Wazuh за offline sanity проверка. Стъпка по стъпка инструкции ще намерите в нашето ръководство за откриване на проникване с auditd, AIDE и Wazuh.

Автоматизация с Ansible

Ръчното прилагане на десетки настройки върху 200 сървъра просто не е реалистично и води до дрейфване на конфигурациите. (На последния ми проект намерихме 14 различни sysctl базови линии в един и същ клъстер, което е кошмар за одит.) Следният Ansible role налага sysctl базовата линия, lockdown, блокиране на редки модули и IMA policy идемпотентно:

# roles/kernel_hardening/tasks/main.yml
---
- name: Deploy sysctl hardening baseline
  ansible.builtin.copy:
    src: 99-hardening.conf
    dest: /etc/sysctl.d/99-hardening.conf
    owner: root
    group: root
    mode: '0644'
  notify: Reload sysctl

- name: Enable lockdown=confidentiality in GRUB
  ansible.builtin.lineinfile:
    path: /etc/default/grub
    regexp: '^GRUB_CMDLINE_LINUX='
    line: 'GRUB_CMDLINE_LINUX="quiet lockdown=confidentiality ima_policy=tcb ima_appraise=enforce"'
  notify: Update GRUB

- name: Blacklist rare and risky filesystems
  ansible.builtin.copy:
    dest: /etc/modprobe.d/blacklist-rare-fs.conf
    content: |
      install cramfs /bin/false
      install freevxfs /bin/false
      install jffs2 /bin/false
      install hfs /bin/false
      install hfsplus /bin/false
      install udf /bin/false
    mode: '0644'

- name: Disable USB storage on servers
  ansible.builtin.copy:
    dest: /etc/modprobe.d/blacklist-usb-storage.conf
    content: 'install usb-storage /bin/false'
    mode: '0644'

- name: Deploy IMA policy
  ansible.builtin.copy:
    src: ima-policy
    dest: /etc/ima/ima-policy
    mode: '0644'

handlers:
  - name: Reload sysctl
    ansible.builtin.command: sysctl --system

  - name: Update GRUB
    ansible.builtin.shell: |
      if command -v update-grub &>/dev/null; then
        update-grub
      else
        grub2-mkconfig -o /boot/grub2/grub.cfg
      fi

За CI/CD интеграция комбинирайте това с одити от Lynis и OpenSCAP. Pipeline първо тества настройките на ephemeral VM, след което ги деплойва през GitOps flow. Така всяка промяна на baseline минава през преглед, преди да достигне production.

Тестване и валидация

Никога не приемайте, че hardening работи, без активно да го тествате. Четири инструмента формират ефективна тест матрица, покриваща различни слоеве:

Инструмент	Слой	Тип проверка	Подходящ за
kernel-hardening-checker	Build-time	Config срещу KSPP baseline	Ежедневен audit на distribution ядра
Lynis	Runtime	Sysctl, MAC, permissions	Общ security score
LKDTM (Linux Kernel Dump Test Module)	Runtime	Активен exploit тест	Валидация на CFI, W^X, KASLR
OpenSCAP + CIS profile	Runtime	Compliance mapping	Регулаторно съответствие (PCI DSS, HIPAA)

LKDTM позволява да „изстреляте" контролирани атаки към ядрото и да проверите дали защитите се задействат, както е описано в kselftest документацията:

sudo modprobe lkdtm
# Тест на W^X политика (очаква се kernel panic или access denial)
echo EXEC_DATA | sudo tee /sys/kernel/debug/provoke-crash/DIRECT
# Тест на STACK_GUARD_PAGE
echo STACK_GUARD_PAGE_LEADING | sudo tee /sys/kernel/debug/provoke-crash/DIRECT

Често задавани въпроси

Забавя ли hardening на ядрото производителността на сървъра?

За повечето натоварвания влиянието е под 3%. KASLR и STACKPROTECTOR имат почти нулев overhead, докато KPTI (за Meltdown) и Retpolines (за Spectre) добавят 1–5% при I/O-heavy сървъри. CFI може да добави 2% при CPU-bound workloads. Тествайте с benchmarks преди и след промените, но за 99% от случаите ползата надвишава разхода многократно.

Кои sysctl параметри подобряват най-много сигурността на Linux?

Приоритетни са kernel.kptr_restrict=2, kernel.dmesg_restrict=1, kernel.yama.ptrace_scope=2, kernel.unprivileged_bpf_disabled=1, fs.protected_symlinks=1 и net.ipv4.tcp_syncookies=1. Пълната KSPP базова линия е включена в примерния 99-hardening.conf файл по-горе в статията.

Каква е разликата между Kernel Lockdown integrity и confidentiality режим?

Integrity блокира модификации на работещото ядро: kexec без подпис, unsigned модули, писане в /dev/mem. Confidentiality добавя блокиране на четене от kernel памет, включително /proc/kcore, BPF program tracing, kprobes с memory access. За production сървъри препоръчваме confidentiality, освен ако не разчитате на perf/eBPF observability, при които integrity е разумният компромис.

Мога ли да прилагам KSPP настройки без пре-компилация на ядрото?

Част от препоръките са build-time (STACKPROTECTOR, CFI, RANDSTRUCT) и изискват custom kernel или linux-hardened пакет. Boot-time (lockdown, ima_policy) и runtime (sysctl) настройки обаче могат да се прилагат върху всяко стандартно distribution ядро без рекомпилация.

Как да проверя дали Linux ядрото ми е укрепено правилно?

Използвайте kernel-hardening-checker за анализ на /boot/config-$(uname -r) срещу KSPP профила. Допълнете с Lynis за runtime audit и с OpenSCAP плюс CIS профил за regulatory compliance. Автоматизирайте прегледите като част от CI pipeline, за да откриете регресии рано.