攻击面分析
攻击面分析是安全架构里最实在的活儿。我当年刚入行时，光知道用扫描器扫端口，结果被老工程师一句话问住：“你漏掉的业务逻辑接口，比端口多十倍”。说白了，攻击面就是系统里所有可能被攻击者利用的“点”：端口、API、文件上传、用户输入、甚至一个忘记关的调试页面。
1. 攻击面到底指什么
别绕概念。我就用一个场景说清楚：你搭了个电商平台，攻击者能碰到的所有入口加起来，就是攻击面。
- 网络层面：开放端口、服务端口、VPN入口
- 应用层面：所有REST API、GraphQL端点、WebSocket通道
- 物理层面：机房门禁、USB接口、运维终端
- 人员层面：客服系统、弱口令、钓鱼目标
这四层我在一次红蓝对抗里全撞上了。我方蓝队只守了网络层，结果红队从客服系统偷到员工账号，直接登入后台——攻击面没覆盖完整，防线再硬也没用。
关键认知：攻击面不是你“以为”暴露了多少，而是攻击者能实际触及的所有路径的集合。拿一个微服务架构来说，几十个服务各有暴露端口，外加API网关、消息队列、配置中心……随便一个口子没封，就是突破口。
2. 攻击面识别——我自己的三板斧
老老实实用工具扫一遍，那是基本功。但我总结了三个更有效的思路：
- 从文档出发：先翻架构设计文档、网络拓扑图、接口列表。我习惯拉一个Excel表，把每一条对外暴露的路径记下来。
一个小技巧：找运维要Nginx/Apache的upstream配置，那里藏着很多没写在文档里的上游服务。 - 主动扫描 + 被动嗅探：Nmap、Masscan扫端口；Burp Suite或ZAP爬应用路径。被动层用tcpdump或Wireshark抓实际流量——我遇到过很多服务只在夜间定时同步，白天扫不到。
- 威胁情报反向查：用Shodan、Censys查公司的公网资产，看有没有被人标记过的服务。有一次我查到自己公司有个Redis竟然直接暴露在公网，运维完全不知道——那是个测试环境忘了下架。
避坑指南：我曾经在一个项目里只顾着扫对外开放的域名，完全忘了第三方集成商也开了反向代理绕过了我们的WAF。后来审计发现那个代理没做任何认证，攻击者可以直通内网数据库。所以，攻击面识别一定要包含信任的第三方链路。
3. 攻击树构建——把攻击路径画出来
攻击树不是图表花哨就行。它的逻辑是：根节点是攻击目标，子节点是达成目标需要满足的条件，叶子节点是具体攻击手段。
举个例子。目标是“获取管理员权限”。
获取管理员权限（根）
├── 1.0 获取管理员密码
│ ├── 1.1 弱口令爆破（叶子）
│ ├── 1.2 从数据库泄露获取hash（叶子）
│ └── 1.3 社会工程学骗取（叶子）
│ └── 1.3.1 钓鱼邮件拿到密码（子叶子）
├── 2.0 利用未授权接口
│ ├── 2.1 直接访问/admin/api（叶子）
│ └── 2.2 绕过JWT校验（叶子）
└── 3.0 提权漏洞
├── 3.1 缓冲区溢出（叶子）
└── 3.2 内核漏洞CVE-XXXX（叶子）
这种树画出来，你就能一眼看出：哪些路径防御最弱？那棵树的“子树”最容易被攻破？然后针对性地加固。
我习惯用开源工具draw.io或yEd画，但更推荐直接在安全报告中用Mermaid或Graphviz——可以贴在Jira里自动更新。有一次我画完攻击树，发现三条路径里两条都要经过同一个内网跳板机，就把那台机器的日志加急分析了，果然抓到了横向移动。
4. 攻击向量分析——给每个攻击点打标签
攻击树画完了，你手上可能有一大堆叶子节点。但哪些是真正高危的？需要逐个分析攻击向量。
我常用的分析维度：
| 攻击向量 | 威胁等级 | 利用难度 | 常见场景 |
|---|---|---|---|
| 外部端口暴露（如SSH/3389） | 高 | 低（大量扫描器可用） | 云服务器默认安全组配置错误 |
| API未做身份校验 | 极高 | 低（直接发请求即可） | 内部工具接口外泄 |
| 文件上传漏洞 | 高 | 中（需绕过类型检查） | 用户头像上传功能 |
| 社会工程钓鱼 | 中高 | 低（需发送伪造邮件） | 客服系统、员工邮箱 |
| 第三方SDK后门 | 高 | 高（需供应链攻陷） | npm包投毒、CDN替换 |
分析完向量后，我还会做一件事：给每个向量打上“防御现状”标签（已覆盖、部分覆盖、未覆盖）。这能帮助决策下一步该优先修什么。
我的经验：攻击向量分析最容易遗漏的不是技术面，而是运维习惯面。比如有的团队把默认密码写成“admin123”不改，这种向量在攻击树上经常被漏掉。所以我在列表里总会加一行“默认配置 / 弱口令”，单独过一遍。
上面这张图是我自己一直在用的分析框架：先定义 → 再识别 → 画成攻击树 → 最后做向量分析。每一步的输出都要落到文档里，形成可追踪的攻击面清单。我见过太多团队只在“漏扫报告”上打勾，却从没系统化地画过攻击树——结果每次被攻破都像是“意外”。
实战中我建议你把攻击面分析的结果和Jira/缺陷管理工具打通，每个叶子节点转化成一个安全需求。这样开发团队就知道该修什么，而不是只收到一条“漏洞多”的废话。
小结（留给自己回头看）
攻击面分析不是一次性的。每次架构变更、每次新功能上线、每次第三方集成，攻击面都可能膨胀。我的习惯是：每两周回顾一次攻击树，每月重新做一次全量攻击面盘点。这听起来繁琐，但比起出事再救火，划算太多了。