Как безопасно усилить защиту Linux-сервера в 2026 году

Tue Sep 01 2026

Как безопасно усилить защиту Linux-сервера в 2026 году

В Linux нет централизованной консоли, из которой можно применить 250 настроек безопасности к 400 серверам. Плоский список из 50 шагов по усилению защиты оставляет работу без четких ориентиров. Начните с мер, которые снижают риск несанкционированного доступа, а затем переходите к более глубоким ограничениям системы.

Защитите Linux-сервер, сопоставив CIS benchmark с его операционной системой. Защитите SSH и повышение привилегий, ограничьте сетевую доступность, примените совместимые настройки файловой системы и ядра, установите патчи на хост, передавайте события аудита в SIEM и проверяйте работоспособность сервисов после каждой группы изменений.

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

В этой статье

Усиление защиты Linux — это управление конфигурацией, а не поиск настроек
Выберите benchmark, соответствующий операционной системе
Защитите SSH до изменения настроек ядра
Защитите пути, ведущие к root
Закройте ненужные сетевые пути
Осторожно усильте защиту временных файловых систем
Используйте sysctl для понятных вам мер контроля
Установите патчи на хост, затем внедрите протестированный профиль
Передавайте события аудита, чтобы использовать их для обнаружения
Что это сломает на реальном сервере?
Проверяйте сервер, а не объявляйте победу

Усиление защиты Linux — это управление конфигурацией, а не поиск настроек

Усиление защиты Linux охватывает настройки пакетов, менеджеры сервисов, файлы аутентификации, модули безопасности, разрешения и параметры ядра. Владение настройками важнее запоминания имен файлов.

Храните профиль для каждого сервера. Фиксируйте его роль и необходимые сервисы. Добавляйте одобренные меры контроля, исключения, шаги отката и свидетельства проверки. Системы семейств Debian и RHEL требуют отдельных процедур, а в большом масштабе — отдельных Ansible-ролей. Настройка, скопированная из руководства для RHEL, может быть неправильной для Debian, даже если имя файла выглядит знакомо.

Выполняйте работу в следующем порядке:

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

Оставляйте SELinux в режиме enforcing на системах семейства RHEL и включайте AppArmor на Ubuntu или Debian, если для приложения существует рабочий профиль. Тестируйте политики до их перевода в режим enforcing.

Наш подход намеренно скучен: небольшие группы изменений, зафиксированные действия и протестированный путь восстановления. Это лучше, чем собирать shell-команды из несовместимых чеклистов.

Выберите benchmark, соответствующий операционной системе

CIS Benchmarks дают правильную исходную структуру для усиления защиты Linux-сервера. Портал CIS Benchmark предлагает PDF-файлы benchmark бесплатно для некоммерческого использования.

Какие версии Linux представлены в списке 2026 года?

Платформа	Версия benchmark
AlmaLinux OS 8	4.0.0
AlmaLinux OS 9	3.0.0
AlmaLinux OS 10	1.0.0
Amazon Linux 2	4.0.0
Amazon Linux 2023	1.0.0
Debian Linux 11	2.0.0
Debian Linux 12	2.0.0
Debian Linux 13	1.1.0
Ubuntu 22.04	3.0.0
RHEL 10 STIG	1.0.0

Активность выпуска в 2026 году включает поддержку Debian 13 и Ubuntu 22.04, а RHEL 10 STIG 1.0.0 появился в течение года. В обновлении CIS за январь 2026 года зафиксирована дополнительная активность по новым и пересмотренным benchmark.

Для большинства производственных систем начните с Level 1. Переходите к Level 2, когда требования безопасности оправдывают более жесткие ограничения и приложение прошло тестирование. CIS — это базовый уровень, а не скрипт развертывания в production.

Benchmark дает вам обоснованный набор мер контроля. Он не знает, требуется ли вашему агенту мониторинга читать логи Nginx или зависит ли PostgreSQL от определенного ограничения shared memory.

Защитите SSH до изменения настроек ядра

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

Предположим, что это production-хост Ubuntu или Debian, на котором работают Nginx, PostgreSQL и агент мониторинга, а администрирование выполняет небольшая операционная команда через SSH.

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

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 4
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 3
AllowGroups ssh-admins
Banner /etc/issue.net

PermitRootLogin no убирает прямой удаленный вход root. PasswordAuthentication no убирает аутентификацию по паролю через SSH после того, как доступ по ключу заработал. AllowGroups ограничивает доступ по SSH одобренными учетными записями; используйте AllowUsers, когда больше подходит явный список пользователей.

Настройки keepalive задают предполагаемую политику активности: проверять неактивное соединение каждые 300 секунд и закрывать его после трех проверок без ответа. Проверяйте фактическую конфигурацию, особенно когда подключаемые файлы или drop-in-файлы могут переопределять основной файл.

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

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256,hmac-sha2-512
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256

Перед развертыванием проверьте каждый алгоритм на установленной версии OpenSSH и в парке клиентов. Список шифров, из-за которого вы теряете единственный административный клиент, — это мера безопасности с плохим операционным решением. Banner /etc/issue.net поддерживает юридические уведомления или уведомления о соответствии требованиям; это не граница безопасности.

Проверьте конфигурацию с помощью sshd -t, откройте новое соединение и протестируйте административный доступ. Перезагружайте OpenSSH через менеджер сервисов вашего дистрибутива только после успешного прохождения обеих проверок. Сохраняйте существующую сессию, пока новая не заработает.

Защитите пути, ведущие к root

В рассматриваемых здесь системах root по-прежнему является частью модели привилегий. Защитите пути, ведущие к нему.

Используйте именованные учетные записи людей и требуйте sudo. Ограничьте членство в административных группах. Проверьте, какие команды может выполнять каждый администратор. Разделяйте человеческие идентификаторы и сервисные учетные записи. Nginx, PostgreSQL, резервное копирование и мониторинг должны работать под минимально привилегированными идентификаторами, необходимыми для их задач.

Аудитируйте выполнение sudo и изменения политики sudo. SSH контролирует вход; sudo контролирует действия аутентифицированного пользователя после входа. Проверяйте обе границы.

Будьте осторожны с pam_faillock. Блокировка может сократить число повторных интерактивных попыток аутентификации, но одновременно заблокировать автоматизированную сервисную учетную запись после устаревших учетных данных или неудачного задания. Ограничьте ее интерактивными PAM-сервисами, такими как SSH и login, а затем отдельно протестируйте запланированные задачи.

Закройте ненужные сетевые пути

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

Определите слушающие сервисы и их владельцев. Документируйте необходимые исходные сети и оставьте аварийный доступ для SSH. Затем примените политику allow-list. После этого проверьте доступность из отдельной административной сессии.

После определения необходимых разрешений запретите нежелательный входящий трафик по умолчанию. Выберите инструмент межсетевого экрана, соответствующий дистрибутиву и существующей инфраструктуре. UFW, nftables и iptables имеют законные варианты применения, но смешивание фреймворков на одном хосте делает ответственность неясной.

Для примерного хоста Nginx может требовать публичного доступа, тогда как PostgreSQL и мониторинг должны принимать соединения только из одобренных сетей. Конкретные порты и сети должны находиться в вашем инвентаре.

Отключение IPv6 только потому, что так сказано в чеклисте, является имитацией безопасности, пока вы не проверили, какие сервисы слушают этот протокол. Приложения Java, Redis и некоторые слушатели баз данных могут по умолчанию привязываться к IPv6. Сначала проверьте слушающие сервисы и маршруты. Проверьте также клиентов. Защитите IPv6 наряду с IPv4 или отключайте его только тогда, когда рабочая нагрузка подтверждает, что он не используется.

Осторожно усильте защиту временных файловых систем

Эти параметры часто имеют ограниченное влияние, но production-хост все равно может зависеть от выполнения, доступа к устройствам или поведения SUID в этих путях. Перед развертыванием протестируйте каждую точку монтирования.

Если совместимость это позволяет, задайте noexec, nosuid и nodev для /tmp, /dev/shm и /var/tmp в /etc/fstab.

noexec блокирует выполнение бинарных файлов из точки монтирования.
nosuid предотвращает выполнение set-user-ID и set-group-ID в ней.
nodev не позволяет использовать в ней файлы устройств.

Тестируйте установщики и средства запуска приложений, использующие эти каталоги. Также тестируйте агенты и запланированные задания.

Для управляемых PAM-сессий, которым не нужны core dumps, используйте такие ограничения:

* hard core 0
* soft core 0

Core-файлы могут содержать учетные данные, ключи и данные приложения. Это ограничивает управляемые PAM-сессии; правило может не распространяться на каждый демон, управляемый systemd. Отдельно проверьте фактический лимит демона.

Проверьте ASLR с помощью:

kernel.randomize_va_space = 2

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

Рассматривайте umask 027 как решение, зависящее от совместимости. На примерном хосте проверьте, может ли агент мониторинга по-прежнему читать логи Nginx. Убедитесь, что приложения могут создавать необходимые временные файлы, socket-файлы или PID-файлы.

Используйте sysctl для понятных вам мер контроля

Vucense описывает усиление защиты через sysctl как область Level 1 с большим эффектом и небольшими затратами. Это поддерживает отдельные меры контроля, а не универсальный файл ядра, который следует развертывать повсюду.

Используйте net.ipv4.tcp_syncookies=1 как пример для оценки относительно выбранного benchmark и рабочей нагрузки. Не называйте любое отдельное значение sysctl универсально безопасным.

Ограничения ядра, скопированные из общего benchmark для хоста базы данных, переоцениваются. Значения вроде kernel.shmmax, kernel.shmall и kernel.sem зависят от конфигурации базы данных и требований производителя. Перед изменением любого из них зафиксируйте предыдущее значение и определите путь отката.

Отключение transparent huge pages — одна из областей, где рекомендации CIS и производители баз данных, включая MongoDB, Redis и Oracle, указывают в одном направлении (для контейнеров см. наш гид по защите Docker-контейнеров в продакшене). Однако точный операционный метод и влияние по-прежнему требуют проверки для конкретной базы данных.

Установите патчи на хост, затем внедрите протестированный профиль

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

Утверждение «менее 30 минут» относится к свежему серверу Ubuntu и узкому проходу Level 1 по пяти областям. Оно мало что говорит о production-хосте с зависимостями приложений.

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

Для развертывания в парке серверов внедряйте протестированный профиль через отдельные Ansible-роли для семейств Debian и RHEL. Применяйте меры контроля пакетами, проверяйте исключения и выпускайте роль в production только после того, как профиль пройдет проверки сервисов.

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

Сам по себе auditd, работающий на сервере, не является стратегией обнаружения. Если злоумышленник может очистить локальный журнал, улучшение в основном косметическое; передавайте события в SIEM.

«Защищенный сервер без настроенного auditd дает улучшения в части соответствия требованиям, но ограниченные возможности обнаружения. auditd с правильным набором правил превращает защищенный сервер в систему обнаружения».

В первую очередь отслеживайте выполнение привилегированных команд и изменения в /etc/passwd, /etc/shadow, /etc/sudoers и /etc/sudoers.d/. Также охватите политику sudo и аутентификацию. Включите su, входы по SSH и создание сетевых сокетов.

Представительные правила включают:

-a always,exit -F arch=b64 -F euid=0 -S execve
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa
-w /etc/sudoers.d/ -p wa
-a always,exit -F arch=b64 -S socket

Не копируйте этот блок как полный production-профиль. Синтаксис правил, охват архитектур, сохранение настроек и выбранный профиль CIS должны соответствовать хосту. -S socket может создавать значительный объем событий, поэтому намеренно расставляйте приоритеты и настраивайте ограничения скорости.

Передавайте данные через dispatcher auditd или плагин audisp-syslog в поддерживаемый хостом транспорт syslog, а затем в SIEM. Точный путь зависит от дистрибутива. Подтвердите его:

auditd → audit dispatcher or plugin → supported syslog transport → SIEM

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

Что это сломает на реальном сервере?

Рассматривайте эту таблицу как проверку перед изменением: найдите меру контроля, определите зависимый сервис и напишите тест до изменения настройки.

Мера контроля	Вероятный отказ	Более безопасная реакция
`umask 027`	Мониторинг не может читать логи Nginx или Apache; приложения теряют ожидаемый доступ к временным файлам, socket-файлам или PID-файлам.	Протестируйте создание файлов и разрешения на чтение для каждого сервиса; при необходимости задайте umask точечно.
`pam_faillock`	Автоматизированная сервисная учетная запись блокируется.	Применяйте блокировку к интерактивным сервисам, таким как SSH и login; автоматизацию тестируйте отдельно.
Отключение IPv6	Java, Redis или слушатель базы данных перестает работать, поскольку по умолчанию привязывается к IPv6.	Проверьте слушающие сервисы и клиентов; защитите IPv6 или отключайте его только при наличии подтверждения.
Ограничение `kernel.shmmax` или `kernel.shmall`	PostgreSQL может не запуститься.	Проверьте требуемый объем shared memory относительно `shared_buffers` и накладных расходов, затем протестируйте запуск с учетом механизма памяти и конфигурации хоста.
Ограничение `kernel.sem`	Документированные Oracle требования к семафорам конфликтуют со значениями benchmark.	Следуйте инструкциям Oracle по установке и зафиксируйте исключение из benchmark.
`nosuid` на `/var`	Необычная установка базы данных, зависящая от SUID-бинарных файлов в `/var`, перестает работать.	Проверьте структуру установки до применения ограничения точки монтирования.

Профиль Level 1 примерно из 250 мер контроля, примененный без тестирования рабочей нагрузки, предсказуемо сломает production-системы — часто из-за неудачного запуска или потери мониторинга, а не из-за очевидного сбоя. Зеленая оценка benchmark рядом со сломанным агентом мониторинга означает, что задача по усилению защиты провалена.

Проверяйте сервер, а не объявляйте победу

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

Повторно проверьте SSH из новой сессии с проверенным административным ключом.
Убедитесь, что вход root и аутентификация по паролю ведут себя ожидаемым образом.
Сопоставьте доступность межсетевого экрана с инвентарем сервисов.
Проверьте параметры монтирования, лимиты core dumps, ASLR и одобренные значения sysctl.
Сгенерируйте или проверьте события аудита привилегированных действий, аутентификации, sudo и отслеживаемых файлов.
Убедитесь, что соответствующее событие поступает в SIEM и остается доступным для поиска.
Запустите выбранную оценку CIS и зафиксируйте обоснованные исключения.
Проверьте активное состояние в менеджере сервисов и endpoint проверки работоспособности приложения. Протестируйте подключение к базе данных и heartbeat мониторинга. Проверьте резервное копирование и автоматизацию.

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

Зафиксируйте семь артефактов: версию benchmark, фактическую конфигурацию SSH, доступность межсетевого экрана, значения параметров монтирования и sysctl, проверки сервисов, идентификатор события SIEM и одобренные исключения.

Нет артефакта — нет развертывания.