一、事件背景：3.29老师分享apifox出现问题，让我们自查
1. 事件起因
3 月 29 日，从老师分享内容得知Apifox（API 调试工具）遭恶意攻击，攻击者可能植入恶意代码窃取本地敏感信息（如 API 密钥、云服务器凭证）。作为刚在 3 月下载该桌面工具的用户，我立即意识到风险，启动全面自查。
2. 中招确认
通过老师分享的b站博主“枫枫知道”的自查指南，我发现我确实中招了
3. 应急处理全流程
（1）彻底清理 Apifox
-
卸载程序：Windows→控制面板→程序和功能→右键卸载 Apifox
-
删除所有存档：
- Windows：删除
%AppData%\Apifox、%LocalAppData%\Apifox、%ProgramFiles%\Apifox；
- Windows：删除
（2）Git 仓库安全检查
-
进入本地所有 Git 仓库目录，执行
git remote -v：- 确认链接协议为HTTP（而非 SSH） ，避免密钥泄露风险；
-
登录 GitHub：进入「Settings→SSH and GPG keys」→删除所有旧密钥对（无影响，因仓库用 HTTP 链接）；
（3）云服务器安全核查
-
阿里云 / 华为云：
- 进入 ECS 实例→安全组→入站规则；
- 确认仅允许本地动态 IP访问 SSH 端口（22）（之前配置的
curl -4 ip.sb规则生效）； - 检查实例登录日志：无异常登录记录；
-
XShell 验证：用密码登录服务器（无密钥配置），连接正常且无异常操作。
（4）其他安全检查
- 本地防火墙：启用 Windows Defender Firewall，限制陌生端口访问；
- 密码修改：修改 GitHub、云服务器的登录密码（启用多因素认证 MFA）。
二、学到的网络安全新知识
1. SSH 协议的本质
【我之前一直把SSH协议和通过密钥加密这个混杂了(((φ(◎ロ◎;)φ)))】
SSH 是基于非对称加密的安全传输协议，核心原理：
- 密钥对生成：客户端生成「私钥（本地保管）+ 公钥（存服务器）」；
- 密钥交换：连接时用 Diffie-Hellman 算法协商会话密钥，确保数据加密传输；
- 身份验证：服务器用公钥加密挑战，客户端用私钥解密响应（无明文密码传输）。
2. 登录方式对比（密码 vs 密钥）
【虽然使用密码不好，可是正因为这样，这次反而救了我一下/(ㄒoㄒ)/~~】
| 对比维度 | 密码登录 | 密钥登录 |
|---|---|---|
| 安全性 | 中等（易被撞库、弱口令） | 高（无明文传输，私钥唯一） |
| 便利性 | 高（无需管理密钥） | 中等（需备份 / 轮换密钥） |
| 风险点 | 密码泄露、暴力破解 | 私钥丢失、权限设置不当 |
| 适用场景 | 临时测试、低风险环境 | 生产环境、长期稳定连接 |
3. 安全防护实践
【我之前设定的这个动态ip还是有点作用，虽然别人可能并没有攻击我，但是网络安全还是很重要的】
- 动态 IP 安全组：限制 SSH 仅允许本地动态 IP 访问，减少暴露面（即使 IP 变化，需每周更新安全组）；
三、教训与反思
1. 工具选择的安全原则
- 避免 “工具依赖” ：Apifox 虽便捷，但安全审计不足，优先选择 Postman、Swagger 等成熟工具；
2. 应急响应的核心步骤
- 隔离：发现风险后立即卸载可疑工具、断开网络；
- 备份：重要数据（如 Git 仓库、云服务器配置）定期备份（本地 + 云端）；
- 上报：若发现敏感信息泄露，及时上报 GitHub、云服务商；
- 修复：修改所有相关密码、轮换密钥、更新安全组规则。
3. 敏感信息管理红线
- 不存储密码在工具中：Apifox 若存储 API 密钥 / 云凭证，需立即修改；
- 启用 MFA：GitHub、云服务器、邮箱均开启多因素认证；
- 动态 IP 更新：每周用
curl -4 ip.sb更新云服务器安全组的允许 IP。
总结
这次事件让我深刻体会到：开发者的网络安全不是 “事后补救”，而是 “事前预防 + 定期自查” 。即使工具看似便捷，也需保持警惕 —— 毕竟云服务器、Git 仓库的安全，直接关系到个人 / 项目的核心资产。
碎碎念：虽然这次自查我发现可能对我没有什么影响，但凡是就怕万一，而且真的的亏我不是很了解这些密钥什么的，之前可能为了省事没有创建，这次反而没有收到影响，虽然运气不好遇上这种事情，但是万幸没有什么损失。
