Харденинг ОС и хоста

Поверхность атаки — это сумма того, что достижимо

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

Именно поэтому сокращение поверхности атаки — самый высокорычажный шаг в безопасности хоста и самый дешёвый. Патч чинит один известный баг в сервисе; удаление сервиса чинит все баги, которые в нём когда-либо будут, включая ещё не обнаруженные. Когда прилетели классы багов вроде Shellshock (2014) и PrintNightmare (2021), отмахнулись не те хосты, что патчились быстрее всех, — а те, что вообще никогда не ставили уязвимый компонент. Сокращение бьёт реакцию.

Минимизация сервисов: вычитай, прежде чем добавлять

Минимизация сервисов — это дисциплина запускать минимальный набор процессов, нужных хосту для его одной задачи, и ничего больше. Машине, которая обслуживает HTTP, не нужны почтовый агент, десктопный DNS-резолвер, Avahi/mDNS, CUPS или X-сервер. Операционный тест для каждого слушателя — одно предложение: назови конкретную функцию, которую он обслуживает, и команду-владельца. Не можешь — он не должен работать.

На практике ты проходишь по поверхности и срезаешь:

• Аудит слушателей — ss -tulpn (или ss -tlnp для TCP) сопоставляет каждый открытый порт с процессом и PID, который его держит. Всё, что не можешь назвать, останавливается.
• Сначала отключи, потом удали — systemctl disable --now <svc> не даёт ему пережить перезагрузку; apt purge / dnf remove стирает бинарник, чтобы его нельзя было снова включить или проэксплуатировать.
• Привязывай к самому узкому интерфейсу — сервис, который говорит только с localhost, должен слушать 127.0.0.1, а не 0.0.0.0. База, привязанная к 0.0.0.0 с дефолтным паролем, — так и попадают в записку с требованием выкупа.
• Файрвол по умолчанию запрещает — отбрасывай весь входящий, затем разрешай только названные порты. Файрвол — твоя страховка для сервиса, который ты забыл отключить.

Безопасные умолчания: выжившие должны быть безопасны из коробки

У всех сервисов, переживших минимизацию, умолчания настроены на быстрый старт, а не на продакшен-безопасность — а это противоположные цели. Поставляемые умолчания оптимизированы под «работает с первого запуска без конфигурации», а это значит широкие привязки, многословные ошибки, разрешающие права и образцовые учётки. Харденинг переворачивает каждое из этих умолчаний в deny-by-default: конфигурация стартует с самой ограничительной настройки и открывает только то, что названо явно.

Два самых ценных умолчания для исправления — аутентификация и привилегии. SSH с парольной аутентификацией и включённым входом под root — самая брутфорсимая поверхность в публичном интернете; переход на вход только по ключам с PermitRootLogin no убирает весь класс атак на угадывание учёток. А принцип наименьших привилегий применим к каждому процессу: веб-сервер, скомпрометированный во время работы под root, — это скомпрометированный хост; тот же эксплойт против сервиса, работающего под непривилегированным пользователем со сброшенными Linux-capabilities, — это скомпрометированный процесс, разница между инцидентом и катастрофой.

Базовые линии: сделать укреплённое состояние измеримым и долговечным

Хост, который ты захарденил руками, укреплён один раз. Через три месяца и сорок деплоев кто-то снова включил сервис, чтобы дебажить аварию, прогон config-management откатил настройку, пересборка образа уронила твои правила файрвола — а ты не в курсе, потому что «укреплён» жил только в памяти одного инженера. Лекарство — базовая линия: записанное, машинно-проверяемое определение известно-хорошего безопасного состояния хоста плюс непрерывное сравнение с ним.

Ровно это и дают CIS Benchmarks — построенные по консенсусу, предписывающие конфигурационные базовые линии для каждой ОС и платформы, где каждый контроль указывает и проверку аудита, и шаг исправления. NIST SP 800-123 формулирует ту же идею на уровне программы: укрепи до документированного стандарта, а затем поддерживай его. Базовая линия превращает харденинг из героического разового усилия в принудительно соблюдаемое свойство:

• Закрепи как код — закодируй базовую линию в Ansible/Chef/Puppet или в золотом образе, чтобы каждый хост рождался укреплённым, а не укреплялся постфактум.
• Аудируй непрерывно — инструменты вроде OpenSCAP, Lynis или скан CIS-CAT оценивают живой хост против бенчмарка и выдают балл плюс список проваленных контролей.
• Алертуй на дрейф — когда живой хост расходится с базовой линией, эта дельта — событие безопасности, а не сноска. Дрейф часто оказывается первым видимым признаком либо небрежного изменения, либо активного вторжения.