Защита сервера: полный чек-лист

01Мышление: слои и минимальные привилегии

Защита сервера строится на двух принципах. Эшелонированная защита: исходите из того, что любой отдельный слой может отказать, и складывайте несколько (WAF на краю, файрвол, политика SSH, права приложений, бэкапы). Минимальные привилегии: каждый пользователь, процесс и ключ получает только тот доступ, который ему нужен, чтобы компрометация оставалась небольшой. Действуйте в безопасном порядке, потому что классическая авария при защите сервера — запереть самого себя. Сначала создайте своего пользователя и ключ, убедитесь во втором терминале, что можете войти с ними, и только потом отключайте root и пароли. Разрешите SSH в файрволе до его включения. Держите веб-консоль провайдера как запасной выход. Записывайте каждый шаг в короткий runbook или скрипт, чтобы следующий сервер получил ровно такую же обработку и вы могли показать клиенту, что было сделано.

• Сокращайте поверхность атаки: меньше открытых портов, сервисов и пакетов.
• Ограничивайте радиус поражения: отдельные пользователи, частные сети, учётные данные с узкими правами.
• Исходите из того, что взлом возможен: бэкапы вне площадки, логи и алерты, которые вы действительно будете читать.

021. Пользователи и SSH: только ключи, без root

Создайте личного администратора с sudo и установите свой публичный ключ (ключ Ed25519 — современный стандарт). Затем отключите вход под root и аутентификацию по паролю через отдельный файл в /etc/ssh/sshd_config.d/, который переживает обновления пакетов лучше, чем правка основного файла. В Ubuntu сервис называется ssh. Проверьте конфиг через sshd -t перед reload и держите текущую сессию открытой, пока тестируете новый вход в другом терминале. Смена порта SSH лишь уменьшает шум в логах; это не мера безопасности, так что делайте это, только если хотите более тихие логи. В командах дайте каждому человеку собственного пользователя и ключ, чтобы доступ можно было отзывать индивидуально, и удаляйте ключи ушедших людей.

1# On the server, as root (one time)
2adduser your_user
3usermod -aG sudo your_user
4# From your laptop
5ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
6 
7# /etc/ssh/sshd_config.d/99-hardening.conf
8PermitRootLogin no
9PasswordAuthentication no
10KbdInteractiveAuthentication no
11PubkeyAuthentication yes
12MaxAuthTries 3
13AllowUsers your_user
14 
15# Validate, then reload (keep the current session open!)
16sudo sshd -t && sudo systemctl reload ssh

032. Файрвол, обновления и fail2ban

По умолчанию запретите весь входящий трафик и откройте только то, что обслуживает сервер: SSH, HTTP и HTTPS. Продублируйте те же правила в файрволе облачного провайдера, чтобы трафик фильтровался ещё до того, как дойдёт до машины. Одна важная ловушка: Docker публикует порты контейнеров, записывая собственные правила iptables, которые обходят ufw. В файлах Compose привязывайте опубликованные порты к 127.0.0.1, если им действительно не нужно быть публичными. Далее включите unattended-upgrades для патчей безопасности; большинство обновлений ядра всё равно требует перезагрузки, так что запланируйте окно обслуживания или разрешите автоматические перезагрузки в тихий час. Установите fail2ban, чтобы банить источники brute force. Наконец, удалите сервисы, которыми не пользуетесь: каждый слушающий демон — это ещё одна вещь, которую нужно патчить.

1sudo ufw default deny incoming
2sudo ufw default allow outgoing
3sudo ufw allow OpenSSH
4sudo ufw allow 80/tcp
5sudo ufw allow 443/tcp
6sudo ufw enable
7sudo ufw status verbose
8 
9sudo apt update && sudo apt install -y unattended-upgrades fail2ban
10sudo dpkg-reconfigure -plow unattended-upgrades
11# Optional: /etc/apt/apt.conf.d/50unattended-upgrades
12#   Unattended-Upgrade::Automatic-Reboot "true";
13#   Unattended-Upgrade::Automatic-Reboot-Time "04:00";
14 
15sudo ss -tulpn   # everything listening; nothing unexpected on 0.0.0.0

043. Приложения: отдельные пользователи, права, приватные базы, секреты

Запускайте каждый сайт или приложение под собственным системным пользователем со своим пулом PHP-FPM или записью в менеджере процессов. Если одно приложение взломают, оно не сможет прочитать код, загрузки или env-файл другого. Код должен принадлежать пользователю deploy и быть недоступным для записи веб-процессу; доступны для записи только папки, которые должны меняться во время работы (storage и bootstrap/cache в Laravel, папки загрузок). Env-файлы доступны для чтения только пользователю приложения. Базы данных и Redis слушают localhost или частную сеть, и у каждого приложения свой пользователь БД с минимальными правами. Секреты живут в env-файлах на сервере или в менеджере секретов, никогда в Git, и ротируются, когда кто-то уходит или есть подозрение на утечку. Прогоняйте по репозиторию сканер секретов, потому что утёкшие ключи в старых коммитах — частый источник взломов.

1# One system user per app, no login shell
2sudo adduser --system --group --home /var/www/shop --shell /usr/sbin/nologin shop
3 
4# Code: owned by the deploy user, readable by the app group
5sudo chown -R deploy:shop /var/www/shop
6sudo find /var/www/shop -type d -exec chmod 750 {} +
7sudo find /var/www/shop -type f -exec chmod 640 {} +
8 
9# Only runtime folders are writable by the app
10sudo chmod -R 770 /var/www/shop/storage /var/www/shop/bootstrap/cache
11 
12# Secrets: readable by the app only
13sudo chown deploy:shop /var/www/shop/.env && sudo chmod 640 /var/www/shop/.env

054. HTTPS везде и WAF впереди

Каждый сайт получает сертификат, обычно от Let's Encrypt через certbot, с автоматическим продлением (certbot устанавливает таймер systemd; проверьте его через dry run). Перенаправляйте HTTP на HTTPS, используйте только TLS 1.2 и 1.3 и добавьте HSTS, когда убедитесь, что каждый поддомен работает по HTTPS. Cloudflare или похожий CDN/WAF впереди скрывает IP origin-сервера, поглощает базовый DDoS-трафик и позволяет блокировать плохих ботов и применять rate limits на краю. Используйте режим SSL Full (strict), чтобы соединение от Cloudflare до вашего сервера было зашифровано, а сертификат проверялся; Flexible отправляет трафик на origin незашифрованным. Для дополнительной защиты разрешите 80 и 443 только с диапазонов IP Cloudflare или используйте туннель, чтобы атакующие не могли обойти край, обращаясь к IP origin напрямую.

1sudo apt install -y certbot python3-certbot-nginx
2sudo certbot --nginx -d example.com -d www.example.com
3sudo certbot renew --dry-run
4systemctl list-timers | grep certbot
5 
6# nginx: modern TLS and HSTS (add HSTS only when all subdomains use HTTPS)
7ssl_protocols TLSv1.2 TLSv1.3;
8add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
9add_header X-Content-Type-Options "nosniff" always;
10add_header Referrer-Policy "strict-origin-when-cross-origin" always;
11server_tokens off;

065. Бэкапы, мониторинг и аудит

Защита сервера — это ещё и умение пережить то, что не удалось предотвратить. Делайте снапшоты у провайдера и, отдельно, бэкапы баз данных и загрузок на уровне приложения, скопированные в другой аккаунт или к другому провайдеру. Проверяйте восстановление по расписанию: непроверенный бэкап — это надежда, а не план. Мониторьте то, что обычно убивает небольшие серверы: заполненные диски, исчерпание памяти, истёкшие сертификаты и упавший сайт. Внешний мониторинг доступности (Uptime Kuma или алерты провайдера) плюс алерты по диску и нагрузке покрывают большую часть. Храните логи достаточно долго, чтобы расследовать инцидент. Затем проводите аудит: Lynis сканирует систему и выдаёт конкретные рекомендации по защите с оценкой — хороший способ поймать то, что пропустил чек-лист. Повторяйте его после изменений и сохраняйте отчёт.

1# Audit the system and read the suggestions
2sudo apt install -y lynis
3sudo lynis audit system
4sudo less /var/log/lynis-report.dat
5 
6# Quick health checks
7df -h                          # disk usage
8free -h                        # memory
9sudo last -n 20                # recent logins
10sudo journalctl -p err -b      # errors since boot
11sudo fail2ban-client status sshd

07SSH изнутри в современной Ubuntu: socket activation и криптография

Начиная с Ubuntu 24.04, SSH использует socket activation в systemd: ssh.socket слушает порт и запускает ssh.service при первом подключении. Генератор systemd читает Port и ListenAddress из sshd_config, чтобы собрать сокет, поэтому смена порта требует daemon-reload плюс перезапуска ssh.socket, а не просто reload сервиса. Многие заблокировали себе доступ: поменяли Port, перезагрузили ssh и закрыли сессию, а сокет всё ещё слушал 22, тогда как файрвол разрешал только новый порт. Что касается криптографии, текущие настройки OpenSSH по умолчанию хороши: свежие релизы автоматически согласуют гибридный постквантовый обмен ключами, а ключи Ed25519 — стандарт. Не копируйте старые списки шифров из блогов — они часто ослабляют современные настройки. sshd -T выводит действующую конфигурацию после всех drop-in, а инструмент ssh-audit сообщает о слабых алгоритмах. Для максимальной надёжности используйте аппаратные ключи (ed25519-sk) на security key, чтобы украденный с ноутбука файл был бесполезен.

1# /etc/ssh/sshd_config.d/99-hardening.conf
2Port 2222
3 
4# Open the new port first, then rebuild the socket
5sudo ufw allow 2222/tcp
6sudo sshd -t
7sudo systemctl daemon-reload
8sudo systemctl restart ssh.socket
9sudo ss -tlnp | grep -E ':22 |:2222 '
10 
11# Effective settings after all drop-ins
12sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|port'

08Песочница для сервисов с помощью systemd

Отдельный Unix-пользователь ограничивает, какие файлы может прочитать скомпрометированное приложение, но процесс всё равно видит большую часть файловой системы, может писать в /tmp, запускать произвольные бинарники и открывать любые сетевые сокеты. systemd может ограничить каждый сервис гораздо сильнее несколькими строками в drop-in: доступ к ОС только на чтение, никакого доступа к домашним каталогам, приватный /tmp, запрет повышения привилегий через setuid-бинарники и только нужные семейства адресов. systemd-analyze security оценивает каждый юнит от 0 (хорошо защищён) до 10 (открыт) и перечисляет недостающие опции, что делает защиту измеримой. Применяйте опции постепенно и тестируйте, потому что слишком тесная песочница проявляется ошибками доступа во время работы. MemoryMax и CPUQuota к тому же не дают одному вышедшему из-под контроля процессу положить весь сервер. Те же идеи есть и для контейнеров: запуск не от root, корневая файловая система только для чтения, урезанные capabilities.

1# /etc/systemd/system/web.service.d/hardening.conf
2[Service]
3User=web
4NoNewPrivileges=yes
5ProtectSystem=strict
6ProtectHome=yes
7PrivateTmp=yes
8PrivateDevices=yes
9ReadWritePaths=/var/www/web/shared
10ProtectKernelTunables=yes
11ProtectKernelModules=yes
12ProtectControlGroups=yes
13RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
14CapabilityBoundingSet=
15MemoryMax=1G
16# Then: sudo systemctl daemon-reload && systemd-analyze security web.service

09Настройки ядра и сети

Настройки sysctl управляют поведением ядра. Ubuntu уже поставляет разумные значения по умолчанию в /etc/sysctl.d/10-*.conf: SYN cookies, защищённые symlink и hardlink, ограниченные указатели ядра, а начиная с 24.04 — ограничения AppArmor на непривилегированные user namespaces. Небольшой дополнительный файл ещё сильнее укрепляет сетевой стек: игнорировать ICMP redirect и пакеты с source routing, которые могут перенаправить трафик, не отправлять redirect, раз сервер не маршрутизатор, и логировать пакеты с невозможными адресами источника. Два предостережения. Docker, Kubernetes и VPN-серверам нужен net.ipv4.ip_forward = 1, поэтому никогда не отключайте forwarding вслепую на таких хостах. А строгая проверка обратного пути (rp_filter = 1) может сломать серверы с несколькими интерфейсами и асимметричной маршрутизацией; поэтому Ubuntu по умолчанию использует мягкий режим (2). Применяйте через sysctl --system и перед раскаткой проверьте, что сеть и контейнеры по-прежнему работают.

1# /etc/sysctl.d/99-hardening.conf
2net.ipv4.conf.all.accept_redirects = 0
3net.ipv6.conf.all.accept_redirects = 0
4net.ipv4.conf.all.send_redirects = 0
5net.ipv4.conf.all.accept_source_route = 0
6net.ipv6.conf.all.accept_source_route = 0
7net.ipv4.conf.all.log_martians = 1
8net.ipv4.tcp_syncookies = 1
9kernel.dmesg_restrict = 1
10kernel.kptr_restrict = 2
11 
12# Apply and check one value
13sudo sysctl --system
14sysctl net.ipv4.conf.all.accept_redirects

10Обнаружение: как узнать, что слой защиты не сработал

Предотвращение рано или поздно даёт сбой, поэтому заранее планируйте, как это заметить. Отправляйте логи за пределы сервера (пересылка journald, Loki или облачный сервис), потому что атакующий с root первым делом правит локальные логи. auditd записывает значимые для безопасности события, например изменения /etc/passwd, sudoers или SSH-ключей. Проверка целостности файлов вроде AIDE строит базу хэшей системных файлов и сообщает об изменениях; запускайте её по таймеру и храните эталонную базу вне хоста. У патчинга тоже есть сторона обнаружения. unattended-upgrades устанавливает исправления, но работающие процессы держат старые библиотеки в памяти до перезапуска: needrestart их показывает, а /var/run/reboot-required сообщает, что новое ядро ждёт перезагрузки. Ubuntu Pro, бесплатная для небольшого числа личных машин, добавляет Livepatch для исправлений ядра без перезагрузки и Ubuntu Security Guide для автоматических профилей CIS или DISA-STIG. Ставьте алерты на новых sudo-пользователей, новые записи в authorized_keys и неожиданные слушающие порты.

1# Watch changes to identity and SSH files
2sudo apt install -y auditd
3sudo auditctl -w /etc/passwd -p wa -k identity
4sudo auditctl -w /etc/sudoers.d -p wa -k sudoers
5sudo auditctl -w /home/your_user/.ssh/authorized_keys -p wa -k sshkeys
6sudo ausearch -k sshkeys --start today
7 
8# Services still running old libraries, and pending reboot
9sudo needrestart -r l
10[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs