第三章 MAP协议安全：核心网漫游的“阿喀琉斯之踵”
各位同仁，今天我们聊聊MAP协议。说实话，在核心网漫游这个领域，MAP协议就像个“老将”——资历深、应用广，但身上也带着不少陈年旧伤。我在现网排查过无数次漫游故障，有七成以上都跟MAP协议的安全问题脱不了干系。你想想看，一个诞生于90年代的协议，要承载今天复杂的漫游场景，不出问题才怪。
核心观点：MAP协议的安全缺陷，本质上是“信任过度”与“认证不足”的叠加。攻击者一旦摸清这些漏洞，就能在运营商之间“隐身穿行”。
3.1 MAP协议漏洞分析：那些“天生”的坑
MAP协议在设计之初，网络环境相对封闭，参与者都是可信的运营商。所以它的安全假设很朴素：只要你能连上信令网，你就是自己人。这个假设在今天看来，简直漏洞百出。
我个人习惯把MAP协议的漏洞归纳为三类：
- 认证缺失：MAP操作（如发送鉴权向量、更新位置）几乎不校验请求方的身份。我记得有一次做渗透测试，直接用伪造的GT地址发了一条
MAP_SEND_AUTHENTICATION_INFO，对方HLR居然照单全收，把鉴权五元组全吐出来了。 - 明文传输：MAP消息在TCAP层之上是明文。虽然底层有SS7的链路加密（很多运营商根本没开），但信令面本身不提供端到端加密。说白了，只要你能接入信令网，就能“看”到所有漫游用户的IMSI、MSISDN、位置信息。
- 无完整性保护：MAP消息可以被篡改而不被察觉。攻击者可以修改
MAP_UPDATE_LOCATION中的VLR地址，把用户“骗”到一个假的MSC上。
⚠️ 注意：很多厂商的MAP实现还有“缓冲区溢出”这类低级漏洞。我曾经在某个老款STP设备上，发现一条超长的MAP_PROVIDE_ROAMING_NUMBER请求就能让设备重启——这属于实现层面的“坑”，但同样致命。
3.2 MAP信令劫持：让用户“消失”在漫游地
信令劫持，说白了就是攻击者冒充合法网元，截获或篡改MAP信令。最常见的场景是位置更新劫持。
攻击流程大致是这样的：
- 攻击者伪造一个假的VLR，向HLR发送
MAP_UPDATE_LOCATION，声称用户已进入其服务区。 - HLR更新位置信息，把用户“绑定”到攻击者的VLR上。
- 后续所有发往该用户的呼叫、短信，都会被路由到攻击者的VLR。
- 攻击者可以静默拦截，或者直接拒绝服务——用户就“失联”了。
我在项目中遇到过一起真实案例：某跨国运营商的漫游用户频繁投诉“无法被叫”。我们抓包分析发现，HLR中用户的VLR地址被篡改成了一个不存在的GT。攻击者就是通过伪造的MAP_UPDATE_LOCATION实现的。嗯，这里要注意，HLR对位置更新请求的源地址校验几乎为零，这是劫持能成功的根本原因。
💡 避坑指南：我曾经建议团队在HLR侧增加“位置更新频率检测”。如果某个用户在1分钟内发起超过3次跨VLR的位置更新，直接触发告警并拒绝后续请求。这招虽然简单，但能挡住大部分自动化劫持工具。
3.3 MAP中间人攻击：在信令链路上“隐身”
MAP中间人攻击，比劫持更隐蔽。攻击者不冒充网元，而是插入到两个合法网元之间，双向拦截并修改消息。
为什么会这样？因为MAP信令在SS7网络中传递时，中间节点（如STP）天然可以“看到”并修改消息。攻击者只要控制了某个STP，或者伪造了一个STP接入信令网，就能实施中间人攻击。
一个经典的攻击场景是鉴权向量窃取：
- 正常流程：VLR → HLR 请求鉴权向量 → HLR返回RAND/AUTN/SRES/CK/IK
- 中间人攻击：攻击者截获HLR返回的鉴权向量，复制一份给自己，再把原消息转发给VLR。
- 后果：攻击者获得了用户的鉴权参数，可以伪造用户身份接入网络，或者解密用户通信内容。
你想想看，攻击者甚至不需要破解任何密码学算法，只需要“复制粘贴”一下信令消息。这就是MAP协议没有端到端完整性保护的恶果。
关键点：MAP中间人攻击的防御核心在于“信令路径可信”。如果VLR和HLR之间的信令路径上存在不可控节点，攻击就防不住。我个人建议在运营商间部署SIGTRAN over IPSec，至少保证传输层安全。
3.4 MAP重放攻击：老酒装新瓶
重放攻击，就是把之前截获的合法MAP消息，重新发送一遍。MAP协议对消息的“新鲜度”几乎没有校验，所以重放攻击特别好用。
举个例子：
- 攻击者截获一条
MAP_CANCEL_LOCATION消息（用于注销用户在某个VLR的位置）。 - 过了一段时间，攻击者把这条消息重放给HLR。
- HLR收到后，会认为用户已经离开了某个VLR，从而删除该VLR中的用户数据。
- 如果用户恰好正在那个VLR下做业务，就会被强制下线。
我记得有一次做安全演练，我们重放了一条3小时前的MAP_INSERT_SUBSCRIBER_DATA消息，居然成功修改了用户的签约数据——把用户的APN配置改成了一个不存在的值。这说明HLR对消息的“时序”和“重复性”完全没有检查。
⚠️ 注意：重放攻击的防御其实不难。在MAP消息中加入时间戳或序列号，接收方做去重和时效性校验就行。但问题是，很多老旧的MAP实现根本不支持这些扩展。我曾经在某个现网中看到，HLR的MAP处理逻辑里连“消息ID去重”都没做——这相当于把大门敞开了。
3.5 知识体系总览
下面这张图，是我梳理的MAP协议攻击与防护的核心逻辑。你可以把它当作本章的“思维导图”：
3.6 实战防护建议
讲了这么多攻击，总得给点干货。我个人在现网中总结了一套“MAP安全三板斧”：
| 防护层面 | 具体措施 | 效果 |
|---|---|---|
| 信令过滤 | 在STP或信令网关上，配置白名单，只允许已知GT地址发送MAP请求 | 挡住大部分伪造源地址的攻击 |
| 消息校验 | 对MAP_UPDATE_LOCATION、MAP_SEND_AUTHENTICATION_INFO等敏感操作，增加源地址反向校验 | 防止VLR/HLR被冒充 |
| 去重与时效 | 在HLR/MSC中实现MAP消息ID缓存，对重复消息直接丢弃；增加时间戳校验 | 有效防御重放攻击 |
💡 我的经验：别指望一套方案解决所有问题。MAP协议太老了，很多漏洞是“设计使然”，补丁只能缓解。我建议在现网中逐步向Diameter/SBI协议迁移，那才是未来的方向。但在那之前，先把信令过滤做好——这能挡住80%的脚本小子。
好了，MAP协议的安全问题就聊到这儿。记住一句话：在信令网里，没有“默认信任”这回事。每一个MAP消息，都可能是敌人递过来的刀。
公众号:蓝海资料掘金营，微信deep3321