F1000 配置 URL 黑名单阻断域名，但上级天眼系统仍能查获该域名

核心现象：防火墙阻断了 TCP 网页访问，但是 DNS 解析报文依然向外发出；上级天眼（旁路镜像 / 流量探针）抓到 DNS 请求报文，上报记录，所以会告警查获该非法域名。

主要 4 个根因（按出现概率排序）

1️⃣URL 过滤≠DNS 过滤（最常见）

F1000 的URL 黑名单工作在 HTTP/HTTPS 应用层：

• 只拦截网页连接（HTTP 请求、HTTPS 的 SNI 握手）；
• DNS 域名解析报文（UDP53）默认完全放行，防火墙不会阻止终端发 DNS 查询；

内网终端会正常向 DNS 服务器查询非法域名，DNS 请求报文穿过防火墙，上级天眼做端口镜像抓出口流量，直接捕获 DNS 请求，就产生告警记录，哪怕后续网页访问被防火墙阻断H3C。

一句话区分：

• URL 过滤：拦网页访问；
• DNS 报文放行：域名解析查询还会出去，镜像设备能看见。

2️⃣HTTPS 流量未正确识别黑名单

1. 如果没有开启https‑traffic‑filter enable，HTTPS 流量不做 URL 黑名单匹配，黑名单对 HTTPS 网站不生效H3C。
2. TLS1.3 场景，部分客户端 SNI 加密，防火墙提取不到域名，黑名单失效。

核查命令：display url‑filter profile，确认开启 HTTPS 流量过滤。

3️⃣安全策略没有正确引用 URL 过滤配置文件

安全策略动作是允许，但是内容安全配置文件没有绑定 URL‑filter；黑名单根本没有生效，终端实际可以访问，天眼自然捕获访问行为H3C。

查看策略内是否调用 url‑filter 配置文件。

4️⃣天眼采集位置在防火墙内侧

镜像点接在 F1000 的内网侧（Trust 侧），终端发出的 DNS、网页请求还没经过防火墙处理就被镜像采集，防火墙阻断动作发生在镜像点之后，天眼提前抓到报文产生告警。

解决办法（要同时实现【阻断访问】+【不让 DNS 查询报文流出被审计捕获】）

方案 A：在防火墙上拦截 DNS 请求报文（推荐）

在安全策略，针对 UDP53（DNS）增加规则：内网终端访问 DNS 服务器，禁止内网向 DNS 服务器查询该非法域名。

方式 1：使用域名信誉（DNS 域名黑名单），直接在 DNS 解析阶段丢弃该域名的 DNS 请求报文，DNS 报文不会发送到外网，上级天眼抓不到该 DNS 查询报文。 方式 2：ACL + 安全策略，拦截内网终端去往 DNS 服务器、目的 UDP53，配合 FQDN 对象匹配非法域名。

⚠️注意：FQDN 对象是匹配目的 IP，不是匹配 DNS 报文内容；想要拦截DNS 报文中的域名字符串，需要使用【域名信誉】特性。

方案 B：镜像采集点改到防火墙的外网 Untrust 侧

天眼镜像口接 F1000 出口外网侧；防火墙处理完成后的流量才会被镜像，被防火墙丢弃的报文不会出现在镜像流量，天眼就不会捕获。

方案 C：双重校验

1. 保留原有 URL 黑名单，阻断网页访问；
2. 开启https‑traffic‑filter enable，保证 HTTPS 域名识别；
3. 同时配置域名信誉黑名单，丢弃 DNS 请求报文。

核查命令

简短总结

1. URL 黑名单只拦网页，不拦 DNS 查询报文；DNS 请求报文依然会发到外网，上级镜像天眼抓到 DNS 请求就上报告警，这是最主要原因。
2. 想要彻底避免天眼查获，不能只配 URL 黑名单，需要域名信誉黑名单拦截 DNS 报文，或者把镜像采集点放到防火墙外网侧。
3. 检查是否开启https‑traffic‑filter enable，否则 HTTPS 网站黑名单不生效。

补充：如果是上级是旁路镜像，旁路只能看流量，不能干预流量；旁路看到 DNS 查询就会告警，和防火墙是否阻断网页访问是两件独立的事。

防火墙已阻止但天眼仍告警，核心问题通常在于流量虽然被防火墙处理，但其访问行为已被天眼记录。要解决此问题，关键是让防火墙在域名解析阶段就进行阻断，而非在连接建立阶段。

 核心原因：为什么阻止了还会告警？

这通常由以下一个或多个原因导致：

• HTTPS加密流量无法识别：这是最常见的原因。如果目标域名使用HTTPS（443端口），防火墙的URL过滤功能无法解密查看其内容，因此可能无法阻止。天眼作为旁路检测设备，可以通过其他技术（如SNI、证书等）识别出加密流量中的域名，从而产生告警。

• 防火墙部署模式限制：如果防火墙采用透明模式（二层部署），它只能基于IP地址进行过滤，无法识别HTTP/HTTPS流量中的域名。域名只出现在DNS请求中，业务流量里只有IP，因此基于域名的策略会失效。

• DNS解析绕过：终端设备可能使用了防火墙未监控到的DNS服务器（如直接使用8.8.8.8），导致防火墙无法干预域名解析过程。

• 浏览器兼容性问题：部分新版浏览器（如Chrome/Edge）可能使用私有加密或报文分片技术，导致防火墙无法从流量中提取出域名进行匹配。

• License或特征库问题：URL过滤功能需要有效的License授权才能使用。同时，如果URL特征库版本过旧，也可能无法识别最新的域名。

 系统性排查与解决方案

建议按以下顺序排查，以定位问题根源：

第一步：确认防火墙基础配置与状态

1. 检查License：确认URL过滤功能的License是否有效且未过期。

2. 更新特征库：确保URL过滤特征库已升级到最新版本。

3. 确认策略配置：检查URL过滤配置文件（Profile）是否已正确引用到安全策略中，且安全策略的动作是“拒绝”。

4. 查看命中日志：在防火墙的日志中（路径通常为：日志中心 > 策略日志 > URL过滤），检查是否有针对该域名的拒绝记录。如果没有任何日志，说明流量根本没有匹配到策略，问题可能出在流量路径或DNS解析上。

第二步：采用DNS过滤方案（推荐且最有效）

解决HTTPS加密和透明模式限制的根本方法是在DNS解析阶段进行阻断，让终端根本无法获得目标域名的IP地址。

• 配置DNS过滤：在防火墙的URL过滤配置中，勾选“启用DNS过滤”。这样，当终端发起DNS查询请求时，防火墙会直接拦截对黑名单域名的解析，终端因无法获得IP而无法访问。

• 配置DNS代理（可选但推荐）：为了确保所有终端的DNS请求都经过防火墙，可以开启DNS代理功能，并将终端的DNS服务器指向防火墙的内网接口地址。

  bash

  # 示例：开启DNS代理 [H3C] dns proxy enable [H3C] dns server 114.114.114.114 # 指定上游DNS服务器

  随后，在DHCP地址池中将DNS服务器地址配置为防火墙的内网接口IP。

第三步：其他辅助排查与优化

• 核对域名与IP：如果必须使用IP过滤，请确认防火墙解析到的IP与终端实际访问的IP完全一致。可以使用 nslookup 命令在终端和防火墙上分别验证。

• 检查策略顺序：确保拒绝策略的优先级高于允许策略，避免被更宽泛的允许规则提前匹配。

• 排查浏览器因素：可以尝试使用系统自带的浏览器（如IE）或旧版浏览器进行测试，以排除浏览器兼容性问题。

• 升级防火墙版本：如果排查后确认为防火墙软件Bug（如对某些浏览器分片报文识别失败），建议升级到官方修复后的最新版本。

正常得，DNS得请求解析报文还是会发，防火墙记录返回得解析记录，根本上还是禁用的解析后得IP地址