凌晨两点，运维小李收到告警邮件——公司官网后台登录失败次数激增，同一IP在30秒内尝试了47次密码。他没慌，打开桌面上的《安全事件响应检查表》，照着步骤一条条核对：确认是否真实攻击、隔离受影响主机、保留日志、通知负责人……20分钟后，攻击源被封禁，系统恢复正常。
这不是演习，是日常
很多团队把“安全事件响应”想成大厂才配有的流程，其实中小公司更需要它——没有专职安全部门，反而更依赖清晰、可执行的动作指引。一套靠谱的响应流程，不是为了写进PPT，而是让任何人值班时看到异常能立刻知道下一步该点哪里、查什么、通知谁。
五步走，不卡壳
1. 识别与确认
别急着删日志或重启服务。先问三个问题：这个告警有没有误报可能？有没有其他系统同步异常（比如数据库连接超时、防火墙拦截日志）？有没有员工反馈无法访问？用命令快速验证：
tail -n 50 /var/log/auth.log | grep 'Failed password'2. 隔离与遏制
控制影响面比“抓黑客”更紧迫。常见操作包括：在防火墙临时封禁可疑IP、将中招服务器从负载均衡摘除、禁用被撞库的测试账号。注意：不要关机！保留内存和进程状态，方便后续分析。
3. 分析与溯源
重点看三类日志：Web访问日志（/var/log/nginx/access.log）、系统认证日志（/var/log/auth.log）、应用错误日志。时间线要对齐，比如攻击IP首次出现时间，是否紧跟着某次异常登录成功？有没有上传可疑文件的记录？
grep '192.168.3.222' /var/log/nginx/access.log | awk '{print $4,$9}' | head -104. 清除与恢复
删掉Web目录下的PHP木马文件、重置被泄露账号密码、更新SSH密钥。恢复前务必验证补丁有效性——比如改完密码后，用新凭据手动登录一次，别只改配置就上线。
5. 复盘与加固
不是写报告，是改动作。例如这次是弱口令导致的爆破，那就批量检查所有管理后台密码强度，并在堡垒机上启用双因素；如果是旧版本CMS漏洞，就排期升级，同时加一道WAF规则拦截已知攻击特征。
一张纸就够用
不必追求几十页SOP。把核心步骤打印出来贴在工位旁，包含：关键日志路径、常用排查命令、紧急联系人电话（含备份联系人）、封禁IP的防火墙操作路径。有同事轮休？留个便签：“今天封了10.23.44.191，原因：扫描phpmyadmin，默认口令爆破，已重置root密码”。信息够用，不绕弯，就是好流程。