Sophos Firewall Configuration Viewer：审计与对比配置

大家好，

如果你在真实的业务环境里管理过 Sophos Firewall，你一定知道这个困境：配置就是“single source of truth”。但只要你想在 web UI 之外复盘配置、认真做文档，或者对比一次改动的前后差异，事情很快就会变得痛苦。

当然，你可以截图。你也可以导出单条规则。但一旦遇到更大的变更（WAN 迁移、新 VLAN、对象清理、重构 NAT 逻辑、“就顺手”改几个 VPN），你真正需要的其实只有两件事：

1. 可读的配置。
2. 一个不是“对着 XML 做 diff 然后流泪”的对比方式。

这正是 Sophos Firewall Configuration Viewer 的用武之地。

它不会替你负责。你仍然要设计干净的配置、认真测试变更。但它会拿走日常运维里一个非常耗时的东西：格式问题。把“技术上正确但极难阅读”的导出文件，变成“你真的可以拿来工作的视图”。

而且我承认我在这方面很“龟毛”。规划变更时，我不只是想知道“变了”，我想知道“到底变了什么”，以及我是否不小心碰到了某个对象、某条 NAT 规则或某个 VPN 设置。Viewer 在这件事上非常务实。

Sophos Firewall Configuration Viewer 是什么？

Sophos Firewall Configuration Viewer 是一个基于浏览器的工具，用于将 Sophos Firewall 配置转换成 人类可读 的格式。它可以帮助你：

• 对配置进行过滤、排序与搜索
• 搜索特定对象/主机/FQDN，并查看它们在哪里被引用
• 对比两份配置（Added/Modified/Removed）
• 将结果导出为 HTML 报告

重要的是：它是一个 独立工具，直接用浏览器打开即可。不需要安装，基本上任何管理员的笔记本都能用。这也是我喜欢它的原因：可以很自然地融入现有流程。

它的核心输入其实就是 Sophos 原本就提供的配置导出 XML（通常是 Entities.xml）。差别在于呈现方式：你不需要盯着 XML 结构，而是得到一个更像“整理好的文档”的视图。

而且它不仅仅是“查看”。在实际运维中，最常用的三件事是：

1. 阅读：结构化、可过滤的配置视图。
2. 搜索/引用关系：找到对象并确认它被哪些地方使用。
3. 对比：变更前后，或 Firewall A vs Firewall B。

安全与隐私方面最关键的一点：Sophos 强调数据会在 浏览器本地处理，不会被“上传”。解析、分析和报告生成都应该发生在你的设备上。

工具入口在这里：Sophos Firewall Configuration Viewer

如果你想先看一个快速演示，这是 Sophos 的 TechVid：

一个常见的中小企业实战场景

周五下午 3:30。一家约 80 人的公司：新接入了一条互联网线路，公网 IP 也换了，同时还在做一个小项目（新 CRM、新子网）。变更申请写得很清楚：哪些 NAT 规则要改、哪些 VPN endpoint 要改、哪些防火墙规则会受影响。

但现实通常是这样：

• 一个像 WAN_Public_IPs 的对象，被三条 NAT 规则、两条业务应用规则，以及一条“历史遗留”的 WAF 规则引用，而这条 WAF 规则可能几年没人看过。
• 某个 SaaS 的 FQDN 对象曾经被塞进一个组，现在出现在 10 条规则里，但真正还相关的可能只有 2 条。
• 你想清理，但你不想周一早上接到电话：“自从那次变更之后，我们的 X 不工作了。”

这就是 Configuration Viewer 真正省时间的地方。

我在这种场景下常用的流程是：

1. 变更前导出（保存 baseline）
2. 实施变更
3. 变更后导出
4. 在 Viewer 里做一次 diff，把 HTML 附到工单里
5. 删除对象前：用 Usage Reference 确认它到底在哪里被使用

这不只是方便。它让变更具备可追溯性。审计、内部审批，以及未来的你都会感谢这一点。

工具的实际用法

1) 导出配置（Full 或 Selective）

直接在防火墙上导出：

• WebAdmin：Backup & Firmware > Import / Export
• 选择 Export full configuration（全部）或 Export selective configuration（部分，可选勾选 “Include dependent entity”）

Sophos 会生成一个 .tar 文件供你下载。

一些在实际运维里很重要的细节：

• Full export 是我做变更管理（baseline/diff）的默认选择。拿到全部内容，依赖关系不容易漏。
• Selective export 适合你只想审一部分（比如只看 interfaces + routing），或需要与第三方（ISP/vendor）协作、并尽量减少暴露信息时使用。
• Include dependent entity 对 selective export 往往很关键：如果你只导出 firewall rules，通常也希望把它引用到的 network/service objects 一并导出，不然很容易“缺上下文”。

对比的一个 pro tip：做 “Compare” 时，务必导出 两份选择完全一致的配置（Full vs Full，或 Selective vs Selective 且勾选项相同）。如果你拿 Full 去对比 Selective，差异会很夸张，但实际意义很小。

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"

最后删掉目录即可。听起来很基础，但这正是防止敏感配置“在电脑里躺几周”的卫生习惯。

安全提醒：根据 Sophos 文档，不含敏感内容的导出（例如只导出接口）往往只包含 Entities.xml。一旦包含敏感信息（例如 users），TAR 里可能还会有 hashFile.json、propertyfile 等附加文件。

实际操作上：把整个 TAR 当作机密数据处理。

3) 让配置变得“可读”

在 Viewer 中选择 “Single configuration”（或类似选项），上传 Entities.xml。随后你会得到一个渲染后的配置视图。

配置越大，加载可能需要几秒。之后你会得到一个 web UI 里经常缺失的东西：一种更接近“文档视角”的配置浏览方式，而不需要在很多菜单间来回跳。

我最喜欢的是左侧的过滤能力。如果你正在做 routing/NAT 相关的变更，你不想在 report、logging、各种边缘功能里滚动。你只需要打开 此刻 相关的部分。

实际常用的过滤组合：

• 只看 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 报告。

我经常把它当作“review 包”：导出 HTML，放进变更工单（或内部安全文档目录），让其他同事在不登录防火墙的情况下也能审阅配置。这对四眼复核、内部审批、外部审计都很实用。

4) Usage Reference：对象到底被哪里使用？

这对我来说是 killer feature。

Sophos 的配置大量依赖 objects：hosts、networks、services、FQDNs、groups。这很好，因为可复用。但几年之后，你往往不再清楚一个对象到底挂在哪些地方。

而经典事故就发生在这里：

• 有人因为“看起来旧”就删了对象，后来才发现它还在某条 NAT 规则里使用
• 有人修改对象（比如扩大 IP 段），结果不知不觉影响了多条 policy

Usage Reference 能把这些依赖关系显性化。 你不需要在 web UI 里“凭感觉”找，而是用 search/Usage Reference 直接定位对象或 hostname 的引用点。

TechVid 里的例子是搜索 box，立刻能看到哪些 policies/NAT rules 引用了那个 FQDN 对象。

更舒服的是 click-through：从搜索结果点进对象，再看到引用关系（哪些 firewall policy、哪些 NAT rule 在用）。我做 cleanup change 时经常把这一页导出成 HTML 附到工单里，后续就能解释清楚为什么删/改了这个对象。

适用场景：

• cleanup（清理旧对象）
• 变更规划（到底哪些规则需要改）
• 故障排查（为什么规则还在匹配）

5) 对比两份配置（Before/After）

在工具首页选择 “Compare” 而不是 “View”，上传两份 Entities.xml。

这看起来很简单，但非常强。我经常用它来做：

• 变更前后对比（经典）
• test/staging 与 production 对比，找 drift
• 迁移后的验证（新 WAN、新 NAT 逻辑、新 VPN）

我喜欢 compare 模式的一点是：它不是简单的文本 diff，而是试图“按意义”分组变化。你看到的不是“XML 变了”，而是：这个对象新增、那条规则修改、这个条目删除。

这正是变更管理需要的输出：

• summary：removed/modified/added 了什么
• 每个对象/规则的细节
• 可选的 raw XML 左右对照
• 可导出 HTML 用于工单/审计

我个人的流程很简单（但有效）：

1. 先看 summary：变化规模是否合理？（比如“只改了 3 条规则”，却出现“200 个对象 modified”）
2. 钻进关键区域：interfaces/WAN、routing、NAT、VPN、firewall rules
3. 趁记忆还新鲜把 HTML 导出保存下来

尤其是第 1 步能显著减少焦虑。如果看到 只有 预期对象发生变化，我的周末睡眠质量都会更好。

如果你养成了为大变更保存 before/after diff 的习惯，长期来看会省掉很多麻烦。

功能与特性更细节的视角

到这里工具已经很实用了。但用过几次你会发现：Viewer 更像一个小工具箱，专门解决管理员常见问题。下面是我在日常里最常用的点。

Human-Readable View：不用再在 UI 里“点马拉松”

Sophos 的 web UI 逻辑上是分组的，但信息分散在很多页面。快速操作可以，做审计或规划变更就很累，因为上下文不断被打断。

Viewer 把它压缩成一份更紧凑的展示。我通常用它做快速 reality check：

• 实际有哪些 interfaces/zones？
• 哪些 NAT 规则在发布哪些服务？
• 哪些规则过于宽松，只是因为以前“必须能用”？

它不能替代良好的设计，但能让你看清最终配置 到底写成了什么样子。

Filters：把注意力放在此刻最重要的部分

左侧过滤器看似普通，但在实际运维里非常值钱。大多数变更并不涉及整个配置，而是某个区域（WAN、NAT、VPN、routing）。

比如我在接入新线路时，会把视图压缩到：

• interfaces/WAN
• routing/SD-WAN
• NAT
• firewall rules（受影响的流）

这听起来很基础，但能避免你在 review 时陷入无关的细节。

Search：从 “box” 到 “10.20.30.0/24”

Search 是一个很好的入口，尤其当你从运维现场带回来的只有症状：

• “我们连 box.com 的业务不通了”
• “新分支网络 10.20.30.0/24 没有访问权限”
• “为什么 SMTP 还开着？”

你可以按名称、IP、FQDN、对象搜索，很快定位到相关位置。

Usage Reference：在“疼”之前先看到影响范围

Usage Reference 往往决定一次 cleanup 是“大胆”还是“负责任”。我主要用在三个场景：

1. 删除对象：先确认它是不是还被引用。
2. 修改对象：先确认会间接影响多少 rules/policies。
3. 规划变更：先确认哪些规则真正依赖同一对象。

坚持这样做，“啊原来还挂在这里”的意外会少很多。

Compare + HTML 导出：我做变更管理的默认动作

Compare 模式对我来说是“变更按计划发生了”的证据。

我大多数时候是这样做：

1. 变更前导出
2. 变更后导出
3. Compare
4. 保存 HTML diff 并附到工单

看起来有点“较真”，但只花几分钟，却能在之后有人追问“到底改了什么”时省下大量沟通时间。对团队 review 来说也很好用。

安全：优点与边界

1) Privacy-first 很棒，但别把它当成大意的理由

“数据不出浏览器”是一个很强的优点。

但防火墙配置几乎总是敏感的。即便没有明文密码，里面也常有：

• 内部网络、VLAN、IP 规划
• NAT 定义与公网 endpoint
• VPN 拓扑
• 对象组（经常比你想象的更“泄露信息”）

2) 真正的风险在导出文件的生命周期

Viewer 帮你读配置，但风险更多发生在前后：

• 下载 TAR
• 解压
• 保存/分享 HTML 报告

Sophos 明确提到：包含敏感信息的导出可能会有额外文件；导入时还涉及 secure storage master key 等话题。

我的日常建议：

• 导出文件尽量短时间留在本机，用完就清理
• 不要把报告丢进“开放”的工单系统
• 与第三方协作时优先用 selective export，并只分享必要内容

3) SSH/Advanced Shell：Viewer 只能看到 export 里有的东西

在真实环境里，事故发生时通过 SSH 进入 Advanced Shell “先把问题救回来”并不少见。

关键点不是“这次修补会不会撑过重启”，而是：如果某些东西没有进入导出（Entities.xml），Viewer 就看不到。 Advanced Shell/SSH 的调整并不一定会以“正常配置”的形式出现在导出中。

所以如果你通过 SSH/Advanced Shell 做了改动：请单独记录，并规划将其回归到 WebAdmin 的正式配置里。否则下一次 restore、HA failover 或固件升级时就可能踩坑，或者你在 diff 里根本看不到它。

4) 生产环境里真正有用的几条规则

1. 用一个扩展插件尽量少的浏览器 profile 来做这类工作。
2. TAR/HTML 只存放在你平时存放机密配置的地方。
3. 必须分享时：尽量 selective export，并考虑依赖项。

总结

Sophos Firewall Configuration Viewer 并不是那种会上新闻的功能。但说实话：这类工具才是真正让你在日常运维里“省心”的关键。

这些年我见过很多配置，真正让人崩溃的不是技术，而是可追溯性：什么时候改了什么？对象到底还用不用？我们有没有顺手碰到别的东西？web UI 能查到很多，但不快。直接读 XML 导出更是没人愿意做超过五分钟。

Viewer 很好地补上了这块短板。你可以像读文档一样读配置、按需过滤、检查引用关系，并在最后保存 HTML diff。对团队来说，这会让 review 更轻松、审计更平静、周一早上的惊吓更少。

如果你只带走一个习惯：请建立一个小反射动作。

大变更前导出一次，大变更后再导出一次，Compare，保存 HTML diff。 只花几分钟，但它能有效对抗“我感觉只改了 X”这种错觉。

以及一如既往：Viewer 只会让配置 更可读，不会自动让它 更安全。思考仍然是你的工作。它只是终于给了你一个不和你作对的工具。

如果你过去曾在 Advanced Shell 里通过 SSH 做过 “quick & dirty” 的调整，请记住：它们不一定出现在备份/导出里，因此 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