Sophos Firewall: Без CVE, но с кучей багов (с v21.5 по v22)

3 марта 2026 г. • 19 min read

Содержание

Если вы сейчас работаете в сфере сетевых экранов (файрволов), то, как правило, боретесь с одним из двух больших зол: либо вы постоянно находитесь в стрессе из-за критических уязвимостей (CVE, как сейчас у Fortinet) и ночами накатываете патчи — либо системы создают столько препятствий в вашей повседневной работе из-за нестабильных прошивок и раздражающих багов (как сейчас у Sophos), что вы просто не успеваете делать ничего другого.

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

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

Дисклеймер, чтобы не казалось, что я сравниваю теплое с мягким: Я прекрасно понимаю, что Fortinet тоже борется с огромными багами (вспомним Conserve Mode и утечки памяти в FortiOS 7.2/7.4/7.6) и что у Sophos в прошлом тоже была своя доля серьезных CVE. Однако на текущем этапе v21.5/v22 ситуация бьет по нам именно так: у одних это постоянный патчинг CVE, у Sophos — ненужная операционная работа, вызванная проблемами со стабильностью.

Контекст версий (Вкратце)

Просто чтобы было понятно, что я пишу не о какой-то пыльной v19, а о том, что многие сейчас используют как “актуальное”:

SFOS 21.5 GA (02.06.2025): Примечания к выпуску (Release Notes): SFOS 21.5
SFOS 21.5 MR2 (Build 323, 18.02.2026): Согласно примечаниям к выпуску, это последняя версия 21.5 в данном периоде.
SFOS 22.0 GA (Декабрь 2025) и v22 GA Re-Release (Build 411, 20.01.2026): Примечания к выпуску: SFOS 22.0

Это версии GA (General Availability) и Maintenance Releases, а не случайные ночные сборки.

Чтобы убедиться, что это сравнение основано не только на ощущениях, вот небольшая проверка реальностью.

Fortinet: CVE для FortiOS с ноября 2025 года (На 26.02.2026)

Период: с 01.11.2025 по 26.02.2026 (Дата публикации). Источник: Бюллетени Fortinet PSIRT (Обзор PSIRT).

Я намеренно не перечисляю здесь “все от Fortinet”, а только те бюллетени, которые касаются FortiOS/FortiGate за этот период, потому что на практике именно это доставляет боль: вам нужно патчить, планировать, тестировать.

Оценка CVSS — это еще не все, но она делает операционный контраст очевидным: средний уровень (Medium) с оценкой 5.x часто можно спланировать, а вот 9.x быстро превращается в сценарий “бросай все и патчь”.

Опубликовано 10 февраля 2026 (Несколько бюллетеней в один день)

FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): Request smuggling в GUI FortiOS. Неприятно еще и потому, что связано с “незалогированными запросами” (unlogged requests).
FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): Проблема со строкой формата (Format-String) в режиме быстрого переключения CAPWAP (Admin/Config в качестве триггера).
FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): Обход аутентификации LDAP в Agentless VPN/FSSO (Workaround на практике часто: отключение неаутентифицированной привязки на сервере LDAP).
FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): Обход патча устойчивости символических ссылок SSL VPN. Важно для контекста: Согласно бюллетеню, сначала требуется компрометация через другую уязвимость на уровне файловой системы.
FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): Обход политик в агенте служб терминалов FSSO (Исправление требует комбинации версии FortiOS и минимальной версии агента TS).

Январь 2026

FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4), опубликовано 27.01.2026: Обход административной аутентификации FortiCloud SSO. Бюллетень также описывает эксплуатацию in the wild и конкретные контрмеры.
FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4), опубликовано 13.01.2026: Переполнение буфера в куче (Heap-based buffer overflow) в демоне cw_acd (FortiOS/FortiSwitchManager).

Опубликовано 9 декабря 2025

FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): Обход аутентификации FortiCloud SSO Login через поддельное SAML-сообщение (Функция не включена по умолчанию, но реально используется в рабочих средах).
FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): Недостаточное истечение сессии в SSL VPN (Срок действия сессии/Крайний случай при смене пароля).
FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): Чувствительная информация попадает в логи REST API (если включено логирование REST API).
FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): Приватный ключ может быть прочитан администратором (Ошибка управления ключами, исправляется патчем).

Опубликовано 18 ноября 2025

FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): Переполнение буфера стека в демоне CAPWAP.
FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): Еще одно переполнение буфера стека в демоне CAPWAP.
FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): Обход доверенных хостов (Trusted hosts) через SSH (Крайний случай в CLI).

Да, это много. И да, с этим можно справиться с помощью процессов (Окна патчинга, Staging, Управление изменениями, Окна обслуживания).

А затем наступает обратная сторона медали.

Sophos: Без заголовков в новостях, но эксплуатация в огне

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

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

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

Это не академические дебаты. Это реальная эксплуатация (Operations). И, к сожалению, сейчас я почти готов предпочесть теоретическую уязвимость, которую возможно когда-нибудь эксплуатируют, клиенту, чья сеть снова полностью лежит несколько часов из-за банального бага.

Наши текущие болевые точки (Да, все сразу)

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

Файрвол иногда не загружается нормально после перезагрузки.
Кластер HA (отказоустойчивости) разваливается или ведет себя как split-brain.
Логирование внезапно становится ненадежным (или полностью пропадает).
Сертификаты Let’s Encrypt не обновляются, и приходится исправлять это вручную по ночам.
Интерфейс пропадает или внезапно перестает отображаться в GUI.
SSD-накопители умирают (аппаратные поломки).
Логин в WebAdmin полностью бастует — войти невозможно, часто помогает только перезагрузка.
Интерфейсы внезапно полностью исчезают из конфигурации.
Диск с логами переполняется, после чего появляются сообщения об ошибках или затронутые сервисы напрямую останавливаются.

Что говорит сообщество (Вы не одиноки!)

Если заглянуть в сообщество Sophos (на начало 2026 года), картина падения качества, к сожалению, совпадает с нашим опытом. К нашим проблемам в v21.5 / v22 у других пользователей добавляются еще более жесткие “шоустопперы”:

Сломанные профили SSL-VPN (v22.0 Build 411): Некоторые пользователи сообщают, что после обновления до последней v22 создание профилей SSL-VPN завершается ошибкой. Иногда им приходилось делать откат на v21.5, потому что новая версия была слишком забагованной.
Сломанный SNAT / Доступ к веб-серверу (v22.0 Build 365): Есть сообщения о том, что после обновления ломается доступ к внутренним веб-серверам извне. Часто маршрутизация интернета полностью перестает работать, пока SNAT не будет вручную сброшен на стандартную опцию MASQ.
Спам в CLI / “Invalid rule id”: В консоли массово появляются предупреждения вроде “Invalid rule id or family for update”. (Похоже, это “всего лишь” ошибка отображения, но она бессмысленно затапливает логи).

И самое горькое во всем этом: каждая из этих вещей — не просто раздражающий фактор, это огромный риск. Если нет логов, вы летите вслепую. Если HA шатается, вы теряете доверие к отказоустойчивости. Если сертификаты не обновляются, вы городите костыли (workarounds). А костыли — это идеальная среда для будущих инцидентов.

Баги Sophos (с v21.5 по v22): То, что бьет прямо по вашим симптомам

Я намеренно привожу здесь конкретные идентификаторы NC (NC-IDs) из официальных примечаний к выпуску или официально задокументированных известных проблем (Known Issues), чтобы вы, как администратор, могли четко это отследить.

TL;DR: Симптом -> Что об этом говорят Release Notes

Симптом в эксплуатации	Примеры из Release Notes / Known Issues
Загрузка/Перезагрузка проходит криво	NC-151715, NC-152641, NC-123910
HA шатается или паникует при failover	NC-142962, NC-132291, NC-147307, NC-147739, NC-149039
Логи/Отчеты пропали или ненадежны	NC-158526, NC-160962, NC-157663, NC-169237, NC-135594, NC-175936, NC-170292, NC-166381
Let’s Encrypt/WAF создают стресс	NC-148937, NC-152022, NC-140663, NC-141062, NC-152540, NC-146082, NC-159041
Entra SSO/Captive Portal/VPN Portal дурят	NC-167126, NC-157635, NC-167130, NC-167128
VPN/IPsec не поднимается или ломается совместимость	NC-136352, NC-128116
Потери трафика без явных причин в правилах	NC-169842 (и после апгрейдов всегда подозревайте IPS/Snort)
Интерфейс “отсутствует” (UI)	Известная проблема: Имена интерфейсов, заканчивающиеся на 10+ цифр, делают их невидимыми в WebAdmin

Раздражающая история из практики

Мы сидим утром и делаем то, что всегда: обрабатываем тикеты, планируем изменения, читаем мониторинг.

И тут в дверь стучится файрвол. Без предупреждения.

Не с помощью CVE, не через “Critical Advisory”. А с помощью суровых будней.

Первый кофе, первая перезагрузка, и вопрос в голове: Он поднимется или нет?

Если все идет хорошо, он загружается. Если плохо, он зависает где-то между “Failsafe” и “работает, но не обрабатывает трафик”. И пока ты все еще думаешь, неужели снова придется доставать консольный кабель, открывается следующая глава.

HA (Отказоустойчивость). Твоя подушка безопасности. И иногда кажется, что эта подушка срабатывает, пока ты просто паркуешься.

Затем логи. Мы все знаем: если ты не видишь, что происходит, ты не можешь этим управлять. И внезапно логи пропадают, отчеты пусты, или какой-то сервис падает. Ты стоишь и гадаешь: у тебя сейчас проблема безопасности, проблема качества данных или и то, и другое?

А потом наступает кульминация: WAF, Reverse Proxy, Let’s Encrypt.

Ты даже не хочешь ничего сверхъестественного. Ты просто хочешь, чтобы сертификаты обновлялись и чтобы твои сайты не кричали “connection refused” в 02:13 ночи.

Ну и бонусом — “пропавший” интерфейс. На самом деле не пропавший, а просто невидимый в интерфейсе пользователя (UI). Трафик, возможно, даже идет, но ты не можешь посмотреть его настройки для дебага.

В какой-то момент ты задаешь себе этот абсолютно абсурдный вопрос:

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

1) Загрузка, Перезагрузка, Апгрейд: “Он жив, но не работает”

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

Несколько примеров из Release Notes SFOS 21.5:

Failsafe при перезагрузке: NC-151715 (Firmware Management): Вспомогательное (Auxiliary) устройство ушло в Failsafe при перезагрузке; рестарт не удался.
Остановка трафика после апгрейда: NC-152641 (Firmware Management): После обновления (с 21.0 MR1 Build 237) перестал обрабатываться трафик (Связано с изменениями конфигурации SWAP Memory).
Kernel Panic: NC-123910 (Firewall): Проблема Kernel panic.

И да, SFOS 22.0 добавляет еще один фактор: Sophos отмечает в Release Notes, что v22 приносит архитектурные изменения и что в редких случаях могут потребоваться дополнительные ручные шаги. Это именно тот “крайний случай” при обновлении, который больно бьет по эксплуатации.

2) HA: Подушка безопасности, которая срабатывает на парковке

HA — это твоя страховочная сетка. И именно поэтому так больно, когда проблемы возникают именно там.

Из Release Notes SFOS 21.5 (Выборочно):

HA Event Tracking останавливается при одновременных перезагрузках: NC-142962 (HA).
Загрузка прошивки на пассивный узел зависает: NC-132291 (HA).
Failover приводит к циклу перезагрузок (Restart Loop): NC-147307 (HA) (в заметках прямо указано, например, про XGS 2300).
Синхронизация падает после отключения питания: NC-147739 (HA).
Статус HA мигает, Crash Dump на Dedicated Link: NC-149039 (HA).

3) Логи и Отчеты: Когда летишь вслепую

Для меня это главная причина, почему “баги” — это не просто “рутина”. Когда логирование/отчетность хромает, это настоящая проблема безопасности.

Из Release Notes SFOS 21.5 (Выборочно):

Логирование/Reporting спорадически останавливается; частые coredump у сервиса Garner: NC-158526 (Logging Framework).
Службы Garner и fwcm-heartbeatd останавливаются: NC-160962 (Logging Framework).
После апгрейда: отчетов больше нет: NC-157663 (Logging Framework).
Log Viewer теряет события из-за повреждения БД: NC-169237 (Logging Framework).
Повреждение файлового дескриптора (fd) Syslog, данные уходят не в тот FD: NC-135594 (Logging Framework).

Кроме того, в списке известных проблем (Known Issues List - KIL) Sophos есть вещи, которые так же болезненны:

Log Viewer не показывает новых данных (отсутствует active.db): NC-175936 (Logging Framework). На некоторых системах 21.5.1 может отсутствовать файл active.db в /tmp/eventlogs/. Из-за этого Log Viewer “зависает”, хотя трафик и функции безопасности продолжают работать. Согласно KIL, это исправлено в v22 и должно войти в патч для 21.5 MR2.
Ложное срабатывание “advanced threat detected” в HA: NC-170292 (Logging Framework). Sophos Central может прислать алерт в HA-инсталляциях, прикрепив сырые логи в описание. Костыль (workaround) по версии KIL: перезапустить службу Garner. KBA: https://support.sophos.com/support/s/article/KBA-000043672
Служба ReportDB_v9 показывает STOPPED (выглядит страшно, но это не так): NC-166381 (Reporting). После апгрейда на v21.0 GA или выше, этот сервис через строго определенное время получает статус STOPPED. По данным KIL, это ожидаемое поведение и оно не влияет на работу, так как касается только устаревшей системы отчетов (до v21).

А вот и “Фактор Sophos Central”: Если вы используете Central как единую панель управления (Single Pane of Glass), проблема с логами бьет вдвойне. Если падает локальный конвейер логирования (Garner/DB), может зависнуть и выгрузка в Central Firewall Reporting (CFR). А CFR и так не всегда работает “в реальном времени”. То есть, в худшем случае вы не только теряете локальные логи, но и именно тот централизованный обзор, на который хотели положиться.

4) WAF и Let’s Encrypt: Публичный сервис, но давайте без драмы

Когда сертификаты не продлеваются, а Reverse Proxy сходит с ума, это уже не “небольшой баг”. Это прямой удар по клиенту (Customer Impact).

В Release Notes SFOS 21.5 вы найдете целое семейство проблем с WAF/Let’s Encrypt:

Создание сертификата Let’s Encrypt не удается: NC-148937 (WAF).
Запрос LE падает, потому что отсутствует Auto-Firewall-Rule: NC-152022 (WAF).
Невалидная конфигурация LE заставляет Reverse Proxy постоянно перезагружаться: NC-140663 (WAF).
ACME не выдает сертификаты для IP-адресов: NC-141062 (WAF).
Правило WAF самопроизвольно включается/выключается: NC-152540 (WAF).

И еще есть темы из разряда “выглядит как баг, но это компромисс безопасности”. Пример из KIL:

Закодированные слэши (%2F) в URL: WAF выдает 404: NC-159041 (WAF). Если ваше приложение использует в URL закодированные слэши, Apache блокирует это по умолчанию (директива AllowEncodedSlashes установлена в No), и вы видите ошибку 404, хотя у бэкенда “на самом деле” этот путь существует. Причина: закодированные слэши могут обходить ограничения путей (классический пример: .../something%2F..%2Fadmin). Детали: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

А если хотите знать, как это выглядит в полевых условиях: В этом треде сообщества человек описывает, что после апгрейда до 21.5.x сертификаты с автопродлением “исчезли”, WAF не запустился, а сайты умерли с ERR_CONNECTION_REFUSED. В итоге решением стала полная очистка правил Web Protection и удаление битых CSR-запросов от LE, после чего всё заработало. (Тред: WAF/Let’s Encrypt после апгрейда, ERR_CONNECTION_REFUSED).

Иногда это даже не “баг”, а процесс: На форуме Sophos также были случаи, когда “Условия обслуживания” (Terms of Service) Let’s Encrypt в WebAdmin помечались как истекшие, и их нужно было принять заново. (Тред: Let’s Encrypt Terms of Service have expired).

Еще одна классическая “ловушка при апгрейде” из KIL: Обновление может провалиться, если встроенный сертификат уже носит то же имя, что и недавно добавленные сертификаты Let’s Encrypt в хранилище CA (NC-146082).

5) “Отсутствующий интерфейс” (или просто невидимый)

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

Официально задокументировано как Known Issue:

Если физический или логический интерфейс в SFOS 21.5 GA и новее имеет имя, которое заканчивается на 10 или более цифр (Пример из примечаний: VLAN_1234567890), то физические интерфейсы перестают быть видимыми в WebAdmin в разделе Network > Interfaces, или логические интерфейсы невозможно развернуть (раскрыть список). Важно: Согласно Release Notes, сама функциональность не страдает, проблема только в отображении в консоли WebAdmin.

Промежуточный итог (до этого момента): Загрузка, Апгрейд, HA, Логи, WAF/Let’s Encrypt и даже пользовательский интерфейс могут подставить вам подножку одновременно. Дальше идут темы, которые поначалу кажутся “тонкими сетевыми деталями”, но в эксплуатации обходятся так же дорого: Entra SSO, совместимость VPN и случайные падения трафика.

6) Учетные данные/SSO (Entra) и Captive Portal: Когда доступ кажется “случайным”

Это та категория багов, которая особенно коварна в эксплуатации: Для конечного пользователя это выглядит как “мой аккаунт глючит”. Для вас это выглядит как “это просто проблемы с SSO”. В реальности между ними часто стоит файрвол.

Пара открытых проблем из KIL, если в вашей сети используется Microsoft Entra ID (Azure AD):

Sophos Connect VPN: Conditional Access поддерживается не полностью: NC-167126 (Authentication). После первоначального запроса MFA при первом входе, проверки Conditional Access (Условного доступа) не обязательно срабатывают при каждом последующем подключении. Согласно KIL, принудительное применение политик произойдет только после ручного выхода пользователя (log out) в клиенте Sophos Connect.
VPN SSO: Различия в UPN и Email ломают логин: NC-157635 (Authentication). Если Email-ID и UPN в Entra отличаются, пользователи могут зайти на портал VPN, но не в SSL VPN или IPsec Portal. Причина по версии KIL: заголовок OAuth передает Email, который затем интерпретируется файрволом как UPN.
Captive Portal: Пользователям Entra SSO требуется Primary Group в правиле: NC-167130 (Authentication). Доступ в интернет срабатывает, только если вы используете Primary Group (Основную группу) в условии срабатывания правила (Secondary Groups здесь не учитываются). Исправление ожидается “в будущих MR”; Workaround: явно указывать Primary Group или использовать правила на основе пользователей.
Случайные ошибки “no permission” при Entra SSO: NC-167128 (Authentication). Может возникать, если аутентификация через Entra ID и локальная AD Auth используются параллельно (Token-Reuse). Костыли из KIL: почистить куки браузера или сделать “force re-logon” в клиенте Sophos Connect. В качестве альтернативы — жестко использовать только один метод аутентификации.

7) Совместимость VPN/IPsec: Обновления часто разбиваются о “соседа”

Две темы из KIL, которые начались не с версии 21.5, но остаются крайне актуальными в 21.5/v22, если у вас в сети остаются старые клиенты или удаленные точки:

IPsec IKEv2: Туннель не поднимается (Фрагментация/PMTU): NC-136352 (IPsec). Начиная с 20.0 MR1, дефолтный профиль IKEv2 может генерировать более крупные пакеты (из-за бóльшего числа полей по умолчанию), иногда размером свыше 1500 байт. Если на маршруте плохая фрагментация/PMTU (фрагменты отбрасываются), туннель S2S не поднимется. Решение по версии KIL: сократить группы Диффи-Хеллмана (DH Groups) в профиле IPsec (оставить минимум 4) или настроить в точности те же группы, что используются на удаленной стороне.
SSL VPN/OpenVPN 2.6.0: Несовместимость с EoL-клиентами/UTM9: NC-128116 (SSLVPN). Начиная с 20.0 MR1, версия OpenVPN обновлена до 2.6.0. Из-за этого ломаются Site-to-Site SSL VPN туннели со старыми версиями SFOS (18.5 и старше), устаревшими (Legacy) SSL VPN клиентами и ОС UTM9. Рекомендация KIL: обновить обе стороны или перейти на IPsec/RED; Для удаленных пользователей: использовать Sophos Connect или актуальные клиенты OpenVPN.

8) Падение трафика без срабатывания правил: Accurate ECN как скрытая причина

Когда трафик начинает “случайно” дропаться, первое, что вы проверяете — это правила, IPS, TLS-инспекцию и маршрутизацию. А после обновления прошивки к этому списку добавляется еще один классический пункт: Движок IPS (Snort) или его сигнатуры становятся строже, блокируют легитимный трафик, а вы не сразу находите четкое событие в логах. Затем вы часами дебажите “маршрутизацию” или “правила”, хотя в итоге все сводится к настройкам политик и тюнингу.

Однако в KIL есть еще один кандидат, который может надолго занять вас, если его нет на ваших радарах:

Трафик отбрасывается из-за битов Accurate ECN: NC-169842 (Firewall). Технология Accurate ECN устанавливает биты TCP (ECE/CWR/NS) нестандартным образом (RFC 7560). Согласно KIL, ядро интерпретирует это как “reserved bit set” (установлен зарезервированный бит) и отбрасывает трафик. Для локализации проблемы помогает взгляд на сторону клиента: На практике это чаще бросается в глаза с новыми ядрами Linux или у клиентов Apple, так как они более активно используют RFC 7560/Accurate ECN (“почему у нас отваливаются только Макбуки?”). RFC: https://www.rfc-editor.org/rfc/rfc7560

9) Перевыпуск v22 GA (Build 411): Зачем он вообще понадобился

20 января 2026 года Sophos выкатила перевыпуск (re-release) v22 GA (Build 411) для исправления “редких и единичных проблем”. Однако список выглядит как настоящий сборник лучших хитов “ненужной работы во время технологического окна” (Источник: блог-пост сообщества Sophos о Re-Release):

NC-171003: WebAdmin недоступен через Bridge-интерфейс при использовании VLAN filtering.
NC-170987: Спам в CLI логах сообщениями “Invalid rule id or family for update”.
NC-170970: Трафик DNAT не проходит, если в правиле DNAT указан конкретный исходящий интерфейс (outbound interface).
NC-171600: Данные в виджетах SSL/TLS и на графике сессий (Session Chart) неверны/пусты.
NC-172197: Невозможно добавить конфигурацию SNMP.

Блог-пост: v22 GA re-release (Build 411) is now available.

Реальный ущерб: Баги делают безопасность дороже

Суть не в том, что “баги хуже, чем CVE” или наоборот.

Суть в следующем: Когда ваша инфраструктура работает нестабильно, безопасность автоматически снижается.

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

И еще один момент, который на практике часто недооценивают: Time-to-Resolution (Время разрешения инцидента). С CVE у вас обычно есть Advisory (уведомление), Mitigation (меры по снижению риска) и Fix (патч). С багом же бремя доказательства быстро ложится на самого админа: tcpdump, CTR-логи, Advanced Shell экспорт, “а вы уже пробовали перезагрузить?” — и всё это в то время, когда прод лежит. И только потом вы попадаете на карусель техподдержки: эскалация, ожидание хотфикса или следующего MR. Все это сжирает дополнительное операционное время, которое вы не планировали.

Именно поэтому вопрос “Лучше уязвимость, но стабильно?” — хоть и очень человеческий, но по сути ведет в тупик:

Не только “уязвимость” является проблемой безопасности. “Нестабильный файрвол” — это тоже огромная проблема безопасности.

Что мы выносим из этого (Чтобы всё не скатилось в полный хаос)

Несколько вещей, которые помогают нам ограничивать это безумие, не изобретая колесо каждую неделю:

Проверки перед апгрейдом (Upgrade-Preflight)

Относитесь к бэкапам как к восстановлению (Restore): Экспортируйте конфигурацию, делайте оффлайн-бэкапы, как минимум один раз проверьте, что восстановление реально работает.
Зеленый статус HA ничего не значит — тестируйте Failover! По данным GUI у нас синхронизация была в норме, а Heartbeat был чист. Но в реальной нештатной ситуации резервное (Auxiliary) устройство все равно не перехватило трафик нормально. Зеленая галочка в WebAdmin сейчас, к сожалению, не гарантирует успеха во время планового переключения.
Проверка логов: Внешний Syslog/Collector получает события, нет пробелов во времени, настройки времени/NTP в порядке.
Проверка сертификатов/WAF: Сроки действия, валидация Let’s Encrypt, наличие fallback-сертификата (заглушки) как плана “Б”.
Действительно проверяйте SSO/VPN: Логин Entra, Captive Portal, Sophos Connect, SSL VPN, IPsec S2S (включая failover) — это всё отдельные тестовые сценарии.
Break-Glass (План Б) должен быть наготове: Доступ по консоли/Out-of-band, локальные учетки администраторов, скачанные образы прошивок для отката (rollback).
Не забывайте про Dual-Boot (и не переоценивайте его): У Sophos есть два раздела с прошивками. Если апгрейд пошел не по плану, откат на 21.5 часто сводится просто к перезагрузке с выбором другого раздела. Но: Бывают случаи, когда второй раздел тоже нормально не грузится, и тогда спасает только полный Reimage (чего служба поддержки требует на удивление быстро). И даже Reimage не всегда лечит истинную причину бага.

Во время апгрейда (Если используется HA)

Сначала Пассивный/Вторичный узел, затем Failover, затем Активный.
Краткая валидация после каждого шага: Трафик, VPN, DNS, Логи, WAF/Reverse Proxy.

В повседневной эксплуатации

Тестируйте HA, а не просто настраивайте: Проводите регулярные учения (Failover-Drills) и имейте четкие критерии того, когда следует искусственно разорвать кластер (split cluster).
Относитесь к системе логирования как к продукту: Настройте алерты на отсутствие логов, следите за Service Health, подготовьте инструкцию по экстренному экспорту через CLI на случай, если веб-интерфейс зависнет.
Активно мониторьте сертификаты: Обновление сертификатов — это не “nice to have”, это операционный риск. Относитесь к изменениям Terms of Service (ToS) от удостоверяющих центров так же серьезно, как к изменениям в инфраструктуре.
Health Check — это подсказка, а не KPI: В v22 Sophos представил инструмент Health Check (Подробнее в моей статье Sophos Firewall v22 Health Check - Полный обзор ). В качестве чеклиста лучших практик — это хорошая вещь, но иногда это выглядит как “попытка переключить все ползунки в экосистеме на зеленый”. Пример из жизни: Многие включают Login-Disclaimer только ради того, чтобы получить зеленую галочку в Health Check. Чего мне там действительно не хватает, так это жестких операционных индикаторов, таких как: “здорова ли база данных логирования/отчетов?” или “в каком состоянии находится SSD?” — особенно учитывая, что на некоторых устройствах (appliances) проблемы с хранилищами начали проявляться гораздо быстрее, чем ожидалось.

Заключение: Когда инструмент становится угрозой

В конечном счете, мы все находимся в одной лодке. Мы управляем критически важной инфраструктурой и должны быть уверены в том, что инструменты, которые призваны спасать нас от хаоса, сами этот хаос не создают. Учитывая текущее качество прошивок (v21.5 / v22), компании Sophos определенно предстоит проделать колоссальную работу над ошибками. Доверие к “стабильным релизам” сильно пошатнулось как у нас, так и у многих других участников сообщества.

Я не хочу файрвол, который будет “либо безопасным, либо стабильным”. Я хочу — нет, мне нужен — файрвол, который сочетает в себе и то, и другое.

Пока Sophos не возьмет эти проблемы с качеством под контроль, у нас в Operations остается только один путь: мы должны стать еще более дисциплинированными, перестать слепо доверять “зеленым галочкам” в пользовательском интерфейсе и относиться к банальным багам при планировании внедрений так же серьезно, как и к критическим CVE.

До новых встреч,
Joe