Полный чеклист для безопасной настройки нового сервера

«Создание сервера, это не просто нажатие кнопки в панели управления. Это создание нового узла в сети, который будет жить своей жизнью, собирать пыль, уязвимости и внимание злоумышленников. Стандартный чеклист из пяти пунктов не работает, потому что упускает контекст: зачем этот сервер, кто к нему придёт и что он оставит после себя. Настройка, это не про галочки, а про создание системы, которая будет устойчива к человеческим ошибкам и автоматизированным атакам.»

От идеи до машины: что нужно решить до создания

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

Назначение: Будет ли это веб-сервер, база данных, файловое хранилище или шлюз? От этого зависит выбор ОС, размер диска, объём оперативной памяти и сетевые настройки.
Масштабируемость: Планируется ли увеличение нагрузки? Если да, сразу продумайте, как будете добавлять ресурсы или создавать клоны. Использование конфигураций через код (Infrastructure as Code) или готовых образов системы (Golden Images) сэкономит время в будущем.
Изоляция: Насколько критична изоляция этого сервера от других? Возможно, его стоит разместить в отдельной подсети или даже в отдельном проекте/аккаунте облачного провайдера.
Доступ: Кто и как будет подключаться к серверу? Только из внутренней сети или нужен доступ извне? Ответ определит правила файрвола и необходимость в шлюзах.

Пропуск этого этапа ведёт к ситуации, когда сервер приходится пересоздавать или кардинально перестраивать уже под нагрузкой.

Базовый образ и первичная настройка

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

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

Обновление репозиториев и системы: Установите все доступные обновления безопасности. Для Debian/Ubuntu: apt update && apt upgrade -y. Для CentOS/RHEL/AlmaLinux: yum update -y или dnf update -y.
Настройка hostname: Задайте осмысленное имя сервера, которое будет понятно в логах и мониторинге. Например, web-prod-01 или db-backup-internal.
Создание непривилегированного пользователя: Работа от root, это прямой риск. Создайте отдельного пользователя с sudo-правами для административных задач: adduser deploy и usermod -aG sudo deploy (для Debian/Ubuntu).

Безопасность доступа: ключи, файрвол и Fail2ban

Парольная аутентификация по SSH устарела и опасна. Её следует отключить в пользу ключевой.

Настройка SSH: Отредактируйте файл /etc/ssh/sshd_config. Установите PasswordAuthentication no, PermitRootLogin no. Измените стандартный порт 22 на другой (например, 5022), это не панацея, но снизит уровень шума от автоматических сканеров. Не забудьте добавить свой публичный ключ в ~/.ssh/authorized_keys пользователя deploy перед перезагрузкой SSH.
Настройка базового файрвола: Используйте iptables, nftables или встроенный инструмент облачного провайдера. Минимальный набор правил: разрешить входящие подключения только по SSH (на выбранном порту), HTTP/HTTPS (если нужно) и, возможно, ICMP (ping). Все остальные входящие соединения должны быть по умолчанию запрещены (DROP).
Установка Fail2ban: Эта утилита анализирует логи и временно блокирует IP-адреса, с которых идёт слишком много неудачных попыток входа. Установите её и настройте под SSH: apt install fail2ban (или yum install fail2ban).

Системный мониторинг и логи

Сервер без мониторинга — чёрный ящик. Проблемы обнаруживаются только тогда, когда сервис уже не отвечает.

Базовые метрики: Установите агент для системы мониторинга (например, Zabbix-agent, Prometheus node_exporter). Он будет собирать данные о загрузке CPU, использовании RAM, дискового пространства и сети.
Логирование: Настройте централизованный сбор логов (например, в ELK-стек или Grafana Loki). Как минимум, убедитесь, что логи ротируются и не заполняют весь диск. Проверьте работу logrotate.
Оповещения: Настройте алерты на критические события: 95% заполнения диска, отсутствие отклика от сервиса, подозрительную активность в логах аутентификации.

Мониторинг, это не роскошь, а система раннего предупреждения. Его настройка на этапе ввода в эксплуатацию проще, чем в аварийной ситуации.

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

Любой сервер может выйти из строя. Вопрос не в «если», а в «когда».

Что бэкапить: Конфигурационные файлы (/etc/), данные приложений, базы данных (отдельным, специфичным для СУБД, способом), пользовательские данные.
Как бэкапить: Используйте инструменты вроде rsync, BorgBackup или Restic. Ключевые принципы: инкрементальность, шифрование, хранение нескольких поколений бэкапов.
Где хранить: Бэкапы должны храниться отдельно от основного сервера, предпочтительно в другом дата-центре или у другого провайдера.
Проверка восстановления: План без проверки, это фантазия. Регулярно (хотя бы раз в квартал) проводите учебное восстановление сервера из бэкапа на тестовом стенде. Только так можно быть уверенным, что процесс работает.

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

Если сервер обрабатывает персональные данные или критичную информацию, базовых мер недостаточно. Требуется реализовать дополнительные меры защиты.

Аудит и учёт событий безопасности: Настройте аудит с помощью auditd для отслеживания критичных событий: вход/выход пользователей, запуск привилегированных команд, доступ к важным файлам. Собранные события должны защищаться от модификации.
Защита от НСД (несанкционированного доступа): Помимо настройки SSH и файрвола, рассмотрите использование мандатного разграничения доступа (например, через SELinux в режиме Enforcing) для ограничения возможностей взломанного процесса.
Обнаружение вторжений (IDS/HIDS): Установите host-based систему обнаружения вторжений, такую как OSSEC или Wazuh. Она будет отслеживать целостность файлов (изменения в /etc/passwd, /etc/shadow, конфигах), анализировать логи и реагировать на подозрительные действия.
Шифрование дисков: Для защиты данных на случай физического доступа к диску или его изъятия используйте полное шифрование диска (LUKS) или шифрование на уровне облачного провайдера.

соответствие, это не разовая настройка, а процесс. Конфигурации должны документироваться, а меры защиты — регулярно проверяться.

Оптимизация производительности и ресурсов

После обеспечения безопасности можно заняться эффективностью работы.

Настройка свопа (swap): Даже при достаточном объёме RAM наличие свопа предотвращает аварийное завершение процессов при резком скачке потребления памяти. Настройка swappiness (/proc/sys/vm/swappiness) зависит от нагрузки.
Лимиты процессов и файловых дескрипторов: Для высоконагруженных серверов (веб-серверы, БД) увеличьте лимиты на количество файловых дескрипторов и пользовательских процессов в /etc/security/limits.conf.
Настройка сетевого стека: Для серверов, обрабатывающих много сетевых соединений (прокси, балансировщики), может потребоваться тонкая настройка параметров ядра в /etc/sysctl.conf (например, net.core.somaxconn, net.ipv4.tcp_tw_reuse).
Удаление ненужного: Отключите или удалите все неиспользуемые службы (демоны). Каждая запущенная служба, это потенциальная точка входа и потребитель ресурсов.

Документирование и финальная проверка

Сервер готов, но работа не закончена. Если действия не задокументированы, они со временем забываются.

Создание паспорта сервера: Ведите внутренний документ (базу знаний), где для каждого сервера указаны: hostname, IP-адреса, назначение, установленное ПО, учётные данные для доступа (хранимые в менеджере паролей!), ответственные, дата ввода в эксплуатацию.
Автоматизация конфигурации: Все выполненные шаги настройки должны быть записаны в виде скриптов (Ansible playbook, Bash-скрипт, Terraform-конфигурация). Это позволит воспроизвести идентичный сервер за минуты, а не за часы.
Финальный прогон чеклиста: Перед сдачей в эксплуатацию пройдитесь по всем пунктам ещё раз. Проверьте доступность сервисов, работу бэкапов, получение метрик в системе мониторинга, отсутствие открытых неиспользуемых портов.

Только после этого сервер можно считать готовым к работе в production-среде. Этот процесс кажется долгим, но он предотвращает гораздо более длительные и дорогостоящие простои в будущем.