Миф: Linux не нужно обновлять, он и так стабилен

MAATRIX

Сисадмин смотрит на аптайм в 400+ дней, видит uptime -p: up 1 year, 2 months и делает логичный на первый взгляд вывод: система работает, значит трогать её не нужно — обновление может что-то сломать, а зачем чинить то, что не сломано. Логика верна только наполовину: она путает два разных свойства системы, и именно эта путаница чаще всего приводит к взлому сервера, который годами казался образцово надёжным.

Стабильность и защищённость — это не одно и то же

"Стабильность" в контексте Linux обычно означает, что система не падает сама по себе: ядро не паникует без внешнего воздействия, демоны не крашатся от штатной нагрузки, файловая система не теряет данные при нормальном выключении. И тут миф прав — зрелые дистрибутивы вроде Debian, AlmaLinux или Ubuntu LTS действительно спроектированы так, чтобы годами работать без самопроизвольных сбоев. Это заслуга консервативной модели разработки: пакеты в стабильных ветках почти не меняют поведение между релизами, а бэкпортируются в них в основном как раз патчи безопасности.

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

Разница становится осязаемой, если задать себе простой вопрос: что именно не давало серверу упасть эти 400 дней? Ответ — отсутствие внешнего воздействия. Никто не пытался его специально уронить. Но это ничего не говорит о том, что случится, если попытаются — а именно это проверяют обновления безопасности.

Что на самом деле закрывают обновления безопасности

Когда исследователь или вендор находит уязвимость в OpenSSH, sudo, glibc, ядре или веб-сервере, ей присваивают идентификатор CVE (Common Vulnerabilities and Exposures) и публикуют описание — что именно уязвимо, при каких условиях эксплуатируется, насколько критично по шкале CVSS. Это публичная база данных: любой может её читать, включая авторов ботнетов и автоматических сканеров.

Отсюда ключевой момент, который миф упускает: необновлённый сервер — это не "работающая система, которую лучше не трогать". Это известная и опубликованная уязвимость, ждущая, когда до её IP дойдёт очередной проход сканера. CVE публикуется вместе с патчем практически одновременно (иногда патч выходит раньше публикации, иногда позже, но окно всегда конечное) — и с этого момента начинается гонка: у защитников есть патч, у атакующих есть публичное описание дыры и часто рабочий эксплойт на GitHub в течение суток-недели.

Массовое сканирование интернета по портам 22, 80, 443, 3389 и сигнатурам уязвимых версий ПО — это не таргетированная атака конкретно на вас, это фоновый шум интернета: боты вроде Mirai-подобных сетей или коммерческих сканеров непрерывно проходят весь IPv4-диапазон в поисках конкретных версий ПО с известными CVE. Сервер, который годами не обновлял OpenSSL, Apache/nginx, PHP или ядро, рано или поздно попадёт в выборку такого прохода — не потому что кто-то охотится именно на него, а потому что он статистически предсказуемо содержит одну из проверяемых дыр.

Важный нюанс: "стабильная" ветка дистрибутива (Debian stable, RHEL/AlmaLinux) специально держит версии пакетов замороженными и не гонится за новыми фичами — но патчи безопасности в неё бэкпортируют отдельно, без изменения общей версии пакета. Именно поэтому apt list --upgradable на "стабильном" сервере может показывать обновления даже без смены минорной версии дистрибутива — это не "нестабильность", это как раз механизм, которым система остаётся защищённой, не переставая быть стабильной.

Почему "работает — не трогай" усиливает риск, а не снижает его

У аргумента "не трогай, вдруг сломается" есть рациональное зерно: обновления действительно иногда вносят регрессии — несовместимость конфигов, изменение поведения демона, поломку зависимостей в проде. Это реальный риск, и опытные администраторы его не игнорируют — они им управляют, а не избегают ценой открытой дыры.

Но сравните последствия по вероятности и по тяжести:

Ключевая асимметрия: откат неудачного обновления — это штатная, хорошо изученная процедура (пакетные менеджеры хранят версии, есть снапшоты). А "откат" взлома — это инцидент-респонс, зачистка бэкдоров, смена всех секретов и, часто, разбор с клиентами и регулятором, если были утечки персональных данных. Риск регрессии асимметрично меньше риска эксплуатации, поэтому его стоит снижать процессом, а не устранять полным отказом от обновлений.

Как обновляться, не рискуя регрессией в проде

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

1. Разделяйте security-патчи и мажорные апгрейды. Это разные по риску операции, и объединять их в одно решение "обновляться или нет" — ошибка. Патч уязвимости в sudo или OpenSSL внутри той же мажорной версии дистрибутива почти никогда не меняет поведение приложения — он просто закрывает дыру в уже существующем коде. А переход с PHP 8.1 на 8.3 или с Ubuntu 22.04 на 24.04 — это отдельное, гораздо более рискованное событие с миграцией конфигов и проверкой совместимости. На Debian/Ubuntu это разделение уже встроено на уровне репозиториев:

# Ubuntu/Debian: только security-обновления, без апгрейда версий пакетов
sudo apt update
sudo apt-get -s dist-upgrade | grep -i security   # dry-run, посмотреть что подтянется
sudo unattended-upgrade --dry-run -d

На AlmaLinux/RHEL — аналогично через dnf-automatic с фильтром по типу апдейта:

sudo dnf install dnf-automatic
sudo sed -i 's/^upgrade_type = .*/upgrade_type = security/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer

Это уже разбиралось детально в статье про настройку автообновлений безопасности на VPS — там пошагово конфиг unattended-upgrades и dnf-automatic, а частые проблемы с ними (например, зависшие блокировки apt или пропущенные перезапуски сервисов) разобраны в статье про типичные ошибки автообновлений безопасности.

2. Тестируйте на staging перед проливом на прод. Не нужен полноценный клон инфраструктуры — достаточно второго небольшого VPS или локальной VM с той же версией дистрибутива и похожим набором сервисов, где сначала прогоняется тот же набор обновлений, а через день-два, если ничего не сломалось, — на прод. Для одиночного проекта это может быть даже Docker-контейнер с тем же базовым образом.

3. Снапшот перед крупным изменением. Перед мажорным апгрейдом (do-release-upgrade, смена major-версии PostgreSQL/MySQL, апгрейд ядра с ребутом) — обязательный снапшот диска на уровне гипервизора или LVM:

# LVM: снапшот тома перед рискованной операцией
lvcreate --size 5G --snapshot --name root_snap /dev/vg0/root

# после успешного апгрейда снапшот можно удалить
lvremove /dev/vg0/root_snap

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

Регулярность важнее размера обновления

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

Отсюда практический ритм для большинства проектов:

• Security-патчи (эта же мажорная версия дистрибутива) — автоматически или еженедельно вручную, без согласований.
• Минорные обновления пакетов (не security, просто новая версия) — раз в месяц, после проверки на staging.
• Мажорные апгрейды дистрибутива/СУБД — по плану, с окном обслуживания, снапшотом и полным регрессионным прогоном.

Такой ритм закрывает свежие CVE быстро (то есть убирает главный риск сканеров), но не превращает сервер в полигон для непроверенных мажорных изменений.

Постмортем: как забытый патч превращается во взлом

Ниже — типовой, собирательный сценарий, который регулярно повторяется на серверах "работает — не трогай" (это иллюстрация паттерна, а не описание конкретного реального инцидента с точными датами и цифрами).

Небольшой проект держит свой VPS с самостоятельно поднятым веб-приложением на Linux. Сервер настроили один раз, всё заработало, и с тех пор администратор заходит на него только когда что-то нужно поменять в коде приложения — пакеты ОС не трогает уже больше года, потому что "всё же работает". За это время в компоненте, который использует приложение (это может быть библиотека логирования, версия OpenSSH, устаревшая версия веб-сервера или интерпретатора — конкретный CVE тут не важен, важен паттерн), публикуют критическую уязвимость с публичным PoC-эксплойтом. Патч выходит в тот же день.

Дальше события развиваются по накатанной схеме автоматизированной атаки:

1. В течение нескольких дней после публикации CVE массовые сканеры добавляют сигнатуру уязвимой версии в свои проверки и начинают проходить весь диапазон адресов, включая IP этого сервера — не целенаправленно, а в порядке обычного скана.
2. Сканер находит совпадение по версии и либо сразу эксплуатирует уязвимость автоматическим скриптом, либо передаёт находку в очередь для более прицельной атаки.
3. Получив доступ, атакующий не сразу проявляет себя явно — типичное поведение это закрепление (новый SSH-ключ в authorized_keys, cron-задача, скрытый процесс), а уже потом — либо майнинг криптовалюты на серверных мощностях, либо использование сервера как плацдарма для дальнейших атак, либо кража данных приложения.
4. Замечают вторжение не сразу — часто это происходит, когда сервер начинает "тормозить" от постороннего процесса, приходит абьюз-жалоба от хостинга за исходящий спам-трафик или сканирование других хостов, либо падает продуктивность из-за конкурирующей нагрузки.
5. Разбор постфактум показывает: эксплуатированная уязвимость была публично известна и запатчена за много месяцев (иногда за год и больше) до инцидента. Сервер был взломан не "продвинутой атакой", а автоматическим сканером по давно опубликованному рецепту.

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

Частые вопросы