Hardening Linux-сервера: 15 обязательных шагов для production

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет администрирования Linux я принимал десятки серверов «по наследству» — и почти каждый раз находил в дефолте одно и то же: root по паролю в SSH, открытые наружу сервисы, отсутствие логов, последние обновления полгода назад. Эти базовые вещи — первая линия защиты. В этой статье собрал 15 шагов, которые я прохожу на каждом новом сервере в течение первого часа после получения доступа.

Шаг 1. Обновить систему

Первое, что я делаю на новой машине — полное обновление. Даже если это «свежая установка с прошлой недели», за это время успели выйти security-патчи.

sudo apt update && sudo apt upgrade -y    # Debian/Ubuntu
sudo dnf upgrade --refresh -y               # RHEL/Rocky
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure unattended-upgrades   # включить автоустановку security

Для RHEL-семейства аналог — dnf-automatic. У нас на практике автообновление security-патчей — лучшее, что можно сделать против 0-day. Оверхед минимальный, эффект огромный.

Шаг 2. Создать административного пользователя

Никогда не работаем под root на постоянной основе. Создаём отдельного пользователя с sudo:

sudo adduser admin
sudo usermod -aG sudo admin        # Debian/Ubuntu
sudo usermod -aG wheel admin       # RHEL/Rocky
sudo mkdir /home/admin/.ssh && sudo chown admin:admin /home/admin/.ssh
# Копируем публичный ключ
sudo -u admin sh -c 'echo "ssh-ed25519 AAAA..." > ~/.ssh/authorized_keys'
sudo chmod 600 /home/admin/.ssh/authorized_keys

Шаг 3. Отключить SSH-вход по паролю и root

Классика: /etc/ssh/sshd_config.d/50-hardening.conf — отдельный файл чтобы не трогать дефолтный:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
AllowUsers admin deploy
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
Protocol 2

Перед применением открываем вторую SSH-сессию (чтобы не потерять доступ, если что-то сломается), тестируем:

sudo sshd -t && sudo systemctl restart sshd

Шаг 4. Установить fail2ban

Даже при отключённых паролях боты не прекращают стучаться. fail2ban добавляет IP в firewall после 3-5 неудачных попыток.

sudo apt install fail2ban
sudo tee /etc/fail2ban/jail.local <<EOF
[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5
backend  = systemd

[sshd]
enabled = true
port    = 22
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Шаг 5. Настроить firewall

Открытые наружу только то, что реально нужно. Для базового набора — ufw (Ubuntu/Debian) или firewalld (RHEL). Для нагруженного — nftables напрямую.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.10.0/24 to any port 22
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Шаг 6. Harden sysctl

Сетевые и ядрные защиты через /etc/sysctl.d/:

# /etc/sysctl.d/40-security.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 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.icmp_echo_ignore_broadcasts = 1
net.ipv6.conf.all.accept_redirects = 0

kernel.randomize_va_space = 2
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 2
fs.suid_dumpable = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

sudo sysctl -p /etc/sysctl.d/40-security.conf

Шаг 7. Настроить AppArmor или SELinux

Мандатный контроль доступа ограничивает, к каким файлам и сокетам имеет доступ конкретный процесс. На Ubuntu AppArmor включен по умолчанию, но часто профили в режиме complain — переводим в enforce:

sudo aa-status
sudo aa-enforce /etc/apparmor.d/*
sudo systemctl restart apparmor

# RHEL/Rocky — SELinux
sudo getenforce
sudo setenforce 1
# В /etc/selinux/config: SELINUX=enforcing

Шаг 8. Включить auditd

auditd логирует системные события уровня ядра: запуск привилегированных команд, изменения критичных файлов, sudo-активность.

sudo apt install auditd audispd-plugins
sudo tee /etc/audit/rules.d/99-custom.rules <<EOF
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/sudoers.d/ -p wa -k privilege
-w /var/log/auth.log -p wa -k auth
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec
EOF
sudo systemctl restart auditd
sudo ausearch -k identity

Шаг 9. Ограничить sudo

Не все админы должны иметь полный sudo ALL. Для ограниченных ролей — конкретные команды:

# /etc/sudoers.d/webadmin
%webadmin ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, \
                               /usr/bin/systemctl reload nginx, \
                               /usr/bin/journalctl -u nginx

Шаг 10. Настроить централизованные логи

Локальные логи — первая цель злоумышленника после взлома. Отправляем копию в centralized log server (Graylog, Wazuh, rsyslog на отдельной машине):

# /etc/rsyslog.d/50-remote.conf
*.* @@logs.office.local:6514  # TCP с TLS

Шаг 11. Шифрование дисков

Для физических серверов — LUKS на системном диске. Для ВМ — зависит от требований по 152-ФЗ. Если сервер в дата-центре (МТС, Selectel) — обязательно, если админы заказчика работают с ПДН.

sudo cryptsetup luksFormat /dev/nvme1n1
sudo cryptsetup luksOpen /dev/nvme1n1 data
sudo mkfs.ext4 /dev/mapper/data
# /etc/crypttab + /etc/fstab для автомонтирования

Шаг 12. Disable ненужные сервисы

Меньше работающих сервисов — меньше поверхность атаки. Смотрим, что запущено:

sudo systemctl list-units --type=service --state=running
sudo ss -tulnp   # сетевые слушатели

# Типичные кандидаты на отключение на web-сервере:
sudo systemctl disable --now avahi-daemon cups bluetooth

Шаг 13. Мониторинг integrity

AIDE или Tripwire создают снимок хеша всех важных файлов и алертят при изменениях:

sudo apt install aide
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# В cron ежедневно:
# 0 3 * * * aide --check | mail -s "AIDE check" admin@company.ru

Шаг 14. Регулярный аудит lynis

Lynis — утилита, которая проходит по чек-листу harden'инга и выставляет балл:

sudo apt install lynis
sudo lynis audit system
# Отчёт в /var/log/lynis-report.dat с рекомендациями

У нас на практике новый сервер стартует с hardening-index 60-70, после прохождения наших 15 шагов — 85-92. Лишнее выводится системой как suggestions — прорабатываем индивидуально.

Шаг 15. Процедуры восстановления

Самый недооценённый шаг. Недостаточно настроить безопасность — нужно знать, что делать при инциденте:

• Документ «что делать при обнаружении взлома»: изолировать, сохранить форензическую копию, восстановить из бэкапа.
• Контактный список: администраторы, безопасник, юрист, MSSP, провайдер.
• Regularly тестируем восстановление — не только данных, но и инфраструктуры «с нуля».
• Таблица критичности сервисов и их RPO/RTO — чтобы при инциденте знать, что восстанавливать первым.

Сравнение: до и после harden'инга

Кейс: harden'инг после взлома веб-сервера

В ноябре 2025 к нам обратился клиент — интернет-магазин электроники на 15 сотрудников, Москва. Веб-сервер на Ubuntu 22.04 был взломан через уязвимость в устаревшей версии WordPress-плагина. Атакующий получил shell, попробовал privesc, но SELinux не дал развиться. Ограничился майнингом и web-shell.

За 4 часа мы: изолировали машину, сделали форензический образ, поставили рядом новый Dell PowerEdge R640 с Xeon Silver 4210, 32 ГБ RAM, в дата-центре МТС. Развернули чистую Ubuntu 24.04 по чек-листу из 15 шагов. Ключевые добавления: Wazuh SIEM с пересылкой логов на отдельный сервер, CrowdSec как альтернатива fail2ban с community-списками IP, ежедневный AIDE-аудит. После миграции вторых попыток проникновения не было. Стоимость работ — 62 000 руб., клиент был доволен.

FAQ — частые вопросы по harden'ингу

С чего начать harden'инг сервера?

Отключить SSH-пароли и включить автообновления безопасности. Это закрывает 80% типовых атак.

Нужен ли fail2ban, если SSH только по ключу?

Да, чтобы блокировать брутфорс-мусор в логах и снижать нагрузку.

AppArmor или SELinux — что выбрать?

AppArmor для Ubuntu/Debian, SELinux для RHEL/Rocky. Оба эффективны при правильной настройке.

Как часто проверять логи вручную?

Регулярно — нереально. Настройте централизованный сбор с алертами в Telegram/email.

Что делать с пакетными уязвимостями?

Автообновление security-патчей + еженедельный lynis + подписка на security-announce.