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

Привет! Меня зовут Семёнов Евгений Сергеевич, и я директор ITFresh. За мои 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-индексом где-то 60-70. Но когда он проходит наши 15 шагов, мы доводим его до впечатляющих 85-92! Если система выдаёт какие-то «suggestions», то это уже мелочи, которые мы прорабатываем для каждого клиента индивидуально.

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

Это, пожалуй, самый недооценённый пункт, вы не согласны? Ведь просто настроить безопасность — это только полдела. Что толку от идеальной защиты, если вы не знаете, как действовать, когда что-то пойдёт не так? Важно точно понимать, что делать при инциденте.

• Представьте: у вас на руках чёткий документ «Что делать, если обнаружили взлом». Там всё по шагам: сначала — изолировать, потом — обязательно сохранить форензическую копию, и только потом — восстанавливать всё из надёжного бэкапа. Просто, понятно, эффективно.
• А что насчёт экстренного контактного списка? Он должен быть всегда под рукой: администраторы, ваш безопасник, юрист, возможно, MSSP-партнёр и, конечно же, провайдер. Все, кто нужен, на одной странице.
• Мы регулярно, не просто так, а по расписанию, тестируем восстановление. И это не просто проверка данных, а полное разворачивание всей инфраструктуры «с нуля». Готовы ко всему!
• Что восстанавливать в первую очередь? Для этого есть таблица критичности ваших сервисов с чётко прописанными RPO и RTO. Так вы точно будете знать, за что хвататься при инциденте и что поднимать первым.

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

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

Вспомним один случай: в ноябре 2025 года к нам пришёл клиент — московский интернет-магазин электроники, у них целая команда из 15 человек. Что случилось? Их веб-сервер, который работал на Ubuntu 22.04, просто взломали! Причина оказалась до банальности проста: уязвимость в каком-то старом WordPress-плагине. Злоумышленник, конечно, получил шелл, даже попытался провести повышение привилегий (privesc). Но тут, к счастью, сработал SELinux, который не дал ему развернуться по-настоящему. В итоге, он ограничился майнингом и установил web-shell.

Мы не теряли ни минуты! Всего за 4 часа проделали невероятную работу: сначала изолировали атакованную машину, потом сняли с неё форензический образ. А параллельно, буквально тут же, в дата-центре МТС подняли абсолютно новый сервер — это был мощный Dell PowerEdge R640, с процессором Xeon Silver 4210 и 32 ГБ оперативной памяти. На него мы поставили чистую 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.