Настройка автообновлений безопасности в Debian: мой опыт

Признаюсь сразу: годами я обновлял серверы руками. Раз в пару месяцев заходил по SSH, запускал apt upgrade, читал списки пакетов, иногда забывал. Пока однажды не обнаружил, что на одном из моих Debian-серверов полгода не было критического патча безопасности. С тех пор настройка автообновлений безопасности в Debian — первый шаг после установки для меня. Рассказываю, как я настроил unattended-upgrades, что подкрутил и какой подвох выловил.

Если у вас есть хоть один сервер на Debian, который живёт без присмотра, — дочитайте. Пятнадцать минут настройки заменяют месяцы тревожного «а поставил ли я тот патч».

Почему я доверил безопасность Debian автоматике

Аргументы простые. Первое: патчи безопасности выходят тогда, когда выходят, — и ждать удобного момента бессмысленно, дырку эксплуатируют уже сегодня. Второе: ручные обновления зависят от памяти и настроения, а память у меня так себе, проверено. Третье: в Debian этот механизм встроен официально, его поддерживает сама команда безопасности дистрибутива. Это не сторонний костыль, а штатная практика.

Важно понимать границу: автоматически ставятся только обновления безопасности из специального репозитория. Обычные апгрейды программ остаются на мне. Такой компромисс даёт защиту без риска внезапно получить новую версию чего-то важного посреди ночи.

Установка unattended-upgrades: два пакета и одна команда

В свежих Debian базовый пакет обычно уже стоит, но проверить стоит каждому:

sudo apt update
sudo apt install unattended-upgrades apt-listchanges

Второй пакет полезен тем, что показывает changelog перед установкой — пригодится при разборе полётов. Дальше включаем механизм интерактивным мастером:

sudo dpkg-reconfigure --priority=low unattended-upgrades

Он задаст один вопрос про автоматические стабильные обновления — отвечаете «да». Всё, каркас работает. Но не спешите закрывать терминал: дьявол в конфиге, о нём ниже.

Мой конфиг: что именно я разрешаю обновлять

Главный файл — 50unattended-upgrades в каталоге /etc/apt/apt.conf.d/. Мой рабочий набор строк такой:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";

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

Ещё советую заглянуть в файл 20auto-upgrades — там две строки, отвечающие за сами периодические запуски. Должно быть единичное значение у Update-Package-Lists и Unattended-Upgrade. Без них механизм просто спит.

Момент Икс: почта, которая молчала месяц

Настроив всё, я был уверен, что система работает. Уведомления на почту включены, отчёты придут — красота. Через месяц случайной проверкой обнаружил: обновления шли, а писем нет. И тут я понимаю: локальный exim складывал отчёты в очередь, но наружу отправить не мог, потому что релей я так и не прописал. Классика: механизм работает, а канал связи — нет.

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

Unattended-Upgrade::Mail "admin@example.ru";
Unattended-Upgrade::MailReport "on-change";

Теперь письмо приходит при каждом изменении набора пакетов. Мораль: настраивая автоматику, всегда устраивайте ей учебную тревогу и проверяйте канал оповещения. Молчащая автоматика опаснее отсутствующей — она создаёт ложное чувство защищённости.

Как я проверяю, что автообновления Debian реально работают

Доверяй, но проверяй — мой девиз для любой автоматики. Есть три способа убедиться. Первый — журнал работы механизма:

less /var/log/unattended-upgrades/unattended-upgrades.log

Видно каждую сессию: какие пакеты предлагались, что поставилось, были ли ошибки. Второй способ — сухой остаток в системе:

apt list --upgradable | grep -i securi

Если список пуст, а журнал свежий — всё отлично. Третий — таймер systemd, который запускает задачу дважды в день:

systemctl list-timers | grep apt

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

Что делать с перезагрузками после обновлений

Отдельная боль любого администратора: библиотеки обновились, а работающие сервисы держат старые версии в памяти до рестарта. В Debian есть аккуратный инструмент проверки:

checkrestart

Из пакета debian-goodies (ставится одной командой). Он честно покажет список процессов со старыми библиотеками. Мой регламент: раз в неделю захожу на серверы, смотрю вывод, рестартую только то, что реально требует перезагрузки, и только в согласованные окна. Так безопасность соблюдается, а пользователи не замечают ночных плясок.

Для ленивых есть компромисс в самом конфиге: Automatic-Reboot-Time позволяет назначить конкретный час автоперезагрузки при необходимости. Я всё же предпочитаю руками, но вариант рабочий, пользуются коллеги.

Полезные команды для обслуживания автообновлений

• apt install unattended-upgrades — установка самого механизма
• dpkg-reconfigure unattended-upgrades — включение через мастер
• unattended-upgrade -d —dry-run — пробный запуск с отладкой, ничего не ставит
• tail -f /var/log/unattended-upgrades/unattended-upgrades.log — живой журнал
• do-release-upgrade — это для Ubuntu, в Debian путь другой, не перепутайте

Команда dry-run вообще моя любимица: любые правки конфига сначала гоняю в холостую и читаю план действий. Экономит нервы при экспериментах с секциями Allowed-Origins.

Грабли, о которых стоит знать заранее

Собрал свои шишки в список. Первая: заблокированные пакеты. Если какой-то пакет держится на версии через apt-mark hold, автообновление его обойдёт молча — а вы можете этого не заметить. Вторая: сторонние репозитории не входят в security-секцию по умолчанию, для них нужны отдельные записи в конфиге. Третья: при малом объёме диска загрузка пакетов может падать — следите за местом в /var/cache/apt.

И главная, философская: автоматика не отменяет мониторинга новостей безопасности. Бывают инциденты, требующие немедленной реакции руками. Автообновления закрывают рутину, но не голову.

Пара слов о виртуалках и контейнерах, которые тоже живут у меня на Debian. Механизм прекрасно работает в LXC-контейнерах и минимальных образах без изменений в конфигурации. Единственный нюанс: следите за тем, чтобы таймеры systemd внутри контейнера были активны — в некоторых урезанных шаблонах их нужно включать руками. Проверка всё те же три команды из раздела выше, они работают везде одинаково.

И последнее, о чём стоит подумать: документируйте свои исключения. Заведите в заметках сервера короткий файл с ответами на три вопроса: какие пакеты в чёрном списке и почему, какие источники добавлены в охват и когда планируете их пересмотреть. Через полгода вы не вспомните, зачем блокировали тот драйвер, а такая записка сэкономит вечер разбирательств. Хорошая автоматика всегда идёт в паре с короткой понятной документацией — это правило работает без исключений.

Итог: спокойствие за пятнадцать минут настройки

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

Если ваш сервер ещё обновляется «когда вспомню» — исправляйтесь. Пятнадцать минут сегодня против неприятного разговора с самим собой после инцидента. Выбор очевиден, правда?

Границы автоматики: что обновляется, а что нет

Чтобы не питать ложных надежд, разложу границы. Автоматически ставятся пакеты из секции security вашего релиза. Всё остальное — обычные апгрейды, новые версии программ, сторонние репозитории — остаётся вашей ручной работой по умолчанию. Это осознанный компромисс Debian: безопасность должна ехать сама, а функциональные изменения требуют человека.

Если хотите расширить охват, в Allowed-Origins можно добавить обычные ветки дистрибутива или свои источники. Я добавлял ветку backports для одного сервера с новым ядром — работает, но будьте готовы к тому, что объём автоматических изменений вырастет заметно. Мой совет: начинайте строго с security, расширяйте только когда привыкнете к потоку писем-отчётов и поймёте их ритм.

Чёрный список пакетов: тонкая настройка под себя

Бывает, что какой-то пакет нельзя трогать без вашего участия. Например, у меня месяц жил особый драйвер, совместимый только с конкретной версией ядра. На этот случай в конфиге есть секция Package-Blacklist:

Unattended-Upgrade::Package-Blacklist {
    "linux-image-specific";
    "my-custom-driver";
};

Указанные пакеты пропускаются молча, но факт пропуска всё равно попадает в журнал и письмо-отчёт. Именно так я и контролирую исключение: раз в неделю смотрю отчёт, вижу строку «пропущено», вспоминаю, зачем это делал, и решаю, не пора ли разблокировать. Система честная: она не делает тайных движений за вашей спиной, и за это ей спасибо.

Как я раскатал настройку на все серверы сразу

Первый сервер я настраивал руками, второй — копипастой конфигов, а на третьем вспомнил о своей же статье про Ansible и сделал по уму. Конфиги unattended-upgrades живут в двух файлах — их и описал в плейбуке одной задачей шаблона. Теперь новый сервер получает автоматику безопасности ещё на этапе первичной настройки, вместе с базовыми пакетами.

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

Насколько это безопасно: подписи пакетов

Частый вопрос от знакомых: а не подсунут ли мне под видом обновления что-то плохое? Здесь Debian традиционно строг. Каждый пакет подписан GPG-ключами команды безопасности, apt проверяет подпись перед установкой автоматически. Поддельный или повреждённый пакет просто не пройдёт проверку и не поставится — механизм упадёт с громкой ошибкой в журнале, которую вы увидите в том самом письме-отчёте.

За годы практики у меня не было ни одного случая проблем с целостностью пакетов из официальных источников. Все инциденты безопасности, которые я наблюдал у знакомых, начинались со сторонних репозиториев и скриптов из интернета. Так что добавляя новые источники в Allowed-Origins, дважды убедитесь, что доверяете владельцу ключей этого источника.

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

План для ленивых: автообновления Debian за один вечер

• Установить unattended-upgrades и apt-listchanges
• Включить через dpkg-reconfigure, проверить 20auto-upgrades
• Прописать Mail и MailReport, настроить доставку почты
• Прогнать dry-run, убедиться в отсутствии ошибок
• Раз в месяц: три команды проверки (журнал, upgradable, таймеры)
• После смен ядра — плановая перезагрузка в согласованное окно