高危告警但评级SAFE？安全评估工具告警与评级逻辑详解

最近用 SkillSpector 给自己的测试服务器做了一次全方位安全体检，结果报告一出来就让人非常困惑：详细扫描列表里明明躺着好几条高危告警，页面顶部的综合评级却明晃晃显示着 SAFE。我当时的第一个反应是这工具出 bug 了，或者评级阈值被人调错了。于是花了一晚上时间，把告警详情、检测项定义、评分算法全部翻了一遍，最后发现真正的问题出在我自己身上——搞混了“告警”和“评级”这两套体系。这篇文章就把完整的排查过程还原出来，也说说以后遇到“有高危告警但结论 SAFE”这种组合时，应该从哪几个角度去判断它到底是不是一个真问题。

如果你经常用这类安全评估工具，或者经常被报告里“有告警但结论安全”的结果搞得一头雾水，这篇实测记录应该能帮你把思路理清楚。

1. 先交代一下实测背景：告警不少，结论却是 SAFE

这次检测的目标是一台测试服务器，上面跑着 Nginx、Postfix 邮件服务和 OpenSSH，域名解析、证书签发、邮件服务记录都按常规方式配好了，不算特别加固，但也不是裸奔状态。SkillSpector 整体检测项大概一百六十多个，跑完以后生成了几十条提示信息，其中有三条被标成了 High 高危。单看告警列表，这服务器给人的感觉是“问题还挺多”，但顶部综合评级却稳稳停在 SAFE。

这个组合让很多第一次接触的人来说会很分裂，因为直觉上“有高危”和“最终安全”听起来是矛盾的。但如果你把 SkillSpector 这类工具的底层逻辑拆开看，就会发现这根本不是矛盾，而是两套独立机制各管各的结果。下面先把这个核心逻辑说透。

1.1 高危告警到底意味着什么

先说一个最重要的事实：高危告警里的“高危”，指的是检测项与工具内置安全基线之间的偏离程度，不是“攻击者已经能打穿你”的概率。工具里预置了几百条检测规则，每条规则都对应一个理想状态，比如“TLS 配置不应该包含 TLS 1.0/1.1”“邮件服务器不应该允许明文传输”“证书链里不应该出现 SHA-1 签名”等等。只要实际探测结果和这些理想状态不符，规则引擎就会抛出一条告警。

至于这条告警被标成 High、Medium 还是 Low，取决于偏离的严重程度。偏离程度这个词很关键：一个服务端配置文件里只要出现了 TLS 1.0 字样，规则引擎就会认为你“没有遵循现代加密套件基线”，直接给 High 告警，但它不会去深入判断你的服务器实际握手时到底会不会用 TLS 1.0。也就是说，这条告警是高危，只能代表“配置层面存在与基线的偏离”，不能代表“这个偏离已经可以被外部利用”。这个认知是整个排查过程的地基，如果不接受这一点，后面所有解释都会觉得是在给工具找借口。

我后来把这三条高危告警点开逐条看，发现每条下面都标注了验证级别。目前这类检测平台里常见的验证级别大致分三种：

• Evidence：只拿到了配置或网络层面的证据，未确认是否能真实利用。
• Confirmed：已经复现了至少一个可利用条件，比如成功用旧协议握手、成功触发某个漏洞特征。
• Exploited：在受控环境里完整验证了攻击路径，拿到了相对确定的利用结果。

我这次遇到的三条高危告警，清一色都是 Evidence 级别。换句话说，连工具自己都只是“发现了异常迹象”，并没有实际证明它能被打穿。这个细节接下来还会反复用到。

1.2 SAFE 评级看的是什么

综合评级是另一套完全不同的计算逻辑。评级引擎不会简单地把告警数量加一加，然后超过三条就变色。它会把每条告警映射成一条风险证据，然后做三层过滤：

• 可达性：这个端口、服务、协议是否真的能被外部网络触达。
• 可利用性：即使能触达，有没有公开的利用手段或者实际攻击面。
• 影响范围：问题会不会影响核心资产、关键数据，还是只影响某个边缘子服务。

一条告警如果连第一层“可达性”都过不了，它就会被评级引擎标记成“不可利用”或“受限制”，对最终评分没有任何下拉作用。这就是为什么报告里能有一堆红色告警，但总分依然维持在 SAFE 区间。

再加上前面说的验证级别，两条链路一对比就清楚了。评分模型通常会给出一个非常保守的权重策略：Evidence 级别的告警，除非同时满足“公网可达 + 影响核心服务 + 没有任何缓解措施 + 有公开利用链”四个条件，否则基本不会把总体评分拖出 SAFE 区间。而在我的测试场景里，三条高危告警都没能同时满足这些条件。

这里可以把两套体系用一个日常类比说清楚：告警列表就像体检报告里“指标偏高”的明细，SAFE 评级则是医生看完所有指标后给出的综合判断。前者是数据事实，后者是综合诊断，两者本来就不在同一条产出线上。

1.3 告警级别和评分权重为什么是两套体系

可能会有读者问：那为什么不直接让规则引擎把Evidence级别过滤掉，非要保留一堆高危告警？这里其实是产品设计上的有意为之。检测规则如果做得太“聪明”，为了规避误报而把所有没把握的异常全部过滤，就会产生大量漏报，漏报带来的安全风险比误报高得多。所以这类工具普遍采用“宁可多报，不可漏报”的思路，底层规则引擎把能看到的异常全部如实列出来，让评级引擎在后面做二次评估，而不是让规则引擎一边发现问题一边自己先筛一遍。

这样设计还有一个额外好处：告警列表保留了完整的原始证据，你可以拿着它去做人工复核，即使最终结论是 SAFE，也不会丢掉任何值得关注的细节。双层的结构本质上是在覆盖率和准确率之间找到了一个平衡点，代价就是读者看报告时容易产生“报告前后不一致”的观感。可以说，只要理解了“偏移程度”和“可利用风险”是两个维度，这个问题就解开了大半。

2. 实测复盘：三条高危告警，逐条验证

理论说了一堆，还是得上实操。下面把我遇到的这三条高危告警逐条列出来，说明工具为什么报高危、我做了哪些验证、以及为什么 SAFE 结论在当下是成立的。

2.1 告警一：TLS 1.0/1.1 显示开放，实际握手全部失败

SkillSpector 报的第一条高危告警是“检测到 TLS 1.0/1.1 协议支持”，建议禁用旧版协议。从配置层面来看，这条告警有它的道理，因为很多安全基线的确把 TLS 1.0/1.1 视为必须消除的隐患。但我没有直接接受这个结果，而是自己手动做了一次握手验证。

先用系统自带的 openssl 强制走 TLS 1.0 和 TLS 1.1：

openssl s_client -connect 你的域名:443 -tls1 -brief </dev/null openssl s_client -connect 你的域名:443 -tls1_1 -brief </dev/null

两条命令的结果都是握手失败，返回了 handshake failure 或 connection reset。紧接着再测 TLS 1.2 和 TLS 1.3：

openssl s_client -connect 你的域名:443 -tls1_2 -brief </dev/null openssl s_client -connect 你的域名:443 -tls1_3 -brief </dev/null

这两条都正常完成了握手。也就是说，虽然服务器配置文件里可能还残留着旧协议的声明，但由于加密套件优先级和实际协商逻辑的限制，外部客户端根本没有办法用 TLS 1.0/1.1 完成一次有效连接。工具报告的是配置文本层面的偏离，而真实行为已经被其他配置约束住了。这条高危告警停在了 Evidence 级别，没有进入可利用风险的计算，SAFE 结论是站得住的。

以后遇到类似的告警，我的建议是不要看配置文件的“写法”，直接看实际握手结果。只要外面的人没法用旧协议连上来，这个高危就只是历史残留，不是真实漏洞。

2.2 告警二：SMTP 25 端口明文传输和 VRFY，受业务模式和访问控制限制

第二条高危告警来自邮件服务这个大板块。SkillSpector 同时给了两个提示：一个是 25 端口允许明文 SMTP 传输，另一个是 VRFY 命令可能存在邮箱用户枚举风险。这两个提示在邮件服务的检测里非常常见，看到时容易让人觉得邮件服务器已经裸奔了。

我针对第一条提示先做了检查。25 端口是 SMTP 的默认端口，只要这台服务器确实承担邮件收件功能，就一定要对外开放。问题只在于这个会话过程是否强制加密。用 postconf 查看配置后发现，当前设置是允许 STARTTLS 但不强制。也就是说，在极端情况下，外部客户端确实可以跟我的服务器建立一条明文 SMTP 会话。但实际业务里，所有正常发信客户端都走 587 端口提交，并且该端口已经配置为强制 STARTTLS；25 端口只用于接收来自其他邮件服务器的外发信件，而主流邮件服务商之间基本都会协商 STARTTLS。从真实威胁角度来说，这台机器既没有流量规模，也不承载敏感邮件，明文会话能带来的链路嗅探风险非常有限。

对于 VRFY 命令，我更直接地做了外网视角验证。用 nc 连接 25 端口后手动输入命令，得到的结果是：

220 test.example.com ESMTP Postfix VRFY test 550 5.1.1 <test>: Recipient address rejected: User unknown EXPN root 502 5.5.2 Error: command not recognized

VRFY 返回 550 表示外部用户无法通过这个命令枚举邮箱，EXPN 也已经被禁用。这说明工具报的“VRFY 可用”大概率是抓到了配置项层面的声明，而真实访问控制层已经把外部请求拦住了。评级引擎会认定这条告警没有外部可利用路径，自然也不会把它计入风险评分。通过这个实例可以看到，邮件相关的告警往往需要结合“业务必要性”和“访问控制是否生效”来综合判断，不能只看列表里的 High 字样。

2.3 告警三：证书链中存在 SHA-1 签名，实际信任链不受影响

第三条高危告警是“证书链中存在 SHA-1 签名证书”。这名字听起来很吓人，因为 SHA-1 在证书体系里已经被公认为不安全，绝大多数客户端都会拒绝信任使用了 SHA-1 签名的证书。但是我的服务器实际使用的证书是 Let’s Encrypt 签发的，叶子证书和中间证书都是 SHA-256。那么问题出在哪？

我把证书链拉出来看了一遍：

openssl s_client -connect 你的域名:443 -showcerts </dev/null | grep -i "Certificate Signature Algorithm"

输出里确实出现了一个 SHA-1 的签名算法项，但仔细对照后发现，这个 SHA-1 来自一个已经不再被信任的备用交叉证书，或者说来自证书链中某个陈旧的附属条目。现代客户端在验证证书链时，会优先选择自己信任的根证书路径，遇到已经过期或已失去信任的旧路径时会自动跳过，改走 ISRG Root X1 这一条新链。所以实际访问网站的用户和浏览器都不会受到影响。

这个场景尤其值得注意，因为很多证书相关的高危告警并不是“你的证书有问题”，而是“你的证书链里混入了一些跟信任锚不再相关的历史产物”。用外部工具交叉验证一下，或者去 SSL Labs 这类平台跑一遍证书链分析，基本就能确认真实情况。当你确认现代客户端不会选择那条包含 SHA-1 的链时，这条高危告警对 SAFE 结论就不构成威胁。

3. 还有哪些“高危告警但 SAFE”的常见坑

除了上面三条具体案例，这类“高危告警但最终 SAFE”的现象还有几种常见背景，几乎在每次大规模扫描里都会遇到。把这些场景提前想明白，以后再看到类似结果就不会慌了。

3.1 端口看似开放，实际网关层已限制访问来源

扫描器探测端口时，得到的结果取决于它所在的位置和探测源。有些平台为了减少误报，会从多个检测源发起扫描，然后再合并结果。如果你的服务器在防火墙上做了来源 IP 限制，比如 SSH 管理端口只允许办公网 IP 访问，那么一部分检测源可能落在允许范围内，端口就会显示为 open；另一部分不在范围内的检测源则会看到连接超时。平台合并结果时，有可能保留一条“端口开放”的告警，但评级引擎在计算可达性时会把它标记成“受限开放”。从外部攻击者的视角来看，如果他的来源 IP 不在白名单里，这个端口就是不可达的，评分自然不会被拉低。

不过这里一定要分清一个细节：TCP 端口显示 open，通常意味着 TCP 握手已经完成或者至少收到了 SYN-ACK，这说明至少对扫描源来说服务是可触达的。如果你发现实际业务要求这个端口只对特定来源开放，但扫描源又能扫到 open，就要去检查是不是防火墙规则只覆盖了某几个 IP，而现有规则本身写漏了，而不是简单认为“端口开着也打不进来”就放过去。

3.2 告警挂在内网组件上，不参与公网暴露面评分

有些平台会把一组相关资产合并成一个资产组，然后统一扫描。扫描结果里可能会发现内网管理后台有高危漏洞、数据库端口弱口令、测试环境存在未授权访问等。这类告警单独看，严重程度拉满。但如果这个资产组里没有对应的公网映射，例如那些内网组件根本没有暴露到公网，那么评级引擎在计算外部风险时就会把它们排除在外，因为攻击者首先要能找到一个公网入口才能进入内网。工具会给出一条“内网风险”的记录，但不会因此把公网综合评级打成非 SAFE。

这种设计本身没问题，但读报告的人需要知道自己看的是哪种视图。如果想看真正的全量风险，应该切换成资产视角，而不是只盯着公网评级。很多团队误以为 SAFE 就是所有资产都安全，结果把内网高危置之不理，这是对报告体系理解不足造成的，不能怪工具。

3.3 合规类告警和可利用风险被放在两个维度

还有一类高危告警跟攻击路径几乎没有关系。密码复杂度、日志审计缺失、账号未启用多因素认证、备份未加密，这些在等保或合规基线里都是硬性要求，一旦不满足，工具就会生成 High 级别告警。但风险评估模型的核心目标是回答“资产现在能不能被打穿”，而不是“资产是不是符合全部合规条款”。所以合规类告警通常会被归入独立的合规模块，单独计分，不进入最终的风险评级权重。

这并不是说这类告警不重要。恰恰相反，它们往往是中长期安全建设的主要方向。只是在解读“为什么 SAFE”这个问题时，要知道两类告警属于不同的评价维度，不能混在一起算账。

3.4 服务版本指纹不准确，导致高危假象

版本识别型的高危告警也要小心。工具一般通过响应头里的 Server 字段、页面特征或者 TLS 指纹来推断目标运行的服务版本，一旦发现版本过旧，就关联 CVE 并标记高危。但这种指纹识别非常容易被反向代理、负载均衡或者自定义响应头干扰。举例来说，前端 Nginx 响应头里写着老版本号，真实后端的程序已经打了补丁，或者前面还有一层 Web 应用防火墙在拦截攻击载荷，那么“版本旧”这件事本身并不能直接证明漏洞可利用。

遇到版本类高危告警，我建议先做两件事：第一，直接看真实响应头和服务端配置，确认版本指纹有没有被伪装或代理改写；第二，针对 CVE 描述的利用条件逐个验证，看前后是否有补偿缓解。如果只是指纹层面的“看起来像旧版本”，评级模型也会给它打上低置信度标记，SAFE 结论同样会出现。

4. 正确解读 SAFE：我的复核清单和实操建议

讲了这么多，最核心的问题是：当你看到“高危告警 + 显示 SAFE”时，到底应该怎么处理。下面这套流程是我自己踩过几次坑以后固定下来的复核清单，从简单到复杂排好顺序，你可以直接抄作业。

4.1 看到高危告警先别慌，按五步走

第一步，看验证级别。如果工具明确标注为 Evidence 或者 Advisory，不要直接按“确认可利用”去处理，先把它当成一个待核实线索。

第二步，看告警详情里的“是否计入评级”字段。很多工具会明确标注这条告警是 Affects Risk 还是 Excluded，或者是否被条件性豁免。如果它已经被排除在评分模型之外，SAFE 结论自然成立。

第三步，对 Affects Risk 的告警做可达性验证。端口能不能从外网连、协议能不能实际协商、VRFY 这类敏感命令是不是真的对外有效，都用命令实测一遍，不要只看扫描结果。

第四步，用第二个独立工具交叉验证。相同结论才有更高可信度。比如 TLS 的问题，可以再拿 SSL Labs 或者浏览器开发者工具的安全面板看一眼；端口问题换用不同的扫描源对比结果。

第五步，把每条高危告警的复核结论记录在案，写清楚验证日期、验证工具、裁定结果、负责人。下次扫描或者评级变化时，能直接追溯这条告警的来龙去脉。

4.2 用交叉验证工具降低单一扫描器的误报

任何扫描器都只能覆盖有限的检测维度，单一来源的结论都不应该直接当成最终答案。推荐至少准备以下几种交叉工具：

交叉验证的核心原则是：不要用制造告警的那个工具来验证自己。独立第三方视角能把误报率和幸存者偏差压到最低。

4.3 什么情况下高危告警真的会推翻 SAFE

当然，SAFE 也不是免死金牌。如果复核过程中出现下面几种情况，就要立刻把这条告警升级，不能继续停留在“可能只是误报”的幻想里：

• 告警验证级别是 Confirmed 或 Exploited，说明工具已经复现了可利用条件；
• 端口公网可达，并且对应服务存在公开利用链，没有 WAF、ACL、补丁等缓解措施；
• 证书私钥疑似泄露或者证书已经被吊销，这类属于直接严重事故；
• 邮件系统被证实可匿名中继转发，这个对域名信誉影响非常大；
• 多个独立工具都得出同一个高危结论时，不要再纠结单个工具是否误报。

我自己的排序习惯是：先处理“可利用 + 公网可达 + 无缓解”的高危，再处理合规类高危。虽然 SAFE 评级不会因为合规类告警发生变化，但它确实是未来审计和等保评级的扣分点，早晚要还债。

另外还有一条非常想提醒的实操禁忌：不要因为看到 SAFE，就把所有高危告警批量加入白名单或者直接标记为已忽略。做白名单前必须有明确的复核记录作为支持材料，否则下次扫描时这个真相就会被掩盖。SAFE 是一个动态结论，一条配置变化、一次证书更换、一个新端口开放，都可能让评分瞬间跌出安全区间。保持告警列表的完整，比维持一个永远绿色的评级重要得多。

按照上面这套流程走下来，你基本能区分两种完全不同的情况：一种是工具产出了“配置级的高危但真实风险很低”，另一种是工具确实发现问题但评分模型迟滞或者配置不当。前者可以放心继续观察，后者则需要立即处理。看到“高危告警 + SAFE”组合时，多花二十分钟做一轮复核，心里会比单纯盯着那个绿色标签踏实得多。