服务器出现异常登录、文件被改写或服务突然外联时，先别急着删文件、重启或清空日志。服务器被攻击后的日志排查与恢复，关键是保留证据、找出可能的进入路径，并在可信环境中恢复业务。日志能提供线索，但单条记录通常不足以证明攻击者从哪里进入。
先控制影响，再保全证据
- 记录发现时间、告警内容、受影响主机和已采取的操作；统一使用同一时区，避免不同日志的时间无法对齐。
- 若仍有异常访问或外联，在防火墙、负载均衡或云平台安全策略处限制相关流量。业务允许时，将主机从生产网络隔离；不要贸然关机，以免丢失内存中的线索。
- 导出并只读保存访问日志、系统日志、应用日志、身份验证记录和云平台流量记录。保留原件及文件校验值，记录导出时间与经手人；不要只留经过筛选的片段。
日志可能已轮转、被覆盖，甚至遭到篡改。若发现记录突然中断、时间异常或权限变化，应同时检查集中日志平台、云厂商审计记录和备份，而不是把缺失简单理解为“没有攻击”。
沿时间线缩小入口范围
从访问记录找可疑请求
以首次异常时间为中心，向前回看数小时至数天，具体范围取决于日志保留期和攻击持续时间。Nginx 访问日志通常能看到请求时间、路径、状态码和来源地址；错误日志可补充请求处理失败的上下文。重点关注突然增多的登录尝试、陌生管理路径、异常上传请求，以及随后出现的成功响应。状态码为 200 不等于攻击成功，仍要对照应用行为和文件变化。
如果前面有反向代理或内容分发服务，访问日志记录的来源地址可能是代理节点。只有在代理配置可信、且正确限制了可接受的转发头时，转发地址才适合用于关联；否则应结合边缘设备记录判断，不能仅凭一个地址封禁或归因。
把请求和主机变化串起来
按时间顺序对照系统登录记录、进程或服务变更记录、应用报错、文件完整性校验结果及云平台审计事件。若某个可疑请求之后紧接着出现新账户、计划任务变更、未知程序运行或配置文件修改，说明这些事件值得关联调查，但仍需核对部署记录和管理员操作，排除正常变更。发现疑似 web shell 时，不要直接访问或执行它；先复制样本并隔离分析。
确认范围，避免带病恢复
- 列出受影响主机、应用、账户、数据和外部依赖，并检查同一凭据是否被其他服务共用。
- 判断日志是否足以解释入口和后续行为。若关键日志缺失、管理员权限已被滥用或系统文件完整性无法确认，应按主机整体不可信处理。
- 检查备份时间、恢复点和备份访问权限。备份能否使用，取决于其是否早于入侵、内容是否完整，以及备份系统本身是否未被攻击者控制。
服务器被攻击后的日志排查与恢复，不应以“删掉可疑文件后继续运行”作为默认方案。若系统完整性无法验证，通常更稳妥的做法是在干净环境重建主机，再从确认可信的备份恢复业务数据和配置。
按安全顺序恢复服务
- 从可信安装介质或已验证的基础镜像部署干净环境，并安装适用的安全更新。
- 恢复经过检查的数据和必要配置；重新核对账户、远程管理入口、开放端口、服务权限及启动项。
- 从可信设备轮换管理员密码、密钥、数据库口令和应用密钥，撤销不再需要的账户与令牌。不要把旧凭据原样带回新环境。
- 先在隔离网络验证登录、关键业务、备份和监控，再逐步开放流量。恢复后持续查看认证失败、异常出站连接和文件变化，并补足集中日志与告警。
若涉及个人信息、支付数据或受监管业务，应依适用法律、合同和组织流程评估通报义务；不确定时及时联系负责安全、隐私或合规的人员。
常见问题
日志里没看到攻击请求，能否确定没有入侵？
不能。日志可能未开启、已轮转、被删除，入口也可能来自其他主机或管理渠道，应结合云审计、备份和文件变化判断。
要不要马上重启服务器？
不一定。重启可能中断业务，也可能丢失易失性线索。先评估风险并保全现有记录；若仍在造成损害，优先通过网络策略隔离。
只恢复备份是否足够？
不够。还要确认备份可信、修复进入路径、轮换凭据，并验证恢复后的系统和业务。
什么时候需要外部专业协助？
无法确认攻击范围、关键日志缺失、怀疑数据泄露或攻击者取得高权限时，应尽早寻求专业事件响应支持。
把证据保全、入口调查、可信重建和凭据轮换连成闭环，才是服务器被攻击后的日志排查与恢复的稳妥做法。
