发现异常登录，别急着断网
凌晨两点，安全监控系统弹出一条告警：某台内网服务器正在向境外IP传输大量数据。运维小李第一反应是立刻拔掉网线，但被安全负责人拦了下来。这种场景在真实事件中太常见了——面对疑似APT攻击，慌乱操作可能让关键线索消失。
什么是APT？它不像普通病毒那样张扬
APT（高级持续性威胁）更像是潜伏的间谍，不会像勒索软件那样立刻加密文件索要赎金。它通过钓鱼邮件、0day漏洞等方式悄悄进入网络，长期驻留、横向移动，慢慢收集敏感信息。你可能几个月都察觉不到它的存在，直到某天核心数据被悄然拖走。
应急响应的第一步：确认不是误报
很多告警其实是业务变更引发的。比如新上线的同步脚本频繁访问数据库，看起来像数据窃取。先查变更记录，再看日志上下文。可以快速执行一个命令查看最近活跃账户：
lastlog -t 7 # 查看过去7天有登录行为的账号隔离要讲究方式，物理断网不如策略阻断
直接断电会丢失内存中的攻击痕迹。更合理的做法是在防火墙上添加临时规则，阻止可疑主机对外通信，同时保留其运行状态用于取证。例如在iptables中添加限制：
iptables -A OUTPUT -s 192.168.10.15 -j DROP # 阻止该IP所有外发流量日志收集比杀毒更重要
这时候别忙着装杀毒软件扫描。优先保存系统日志、DNS查询记录、进程列表和网络连接状态。这些信息一旦丢失就很难恢复。可以用如下命令打包关键日志：
tar -czf incident_logs_$(date +%Y%m%d).tar.gz /var/log/auth.log /var/log/syslog ~/.bash_history分析攻击路径：从哪进来的？
翻看邮件网关日志，发现三天前有人点击了一封伪装成财务通知的附件。这个时间点和服务器首次异常外联吻合。这就是典型的APT初期渗透手法。后续调查发现，攻击者利用该员工权限提权，并通过内网弱密码横向移动到其他机器。
修复不等于结束，得让它再也回不来
重置所有相关账户密码只是基础。必须检查是否有隐藏的后门账户、计划任务或注册表启动项。还要审查同类系统的安全配置，统一加固。比如关闭不必要的远程服务，启用多因素认证。
写报告不是走形式，是为了下次更快反应
事件处理完后，把时间线、关键证据、处置动作整理成文档。重点标出耗时最长的环节——是判断慢了？还是审批流程卡住了？下次遇到类似情况就能压缩响应时间。这类文档最好用清晰标题分段，方便团队成员快速定位内容。