网站恶意代码检测 - 怎样建立持续监测记录，时间人手有限时先做什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /14878ebc6d0e.html
📄
网站恶意代码检测 - 怎样建立持续监测记录，时间人手有限时先做什么
建立持续监测记录的核心，不是每天全站扫描一遍，而是固定一条可复查的证据链：谁在什么时间、用什么方式、检查了哪些页面或文件、看到什么结果、之后改了什么。人手有限时，先把首页、近期改动过的页面、上传目录和外部脚本引用这四类对象纳入记录，再按周或按次补充，而不是追求一次覆盖全站。
先确定记录什么，而不是先找工具
恶意代码的表现形式不同，记录字段也不同。常见需要留痕的对象包括：页面源码中出现的陌生外链脚本、<iframe>、混淆代码；服务器上被修改的文件路径与修改时间；搜索引擎结果里出现的异常标题或跳转；访问日志中反复请求的可疑参数。记录时至少写清四项：检查时间、检查对象（URL或文件路径）、观察到的现象、判断依据。
判断依据要能复核。例如“页面底部多了一段指向陌生域名的脚本”，比“感觉有问题”更有用；“该脚本在本地源码和线上源码中同时存在，且不在版本库记录里”比“可能是被注入”更接近可验证结论。注意区分“可能原因”和“已经定位的原因”：看到陌生脚本，可能是模板自带、第三方统计代码、CDN注入，也可能是被篡改，不能一发现就断言是攻击。
按观察、判断、处理、复查四步排优先级
时间和人手有限时，建议按下面的顺序安排最先处理的工作：
- 观察：先看最容易被利用的入口。首页、登录页、搜索页、上传目录、
robots.txt、.htaccess或Nginx配置，以及最近一周有改动的文件。 - 判断：把观察到的现象和基线对比。基线可以是版本库记录、上一次备份、已知的第三方脚本清单。没有基线时，先建立一次当前快照作为起点。
- 处理：确认是恶意代码后，先隔离而不是直接删除全部可疑文件。保留样本、记录路径和时间，再清理或替换。若无法确认，先下线受影响页面或加访问限制。
- 复查：处理完不是结束。隔24小时、72小时各复查一次同一对象，看是否重新出现。重新出现说明入口未封堵，需要回到观察步骤查上传接口、弱口令、插件漏洞或权限配置。
这个顺序的适用条件是：站点规模不大、没有专职安全人员、无法做全量实时监控。若站点有交易或大量用户数据，应把隔离和取证提前，并考虑专业安全服务介入。
用一张最小记录表维持连续性
持续监测的关键是“连续”，不是“详细”。可以用表格或工单系统维护以下字段：日期、检查人、检查对象、检查方式、现象、判断、处理动作、复查日期、复查结果。每次只填实际检查过的对象，不补写没做过的项目。
- 检查方式写具体：手工查看源码、对比版本库、查看访问日志、使用本地扫描脚本、查看搜索引擎结果。
- 现象写可复核内容：文件路径、URL、出现位置、时间点。
- 判断写依据和不确定处：已确认、疑似、待观察分开标注。
- 复查写结果：仍存在、已消失、再次出现、无法访问。
假设某站发现首页被插入一段陌生脚本，记录中应写明：检查时间、首页URL、脚本所在行、脚本指向的域名、是否在版本库中、处理方式（删除或替换）、复查时间与结果。这样下次再出现类似现象时，可以直接比对，而不是从头猜。
复查时重点看什么
复查不是再扫一遍全站，而是回到上次处理过的对象，并检查三个容易反复的位置：被修改文件的同目录其他文件、上传目录中新出现的可执行文件、外部脚本引用是否被再次加入。若条件允许，对比文件哈希或修改时间，比肉眼查看更可靠。
不同来源的信息口径不同：站内日志、搜索引擎结果、第三方估算流量反映的不是同一件事，不能用一个指标直接推断恶意代码是否清除。判断是否清除，应以文件内容、访问行为和复查结果为准。搜索引擎结果中的异常提示可能滞后，也可能来自其他原因，需要单独核实。
下一步可以做的，是选一个当前最可能被利用的入口，按上面的字段建立第一条记录，并设定下一次复查时间。记录一旦开始，就按同一格式延续，不要每次换一套字段。
