服务器被黑了怎么办？应急响应全流程实战指南

开头

想象一下这个场景：

凌晨三点，你被电话吵醒。老板在电话里吼：“网站打不开了！数据库里的数据全没了！客户都在投诉！你赶紧看看怎么回事！”

你迷迷糊糊爬起来，打开电脑，登录服务器。一看——所有文件都被加密了，桌面上留了一封勒索信，要求支付3个比特币才能解密。

你的脑子"嗡"的一声：服务器被黑了。

这时候你该怎么办？是直接重启服务器？还是赶紧删木马？还是拔网线？

很多人遇到这种情况，第一反应是慌，然后一顿乱操作——重启服务器、删可疑文件、改密码……结果把入侵痕迹全毁了，木马也没清干净，黑客第二天又进来了。

服务器被入侵后，正确的应急响应流程至关重要。 处理得好，可以快速恢复业务、保住数据、找到入侵源；处理不好，可能导致数据永久丢失、黑客反复入侵、甚至法律风险。

今天这篇文章，我就把应急响应的完整流程讲透——从发现入侵到最终恢复，每一步该做什么、不该做什么、用什么工具、看什么日志。看完这篇，下次再遇到服务器被黑，你就不会慌了。

文章很长，建议先收藏，关键时刻能救命。

一、应急响应是什么？为什么重要？

1.1 什么是应急响应？

应急响应（Incident Response，简称IR），简单说就是：安全事件发生后，采取一系列有组织、有流程的措施，来处理事件、减少损失、恢复业务、防止再次发生。

就像火灾发生后，消防员要按流程来——先报警、再疏散、再灭火、再调查起火原因、最后做防火整改。应急响应也是一样，有标准的流程和步骤。

1.2 应急响应的目标

应急响应不是简单的"删木马、改密码"，它有四个核心目标：

很多人只做到了"恢复"，没做到"根除"和"复盘"，结果黑客留的后门没清干净，过几天又被入侵了。完整的应急响应，四个目标缺一不可。

1.3 应急响应的原则

在开始具体操作之前，先记住几个重要原则：

原则一：先保护证据，再处理问题

很多人一上来就重启服务器、删文件、改配置，结果把入侵痕迹全毁了。后面想查黑客是怎么进来的、偷了什么数据、留了什么后门，全都查不到了。

正确的做法是：先做镜像和日志备份，保留证据，再进行处理。 即使要紧急遏制，也要尽量保留关键证据。

原则二：不要慌，按流程来

遇到安全事件，慌是正常的。但慌解决不了问题，反而容易出错。按流程一步一步来，比乱操作强100倍。

原则三：最小化业务影响

应急响应过程中，要尽量减少对正常业务的影响。能不重启就不重启，能不关机就不关机，能在线处理就在线处理。但如果攻击正在造成严重损失，该断网就断网，该关机就关机——业务中断是暂时的，数据丢失是永久的。

原则四：记录所有操作

应急响应过程中的每一步操作，都要记录下来：什么时间、做了什么、结果是什么。这对后续的调查、复盘、甚至法律取证都非常重要。

二、应急响应全流程：6个阶段详解

标准的应急响应流程分为6个阶段：准备 → 识别 → 遏制 → 根除 → 恢复 → 复盘。下面逐一讲解。

阶段一：准备（Preparation）

准备阶段是在安全事件发生之前做的工作。最好的应急响应，是在事件发生之前就做好准备。

需要准备的东西：

1. 应急预案

提前制定好应急响应预案，明确：

• 安全事件的分级标准（一般、较大、重大、特别重大）
• 不同级别事件的响应流程和负责人
• 应急响应团队的成员和联系方式
• 上报流程（什么时候上报、上报给谁、怎么上报）
• 业务恢复的优先级（哪些业务先恢复、哪些可以后恢复）

2. 工具准备

提前准备好应急响应工具包，存在U盘或专用服务器上：

Linux应急工具：
– netstat / ss → 查看网络连接
– ps / top / htop → 查看进程
– lsof → 查看文件打开情况
– find → 查找文件
– grep / awk / sed → 日志分析
– last / lastb → 登录记录
– history → 命令历史
– chkrootkit / rkhunter → Rootkit检测
– ClamAV → 病毒扫描
– Volatility → 内存取证（需要先做内存镜像）

Windows应急工具：
– Process Explorer / Process Hacker → 进程分析
– Autoruns → 启动项分析
– TCPView → 网络连接查看
– Wireshark → 流量分析
– 火绒剑 / PCHunter → 系统安全分析
– WinDbg → 调试分析
– Memoryze / Redline → 内存取证

3. 日志和监控

提前部署好日志和监控系统：

• 系统日志、安全日志、应用日志都要开启
• 日志要异地备份（防止黑客删日志）
• 部署入侵检测系统（IDS/IPS）、文件完整性监控（FIM）
• 设置告警规则，异常行为及时通知

4. 备份

定期备份重要数据和系统配置：

• 数据库定期备份，异地存储
• 重要文件定期备份
• 系统配置备份
• 定期测试备份是否可用（备份了但恢复不了等于没备份）

准备阶段做的越好，事件发生时就越从容。很多公司平时不做准备，出事了才手忙脚乱，损失惨重。

阶段二：识别（Identification）

识别阶段的目标是：确认是否真的发生了安全事件，是什么类型的事件，影响范围有多大。

很多时候，告警不一定是真的安全事件，可能是误报；也可能看起来是小问题，实际上是大事件。识别阶段就是要搞清楚状况。

2.1 安全事件的常见信号

安全事件发生时，通常会有一些信号。如果你发现以下情况，就要警惕了：

系统层面：

• 服务器异常卡顿、CPU/内存/带宽占用异常高
• 出现不明进程、不明服务、不明用户
• 文件被篡改、被加密、被删除
• 系统时间异常、日志被清空
• 重启后异常进程又出现（说明有持久化）

网络层面：

• 服务器主动连接陌生IP（特别是境外IP）
• 异常的大流量上传（可能是数据被窃取）
• 出现大量失败的登录尝试（暴力破解）
• 陌生的端口被打开

应用层面：

• 网站被篡改、被挂马、被跳转
• 数据库数据异常（被删除、被篡改、被导出）
• 用户投诉账号被盗、资金异常
• 后台出现不明管理员账号
• 收到勒索信、被威胁公开数据

2.2 事件分类和定级

确认是安全事件后，要对事件进行分类和定级：

常见事件类型：

• 网页篡改
• 勒索软件攻击
• 数据泄露/拖库
• WebShell植入
• 暴力破解/未授权访问
• 挖矿木马
• DDoS攻击
• 内网横向移动
• APT攻击

事件定级（参考国家标准）：

2.3 影响范围评估

搞清楚事件影响了哪些系统、哪些数据、哪些业务：

• 有几台服务器被入侵？
• 是Web服务器、数据库服务器、还是其他？
• 哪些数据可能被窃取或篡改？
• 哪些业务受到了影响？
• 攻击是否已经扩散到内网其他机器？

识别阶段的核心是：搞清楚发生了什么、影响有多大。 不要一上来就急着处理，先把状况摸清楚，才能制定正确的应对策略。

阶段三：遏制（Containment）

遏制阶段的目标是：阻止攻击继续扩散，减少损失。 这是应急响应中最紧急的阶段，需要快速行动。

3.1 遏制的优先级

遏制的时候，要按优先级来：

3.2 常见的遏制措施

根据事件类型和严重程度，选择合适的遏制措施：

措施一：网络隔离

这是最常用、最有效的遏制手段。把被入侵的服务器从网络中隔离，防止黑客继续操作、防止攻击扩散到内网其他机器。

# 方法1：物理拔网线（最彻底，但需要物理接触）
# 方法2：在交换机上关闭端口
# 方法3：在服务器上用iptables封禁所有入站和出站连接（除了应急响应的IP）
iptables -I INPUT -s 你的应急IP -j ACCEPT
iptables -I OUTPUT -d 你的应急IP -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

注意：网络隔离后，你就无法远程登录服务器了。所以在隔离之前，要确保你有其他方式可以访问服务器（比如控制台、KVM、物理访问），或者先把需要的工具和日志备份好。

措施二：关闭服务/端口

如果攻击是通过某个服务或端口进来的，可以先关闭这个服务或端口：

# 关闭SSH服务
systemctl stop sshd

# 关闭Web服务
systemctl stop nginx
systemctl stop httpd

# 用iptables关闭端口
iptables -A INPUT -p tcp –dport 22 -j DROP

措施三：禁用可疑账号

如果发现黑客创建了可疑账号，或者某个账号被盗用了，先禁用：

# 禁用用户
usermod -L username # 锁定用户密码
passwd -l username # 另一种锁定方式

# 强制用户下线
pkill -u username

措施四：阻断恶意IP

如果发现黑客正在从某个IP操作，可以在防火墙或WAF上封禁这个IP：

iptables -I INPUT -s 恶意IP -j DROP

措施五：关机/断电

这是最后的手段，只有在以下情况才考虑：

• 攻击正在造成严重的数据破坏（比如勒索软件正在加密文件）
• 攻击正在大量窃取敏感数据
• 其他遏制措施都无效

# 立即关机
shutdown -h now
# 或者直接断电（最彻底，但可能损坏文件系统）

注意：关机后，内存中的数据（包括黑客的进程、网络连接、可能的内存马）就会丢失。如果需要做内存取证，一定要在关机之前先做内存镜像。

3.3 遏制阶段的注意事项

• 不要急于重启服务器：重启会丢失内存中的证据（进程、网络连接、内存马等），如果需要取证，先做内存镜像再重启
• 不要急于删文件：可疑的木马、后门文件先保留，这是重要的证据，可以用来分析黑客的手法
• 不要急于改密码：如果黑客已经在内网了，改密码可能打草惊蛇。先遏制住，再统一改密码
• 记录所有操作：遏制阶段做了什么，都要记录下来

遏制阶段的核心是：快速阻止攻击继续扩散，同时尽量保留证据。 这两个目标有时候会冲突，需要根据具体情况权衡。如果攻击正在造成巨大损失，优先遏制；如果损失已经停止，可以先保留证据再遏制。

阶段四：根除（Eradication）

根除阶段的目标是：找到并清除所有入侵痕迹和后门，确保黑客无法再次进入系统。

这是应急响应中最关键、也最容易出问题的阶段。很多人删了几个木马文件就以为干净了，结果黑客留的其他后门没清掉，过几天又被入侵了。

根除阶段要做的事情，按顺序来：

4.1 入侵路径分析

首先要搞清楚：黑客是怎么进来的？

只有找到入侵路径，才能从根源上堵住漏洞，防止黑客再次从同一个地方进来。

常见的入侵路径排查方向：

Web层面：
– 查看Web访问日志，找异常的请求（SQL注入、文件上传、WebShell访问等）
– 检查Web目录下是否有WebShell（一句话木马、大马）
– 检查网站代码是否被篡改
– 检查是否有已知漏洞（Struts2、ThinkPHP、Log4j等）

系统层面：
– 查看SSH登录日志，找异常的登录IP和时间
– 检查是否有暴力破解成功的记录
– 检查系统是否有未打补丁的已知漏洞
– 检查是否有弱口令

数据库层面：
– 查看数据库日志，找异常的查询和操作
– 检查数据库是否有SQL注入痕迹
– 检查数据库用户权限是否合理

内网层面：
– 检查是否有横向移动的痕迹
– 检查其他服务器是否也被入侵

4.2 恶意文件和后门排查

找到入侵路径后，接下来要全面排查系统中的恶意文件和后门。

WebShell排查：

# 查找最近修改的PHP文件（可能是WebShell）
find /var/www/html -name "*.php" -mtime -7 -type f

# 查找包含危险函数的PHP文件（eval、assert、system、exec等）
grep -r "eval\\|assert\\|system\\|exec\\|shell_exec\\|passthru\\|preg_replace" /var/www/html/

# 查找一句话木马常见特征
grep -r "\\$_POST\\|\\\\$_GET\\|\\\\$_REQUEST" /var/www/html/ | grep -i "eval\\|assert\\|system"

# 用工具扫描（推荐）
# 河马WebShell查杀、ShellDetective、findWebshell等

进程排查：

# 查看所有进程
ps auxf
ps -ef

# 查看占用CPU/内存高的进程
top
htop

# 查看进程的可执行文件路径
ls -l /proc/进程ID/exe

# 查看进程打开的文件
lsof -p 进程ID

# 查看进程的网络连接
lsof -i -p 进程ID
netstat -antp | grep 进程ID

网络连接排查：

# 查看所有网络连接
netstat -antp
ss -antp

# 查看ESTABLISHED状态的连接（正在通信的）
netstat -antp | grep ESTABLISHED

# 查看监听的端口
netstat -tlnp
ss -tlnp

# 查看哪个进程在监听某个端口
lsof -i :端口号

启动项和持久化排查：

# 查看系统服务
systemctl list-units –type=service
chkconfig –list

# 查看定时任务
crontab -l
cat /etc/crontab
ls -l /etc/cron.d/
ls -l /etc/cron.daily/
ls -l /etc/cron.hourly/

# 查看启动脚本
cat /etc/rc.local
cat /etc/rc.d/rc.local
ls -l /etc/init.d/

# 查看用户登录脚本
cat ~/.bashrc
cat ~/.bash_profile
cat /etc/profile
cat /etc/profile.d/

# 查看SSH公钥（黑客可能植入了SSH公钥）
cat ~/.ssh/authorized_keys
ls -l /home/*/.ssh/

# 查看sudoers配置
cat /etc/sudoers
ls -l /etc/sudoers.d/

用户排查：

# 查看所有用户
cat /etc/passwd

# 查看可以登录的用户（shell不是/sbin/nologin的）
grep -v "/sbin/nologin" /etc/passwd

# 查看最近登录的用户
last
last -f /var/log/wtmp

# 查看登录失败的记录
lastb
cat /var/log/btmp

# 查看当前在线用户
who
w
users

文件排查：

# 查看最近7天修改过的文件
find / -mtime -7 -type f 2>/dev/null

# 查看最近1天创建的文件
find / -ctime -1 -type f 2>/dev/null

# 查看SUID文件（可能被用来提权）
find / -perm -4000 -type f 2>/dev/null

# 查看可执行文件（/tmp和/var/tmp目录下的可执行文件很可疑）
find /tmp -type f -executable
find /var/tmp -type f -executable

# 查看隐藏文件（以.开头的文件）
find / -name ".*" -type f 2>/dev/null

Rootkit检测：

# 用rkhunter检测
rkhunter –check

# 用chkrootkit检测
chkrootkit

# 检查系统命令是否被替换（对比MD5）
md5sum /bin/ls /bin/ps /usr/bin/netstat
# 和正常系统的MD5对比，如果不一样说明可能被替换了

4.3 清除恶意文件和后门

排查完之后，把所有发现的恶意文件和后门都清除掉：

• 删除WebShell、木马文件
• 结束恶意进程
• 删除恶意服务和启动项
• 删除恶意定时任务
• 删除可疑用户和SSH公钥
• 恢复被篡改的系统文件和网站代码

注意：清除的时候要小心，不要误删正常文件。对于不确定的文件，可以先隔离（移动到备份目录），观察一段时间没问题再删除。

4.4 修复漏洞

找到入侵路径后，要及时修复漏洞：

• 打系统补丁，更新有漏洞的软件
• 修复Web应用的漏洞（SQL注入、文件上传、XSS等）
• 修改弱密码，所有相关账号的密码都要改
• 关闭不必要的服务和端口
• 加固系统配置（SSH配置、防火墙规则、文件权限等）

根除阶段的核心是：找到入侵路径，清除所有后门，修复漏洞。 这三个事情都做到了，才能确保黑客无法再次进入。任何一个没做到，都可能导致再次被入侵。

阶段五：恢复（Recovery）

恢复阶段的目标是：让业务恢复正常运行，同时确保系统是安全的。

5.1 恢复的优先级

恢复的时候，按业务优先级来：

5.2 恢复方式

根据系统被破坏的程度，选择合适的恢复方式：

方式一：在线修复后恢复

如果系统被破坏得不严重，只是被植入了WebShell或少量木马，根除之后可以直接恢复业务：

• 确认所有后门都清除了
• 确认漏洞都修复了
• 重启相关服务（Web服务、数据库服务等）
• 测试业务是否正常
• 逐步放开网络访问，先内部测试，再对外提供服务

方式二：从备份恢复

如果系统被严重破坏（比如勒索软件加密了大量文件、系统文件被篡改严重），最好从备份恢复：

• 确认备份是干净的（备份是在入侵之前做的，没有被感染）
• 重装操作系统（最彻底，确保没有后门）
• 从备份恢复数据和应用
• 打所有安全补丁，修复漏洞
• 配置安全加固
• 测试业务是否正常
• 上线

注意：从备份恢复的时候，一定要确保备份是干净的。如果备份是在入侵之后做的，备份里可能已经包含了木马和后门，恢复了等于没恢复。

方式三：重建系统

如果不确定系统是否干净，最安全的方式是彻底重建：

• 全新安装操作系统
• 重新部署应用（从代码仓库重新部署，不要从被入侵的服务器上复制）
• 从干净的备份恢复数据
• 全面安全加固
• 测试后上线

5.3 恢复后的验证

业务恢复后，不要以为就完事了，还要做验证：

• 业务功能是否正常？
• 数据是否完整？有没有丢失或损坏？
• 系统性能是否正常？
• 安全设备是否正常工作？
• 监控和告警是否正常？
• 有没有异常的进程、连接、文件？

5.4 加强监控

恢复后的一段时间内，要加强监控：

• 密切关注系统日志、安全日志、应用日志
• 关注异常的登录、异常的进程、异常的网络连接
• 可以部署额外的监控和告警规则
• 定期做安全检查，确保没有再次被入侵

恢复阶段的核心是：安全地恢复业务，同时确保系统是干净的。 不要为了快速恢复业务，把带木马的系统直接上线，那样等于没恢复。

阶段六：复盘（Lessons Learned）

复盘阶段是应急响应的最后一步，也是最容易被忽略的一步。很多人业务恢复了就以为完事了，结果过了一段时间，同样的事情又发生了。

复盘的目标是： 总结这次事件的经验教训，改进安全措施，防止类似事件再次发生。

6.1 事件调查

深入调查这次事件的完整过程：

• 入侵时间：黑客是什么时候进来的？
• 入侵路径：黑客是通过什么漏洞、什么方式进来的？
• 攻击手法：黑客做了哪些操作？用了什么工具？
• 影响范围：哪些系统、哪些数据受到了影响？
• 持续时间：黑客在系统里待了多久？
• 数据泄露：有没有数据被窃取？窃取了多少？
• 后门情况：黑客留了哪些后门？

6.2 响应过程评估

评估这次应急响应的过程：

• 发现是否及时？为什么没有更早发现？
• 响应是否迅速？有没有延误？
• 遏制是否有效？有没有扩散？
• 根除是否彻底？有没有遗漏的后门？
• 恢复是否顺利？有没有遇到问题？
• 沟通是否顺畅？内部和外部的沟通有没有问题？
• 哪些地方做得好？哪些地方做得不好？

6.3 改进措施

根据调查和评估的结果，制定改进措施：

技术改进：

• 修复发现的所有漏洞
• 加强系统安全加固
• 部署/改进WAF、IDS/IPS、EDR等安全设备
• 加强日志和监控，优化告警规则
• 改进备份策略，确保备份可用
• 部署文件完整性监控、异常行为检测

流程改进：

• 更新应急预案
• 明确应急响应团队的职责和分工
• 优化上报和沟通流程
• 定期做应急演练
• 建立安全事件知识库

人员改进：

• 加强安全培训，提高全员安全意识
• 对应急响应团队做技术培训
• 必要时招聘安全专业人员

6.4 输出复盘报告

最后，输出一份正式的应急响应复盘报告，内容包括：

• 事件概述（时间、类型、影响）
• 事件时间线（从发现到恢复的完整时间线）
• 入侵路径和攻击手法分析
• 应急响应过程记录
• 损失评估
• 经验教训
• 改进措施和计划

报告要提交给管理层，并存档，作为后续安全改进的依据。

复盘阶段的核心是：从这次事件中学习，防止下次再犯同样的错误。 安全是一个持续改进的过程，每一次安全事件都是一次学习的机会。

三、常见安全事件的应急响应要点

上面讲了通用的应急响应流程，下面针对几种最常见的安全事件，讲一下具体的应对要点。

3.1 勒索软件攻击

现象： 文件被加密，文件名被修改，留下勒索信要求支付比特币解密。

应对要点：

3.2 WebShell植入

现象： 网站被篡改、被挂黑链、被跳转，或者在Web目录下发现可疑的PHP文件。

应对要点：

3.3 数据泄露/拖库

现象： 发现数据库数据被导出、用户数据在网上流传、收到威胁要公开数据。

应对要点：

3.4 挖矿木马

现象： 服务器CPU占用异常高，风扇狂转，系统卡顿，发现不明进程在大量占用CPU。

应对要点：

四、应急响应的常见错误

最后，讲一下应急响应中最常见的错误，大家一定要避免。

错误一：上来就重启服务器

很多人遇到安全事件，第一反应是重启服务器。重启确实能结束内存中的恶意进程，但也会：

• 丢失内存中的证据（进程、网络连接、内存马等）
• 可能触发黑客的自毁机制（有些木马检测到重启会删除文件或加密数据）
• 并不能清除持久化的后门（重启后木马又会起来）

正确做法： 先做内存镜像和日志备份，保留证据，再考虑重启。如果必须重启（比如系统完全卡死），也要先记录当前的进程、网络连接等信息。

错误二：只删木马，不找入侵路径

很多人应急响应就是：找到木马 → 删除木马 → 收工。结果过了几天，黑客又通过同一个漏洞进来了，又种了新的木马。

正确做法： 删木马只是第一步，更重要的是找到黑客是怎么进来的，修复那个漏洞。不修复入侵路径，删再多木马也没用。

错误三：只检查被入侵的机器，不检查内网其他机器

黑客入侵一台机器后，通常会以它为跳板，攻击内网其他机器。如果你只清理了被发现的那台机器，内网其他被入侵的机器没发现，黑客还是可以从其他机器再进来。

正确做法： 发现一台被入侵后，要对内网所有机器进行排查，检查是否有横向移动的痕迹，是否有其他机器也被入侵了。

错误四：改了一个密码，其他密码都不改

黑客入侵后，可能已经获取了多个系统的密码。如果你只改了被入侵那台机器的密码，其他机器的密码没改，黑客还是可以用获取到的密码登录其他机器。

正确做法： 全面评估黑客可能获取了哪些密码，所有相关的密码都要改，包括系统密码、数据库密码、后台密码、应用密钥等。而且要确保新密码是强密码，不同系统用不同的密码。

错误五：不做复盘，不做改进

很多人业务恢复了就以为完事了，不做复盘，不做改进。结果过了一段时间，同样的漏洞、同样的攻击方式，又被入侵了一次。

正确做法： 每次安全事件后都要做认真的复盘，总结经验教训，制定改进措施并落实。安全是一个持续改进的过程，每一次事件都是一次学习和提升的机会。

错误六：不保留证据，不记录操作

应急响应过程中，很多人不注意保留证据，也不记录自己做了什么操作。结果后面想调查入侵路径、想做法律取证、想复盘的时候，发现什么证据都没有了。

正确做法： 应急响应开始前，先做系统镜像、日志备份，保留证据。响应过程中，每一步操作都要记录（时间、操作、结果）。响应结束后，证据和记录都要存档。

结尾

服务器被入侵，是每一位安全从业者、运维同学的噩梦。
但遭遇入侵并不可怕，可怕的是事发之后手足无措，乱操作扩大损失，甚至留下二次隐患。

应急响应并不是玄乎的高阶黑科技，而是一套标准化、可落地的攻防处置方法论：准备 → 识别 → 遏制 → 根除 → 恢复 → 复盘。
严格按照六个阶段一步步处置，就算遇到高危安全事件，也可以从容应对。

不过对于网络安全人来说，最好的应急响应，就是尽量避免安全事件发生。
在攻击到来之前做好基线加固、备份策略、入侵监控、应急预案，远比出事之后慌忙救火要重要得多。

网络安全从来不是一次性的突击刷题，而是一场漫长的攻防马拉松。
不管是做SRC挖洞、渗透测试，还是日常服务器运维，只有持续积累实战经验、不断完善防护体系、复盘安全事件，才能在对抗中守住防线。

希望这份实战内容，你永远没有机会实际用上。但如果真的碰到服务器入侵、WebShell、勒索攻击这类安全事故，希望它可以成为你的参考。

我整理了一份《服务器应急响应实战手册》，专门面向安全学习者、运维工程师：
✅ 完整应急响应处置流程图
✅ Linux/Windows入侵排查全套命令
✅ WebShell特征识别与排查要点
✅ 勒索病毒攻击处置方案
✅ 数据泄露事件处置流程
✅ 应急复盘报告模板
✅ 配套Linux&Windows应急工具包

正在学网络安全、做渗透、运维服务器的同学，私信我，全部免费分享。