Sophos Firewall v22 MR2: обновление или новый риск?

Sophos Firewall v22 MR2 вышла. Сборка 546 опубликована 14 июля 2026 года и содержит умеренный, но вполне полезный набор функций безопасности, изменений аутентификации, корректировок сертификатов и более 50 исправлений ошибок.

На бумаге это классический Maintenance Release. На практике в нём собрана именно та комбинация, из-за которой я теперь дважды присматриваюсь к релизам Sophos: новая логика обнаружения в IPS, изменённое поведение привязки пользователей, новые цепочки сертификатов и одновременно длинный список сбоев ядра, проблем HA, состояний Failsafe, ошибок VPN и отказов отчётности.

Это не только хорошая новость. Если Maintenance Release исправляет более 50 ошибок, с одной стороны, Sophos наводит порядок. С другой — это показывает, сколько серьёзных проблем всё ещё оставалось в GA и MR1. Именно это качество прошивок я уже критиковал в статье Sophos Firewall: CVE нет, а ошибки есть (от v21.5 до v22).

Я сразу установлю MR2 на один из своих Sophos Firewall. Не потому, что слепо доверяю релизу в первый день, а чтобы понять, успокоит ли сборка 546 линейку v22 или обновление снова принесёт больше новых ошибок, чем исправит. Особенно меня интересуют HA, журналирование, IPsec, отзывчивость WebAdmin, STAS и стабильность после обновления patterns.

Одновременно Sophos создаёт странный контраст. Config Studio 2.6 теперь занимает заметное место в официальных материалах об обновлении firewall. Внешний браузерный инструмент получает объединение шаблонов, улучшенный поиск, сравнение нескольких файлов, анализ миграции и данные о совместимости оборудования. В повседневной работе интерфейса самой firewall опять почти нет заметных изменений.

Поэтому технически MR2 важна, но стратегически разочаровывает. Механизм безопасности получает новые функции, а современные административные workflows снова выносятся в Config Studio.

Самое важное вкратце

SFOS 22.0 MR2 имеет номер сборки 546 и следует за MR1 build 490. Sophos выделяет семь основных направлений:

• обнаружение и контроль постквантовой криптографии;
• более точная категоризация приложений генеративного ИИ;
• новое расширение Chromebook User ID на Manifest V3;
• изменение стандартного поведения STAS;
• раннее объявление об окончании поддержки Novell eDirectory в SFOS 23.0;
• новые цепочки доверия Let’s Encrypt и улучшенные уведомления по электронной почте;
• Config Studio 2.6 с новыми функциями анализа, миграции и сравнения.

К этому добавлено более 50 исправлений. С эксплуатационной точки зрения некоторые из них важнее новых функций: среди них сбои ядра, проблемы HA, состояния Failsafe, ошибки VPN и снижение производительности отчётности.

Моя краткая оценка:

• У тех, кто уже работает на v22 GA или MR1 и сталкивается с одной из перечисленных ошибок, есть конкретная причина перейти на MR2.
• Стабильную установку 21.5 не стоит спешно обновлять только ради PQC или Config Studio.
• Сигнатуры PQC сначала следует включать исключительно для наблюдения, а не сразу с действием Drop.
• В средах STAS после обновления нужно проверить обработку неаутентифицированного трафика во время Identity Probe.
• Установкам HA, IPsec, WAF, почты и отчётности необходимы настоящие функциональные тесты, а не беглый взгляд на зелёные индикаторы.
• Config Studio 2.6 технически полезна, но не доказывает модернизацию интерфейса SFOS WebAdmin. Скорее наоборот.

Важно учитывать аппаратное ограничение: SFOS 22.0 больше не поддерживает аппаратные appliances XG и SG. Релиз предназначен для XGS, виртуальных, программных и поддерживаемых облачных установок. Владельцы оборудования XG не могут рассматривать MR2 как обычный следующий этап обновления прошивки.

Обнаружение и контроль постквантовой криптографии

Самая интересная техническая новинка — контроль постквантовой криптографии, или PQC. Это не означает, что Sophos Firewall внезапно научилась отражать атаки квантовых компьютеров. Функция касается современных криптографических механизмов обмена ключами, рассчитанных на более высокую устойчивость к будущим атакам достаточно мощных квантовых компьютеров.

MR2 сосредоточена на ML-KEM. В 2024 году механизм стандартизирован как FIPS 203 и основан на предполагаемой сложности задачи Module Learning With Errors. NIST определяет три набора параметров:

• ML-KEM-512 с наименьшими ключами и объёмом данных;
• ML-KEM-768 как средний и сегодня особенно распространённый вариант;
• ML-KEM-1024 с более высоким уровнем безопасности, но большей вычислительной и сетевой нагрузкой.

В документации MR2 Sophos лишь в общем говорит о чистых и гибридных алгоритмах обмена ключами на базе ML-KEM. Конкретные наборы параметров, группы TLS и идентификаторы сигнатур не раскрываются. Поэтому нельзя автоматически считать, что распознаётся любой возможный вариант ML-KEM.

Что технически делает KEM

ML-KEM не шифрует весь поток данных напрямую. Упрощённо Key Encapsulation Mechanism состоит из трёх операций:

1. KeyGen создаёт Encapsulation Key и соответствующий Decapsulation Key.
2. Encaps с публичным Encapsulation Key создаёт объект Ciphertext и общий секрет.
3. Decaps на другой стороне восстанавливает тот же секрет с помощью закрытого Decapsulation Key.

Затем протокол выводит из общего секрета симметричные сеансовые ключи. Полезные данные по-прежнему защищаются быстрыми симметричными алгоритмами вроде AES или ChaCha20. Таким образом, ML-KEM заменяет уязвимую асимметричную часть согласования ключей, а не всё шифрование данных TLS.

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

Чистый и гибридный варианты — не одно и то же

При чистом PQC-обмене безопасность согласования опирается только на новый постквантовый механизм. Гибридный обмен сочетает классический механизм с ML-KEM. Распространённый практический пример — X25519MLKEM768: классическая часть X25519 и ML-KEM-768 вместе участвуют в формировании общего секрета.

Сейчас гибридный подход разумен. Если позднее обнаружится ошибка реализации или математическая слабость ML-KEM, останется классический компонент. Если достаточно мощный квантовый компьютер сможет взломать классическую эллиптическую кривую, останется компонент ML-KEM. Гибрид — это мост для миграции, а не ненужное двойное шифрование.

Но важно: X25519MLKEM768 здесь является реальным техническим примером из современных реализаций TLS. Sophos не утверждает в материалах MR2, что распознаётся только или преимущественно эта группа.

Что делает IPS

Intrusion Prevention System получает новые сигнатуры для обнаружения чистых и гибридных механизмов обмена ML-KEM. Администраторы могут создать для них отдельные правила IPS с действиями Allow, Drop или Reset.

Технически firewall может увидеть предлагаемый и выбранный обмен ключами в handshake TLS: клиент объявляет поддерживаемые группы и Key Shares в ClientHello, а сервер подтверждает выбор в ServerHello. Это происходит до начала зашифрованного потока приложения. Поэтому обнаружение в принципе возможно без чтения последующего содержимого HTTPS.

Однако Sophos не документирует, где именно Snort или pipeline IPS в SFOS анализирует эти признаки, какие версии TLS охватываются и отличается ли обнаружение для proxy, DPI и незашифрованного FastPath-трафика. Release Notes подтверждают возможность, но не внутреннюю реализацию пути данных. Для производственной policy необходим собственный тест с журналами firewall и IPS.

Действия дают разные результаты:

• Allow пропускает соединение и вместе с журналированием подходит для инвентаризации.
• Drop молча отбрасывает соответствующие пакеты. Клиент обычно видит timeout или прерванный handshake.
• Reset активно завершает TCP-соединение. Ошибка появляется быстрее, но для пользователя и в журналах приложения может выглядеть иначе, чем тихий Drop.

Новые сигнатуры по умолчанию отключены. Это правильное решение. PQC уже не лабораторная технология: крупные браузеры, облачные сервисы и веб-платформы тестируют или применяют гибридные механизмы. Безусловная блокировка таких соединений Sophos могла бы нарушить работу легитимных сайтов и приложений.

Разумное внедрение выглядит так:

1. Сначала включить сигнатуры, разрешая и журналируя трафик.
2. Несколько дней или недель анализировать, какие приложения и адресаты используют ML-KEM.
3. Проверить, запрещают или требуют ли внутренние криптографические правила определённые механизмы.
4. Только затем целенаправленно применить Drop или Reset.

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

Перед изменением policy я бы проверил:

• Активен ли IPS и действительна ли подписка Network Protection?
• Какая версия patterns IPS установлена?
• Под каким именем и SID отображаются новые сигнатуры?
• Появляются ли срабатывания в журнале IPS и центральной отчётности?
• Одинаково ли обнаружение при исключениях DPI, TLS Inspection и FastPath?
• Какие браузеры, ОС, облачные сервисы и внутренние приложения создают срабатывания?

Что делает Web Protection

Кроме того, по заявлению Sophos, Web Protection не позволяет веб-сессиям согласовывать неподдерживаемые алгоритмы PQC. Это другая задача, чем у сигнатуры IPS. IPS распознаёт определённые шаблоны и реагирует на них. Web Protection вмешивается в контролируемый workflow TLS и web, чтобы соединение не использовало механизм, который firewall не может обработать или который запрещён policy.

Это особенно актуально при TLS Inspection. В расшифровываемом соединении firewall завершает TLS-сессию клиента и сама устанавливает вторую TLS-сессию с целевым сервером. Существуют два отдельных handshake и два набора сеансовых ключей. Браузер и веб-сервер могут поддерживать PQC, тогда как промежуточный компонент инспекции не способен корректно обработать предложенную группу.

Без контролируемого поведения возникают непонятные ошибки: клиент предлагает новую группу, firewall не может полностью посредничать в handshake, сервер выбирает неожиданный вариант или fallback работает иначе. MR2 должна предотвращать согласование неподдерживаемых алгоритмов PQC веб-сессиями.

Не менее важно, чего Sophos не описывает: нет отдельной матрицы policy PQC для Web Protection, списка поддерживаемых групп и точного пояснения, удаляется ли неподдерживаемое предложение, отклоняется или заменяется классическим fallback. Это нельзя приравнивать к свободно настраиваемому действию IPS.

Функция полезна, но не заменяет криптографическую стратегию. Организациям всё равно нужно знать, какие TLS-соединения расшифровываются, где действуют исключения и следует ли лишь наблюдать PQC или действительно принудительно применять его.

Приложения генеративного ИИ становятся заметнее

Вторая новая функция безопасности касается приложений генеративного ИИ. Sophos улучшает их категоризацию через Synchronized Application Control.

Принцип не нов: Sophos Endpoint видит, какой локальный процесс открывает соединение, и передаёт контекст приложения firewall через Security Heartbeat. Благодаря этому firewall связывает сессию с программой, даже если порт, целевой IP и зашифрованный трафик сами по себе не позволяют однозначной идентификации.

Упрощённый технический путь данных выглядит так:

1. Приложение на защищённом endpoint открывает сетевое соединение.
2. Sophos Endpoint знает имя процесса, путь и локальный контекст приложения.
3. Security Heartbeat связывает представления endpoint и firewall.
4. SFOS назначает неизвестную или приблизительно распознанную сессию приложению.
5. Приложение появляется в Synchronized Application Control и получает категорию.
6. Application Filter Policy разрешает, блокирует или регулирует соответствующий трафик.

В Connection List SFOS может запросить у endpoint сведения о неидентифицированном соединении через Resolve application info. Список приложений ищется по имени, пути, категории или endpoints. Sophos указывает предел в 15 000 приложений под управлением Synchronized Application Control. Для экономии памяти firewall хранит лишь пять последних случаев на приложение и endpoint.

MR2 отдельно улучшает привязку приложений генеративного ИИ. Sophos Endpoint должен распознавать их точнее и передавать информацию firewall. Категория Generative AI присутствует в списке приложений SFOS и может использоваться в Application Filters и Reports.

Для администраторов важны три аспекта:

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

Это полезно, но не следует преувеличивать формулировку «обнаружение генеративного ИИ».

Synchronized Application Control прежде всего отвечает на вопрос: Какое приложение создало соединение? Он автоматически не определяет:

• какой prompt ввёл пользователь;
• какой файл был загружен;
• содержались ли персональные или конфиденциальные данные;
• относится ли браузерная сессия к частному или рабочему использованию ИИ;
• использовался ли разрешённый ИИ-сервис через встроенную функцию браузера.

Desktop-клиент с однозначным путём процесса идентифицировать проще, чем десять ИИ-сервисов в одном процессе браузера. Категоризация URL, TLS Inspection и обнаружение Cloud Apps могут дать дополнительные сведения, но технически это другие уровни распознавания.

Польза также зависит от Sophos Endpoint, активного Security Heartbeat и включённого Synchronized Application Control. Первое включение выполняется через Sophos Central. Использование только SFOS без Sophos Endpoint или endpoints вне пути Heartbeat не обеспечивает автоматически ту же глубину обнаружения.

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

После обновления я бы не стал сразу блокировать всю категорию Generative AI. Сначала отчётность должна показать, какие срабатывания получены из контекста endpoint, сигнатуры firewall или веб-категоризации. Иначе можно заблокировать рабочие функции Microsoft 365, средств разработки, браузеров или платформ поддержки, не поняв фактическое использование.

Изменения аутентификации и привязки пользователей

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

Chromebook User ID с Manifest V3

Расширение Sophos Chromebook User ID переведено на Manifest V3 — современную платформу расширений Chrome, заменяющую прежнюю техническую основу.

Ключевой момент: Sophos требует удалить старое расширение и установить новую версию. Простого тихого обновления недостаточно. Школам и компаниям с централизованно управляемыми Chromebook следует подготовить смену через политики Google Admin, проверить на тестовой группе и затем развернуть широко.

Технически расширение — лишь часть пути SSO. Для Chromebook SSO Sophos требует, среди прочего:

• сервер AD, LDAP или Google Secure LDAP на firewall;
• Chromebook в защищённой SFOS сети;
• адреса пользователей из зарегистрированного домена Google Workspace;
• сертификат для зашифрованной связи;
• соответствующий сертификату CN;
• стандартный коммуникационный порт Sophos 65123;
• JSON-конфигурацию, экспортированную из SFOS и размещённую в Google Workspace;
• доступ к accounts.google.com, Google API Hosts и Chrome Web Store.

В Google Workspace новое расширение распространяется через Devices > Chrome > Apps and extensions > Users and browsers. Для production разумно использовать Force install, чтобы пользователи не удаляли расширение, необходимое для идентификации. Sophos User ID App также должна быть отмечена как доверенная в API Controls, иначе OAuth может завершиться ошибкой.

После перехода мало проверить наличие расширения. Важна вся цепочка:

1. Пользователь входит в Chromebook.
2. Расширение достигает firewall через предусмотренную сеть и сертификат.
3. Пользователь появляется в Live users.
4. Правило на основе пользователя действительно совпадает с пользователем или группой.
5. После выхода или смены устройства привязка корректно исчезает.

Без нового расширения могут прекратиться будущие обновления. В зависимости от схемы аутентификации это способно нарушить привязку пользователей и правила firewall или web на её основе. В школе это быстро превращается в проблему фильтрации, хотя firewall, Интернет и Chromebook на первый взгляд остаются «online».

STAS больше не блокирует трафик во время проверки личности по умолчанию

В Sophos Transparent Authentication Suite MR2 меняет стандартное значение Restrict client traffic during identity probe на No.

STAS сопоставляет IP-адреса с пользователями, обнаруженными Windows Domain Controller. Механизм старый, но технически интересный:

1. Пользователь входит в домен Windows.
2. Domain Controller записывает Security Audit Event, обычно Event ID 4768 в современных Windows.
3. STAS Agent извлекает имя пользователя и IP-адрес.
4. Agent по умолчанию передаёт данные Collector по TCP 5566.
5. Collector сообщает успешные соответствия firewall по UDP 6060.
6. Увидев трафик от неизвестного IP, SFOS может опросить Collector на порту 6677.
7. Firewall дополняет членство в группах через настроенный сервер AD и применяет пользовательские правила.

Если привязки IP ещё нет, адрес попадает в Learning Mode. До сих пор трафик во время проверки по умолчанию задерживался или отбрасывался. Документированный стандартный период — 120 секунд. Если Collector не отвечает, IP затем может считаться неаутентифицированным в течение часа, и применяются правила для такого трафика.

Именно здесь в MR1 существовала реальная эксплуатационная проблема. Sophos документирует NC-181885: при Restrict client traffic during identity probe = Yes повторные Identity Probes могли приводить к периодическим прерываниям или блокировать обновление MR1. MR2 указана как исправляющая версия и одновременно меняет стандарт на No.

С No клиентский трафик продолжает идти во время проверки. Это уменьшает перебои, но меняет баланс:

• пользователь сталкивается с меньшим числом прерываний;
• во время проверки у firewall может ещё не быть подтверждённой личности;
• пользовательские правила и журналирование в переходной фазе требуют внимательной проверки.

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

Release Notes говорят, что стандартное значение становится No. Они не утверждают однозначно, что MR2 перезаписывает любую намеренно заданную существующую настройку. Поэтому после обновления следует проверить фактическое значение.

Кроме того, я бы проверил:

• Открыты ли UDP 6060 и 6677 между firewall и Collector?
• Работает ли STAS Service и привязан ли он к правильной NIC?
• Настроены ли несколько Collectors в группах для Fault Tolerance?
• Охватывают ли объекты Clientless User принтеры, IoT и прочие устройства вне домена?
• Корректно ли пользователи отображаются после Sleep, Roaming, смены DHCP и Logout?
• Соответствуют ли правила во время Learning Mode и неаутентифицированного состояния дизайну безопасности?

Это особенно важно там, где личность пользователя применяется не только для отчётности, но и как реальное условие доступа.

Novell eDirectory прекращает работу с SFOS 23.0

MR2 впервые заранее сообщает, что Sophos прекратит поддержку серверов аутентификации Novell eDirectory в SFOS 23.0.

В MR2 eDirectory продолжает работать. Это предупреждение, а не немедленная потеря функции. Тем, кто всё ещё использует eDirectory в production, следует вовремя перейти на поддерживаемый тип аутентификации до установки SFOS 23.0.

Такая миграция касается не только записи сервера. От источника личности могут зависеть группы, правила firewall, Web Policies, доступы VPN, пользовательские порталы и отчётность. Различия в Distinguished Names, вложенных группах, путях поиска и форматах имён означают, что успешный технический тест LDAP ещё не гарантирует рабочую миграцию policies.

Есть и давнее ограничение: STAS не поддерживает для eDirectory LDAP через SSL/TLS. Поэтому полное удаление eDirectory в SFOS 23.0 не совсем неожиданно. Но замещающая архитектура должна быть готова заранее. Это отдельный проект с тестовыми учётными записями, параллельно созданными группами, документированными ссылками правил и планом отката.

Let’s Encrypt: новые цепочки и лучшая идентификация

Let’s Encrypt постепенно переводит инфраструктуру сертификатов на новые Root и Intermediate certificates. MR2 добавляет поддержку YE Root, YE1, YE2, YR Root, YR1 и YR2.

Так называемая иерархия Generation Y включает два новых Root CA с разными типами ключей:

• ISRG Root YE использует ECDSA P-384 и является последующим путём прежней ECDSA-иерархии.
• ISRG Root YR использует RSA 4096 и служит новым RSA Root.
• YE1 и YE2 — Intermediates ECDSA P-384.
• YR1 и YR2 — Intermediates RSA 2048.

Roots имеют перекрёстную подпись прежних ISRG Roots. Поэтому новые цепочки могут опираться на старые распространённые Trust Anchors, пока разработчики браузеров и ОС добавляют новые Roots в Trust Stores. Intermediates YE1, YE2, YR1 и YR2 стали актуальны для активной выдачи в 2026 году.

Для SFOS это прежде всего изменение совместимости. Firewall должна корректно знать новые центры выдачи и цепочки, чтобы автоматическая выдача, продление, использование WAF и валидация работали с новым поколением инфраструктуры Let’s Encrypt. Без обновлённой цепочки доверия операции сертификатов могли бы завершаться ошибкой даже при корректных домене, порте 80 и HTTP-01.

Такую ошибку ACME легко неправильно диагностировать: искать проблему в DNS, DNAT, порте 80, правиле WAF или Terms of Service, хотя причина находится в новой цепочке CA.

SFOS по-прежнему использует HTTP-01 для запросов Let’s Encrypt. FQDN домена должен указывать на выбранный публичный WAN-адрес. Порт 80 должен достигать firewall, а конкурирующее правило DNAT на том же адресе и порту может помешать валидации. MR2 не меняет этот принцип, а расширяет поддерживаемую иерархию CA.

Кроме того, уведомления Let’s Encrypt по электронной почте теперь включают hostname и серийный номер firewall. Это кажется мелочью, но очень полезно для MSP и крупных сред: предупреждение среди десятков firewalls быстрее связывается с нужным устройством.

Это классическое улучшение Quality of Life: технически непримечательное, но полезное. Каждое системное сообщение централизованно управляемой firewall должно содержать как минимум hostname, серийный номер, модель и firmware. В письмах о backup Sophos уже двигалась в этом направлении; Let’s Encrypt следует за ними в MR2.

Config Studio 2.6: объяснение каждой новой функции

Sophos официально включает Config Studio 2.6 в анонс MR2, хотя это по-прежнему отдельный браузерный инструмент, а не новый интерфейс внутри SFOS. Основной принцип и полный workflow с экспортом, Entities.xml, сравнением и Editor описаны в прежней статье Sophos Firewall Config Studio V2: больше, чем viewer.

Важная техническая деталь и аспект защиты данных: Sophos утверждает, что parsing, анализ и создание отчётов выполняются локально в браузере endpoint. Загруженная конфигурация не должна передаваться Sophos или другому серверу. Это существенно, ведь полный Entities.xml может содержать внутренние сети, объекты, правила, определения VPN, ссылки на сертификаты и названия организации.

Но локальная обработка не означает автоматической безопасности. Браузер всё равно загружает приложение из Интернета. В особо чувствительных средах остаются вопросы версии кода, browser cache, offline-использования, защиты endpoint и безопасного хранения экспортов. Entities.xml не должен бесконтрольно попадать в Downloads, тикеты или обычную cloud-синхронизацию.

Config Studio 2.6 теперь охватывает пять рабочих областей:

• Configuration Report с Policy Test, анализом и глобальным поиском;
• сравнение двух и более конфигураций;
• визуальный Editor с Bulk Editing и выводом XML, API или curl;
• миграция Sophos UTM, SonicWall, FortiGate и Palo Alto Networks;
• совместимость Backup Restore, Flexi Port, transceivers и моделей.

Версия 2.6 расширяет несколько из них.

Объединение шаблонов

Merge Templates позволяет совмещать базовые конфигурации с отраслевыми шаблонами. Например, MSP может объединить техническую основу для logging, DNS, административного доступа и стандартных объектов с шаблоном для врачебных кабинетов, школ или филиалов.

Преимущество — повторное использование. Не нужно начинать с нуля для каждой firewall. Baseline может включать административный доступ, NTP, DNS, Syslog, стандартные Services и соглашения logging. Второй template добавляет отраслевые правила и объекты.

Критичным остаётся разрешение конфликтов:

• Что происходит при одинаковых именах объектов с разными значениями?
• Согласованно ли разрешаются UUID, ссылки и порядок правил?
• Какие ссылки на interfaces и zones не соответствуют целевой модели?
• Создаёт ли объединение дубликаты или пересекающиеся правила?
• Заменяется ли существующий ограничительный объект более широким значением шаблона?

Поэтому после объединения обязательны Duplicate Analysis, Shadow Rule Analysis, Usage References и полный Policy Test. Технически успешное объединение не доказывает безопасность итоговой policy.

Улучшенный глобальный поиск

Глобальный поиск быстрее находит объекты конфигурации и сразу переходит к ним. Для больших наборов правил это важнее, чем кажется. Host-объект может использоваться в firewall, NAT, TLS, web или VPN. Прямой переход к результату экономит множество ручных открытий и возвратов.

Config Studio ищет не только видимое имя. В зависимости от типа данных важны также значения, пути и ссылки. Прямой переход особенно полезен для общих имён вроде Server, LAN_Network или исторически выросших групп хостов.

Однако поиск — не то же самое, что Usage Reference. Search отвечает: «Где находится объект или значение?» Usage Reference — «Какие другие элементы конфигурации от него зависят?» Для безопасного изменения нужны обе перспективы.

Именно эта функция крайне необходима и в интерфейсе самой firewall.

Более содержательные отчёты конфигурации

Для правил Firewall, NAT и TLS отчёты теперь показывают не только имена ссылок, но также значения и детали объектов. Вместо одного Webserver-Gruppe reviewer сразу видит входящие в него hosts или networks.

Для аудита, передачи и проверки четырьмя глазами это большой шаг вперёд. Правило можно оценить только тогда, когда источник, назначение, Services и связанные объекты видны без дополнительных кликов. Аккуратное имя объекта может скрывать Any, слишком широкую сеть или давно забытые записи.

Отчёт также поддерживает Policy Test и анализ. Policy Test проверяет, какое правило или Route соответствует заданным источнику и назначению. Анализ ищет Shadowing и дубликаты. Поскольку SFOS проверяет правила firewall сверху вниз и останавливается на первом совпадении, порядок является частью логики безопасности, а не только отображения.

Config Studio 2.6: миграция, сравнение и экспорт

Анализ миграции с процентом успеха

Config Studio отображает сведения о миграции и конвертации, включая долю успешно перенесённых элементов. Процент — быстрый индикатор, но не протокол приёмки.

При миграции сторонних продуктов Sophos выделяет состояния:

• Supported: автоматически перенесено без содержательных изменений;
• Partial: перенесено с пробелами, которые нужно заполнить;
• Manual: требуется вручную создать на Sophos Firewall;
• Not supported: не переносится;
• Action required: перед экспортом необходимо решение.

Если конвертировано 95% конфигурации, оставшиеся 5% могут приходиться именно на сертификаты, пароли, VPN, NAT или специальную маршрутизацию. Практическая польза не только в зелёном проценте, но в списке неперенесённых, частично перенесённых и автоматически разрешённых элементов.

Различия логики производителей реальны. Правила FortiGate могут сильнее опираться на interfaces, тогда как SFOS работает с zones. У Palo Alto иные модели объектов, зон и policies. Config Studio конвертирует синтаксис и многие структуры, но не может автоматически доказать семантическую идентичность модели безопасности.

Multi-File Configuration Diff

Раньше классическое сравнение в основном было моделью «до и после». Multi-File Diff позволяет загрузить два и более состояния и сравнивать их во времени. Config Studio упорядочивает файлы по дате изменения и показывает добавленные, удалённые и изменённые поля.

Доступны Side-by-Side, Unified и Semantic. Семантическое сравнение особенно интересно, поскольку обычный текстовый diff XML быстро засоряется порядком, IDs и форматированием. Diff на уровне Entity и Field пытается показать реальное изменение конфигурации.

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

Но нужны регулярно сохранённые конфигурации, правильные timestamps и аккуратная работа с чувствительными экспортами. Дата изменения скачанного или скопированного файла не обязательно совпадает со временем изменения firewall. Для надёжной истории вместе следует документировать имя файла, время экспорта, hostname, серийный номер, firmware и связанный Change Ticket.

Без дисциплины версий даже Multi-File Diff не создаст историю из ничего. Поэтому такая функция была бы значительно сильнее непосредственно в Central с неизменяемым Audit History, чем при ручной загрузке файлов.

Справочник Backup Restore, Flexi Port и скоростей

Config Studio проверяет совместимость Backup Restore и схемы портов разных моделей Sophos Firewall. Также отображаются модули Flexi Port и поддерживаемые стандарты и скорости до 25, 40 или 100 Gbit/s.

Функция помогает при аппаратной миграции. Перед сменой модели можно оценить:

• возможно ли в принципе восстановить backup;
• сколько физических портов доступно;
• совместимы ли существующие модули Flexi Port;
• какие стандарты и скорости interfaces поддерживаются.

Но она не заменяет проектирование миграции. LAG, VLAN, Bridges, HA, имена портов, zones и конкретное назначение interfaces по-прежнему нужно планировать и проверять после Restore.

Расширенная совместимость Backup Restore действует для целей начиная с SFOS 20.0 MR2. В зависимости от исходной версии и платформы назначения появляется Backup Restore Assistant для сопоставления interfaces. Физические порты можно переназначить, а VLAN и Aliases следуют Parent Interface; LAG или Bridges заново формируются из назначенных портов.

Для Flexi Ports вопрос «подходит ли модуль физически?» недостаточен. Нужно совместно проверить поколение модели, форм-фактор, transceiver, поддерживаемый стандарт, скорость порта, Breakout и доступную версию SFOS. Config Studio ускоряет справку, но не заменяет тесты Link и Failover после миграции.

Dark Mode

Release Notes также называют Dark Mode. Это небольшое улучшение удобства, а не функция firewall. Но оно почти символично: даже Dark Mode сначала появляется во внешней Config Studio, тогда как локальная WebAdmin-консоль годами очень медленно развивается визуально и эргономически.

Что технически выводит Editor

Editor импортирует или создаёт конфигурации, выполняет Bulk Changes и перед экспортом показывает результат как Import XML, API Request или curl. Можно также скачать XML или TAR-архив и импортировать в SFOS через Backup & firmware > Import export.

Это мощно, но повышает ответственность администратора. Сгенерированный API Request не становится автоматически идемпотентным. Успешный Import не подтверждает функциональную правильность Rule Order, использования объектов, NAT, VPN и Security Policies. Перед production вывод должен попасть в Change Ticket, diff — пройти Review, а полученная firewall — реальный тест пути данных.

Более 50 исправлений — главная причина для MR2

Sophos сообщает о более чем 50 исправленных проблемах надёжности, стабильности и безопасности. Не каждое касается любой установки, но несколько эксплуатационно серьёзны.

Особенно важны следующие группы:

HA и Failsafe — не второстепенные темы

Некоторые исправления влияют не на отдельную функцию, а на работоспособность appliance:

• NC-181331: заполненный раздел конфигурации мог перевести firewall в Failsafe Mode.
• NC-180110: на Primary не запускался Logging Daemon, после чего HA-устройство переходило в Failsafe.
• NC-177441: после обновления до v22 GA исходное Primary-устройство могло попасть в Failsafe из-за Postgres.
• NC-178906: RED Server Service не запускался и мог вызвать Failsafe.
• NC-177467: Auxiliary-устройство некорректно запускалось при множестве параллельных неаутентифицированных SSH-подключений.

Причины различны, но эксплуатационный эффект одинаков: firewall теряет службы, переходит в защитный режим или партнёр HA недоступен, несмотря на прежнее зелёное изображение кластера. После обновления недостаточно увидеть HA status: Active-Passive. Необходимо проверить синхронизацию, службы, Failover и реальный трафик.

Исправления IPsec глубоко затрагивают путь данных

Исправления VPN также не косметические:

• NC-180433: Multicast-трафик через VPN мог вызывать повторные crashes firewall.
• NC-171719: ESP-трафик получал неверную маршрутизацию в конфигурации SD-WAN.
• NC-180520: при IPsec Acceleration XFRM Gateway оставался недоступен после обновления, если туннель был связан с Alias IP, а ESP приходил через другой WAN-порт.
• NC-176855: снижалась пропускная способность IPv6 через route-based IPsec.
• NC-178121: Drag-and-Drop мог переместить Site-to-Site IPsec-соединения в неправильные позиции Failover Group.

В этих случаях состояние туннеля Active ничего не доказывает. Для route-based VPN отдельно тестируются XFRM Interface, Routing Table, решение SD-WAN, путь ESP, MTU, IPv4 и IPv6. В Failover Groups нужно также убедиться, что порядок и переключение после обновления соответствуют документированному приоритету.

Logging и reporting сами могли вызывать отказы

NC-155252 — особенно неприятное исправление: высокая нагрузка Disk I/O отчётности вызывала пики CPU и периодические разрывы Интернета продолжительностью до минуты. Это именно тот случай, когда аналитическая подсистема влияет на производственный путь данных.

NC-178745 описывает автоматический restart HA-устройства из-за Out of Memory в Logging Framework. NC-181520 повышает производительность Log Viewer. Вместе они показывают, что logging в SFOS нельзя считать безобидной вторичной функцией. Storage, база данных, Garner, Log Viewer и Central Reporting эксплуатационно связаны с системой теснее, чем предполагает интерфейс.

После MR2 я проверил бы не только появление новых строк журнала. Важно:

• Полностью ли приходят события Firewall, IPS, WAF, Authentication и VPN?
• Нет ли разрывов во временной шкале?
• Продолжает ли внешний Syslog Collector получать данные?
• Стабильны ли CPU, RAM и Disk I/O под обычной нагрузкой?
• Создаются ли Reports без влияния на путь данных?

Исправления Central показывают пределы «Single Pane of Glass»

При NC-181175 Group Policies из Sophos Central могли зависать в Pending. NC-180513 затрагивала Import конфигурации из Central View после обновления до MR1. NC-181904 мешала освобождать карантинные письма через Central.

Общее здесь то, что центральный интерфейс может принять или отобразить задачу, хотя нужное изменение фактически не выполнено на firewall. После Group Policy Push на целевом устройстве необходимо проверить объект, правило, порядок и timestamp. Успешно закрытый диалог Central — не техническое доказательство commit.

Этот список показывает, почему я оцениваю Maintenance Releases не только по длине перечня функций. Если logging, Postgres, SD-WAN или Multicast переводит firewall в Failsafe или перезапускает её, исправление важнее новой плитки dashboard.

Но число исправлений не является автоматическим знаком качества. Оно показывает, что проблемы устранены, и одновременно — сколько серьёзных ошибок было в прежних builds. Владельцу критичной HA, VPN или WAF среды не следует ни вечно оставаться на старой сборке из страха, ни распространять MR2 повсюду без тестов в первый день.

Что проверить администраторам перед обновлением

Sophos рекомендует оперативно установить MR2 из-за исправлений безопасности, стабильности и производительности. Это понятно. Но в production «оперативно» не означает «вслепую».

Устаревший VLAN tagging на Bridges блокирует MR2

MR2 вводит жёсткую блокировку обновления при старом VLAN tagging через CLI на Bridge Interfaces. Если конфигурация ещё использует механизм legacy system vlan-tag, firewall нельзя обновить до SFOS 22.0 MR2 или новее.

Такие конфигурации нужно очистить или мигрировать заранее. Кроме того, backups с этой legacy-конфигурацией нельзя восстановить на SFOS 22.0 GA и новее. Это особенно важно для старых установок, когда-либо изменённых через CLI.

Прежние препятствия v22 сохраняются

Продолжают действовать известные требования GA и MR1:

• Legacy Remote Access IPsec нужно удалить или мигрировать до MR1 или MR2.
• SFOS 22 требует больше дискового пространства; отдельные desktop, виртуальные или программные appliances нужно заранее адаптировать.
• Поведение policy-based IPsec VPN изменилось с GA и требует проверки соответствующих туннелей.
• Оборудование XG и SG не поддерживается SFOS 22.
• Старые RED 15, RED 15w и RED 50 не поддерживаются с v21.5.

Моя процедура обновления

Для production firewalls я бы как минимум:

1. Создал актуальный backup и сохранил его вне устройства.
2. Проверил поддержку, лицензии и разрешённый путь обновления.
3. Исключил Legacy Remote Access IPsec и CLI VLAN tagging на Bridges.
4. Проверил предупреждения Disk Space в Control Center.
5. Для HA проверил оба узла, синхронизацию и доступную прошивку.
6. Задокументировал критичные VPN, WAF-публикации, Mail Flows, правила SD-WAN и аутентификацию.
7. Сначала установил MR2 на репрезентативный тестовый или менее критичный appliance.
8. После обновления протестировал logs, версию patterns, HA, routing, DNS, VPN, WebAdmin, reporting и центральные Policy Pushes.

Для релиза с множеством исправлений особенно ценен чистый тест «до и после». Иначе известно лишь, что firmware новая, но не то, работают ли критичные пути данных точно как прежде.

Начиная с версии 20, SFOS выполняет автоматический Firmware Rollback при сбое миграции конфигурации во время обновления. Это снижает риск запуска с Factory Configuration вместо production-конфигурации. Но защита действует не во всех сценариях, например при неподдерживаемом пути обновления или некоторых workflows Setup Assistant. После автоматического rollback следует анализировать migration.log и migrationhash.log.

Автоматический rollback не заменяет внешний backup, Secure Storage Master Key и доступ к консоли. Он защищает преимущественно от сбоя миграции конфигурации, но не доказывает корректность WAF, VPN, HA или reporting после технически успешного обновления.

В своём прямом тесте MR2 я до и после обновления измерю или вызову одинаковые события:

• restart и полный запуск служб;
• вход в WebAdmin и отзывчивость больших списков правил;
• локальный и внешний поток logs;
• трафик IPsec, Rekey и Failover;
• Central Policy Push с проверкой на firewall;
• обновление patterns IPS и Application Control;
• новую аутентификацию STAS и поведение ещё неизвестного Client IP;
• синхронизацию HA и контролируемую смену ролей, если тестовая система является кластером.

Лишь после этого можно сказать, действительно ли MR2 лучше в моей среде. Успешной установки и зелёной страницы Control Center недостаточно.

Что говорят первые отзывы сообщества

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

Но стоит отметить две дискуссии:

• Оператор XGS 5500 в Active-Passive HA прямо спрашивает о глубине тестов, поскольку NC-177467 мешала ему месяцами на MR1. Sophos называет ошибку исправленной в MR2. Она не позволяла Auxiliary-устройству запуститься из-за множества одновременных неаутентифицированных SSH-подключений.
• По сигнатурам PQC сотрудник Sophos подчёркивает, что они намеренно отключены. По мере роста PQC-TLS в браузерах и приложениях немедленное включение может породить множество сообщений. Рекомендуется сначала Allow с logging и только затем, при необходимости, блокирующее действие.

Это разумная ранняя фаза релиза: конкретные тесты, Case IDs и понятные отзывы вместо общего «работает» или «сломано». В первые дни и недели я продолжил бы следить за обсуждением, особенно по HA, IPsec, WAF, STAS и reporting.

Config Studio становится складом запчастей для старого интерфейса

Теперь о неприятном.

Config Studio 2.6 — хороший инструмент. Объединение templates, поиск объектов, раскрытие ссылок в отчёте, сравнение нескольких состояний и подготовка аппаратной миграции — настоящие административные функции. Я критикую не их создание, а место, где Sophos их создаёт.

Sophos теперь прямо называет Config Studio в Firewall Release Notes и официальном анонсе MR2. Инструмент всё больше выглядит стратегическим ответом на проблемы, которые следовало бы решать в WebAdmin или Sophos Central.

Локальный интерфейс firewall в повседневной работе остаётся старым и часто медленным на больших конфигурациях. Массовые изменения недостаточны. Использование объектов, настоящий глобальный поиск, чистые diffs, клонирование NAT, конфликты правил и современный workflow изменений отсутствуют там, где администраторы работают ежедневно. Sophos Central закрывает лишь часть пробела.

Проблема не только в дизайне. Современному интерфейсу firewall, на мой взгляд, нужен надёжный процесс изменений:

• Candidate Configuration вместо немедленно распределяемых одиночных изменений;
• полные diffs до и после перед commit;
• проверка зависимостей объектов, правил, NAT, VPN и TLS;
• атомарный commit или ясный статус транзакции;
• проверенный rollback к последнему известному состоянию;
• достоверная привязка пользователя, времени и источника в Audit Trail;
• Bulk Operations с предварительным просмотром и проверкой конфликтов;
• согласованный API-вывод для воспроизводимых изменений.

Config Studio воспроизводит часть этого вне системы. Она анализирует export, создаёт XML или API Requests и помогает с diffs. Но между offline-представлением и активным состоянием firewall остаётся разрыв. Sessions, динамическая маршрутизация, HA, текущие patterns, сертификаты и фактически загруженная конфигурация — не то же самое, что локально открытый Entities.xml.

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

Workflow остаётся фрагментированным:

1. Экспортировать конфигурацию firewall.
2. Распаковать архив и найти Entities.xml.
3. Загрузить файл в отдельный браузерный инструмент.
4. Там анализировать, сравнивать или редактировать.
5. Экспортировать результат и вернуть его через XML, API или curl.

Для аудита это нормально. Для современного, безопасного и отслеживаемого администрирования — обходной путь. Особенно раздражает, что Config Studio покрывает не один особый случай, а именно те Low-Hanging Fruits, которых администраторы Sophos ждут годами.

И здесь моя критика усиливается: если Sophos уже делает Config Studio крупной темой обычных Firewall Release Notes, внешний инструмент нельзя считать небольшой утилитой. Sophos заметно превращает его в часть стратегии администрирования. Поэтому производитель должен наконец объяснить, какие функции будут интегрированы в WebAdmin или Central, а какие навсегда останутся в браузерном инструменте.

Без roadmap создаётся впечатление, что старый, медленный и всё менее удобный на больших конфигурациях интерфейс останется прежним, а для современных workflows администраторам предложено просто использовать Config Studio. Это не подтверждённый план Sophos, но именно такое направление сейчас передаёт продукт.

Почему UniFi получает лёгкую игру

UniFi не является полной заменой любому Sophos Firewall. В зависимости от лицензии и архитектуры Sophos предлагает более глубокие функции безопасности, IPS, Web Protection, WAF, интеграцию Endpoint, подключение MDR/XDR и классические Enterprise-функции. Честное сравнение не должно стирать различия.

Но в воспринимаемом качестве продукта удобство побеждает каждый день.

Ubiquiti заметно инвестирует в дизайн, мобильные приложения, последовательную навигацию, топологию, простое подключение устройств и понятный без многолетнего опыта интерфейс. Не каждая функция UniFi технически глубже. Но продукт ощущается современнее, и это сильнее влияет на покупку, чем готовы признать традиционные производители firewalls.

Небольшая ИТ-команда при выборе видит не только спецификации IPS. Она спрашивает:

• Как быстро найти устройство, правило или клиента?
• Можно ли содержательно проверить среду со смартфона?
• Понятны ли предупреждения и зависимости без специальных знаний?
• Сколько кликов нужно для повседневного изменения?
• Выглядит ли продукт единой платформой или набором отдельных инструментов?

Здесь Sophos без необходимости облегчает жизнь производителям вроде Ubiquiti. Sophos Firewall может давать больше безопасности и оставаться разумнее для многих сред малого и среднего бизнеса. Но если для современного поиска, diffs, templates и массовых изменений нужен отдельный Config Studio, а основной интерфейс остаётся старым и медленным, Sophos теряет доверие на самом заметном уровне.

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

Вывод: установить MR2, но проблема продукта остаётся

SFOS 22.0 MR2 — не крупный Feature Release. Это важный Maintenance Release с полезными дополнениями.

Контроль PQC появляется вовремя, но сначала должен работать в режиме наблюдения. Улучшенное обнаружение приложений генеративного ИИ помогает видимости и policies, но не заменяет стратегию DLP или управления ИИ. Администраторам Chromebook нужно активно развернуть расширение Manifest V3. STAS становится менее склонным к перебоям, но требует осознанной проверки правил идентичности. Let’s Encrypt готовится к новым цепочкам сертификатов. А многочисленные исправления устраняют проблемы, способные вызывать реальные простои в production.

Я установлю MR2 сразу после backup и preflight, а затем проверю эти пути данных. У затронутых проблемами HA, VPN, reporting, Central или Failsafe есть веские причины обновиться. В день релиза нельзя серьёзно сказать, будет ли сборка 546 действительно спокойнее или принесёт новые регрессии.

Моя критика остаётся чёткой: Config Studio 2.6 полезна, но её заметная роль в релизе firewall усиливает ощущение, что Sophos переносит современное администрирование во вспомогательный инструмент. Это не подтверждённый отказ от нового интерфейса SFOS, но стратегически тревожный сигнал.

У Sophos сильная база firewall. Производитель должен наконец дать администраторам опыт управления, соответствующий этой технической основе. Иначе современные платформы победят не обязательно лучшей безопасностью, а более серьёзным отношением к человеку перед экраном.

До следующего раза,
Joe

FAQ