Sophos Firewall Configuration Viewer: как проверять и сравнивать конфигурации

Всем привет,

если ты когда-либо админил Sophos Firewall в реальном бизнесе, ты знаешь эту боль: конфигурация - это “single source of truth”. Но как только нужно спокойно перечитать ее вне web UI, нормально задокументировать или сравнить “до/после” изменения, становится неприятно.

Да, можно делать скриншоты. Да, можно экспортировать отдельные правила. Но как только речь про изменения посерьезнее (миграция WAN, новые VLAN, чистка объектов, перестройка NAT-логики, “давай быстро” поправить пару VPN), ты хочешь две вещи:

1. Конфиг, который можно читать.
2. Сравнение, которое не выглядит как “diff XML и плач”.

И вот тут появляется Sophos Firewall Configuration Viewer.

Этот инструмент не снимает с тебя ответственность. Конфиг все равно нужно проектировать нормально и изменения - тестировать. Но он убирает то, что в повседневной работе съедает абсурдно много времени: проблему формата. Он превращает экспорт, который технически корректен, но читать его невозможно, в представление, с которым реально можно работать.

И да - я тут придирчивый. Когда я планирую change, мне недостаточно знать что что-то изменилось. Я хочу понимать что именно изменилось, и не задел ли я случайно какой-нибудь объект, NAT-правило или VPN-настройку “по краю”. Viewer - удивительно прагматичная штука именно для этого.

Что такое Sophos Firewall Configuration Viewer?

Sophos Firewall Configuration Viewer - это браузерный инструмент, который конвертирует конфигурации Sophos Firewall в человеко-читаемый формат. С его помощью можно:

• фильтровать, сортировать и искать по конфигурации
• находить объекты/хосты/FQDN и смотреть, где они используются
• сравнивать две конфигурации (Added/Modified/Removed)
• экспортировать результат как HTML-отчет

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

Под капотом он работает с тем, что Sophos и так выдает: экспорт конфигурации в XML (обычно Entities.xml). Разница - в подаче. Вместо того чтобы смотреть на XML-структуры, ты получаешь вид, который ощущается как аккуратно собранная документация.

И это не только “посмотреть”. На практике постоянно нужны три вещи:

1. Read: структурированный просмотр конфига с фильтрами.
2. Search/References: поиск объектов и их мест использования.
3. Compare: сравнение до/после или firewall A vs firewall B.

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

Инструмент здесь: Sophos Firewall Configuration Viewer

Если хочешь сначала короткий walkthrough, вот TechVid от Sophos:

Реальный кейс из SMB

Пятница, 15:30. Компания примерно на 80 сотрудников: новая интернет-линия, новые публичные IP, и параллельно небольшой проект (новая CRM, новые подсети). Change request написан нормально: какие NAT-правила, какие VPN endpoints и какие firewall rules нужно поправить.

На практике происходит классика:

• Объект вроде WAN_Public_IPs используется в трех NAT-правилах, двух business-application правилах и одной “исторической” WAF-правилке, о которой никто не вспоминал годами.
• FQDN-объект для SaaS когда-то добавили в группу - и теперь он всплывает в десяти правилах, хотя реально нужны два.
• Ты хочешь навести порядок, но ты не хочешь звонка в понедельник утром: “После изменения X перестало работать.”

Вот где Configuration Viewer экономит реальное время.

Мой типичный подход в таких ситуациях:

1. Экспорт до (сохранить baseline)
2. Внести изменения
3. Экспорт после
4. Прогнать diff в viewer и приложить HTML в тикет
5. Перед удалением объектов: использовать Usage Reference, чтобы проверить, где они реально используются

Это не просто удобство. Это делает изменения прозрачными и проверяемыми. А это ровно то, что нужно аудитам, внутренним согласованиям и твоему будущему “я”.

Как пользоваться инструментом в реальной работе

1) Экспорт конфигурации (Full или Selective)

Экспортируй конфиг прямо с firewall:

• WebAdmin: Backup & Firmware > Import / Export
• Экспорт либо Export full configuration (всё), либо Export selective configuration (выборочно, опционально с “Include dependent entity”)

Sophos сформирует .tar файл, который ты скачиваешь.

Несколько деталей, которые реально важны:

• Full export - мой default для change management (baseline/diff). Ты получаешь всё и меньше рискуешь упустить зависимости.
• Selective export удобно, когда нужно проверить только конкретную область (например только interfaces + routing) или когда нужно что-то отдать третьим лицам (ISP/vendor) и ты хочешь минимизировать, что именно раскрываешь.
• Include dependent entity часто критично для selective export: если ты экспортируешь firewall rules, тебе обычно нужны и объекты network/service, на которые они ссылаются. Иначе экспорт будет неполным и контекст потеряется.

Pro tip для сравнения: для “Compare” всегда экспортируй две конфигурации с одинаковым набором выбранных пунктов (Full vs Full, или Selective vs Selective с одинаковыми галочками). Если сравнивать Full с Selective, diff будет выглядеть впечатляюще, но по сути это мусор.

2) Распаковать TAR и найти Entities.xml

Из .tar нужно достать Entities.xml (в зависимости от экспорта файл может называться и entities.xml).

На macOS/Linux:

tar -xvf backup.tar
ls -la

На Windows можно использовать, например, 7-Zip.

Если (как я) ты не хочешь, чтобы такие бэкапы валялись в Downloads, создай временную рабочую папку. Пример для macOS/Linux:

WORKDIR="$(mktemp -d)"
tar -xvf backup.tar -C "$WORKDIR"
ls -la "$WORKDIR"

В конце папку можно удалить. Звучит банально, но это ровно та гигиена, которая не дает чувствительным конфигам лежать неделями.

Для твоего security-радара: по документации Sophos экспорт без чувствительных данных (например только interfaces) часто содержит только Entities.xml. Как только в экспорте есть sensitive info (например users), TAR может дополнительно содержать файлы вроде hashFile.json и propertyfile.

Практический вывод: считай весь TAR конфиденциальным.

3) Сделать конфиг “человеко-читаемым”

В viewer выбираешь “Single configuration” (или аналогично) и загружаешь Entities.xml. После этого получаешь отрисованное представление конфига.

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

Что особенно нравится: слева можно агрессивно фильтровать. Если change про routing/NAT, ты не хочешь листать отчеты, логирование и второстепенные функции. Ты включаешь только те разделы, которые важны прямо сейчас.

Типичные комбинации фильтров:

• только firewall rules + NAT
• только interfaces + routing
• только VPN

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

1. Interfaces/zones (что внутри, что снаружи?)
2. Routing/SD-WAN (как трафик выходит наружу, откуда берутся обратные маршруты?)
3. NAT (что публикуется, что переписывается?)
4. Firewall rules (какие потоки реально разрешены?)
5. VPN (site-to-site и remote access, в зависимости от сетапа)

Это не единственный правильный порядок, но он помогает не оценивать правила, не понимая топологию.

И если нужно что-то для документации или согласования: в любой момент можно экспортировать HTML-отчет.

Мне нравится использовать это как “пакет для ревью”: экспортируешь HTML, прикладываешь к change ticket (или сохраняешь в защищенной внутренней документации), и другой человек может прочитать конфиг без доступа к firewall. Это отлично работает для принципа “четырех глаз”, внутренних согласований и внешних аудитов.

4) Usage Reference: “Где этот объект реально используется?”

Для меня это killer feature.

Sophos-конфиги сильно завязаны на объекты: hosts, networks, services, FQDN, группы. Это классно, потому что можно переиспользовать. Минус: спустя пару лет часто уже не очевидно, где конкретный объект используется.

И именно тут случаются типовые ошибки:

• кто-то удаляет объект “потому что выглядит старым”, а потом выясняет, что он все еще был в NAT-правиле
• кто-то меняет объект (например расширяет IP range) и незаметно меняет сразу несколько policies

Usage Reference в viewer делает зависимости видимыми. Вместо поиска в web UI “на глаз”, ты используешь поиск/Usage Reference, чтобы понять, где объект или hostname упоминается.

Пример из TechVid: ищешь box - и сразу видишь, какие policies/NAT rules ссылаются на FQDN-объект.

Кайф в том, что это кликабельный путь: из поиска ты переходишь в объект и видишь ссылки (например какая firewall policy или NAT rule использует его). Когда я делаю cleanup change, я часто экспортирую эту страницу в HTML и прикладываю к тикету. Потом легко объяснить, почему объект был удален или изменен.

Идеально для:

• cleanup (удаление старых объектов)
• планирования изменений (какие правила реально нужно трогать)
• troubleshooting (почему правило все еще где-то матчится)

5) Сравнить две конфигурации (Before/After)

На стартовой странице можно выбрать “Compare” вместо “View” и загрузить два файла Entities.xml.

Звучит просто, но это очень мощный паттерн. Я использую его, например, для:

• сравнения до/после изменения (мой классический кейс)
• сравнения тест/стейджинга с продом, чтобы увидеть drift
• проверки после миграций (новый WAN, новая NAT-логика, новый VPN)

Что мне нравится в compare mode: это не просто “сырой текстовый diff”. Он пытается группировать изменения осмысленно. Ты видишь не только “XML отличается”, а: этот объект добавлен, это правило изменено, эта запись удалена.

Это ровно то, что нужно для change management:

• summary: что удалено, изменено, добавлено?
• детали по объектам/правилам
• raw XML side-by-side (опционально)
• HTML export для тикета/аудита

Мой workflow довольно прямолинейный (но эффективный):

1. Смотрю summary: порядок цифр логичный? (например “я изменил 3 правила” vs “почему-то 200 объектов modified”)
2. Проваливаюсь в критичные зоны: interfaces/WAN, routing, NAT, VPN, firewall rules
3. Сохраняю HTML export, пока всё еще свежо

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

Если выработать привычку сохранять before/after diff для больших изменений, жизнь в долгую станет заметно проще.

Функции и возможности подробнее

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

Human-Readable View: наконец без марафона кликов

В Sophos web UI настройки часто логично сгруппированы, но раскиданы по куче страниц. Для “быстро” это нормально. Для аудита и планирования изменений - выматывает, потому что постоянно теряешь контекст.

Viewer превращает это в компактное представление. Я использую его как быстрый reality check:

• какие interfaces/zones реально существуют?
• какие NAT rules публикуют какие сервисы?
• какие правила слишком широкие, потому что когда-то “надо было, чтобы работало”?

Это не заменяет хороший дизайн, но помогает увидеть, как именно firewall описан в итоге.

Фильтры: фокус на том, что важно сейчас

Фильтры слева выглядят простыми, но на практике это золото. Большинство изменений касается не всей конфигурации, а конкретной области (WAN, NAT, VPN, routing).

Когда я подключаю новый интернет-канал, я скрываю всё и оставляю:

• interfaces/WAN
• routing/SD-WAN
• NAT
• firewall rules (для затронутых потоков)

Звучит тривиально, но это не дает утонуть в “побочных квестах” во время review.

Поиск: от “box” до “10.20.30.0/24”

Поиск - отличный вход, когда у тебя есть только симптом:

• “Сервис к box.com перестал работать”
• “Новая сеть филиала 10.20.30.0/24 без доступа”
• “Почему SMTP вообще еще открыт?”

Ты ищешь по имени, IP, FQDN или объекту и быстро находишь релевантное место.

Usage Reference: видеть impact (до того как станет больно)

Usage Reference чаще всего определяет, будет ли cleanup “смелым” или “ответственным”. Я использую это в трех случаях:

1. Удаление объектов: сначала проверяю, где он используется.
2. Изменение объектов: сначала проверяю, сколько правил/политик затронется косвенно.
3. Планирование changes: сначала проверяю, какие правила реально завязаны на один и тот же объект.

Если делать это системно, количество “о, оно еще тут использовалось” резко падает.

Compare + HTML export: мой default для change management

Compare mode для меня - это “доказательство”, что change прошел так, как планировалось.

Чаще всего делаю так:

1. Export до
2. Export после
3. Compare
4. Сохранить HTML diff и приложить к тикету

Это выглядит педантично, но занимает минуты и может сэкономить часы обсуждений позже, когда кто-то спросит, что именно изменилось. Для команды это еще и отличный формат ревью: можно попросить коллегу прочитать HTML diff и проверить только критичные моменты.

Безопасность: что хорошо и где пределы

1) Privacy-first - супер, но это не повод расслабляться

То, что Sophos говорит “ничего не уходит из браузера”, - большой плюс, особенно для конфигов.

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

• внутренние сети, VLAN, IP-схемы
• NAT-определения и публичные endpoints
• VPN-топологии
• группы объектов (часто более информативные, чем кажется)

2) Экспорт - это реальный риск

Viewer помогает читать. Но риск почти всегда до и после:

• при скачивании TAR
• при распаковке
• при сохранении/шеринге HTML-отчетов

Sophos явно документирует, что экспорты с чувствительной информацией могут включать дополнительные файлы, и что тема secure storage master key важна при импорте.

Мой совет на каждый день:

• держать экспорты локально как можно меньше (и потом убирать)
• не закидывать отчеты в “открытые” тикет-системы
• если работаешь с третьими сторонами: лучше selective export и делиться только тем, что нужно

3) SSH/Advanced Shell: viewer видит только то, что попало в экспорт

В реальности это встречается чаще, чем принято признавать: во время инцидента кто-то заходит по SSH и “быстро фиксит” что-то в Advanced Shell.

Важно не то, переживет ли этот фикс следующий reboot. Важно другое: если что-то не попало в экспорт (Entities.xml), viewer этого не покажет. И с Advanced Shell/SSH правками это может случиться, потому что они не всегда попадают в экспорт как “обычная конфигурация”.

Если ты трогаешь что-то через SSH/Advanced Shell - документируй отдельно и планируй перенести это в официальную конфигурацию через WebAdmin. Иначе следующий restore, HA failover или firmware update - тот момент, когда это укусит, или ты просто не увидишь это в diff.

4) Практические правила для продакшена

1. Для таких задач используй браузерный профиль без “зоопарка” расширений.
2. Храни TAR/HTML только там, где ты и так хранишь конфиденциальные конфиги.
3. Если нужно поделиться: экспортируй минимально (selective) и думай о зависимостях.

Итог

Sophos Firewall Configuration Viewer - это не фича, которая делает заголовки. Но честно: именно такие инструменты реально разгружают тебе спину в повседневной работе.

За годы я видел достаточно конфигураций, где стресс был не в “технологии”, а в прозрачности: что изменилось и когда? Этот объект правда нигде не используется? Мы случайно не задели что-то еще? В web UI многое можно найти, но редко быстро. А читать XML exports руками - это то, что никто не делает добровольно больше пяти минут.

Viewer неплохо закрывает эту дыру. Я могу спокойно читать конфиг, воспринимать его как документацию, фильтровать нужное, проверять references и в конце сохранять HTML diff. Звучит как “nice”, но в командах это реально помогает: ревью проще, аудит спокойнее, и меньше сюрпризов в понедельник утром.

Если забрать только одну мысль: сделай это привычкой.

Перед большими changes: один раз экспорт, после change - еще один экспорт, Compare, и заархивировать HTML diff. Это несколько минут, но один из самых надежных способов бороться с “мне кажется, мы изменили только X”.

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

Если ты когда-то делал “quick and dirty” правки через SSH в Advanced Shell: держи в голове, что они не обязательно попадают в backups - и тогда их не будет видно в viewer тоже.

Источники и ссылки

• Sophos Community: Sophos Firewall Configuration Viewer
• Sophos Blog (EN): Sophos Firewall Configuration Viewer
• Tool: Sophos Firewall Configuration Viewer
• YouTube: Sophos Firewall Configuration Viewer (TechVid)
• Sophos Docs: Import/Export (TAR, Entities.xml, sensitive content)
• Sophos Docs: How to update and import a configuration
• Sophos Docs: Secure storage master key
• Sophos Docs: Device management / Advanced Shell (backup note)

До встречи, Joe