Итоги H1 2021: конец CentOS, ransomware на трубопроводах, supply-chain как новая норма

Полгода назад мы подводили итоги 2020-го с чётким ощущением: главное уже случилось, дальше будет нормализация. Нет. Первые шесть месяцев 2021-го оказались насыщеннее, чем хотелось бы - в плохом смысле слова.

Три темы стоят отдельно, потому что каждая из них сломала что-то, что считалось надёжным фундаментом.

Конец CentOS как точки опоры

Когда в январе Red Hat официально подтвердил, что CentOS 8 получает EOL 31 декабря 2021-го и остаётся только CentOS Stream, для большинства клиентов это было не новостью - скорее официальным закрытием вопроса, который висел с декабря 2020-го. Но закрытие вопроса потребовало открыть другой: на что мигрировать и когда.

У нас в обслуживании на начало года было несколько десятков серверов на CentOS 8. За полгода мы провели четыре миграции - три на AlmaLinux, одну на Rocky Linux - и разобрали что в них пошло не так. Инструменты миграции работают, но «нажал кнопку и готово» - это не про реальные окружения со сторонними репозиториями и DKMS-модулями.

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

AlmaLinux и Rocky Linux - рабочие альтернативы. Но у обоих нет того, что у CentOS было годами: истории, экосистемы сертифицированных вендорских агентов, доверия на уровне «это просто работает». Это придёт с практикой, но прямо сейчас - это управляемая неопределённость, не готовый ответ.

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

Ransomware добрался до трубопроводов

Colonial Pipeline в мае - это точка невозврата в разговоре о ransomware как угрозе для КИИ. Не потому что атака была технически уникальной - она была вполне стандартной для RaaS-схем. А потому что бензоколонки на восточном побережье США реально встали. Это перевело разговор из области «теоретических рисков» в область «последствий, которые видны на заправке».

Для нас это стало прямым поводом разобраться с несколькими клиентами из энергетики и транспортной отрасли: как у вас устроена OT/IT сегментация? Ответы, честно говоря, не удивили - но заставили ускориться. Плоские сети, VLAN-ы без жёстких ACL между корпоративным и промышленным сегментами, диспетчерские рабочие места в той же подсети что и офис.

Параллельно отработала волна по другим направлениям: ирландская система здравоохранения HSE была атакована Conti в мае, JBS - крупнейший производитель мяса - заплатил выкуп в июне. Ransomware последовательно тестирует КИИ разных отраслей, и успешные атаки учат других атакующих что работает.

Разговор с клиентами про резервное копирование и сегментацию шёл и раньше. Теперь он идёт иначе - без необходимости объяснять зачем. Это, наверное, единственный позитивный побочный эффект от того что происходит.

Что делаем во втором полугодии: приоритизируем OT/IT-сегментацию у клиентов с промышленными сетями, дожимаем аудиты по тем, кто записался после Colonial Pipeline.

Supply-chain как вектор, а не исключение

В январе мы разбирали SolarWinds - тогда это выглядело как разовый громкий инцидент уровня APT. К концу июня картина другая.

Codecov в апреле: скомпрометированный bash-скрипт собирал переменные окружения CI/CD у всех, кто его тянул через curl. Незаметно, два месяца. Нескольких наших пайплайнов это коснулось напрямую - пришлось ротировать токены и разбираться с правами.

Kaseya VSA в начале июля - уже за рамками полугодия, но вектор тот же: атакующие компрометируют не цель напрямую, а инструмент, которому цель доверяет. MSP-провайдеры, использующие Kaseya, автоматически стали вектором для supply-chain атаки на своих клиентов. Это не проблема Kaseya как продукта - это проблема модели «доверяю инструменту, потому что он мой».

Что объединяет все три инцидента: атакующие нашли место, где доверие встроено в процесс. Апдейт ПО системы мониторинга, скрипт в CI, агент удалённого управления. Именно там, где проверки нет - потому что «это же наш инструмент».

Конкретные вещи, которые мы зафиксировали для себя и клиентов:

• PIN-версий и проверка хешей для внешних скриптов в CI. Не «последняя версия», а конкретный тег и SHA256.
• Мониторинг изменений в критичном ПО. Если система управления инфраструктурой обновляется - это должно быть видно и явно подтверждено, не автоматически.
• Минимальные привилегии для CI-jobs. Каждый шаг пайплайна видит только те credentials, которые ему нужны - не все сразу.
• SBOM как практика, а не теория. Инвентаризация зависимостей и внешних компонентов - начиная хотя бы с критичных систем.

Что по итогу

Три не связанных между собой темы объединяет одно: они ударили по тому, что считалось надёжным. CentOS существовал больше пятнадцати лет. Критическая инфраструктура всегда была «слишком важной» для того, чтобы по ней реально ударили. Собственный инструментарий считался доверенным по определению.

Это не повод для паники - паника не помогает чинить инфраструктуру. Но это повод пересмотреть список допущений, которые лежат в основе текущих решений, и проверить: а на чём они вообще держатся?

Второе полугодие у нас расписано примерно под это: дожигаем миграции CentOS, закрываем аудиты по КИИ, выстраиваем процедуры проверки цепочки поставок там, где их не было. Работы хватает.