📍 WDQWDWQD987AAAAA:216.73.216.150
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /27b11fc51a64.html
📄

在线安全检测怎样记录改动前后的基线：先查这5项

记录改动前后的基线，核心是让每次改动都有可对照的原始快照。做法是：在改动前保存一份可复核的状态记录，改动后再采集同口径的数据，用同一套指标对比差异，并标注改了什么、何时改的、由谁操作。对时间和人手有限的团队，不必追求全量记录，只需固定几个关键检查项，按顺序执行即可。

先确定要记录哪些基线指标

基线不是越多越好，而是选那些能反映安全状态、又容易重复采集的项目。建议固定以下五类：

• 资产清单：域名、子域名、IP、开放端口、对外服务。
• 配置状态：TLS/SSL证书有效期与协议版本、HTTP安全响应头、DNS记录（含SPF、DKIM、DMARC）。
• 暴露面：对外可访问的登录页、管理后台路径、目录列表是否开启。
• 漏洞与告警：扫描器或监控平台在改动前给出的未处理告警列表。
• 变更信息：改动内容、执行时间、执行人、回滚方式。

选择标准是：同一项指标在改动前后能用相同方法、相同工具、相同时间窗口采集，否则对比会失真。

可执行清单：每项查什么、怎么查、结果说明什么

1. 查资产与端口。改动前用端口扫描或资产发现工具记录开放端口和服务版本；改动后重跑同一命令。若出现新增端口或版本变化，说明暴露面扩大，需要确认是否为预期改动。
2. 查证书与协议。记录证书颁发者、到期时间、支持的TLS版本。改动后若最低协议版本降低或证书链变化，可能是配置回退，应优先复核。
3. 查HTTP响应头。用curl -I保存改动前后的响应头，重点看Strict-Transport-Security、Content-Security-Policy、X-Frame-Options是否存在。响应头消失通常意味着安全策略被覆盖。
4. 查DNS记录。导出改动前后的解析记录并逐条对比。新增或修改的A、CNAME、TXT记录若不在变更单内，可能是未授权改动。
5. 查告警差异。把改动前后的未处理告警列表做差集。新增告警指向新引入的问题，消失的告警需确认是修复还是漏报。

执行顺序建议从资产和端口开始，因为它们是其他检查的基础。若时间只够做一项，优先做资产与端口对比，它最容易暴露非预期变化。

怎么保存和对比才算有效基线

基线要可复核，必须满足三个条件：

• 同口径：前后使用相同工具、相同参数、相同采集范围。工具版本变化时要在记录中注明。
• 带时间戳：每条记录标明采集时间，便于与变更时间对应。
• 可回溯：保存原始输出文件，而不只是结论。原始输出能重新比对，结论不能。

对比时先看差异项，再看差异是否落在变更单范围内。范围内的差异属于预期，范围外的差异需要人工确认。第三方估算流量、搜索引擎报告与站内统计口径不同，不能混用同一套数字做前后对比；安全基线对比应使用自己采集的原始数据，而不是外部估算值。

人手有限时怎样安排先后顺序

按影响面和可逆性排序：

1. 先做改动前基线采集，至少保存资产、端口、证书三项。
2. 改动后立即重采同样三项，确认没有新增暴露面。
3. 再做响应头和DNS对比，这两项通常耗时短、差异明显。
4. 最后处理告警差集，把新增告警按严重程度排入后续工作。

如果改动频繁，可把基线采集脚本化，每次改动自动保存一份带时间戳的输出。这样即使人手少，也能保证前后有据可查。判断标准是：任何一次改动后，都能回答“改前是什么、改后是什么、差异在哪、是否在预期内”这四个问题。

下一步：选一个近期要改动的服务，按上面的清单先采集一次改动前基线，保存原始输出，再执行改动并重采对比。