Двухфакторная аутентификация в Zimbra OSE: чего в ней нет

Торговая компания в Подольске, 36 рабочих мест, прислала мне в июле 2024 короткое сообщение: «прочитали, что в Zimbra есть двухфакторка, включите нам, у нас OSE». Пришлось объяснять, что именно у них её и нет — и это не ошибка настройки, а редакция. Разбираю разницу между версиями честно: где 2FA живёт, что реально даёт TOTP, чего в бесплатной версии нет и почему обходной путь через портал с внешней двухфакторкой оказался дешевле лицензий на всех.

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

Первое, что я сделал, — проверил, что у них реально стоит:

zmcontrol -v
# Release 9.0.0.OSE ...  <- OSE = Open Source Edition
zmprov gaa | wc -l          # 36 ящиков, всё сходится

OSE. Open Source Edition. Бесплатная версия, в которой встроенной двухфакторной аутентификации нет вообще — ни в вебе, ни где-либо ещё. Это не выключенная опция, которую я мог бы им включить. Это отсутствующая функция. И вот тут начинается честный разговор про редакции, который мало кто ведёт заранее.

Двухфакторка в экосистеме Zimbra есть, но приходит она из трёх мест, и ни одно из них — не бесплатная OSE.

• Коммерческая Network Edition и расширение Zextras. Именно здесь TOTP-аутентификация встроена. Управляется командой zxsuite auth enforce2fa — можно принудительно включить второй фактор для целого класса обслуживания (COS), а не полагаться на то, что пользователи включат сами.
• Carbonio — преемник Zimbra OSE от той же команды Zextras. Здесь 2FA работает не только в вебе, но и в нативных мобильных приложениях. Для тех, кто и так думает о переезде с замороженной OSE, это аргумент.
• Внешний слой — обратный прокси или портал перед веб-почтой с собственной двухфакторкой. Единственный путь для чистой OSE без покупки лицензий. О нём — отдельный раздел, потому что именно он спас клиента в Подольске.

# так это выглядит в коммерческой редакции (у клиента этой команды НЕТ)
zxsuite auth enforce2fa cos default true
# TOTP становится обязательным для всех в классе default

Что даёт TOTP по существу: одноразовый код из приложения-аутентификатора в дополнение к паролю. Украли пароль — без кода в почту всё равно не войти. Это закрывает главный сценарий массовых атак: подбор и кражу паролей.

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

Кража сессии через stored XSS. Резервные коды 2FA — прямая цель таких атак. При хранимом XSS в веб-интерфейсе (как в CVE-2025-66376) вредоносный JavaScript в теле письма уводит сессионный токен уже после того, как вы прошли оба фактора. Второй фактор вы ввели — сессию у вас всё равно забрали. Более того, резервные коды 2FA прямо перечислены среди похищаемых данных в той кампании.

AiTM-фишинг. Поддельная страница входа Zimbra проксирует ваш логин, пароль и код на настоящий сервер в реальном времени, забирая по пути сессионную cookie. Вы честно ввели TOTP — и честно отдали сессию атакующему.

Вывод, который я всегда проговариваю: 2FA — обязательный, но не единственный слой. Она резко снижает риск компрометации через украденный пароль, и это огромная доля атак. Но без харденинга веб-интерфейса и свежих патчей от XSS второй фактор обходят. Ставить 2FA и не патчить сервер — всё равно что запереть дверь и оставить окно.

Клиенту нужна была двухфакторка, но не нужна была миграция и не хотелось платить за Network Edition на 36 ящиков ради одной функции. Рабочее решение — вынести веб-почту за обратный прокси с внешней аутентификацией и навесить 2FA там.

Идея: пользователь сначала проходит портал (условно — reverse-proxy с OIDC/SAML или связкой типа Authelia/Keycloak), где предъявляет пароль и TOTP, и только после этого прокси пускает его к веб-клиенту Zimbra. Сама Zimbra не трогается — она как была OSE, так и осталась.

# схема потока (упрощённо)
# клиент -> nginx (reverse proxy) -> портал 2FA (TOTP) -> mailboxd
# не забыть отдать Zimbra реальный IP клиента:
zmprov mcf +zimbraMailTrustedIP 10.20.0.5   # IP прокси

На практике поток выглядит так. Наружу торчит один nginx. Все запросы к / он отдаёт в auth_request на портал; портал возвращает 401, если сессии нет, и nginx уводит человека на страницу входа с паролем и полем для шестизначного кода. После успешной проверки портал ставит свою cookie, отвечает 200 — и только тогда nginx проксирует запрос в mailboxd на 8443. Zimbra об этом ничего не знает: к ней приходит обычный HTTPS-запрос с уже прошедшего проверку прокси. Отдельная возня — с путями, которые нельзя закрывать: /service/soap, по которому ходит сам веб-клиент после логина, и /zimbra/js со статикой, иначе интерфейс встанет наполовину загруженным. У меня на это ушло полдня и три перезапуска.

Вторая половина работы — заткнуть обход через порты, которые портал не видит. Это ровно то место, где самостоятельная попытка обычно и заканчивается «сделали, а толку ноль»:

# мобильную синхронизацию оставляем только тем, кому она реально нужна
zmprov mc default zimbraFeatureMobileSyncEnabled FALSE
zmprov ma direktor@example.ru zimbraFeatureMobileSyncEnabled TRUE

# 993 и 465 закрываем на файрволе всем, кроме офиса и VPN,
# иначе украденного пароля хватит, чтобы прочитать почту мимо портала
iptables -A INPUT -p tcp --dport 993 -s 91.204.x.x -j ACCEPT
iptables -A INPUT -p tcp --dport 993 -j DROP

Важные оговорки, без которых это не взлетит начисто:

• Портал закрывает веб-доступ. IMAP/ActiveSync на телефонах ходят мимо него — их надо либо тоже заводить через прокси, либо ограничивать отдельно, иначе второй фактор обходится через мобильный клиент.
• Без zimbraMailTrustedIP в логах будет адрес прокси вместо клиента — при инциденте останетесь слепы.
• Это не встроенная 2FA Zimbra, а внешний слой. Он не защищает от stored XSS внутри самой веб-почты — только от несанкционированного входа.

По деньгам вышло так: настройка портала — несколько дней работы разово, дальше бесплатный open-source стек. Лицензии Network Edition на 36 ящиков окупались бы годами против этого. Для торговой компании выбор был очевиден.

Прежде чем требовать «включите 2FA», узнайте, есть ли у вас вообще на чём её включать. Две команды и один вопрос себе. От пользователя zimbra.

# 1. какая у вас редакция
zmcontrol -v

# 2. есть ли команды Zextras (признак коммерческого слоя)
which zxsuite && zxsuite auth getEnforce2fa cos default 2>/dev/null

# 3. сколько ящиков реально защищать
zmprov gaa | wc -l

Если в первой строке у вас OSE — не тратьте время на поиск «где включить двухфакторку в настройках». Её там нет. Решение — либо внешний слой, либо переезд на платформу, где 2FA есть штатно.

Считаем на кейсе. У торговой компании 36 ящиков. Три пути к 2FA и их цена.

Путь 1 — купить Network Edition ради одной функции. Лицензии считаются по ящикам и продлеваются ежегодно, притом что коллаборативный функционал Network им был не нужен — нужна была только двухфакторка. Точную сумму называть не берусь: в 2024-м у российского покупателя вопрос был уже не «сколько», а «через кого и чем платить». Но даже по самой аккуратной прикидке годовой счёт за 36 ящиков перекрывал разовые 84 000 за портал, и перекрывал каждый год заново. Переплата за то, чем не пользуешься.

Путь 2 — внешний портал с 2FA. У нас это заняло 22 часа: настройка прокси и портала, разбор путей веб-клиента, ограничение IMAP на файрволе, регистрация тридцати шести человек в аутентификаторе и полтора часа объяснений на планёрке, зачем теперь шестизначный код. По деньгам — 84 000 рублей разово, дальше только бесплатный стек и обновления. Минус честный: мобильные клиенты из коробки не покрывает и от XSS внутри веб-почты не спасает. Именно его и выбрали.

Путь 3 — миграция на Carbonio. 2FA штатно, включая мобильные приложения, плюс уход с замороженной OSE. Дороже по трудозатратам разово, но решает не только двухфакторку. Мы отложили его как план на будущее.

А теперь цена бездействия — то, ради чего всё и затевалось. У этой компании через почту ходят счета и заявки на отгрузку. Угон одного ящика менеджера по закупкам — это не «переписку почитали», это письмо контрагенту с подменёнными реквизитами, отправленное из настоящего ящика, в настоящей ветке, с настоящей подписью. Средний счёт у них — 340 000 рублей; одна такая оплата «не туда» стоит дороже, чем портал, вчетверо, и возвращается она через полицию и полгода, если возвращается вообще. Плюс сутки на смену паролей всем тридцати шести и обзвон контрагентов с объяснением, что письмо было не от них. Вот в этой арифметике 84 000 разово и перестают выглядеть как трата.

Типичная ошибка, которую я вижу постоянно: компания покупает Network Edition, думая, что «там безопаснее», а по факту ей нужна была одна функция, которую можно закрыть внешним слоем за долю цены. Или наоборот — упирается в бесплатную OSE из принципа и остаётся вообще без второго фактора, хотя портальное решение стоило пары дней работы. Выбор зависит от того, сколько у вас ящиков, ходят ли люди с телефонов и собираетесь ли вы вообще оставаться на Zimbra.

Если вам сказали «в Zimbra есть 2FA» — уточните, в какой. В бесплатной OSE встроенной двухфакторки нет, и это не чинится галочкой в настройках: её там просто не заложено. Есть три выхода — коммерческая редакция, Carbonio или внешний портал перед веб-почтой, — и правильный зависит от числа ящиков, мобильных клиентов и ваших планов на платформу.

И держите в голове границу: 2FA закрывает кражу пароля, но не спасает от XSS-угона сессии и AiTM-фишинга. Второй фактор без свежих патчей и харденинга веб-интерфейса обходят.

Хотите понять, какой путь ваш, — пришлите мне вывод zmcontrol -v, ответ which zxsuite и число ящиков из zmprov gaa | wc -l. За день скажу, есть ли у вас основа для встроенной 2FA, стоит ли городить внешний портал или дешевле сразу планировать переезд — с прикидкой по трудозатратам, а не «закажите аудит».

Я точно ничего не путаю — в моей Zimbra реально нет 2FA?

Проверьте редакцию командой zmcontrol -v. Если в выводе есть OSE — это Open Source Edition, и встроенной двухфакторной аутентификации в ней нет ни в вебе, ни в мобильных клиентах. Это не выключенная опция и не вопрос лицензионного ключа — функция физически не входит в бесплатную сборку. Статьи в интернете, где показывают «2FA в Zimbra», почти всегда про коммерческую Network Edition или про расширение Zextras: там команда zxsuite auth enforce2fa действительно есть. В чистой OSE этой команды нет вообще. Так что вы не путаете — вам просто попалась инструкция не для вашей редакции.

Раз в OSE 2FA нет, может, просто купить Network Edition?

Можно, но сначала посчитайте, за что платите. Network Edition — это лицензии на каждый ящик ежегодно, и в них входит целый пласт коллаборативного функционала: продвинутый бэкап, мобильный ActiveSync, HSM и прочее. Если вам нужна только двухфакторка, а остальное — нет, вы переплачиваете за неиспользуемое. На 36 ящиках, как у моего клиента в Подольске, это выходило в разы дороже, чем разово настроить внешний портал с 2FA на бесплатном стеке. Покупать Network стоит, когда вам нужен именно её функционал целиком, а не одна галочка. Ради одной функции есть решения дешевле.

Что такое обходной путь через прокси и насколько он надёжен?

Идея в том, чтобы поставить перед веб-почтой обратный прокси с порталом аутентификации (например, на базе Authelia или Keycloak), который требует пароль плюс TOTP-код, и только после этого пускает пользователя к веб-клиенту Zimbra. Сама Zimbra остаётся нетронутой OSE. Надёжность у решения хорошая для веб-входа, но с двумя оговорками: оно закрывает только веб, а IMAP и ActiveSync на телефонах ходят мимо портала — их надо ограничивать отдельно; и оно не защищает от XSS внутри самой веб-почты, только от несанкционированного входа. Как слой против кражи пароля работает отлично и стоит несопоставимо меньше лицензий.

Если я включу 2FA, меня уже не взломают?

Нет, и это важно понимать до внедрения. 2FA закрывает конкретный, самый массовый класс атак — вход по украденному или подобранному паролю. Но есть сценарии, где второй фактор бесполезен. При stored XSS в веб-интерфейсе (класс CVE-2025-66376) вредоносный код в теле письма уводит вашу сессию уже после того, как вы прошли оба фактора, — и резервные коды 2FA прямо входят в список похищаемого. При AiTM-фишинге поддельная страница проксирует ваш код на настоящий сервер и забирает сессионную cookie. Поэтому 2FA — обязательный слой, но в связке с патчами и харденингом веб-интерфейса, а не вместо них.

У нас OSE и люди читают почту с телефонов. Портал это покроет?

Веб — да, телефоны — нет, если не сделать отдельно. Портальная 2FA стоит перед веб-клиентом, а мобильные приложения обычно подключаются по IMAP или ActiveSync напрямую к серверу, минуя портал. Значит, вход с телефона окажется без второго фактора — и это дыра, через которую обходится вся защита. Варианты: либо заводить мобильный доступ тоже через прокси (сложнее технически), либо ограничить прямой IMAP/ActiveSync по IP и разрешить только доверенные сети, либо всерьёз смотреть в сторону Carbonio, где 2FA работает и в нативных мобильных приложениях штатно. Какой вариант ваш — зависит от того, откуда именно ходят сотрудники; пришлите вводные, подскажу.