Можно ли включить Unattended Upgrades без автоматической перезагрузки?

Да. Unattended Upgrades можно использовать для автоматической загрузки или установки разрешённых обновлений, не разрешая системе самостоятельно перезагружаться. В конфигурации /etc/apt/apt.conf.d/50unattended-upgrades оставьте Unattended-Upgrade::Automatic-Reboot "false";. Перед включением проверьте текущие правила в 20auto-upgrades и 50unattended-upgrades. Разрешайте только нужные security-источники: для Ubuntu типичная политика использует ${distro_id}:${distro_codename}-security, а для Debian шаблон должен соответствовать его security-архиву. Не добавляйте proposed, backports и сторонние источники без отдельного решения. Для ежедневной автоматической установки нужны APT::Periodic::Update-Package-Lists "1"; и APT::Periodic::Unattended-Upgrade "1";. Проверьте результат через sudo unattended-upgrade --dry-run --debug, таймеры apt-* и журналы в /var/log/unattended-upgrades/, если они предусмотрены установленной версией. Перезагрузку после обновления ядра или критичных компонентов планируйте отдельно.

Что делать, если выпуск Linux достиг end of life?

Нельзя считать доступные в старом репозитории пакеты подтверждением актуальной защиты. Сверьте точные ID и VERSION_ID с официальной страницей жизненного цикла поставщика. После окончания стандартной поддержки исправления могут поступать только по условиям extended maintenance или отдельной подписки для конкретного выпуска. Если такой поддержки нет, нужен поддерживаемый путь обновления системы.

Можно ли выполнять yum update --security на любом сервере?

Нет. Режим yum update --security доступен только при поддерживаемой версии legacy-YUM и наличии security/updateinfo-функций у поставщика. На старых системах также может требоваться соответствующий плагин. Сначала проверьте yum updateinfo list security и симуляцию с --assumeno; не переносите синтаксис DNF на YUM без проверки документации своего выпуска.

Почему dnf update --security не показывает исправления?

Обычно причина в репозиториях: security-отбор работает, только когда подключённые источники публикуют updateinfo-метаданные и DNF может их использовать. Проверьте включённые репозитории через dnf repolist --enabled, затем выполните dnf updateinfo list --security. Исправленная версия из стороннего репозитория может не иметь security-маркировки и потребовать обычного согласованного обновления пакета.

Как понять, что обновление из APT действительно закрывает уязвимость?

По одному выводу apt list --upgradable это определить нельзя: там есть обычные исправления ошибок, зависимости и функциональные изменения. Сопоставьте пакет с утверждённым security-источником и advisory, затем проверьте план через apt-get -s upgrade. После установки подтвердите версию командой apt-cache policy имя-пакета и журналом /var/log/apt/history.log.

Нужна ли перезагрузка после обновлений безопасности Linux?

Не всегда, но обновления ядра обычно требуют контролируемой перезагрузки: установленный пакет на диске не меняет уже запущенное ядро. В Ubuntu и Debian проверьте наличие /var/run/reboot-required и при необходимости содержимое reboot-required.pkgs. В RHEL-совместимых системах используйте needs-restarting -r, если эта утилита предусмотрена выпуском; needs-restarting -s может показать службы с заменёнными файлами. Перед reboot подтвердите версию запущенного ядра через uname -r, установленную версию ядра в пакетном менеджере и список служб, требующих restart. Зафиксируйте допустимый простой, зависимости, порядок обновления узлов и способ проверки после загрузки. Для кластера перезагружайте узлы в последовательности, которая сохраняет доступность в рамках его архитектуры. Перед sudo systemctl reboot переведите сервисы в обслуживание или остановите их по документации приложения. После загрузки проверьте uname -r, uptime, необходимые systemd-unit, журналы текущей загрузки и прикладную доступность.

Обновления безопасности Linux: APT, DNF, автоматизация и reboot

Устанавливайте патчи безопасности после проверки выпуска ОС, репозиториев, плана транзакции и доступного канала администрирования. APT, DNF и legacy-YUM могут показать доступные обновления, но не каждый пакет в общем списке является исправлением уязвимости. Автоматизация полезна для загрузки и установки по понятной политике, однако обновления ядра и критичных служб обычно требуют отдельного решения о окне обслуживания и перезагрузке.

До обновления: выпуск ОС, роль сервера и доступ

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

Определяет семейство и выпуск ОС, запущенное ядро и доступные менеджеры пакетов.

cat /etc/os-release && uname -r && command -v apt apt-get dnf yum

Вывод:

В `/etc/os-release` важны поля `ID`, `VERSION_ID` и `VERSION_CODENAME`. Обычно Ubuntu и Debian используют APT; современные RHEL-совместимые системы — DNF; YUM встречается прежде всего в старых выпусках.

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

Сверьте точный ID и VERSION_ID с текущей официальной страницей жизненного цикла поставщика ОС. Окончание стандартной поддержки означает, что обычные репозитории могут перестать получать исправления; отдельные программы extended maintenance или подписки применимы только к указанным выпускам и условиям. Не считайте старый репозиторий с доступными пакетами доказательством получения актуальных исправлений.

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

Проверьте источники обновлений безопасности

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

Ubuntu и Debian: APT

Показывает существенные поля APT-источников как в однострочном формате sources.list, так и в формате deb822. Для поддерживаемого Ubuntu обычно ожидается suite с суффиксом `-security`; для Debian — security-архив и suite, соответствующие выпуску.

grep -RhsE '^[[:space:]]*(deb([[:space:]]|\[)|Types:|URIs:|Suites:|Components:|Enabled:)' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

Вывод:

Если security-источник отсутствует, недоступен или относится к другому выпуску, не исправляйте это вслепую во время патча: сначала подтвердите формат файлов, конфигурацию репозиториев и поддержку выпуска.

Обновляет локальные индексы APT без установки пакетов.

sudo apt-get update

Вывод:

Команда должна завершиться без ошибок подписи, DNS, TLS или доступа к репозиторию. Ошибка `Release file` или истёкший репозиторий может указывать на неподдерживаемый выпуск либо неверный источник.

Показывает все доступные обновления после обновления индексов.

apt list --upgradable

Вывод:

Этот вывод сам по себе обычно не маркирует пакеты как security-обновления. Для Ubuntu и Debian определяйте источник и назначение обновления по security-репозиторию, changelog пакета и соответствующему [бюллетеню безопасности](/baza-znaniy/glossariy/security-advisory), а не только по названию пакета.

RHEL-совместимые системы: DNF и legacy-YUM

Показывает включённые DNF-репозитории в типичной RHEL-совместимой системе.

sudo dnf repolist --enabled

Вывод:

Проверьте, что используются репозитории поставщика ОС или утверждённого зеркала для установленного выпуска. На системах с подпиской дополнительно проверьте её состояние штатным средством поставщика.

Проверяет доступные обновления без установки пакетов и выводит код возврата DNF.

sudo dnf check-update; rc=$?; printf 'dnf exit code: %s\n' "$rc"

Вывод:

Код `0` означает, что доступных обновлений нет, а `100` — что обновления найдены. Другой код требует разбора ошибки репозитория, метаданных или зависимостей. Команда не вызывает `exit`, поэтому не завершает текущую административную оболочку.

Выводит security-advisory и сведения о security-обновлениях, когда подключённые репозитории публикуют updateinfo-метаданные.

sudo dnf updateinfo list --security && sudo dnf updateinfo info --security

Вывод:

Если вывод пуст, это не доказывает отсутствие уязвимостей: у репозитория может не быть updateinfo, пакет может отсутствовать в его канале или установленная версия ОС может не поддерживаться.

YUM — устаревший инструмент для систем, где DNF ещё не используется. В таких выпусках команда yum updateinfo list security и режим yum update --security доступны только при наличии поддерживаемой версии YUM и security/updateinfo-функций поставщика, в старых системах — также при установленном соответствующем плагине. Не переносите синтаксис DNF на YUM без проверки документации именно своего выпуска.

Показывает включённые репозитории в системе с legacy-YUM.

sudo yum repolist enabled

Вывод:

Сверьте, что репозитории относятся к установленному выпуску и предоставлены поставщиком ОС либо утверждённым зеркалом. Наличие репозитория само по себе не подтверждает доступность security/updateinfo-метаданных.

Просмотрите транзакцию до установки

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

Симуляция рассчитывает зависимости, но не меняет систему. Результат зависит от версии менеджера пакетов и метаданных репозиториев.

Семейство	Просмотр общего плана без изменений	Просмотр security-плана
Ubuntu / Debian	`sudo apt-get -s upgrade` или `sudo apt-get -s dist-upgrade`	У APT нет универсального штатного флага, который во всех выпусках достоверно отбирает только security-пакеты; сопоставляйте пакеты с security-источником и advisory.
DNF	`sudo dnf upgrade --assumeno`	`sudo dnf upgrade --security --assumeno` при наличии security-метаданных
Legacy-YUM	`sudo yum update --assumeno`	`sudo yum update --security --assumeno`, если функция поддерживается системой и репозиторием

Показывает удержанные пакеты APT и основные поля локальных pin/priority-правил.

apt-mark showhold; grep -RhsE '^[[:space:]]*(Package|Pin|Pin-Priority):' /etc/apt/preferences /etc/apt/preferences.d 2>/dev/null

Вывод:

Не снимайте hold и не меняйте pinning без понимания причины. Сначала определите владельца правила и проверьте, не связано ли исключение с совместимостью приложения или утверждённой политикой обновлений.

Показывает versionlock, если плагин установлен, и проверяет целостность зависимостей RPM.

sudo dnf versionlock list 2>/dev/null; sudo dnf check

Вывод:

Отсутствие плагина versionlock не является ошибкой. Ошибки `dnf check` или конфликты в dry-run требуют отдельного разбора, а не принудительного обновления.

Не соглашайтесь на план автоматически

Остановитесь, если симуляция удаляет неожиданный пакет, меняет поток выпуска, затрагивает загрузчик, драйвер, СУБД или основной сервис. Уточните advisory, зависимости приложения и план отката. dist-upgrade в APT и distro-sync в DNF решают другие задачи и не являются безусловной заменой security-обновлению.

Установка обновлений безопасности

Ubuntu и Debian: установка после проверки плана

В APT выбор исключительно security-обновлений зависит от структуры репозиториев и не имеет одного универсального интерактивного флага для всех поддерживаемых выпусков.

1
Обновите индексы и повторите план
Выполните sudo apt-get update, затем sudo apt-get -s upgrade. Если для исправления требуется новый пакет или изменение зависимостей, отдельно оцените sudo apt-get -s dist-upgrade.
2
Выберите масштаб изменения
Если advisory относится к одному пакету и его версия доступна из утверждённого security-источника, используйте sudo apt-get install --only-upgrade имя-пакета. Команда обновляет уже установленный пакет, но APT может изменить необходимые зависимости.
3
Установите согласованный набор
Когда план общего обновления допустим, выполните sudo apt-get upgrade. Если ранее одобренный план требует изменения зависимостей, выполните sudo apt-get dist-upgrade только в предусмотренном окне.
4
Проверьте установленную версию
Используйте apt-cache policy имя-пакета и журнал /var/log/apt/history.log. Сопоставьте установленную версию с версией из advisory, а не только с отсутствием пакета в общем списке обновлений.

RHEL-совместимые системы: DNF и YUM

Команды security-only применимы, когда поставщик публикует updateinfo/security-метаданные для используемых репозиториев.

1
Проверьте advisory и dry-run
Выполните sudo dnf updateinfo list --security, затем sudo dnf upgrade --security --assumeno. Проверьте список обновляемых, устанавливаемых и удаляемых RPM.
2
Установите security-обновления
Если план согласован, выполните sudo dnf upgrade --security. Прицельное исправление пакета возможно через sudo dnf upgrade имя-пакета, если нужная версия доступна; такая команда не обязана ограничиваться security-advisory.
3
Проверьте результат
Выполните sudo dnf updateinfo list --security, rpm -q имя-пакета и при необходимости sudo dnf history info last. Сохраните идентификатор транзакции и установленную версию.
4
Для старой системы с YUM используйте её штатный режим
Сначала проверьте sudo yum updateinfo list security и симуляцию sudo yum update --security --assumeno; затем, если функция доступна и план принят, выполните sudo yum update --security. Если команда не поддерживается, не подменяйте её случайным плагином: определите поддерживаемый путь для конкретного выпуска.

Иногда security-only режим не решает задачу: исправленная версия может не быть помечена как security в стороннем репозитории, advisory может требовать обычного обновления конкретного пакета, а поддержка приложения — обновления всего набора пакетов. Такое решение фиксируют как обычное изменение с объяснением причин, а не выдают за «безопасный» режим только из-за названия команды.

Службы и перезагрузка после обновления Linux

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

Проверяет состояние и последние сообщения конкретной службы после её restart или обновления.

sudo systemctl status имя-службы --no-pager && sudo journalctl -u имя-службы -b --no-pager -n 100

Вывод:

Статус `active (running)` полезен, но недостаточен: проверьте прикладной health-check, соединение клиента или метрику, относящуюся к роли сервера.

Ubuntu и Debian

Проверяет распространённый в Debian/Ubuntu файл-индикатор необходимости перезагрузки.

test -e /var/run/reboot-required && { cat /var/run/reboot-required; cat /var/run/reboot-required.pkgs 2>/dev/null; } || echo 'Индикатор reboot-required отсутствует'

Вывод:

Наличие файла означает, что пакетный механизм запросил reboot; файл `.pkgs`, если создан, перечисляет связанные пакеты. Отсутствие файла не доказывает, что все процессы уже используют новые библиотеки.

RHEL-совместимые системы

Проверяет необходимость перезагрузки средствами `needs-restarting`, если утилита установлена пакетом, предусмотренным вашим выпуском (часто `dnf-utils` или `yum-utils`).

sudo needs-restarting -r; rc=$?; echo "exit code: $rc"

Вывод:

Для распространённых реализаций код `1` означает, что reboot требуется, а `0` — что утилита не обнаружила такой необходимости. Точное поведение и доступность ключей зависят от выпуска; при отсутствии команды установите штатный пакет инструментов или сверяйтесь с документацией поставщика.

В поддерживаемых версиях показывает systemd-службы, которым может требоваться restart из-за заменённых файлов.

sudo needs-restarting -s

Вывод:

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

Назначение перезагрузки в окно обслуживания

1
Подтвердите необходимость reboot
Проверьте индикатор ОС, версию запущенного ядра uname -r, установленную версию ядра в менеджере пакетов и список служб для restart. Обновление ядра обычно начинает действовать только после загрузки нового ядра.
2
Определите воздействие
Зафиксируйте допустимый простой, зависимости, порядок узлов, проверку после загрузки и канал консоли. Для одного сервера согласуйте конкретное окно; для кластера — последовательность, сохраняющую доступность в рамках его архитектуры.
3
Выполните controlled reboot
Перед командой sudo systemctl reboot остановите или переведите в обслуживание сервисы так, как требует их документация. Не используйте принудительную перезагрузку, пока штатное завершение работы возможно.
4
Подтвердите загрузку нового состояния
После входа проверьте uname -r, uptime, состояние необходимых unit через systemctl, журналы текущей загрузки и прикладную доступность. Зафиксируйте фактическое время и отклонения от плана.

Автоматические обновления Ubuntu и Debian: Unattended Upgrades

Unattended Upgrades может автоматически загружать и устанавливать разрешённые обновления через APT. В типичной конфигурации пакет называется unattended-upgrades, периодические задания APT задаются в /etc/apt/apt.conf.d/20auto-upgrades, а политика выбора — в /etc/apt/apt.conf.d/50unattended-upgrades. Имена файлов, доступные параметры и синтаксис origins/patterns зависят от выпуска Debian/Ubuntu и версии пакета; перед изменением сверяйте комментарии в поставляемом конфиге и документацию своего выпуска.

Настройка Unattended Upgrades с контролем

1
Установите пакет и изучите текущую политику
Выполните sudo apt-get install unattended-upgrades, затем просмотрите 20auto-upgrades и 50unattended-upgrades. Не заменяйте поставляемый файл целиком, если в нём уже есть локальные правила.
2
Разрешите только нужные источники
В 50unattended-upgrades используйте документированный для выпуска список Unattended-Upgrade::Allowed-Origins либо Unattended-Upgrade::Origins-Pattern. Для Ubuntu типичная security-политика выбирает ${distro_id}:${distro_codename}-security; для Debian шаблон должен соответствовать его security-архиву. Не разрешайте proposed, backports или сторонние источники без отдельного решения.
3
Выберите загрузку или автоматическую установку
Для ежедневной установки разрешённых политикой Unattended Upgrades пакетов задайте APT::Periodic::Update-Package-Lists "1"; и APT::Periodic::Unattended-Upgrade "1";. Для периодической загрузки без unattended-установки используйте документированный выпуском параметр APT::Periodic::Download-Upgradeable-Packages "1";, а APT::Periodic::Unattended-Upgrade оставьте равным "0". Учтите: общая загрузка upgradeable-пакетов средствами APT не обязана ограничиваться Allowed-Origins из Unattended Upgrades, поэтому состав загрузки нужно проверить на своём выпуске.
4
Отключите самовольную перезагрузку и настройте уведомление
Оставьте Unattended-Upgrade::Automatic-Reboot "false";, если автоматический reboot не утверждён. Для почтового отчёта используйте поддерживаемые выпуском параметры Unattended-Upgrade::Mail и при необходимости Unattended-Upgrade::MailOnlyOnError; сначала убедитесь, что на хосте действительно настроена доставка почты.
5
Проверьте работу без установки
Запустите sudo unattended-upgrade --dry-run --debug, проверьте системные таймеры systemctl list-timers 'apt-*' и журналы в /var/log/unattended-upgrades/, если они предусмотрены установленной версией. Dry-run должен показать только разрешённые источники; неожиданный origin означает, что правила нужно исправить.

/etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Автоматическая установка не равна автоматической готовности

Unattended Upgrades не подтверждает работоспособность приложения, не решает конфликт зависимостей вместо администратора и не заменяет контроль restart/reboot. Автоматическую перезагрузку включают только при явно согласованном времени, проверенном канале восстановления и понятном поведении сервиса после загрузки.

DNF Automatic в RHEL-совместимых системах

Пакет dnf-automatic выполняет проверку, загрузку, установку или уведомление по конфигурации и выбранному systemd timer. В RHEL и совместимых дистрибутивах состав unit, параметры /etc/dnf/automatic.conf и доступные emitters могут различаться. Ниже приведён типичный маршрут; для конкретного клона ОС применяйте его официальное руководство, а не конфигурацию от другого дистрибутива.

Настройка dnf-automatic

1
Установите компонент и проверьте доступные таймеры
Выполните sudo dnf install dnf-automatic и systemctl list-unit-files 'dnf-automatic*'. Обычно встречаются dnf-automatic-notifyonly.timer, dnf-automatic-download.timer и dnf-automatic-install.timer, но состав unit зависит от выпуска.
2
Настройте тип обновлений
В /etc/dnf/automatic.conf в секции [commands] задайте upgrade_type = security, если ваш репозиторий публикует security-метаданные. Параметр apply_updates определяет установку для конфигурационного режима, но отдельные timer-unit могут задавать собственное поведение download, install или notify-only.
3
Настройте уведомления
В секции [emitters] выберите поддерживаемый emitter, например stdio, email или command; для почты заполните параметры секции [email] только после проверки локальной доставки. Если нужен внешний обработчик, используйте command лишь с контролируемым скриптом без секретов в аргументах.
4
Включите один подходящий timer
Для уведомлений без установки включите sudo systemctl enable --now dnf-automatic-notifyonly.timer; для предварительной загрузки — dnf-automatic-download.timer; для установки — dnf-automatic-install.timer. Используйте только unit, существующий в вашем выпуске, и не включайте несколько таймеров без понимания их перекрытия.
5
Проверьте и согласуйте расписание
Посмотрите фактические настройки выбранного таймера через systemctl cat имя.timer и следующее срабатывание через systemctl list-timers 'dnf-automatic*'. Если время нужно изменить, создайте drop-in командой sudo systemctl edit имя.timer: в секции [Timer] сначала сбросьте поставляемое значение строкой OnCalendar=, затем задайте согласованное OnCalendar= и при необходимости RandomizedDelaySec=. После сохранения выполните sudo systemctl daemon-reload, перезапустите выбранный timer и снова проверьте расписание. Доступные параметры и влияние пропущенного запуска сверяйте с документацией systemd и своего выпуска.
6
Проверьте журнал и доставку отчётов
Просмотрите журнал фактически запускаемого service-unit через journalctl -u имя.service --no-pager. Убедитесь, что отчёт содержит ожидаемые advisory, режим соответствует выбранному таймеру, а уведомления доходят до ответственного адресата.

/etc/dnf/automatic.conf

[commands]
upgrade_type = security
download_updates = yes
apply_updates = no

[emitters]
emit_via = stdio

Почему в примере apply_updates = no

Это консервативная стартовая настройка для режима уведомления или загрузки. Для автоматической установки используют согласованный install-timer и параметры, предусмотренные документацией установленного dnf-automatic. После изменения всегда проверяйте фактически активный unit и его журнал.

Live patching и обновления ядра

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

В Ubuntu Livepatch применим только к поддерживаемым ядрам и условиям сервиса Canonical; перед включением проверьте выпуск, ядро и статус в официальной документации.
В RHEL механизм kpatch зависит от поддерживаемого поставщиком ядра и доступных kpatch-пакетов или сервиса подписки; наличие пакета не означает покрытия всех CVE.
Live patch не отменяет плановую перезагрузку: она нужна для перехода на новый базовый kernel, применения непокрытых изменений, проверки загрузочной цепочки и накопившихся обновлений.

Экстренное обновление публичного сервера

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

Аварийный порядок установки патча

1
Подтвердите применимость
Сверьте advisory с установленной версией, ролью пакета, включёнными модулями и фактической экспозицией сервиса. Зафиксируйте идентификатор advisory/CVE, затронутые пакеты и причину срочности.
2
Оцените сервисное воздействие
Сделайте dry-run транзакции, определите необходимость restart службы и reboot. Подготовьте консольный доступ, проверку доступности и, если архитектура позволяет, вывод узла из балансировки.
3
Примените минимально достаточный патч
Установите конкретный пакет или согласованный security-набор штатным APT, DNF либо YUM. Не добавляйте в ту же транзакцию несвязанные обновления и изменения конфигурации.
4
Перезапустите необходимое и проверьте
Перезапустите только службы, для которых это требуется. Если исправление ядра должно быть активировано загрузкой нового ядра и не покрыто применённым live patch, выполните reboot в согласованном аварийном окне. Проверьте версии, systemctl, журналы, внешний health-check и отсутствие ошибок в приложении.
5
Оформите результат или исключение
Запишите время, исполнителя, транзакцию, фактические версии, перезапущенные службы и результаты проверки. Если патч нельзя применить немедленно, зафиксируйте остаточный риск, срок пересмотра и узкие компенсирующие меры; они не заменяют исправление.

Частоту регулярных обновлений выбирают по роли сервера, допустимому простою, степени внешней доступности и возможностям тестирования. Для плановых работ используйте повторяемое окно и контроль журналов; для критичных advisory — отдельный аварийный порядок. Полный процесс приоритизации CVE, сканирования, исключений и принятия риска описан в статье «Управление уязвимостями сервера: CVE, сканирование и приоритизация».

Термины в статье

Live patching: Live patching — технология применения исправлений к работающей ОС, обычно к ядру, без штатной перезагрузки; поддерживает только изменения, совместимые с механизмом патчинга.
Бюллетень безопасности: Бюллетень безопасности — официальное уведомление о риске или уязвимости, содержащее сведения о затронутых версиях, последствиях и мерах защиты.
Известно эксплуатируемая уязвимость: Известно эксплуатируемая уязвимость — уязвимость с подтверждёнными данными об использовании в атаках, требующая приоритетной оценки и устранения.
Конфигурационный дрейф: Конфигурационный дрейф — накопившееся отклонение фактической конфигурации системы от утверждённого эталона вследствие несогласованных или незафиксированных изменений.
Окно обслуживания: Окно обслуживания — согласованный интервал времени для плановых работ с ИТ-системой, когда допустимы ограничение функциональности, перезапуск или недоступность сервиса.
Остаточный риск: Остаточный риск — уровень риска, сохраняющийся после внедрения и применения мер защиты, включая технические, организационные и компенсирующие контроли.
Патч безопасности: Патч безопасности — обновление ПО, ОС или прошивки, устраняющее конкретную уязвимость либо снижающее риск её эксплуатации без обязательного изменения функциональности.
Управление патчами: Управление патчами — процесс учёта, оценки, тестирования, развёртывания и контроля обновлений ПО и прошивок для снижения риска уязвимостей и сбоев.
Уязвимость: Уязвимость — недостаток программного обеспечения, конфигурации или процесса, который при определённых условиях может быть использован для нарушения безопасности.

До обновления: выпуск ОС, роль сервера и доступ

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

Проверьте источники обновлений безопасности

Ubuntu и Debian: APT

RHEL-совместимые системы: DNF и legacy-YUM

Просмотрите транзакцию до установки

Симуляция рассчитывает зависимости, но не меняет систему. Результат зависит от версии менеджера пакетов и метаданных репозиториев.

Не соглашайтесь на план автоматически

Установка обновлений безопасности

Ubuntu и Debian: установка после проверки плана

RHEL-совместимые системы: DNF и YUM

Службы и перезагрузка после обновления Linux

Ubuntu и Debian

RHEL-совместимые системы

Назначение перезагрузки в окно обслуживания

Автоматические обновления Ubuntu и Debian: Unattended Upgrades

Настройка Unattended Upgrades с контролем

Автоматическая установка не равна автоматической готовности

DNF Automatic в RHEL-совместимых системах

Настройка dnf-automatic

Почему в примере apply_updates = no

Live patching и обновления ядра

Экстренное обновление публичного сервера

Аварийный порядок установки патча

Термины в статье

Вопросы по теме

Можно ли включить Unattended Upgrades без автоматической перезагрузки?

Что делать, если выпуск Linux достиг end of life?

Можно ли выполнять yum update --security на любом сервере?

Почему dnf update --security не показывает исправления?

Как понять, что обновление из APT действительно закрывает уязвимость?

Нужна ли перезагрузка после обновлений безопасности Linux?