PLFM_RADAR是我们在做平台化安全能力时落下的一个内部项目名字里的PLFM是PlatformRADAR则是个比喻——它不对空域探测而是对互联网资产做持续测绘和风险预警。项目的最初形态挺朴素一台服务器、一张定时任务表、一个Nginx反向代理但跑了大半年之后它成了安全团队每天打开的第一块屏幕。这篇文章把PLFM_RADAR从立项到上线的完整链路写清楚它解决什么问题、核心模块怎么设计、指纹识别和风险评分怎么落地以及那些在文档里绝对不会写的坑。适合正在搭资产测绘或攻击面管理平台的工程师也适合想知道安全团队到底每天在看什么的产品和运维同学。1. 一次凌晨的漏洞通告把家底不清的问题彻底摆上了台面事情是从一封凌晨的漏洞通告邮件开始的。第三方漏洞平台发来告警标题写着某测试环境存在未授权访问漏洞危害等级高要求24小时内完成修复。值班同事爬起来排查发现这台机器是三个月前上线的一个内部系统测试机部署完成后负责人换了三轮连系统归属部门都没人说得清。更麻烦的是这个环境用了临时域名和随机端口重新梳理网络拓扑才定位到物理位置。这个场景很多安全团队都经历过。真正的痛点不是漏洞被曝光而是我们不知道这台设备存在。传统安全建设习惯把精力放在WAF、HIDS、防火墙这些防护设备上默认前提是我已经知道自己有哪些系统。但现实是业务发展快的时候开发为了赶进度会临时起一台服务器运维为了联调会开放一个额外端口甚至连云账号开了新的VPC都未必同步给安全团队。这些节点在防护体系之外却在公网上真实暴露着。1.1 传统资产台账为什么救不了场我见过不少团队维护资产台账的方式一张Excel表格字段包括资产名、IP、负责人、上线时间。刚维护的前三个月是准的之后就逐渐失真——新系统上线没人填老系统下线没人删负责人调动后表格里还是旧名字。安全团队拿着这份台账做基线检查等于拿着错误地图找路。PLFM_RADAR立项时的第一个动作就是把这套思路反过来不依赖人工录入而是让系统自己去看。从已确认的少量种子资产出发通过域名解析、IP段扫描、证书透明日志、外部威胁情报等渠道把暴露在互联网上的资产一点点画出来再回填责任人信息。人工台账变成校验参考而不是数据源。1.2 三个目标决定项目边界第1章写多了容易变成需求讨论。当时我们把PLFM_RADAR的交付目标收敛成三句话持续测绘周期性发现并更新域名、IP、端口、服务形成动态资产清单。自动识别通过指纹技术判断每个服务是什么系统、什么版本、属于哪个业务。风险排序结合漏洞信息、暴露程度和资产重要性给出可量化的风险分。这三个目标直接决定了后面的架构选择。我们不打算做一个漏洞扫描器因为市面上已经有很成熟的Nessus、AWVS也不打算做一个合规报表系统因为报告再漂亮也不能解决不知道资产在哪的根本问题。PLFM_RADAR的定位更接近资产底座——它把最基础的盘点工作自动化然后把数据开放给其他安全系统调用。1.3 为什么叫RADAR而不叫资产扫描器命名上我们有过讨论。团队里有人提议叫资产发现平台太绕。后来一致同意用RADAR是因为雷达的工作逻辑和资产测绘很接近雷达主动发射波束接收回波判断目标方位和性质PLFM_RADAR主动发起探测请求分析响应特征判断目标服务和风险状态。雷达不会因为某个方向看起来安全就停止扫描这正是我们需要的工作状态。2. 画资产、认指纹、定风险PLFM_RADAR的核心闭环项目启动时工程文档里画了三张流程图后来被我们并成一条闭环采集原始数据提炼资产主体识别服务指纹汇总风险评分。这一章把这条链路拆开讲。2.1 画资产从域名、IP到服务实例所谓画资产不是简单拉一个域名清单而是把资产之间的关系建立起来。PLFM_RADAR里最重要的资产实体有三个实体关键字段说明域名domain, cname, mx, ns, 解析IP列表资产入口IP资产ip, port, protocol, 归属ASN/地区网络位置服务实例host:port, 指纹标签, 指纹版本, 首次发现时间真正被攻击的客体阶段一的数据来源是内部DNS解析日志和已有CDN配置。我们把已知域名丢进去做被动DNS解析拿到一批IP。然后用主动扫描去探测这些IP的开放端口再对端口做服务识别。第一次全量扫描跑了差不多两天产出的结果让我们吃了一惊发现的实际端口数是原台账记录的三倍多其中Redis、MongoDB、MySQL这类数据库端口直接暴露在公网的有十几个。画资产这个阶段最容易被低估的是归一化工作。同一个系统可能同时有A记录、CNAME、多个端口如果不去重资产数量表会出现大量噪声如果去重过度又会把真实独立节点合并掉。我们的做法是以IP:Port作为服务实例的唯一标识同时保留域名到IP的多对多关系靠后续的指纹关联来判断哪些服务实例属于同一套系统。2.2 认指纹让机器回答这是个什么东西光知道IP 1.2.3.4的443端口开了没有意义攻击者利用的是具体产品的漏洞。所以第二个阶段要让机器回答这个端口上跑的是Nginx还是Apache是Spring Boot还是ThinkPHP是门户网站还是管理后台答案由指纹识别引擎给出。指纹识别的本质是用一组特征规则去匹配探测响应数据。规则来源包括HTTP响应头特征如Server: nginx/1.18.0X-Powered-By: PHP/7.2。页面内容特征HTML里的关键词、meta生成器标签、固定静态资源路径。行为路径特征访问某些固定URL是否返回特定内容例如/wp-login.php暴露WordPress。TLS证书特征证书的CN、SAN、组织名、扩展字段。特殊文件哈希如favicon.ico的MD5很多框架自带独特的favicon。PLFM_RADAR把几十种常见中间件、框架、管理后台的指纹整理成了规则库格式类似这样- name: Nginx category: web-server priority: 80 matches: - type: header field: Server regex: nginx/([0-9.]) confidence: 0.9 - type: banner regex: ^nginx$ confidence: 0.7每条规则都带一个置信度权重服务会收集到若干条命中结果最终得分就是加权后的最大值。现在这套规则库维护了一年多覆盖了近两百个常见产品和组件识别准确率大概稳定在九成左右剩下的误差大多出现在老版本改版和自定义开发场景。2.3 定风险把可能有问题量化成可处置的分数识别出服务版本之后就可以判断有没有已知漏洞了。但这里有个很容易犯的错误把CVSS分数直接当成处置优先级。CVSS只描述漏洞本身的严重程度没有考虑资产在业务里的角色。一个边缘测试系统上的高危漏洞和一个核心生产库上的中危漏洞直接按CVSS排序会让团队天天救火。PLFM_RADAR的风险评分做了二次加权前面的章节会详细讲公式这里先给出结论定风险的本质是组合判断资产重要性、暴露程度、漏洞真实可利用性、是否被外部威胁情报标记四个维度叠起来才是可执行的优先级。3. 系统架构与核心模块拆解PLFM_RADAR从架构上看并没有特别高深的东西但它把很多通用组件组合成了一个完整闭环。整个系统分为四层采集层、存储层、分析层、展示层。我重点讲前三层因为绝大多数工程难点都堆在这里。3.1 采集层主动测绘和被动监听两条腿走路采集层是PLFM_RADAR的信息来源分主动和被动两路。主动采集是主力流程是目标生成从资产库取出需要扫描的IP、域名和端口范围。端口预探测用masscan做全端口SYN探测快速筛选出开放端口。服务识别对开放端口执行Nmap的服务版本识别和httpx的Web指纹探测。指纹采集拉取页面、响应头、证书、favicon等原始数据存入暂存区。被动采集是补充主要接内部DNS日志和主机流量元数据。它的价值在于能发现主动扫描永远发现不了的东西内网DNS里出现了一个新域名流量日志里出现了一个外联IP这些信息能帮助我们发现种子资产之外的未知边界。被动数据有个好处频率高、成本低适合做实时感知但也有个毛病噪声大需要大量清洗。比如内网DNS里有大量healthcheck、autodiscover这种随机探测记录如果不做过滤资产库会迅速膨胀。3.2 存储层资产数据为什么不能只放一种数据库这个选择我们踩过坑一开始图省事把所有数据塞进MySQL结果扫描结果一多单表轻松破亿查询慢到没法用。后来重新设计了存储方案用途存储引擎设计要点资产关系域名、IP、归属PostgreSQL主库强事务维护资产主体扫描记录与指纹原始数据Elasticsearch全文检索按天建索引定期冷数据迁移任务队列和去重状态Redis短生命周期高吞吐统计报表、趋势分析ClickHouse列存适合多维度聚合PostgreSQL和Elasticsearch之间通过资产ID关联这里有个细节ES里只存事实记录比如某次扫描发现某端口返回什么指纹而每个资产的最新状体态放在PostgreSQL里。这样既保证历史可追溯又让查询快速。3.3 分析层标签、关联和沉睡资产发现分析层负责把采集到的原始数据翻译成安全团队能理解的信息。第一步是打标签。标签体系分为几类技术标签语言、框架、中间件、业务标签生产、测试、管理后台、异常标签公网暴露、弱口令、敏感端口。标签由规则引擎、指纹结果和人工运营共同产出。第二步是关联。一个开放了3306端口的IP同时指纹结果是MySQL并且在证书或历史DNS里能关联到某个域名那它大概率是数据库服务。这种关联让资产画像从一列IP变成一套系统的节点。第三步是沉睡资产发现。定义很简单超过30天没有活跃流量、没有更新记录、但依然暴露在公网上的资产。这些节点往往是安全团队最大的盲区也是攻击者最喜欢的目标。PLFM_RADAR每天跑一次沉睡资产检测把命中列表推送给人处理。3.4 任务调度一次全量扫描怎么拆成百万级小任务PLFM_RADAR刚上线时的扫描任务调度就是一个简单的定时脚本按顺序跑结果经常出现某台采集机扫到一半卡住半个流程全停摆。后来改成基于Redis队列的调度模型每次全量扫描任务被拆成目标IP段 目标端口段的原子任务每个任务处理一小块范围。工作节点从队列里取任务执行完成后上报结果按指数退避策略做重试。每个IP段的任务执行完会打一个标记下次调度时跳过已完成段支持增量扫描。这个模型并没有用很重的框架Redis 一个简单的Python Worker进程就搞定了。拆小任务的好处除了容灾还能精准分配扫描速率避免一下子把出口带宽打满。4. 指纹识别引擎的工程实现细节指纹识别是PLFM_RADAR里技术含量最集中、也最体现做没做过的部分。市面上很多扫描器也能出指纹但真正落地到能持续维护、能控制误报、能和漏洞信息联动的并不多。4.1 一次探测请求的完整生命周期拿最常见的Web服务识别的链路举例采集器发起HTTP请求带上一个模拟浏览器的User-Agent设置5秒超时。接收响应后原始数据会被切成四个部分状态码、响应头、页面正文截取前256KB、TLS证书。分别对这四个部分做MD5哈希把哈希值和原始数据一起落地到对象存储方便后续规则变更时离线重算。指纹引擎读取规则库对采集到的数据执行匹配。真实请求可能会遇到网络抖动、协议形态差异比如WebSocket服务对普通HTTP请求返回的是非标准响应。所以在请求阶段会设置重试一次 一次指纹探测请求失败后改用HTTPS再探测的逻辑。这个细节保证了指纹识别的召回率。4.2 指纹匹配从精确匹配到置信度打分指纹匹配不复杂但需要设计一套置信度机制。我们把匹配方式分成四档方式说明适用场景精确匹配哈希、状态码、固定URLfavicon识别、框架固定资源含匹配响应头、正文中是否包含某字符串版本号、X-Powered-By、特定Cookie正则匹配用正则表达式提取版本信息从Server头、JS文件里提取版本组合规则多条子规则同时满足降低泛匹配误报每条规则命中后得到confidence值多个规则命中同一组件时最终分数取加权最大值。比如Server: nginx命中的置信度是0.9如果同时页面里检测到/nginx-logo.png再加0.05但总分封顶1.0。置信度分还有一个用途决定是否需要主动验证。当一条指纹的置信度在0.5到0.75之间时系统会发起一次补充探测比如访问特征URL、拉取特定目录列表来确认或推翻当前判断。4.3 误报处理泛匹配、同源指纹与版本识别指纹误报的来源主要有三类泛匹配某些规则写得太宽比如body里匹配powered by就认为某个CMS实际上这句话可能出现在任何页面的footer里。解决方法是加否定规则出现过某个字符串就排除。同源指纹多个产品共用同一套开源代码或模板导致指纹撞车。最典型的例子是Discuz的模板被很多地方门户二次开发favicon和部分路径完全相同。这种只能靠更细粒度的特征来区分比如特定函数名、特有接口路径、cookie结构。版本识别有些指纹能识别出是Nginx但拿不准具体子版本。PLFM_RADAR的处理方式是版本信息单独存字段风险评分时如果子版本未知按未知版本而不是无漏洞处理提醒人工复核。4.4 指纹规则库的维护节奏指纹库不是一锤子买卖它需要跟着新框架、新版本持续更新。我们的维护节奏是一个月两次流程是从外部威胁情报和GitHub release里收集新出现的组件。搭建一个临时环境安装该组件采集真实响应数据归纳特征。把规则提交到测试库跑一遍历史数据看是否产生大量误报。通过后发布到线上生产规则库。规则维护还必须配一个样本库把每次扫描中识别失败但被人工确认为某组件的样本收集起来作为下次规则优化的输入。这是PLFM_RADAR能越用越准的关键。5. 风险评分与告警降噪让平台不会变成狼来了机器系统刚能跑之后安全团队收到了一堆告警两周后大家开始麻木。因为告警太多了真正严重的问题淹没在海量噪声里。这一章讲评分模型和降噪手段。5.1 为什么告警越做越多处置却越来越慢告警多的根源是检测规则缺少上下文。比如公网暴露了SSH服务本身不算漏洞但如果这个IP还挂着管理后台指纹、近30天有来自境外的登录爆破流量、资产重要性又很高那它才是真正需要立即处置的风险。PLFM_RADAR把告警从一条规则命中升级为多维证据组合让平台输出的每一条告警都能直接对应到处置动作。5.2 评分公式资产重要性、暴露程度、漏洞确证、威胁情报最终的风险分采用加权公式四个维度如下risk_score 0.30 * asset_importance 0.25 * exposure_level 0.30 * vuln_confirmed_factor 0.15 * threat_intel_factorasset_importance资产重要性按域名资历、业务属性、是否涉及敏感数据等指标打分0~10分。exposure_level暴露程度端口暴露范围、是否绕过认证、访问来源是否覆盖全网0~10分。vuln_confirmed_factor漏洞确证因子有没有匹配到已知CVE/漏洞库CVSS有多高0~10分。threat_intel_factor威胁情报因子该资产IP/域名是否出现在恶意IP库、僵尸网络CC情报里0~10分。最后用risk_score 7作为必须人工处置的阈值。资产重要性分数由业务团队在平台上维护我们一开始用域名是否带.com这种粗粒度规则去猜后来才发现人工维护才是性价比最高的方式。5.3 降噪三板斧收敛、白名单、时间窗合并即使有了评分平台还是会有重复和低价值的告警。我们用了三个操作把告警量砍掉大约七成**第一斧收敛。**同类资产、同一天发出相同告警只保留一个主告警其余作为附件详情。比如同一个IP段的100台机器都暴露了同一个高风险端口合成一条该IP段100台机器批量暴露。**第二斧白名单。**有一些资产是业务主动暴露的比如对外开放的官网、客户回调接口。这些资产业务方明确确认过安全策略就在白名单里备注原因告警自动降级为低优先级。**第三斧时间窗合并。**同一个资产的同一类告警在24小时窗口内只提醒一次如果处置超时再升级。这一条直接减少了早上9点重复推送前晚告警的问题。5.4 处置闭环工单、复测打分与止损确认PLFM_RADAR不是只发一个告警就结束了。平台对接了内部缺陷管理系统告警达到阈值后自动创建工单附带资产画像、指纹信息、风险标记和修复建议。处置完成后工单系统回传已修复状态平台会自动发起一次复测验证端口是否已关闭、受影响组件是否已升级。复测通过的工单风险评分会降低并进入观察期复测没通过的工单会自动重新打开并且提示修复措施未生效。这套闭环跑起来之后团队才真正敢说所有高风险问题都在处置中。6. 落地过程中踩过的坑和工程调整技术方案讲起来条理清晰落地过程却是一路踩坑踩过来的。这章把几个印象深刻的坑分享出来给正在做类似平台的同学一点前车之鉴。6.1 第一个坑把扫描频率调成一小时一次交换机先扛不住了一开始为了追求实时我们把资产扫描频率设成了每小时一次。跑了两天网络团队找上门说出口交换机CPU长时间高负载部分办公网络已经出现丢包。排查定位到是masscan的高速率SYN探测把交换机的转发队列打爆了。后来调整了策略高频小范围扫描与低频全量扫描分离。每天跑一次全量端口探测每两小时只扫「已发现开放端口」做存活确认真正的高频监测放在被动数据收集上。这个调整让扫描峰值速率下降了80%资产新鲜度却没有明显下降。6.2 第二个坑泛域名把资产库撑爆还拖垮了评分被动DNS日志接入后资产库的域名数量一夜之间翻了几十倍。仔细一看大部分是web-xxxx.internal.example.com这类泛域名自动生成记录。这些域名不是真实资产但评分体系会把它当成独立资产打高分导致大量无意义的告警。处理方式是给资产库加了一个泛域名聚簇能力域名按主域名分组如果某个主域名下动态子域名超过一定数量就自动归为动态域名簇不再逐条告警只对簇内出现真实Web服务指纹的个别域名单独关注。6.3 第三个坑指纹规则写得太激进把企业网关认成路由器有一次平台把公司出口网关识别成了某品牌路由器并附带了一个中危漏洞告警。排查下来是因为网关设备的管理页面使用了某开源项目的前端模板而那条指纹规则刚好匹配了模板特征。这个坑让我们意识到指纹规则不能只看响应当中出现什么还要看排除性特征。后来的规则库每个条目都增加了exclude字段比如匹配到某特定路径就直接排除避免单一特征误判。6.4 边界感扫描授权的刚性规定和一点个人体会PLFM_RADAR做的是主动探测所以授权边界从一开始就是刚性的。我们对所有扫描目标做分类属于自有资产的范围正常扫描属于云上租户的资源需要确认云平台租约合同允许安全测试属于第三方但在业务链上的系统只做被动数据关联绝对不发起主动扫描。每季度也会重新梳理一次目标清单防止业务下线后的资产被漏出扫描范围。如果让我重新做一次PLFM_RADAR我会把两件事提前第一是提前设计好资产白名单的运营流程而不是等技术上线后才让业务团队补信息第二是做一套完整的指纹样本库从第一天就开始积累后面优化规则会省掉大量回看历史数据的时间。整个项目做下来最深的感觉是——安全平台的复杂性不在某个算法里而在那些每天和数据噪声、误报、资产边界较劲的细节里。把这些细节处理好了平台才能真正成为团队信任的雷达。