CentOS 7 под Zimbra после 30 июня 2024: сервер жив, ОС мертва

В декабре 2024 гостиница на 38 рабочих мест в Хамовниках получила от банка-эквайера отчёт внешнего сканирования: 61 находка, из них четырнадцать помечены как критические. Управляющий переслал мне PDF с вопросом «это всё про нашу почту?». Ответ оказался хуже, чем «да»: почти всё было про операционную систему под почтой, которая перестала получать обновления 30 июня 2024 года. Я сначала прочитал отчёт неправильно и потратил на это вечер.

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

Гостиница в Хамовниках, 38 рабочих мест: ресепшн, бронирование, бухгалтерия, служба питания, техническая служба. Почтовый сервер поставили в 2019-м под конкретную задачу — свои ящики на своём домене, календари для смен и два общих ящика — бронирования и банкетного отдела. С тех пор он просто работал. Управляющий гордился тем, что за пять лет ни разу не вызывал никого по почте.

Я это уважаю. Пять лет без единой заявки — хороший результат для железа в подвале.

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

У CentOS 7 этот второй календарь закончился 30 июня 2024 года. С этой даты ни ядро, ни glibc, ни системный openssl больше не получают исправлений. Всё, что живёт поверх — включая вашу почту — стоит на слое, который зафиксировали в состоянии на конец июня 2024-го и оставили.

PDF на девять страниц, 61 находка. Сканер внешний, смотрел на белый адрес гостиницы со стороны интернета. Я открыл его вечером девятого декабря и сделал ровно то, за что сам ругаю коллег: посмотрел на заголовки, а не на идентификаторы.

Заголовки были в духе «устаревшая версия компонента веб-сервера», «слабый набор шифров TLS», «раскрытие информации о версии». Порт 443, порт 25, порт 7071. Я решил: сканер ругается на Zimbra, значит, нужен апгрейд Zimbra, и полвечера прикидывал план подъёма версии.

Наутро сел разбирать отчёт по-человечески, по CVE-идентификаторам. И картина перевернулась.

# фактура с сервера, 10 декабря 2024
$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

$ rpm -q --last kernel | head -3
kernel-3.10.0-1160.119.1.el7.x86_64   Втр 04 июн 2024 02:11:37
kernel-3.10.0-1160.114.2.el7.x86_64   Чтв 22 фев 2024 09:40:02
kernel-3.10.0-1160.108.1.el7.x86_64   Птн 15 дек 2023 11:05:51

$ openssl version -a | head -2
OpenSSL 1.0.2k-fips  26 Jan 2017
built on: Thu May 30 15:21:47 2024

$ su - zimbra -c 'zmcontrol -v'
Release 9.0.0_GA_4192.RHEL7_64_20220331192416 RHEL7_64 FOSS edition, Patch 9.0.0_P39.

Одна деталь из этого вывода объясняет всё остальное. Почту ставили в 2019-м ещё на восьмёрку; сборка в строке релиза — весна 2022 года, потому что тогдашний подрядчик один раз поднял сервер до девятки и после этого пропал. Патч P39 накатили в начале 2024-го, тоже разово, после какой-то новости про Zimbra. А осенью вышел P41 с фиксом postjournal — и его уже не поставил никто. Итого за пять лет приложение трогали дважды, а операционную систему под ним не трогали ни разу.

Последнее ядро — начало июня 2024 года. Дальше пусто, потому что дальше ядер не выходило. Системный openssl — ветка 1.0.2, застывшая на дате сборки конца мая 2024-го.

Из 61 находки к самой Zimbra относились одиннадцать, и из них по-настоящему серьёзной была одна: патч-уровень P39 при том, что дыра в службе postjournal закрывается патчем P41 и выше. Всё остальное — про операционную систему: наборы шифров, версия системных библиотек, устаревшие компоненты базовой поставки.

Моя ошибка стоила вечера и была ровно той, которую совершает большинство: я считал, что «сервер» и «Zimbra» — одно и то же. Это два разных объекта обслуживания с разными сроками жизни.

Разберу по слоям, потому что «ОС устарела» — фраза без содержания.

Ядро

Локальное повышение привилегий — самая частая вторая ступень любой атаки. Злоумышленник попал внутрь через веб-приложение под непривилегированной учёткой, а дальше ему нужно стать root. Свежее ядро эту ступень усложняет, замороженное — нет. В нашем собственном разобранном инциденте со взломанной Zimbra 9 сервер стоял именно на CentOS 7.9, и путь наверх атакующий нашёл не в почте, а вокруг неё.

glibc и системные библиотеки

На них завязано всё, что не входит в поставку Zimbra: системный ssh, cron, sudo, утилиты. Дыра в любом из них после 30 июня 2024 остаётся открытой навсегда.

openssl — тут нюанс

Zimbra носит часть библиотек с собой, в /opt/zimbra/common, поэтому TLS почтовых служб не обязательно упирается в системный openssl версии 1.0.2. Проверяется одной командой:

$ /opt/zimbra/common/bin/openssl version
OpenSSL 1.1.1t  7 Feb 2023

Но всё, что снаружи почтового каталога — тот же системный ssh — шифруется системной библиотекой. Так что «у Zimbra свой openssl» успокаивает только наполовину.

Чего не происходит

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

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

А в рублях она считается в одну строку, и мы её посчитали с управляющим прямо на встрече. Через карты у гостиницы проходило порядка 2,9 млн ₽ в месяц — около 96 000 ₽ оборота в день. Ужесточение условий эквайринга на пару процентов — минус 58 000 ₽ ежемесячно на ровном месте. Отключение приёма карт хотя бы на неделю в сезон — под 670 000 ₽. Вся работа, которую я описываю ниже, обошлась дешевле трёх дней их оборота. После этой арифметики вопрос «а надо ли» не поднимался.

Четыре команды, все от root, кроме последней.

cat /etc/redhat-release 2>/dev/null || cat /etc/os-release | head -3
rpm -q --last kernel 2>/dev/null | head -2 || dpkg -l 'linux-image*' | tail -3
uptime
su - zimbra -c 'zmcontrol -v'

Читайте вывод так:

Последняя строка таблицы — та, из-за которой не работает очевидный план «давайте просто обновим операционку». Zimbra ставится сборкой под конкретное семейство и версию ОС, и это записано прямо в строке релиза.

Если у вас uptime больше 300 дней и при этом CentOS 7 — вы в самой типичной точке. По моим наблюдениям, такая связка встречается в каждой второй инсталляции, которую я вижу впервые.

Мне этот вопрос задают в каждом втором разговоре, и он абсолютно резонный. Отвечаю подробно.

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

Во-вторых, пакет Zimbra собран под конкретное семейство. В строке релиза так и написано: RHEL7_64. Это не косметика — там зависимости на версии системных библиотек, пути, юниты systemd. Поменять фундамент под установленным приложением нельзя, приложение придётся ставить заново.

В-третьих — и это правило, которое экономит больше всего нервов — при переносе Zimbra между машинами целевой сервер должен получить ту же операционную систему и ту же версию Zimbra, что на исходном. Попытка перенести данные с CentOS на Ubuntu «в лоб», одновременно сменив мажорную версию, ломается почти гарантированно.

Я это правило проверил на себе, за что и заплатил пятью часами. Двенадцатого декабря я поднял тестовую машину на Rocky Linux 8 — логика была «ну это же тот же RHEL-мир, соседняя мажорная» — и попробовал развернуть туда ту же сборку 9.0.0 для RHEL7. Инсталлятор ругнулся на зависимости, я начал подпирать, подпёр, установка прошла, а дальше mailboxd отказался стартовать. Я честно потратил на подпорки полдня, потом снёс виртуалку и сделал как положено: CentOS 7.9, та же 9.0.0.

Вывод простой. Смена ОС и перенос данных — две разные операции, и делать их одновременно нельзя. Либо переносите как есть и меняете ОС отдельным проектом, либо меняете платформу целиком, и тогда ОС меняется вместе с ней.

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

Последовательность, которую я использую:

# 1. на новой машине — та же ОС, тот же hostname, те же UID/GID
$ id zimbra
uid=999(zimbra) gid=999(zimbra) groups=999(zimbra)

# 2. установка без мастера конфигурации
# ./install.sh -s

# 3. остановить исходный сервер
$ su - zimbra -c '/opt/zimbra/bin/zmcontrol stop'

# 4. перенос данных
# rsync -avr --numeric-ids /mnt/migration/zimbra /opt

# 5. права после переноса, обязательно от root
# /opt/zimbra/libexec/zmfixperms

# 6. переустановка поверх перенесённых данных -> инсталлятор предложит upgrade, соглашаемся

Три места, где это ломается у тех, кто делает впервые.

UID и GID пользователя zimbra. На исходной машине они одни, на новой инсталлятор может выдать другие. После rsync вы получите каталог, где файлы принадлежат несуществующему числовому владельцу. У меня в этот раз было 999 против 1001, и я поймал это уже после копирования — спасибо флагу --numeric-ids, иначе разбирался бы дольше. Лечится запуском zmfixperms, но полтора часа он на 372 гигабайтах думает.

Hostname. Восстановление архива /opt/zimbra на машину с другим именем хоста — отдельный сорт боли. Проще сохранить имя и разобраться с DNS, чем переименовывать после.

Окно простоя. Копирование идёт при остановленной почте, иначе часть писем, пришедших во время копирования, останется на старом сервере. На 372 ГБ по гигабитной сети это 4–6 часов, и делать это надо ночью.

Сроки и деньги на нашей гостинице: 14 часов работ, 56 000 ₽ по ставке 4 000 ₽ в час, окно с 23:00 пятницы до 5:40 субботы. Это купило нам снапшоты, свежий гипервизор и спокойный февраль для настоящего переезда.

Логика здесь обратная: раз ОС всё равно надо менять, а Zimbra всё равно надо переставлять — не переставлять ли сразу на то, что развивается.

Мы выбрали Carbonio Community Edition. Причины прагматичные: тот же фундамент — Postfix, OpenLDAP, Jetty, — сделана той же командой Zextras, и админ, знающий Zimbra, не начинает с нуля. Рекомендуемая под неё ОС — Ubuntu 24.04 LTS, то есть операционная система обновляется вместе со сменой платформы, а не отдельным подвигом.

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

Порядок, который отработан:

1. Инвентаризация через zmprov: домены, ящики, алиасы, списки, выгрузка хешей паролей;
2. Установка новой платформы на Ubuntu 24.04, создание доменов и учёток с временными паролями, импорт хешей;
3. Поднять лимит размера письма перед переносом, иначе крупные письма с вложениями молча отвалятся;
4. Прогоны imapsync по группам ящиков, крупные — отдельными окнами;
5. Служебные учётки (galsync, spam, ham, virus-quarantine) не переносить: платформа создаёт их сама;
6. Переключение DNS — A, MX, SPF, DKIM, DMARC, PTR — после проверки, старый сервер держим неделю;

Грабли на новой ОС, о которых лучше знать заранее. На Ubuntu 24.04 у amavis случается конфликт версий OpenSSL — лечится добавлением LD_LIBRARY_PATH в systemd-override для юнита. Второе: fail2ban на этой связке нужно переводить в режим backend = polling, иначе он просто не видит логи и делает вид, что всё хорошо. Оба пункта отнимают по часу, если знаешь, и по полдня, если нет.

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

Декабрь 2024, этап первый. 11 декабря накатили патч 9.0.0_P41 — закрыли ту единственную по-настоящему серьёзную находку по самой Zimbra. В ночь с 13 на 14 декабря перенесли сервер на новую виртуалку на свежем гипервизоре, той же CentOS 7.9 и той же 9.0.0. 14 часов работ, 56 000 ₽. Банку отчитались: критические находки по приложению закрыты, по операционной системе — план и срок.

Февраль 2025, этап второй. Переезд на Carbonio CE, Ubuntu 24.04. 44 ящика, из них 38 живых, 372 ГБ store, 19 ГБ index. Переносили четырьмя окнами по вечерам: сначала 35 обычных ящиков, потом ящик бронирования на 84 ГБ, отдельно общий ящик банкетного отдела, отдельно архив управляющего — 38 живых ящиков ровно по списку. Смета была на 44 часа, то есть 176 000 ₽ по ставке 4 000 ₽ в час.

Что пошло не по плану. Общий ящик банкетного отдела жил у гостиницы с 2019 года и накопил 186 тысяч писем в одной папке без единой подпапки. imapsync на нём споткнулся дважды: сначала по таймауту, потом на письмах с нестандартными тегами, выставленными старым клиентом. Разбили перенос на диапазоны по датам, догнали за три прохода. По факту на второй этап ушло 52 часа вместо сорока четырёх. Восемь часов сверх сметы я перевыставлять не стал — сам недооценил ящик, хотя размер его видел заранее, — так что счёт остался на 176 000 ₽.

Сверка по числу писем сошлась везде, кроме той же общей папки: расхождение 41 письмо. Все 41 оказались с пустой темой и пустым телом — артефакты, порождённые ещё на старом сервере. Проверил вручную, спокоен.

Итого гостиница потратила 232 000 ₽ за два месяца и получила почту на поддерживаемой платформе и поддерживаемой ОС. Если бы всё делали одним заходом в декабре под давлением банковского срока — вышло бы дешевле по деньгам и заметно хуже по нервам.

Сначала разделите два вопроса, которые обычно склеены в один: «что с почтой» и «что с сервером под почтой». Ответы на них разные, сроки разные, деньги разные.

Дальше по порядку:

• Снимите вывод четырёх команд из блока проверки. Это займёт минуты и даст точку отсчёта;
• Если патч-уровень Zimbra отстаёт — закрывайте его первым, отдельно от всей истории с ОС. Это дёшево и быстро;
• Посчитайте объём store и найдите самый большой ящик. Эти две цифры определяют длительность любого переноса больше, чем что-либо ещё;
• Решите, есть ли у вас внешний срок. Если банк или аудитор дал 60 дней — двухэтапная схема реалистична, одноэтапная почти нет;
• Если внешнего срока нет — не делайте промежуточный клон. Идите сразу на новую платформу с современной ОС, это дешевле в сумме.

Чего я делать не советую, хотя такое предлагают. Не пытайтесь тянуть CentOS 7 на сторонних сборках ядра и самособранных пакетах openssl. Технически можно. Практически вы получаете систему, которую не сможет обслуживать никто, кроме автора этих подпорок, и первая же нештатная ситуация превращается в раскопки.

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

Хотите быстрый ответ по своей ситуации — пришлите мне вывод четырёх команд из блока проверки и скажите число сотрудников. Отвечу, сколько у вас реально времени, какой путь дешевле именно у вас и какой объём работ за этим стоит. Обычно на это уходит день.

Можно ли обновить CentOS 7 до 8 или 9 прямо под работающей Zimbra?

Штатного пути обновления на месте между мажорными версиями в этом семействе не существует — переходы всегда делались переустановкой. Есть народные скрипты миграции, и они иногда даже отрабатывают, но применять их под живой почтой с сотнями гигабайт данных я не берусь. Слишком много движущихся частей: зависимости пакетов, systemd-юниты, права в /opt/zimbra. Плюс сама Zimbra собрана под конкретное семейство ОС, что прямо написано в строке релиза как RHEL7_64. Даже успешная миграция ОС оставит вас с приложением, собранным под предыдущую версию. Правильный путь — новая машина и перенос.

У нас Zimbra носит свой openssl. Значит, системный неважен?

Наполовину. Проверьте командой /opt/zimbra/common/bin/openssl version — там действительно может стоять ветка новее системной, и TLS почтовых служб пойдёт через неё. Но операционная система — это не только openssl. Ядро, glibc, системный ssh, sudo, cron живут вне каталога Zimbra и обновляются вместе с ОС, то есть с 30 июня 2024 года не обновляются вовсе. Локальное повышение привилегий через дыру в ядре — стандартная вторая ступень атаки после того, как злоумышленник попал внутрь. Именно этот слой и остаётся замороженным.

Сканер банка дал 61 находку. Это же надо закрыть все?

Нет, и разбирать их надо по идентификаторам, а не по заголовкам — я сам на этом обжёгся и потерял вечер. В нашем случае из 61 находки к самой Zimbra относились одиннадцать, а по-настоящему критической была одна: отставший патч-уровень. Остальные полсотни были про операционную систему и закрывались не патчами, а переносом. Практический порядок такой: сначала отфильтруйте находки по объекту — приложение или ОС; затем закройте всё, что закрывается патчем приложения, это дёшево; и только потом стройте план по ОС, потому что он длинный и требует окна.

Сколько времени занимает перенос и сколько почта будет лежать?

Это два разных числа, и путать их не надо. Общая длительность проекта у нас была 52 часа работ, растянутых на февраль. А простой пользователей — минуты, потому что imapsync гоняли при живом старом сервере, инкрементально, и переключали только MX в конце. Если же вы идёте путём клона на новую машину той же конфигурации — там простой настоящий, потому что копировать надо при остановленной почте: на 372 ГБ по гигабитной сети это 4–6 часов ночью. Прикидка по объёму: считайте примерно 60–80 ГБ в час на копирование и добавляйте время на проверки.

Нам не нужна Carbonio, мы хотим остаться на Zimbra. Так можно?

Можно, и иногда это правильно. Тогда схема такая: новая машина, современная поддерживаемая ОС, актуальная ветка Zimbra, перенос данных. То есть ровно тот же объём работ, только целевая платформа другая. Экономии здесь нет — вся стоимость переезда сидит в переносе данных и сверке, а не в том, какое приложение стоит на приёмной стороне. Смысл остаться есть, если у вас развесистые общие календари, интеграции по LDAP и админ, который живёт в этой системе годами. Тогда переучивание людей стоит дороже, чем разница в платформах. Одна оговорка, которая меняет смету, и её лучше узнать сейчас. «Актуальная поддерживаемая ветка Zimbra» на сегодня — это десятка, а она выпускается только как Network Edition: свободной редакции у неё нет, и без лицензионного ключа инсталлятор апгрейд не начинает. Бесплатная линия закончилась на 8.8.15 и девятке. Так что «остаёмся на Zimbra» для бесплатной инсталляции означает либо ежегодную лицензию отдельной строкой в бюджете, либо осознанное решение сидеть на девятке до конца её жизненного цикла.