发现业务被攻击后，第一时间要做的不是分析入侵原因，而是立刻切断攻击路径并保留现场证据。先把业务影响范围控制住，再谈追溯和修复，顺序错了,损失会成倍扩大。
第一步：判断攻击类型并启动分级响应
先看现象，再定级，别盲目操作
接到告警或者发现业务异常时，先花30秒看清现象，这决定了后续所有动作的优先级，行业共识认为，攻击响应的黄金窗口在前5分钟。
常见的异常现象对应着不同的攻击类型：
- 服务器CPU和带宽跑满，大概率是DDoS流量攻击，核心诉求是快速引流和封禁来源IP
- 数据库出现大量慢查询或锁表，大概率是SQL注入或拖库行为，需要立即断掉应用层连接
- 首页被篡改或页面跳转赌场站点，大概率是Webshell上传或后台弱口令被爆破，先撤下页面并锁定文件权限
- 业务数据被加密并出现勒索提示，大概率是勒索病毒，立即隔离主机，不要急着付赎金
- 账号大量异地登录，大概率是撞库攻击，先冻结异常账号并开启强制改密
分级响应的具体动作
根据攻击影响程度,把响应分成三个级别：
| 级别 | 影响范围 | 第一动作 | 响应时限 |
|---|---|---|---|
| 一级 | 核心业务瘫痪或数据泄露 | 立即断网隔离 | 1分钟内 |
| 二级 | 部分功能异常但数据安全 | 切断异常模块入口 | 5分钟内 |
| 三级 | 边缘系统被探测或低危告警 | 保留现场，持续监控 | 30分钟内 |
一级响应的核心动作是断网，拔掉服务器网线或者直接在云控制台做安全组隔离，这两件事必须同时做，先通过安全组把入方向规则改成全部拒绝，再在服务器内部执行iptables -F清空防火墙规则,防止攻击者已经植入的持久化进程继续外连。
第二步：备份证据与快照，锁定攻击痕迹
为什么先备份而不是先清理
很多运维人员遇到攻击第一反应是杀掉恶意进程、删除木马文件，这恰恰是最大的错误，攻击者的工具、后门文件、临时目录里的payload,都是溯源定位攻击来源的关键证据。
在断网和隔离动作完成后,立刻执行以下备份操作：
- 云服务器先打磁盘快照，在控制台找到云盘管理，点击创建快照，确保内存数据也能被记录
- 使用
cp -a或tar命令，把/var/log、/etc/passwd、/etc/shadow、web目录下的访问日志全部打包保存 - 导出数据库binlog日志，这能还原攻击者执行过的所有SQL语句
- 对运行中的进程执行
ps -ef和netstat -tunlp，保存当前进程与端口连接状态截图
溯源信息从哪几个维度找
拿到备份后，开始系统性地收集攻击线索,重点排查以下位置：
系统层面：检查/etc/crontab和/var/spool/cron/里的计划任务，攻击者常在这里写入反弹shell，用ls -lt按时间排序查看最近被修改的文件，重点关注/tmp、/var/tmp、/dev/shm目录。
web层面：查看nginx或apache的access日志，用grep -i "eval\|base64_decode\|shell_exec"匹配异常请求，关注兄弟域名和子目录里新增的php、jsp、aspx文件。
用户层面：执行last查看登录记录，用awk -F: '$3==0{print $1}' /etc/passwd查找uid为0的隐藏账号，检查~/.ssh/authorized_keys有没有陌生的公钥,这是持久化后门的常见手法。
第三步：遏制扩散与业务恢复的双线操作
止血动作的优先级排序
证据保留完毕后，才开始清理和恢复，这时候的思路不是一口气把所有恶意文件删干净，而是先让业务跑起来,再慢慢完善加固。
按以下优先级推进：
- 修改所有密码，包括服务器root密码、数据库密码、后台管理员密码，要求长度16位以上且带特殊字符
- 封禁攻击源IP，从日志中提取出现频次最高的IP段，在防火墙层加入黑名单
- 移除恶意文件，仅删除确认无误的Webshell和恶意脚本，不确定的先移动到隔离目录
- 恢复业务入口，先恢复静态页面和只读功能，等确认无异常后再开放写入功能
这个阶段最容易犯的错误是追求完美清理再恢复，副作用是业务停滞时间过长，实际操作中应该采用先恢复、再加固的策略,业务恢复优先级高于完全清理优先级。
针对不同攻击类型的恢复路径
DDoS攻击恢复：接入高防IP，把DNS解析切到高防节点，源站IP改为内网地址或换新公网IP，如果自身有多个线路,把流量分散到不同机房。
数据被加密的恢复：别急着付赎金，先检查是否有离线备份或云上的异地快照，如果使用云数据库，直接使用按时间点恢复功能,恢复到攻击发生前2小时的实例。
web篡改恢复：从备份中恢复被篡改文件，同时检查web容器配置里有没有异常的路由规则或重定向配置，恢复完成后把目录权限调整为只读,仅在更新时临时开放写权限。
第四步：复盘加固与防御体系升级
用入侵路径反推防守缺口
业务恢复正常访问后，攻击复盘才算安全工作真正的开始，回答一个核心问题：攻击者到底是怎么进来的？
对前期收集的证据做完整分析,常见的入口路径有：
- 弱口令爆破：检查密码策略，登录失败锁定阈值调到5次以内
- 未打补丁的已知漏洞：对照漏洞库逐项排查，比如中间件版本、开发框架版本是否在危险版本列表
- 第三方组件风险：检查前端依赖库和开源组件版本，锁漏洞库比对是否有新披露的CVE
- 钓鱼邮件引入的恶意宏：排查员工终端，加装EDR并开启邮件网关的附件沙箱检测
加固落地的具体步骤清单
完成攻击路径还原后,立刻执行以下加固动作：
- 修改SSH默认端口，禁用root账号远程登录，改用密钥认证方式
- 在云安全组配置中，仅放行业务所需端口，数据库和redis不暴露公网
- 开启云平台自带的WAF和主机安全服务，至少在防护模式下运行观察一周
- 配置日志审计系统，将各类日志同步到独立存储桶或日志服务，留存周期不少于180天
- 建立应急演练机制，定期模拟攻击场景验证响应流程
这里要说一个知乎高热度的问题： “买什么安全设备才能一劳永逸” ，业内专家的回答比较一致：安全设备只是辅助验证手段,核心防御能力在于日常运维规范和敏感数据加密策略。
服务器被入侵排查步骤的常用命令参考
为了方便后续操作,把排查阶段最常用的命令整理成速查表：
| 排查目标 | 命令 | 预期结果 |
|---|---|---|
| 当前网络连接 | netstat -antlp |
发现非业务端口的外联IP |
| 监听端口进程 | lsof -i :端口号 |
定位对应进程PID |
| 系统登录记录 | lastb |
大量失败的登录尝试记录 |
| 最近修改文件 | find / -mtime -3 -type f |
名称可疑的新文件 |
| 异常计划任务 | crontab -l 和 cat /etc/crontab |
非计划内的任务条目 |
| 隐藏启动项 | chkconfig --list 或 systemctl list-unit-files |
非自身业务的开机启动项 |
| 权限异常账号 | awk -F: '$3==0||$4==0{print $1}' /etc/passwd |
非root但uid为0的账号 |
关于应急响应周期的预期管理
从发现攻击到业务恢复,不同攻击类型的时间周期差异很大：
- 单点web入侵：最快2小时内完成初步恢复，1天内完成加固
- 勒索病毒侵入：若备份完整，4小时左右可恢复数据，后续加固需2-3天
- 大型DDoS流量攻击：接入高防后分钟级恢复，但攻击可能持续数天，需要持续关注流量态势
- 数据被拖走但无加密：恢复业务用时较短，但合规上报和用户告知流程需要额外处理
应急响应的核心目标始终是业务连续性和数据完整性，不是抓住攻击者或者找到全部攻击证据，先断网，再备份，后清除，最后加固，这个顺序不能乱，每一次应急响应，都是对防御体系的检验和补强，把攻击链路用文档沉淀下来,在下一次防护中堵住同样的入口。
Q&A：业务被攻击后常见问题
业务被攻击后应该先报警还是先自己处理
只要不涉及数据泄露或大规模用户信息丢失，可以先自行处置控制住攻击影响，处置过程中保留日志和证据，事后补齐报案材料，涉及用户隐私数据泄露的情况，需要同步上报属地网信部门和公安机关,同时联系律师评估信息披露义务。
没有专门的安全人员，小公司业务被攻击怎么处理
中小团队建议优先采购云平台提供的托管安全服务，部分云厂商按年收费，包含基础的不限流量防护和日志审计，攻击发生时由平台侧的安全团队介入支撑，企业侧只需配合提供账号授权和业务说明，日常只需要做好数据备份义务,就能把攻击造成的损失降到很低的水平。
应急响应处理的报价一般是多少
安全服务商的应急响应报价，按照单次事件处理收费，主要看攻击类型和服务器数量，网页篡改类处理大约在数千元一次，勒索病毒处理和数据恢复服务价格相对更高,跨地域的驻场局服务会在基础费用上额外加收差旅成本。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/784464.html
