Конец поддержки Zimbra 8.8.15: что делать бизнесу на ней в 2026

В марте 2026 меня позвали в медклинику на 26 рабочих мест на Дмитровском шоссе: страховой партнёр прислал анкету по защите персональных данных, и в графе «почтовый сервер, версия, дата последнего обновления безопасности» никто не знал, что писать. Сервер стоял с 2019 года и работал. Я снял фактуру за час, потратил день на неверную версию событий и в итоге положил на стол три сметы вместо одной.

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

Заполнить её было некому. Админ, который ставил сервер, ушёл в 2022-м. Приходящий подрядчик отвечал за рабочие станции и в почту не лез принципиально: «работает — не трогаем».

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

Сама ситуация массовая. Zimbra Collaboration Suite ставили в России пачками в 2017–2020 годах: бесплатно, по-русски, с календарями и общими папками, вместо дорогого Exchange. Потом сервер начинал работать, и о нём забывали — ровно до того дня, когда кто-то со стороны задаёт вопрос про версию. У ветки 8.8.15 в бесплатной редакции общая поддержка закончилась 31 декабря 2023 года. На март 2026 это не «скоро», а два года и три месяца без обновлений безопасности.

Контр-довод, который я слышу постоянно и считаю вредным: «нас никто не ищет, мы маленькая клиника». Ищут не вас. Ищут порт и баннер версии. Массовые сканы не разбирают, где юрфирма, а где поликлиника.

Клиника занимает два этажа в бизнес-центре у метро. 26 рабочих мест: врачи, регистратура, страховой отдел, бухгалтерия на аутсорсе. Сервер — виртуалка на локальном гипервизоре в серверном шкафу за дверью процедурного кабинета. Доступ мне дали через тимвьюер администратора рабочих станций, потому что root-пароль нашёлся в блокноте.

Первый час — снятие фактуры. Вот что я увидел.

$ su - zimbra -c 'zmcontrol -v'
Release 8.8.15_GA_3869.RHEL7_64_20190917004220 RHEL7_64 FOSS edition, Patch 8.8.15_P46.

$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

$ su - zimbra -c 'zmprov -l gaa' | wc -l
31
$ su - zimbra -c 'zmprov gad'
klinika.local
med-domain.ru

$ du -sh /opt/zimbra/store /opt/zimbra/index /opt/zimbra/db
226G	/opt/zimbra/store
11G	/opt/zimbra/index
6.1G	/opt/zimbra/db

$ uptime
 11:42:07 up 619 days,  3:11,  1 user,  load average: 0.71, 0.63, 0.55

Тридцать один ящик, из них пять служебных — galsync, spam, ham, virus-quarantine и учётка уволившегося админа, которую никто не отключил. Живых пользовательских — 26, ровно по головам.

Патч-уровень меня удивил. P46 — это не запущенный сервер. Кто-то ставил патч уже после ухода админа. Оказалось, в сентябре 2024 подрядчик по станциям прочитал новость про уязвимость в Zimbra, испугался и накатил патч из репозитория. Один раз. Больше не возвращался. Заодно снимаю вопрос, который тут обычно возникает: установка патча не требует перезагрузки машины, поэтому аптайм от неё не сбрасывается — сентябрьский патч и 619 дней без ребута спокойно уживаются на одном сервере.

Аптайм 619 дней — отдельная строчка. Ядро на этой машине не перезагружали с лета 2024-го, то есть все обновления ядра, если бы они выходили, всё равно не применились бы.

Дальше я потерял день. Честно расскажу как.

P46 для 8.8.15 закрыл RCE через службу postjournal — ту самую дыру, по которой в конце сентября 2024 года пошли массовые атаки. Ключевая деталь: ветка была снята с общей поддержки ещё 31 декабря 2023-го, а патч всё равно вышел. Вендор выкатил его вне жизненного цикла, потому что дыра была слишком громкой.

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

Проверил на следующее утро. Взял февральские уязвимости 2025 года — SQL-инъекцию в SOAP-эндпоинте ZimbraSync Service и SSRF в парсере RSS-фида. Посмотрел, для каких версий вышли исправления: 10.0.12, 10.1.4, для девятки — Patch 43. Ветки 8.8.15 в перечне исправленных нет ни в каком виде.

Взял ноябрьскую историю 2025 года — хранимый XSS в классическом веб-интерфейсе через директивы CSS @import. Исправлено в 10.0.18 и 10.1.13. Восьмёрка снова не упомянута.

Вот в чём фокус, и он неприятнее, чем «вы уязвимы». Для 8.8.15 вендор больше не публикует ни патчей, ни бюллетеней. Значит, по каждой новой уязвимости вы не можете ни подтвердить, ни опровергнуть, что она вас касается: никто не проверял. P46 был исключением, а не правилом — последняя дверь, которую вообще закрыли. Следующих не будет.

Я ошибся, потому что принял разовое решение вендора за политику. Стоило это клинике ноль рублей, а мне — испорченный четверг.

Пять команд. Выполнять от пользователя zimbra, кроме второй и последней — эти две от root.

su - zimbra -c 'zmcontrol -v'
cat /etc/redhat-release 2>/dev/null || cat /etc/os-release | head -2
su - zimbra -c 'zmprov -l gaa' | wc -l
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled'
du -sh /opt/zimbra/store

Первая строка вывода — самая важная. Читайте её так:

Вторая команда показывает операционную систему. Если там CentOS Linux release 7 — под почтой ещё один мёртвый слой: эта ветка не обновляется с 30 июня 2024 года.

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

Если результат вас расстроил — вы не в исключительном положении. У большинства инсталляций, которые я вижу, картина ровно такая.

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

Что входит по делу:

• Убрать веб-почту и админку из прямого доступа: 7071 закрывается наглухо, 443 прячется за обратный прокси с ограничением по географии и rate-limit;
• Отключить неиспользуемые службы — postjournal в первую очередь, если журналирование не нужно;
• Проверить zimbraMtaMyNetworks, чтобы сервер не оказался открытым релеем;
• Fail2ban на mailbox.log и audit.log, отдельными джейлами на веб и на IMAP;
• Работающий бэкап с проверенным восстановлением — в бесплатной редакции штатного средства нет, схему собираем скриптами;
• Ежемесячный регламент: очередь, тома, индексы, сертификаты, свежесть антивирусных баз.

Три команды, с которых у меня начинается любой такой разбор:

ss -lntp | grep -E ':(25|110|143|443|993|995|7071)\s'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraMtaMyNetworks'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled'

Сроки и деньги на 26 ящиках: 22 часа работ, из них 6 — на бэкап-схему и учения по восстановлению. По нашей ставке 4 000 ₽ за час это 88 000 ₽ разово плюс регламент 4 часа в месяц — 16 000 ₽ ежемесячно. Календарно укладывается в две недели без остановки почты.

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

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

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

Начну с того, о чём в обсуждениях апгрейда почему-то молчат. Десятка — она же Daffodil — выпускается только как Network Edition. Свободной редакции у неё нет вообще: инсталлятор требует лицензионный ключ, и без ключа апгрейд просто не стартует, это записано в документации вендора прямым текстом. На mailbox-сервере при этом должна подняться отдельная служба лицензирования, иначе установка обрывается. Ключ покупается до начала работ, лицензия годовая и считается по числу ящиков. А процедура покупки российским юрлицом с 2022 года — отдельный сюжет: кто продаёт, как платить, что будет через год при продлении. Для клиники, которая семь лет прожила на бесплатной редакции, это не строчка в смете, а новая статья расходов навсегда.

Теперь техника, и тут я хочу поправить распространённый тезис. «С 8.8.15 нельзя сразу на 10, надо через девятку» — неправда: условие апгрейда сформулировано как исходная система на 8.8.15 или 9.0 с последним патчем, девятка обязательной ступенью не выступает. Барьера три, и версия среди них последняя. Первый — догнать исходную ветку до последнего доступного патча, инсталлятор к этому придирчив. Второй — лицензия. Третий — CentOS 7 под сервером, на которую десятка не ложится. Из-за третьего это в любом случае не апгрейд, а стройка новой машины с переносом данных, где подъём версии лишь один из этапов. Плюс на форуме вендора висит ветка людей, у которых прямой переход на десятку в их конфигурации не прошёл — так что закладывать надо проект, а не команду.

Порядок, который я закладываю в смету:

1. Новый сервер, современная ОС, снапшот исходной машины как точка отката;
2. Инвентаризация: домены, ящики, хеши паролей, алиасы, списки рассылки, фильтры;
3. Перенос почты и подъём до целевой ветки, ступень за ступенью, каждая — с проверкой;
4. Сверка: число писем по ящикам, папки, флаги, даты;
5. Переключение MX в выходное окно, старый сервер держим неделю как запасной аэродром.

su - zimbra
zmprov gad > /migration/domains.txt          # домены
zmprov -l gaa > /migration/users.txt         # ящики
for u in $(cat /migration/users.txt); do
  zmprov -l ga $u userPassword | grep userPassword: | awk '{print $2}' > /migration/$u.shadow
done

Длинные операции — только в screen. Обрыв сессии на импорте способен повредить базу, и это не теория: я такое видел.

Сроки и деньги: 46 часов, календарно три-четыре недели с учётом согласований и ночного окна. По ставке — 184 000 ₽. Плюс железо или ресурсы гипервизора под вторую машину на время переезда. И плюс лицензия Network Edition на 26 ящиков — ежегодно, отдельной строкой, оплаченной до того, как я вообще притронусь к инсталлятору.

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

Отдельная неприятность в этой ветке, которую надо знать заранее. В линейке 10.1 между версиями 10.1.7 и 10.1.8 появился регресс: архивная выгрузка ящика целиком буферизуется в памяти java-процесса, и на больших ящиках zmmailbox валится по OutOfMemoryError. Бэкпортом это уехало и в 10.0.16 с 10.0.18. То есть новая ветка — не гарантия спокойствия, а другой набор граблей.

Здесь развилка внутри развилки: технически похожая замена или продукт из реестра отечественного ПО.

Carbonio Community Edition

Собрана той же командой Zextras и на том же фундаменте — Postfix, OpenLDAP, Jetty. Для администратора это узнаваемая система, а не переучивание с нуля. Штатного инструмента миграции с Zimbra нет, переносят через imapsync плюс отдельно учётки и хеши паролей. Community-редакция стоит ноль, деньги — только за работы.

Российский продукт из реестра

Если ваш заказчик или регулятор смотрит на реестр Минцифры, вот номера, которые придётся вписывать в бумаги: CommuniGate Pro — №7112, Mailion от МойОфис — №12707 плюс сертификат ФСТЭК №4648, RuPost — №14647, Tegu — №9811, МойОфис Почта — №73. Самой Zimbra в реестре нет и не будет: это американская open-source разработка.

Сильный аргумент, который я показываю клиентам, когда разговор упирается в «а вдруг это перебор». «Группа Астра» — российский разработчик операционной системы — сама сидела на Zimbra Collaboration Suite. В середине августа 2023 года они начали переводить сотрудников на собственный RuPost, к 26 октября того же года перевели около 80% из запланированных 1700 пользователей. Компания, которая делает импортозамещающую ОС, не стала держать у себя Zimbra. Это не маркетинг, это их собственный внутренний проект.

Технически миграция на любой из этих продуктов идёт одинаково — через IMAP. Штатных «зимбра-совместимых» коннекторов нет ни у одного. Различаются лицензии, интерфейс и то, что вы напишете в анкете.

Сроки и деньги для 26 ящиков и 226 ГБ: на Carbonio CE — 38 часов, 152 000 ₽, три недели календарно. На реестровый продукт — те же 38–44 часа плюс стоимость лицензий, которую считает вендор от числа пользователей.

Выбрали Carbonio CE. Решающим оказался не мой расклад, а вопрос директора: «через сколько лет мы вернёмся к этому разговору». По сценарию А — через год. По Б — когда упрёмся в обновления. По В — когда платформа сама доживёт до конца жизненного цикла, а это годы.

Как шли:

• 4 марта — инвентаризация, выгрузка списка ящиков и хешей паролей, замер объёмов по каждому ящику;
• 6–7 марта — новый сервер, установка платформы, домены, учётки с временными паролями, импорт хешей;
• 10–18 марта — почта. Четыре окна: сначала 22 обычных ящика, следом общий ящик регистратуры, потом два по 30 с лишним гигабайт, отдельно архив главврача на 61 ГБ;
• 19 марта — сверка по числу писем в каждой папке, разбор расхождений;
• ночь с 21 на 22 марта — переключение MX, проверка входящей и исходящей, DKIM и SPF на новой площадке;
• до 29 марта — старый сервер жив и принимает, но не отдаёт наружу. Запасной аэродром.

Итог в цифрах: перенесли 26 живых ящиков и 219 ГБ почты — в store старого сервера лежало 226 ГБ, разницу дали служебные учётки и мусор, который не поехал. 41 час вместо запланированных 38 — три часа съел архив главврача, где 2 400 писем не переносились из-за пары нестандартных тегов на сообщениях. Простой пользователей — 40 минут в воскресенье утром. Счёт — 164 000 ₽.

Расхождение по сверке нашлось одно: 17 писем в папке «Отправленные» у регистратуры. Разбирались полтора часа, оказались дубли, созданные ещё на старом сервере кривым почтовым клиентом. На новый они просто не поехали, и это было правильно.

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

Порядок простой, и первые два шага вы сделаете сами.

Снимите вывод пяти команд из блока выше. Посчитайте живые ящики отдельно от служебных. Посмотрите объём store — от него зависит длительность любого переноса, и по моему опыту на 200–250 ГБ уходит 25–40 часов работ независимо от целевой платформы.

Дальше три вопроса, на которые отвечаете не вы, а бизнес:

Что я думаю сам, без обиняков. Для компании до 50 рабочих мест сценарий Б — самый слабый по соотношению «деньги на выходе». Вы платите почти как за переезд, получаете ту же платформу, с которой всё равно предстоит разговор, и вдобавок подписываетесь на ежегодный платёж вендору, которого на бесплатной редакции не было ни разу. Сценарий А хорош ровно как отсрочка с открытыми глазами. Сценарий В дороже А и дешевле Б, и заканчивает тему на годы.

Но это моё мнение по средней больнице, а не приговор. Я видел инсталляции, где апгрейд был правильным решением: развесистые общие календари, интеграции по LDAP, свой админ, который живёт в этой системе. Там переезд ломает рабочие процессы дороже, чем экономит.

И про то, что стоит бездействие, потому что этот вопрос мне задают в каждом втором разговоре. Через страхового партнёра, приславшего анкету, к клинике шло около 90 пациентов в месяц при среднем чеке 6 900 ₽ — это 621 000 ₽ выручки ежемесячно. Незаполненная анкета не означает разрыв договора завтра. Она означает, что вопрос вернётся, и вернётся уже в форме «подтвердите до такого-то числа». Три сценария выше стоят от 88 до 184 тысяч разово. Один месяц без этого партнёра стоит дороже любого из трёх.

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

У нас стоит Patch 46 — это же последний, значит мы защищены?

P46 закрыл конкретную дыру — выполнение кода через службу postjournal, по которой в конце сентября 2024 года шли массовые атаки. Он действительно последний, который вендор выпустил для 8.8.15, и выпустил уже после снятия ветки с поддержки. Но «последний» и «защищены» — разные вещи. По уязвимостям, которые находили после этого, исправления выходили для 10.0.12, 10.1.4, для девятки Patch 43, дальше для 10.0.18 и 10.1.13. Восьмёрки в этих перечнях нет вообще. Никто не проверял, касаются вас эти дыры или нет, и никто не проверит. Так что формулировка честная: у вас максимум того, что существует, и этого максимума мало.

Можно ли обновиться с 8.8.15 сразу до 10 одной командой?

Не одной командой и не только из-за версии. Начну с главного, о чём обычно не пишут: десятка существует только как Network Edition. Инсталлятор требует лицензионный ключ и без него апгрейд не начинает, а на mailbox-сервере должна подняться служба лицензирования. Свободной десятки не существует, так что первый шаг сценария — не команда, а покупка лицензии по числу ящиков, ежегодная. Дальше техника. Прямой переход с 8.8.15 на 10 документацией допускается: условие — исходная система на 8.8.15 или 9.0 с последним патчем, девятка обязательной ступенью не является. Зато мешает другое: у большинства российских инсталляций 8.8.15 живёт на CentOS 7, а десятка на неё не ставится. То есть в реальности это разворачивание новой машины с переносом данных, где подъём версии — один из этапов. На форуме вендора есть целая ветка людей, у которых прямой апгрейд до 10 в их конфигурации не прошёл. Планируйте проект на три-четыре недели, а не вечер.

Что дешевле — остаться и защищаться или переехать?

На 26 ящиках у меня вышло так: харденинг — 22 часа и 88 000 ₽ разово плюс 16 000 ₽ в месяц за регламент; переезд на Carbonio CE — 38 часов и 152 000 ₽ разово, дальше только обычное обслуживание. Точка окупаемости переезда наступает примерно через четыре месяца регламента. Но считать надо не только это. Харденинг не закрывает дыры внутри самого приложения: XSS через содержимое письма прокси не остановит, письмо приходит легально по 25-му порту. Так что вы выбираете не между дешевле и дороже, а между отсрочкой и решением.

У нас медицинские данные. Насколько EOL-версия — это проблема с точки зрения проверки?

Прямого запрета «нельзя использовать ПО, снятое с поддержки» в законе нет. Проблема приходит с другой стороны. Уязвимости Zimbra аккуратно ведутся в банке данных угроз ФСТЭК, а БДУ — обязательный источник при оценке угроз для аттестуемых систем. Когда у вас в модели угроз стоит почтовый сервер, версия которого фигурирует в БДУ, а обновлений для неё не существует, закрыть эту угрозу организационными мерами тяжело. Плюс бытовая часть: анкеты партнёров и страховых, где надо писать дату последнего обновления безопасности. У клиники это и стало спусковым крючком, а не проверка.

Мы точно хотим что-то российское. С чего начать выбор?

Начните с вопроса, зачем вам реестр: требование заказчика, госконтракт, внутренняя политика или просто настроение руководства. От ответа зависит всё. Если формально нужна запись в реестре Минцифры — смотрите CommuniGate Pro (№7112), Mailion (№12707, плюс сертификат ФСТЭК №4648), RuPost (№14647), Tegu (№9811), МойОфис Почта (№73). Если реестр не обязателен, а нужна живая поддерживаемая платформа — Carbonio CE дешевле и ближе по духу к тому, что у вас уже стоит. Технически перенос почты во всех случаях идёт через IMAP, готовых коннекторов под Zimbra нет ни у кого. Кстати, «Группа Астра» ушла со своей Zimbra на собственный RuPost ещё в 2023 году — 1700 пользователей.