TuxCare ELS: обеспечение контролируемой эксплуатации старых версий Linux

Что дополняет TuxCare ELS

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

TuxCare Бессрочная поддержка на протяжении всего жизненного цикла for OS предоставляет обновления безопасности и отдельные исправления ошибок для поддерживаемых устаревших дистрибутивов. По заявлению производителя, предложение охватывает ядро и набор важных пакетов, зависящий от конкретного дистрибутива. При этом не устанавливается новая основная версия Linux: сервер продолжает работать на прежней версии дистрибутива и получает дополнительное обслуживание для компонентов, включенных в поддержку.

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

Die Крышка для посылки не следует приравнивать к безопасности всего сервера. Самостоятельно установленное приложение, расширение или служба из другого источника пакетов может выходить за рамки предложения операционной системы. Кроме того, ошибки в настройках и ненужные доступные службы не исчезают с оформлением подписки; их по-прежнему необходимо проверять и защищать.

Даже в случае пакетов, включенных в программу, степень серьезности имеет значение: TuxCare предусматривает исправления для уязвимостей с высоким и критическим уровнем риска, начиная с CVSS 7. По словам поставщика, для уязвимостей со средним уровнем риска (CVSS от 4,0 до 6,9) исправления могут быть предоставлены, если не существует мер по снижению риска и имеется достаточный спрос со стороны клиентов. Кроме того, TuxCare оставляет за собой право предложить меры по снижению риска вместо непосредственного исправления кода. Таким образом, то, что пакет включён в программу поддержки, не означает, что каждая известная уязвимость в нём будет устранена.

Поэтому решающим фактором является не только то, включена ли дистрибутив в список поддерживаемых. Для Безопасность Linux учитывает, какие компоненты используются на конкретном сервере, доступны ли соответствующие исправления и действительно ли они установлены. ELS дополняет процесс установки исправлений, но не заменяет ни инвентаризацию, ни план миграции.

Проверить крышку и инвентарь сервера

Перед выбором TuxCare ELS необходимо Инвентарь сервера. Укажите дистрибутив, а также точную версию, архитектуру и запущенное ядро. Кроме того, зафиксируйте настроенные источники пакетов и службы, доступные из открытых сетей или других сетей. Таким образом, можно сравнить список производителей с фактической конфигурацией системы, а не просто отметить название дистрибутива.

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

Сравните эти компоненты по отдельности с актуальным списком пакетов для соответствующего дистрибутива. Также проверьте архитектуру и условия предлагаемого решения. Поддерживаемый дистрибутив не означает, что каждый установленный в нём пакет или каждая версия среды выполнения автоматически поддерживается ELS for OS. Даже в случае поддерживаемых пакетов обработка отдельных уязвимостей зависит, в частности, от степени их серьезности.

Особенно легко упустить из виду программы, скомпилированные самостоятельно, и отдельно установленные среды выполнения. Кроме того, контейнерный образ содержит собственные компоненты: обслуживание хост-операционной системы не гарантирует, что пакеты в образе обновлены. Для таких компонентов требуется отдельное подтверждение и собственный процесс обновления.

ELS для ОС и ELS для различных областей применения — это отдельные предложения. Возможность обслуживания старой версии PHP в рамках дополнительного предложения зависит, в частности, от версии, формата пакета, архитектуры и способа получения. Еще одна возможная среда для старых приложений PHP описана в статье, посвященной CloudLinux Alt-PHP и вопросы безопасности; из этого следует, что данная услуга не входит в подписку на ОС TuxCare.

Правильно определять сроки оказания поддержки

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

В доступной на данный момент документации TuxCare для поддерживаемых операционных систем указано гарантированное время работы ELS, составляющее 25 лет начиная с указанной даты окончания первоначальной поддержки. В качестве примеров она приводит 30 июня 2049 года для CentOS 7 и 31 мая 2048 года для Ubuntu 18.04. Это данные поставщика о сроке поддержки, а не гарантия для каждого установленного приложения.

В случае с Ubuntu 18.04 компания Canonical выделяет несколько этапов: стандартная поддержка завершилась в мае 2023 года; поддержка Ubuntu Pro будет продолжаться до мая 2028 года. В текущем обзоре указан май 2033 года в качестве срока дополнительной поддержки устаревших версий. Эти предложения нельзя сравнивать исключительно по датам окончания поддержки, поскольку важную роль играют объем пакетов, архитектура и условия контракта для конкретного сервера.

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

Указанные сроки основаны на данных динамически обновляемых сайтов производителей по состоянию на 4 ноября 2026 года. Невозможно полностью ретроспективно проверить, действовали ли все актуальные сведения уже на эту дату. Поэтому перед публикацией или заключением договора следует ещё раз проверить сроки и списки пакетов и соблюдать соответствующие Состояние запросов точно. Даже долгосрочное обещание поддержки не является гарантией общей безопасности сервера.

Практическое внедрение сервера CentOS 7

Предположим, что веб-сервер под управлением CentOS 7 должен временно продолжить работу с устаревшим специализированным приложением. Прежде чем вы TuxCare ELS Выбирая эту опцию, вы определяете фактическое состояние системы и зависимости приложения. Решающим фактором является не только то, поддерживается ли CentOS 7, но и то, предусмотрены ли необходимые компоненты для имеющейся архитектуры.

Следующие команды можно выполнить на сервере в командной оболочке. Они выводят идентификатор дистрибутива, архитектуру машины и версию запущенного ядра; они не изменяют ни пакеты, ни источники пакетов. Запишите результаты в инвентарную ведомость сервера и сверьте их с актуальным руководством по CentOS 7.

cat /etc/os-release
uname -m
uname -r

Добавь это Инвентарь сервера настроенные источники пакетов, установленные версии пакетов и общедоступные службы. В случае веб-сервера к ним относятся, в частности, пакет веб-сервера, криптографические библиотеки, среда выполнения PHP и расширения. Также отметьте, какие компоненты были получены из сторонних источников или скомпилированы самостоятельно; они не должны считаться частью охвата ОС без соответствующей проверки.

Для CentOS 7 компания TuxCare указывает в качестве необходимых условий наличие действующего лицензионного ключа, прав root и HTTPS-соединений. Кроме того, в руководстве проводится различие по архитектуре: для aarch64 и i686 описывается поддержка пользовательского пространства, а исправление ядра в режиме реального времени — только для x86_64. Это ограничение касается руководства по CentOS 7 и не может быть обобщено на другие дистрибутивы.

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

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

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

В случае с CentOS 7 компания TuxCare описывает процесс регистрации системы, добавления репозитория пакетов и PGP-ключа. Этот репозиторий позволяет впоследствии загружать необходимые пакеты, однако он не устанавливает автоматически все доступные обновления. После настройки проверьте, правильно ли подключен репозиторий и предлагает ли менеджер пакетов соответствующие обновления.

При планировании необходимо учитывать наличие прокси-сервера или ограничительных правил исходящего трафика брандмауэра. В случае использования нескольких систем после согласования с TuxCare можно рассмотреть возможность создания локального зеркала. Не следует слепо копировать адреса назначения из общих часто задаваемых вопросов (FAQ): перед публикацией сверьте их с актуальной инструкцией для выбранного дистрибутива и предусмотренным способом работы.

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

Если ожидаемое обновление ещё не доступно, проверьте также Статус внедрения. Для нескольких платформ TuxCare выпускает обновления поэтапно; после публикации в стабильном репозитории это может занять до 14 дополнительных дней. При необходимости поставщик описывает обходной путь: используйте его только в соответствии с актуальной инструкцией для конкретного дистрибутива и конкретного выпуска, а также после получения разрешения от администрации. Продолжительность внедрения не означает гарантированного общего срока выпуска патча.

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

Сравнение вариантов технического обслуживания

Выбор между TuxCare ELS и расширенной поддержкой от производителя зависит от фактического набора пакетов и условий контракта. В таблице приведены примеры предварительного отбора, а не общие гарантии для каждой архитектуры или каждого пакета. Дата запроса — 4 ноября 2026 года; динамически обновляемые данные производителей и списки пакетов необходимо повторно проверить перед публикацией.

Стандартная поддержка Ubuntu 18.04 завершилась в мае 2023 года. Canonical указывает, что поддержка Ubuntu Pro будет предоставляться до мая 2028 года, а в своём текущем обзоре дополнительной поддержки устаревших версий — до мая 2033 года. TuxCare в настоящее время указывает 31 мая 2048 года в качестве даты окончания поддержки ELS для Ubuntu 18.04. Эти даты относятся к разным предложениям; более поздняя дата окончания поддержки не означает автоматически соответствующего покрытия пакетов.

Поэтому сравните Объем технического обслуживания для каждого необходимого пакета и фактически используемой архитектуры. В случае с Ubuntu особое значение имеют компоненты Main и Universe, а также условия для Pro и возможного дополнения Legacy. Кроме того, уточните, как можно подтвердить наличие исправлений CVE и соответствуют ли существующие процессы утверждения и обновления требованиям проекта.

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

Проверить уведомления CVE и бэкпорты

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

Причиной кажущихся противоречий может быть Бэкпорт : При этом исправление, связанное с безопасностью, переносится в более раннюю версию, при этом видимый номер версии «upstream» не соответствует номеру последнего выпуска. Поэтому сам по себе более ранний номер версии не доказывает ни того, что пакет уязвим, ни того, что сообщение сканера обязательно является ошибочным.

Сверьте конкретный CVE и версию установленного пакета с данными для вашего дистрибутива в трекере CVE от TuxCare. „In Testing“ означает, что исправление ещё находится на стадии тестирования; статус „In Rollout“ означает, что оно распространяется через репозитории Rollout. „Released“, напротив, означает полное выпущение для всех пользователей. Даже в этом случае необходимо проверить, действительно ли была установлена подходящая версия; „Not Vulnerable“ означает, что версия TuxCare не затронута уязвимостью.

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

Затем изучите базу данных и результаты анализа сканера. TuxCare предоставляет данные OVAL для ряда продуктов ELS; вам необходимо самостоятельно проверить, использует ли ваш инструмент данные, подходящие для конкретной системы, и правильно ли он их интерпретирует. Зафиксируйте версию пакета, статус CVE и время сканирования. Если результаты сравнения остаются неясными, продолжайте рассматривать данное обнаружение как нерешенное и уточняйте его с соответствующими специализированными подразделениями или поставщиком.

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

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

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

Кроме того, предусмотрите время на внесение изменений Окно обслуживания. Даже после успешного обновления пакетов запущенные процессы могут по-прежнему использовать старые библиотеки до тех пор, пока их не перезапустить. При необходимости приложения также нужно перезапустить; в случае изменений ядра может потребоваться перезагрузка системы. После перезагрузки проверьте как работу служб, так и ожидаемое состояние пакетов и системы.

KernelCare Live Patching — это дополнительный продукт, который следует отличать от регулярных обновлений пакетов ELS. Он позволяет применять поддерживаемые исправления ядра без остановки системы, но не заменяет ни все обновления, ни перезапуск служб или системы. Проверьте продукт, дистрибутив и архитектуру: для CentOS 7 компания TuxCare документирует функцию Live Patching ядра только для архитектуры x86_64. Дополнительные сведения приведены в статье о KernelCare Patch Feed.

Вывод uname -r отображает текущее ядро, но не полное состояние обновлений сервера. Например, установленный пакет ядра может начать действовать только после перезагрузки; с другой стороны, вывод не содержит информации о том, были ли обновлены и перезапущены библиотеки и приложения.

Выбрать временное решение или миграцию

Решение о том, достаточно ли TuxCare ELS для конкретного сервера, зависит от его фактических компонентов и рисков. Сравните необходимые пакеты с доступным охватом и выявите имеющиеся пробелы в приложениях, средах выполнения и стороннем программном обеспечении. ELS for OS охватывает набор, зависящий от дистрибутива; поддержка операционной системы не подразумевает обслуживание каждого приложения, работающего на ней.

Проверьте также оставшиеся уязвимости CVE в пакетах, для которых уже выпущены исправления. Согласно TuxCare, уязвимости со средним уровнем риска учитываются для выпуска патча только при соблюдении дополнительных условий; кроме того, поставщик может предложить меры по снижению риска вместо непосредственного исправления кода. Поэтому для каждой конкретной уязвимости оцените, доступно ли исправление или меры по снижению риска, а также являются ли оставшиеся риски приемлемыми для вашей деятельности.

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

Для общедоступного сервиса с неухоженным приложением или с несогласованным сроком действия одного только ELS может оказаться недостаточно. Поэтому ограничьте доступ только к действительно необходимым сетям и сервисам, удалите ненужные разрешения и контролируйте административный доступ. Это Ограничение сети уменьшает уязвимость системы, но не заменяет пропущенные обновления безопасности.

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

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