Автообновления безопасности на Linux: ночные заплатки с утренним отчётом

На Windows-парке у нас уже давно работал WSUS - поставил задание, выбрал категории, сервер сам скачивает одобренные обновления, машины получают их по расписанию, утром можно смотреть отчёт. Удобно и предсказуемо. С Linux-серверами такого порядка не было: обновляли руками, когда добирались, или когда что-то случалось и вспоминали, что давно не смотрели.

Давно хотелось выровнять это. Поводом стало то, что apt и yum уже умели делать всё нужное - дело было только в том, чтобы правильно всё настроить и не выстрелить себе в ногу автоматическими обновлениями на продакшн-серверах.

Почему руками - это не работает

Логика «обновляем когда выходит что-то важное» хороша в теории. На практике это значит: следим за рассылками, читаем security advisories, выбираем момент, идём на каждый сервер. Если серверов пять - ещё терпимо. Если двадцать, и они у разных клиентов на разных дистрибутивах - это уже полноценная ручная работа, которую начинают откладывать. А откладывать патчи безопасности мы с 2003 года себе зарекались.

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

Внутреннее зеркало репозитория

Первый вопрос при автообновлениях: откуда тянуть пакеты. Тянуть с публичных зеркал каждому серверу по отдельности - это и трафик наружу, и зависимость от доступности внешних ресурсов, и отсутствие контроля над тем, что именно скачается.

Мы подняли внутреннее зеркало. На CentOS-парке это rsync с ближайшего зеркала CentOS, для Debian/Ubuntu - apt-mirror. Зеркало синхронизируется ночью, раз в сутки. Все серверы смотрят на него - не наружу.

Плюсы сразу видны:

• Скорость. Внутри сети пакет скачивается за секунды, не за минуты.
• Надёжность. Внешнее зеркало лежит - нам не важно, наши серверы это не замечают.
• Единая точка. Что лежит в нашем зеркале - то и может скачаться. Ничего неожиданного.
• Трафик наружу. Одно зеркало тянет обновления один раз, не двадцать серверов параллельно.

Что именно автоматизируем - и что нет

Вот тут главный вопрос, и его стоит проговорить отдельно. Автоматические обновления - это не «apt-get upgrade по крону». Это источник катастроф, если делать бездумно.

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

Поэтому мы автоматизируем только одну категорию: обновления безопасности. Не все доступные обновления - только те, которые в CentOS помечены как security, и только те пакеты, которые не тянут за собой обновление ядра или критичных системных компонентов.

На CentOS это делается через yum update с ограничением по репозиторию: настраиваем yum.conf так, чтобы подтягивались только пакеты из security-репозитория нашего внутреннего зеркала. На Debian-системах - через unattended-upgrades, который настраивается на источник Debian-Security и игнорирует остальные.

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

Утренний отчёт

Автообновление без видимости - это почти то же самое, что и никакого обновления. Мы настроили простую схему: скрипт запускается после обновления, собирает список установленных пакетов и их версии, сравнивает с предыдущей ночью и отправляет diff на почту.

Письмо приходит утром. В нём - по каждому серверу: что обновилось, что не смогло обновиться и почему, были ли ошибки. Если ничего не обновлялось - короткое «всё актуально». Если что-то не смогло - смотрим глазами.

Это важно по двум причинам. Первая - видно, что процесс работает. Если от сервера три дня нет письма, значит что-то сломалось в схеме. Вторая - видно аномалии. Если пакет вдруг обновился до неожиданной версии или что-то удалилось как зависимость - это заметно сразу, не через месяц.

Где автообновления точно опасны

Есть серверы, на которых мы эту схему не включали вообще или включали с дополнительными ограничениями:

• Серверы баз данных. MySQL, PostgreSQL - обновление сервера баз данных, даже патч безопасности, может менять поведение или формат хранилища. Только руками, только с бэкапом перед обновлением.
• Сервер с самописным ПО. Если приложение написано под конкретную версию библиотеки и хрупко - автоматика опасна. Там сначала нужно привести зависимости в порядок.
• Тестовый и продакшн без разделения. Если нет тестового сервера, на котором можно проверить обновление до того, как оно попадёт на прод - автоматика работает вслепую. В идеале автоматика сначала идёт на тестовый стенд, потом, если всё в порядке, на прод. У части клиентов так и сделано.

На этих серверах мы оставили только автоматическую проверку доступных обновлений безопасности с отчётом по почте - без установки. Инженер видит, что вышло, и сам решает, когда и как ставить.

Что получили

Через месяц работы схемы картина изменилась. Раньше между обновлениями на сервере могло пройти несколько недель - не потому что мы забывали принципиально, а потому что руки доходили не сразу. Теперь патчи безопасности стоят в течение суток-двух после выхода.

Отчёты по утрам стали привычкой: открываешь почту, пробегаешь глазами. Большую часть времени там «всё актуально» - и это само по себе информация. Когда что-то обновилось - сразу знаешь что именно.

Blaster в 2003-м был про Windows, но урок универсальный: патч, который не поставлен, - это открытая дверь, про которую ты забыл. Автоматика не избавляет от необходимости думать, но убирает основной источник проблемы - человеческое «поставлю потом».