Hardening baseline

Hardening baseline — минимальный и повторяемый набор настроек, который снижает поверхность атаки сервера. Он не заменяет модель угроз, полноценный аудит или требования конкретного стандарта, но задаёт единый уровень защиты для серверов одной роли.

Примеры команд ниже ориентированы в основном на Debian/Ubuntu с systemd. Перед изменениями проверьте дистрибутив, зависимости приложений, наличие резервной консоли и возможность отката.

Важно: не отключайте службы и не меняйте доступ вслепую. Сначала соберите инвентаризацию, сохраните конфигурацию и протестируйте изменения на отдельном узле.

Содержание

• Модель базовой защиты
• Чек-лист безопасности сервера
• Инвентаризация
• Отключение ненужных сервисов
• SSH и удалённый доступ
• Firewall и порты
• Fail2ban
• Обновления безопасности
• Аудит конфигурации и CIS Benchmarks
• Минимизация прав
• Логи, секреты и контроль изменений
• Автоматизация baseline
• Порядок внедрения
• Итоговый чек-лист
• Шпаргалка команд

Модель базовой защиты

Безопасность сервера удобно строить в несколько уровней:

1. Инвентаризация — известны пользователи, пакеты, службы, порты и задачи планировщика.
2. Минимизация поверхности — ненужные компоненты отключены, удалены или недоступны по сети.
3. Контроль доступа — применяются SSH-ключи, firewall и принцип наименьших привилегий.
4. Актуальность — установлены исправления безопасности, а устаревшие компоненты удалены.
5. Обнаружение — ведутся логи, настроены уведомления и защита от массового перебора.
6. Проверяемость — состояние сверяется с baseline, изменения документируются и могут быть откачены.

Hardening должен быть повторяемым. Ручная настройка без документации со временем приводит к расхождениям между серверами.

Чек-лист безопасности сервера

Учётные записи и доступ

• Создан отдельный административный пользователь.
• Вход по SSH-ключу проверен из новой сессии.
• Прямой вход для root запрещён.
• Парольная аутентификация SSH отключена после проверки ключей.
• Удалены неиспользуемые пользователи, группы и ключи.
• Административные действия выполняются через sudo.
• MFA используется для VPN, bastion host, облачной консоли или IdP, если это возможно.

Сервисы и сеть

• Запущенные службы инвентаризированы.
• Неиспользуемые службы и пакеты отключены или удалены.
• Открыты только необходимые порты.
• Firewall включён и протестирован.
• Административные порты ограничены VPN или доверенными сетями.
• Приложения не слушают 0.0.0.0, если публичный доступ не нужен.
• Не используются Telnet, FTP и другие незашифрованные протоколы без обоснования.

ОС и эксплуатация

• Используется поддерживаемая версия ОС.
• Установлены security updates.
• Определён процесс регулярного обновления.
• Контролируется необходимость перезагрузки.
• Время синхронизируется через NTP/chrony/systemd-timesyncd.
• Есть резервные копии и проверено восстановление.
• Настроены логи, ротация и уведомления.

Инвентаризация

До изменения конфигурации сохраните текущее состояние.

ОС, пакеты и ядро

cat /etc/os-release
uname -a
hostnamectl
dpkg-query -W -f='${binary:Package}	${Version}
' 2>/dev/null
rpm -qa 2>/dev/null

Сервисы и порты

systemctl --type=service --state=running
systemctl list-unit-files --type=service --state=enabled
sudo ss -tulpen

Каждый слушающий порт должен иметь владельца, назначение и разрешённый источник трафика.

Пользователи и группы

getent passwd
getent group
getent group sudo 2>/dev/null
awk -F: '$7 !~ /(nologin|false)$/ {print $1, $6, $7}' /etc/passwd

Планировщики и mounts

systemctl list-timers --all
sudo ls -la /etc/cron.* /var/spool/cron/crontabs 2>/dev/null
findmnt

Результаты сохраните в отчёте: он нужен для сравнения до и после hardening и для поиска drift — неожиданных изменений.

Отключение ненужных сервисов

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

Проверка зависимостей

systemctl status имя-сервиса
systemctl list-dependencies имя-сервиса
systemctl list-dependencies --reverse имя-сервиса
dpkg -S /usr/lib/systemd/system/имя-сервиса.service 2>/dev/null
rpm -qf /usr/lib/systemd/system/имя-сервиса.service 2>/dev/null

Остановка и отключение

sudo systemctl stop имя-сервиса
sudo systemctl disable имя-сервиса
sudo systemctl is-enabled имя-сервиса
sudo systemctl is-active имя-сервиса

mask не позволяет запускать службу вручную или через зависимость:

sudo systemctl mask имя-сервиса

Используйте его только после проверки: mask может сломать другой компонент.

Если пакет не нужен вообще:

sudo apt remove имя-пакета
sudo apt autoremove

Проверяемые категории: старые сетевые протоколы, печать на сервере без принтера, графические компоненты headless-сервера, тестовые приложения, неиспользуемые агенты и legacy-службы после миграции. Универсального списка отключения не существует: baseline зависит от роли узла.

SSH и удалённый доступ

Ошибка в SSH-конфигурации может закрыть доступ администраторам. Работайте через отдельную текущую сессию и заранее проверьте аварийную консоль.

Резервная копия и проверка

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
sudo sshd -t
sudo systemctl reload ssh

В некоторых системах служба называется sshd.

Базовые параметры

Фрагмент /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
X11Forwarding no
AllowAgentForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Отключайте PasswordAuthentication только после проверки входа по ключу из новой сессии. Доступ можно ограничить группой:

AllowGroups sshusers

Права на ключи:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$USER" ~/.ssh

Публичные ключи удаляйте при отзыве доступа. Приватные ключи не должны храниться на сервере без необходимости.

Firewall и порты

Рекомендуемая базовая политика — запрет входящих соединений по умолчанию и явное разрешение нужных портов. В облаке дополнительно проверяйте security groups и network ACL.

UFW

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

Перед включением добавьте правило SSH, иначе можно потерять удалённый доступ.

firewalld

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Проверяйте доступность только собственных систем:

nc -vz example.com 22
nc -vz example.com 443

Firewall уменьшает число доступных точек входа, но не заменяет обновления, аутентификацию и безопасную конфигурацию разрешённых сервисов.

Fail2ban

Fail2ban анализирует логи и временно блокирует адреса, с которых повторяются подозрительные действия, например неудачные попытки SSH-входа. Это дополнительный слой защиты, а не замена ключам, MFA и firewall.

Установка и проверка

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Локальная конфигурация

Не редактируйте поставляемый jail.conf. Создайте /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
ignoreip = 127.0.0.1/8 ::1 203.0.113.10

[sshd]
enabled = true
port = 22
logpath = %(sshd_log)s
maxretry = 5

Проверка после изменения:

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client get sshd banip

Разблокировка адреса:

sudo fail2ban-client set sshd unbanip 198.51.100.25

Ошибочный ignoreip может разрешить атаку. NAT и прокси могут привести к блокировке адреса, общего для многих пользователей. Убедитесь, что фильтр читает правильный журнал и action действительно меняет правила firewall.

Обновления безопасности

Исправления нужны для ядра, библиотек, runtime и прикладных пакетов. После обновления процесс может продолжать использовать старую библиотеку до перезапуска.

Debian/Ubuntu

sudo apt update
apt list --upgradable
sudo apt upgrade
test -f /var/run/reboot-required && echo "Требуется перезагрузка"

RHEL-подобные системы

sudo dnf check-update
sudo dnf update --security

Автоматические обновления через unattended-upgrades:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Процесс обновления должен учитывать окно обслуживания, staging, резервные копии, перезагрузки, уведомления и план отката. Для поиска процессов со старыми библиотеками можно использовать needrestart:

sudo apt install needrestart
sudo needrestart

Важно не только установить пакет, но и подтвердить версию, состояние сервиса и отсутствие ошибок после обновления.

Аудит конфигурации и CIS Benchmarks

CIS Benchmarks — рекомендации по безопасной настройке ОС, сервисов, облачных платформ и других продуктов. Они не являются универсальным скриптом hardening и не гарантируют абсолютную безопасность.

Обычно используются два уровня:

• Level 1 — базовые настройки с небольшим влиянием на совместимость.
• Level 2 — более строгие настройки для систем с повышенными требованиями; они могут повлиять на функциональность.

Типичные проверки:

• политика паролей и блокировки;
• права системных файлов;
• SSH и firewall;
• аудит событий и журналирование;
• ротация логов;
• параметры ядра и загрузчика;
• разрешения sudo;
• синхронизация времени;
• ненужные файловые системы и протоколы.

OpenSCAP

Доступные профили зависят от дистрибутива и установленного content-файла:

sudo oscap info /path/to/content.xml
sudo oscap xccdf eval   --profile xccdf_org.ssgproject.content_profile_standard   --results results.xml   --report report.html   /path/to/content.xml

Lynis

sudo lynis audit system

Рекомендации Lynis и CIS нужно оценивать в контексте роли узла. Не применяйте все исправления автоматически: часть настроек может нарушить работу приложения.

Результаты удобно оформлять так:

Ценность аудита — в управлении отклонениями, а не только в проценте соответствия.

Минимизация прав

Принцип наименьших привилегий означает, что пользователь, процесс и сервис получают только необходимые разрешения.

Отдельный пользователь сервиса

sudo useradd --system --home-dir /nonexistent   --shell /usr/sbin/nologin --no-create-home app
sudo install -d -o app -g app -m 0750 /opt/app

Приложение не должно запускаться от root, если это не требуется архитектурой.

Ограниченный sudo

sudo -l -U admin
sudo visudo

Избегайте:

admin ALL=(ALL) NOPASSWD: ALL

Лучше разрешить конкретную команду:

%deployers ALL=(root) /usr/bin/systemctl restart myapp.service

Даже ограниченную команду нужно проверять на shell escape и небезопасные параметры.

Права на файлы

sudo chown root:root /etc/myapp/config.yml
sudo chmod 0640 /etc/myapp/config.yml
sudo chown app:app /etc/myapp/secret.env
sudo chmod 0600 /etc/myapp/secret.env
sudo find /etc /opt /usr/local -xdev -type f -perm -0002 -ls

Результаты find анализируйте вручную: некоторые файлы могут быть намеренно доступны для записи.

Systemd sandboxing и capabilities

Для сервисов можно рассмотреть:

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/myapp

После изменения:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

Параметры могут сломать приложение, поэтому включайте их поэтапно. Проверка capabilities:

getcap /path/to/binary
sudo getpcaps PID

Не выдавайте широкие capabilities, например CAP_SYS_ADMIN, без подтверждённой необходимости.

Логи, секреты и контроль изменений

Логируйте входы, изменения пользователей и sudo, запуск служб, изменения конфигурации, ошибки приложений, события firewall и Fail2ban, установку пакетов и перезагрузки.

sudo journalctl -p warning..alert -b
sudo journalctl -u ssh --since today
sudo journalctl -u fail2ban --since today
sudo journalctl --disk-usage

Настройте размер journal, срок хранения, ротацию и отправку в централизованное хранилище. Логи на том же сервере не должны быть единственным доказательством.

Не храните пароли и токены в публичных репозиториях, командной строке, образах контейнеров, world-readable-файлах и логах. Используйте secret manager или защищённые переменные CI/CD. Секрет, который уже попал в Git или лог, нужно заменить.

Для важных конфигураций используйте Git с ограниченным доступом, систему управления конфигурацией или контроль целостности. Эталонные значения храните отдельно от проверяемого сервера.

Автоматизация baseline

Ручная настройка плохо масштабируется. Для повторяемых серверов используйте Ansible, cloud-init или другой управляемый способ конфигурации.

Пример Ansible-задач:

- name: Disable SSH root login
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^#?PermitRootLogin'
    line: 'PermitRootLogin no'
    validate: '/usr/sbin/sshd -t -f %s'
  notify: Reload ssh

- name: Enable fail2ban
  ansible.builtin.service:
    name: fail2ban
    state: started
    enabled: true

Для baseline важны idempotency, проверка конфигурации до перезапуска, тестирование на staging, review, журналирование изменений и отдельные исключения для разных ролей.

В baseline как код обычно описывают разрешённые порты, пакеты и службы, пользователей, SSH, firewall, мониторинг, логирование и срок действия исключений.

Порядок внедрения

1. Подготовка

Определите назначение и владельца сервера, зависимости, окно работ, аварийный доступ и резервное копирование.

2. Инвентаризация

Соберите пользователей, пакеты, службы, порты, cron-задачи, mounts и внешние подключения.

3. Административный доступ

Создайте администратора, добавьте ключ, проверьте новую сессию и только затем ограничивайте root и парольную аутентификацию.

4. Минимизация поверхности

Отключите ненужные службы, удалите лишние пакеты, ограничьте firewall и назначьте владельца каждому открытому порту.

5. Обновление

Установите исправления, проверьте необходимость перезагрузки и работоспособность приложений.

6. Защита и логи

Настройте Fail2ban при необходимости, ротацию, централизованный сбор логов и уведомления.

7. Аудит

Запустите CIS-профиль, OpenSCAP, Lynis или эквивалентный аудит. Разберите предупреждения и задокументируйте исключения.

8. Автоматизация

Закрепите состояние в коде и периодически выполняйте повторную проверку и drift detection.

Итоговый чек-лист

[ ] Назначение и владелец сервера определены
[ ] Есть аварийный доступ и резервная копия
[ ] Используется поддерживаемая версия ОС
[ ] Security updates установлены
[ ] Ненужные пакеты и сервисы отключены
[ ] Список открытых портов утверждён
[ ] Firewall настроен по принципу deny by default
[ ] SSH-ключи проверены из новой сессии
[ ] Прямой вход root запрещён
[ ] Парольный SSH-доступ отключён или документирован как исключение
[ ] Административные действия выполняются через sudo
[ ] Сервисы работают от отдельных пользователей
[ ] Секреты и конфигурации имеют ограниченные права
[ ] Fail2ban настроен при необходимости
[ ] Логи собираются и ротируются
[ ] Время синхронизируется
[ ] Настроен мониторинг диска, процессов и сервисов
[ ] Выполнен аудит CIS/Lynis/OpenSCAP
[ ] Отклонения и исключения документированы
[ ] Baseline автоматизирован
[ ] Восстановление из резервной копии протестировано

Шпаргалка команд

Заключение

Hardening baseline — это управляемый процесс, а не единоразовая настройка. Минимальный результат включает инвентаризацию, ограниченный набор служб и портов, безопасный SSH, актуальные обновления, минимальные права, логи, аудит и возможность восстановления.

Хороший baseline можно автоматически применить, проверить, объяснить и откатить. Каждое исключение должно иметь владельца, причину, срок пересмотра и компенсирующие меры защиты.