Hardening ядра Linux: sysctl параметры безопасности

Установка Ubuntu или Debian «из коробки» — это компромисс между безопасностью и совместимостью. Часть параметров ядра настроена консервативно для максимальной совместимости, а не для максимальной защиты. Linux kernel hardening через sysctl — это изменение этих параметров в сторону безопасности.

Хорошая новость: большинство параметров применяются без перезагрузки и не влияют на производительность заметным образом. На всех серверах клиентов мы раскатываем hardening-конфиг через Ansible сразу после первичной настройки — до открытия каких-либо портов наружу.

Три группы параметров:

• Защита памяти — ASLR, запрет маппинга нулевой страницы, ограничение ptrace
• Защита сети — SYN flood, IP spoofing, ICMP redirect, source routing
• Ограничение информации — dmesg, /proc, kernel pointers

Защита памяти затрудняет эксплуатацию уязвимостей типа buffer overflow и privilege escalation.

По умолчанию kernel.kptr_restrict равен 0: адреса ядра при выводе хешируются. При 1 указатели, выводимые через %pK, заменяются нулями для пользователей без CAP_SYSLOG, при 2 — нулями для всех, включая root. Значение kernel.dmesg_restrict по умолчанию зависит от опции сборки CONFIG_SECURITY_DMESG_RESTRICT, поэтому на разных дистрибутивах оно разное — я задаю его явно, а не полагаюсь на сборку.

Сетевые параметры — самая большая группа. Защищают от IP spoofing, SYN flood, ICMP redirect и других сетевых атак.

Собираем всё в один файл для деплоя через Ansible или вручную:

Префикс 99 я выбираю, чтобы файл шёл после вендорских и перекрывал их. Но при ручном sysctl --system последним всё равно читается /etc/sysctl.conf, поэтому перед раскаткой убираю из него дублирующие ключи.

Самая частая жалоба после раскатки hardening-конфига — «в файле 1, а в ядре 0». Почти всегда причина в одном из трёх мест, и я проверяю их именно в таком порядке.

Первое — очередность файлов. При загрузке параметры выставляет systemd-sysctl.service, он читает *.conf из /etc/sysctl.d/, /run/sysctl.d/, /usr/local/lib/sysctl.d/ и /usr/lib/sysctl.d/. Файл в /etc/ с тем же именем целиком заменяет вендорский. Все файлы сортируются по имени лексикографически, независимо от каталога, и при конфликте побеждает значение из файла, который идёт позже. Документация systemd советует для своих файлов в /etc/ префиксы 60–90, для пакетов в /usr/ — 10–40. Ручная команда sysctl --system проходит те же каталоги, но /etc/sysctl.conf читает последним: старое значение, забытое в нём, перекроет любой файл из sysctl.d.

# где ещё задан параметр
grep -rn "rp_filter" /etc/sysctl.conf /etc/sysctl.d/ /run/sysctl.d/ \
    /usr/local/lib/sysctl.d/ /usr/lib/sysctl.d/ 2>/dev/null

# перечитать все файлы в том же порядке, что при загрузке
sysctl --system

# что реально стоит в ядре
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter

Второе — модули ядра. Часть ключей появляется только после загрузки модуля: например, net.bridge.* — после br_netfilter. Если модуль грузится позже systemd-sysctl, ключа на момент применения просто нет, а запись в отсутствующий ключ логируется на уровне debug и сервис не падает. Справка sysctl.d(5) предлагает два решения: udev-правило на появление модуля или файл в /etc/modules-load.d/, чтобы модуль загружался раньше. Параметры интерфейсов (net.ipv4.conf.*, net.ipv6.conf.*) systemd применяет отдельно для каждого интерфейса по мере его появления.

Третье — путаница all, default и имени интерфейса. Ветка default задаёт значения для интерфейсов, которые будут созданы после, а на уже поднятые не влияет. Правила объединения у каждого ключа свои: для rp_filter ядро берёт максимум из conf/all и conf/<интерфейс>; log_martians включён, если единица стоит хотя бы в одном из них; accept_redirects на хосте без форвардинга остаётся включённым, если он TRUE хотя бы в одном месте. Поэтому редиректы я выключаю и в all, и в default, а проверяю на конкретном интерфейсе, а не на all.

Отдельная ловушка — Docker. Он при старте сам включает net.ipv4.ip_forward и net.ipv6.conf.all.forwarding, если они выключены, и ставит политику DROP для пересылаемых пакетов. На хосте с контейнерами строка net.ipv4.ip_forward = 0 из общего конфига бессмысленна: я убираю её из шаблона для таких серверов, чтобы проверка не показывала ложное расхождение.

Базовый файл выше закрывает очевидное. На серверах, где есть недоверенные локальные пользователи или веб-приложения, я добавляю ещё несколько ключей. У части из них есть особенность: после установки значение нельзя вернуть без перезагрузки, поэтому сначала проверяю их на тестовой машине.

• kernel.unprivileged_bpf_disabled — значение 1 запрещает вызов bpf() без CAP_SYS_ADMIN или CAP_BPF, и снять запрет на работающем ядре уже нельзя. Значение 2 запрещает то же самое, но администратор может позже записать 0 или 1. Если ядро собрано с BPF_UNPRIV_DEFAULT_OFF, по умолчанию там уже 2.
• net.core.bpf_jit_harden = 2 — усиление JIT-компилятора BPF для всех пользователей, защита от JIT spraying. По умолчанию 0; цена — производительность BPF-программ.
• kernel.perf_event_paranoid — по умолчанию 2: без CAP_PERFMON запрещено профилирование ядра. Ниже 2 я не опускаю без конкретной задачи мониторинга.
• kernel.kexec_load_disabled = 1 — отключает вызовы kexec_load и kexec_file_load, вернуть 0 нельзя. Если на сервере работает kdump, образ аварийного ядра должен загрузиться до установки этого ключа.
• fs.protected_fifos = 2 и fs.protected_regular = 2 — запрет O_CREAT на чужие FIFO и обычные файлы в sticky-каталогах, доступных на запись всем или группе (типичный пример — /tmp).
• kernel.yama.ptrace_scope = 3 — полный запрет ptrace, включая PTRACE_TRACEME; после установки значение не меняется. На серверах, где админы пользуются strace -p и gdb --pid, оставляю 1 или 2: при 2 подключаться может только процесс с CAP_SYS_PTRACE.

# /etc/sysctl.d/99-hardening-extra.conf
kernel.unprivileged_bpf_disabled = 2
net.core.bpf_jit_harden = 2
kernel.perf_event_paranoid = 2
fs.protected_fifos = 2
fs.protected_regular = 2
# необратимые до перезагрузки — только после теста:
# kernel.kexec_load_disabled = 1
# kernel.yama.ptrace_scope = 3

Про fs.suid_dumpable: в базовом файле стоит 0, и это значение по умолчанию. Режим 1 (debug) документация ядра прямо называет небезопасным — обычный пользователь получает дампы памяти привилегированных процессов. Поэтому после любой отладки проверяю его отдельно.

После Ansible-прогона я не верю выводу «ok», а сверяю ядро с файлом. Скрипт ниже проходит конфиг построчно и печатает только расхождения:

while IFS='=' read -r k v; do
  k=$(echo "$k" | xargs); v=$(echo "$v" | xargs)
  case "$k" in ''|\#*) continue;; esac
  cur=$(sysctl -n "$k" 2>/dev/null)
  [ "$cur" = "$v" ] || echo "РАСХОЖДЕНИЕ: $k ждём '$v', в ядре '${cur:-нет ключа}'"
done < /etc/sysctl.d/99-hardening.conf

1. sysctl --system отрабатывает без ошибок, кроме ключей, которых нет на этом ядре.
2. Скрипт сверки не выводит ни одной строки.
3. На шлюзах с асимметричной маршрутизацией, нескольких аплинках или VPN вместо rp_filter = 1 стоит 2 (loose): так рекомендует документация ядра со ссылкой на RFC 3704, иначе легитимные пакеты отбрасываются молча.
4. Если в логах появились предупреждения о SYN flood, выясняю, не легитимная ли это нагрузка. SYN cookies — запасной механизм; при реальном потоке соединений документация советует настраивать tcp_max_syn_backlog, tcp_synack_retries и tcp_abort_on_overflow.
5. Тестовый сервер перезагружен, сверка повторена — так ловлю ключи, которые при загрузке не применились из-за поздних модулей.
6. Агенты мониторинга и профилировщики, которые подключаются к чужим процессам через ptrace или читают счётчики perf, работают после изменения ptrace_scope и perf_event_paranoid.