Зачем переводить сухой регламент в работающие настройки — харденинг Linux

Регламенты по безопасности серверов часто пишут для галочки, а не для реального администратора. В три часа ночи при падении сервера нужны конкретные команды и понимание механики атак, а не общие фразы про минимизацию поверхности атаки. Разбор каждого пункта требований через реальные инциденты даёт больше, чем десятки страниц сухих формулировок. https://seberd.ru/27915

Большинство документов по защите информации читаются как перевод с иностранного языка. Красивые слова, логичная структура, ни одного конкретного шага. Администратор получает такой регламент, ставит галочку в чек-листе и идёт дальше. Через полгода сервер оказывается в ботнете, потому что никто не объяснил, почему именно этот пункт важен именно в этой инфраструктуре.

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

В подсистеме nf_tables ядра Linux обнаружена уязвимость CVE-2026-23111, которую вызвал единственный лишний символ «!» в исходном коде. Логическая ошибка в функции nf_tables_addchain() создаёт условие use-after-free, позволяющее локальному непривилегированному пользователю выполнить код в контексте ядра и получить полные привилегии root

Патч сводится к удалению этого одиночного символа, но до его выпуска миллионы систем с активным пакетным фильтром nftables оставались открытыми для полного компрометирования хоста

Почему парольная аутентификация в SSH должна быть отключена

Парольная аутентификация в SSH остаётся рабочей до тех пор, пока сервер не окажется в зоне видимости интернета. Через пятнадцать минут после публикации свежего IP-адреса на него начинают стучаться боты со словарями из миллиона паролей. Fail2ban помогает, но это борьба с симптомами.

Настоящее решение — асимметричные ключи. В конфигурации /etc/ssh/sshd_config прописывается PasswordAuthentication no и PermitRootLogin no. Прямой вход под root запрещается глобально, повышение привилегий идёт только через sudo с обязательной записью в журнал.

Ключевая деталь, о которой часто забывают: доступ к порту 22 нужно ограничить на уровне межсетевого экрана. Разрешаются только IP-адреса администраторов или управляющей подсети. Даже самый стойкий пароль не поможет, если злоумышленник получил к нему доступ через утечку.

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

Как настроить межсетевой экран без ошибок

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

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

Типичная ошибка — публикация баз данных в пользовательские сети. PostgreSQL, MySQL, MongoDB, OpenSearch должны слушать только локальный интерфейс или внутренний VLAN приложений. Один открытый порт 5432 в интернет — и через сутки база окажется на форумах продавцов утечек.

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

Почему веб-интерфейсы нельзя публиковать напрямую

Веб-интерфейсы администрирования и бизнес-приложения привязываются к локальному интерфейсу через параметр http_addr = 127.0.0.1. Доступ из внешних сетей осуществляется исключительно через обратный прокси-сервер — Nginx, HAProxy или Apache.

Обратный прокси обеспечивает несколько функций одновременно. Он принимает TLS-соединения версии 1.2 или 1.3 на порту 443, фильтрует трафик, ограничивает частоту запросов и добавляет заголовки безопасности — HSTS, CSP, X-Frame-Options, X-Content-Type-Options. Без этих заголовков даже правильно настроенное приложение остаётся уязвимым к clickjacking и подмене контента.

В конфигурационных файлах СУБД явно прописывается правило: подключения разрешаются только с IP-адресов серверов приложений. Устаревшие методы аутентификации отключаются. При первом развёртывании любого сервиса заводские учётные данные меняются немедленно. Случаев, когда admin/admin оставался рабочим месяцами, больше чем хотелось бы.

Как работает централизованный сбор логов

Локальное хранение журналов не гарантирует их сохранности при компрометации сервера. Злоумышленник, получивший доступ к системе, первым делом чистит /var/log. Поэтому все журналы событий безопасности — auth.log, audit.log, логи приложений — передаются в реальном времени на выделенный сервер централизованного сбора по защищённому TLS-каналу.

Подсистема аудита ядра Linux (auditd) включается и настраивается на всех серверах. Протоколированию подлежат все попытки входа в систему, действия по повышению привилегий через sudo и su, изменения критичных конфигурационных файлов, запуск и завершение критичных процессов включая Docker.

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

Управление уязвимостями без хаоса

Автоматическая установка обновлений безопасности настраивается на всех серверах. Критические уязвимости устраняются в срок не более 24 часов с момента выхода патча, уязвимости высокого уровня — не более 7 суток. Эти сроки не взяты с потолка — они соответствуют требованиям регулятора и реальной скорости эксплуатации уязвимостей злоумышленниками.

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

Все используемые репозитории пакетов применяют опцию Signed-By для проверки криптографических подписей. Индивидуальные ключи хранятся в директориях /etc/apt/keyrings/ или /usr/share/keyrings/, использование глобального файла trusted.gpg запрещено. В конфигурации APT отключена установка слабых зависимостей — опции APT::Install-Recommends и APT::Install-Suggests устанавливаются в значение 0.

Разметка дисков и опции монтирования

Системные каталоги /tmp, /var, /var/log, /var/log/audit и /home размещаются на отдельных логических разделах диска. Разделение предотвращает исчерпание свободного места на корневом разделе и позволяет применять индивидуальные политики безопасности.

Для каталогов временных файлов /tmp и /var/tmp в файле /etc/fstab обязательно прописываются опции монтирования nodev, nosuid и noexec. Эти опции запрещают создание устройств, исполнение бинарных файлов и повышение привилегий через setuid-бит. Звучит сложно, но на практике это означает, что даже если злоумышленник загрузит вредоносный бинарник во временную директорию, запустить его не получится.

Раздел /var/log/audit получает те же опции — nodev, nosuid, noexec. Журналы аудита защищаются от несанкционированного исполнения кода. Корневая файловая система, раздел подкачки, домашние директории пользователей и резервное пространство для будущего расширения выделяются отдельными логическими томами.

Размер раздела подкачки зависит от объёма оперативной памяти. Для систем с 2-4 GB RAM рекомендуется 2-4 GB swap, для 4-8 GB — 4 GB, для 8-16 GB — 2-4 GB, для 16-64 GB — 2-4 GB или без swap вовсе, для систем с 64 GB и более — 0-2 GB опционально.

Параметры ядра для защиты процессов и памяти

Загрузчик GRUB защищается паролем. Доступ к редактированию параметров загрузки с консоли требует аутентификации суперпользователя, права на файл конфигурации загрузчика ограничены пользователем root.

В параметрах ядра через файлы в директории /etc/sysctl.d/ настраивается защита процессов и памяти. Параметр kernel.randomize_va_space устанавливается в значение 2 для включения полной рандомизации адресного пространства. Параметр fs.suid_dumpable устанавливается в 0 для запрета создания дампов памяти привилегированными процессов. Параметр kernel.yama.ptrace_scope устанавливается в 1 или 2 для ограничения возможности отладки и внедрения в чужие процессы. Параметр kernel.dmesg_restrict устанавливается в 1 для скрытия системных логов ядра от непривилегированных пользователей.

В конфигурации сетевого стека ядра отключаются функции маршрутизации и перенаправления пакетов, если сервер не является маршрутизатором. Параметры net.ipv4.ip_forward, net.ipv4.conf.all.send_redirects и net.ipv4.conf.default.send_redirects устанавливаются в 0.

Запрещается приём ICMP-перенаправлений и маршрутизации по источнику для предотвращения атак типа Man-in-the-Middle. Параметры net.ipv4.conf.all.accept_redirects, net.ipv4.conf.all.accept_source_route, net.ipv6.conf.all.accept_redirects и net.ipv6.conf.all.accept_source_route устанавливаются в 0.

Включается защита от SYN-flood атак и строгая проверка обратного пути. Параметры net.ipv4.tcp_syncookies, net.ipv4.conf.all.rp_filter и net.ipv4.conf.default.rp_filter устанавливаются в 1. Логирование маршрутизируемых пакетов с некорректными адресами источника включается через net.ipv4.conf.all.log_martians и net.ipv4.conf.default.log_martians.

Политики паролей через PAM

Политика сложности паролей реализуется через модуль PAM pam_pwquality. Минимальная длина пароля составляет 14 символов, требуется наличие символов разных регистров и специальных символов. История смены паролей контролируется модулем pam_pwhistory — система запрещает повторное использование последних 24 паролей.

Защита от подбора паролей реализуется через модуль pam_faillock. Учётная запись блокируется после 5 неудачных попыток ввода пароля. В файле /etc/login.defs настраиваются сроки действия учётных записей. PASS_MAX_DAYS не превышает 365 дней, PASS_MIN_DAYS составляет не менее 1 дня, PASS_WARN_AGE составляет 7 дней. Неактивные учётные записи автоматически блокируются через 45 дней после истечения срока действия пароля.

Контроль целостности файлов через AIDE

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

Строгие права доступа устанавливаются на критичные файлы аутентификации. Файл /etc/shadow имеет права 0600 или 0640 и принадлежит root. Файл /etc/gshadow имеет права 0600 или 0640 и принадлежит root. Файл /etc/passwd имеет права 0644 и принадлежит root. Файл /etc/group имеет права 0644 и принадлежит root.

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

Криптографическая защита каналов связи

Передача любых аутентификационных данных, персональных данных и служебной информации по сетям осуществляется в зашифрованном виде — TLS 1.2 и выше, SSH, IPsec. Использование протоколов без шифрования — HTTP, FTP, Telnet, SMTP без STARTTLS — запрещается полностью, включая внутренний контур.

Для внутренних сервисов используется корпоративный центр сертификации. Самоподписанные сертификаты, сгенерированные самими приложениями, заменяются на сертификаты, выпущенные доверенным внутренним УЦ. Корневой сертификат УЦ должен быть доверенным на всех машинах администраторов. Длина ключа для сертификатов TLS составляет не менее 2048 бит для RSA или 256 бит для ECDSA.

Синхронизация времени настраивается через NTP — chrony или systemd-timesyncd. Использование нескольких служб синхронизации одновременно запрещается. Доступ к планировщикам заданий cron и at ограничивается — в системе создаются файлы /etc/cron.allow и /etc/at.allow, содержащие только список привилегированных пользователей. Файлы cron.deny и at.deny удаляются или остаются пустыми, права на файлы разрешений устанавливаются в 0600.

На всех серверах настраиваются юридические предупреждающие баннеры о запрете несанкционированного доступа. Баннеры размещаются в файлах /etc/issue, /etc/issue.net, /etc/motd и настраиваются в конфигурации SSH через параметр Banner /etc/issue.net. Тексты баннеров не содержат информации о версии операционной системы, имени хоста или установленном программном обеспечении.

Действия при обнаружении инцидента

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

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

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

Не все пункты этого регламента применимы в мелких проектах с одним сервером и одним администратором. Мандатный контроль, разделение ролей и централизованный сбор логов имеют смысл только при определённом масштабе инфраструктуры. Но базовые вещи — ключи вместо паролей, запрет root, межсетевой экран с политикой DENY, отдельные разделы для /tmp и /var/log — работают везде и защищают от большинства типовых атак.