Чеклист глубокой настройки сервера перед продакшеном

от

“Каждый раз, когда вы настраиваете сервер, вы думаете, что всё делаете правильно. А потом, под нагрузкой, начинают всплывать проблемы, которые можно было бы предотвратить на этапе первичной конфигурации. Стандартные гайды часто упускают детали, критичные для работы в условиях российских регуляторных требований и типичных инфраструктурных решений. Этот чеклист — не перечень очевидных шагов, а свод практик, которые закрывают уязвимости, влияющие на стабильность, безопасность и соответствие 152-ФЗ и требованиям ФСТЭК.”

Базовый аудит и документация

Первое, что часто игнорируют — системный подход к аудиту. Новый сервер, это не просто машина с установленной ОС. Это объект учета, элемент инфраструктуры, который должен быть однозначно идентифицирован.

  • Уникальный инвентарный номер (asset tag): Сервер должен иметь уникальный идентификатор в системе управления конфигурациями (CMDB). Этот номер привязывается к серийному номеру оборудования, MAC-адресам и доменному имени.
  • Базовая документация: Фиксируйте роль сервера (web, БД, файловое хранилище), ответственного администратора, зону размещения (DMZ, внутренний сегмент), список критичных сервисов и портов. Это основа для любого последующего аудита ФСТЭК.
  • Сбор системной информации: Зафиксируйте точные версии ядра, дистрибутива, аппаратной платформы. Используйте для этого скрипты, а не ручной ввод. Результат сохраняйте в защищённое хранилище логов.

Сетевая изоляция и конфигурация

Неправильная сетевая настройка — самая частая причина инцидентов. Речь не только о firewalld или iptables.

Сегментация и правила доступа

Настройка межсетевого экрана должна быть документирована политикой «минимальных привилегий». Для каждого сервиса явно прописываются разрешённые порты, протоколы и исходные IP-адреса или подсети. Все остальные соединения блокируются по умолчанию. Особое внимание — управляющим портам (SSH, RDP, Web-интерфейсы). Их доступ должен быть ограничен jump-хостами или административными подсетями.

Отключение неиспользуемых сетевых функций

В ядре Linux и сетевых стеках часто по умолчанию включены протоколы, которые не нужны в продакшене и могут быть использованы для атак (например, ICMP redirects, source routing). Отключите их на уровне sysctl.

# Пример критичных параметров net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_ra = 0

Управление учётными записями и аутентификацией

Стандартный совет «отключить root-логин» поверхностен. Нужен комплексный подход к управлению доступом.

  • Централизованная аутентификация: Интеграция с LDAP, FreeIPA или AD для учёта администраторов обязательна. Локальные учётные записи — только для системных сервисов.
  • Настройка PAM-модулей: Жёстко ограничьте количество попыток входа и время блокировки при неудачных попытках. Настройте использование модуля pam_faillock или pam_tally2.
  • Принудительный ротор паролей для локальных аккаунтов: Даже если они редко используются, установите политику истечения срока действия пароля через chage.
  • Безпарольный sudo: Для автоматизации разрешите определённым учётным записям выполнять конкретные команды через sudo без запроса пароля, но только с предварительной аутентификацией по SSH-ключу. Это безопаснее, чем хранение паролей в скриптах.

Настройка мониторинга и логирования

Сервер без мониторинга и централизованного сбора логов — «чёрный ящик». Это прямое нарушение требований к контролю безопасности.

Агенты мониторинга

Установите и настройте агенты систем мониторинга (например, Zabbix-agent, Prometheus node_exporter). Собирайте не только загрузку CPU и RAM, но и более тонкие метрики: давление ввода-вывода (IO pressure), потребление inodes, состояние RAID-массивов, заполнение журналов systemd.

Настройка журналирования

Перенастройте rsyslog или systemd-journald для отправки логов на выделенный log-сервер (систему управления событиями безопасности – SIEM). Критично передавать логи аутентификации (auth, authpriv), команд оболочки (through auditd) и системных ошибок. Убедитесь, что время на сервере синхронизировано с единым источником (NTP, Chrony).

# Пример конфигурации rsyslog для отправки логов на центральный сервер *.* @192.0.2.10:514

Обновление и управление пакетами

Автоматическое обновление всех пакетов («yum update -y») в продакшене — путь к нестабильности. Нужна управляемая политика.

  • Фиксация репозиториев: Используйте стабильные, версионированные репозитории, а не «latest». Настройте локальное зеркало для контроля и скорости.
  • Тестовый стенд: Все обновления, особенно ядра и критичных библиотек (glibc, openssl), должны предварительно тестироваться на идентичной тестовой среде.
  • Исключение пакетов: Явно исключите из автоматического обновления пакеты, от которых зависит ваше приложение, если их версия жёстко зафиксирована.
  • Автоматизация с проверкой: Используйте не просто cron-задачу, а системы управления конфигурациями (Ansible, SaltStack) для применения обновлений безопасности, которые предварительно утверждены.

Конфигурация служб и демонов

Стандартные конфиги служб из репозиториев редко соответствуют требованиям безопасности.

Принцип минимальных привилегий

Запускайте каждую службу от отдельного непривилегированного пользователя и группы. Изолируйте её файловую систему с помощью chroot, systemd namespace или, в идеале, контейнеризации. Удалите или закройте доступ ко всем ненужным модулям и функциям службы (например, неиспользуемые модули Apache или Nginx).

Защита от переполнения ресурсов

Настройте лимиты через systemd (MemoryLimit, CPUQuota) или PAM (limits.conf) для предотвращения DoS-атак, когда одна служба исчерпывает все ресурсы сервера.

[Service]
MemoryLimit=512M
CPUQuota=75%

Файловая система и точки монтирования

Типичные схемы разметки дисков (/, /home, /var) устарели. Современный подход учитывает отказоустойчивость, производительность и безопасность.

  • Выделение /var/log: Монтируйте каталог для логов на отдельный раздел или диск. Это предотвратит ситуацию, когда переполненные логи заполнят корневую файловую систему и «положат» сервер.
  • Опции монтирования: Для системных разделов используйте опции noexec (запрет выполнения бинарников) и nosuid (игнорирование SUID-битов). Для разделов с данными может быть полезна nodev (игнорирование специальных файлов устройств).
  • Квотирование дискового пространства: Настройте дисковые квоты для пользовательских каталогов, если сервер используется для хранения файлов. Это простая, но эффективная мера.

Безопасность ядра и контроль процессов

Возможности ядра Linux можно и нужно ограничивать для снижения поверхности атаки.

  • Настройка sysctl: Помимо сетевых параметров, установите kernel.dmesg_restrict=1 (ограничение доступа к логам ядра), kernel.kptr_restrict=2 (сокрытие адресов ядра).
  • Использование средств контроля доступа: Рассмотрите настройку SELinux в режиме Enforcing или AppArmor для профилирования критичных служб. Даже базовые предустановленные политики блокируют множество векторов атак.
  • Отключение ненужных модулей ядра: Выгрузите модули для неиспользуемого оборудования (например, Bluetooth, неиспользуемые драйверы сетевых карт).

Резервное копирование конфигурации

Конфигурацию сервера нельзя восстанавливать по памяти. Автоматизируйте процесс бэкапа.

  • Выделите критичные конфиги: Каталоги /etc, /root/.ssh/ (публичные ключи), списки установленных пакетов, конфигурация сетевых интерфейсов и правила межсетевого экрана.
  • Версионирование: Используйте Git для хранения конфигурационных файлов. Сервер может «падать», но репозиторий с его конфигами должен быть доступен. Это также даёт историю изменений.
  • Проверка восстановления: Периодически проверяйте, что из бэкапа можно развернуть рабочую конфигурацию на чистой системе.

Заключительное тестирование и нагрузка

Перед сдачей в эксплуатацию сервер должен пройти финальную проверку.

  • Сканирование уязвимостей: Проведите внутреннее сканирование утилитами вроде OpenVAS или Lynis для выявления очевидных проблем в конфигурации.
  • Нагрузочное тестирование: Сымитируйте ожидаемую нагрузку на сервисы. Это выявит проблемы с лимитами процессов, файловыми дескрипторами и сетевыми соединениями, которые не видны в простое.
  • Проверка отказоустойчивости: В контролируемом окне попробуйте «уронить» зависимые сервисы (БД, кэш) или переполнить диск с логами. Убедитесь, что основное приложение ведёт себя предсказуемо (например, переходит в режим graceful degradation, а не просто падает).

Интеграция с регуляторными требованиями (152-ФЗ, ФСТЭК)

Многие из перечисленных шагов напрямую соответствуют требованиям регуляторов. Оформите это документально.

  • Сопоставление с мерами защиты: Например, настройка аудита (auditd) и централизованного сбора логов покрывает требование о регистрации событий безопасности. Политика паролей и блокировки при неудачных попытках входа — меры по управлению доступом.
  • Документация для аудита: Подготовьте краткий отчёт по серверу, где каждый пункт чеклиста подтверждён выводом команды или ссылкой на конфигурационный файл. Это сэкономит время при проверке.
  • Учёт в реестре ИСПДн: Если сервер обрабатывает персональные данные, убедитесь, что он внесён в соответствующий реестр информационных систем, и его конфигурация соответствует утверждённой модели угроз.

Оставьте комментарий