先恢复可用性，再保留证据，最后复盘形成手册，整个过程中把每一步操作、时间点、结论都记录成文档。很多团队在被攻击后第一时间选择重装系统或直接恢复备份，这其实跳过了最重要的取证和复盘环节，根据近年来应急响应的行业共识，大多数被攻破的企业都因为缺少可复用的处置手册，导致同样的问题在数月后再次发生。
服务器被入侵怎么办：先做这三件事再谈恢复
如果你现在正盯着屏幕上的异常告警，先别急着敲命令，请按以下顺序执行，这个顺序来自多次应急响应实战教训，能帮你最大限度保留线索，同时控制损失。
第一件事：物理或逻辑隔离而不是断网
直接拔网线会让攻击者察觉，从而来不及追查他的入侵路径，正确做法是：
- 在云控制台为受害服务器创建安全组,只允许你的办公网IP访问22和3389端口
- 有条件的话,直接开启防火墙的“丢包”策略，而不是“拒绝”策略，让攻击者误以为只是网络抖动
- 如果是物理机,将服务器从业务交换机上断开，接入到一个独立的取证交换机上
第二件事：完整保留内存和磁盘证据
很多人不知道，内存里的进程信息比磁盘上的日志更有价值，攻击者的恶意工具往往只存在于内存中，重启后就会消失，你可以使用以下命令：| 证据类型 | 操作命令 | 保存位置 |
|---|---|---|
| 内存镜像 | dd if=/dev/mem of=/evidence/mem.img |
外置存储 |
| 进程快照 | ps aux > /evidence/ps_$(date).txt |
外置存储 |
| 网络连接 | netstat -antlp > /evidence/net_$(date).txt |
外置存储 |
| 系统日志 | cp -r /var/log /evidence/log_backup |
外置存储 |
特别注意：保存位置一定不能写在被攻击服务器的本地磁盘上，因为攻击者可能设置了定时清理任务，你的证据会跟着一起消失。
第三件事：判断攻击者当前是否还留在系统内
如果上面两步操作过程中，你发现系统响应异常缓慢，或者文件修改时间在不停变化，说明攻击者正在实时操作，这时候应该果断切断所有外联，并在后续排查中格外小心。
被攻击后如何应对：把散落的操作固化成可复用手册 应急响应只是治标，形成手册才是治本，所谓手册，不是写一篇事件总结报告扔进网盘吃灰，而是要让团队中任何一个人在下一次遭遇攻击时，都能按图索骥地执行处置流程。
手册必须包含的四张清单
一份真正能用的安全事件响应手册，至少要包含以下几个部分：
- 资产清单：标注所有业务系统的IP、域名、负责人、备份位置，避免攻击时连自己有哪些系统都数不清楚
- 联系清单：包括云服务商技术支持电话、域名注册商客服、备案服务商、以及公司内部决策人的顺序联系方式
- 工具清单：预设好下载链接或离线安装包，建议优先选择开源工具，并提前校验好文件哈希值
- 操作清单：把下面第三大节的网站被挂马处理步骤浓缩成一张打印出来就能用的流程表
手册库的结构建议
考虑到不同攻击类型的差异，推荐将手册体系拆成三层：
- 第一层：通用应急手册，覆盖登录异常、系统卡顿、文件篡改等常见症状
- 第二层：专项处置指南，包括勒索病毒处置、Webshell清理、DDoS切换备案IP等具体场景
- 第三层：日常巡检手册，规定每周需要手工检查的系统状态和日志关键词
网站被挂马处理步骤：从发现到恢复的完整走查
网站被挂马是中小企业最频繁遭遇的攻击场景，这类攻击不复杂，但如果不按固定顺序处理，很容易出现“今天清完明天又挂”的死循环。排查阶段：先用时间线缩小范围
打开网站根目录，按最近修改时间倒序排序，重点找最近7天内被修改过的文件，常见的藏马路径包括：
/tmp/、/var/tmp/这类临时目录下的PHP文件- 图片文件夹里的伪装脚本,
logo.php.jpg .user.ini或.htaccess中隐藏的自动加载配置
清理阶段：不要只删文件，要找到注入点
行业共识认为，Webshell的清理难点不在于删马，而在于找到上传入口，常见入口排查顺序是：- 检查后台登录日志,确认是否存在暴力破解成功的记录
- 查看编辑器或者附件上传组件的版本,确认是否存在已知未修复漏洞
- 审查所有表单提交接口,观察是否有未做文件类型校验的上传点
清理后的二次确认
清理完webshell文件后，务必在网站目录下再次执行全局搜索，搜索关键词建议使用 `eval(`、`base64_decode(` 配合文件修改时间筛选，如果使用的是宝塔面板，可以直接在“文件-终端”中执行完整的扫描命令。
企业安全应急响应价格对比：自行处置还是采购服务
很多团队犹豫是否要购买应急响应服务，核心顾虑在于价格，做这份对比时，需要评估的不仅是服务费用，还有时间成本和试错成本。| 对比维度 | 自行处置 | 采购专业服务 |
|---|---|---|
| 响应时效 | 依赖个人经验，可能耗时数天 | 正规服务商承诺小时级响应 |
| 证据保留 | 容易操作不当丢失线索 | 标准取证流程，法律效力更高 |
| 漏洞修复深度 | 以清理表面症状为主 | 会追踪完整攻击链路 |
| 输出成果 | 零散的操作记录 | 完整的处置报告和改进建议 |
目前市场上单次应急响应的价格因服务商资质和攻击复杂度而异,从数千元到数万元不等，如果公司缺乏专职安全人员，建议优先采购单次应急服务，然后基于服务商输出的报告反向梳理自己的处置手册，据行业内较大比例的服务商披露，首次应急响应后40%的客户会在半年内再次求助，原因就是没有把处置过程中的发现固化到内部流程中。
手册写完只是开始：如何让手册在实战中真正被用起来
经济高效的处置手册不需要大动干戈，关键是设计一套“被动使用”的机制，让团队成员在紧急时刻自然而然想到翻手册。每月演练比季度培训有效
与其组织全员参加安全培训，不如在每月例行的维护窗口期做一次15分钟的桌面推演，操作步骤可以简化为：
- 模拟一条报警信息（通知站点图片全变成乱码”）
- 随机指定一位团队成员,要求他在5分钟内翻出手册对应章节
- 对照手册检查他能否准确说出隔离流程的三个必要条件
- 记录卡顿点,即时优化手册的检索维度
给手册加上“触发器”
好的手册不只是方案，更应该是像“作战地图”一样的存在，实战中用得顺手的团队，都会在监控告警规则里埋好触发器，比如钉钉告警通知的末尾直接附上手册对应的腾讯文档链接，这样一来，当告警触发时，处理人不需要先找手册，而是可以直接通过告警通知进入对应处置章节。
复盘时问三个问题而非老套总结
事件处置完成后，复盘会议只需要回答三个问题：
- 攻击者进来的那扇门,我们为什么没能在门锁坏掉的第一时间把它关上？
- 从发现攻击到完成隔离,中间浪费了多少时间？这个时间花在了哪个环节？
- 如果下次同样方式打进来,手册中哪一步不需要再做？哪一步需要提前准备好？
常见问题解答：服务器被入侵怎么办的补充细节
被攻击后应该报警还是找技术团队处理？
如果你所在的企业涉及用户个人信息，或者属于金融、医疗等受监管行业，建议同时联系辖区网警报案处理，技术处置和报警并不冲突，正常流程是：先自行或委托安全公司做证据固定，再带着完整的证据链和初步分析报告去报案，警方会依据这份报告决定是否立案侦查，如果只是一般的营销网站被挂马，优先找技术团队清理漏洞，同时按当地网信办要求做好报备即可。
如何判断攻击者是否已经删除了系统日志？
可以把这个问题反过来看攻击者通常会挑明显的日志文件下手，/var/log/secure`，但会忽略一些边角位置，你可以检查`/var/log/wtmp`和`/var/log/btmp`这两个文件是否还存在，以及系统账户登录记录是否完整，如果某个时间段的记录出现大面积空白，且与你发现被攻击的时间吻合，基本可以认为攻击者做了日志清理，同时反过来说明攻击者具备一定的专业背景，后续防护等级需要相应上调。
备份系统也需要纳入应急演练范围吗？
需要，很多团队在演练时忽略了备份恢复这一环，结果真实攻击发生后，才发现备份文件同样被加密或损坏，建议每季度至少做一次完整的备份恢复演练，并在手册中记录每次恢复演练消耗的时间和遇到的问题，当备份恢复的成功率稳定在较高水平后，整个应急响应的底气就完全不一样了。
结尾想强调一句话：被攻击并不可怕，可怕的是下一次依旧用同样的姿势跌倒，花一个下午时间，把你这次处置过程中的每个命令、每个判断、每次犹豫都写下来，这就是你团队的第一份安全财富。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/651204.html
