msrpcDCERPC服务枚举漏洞

拿到一台Windows主机，举漏权限不高，举漏想快速摸清上面跑了哪些RPC服务，举漏很多人第一反应就是举漏去调 epmapper。这个接口挂在135端口，举漏用DCE/RPC的举漏端点映射器把注册过的接口一个个列出来，看起来人畜无害，举漏实际上信息量极大。举漏我见过不少内网机器，举漏防火墙只开了135和445，举漏管理员觉得“就这两个端口，举漏能出什么事”，举漏结果枚举出来的举漏接口列表直接暴露了系统补丁级别、装了哪些第三方组件、举漏甚至某些内部业务系统的举漏通信接口。

问题出在DCE/RPC的设计哲学上。它本来就是个“先问再连”的机制——客户端不知道服务在哪个动态端口，于是先连135问端点映射器，映射器告诉它“你要找的接口在xxxx端口”。这个查询过程默认不需要认证。微软从没觉得这有什么问题，因为RPC本来就是内网基础设施，设计时假设网络边界足够可靠。但现实是，太多机器的135端口对着不该对的方向敞开。

具体枚举起来很简单。rpcdump.py、impacket里的dcetransport工具，甚至自己写个脚本调ept_lookup都行。返回的是一串UUID加版本号，每个UUID对应一个接口。关键在于怎么解读这些UUID。比如12345778-1234-abcd-ef00-0123456789ab是lsarpc，12345778-1234-abcd-ef00-0123456789ac是samr，367abb81-9844-35f1-ad32-98f038001003是svcctl。有经验的人扫一眼就知道这台机器大概是什么角色——域控、Exchange、SCCM服务器，接口列表会说话。

更麻烦的是那些非微软接口。我遇到过一台机器，枚举结果里有个UUID查不到公开资料，版本号是2.0。顺着端点信息连过去，发现是个内部开发的库存管理服务，监听在高端口，没有任何认证。那台机器本身补丁打得很全，但因为这个自研RPC服务，整个内网横向移动的路径就打开了。管理员后来跟我说，这个服务是五年前外包做的，外包公司早就不在了，文档也没有，谁都不敢动。

微软其实在Windows Server 2003之后就逐步收紧了RPC端点的访问控制，但兼容性包袱太重，很多老接口至今还在。135端口本身可以通过防火墙限制源地址，但内网里做这个的少之又少。域环境里更麻烦，域控的135端口必须对大量机器开放，枚举出来的接口列表几乎就是一本Active Directory服务大全。

防御这件事，说难也难，说简单也简单。最直接的办法是在边界防火墙上封掉135，内网用IPsec或者Windows防火墙做端口过滤。但很多企业内网是“信任”模型，同一网段随便通，那就只能靠RPC层面的限制。Windows有个注册表键RestrictRemoteClients，设成1可以强制所有RPC客户端走认证，但设了之后老应用可能直接挂掉。我见过一个运维团队试了一晚上，第二天早上回滚，因为财务系统连不上数据库了。

所以现实中的做法往往是监控而不是阻断。在核心交换机上做NetFlow，盯着135端口的异常连接；或者用EDR在主机层面记录ept_lookup的调用频率。一个普通工作站五分钟内枚举几百个接口，这行为本身就不正常。至于那些必须暴露的RPC服务，至少把接口UUID换成非公开的，虽然这属于“隐藏而非防护”，但能挡住大部分自动化扫描。

说到底，msrpcDCERPC枚举漏洞不是一个CVE，没有补丁可打。它是协议设计、历史包袱和运维习惯共同作用的结果。你没法“修复”它，只能一层层地限制、监控、妥协。每次看到135端口在公网上裸奔的机器，我都觉得这像是一扇没锁的后门——门本身没坏，但谁都能推开看看里面有什么。