“海康威视漏洞合集”这个标题我在安全社区、资产测绘群、甲方运维群里见过太多次了。每次看到它我心里都会冒出同一个念头大家真正缺的不是一份“漏洞清单”而是一张“我能管住的资产表”。我做过几年安全运营也做过安防系统交付前后对接过几百台摄像机、NVR、CVR 和配套的综合安防管理平台从弱口令到组件依赖问题从端口暴露到配置文件管理踩过的坑够写一本小册子。这篇东西就是把这些年的实战经验摊开讲海康威视设备及其配套平台的安全问题为什么反复出现、哪些类型最容易中招、在没有厂商内部资料的情况下怎么自查、加固项具体怎么落地、授权范围内的验证怎么做、报告怎么写才不会被退回、修完之后怎么确认真的修好了。不管你手里只有几台家用摄像机还是管着上千路的企业级安防平台都能从里面挑到立刻能用的东西。1. 为什么海康威视设备的安全问题一直是高频话题1.1 存量与暴露面数量本身就是风险放大器先摆一个事实这类设备的保有量太大了。从街边小店的两三个枪机到园区里成百上千路的高清球机再到交通、能源、制造行业的整套视觉系统同一套协议、同一套 Web 框架、同一个 SDK 被复制了无数遍。任何一个设计上的小疏忽乘以百万级的设备存量都会变成一个看起来很夸张的数字。暴露面的构成也很典型。设备出厂默认就要提供 Web 管理、RTSP 取流、ONVIF 发现、SDK 接入这几条通路任何一条不小心开到公网上就等于把管理界面摆在了马路中央。我见过太多案例施工队为了调试方便把设备的 80 端口直接映射到公网验收完忘了删还有人图省事把整栋楼的设备放在一个没有访问控制的网段里只靠“别人不知道 IP”来当安全措施——这在今天基本等于没设防。更要命的是“老化”。安防项目的生命周期动辄五到十年设备装上去之后很少有人主动升级固件。三年不更新的设备和三年不更新的服务器一样风险是随时间递增的。所以讨论这类话题时我从来不把它当成“某个品牌的漏洞问题”而是当成一个存量资产 长期不维护 默认开放服务的复合问题。理解这一点后面的所有排查和加固思路才立得住。1.2 把“漏洞合集”翻译成“资产台账”才是第一步我特别不建议新手一上来就收藏各种“合集”然后挨个去试。原因有两个。第一网上的合集大多只有现象描述没有版本范围、没有前置条件、没有修复建议你照着试只会浪费时间甚至在不该试的环境里试出问题。第二绝大多数真实事故的成因根本不在“高级漏洞”上而在最朴素的地方默认口令没改、固件没升、端口没关、权限没分。我的做法是把这件事翻译成三个工程问题我有哪些设备每台设备跑的是什么版本每台设备对外开了哪些服务这三问答清楚了安全工作的 80% 就已经完成。剩下的才是针对具体问题类型的深挖。你在做任何扫描、任何验证之前先把台账建起来这不是官僚流程这是让你后面每一步都有据可依。具体来说台账至少要记录这几列设备类型枪机/球机/NVR/CVR/平台服务器、型号、固件或软件版本、管理 IP、所属网段、对外暴露情况、负责人、上次变更时间。别小看这几列我处理过一次紧急事件就是因为台账里记了“某台 NVR 三个月前做过端口调整”五分钟就定位到了变更源头否则光排查就得半天。2. 常见问题类型的分类梳理与原理拆解2.1 认证与口令类最简单也最致命如果让我给所有问题按“实际造成事故的比例”排个序认证类问题稳居第一。它的表现形态很朴素设备使用了出厂默认口令或者使用了施工方为了省事统一设置的弱口令或者多人共用一个管理员账号且从不轮换。为什么这类问题这么顽固因为安防设备的部署场景天然是“多角色参与”的厂商出厂、集成商安装、物业使用、外包维护链条越长口令越容易被“临时改一下、回头再改回来”。我见过一个园区几十台设备的口令是安装日期加房间号规则统一且好记但等于把口令写在了门牌上。加固这件事没有捷径就是把口令管理纳入运维流程新设备上线强制改默认口令口令长度和复杂度按企业内部标准执行管理员账号和操作员账号分离离职和换外包时立刻轮换。听起来很基础但真正坚持做下来的团队安全事故率会低一个数量级。注意口令策略落地时不要只在设备上改还要同步更新密码管理库和交接文档否则下一个人找不到口令很可能会重置成更弱的。2.2 服务暴露类RTSP、ONVIF、Web 与 SDK 端口这一类是“设备属性”带来的天然风险。设备必须提供取流通路管理平台必须提供服务端口这就意味着总有一些端口是“业务上必须开”的。问题不在于开而在于开给谁。常见的几条通路是Web 管理界面、RTSP 取流、ONVIF 设备发现与配置、以及各类 SDK 接入端口。它们的共同特点是协议公开、客户端众多、配置项分散。RTSP 取流地址这类信息在项目交付中经常被写进各种手册和文档里时间一长就变成了“公开信息”谁拿到都不奇怪。我处理这类问题的思路是分三层收口。第一层是网络层管理面必须放在独立管理 VLAN只允许指定的运维跳板访问绝对不做公网映射。第二层是认证层所有对外提供的服务必须启用强认证匿名访问一律关闭取流账号和配置账号分开。第三层是审计层对管理面登录、配置变更、账号增删做日志采集异常时间点的登录要能查到。提示很多团队只做了第一层就以为安全了其实内网横向移动一旦发生第二层的强认证才是真正的最后一道门。2.3 组件依赖类管理平台侧的 log4j、Nacos、JWT 等问题前面聊的是设备本身但真正的重灾区往往是配套的软件平台。综合安防管理平台、视频云平台这类系统本质上是 Java 应用会依赖大量第三方组件。所以你在通用漏洞情报里看到的那批熟悉的名字——日志组件、配置中心、认证令牌、模板引擎、文件解析库——在这类平台上是同样适用的。我按原理把它们分成几组方便你建立直觉类型核心原理典型表现加固方向日志组件类日志内容被当作可执行模板解析特定输入触发外部调用升级组件版本关闭危险解析开关配置中心类命名空间或接口未做鉴权未授权读取配置开启鉴权限制网络访问令牌类签名校验或算法选择被绕过越权访问接口强制指定算法校验受众与有效期XML 解析类外部实体被解析读取本地文件或发起请求禁用外部实体解析服务端请求伪造服务端代发起请求探测内网、读元数据白名单校验目标地址上传与解析类文件类型校验不严执行非预期内容白名单后缀 内容校验 隔离存储这张表的价值不在名字而在于它告诉你该去查什么。比如你做资产盘点时发现平台是 Java 技术栈那你的组件清单里就必须包含日志组件、配置中心、认证框架这几项而不是等出事了才去翻依赖树。JWT 这类认证令牌的问题特别值得单独说一句。很多自研接口为了实现方便会允许客户端指定签名算法或者只解码不校验签名。从原理上看就是“把身份凭证的控制权交回给了客户端”。修复思路很明确服务端固定算法强制校验签名、过期时间、签发方和受众把令牌里的权限声明只当作提示真正的鉴权必须回源查询。这个原则在任何平台上都成立。2.4 配置与业务逻辑类容易被忽略的“合法入口”最后一类是最难自动发现的因为它不涉及任何异常输入所有操作都是“合法请求”。典型例子是订单类系统的库存扣减逻辑、设备侧的级联配置、平台的批量导入导出接口。举个真实的场景某系统的设备批量导入接口没有做数量限制和权限校验一个普通操作员账号可以一次性导入上万条记录触发资源耗尽。从接口定义上看它完全合法从业务上看却是事故。这类问题的排查方式只能是人工梳理核心业务链路哪些接口会读写关键数据、哪些操作会产生资源消耗、哪些功能只有管理员该用。我的经验是做资产梳理时同步画一张“业务链路图”标出每条链路上涉及的角色和接口。这张图不用很精美但它能帮你在评审时快速发现“这个接口怎么谁都能调”。很多修复其实只需要在网关或服务层加一层角色校验成本极低收益极高。3. 自查与加固的完整实操流程3.1 第一步资产盘点别急着扫漏洞我见过太多人上来就开扫描器扫完一堆结果然后不知道从哪下手。正确顺序是先盘点。盘点方式取决于你管理的规模几十台设备Excel 加手工核对就够几百上千台就必须上自动化。自动化盘点的最小可用方案是“先发现、后分类”。发现阶段用一个简单的存活探测和端口探测把活跃设备和开放端口先摸出来。这一步只对你拥有或获得明确授权的网段执行这条界线必须守住。# 仅限自有或已授权网段执行 # 第一步存活探测快速找出活跃主机 nmap -sn 192.168.10.0/24 -oG - | awk /Up$/{print $2} alive_hosts.txt # 第二步针对常见安防端口做探测 # 80/443 Web管理, 554 RTSP, 8000 常见服务端口, 37777 设备服务端口 nmap -sT -p 80,443,554,8000,8080,37777 --open -iL alive_hosts.txt -oX scan_result.xml这两条命令的意图很清楚第一条只做存活判断速度快、噪声小第二条只探特定端口避免全端口扫描带来的巨大噪声和耗时。实测下来一个 C 段网段的存活探测通常在几十秒内完成端口探测视网络质量在一到三分钟之间。拿到结果后把 XML 转成清单表格方便后续分类。我习惯用一个简单脚本做格式化比手工整理快得多import xml.etree.ElementTree as ET tree ET.parse(scan_result.xml) root tree.getroot() rows [] for host in root.findall(host): addr host.find(address).get(addr) ports [] for port in host.findall(./ports/port): if port.find(state).get(state) open: ports.append(port.get(portid)) if ports: rows.append((addr, ,.join(sorted(ports, keyint)))) with open(asset_list.csv, w, encodingutf-8) as f: f.write(ip,open_ports\n) for ip, p in rows: f.write(f{ip},{p}\n) print(f共整理 {len(rows)} 台设备)这段脚本做的事情就是把扫描结果压成两列IP 和开放端口。看起来简单但它是后面所有工作的基础。我强烈建议你给这个 CSV 再加几列手填字段设备类型、型号、固件版本、物理位置、负责人。填完这几列你的台账就成型了。注意扫描动作会留下日志如果你的环境有 IDS 或日志审计提前跟团队打个招呼避免自己的扫描被当成攻击事件处理。3.2 第二步端口与指纹识别有了开放端口清单下一步是判断“这个端口后面到底是什么服务”。这一步决定了你后面用哪种加固策略。安防设备的端口语义相对固定我整理了一张对照表端口常见用途风险关注点建议处置80 / 443Web 管理界面弱口令、未授权页面收进管理 VLAN启用强认证554RTSP 取流匿名取流、口令外泄关闭匿名取流账号最小权限8000部分设备服务端口服务版本老旧核对固件版本必要时升级37777设备服务端口对外暴露面严格限制来源地址8080平台类服务组件依赖问题纳入组件清单逐项核对指纹识别的实现方式我一般用 HTTP 响应头加页面特征结合判断# 抓取 HTTP 响应头判断服务类型与版本线索 curl -sI --max-time 5 http://192.168.10.66/ | head -20 # 检查 RTSP 是否允许匿名访问仅对自有设备 # 如果返回 401说明需要认证这是好现象 # 如果直接返回 200 和流信息说明匿名可取流需要立刻整改 curl -sI --max-time 5 rtsp://192.168.10.66:554/ -u 第二段命令的意图非常明确验证匿名取流是否被允许。返回 401 是正常且安全的返回 200 则必须整改。这个检查只要几秒钟但能覆盖掉一大类真实事故的成因。识别完之后要在台账上补一列“服务指纹”并且标注每一台设备的对外暴露级别仅内网、内网加跳板、还是有过公网映射历史。有过公网映射历史的设备要重点检查日志里有没有异常登录记录。3.3 第三步版本核对与固件台账版本这件事我的态度是“不做猜测只做记录”。因为不同型号的固件分支完全不同同一个功能在不同分支上的行为可能不一样凭印象判断风险极不可靠。具体做法是登录管理界面授权范围内在系统信息页读出版本号记进台账对于平台类系统读取组件清单重点看日志组件、配置中心、认证框架、文件解析库这几项的版本。记录完之后你要做的不是“对照网上某个列表”而是建立一套内部判断标准该版本是否还在厂商的维护周期内近一年内是否有针对该组件或该型号的安全更新升级窗口是否影响业务连续性。第三条经常被忽略。安防系统升级往往需要停机而停机意味着监控中断很多项目因此一拖再拖。我的经验是把升级拆成小批次滚动执行每次只升一个网段或一个机房配合业务方约定的低峰时段这样既能推进又不会造成大面积中断。提示升级前务必备份当前配置。配置备份是运维的基本功很多团队升级失败后才发现没有备份只能重头配置代价巨大。3.4 第四步加固配置逐项落地这是整个流程里最出效果的一步。我把加固项整理成一份可以直接照着做的清单关闭不必要的对外服务。公网映射、UPnP 自动端口、匿名访问这三项能关就关。关闭顺序建议从公网映射开始因为它的风险等级最高。分离管理面与业务面。管理网段和设备网段分开管理面只允许跳板访问。这一步配合防火墙策略做成本不高但效果立竿见影。账号与权限最小化。删除闲置账号取流账号只给取流权限配置账号只给配置权限管理员账号不用于日常取流。日志集中采集。至少采集三类日志管理面登录、配置变更、账号增删。采集到统一平台后设置告警规则比如非工作时间的登录、同账号多地登录。平台侧组件加固。按依赖清单逐项核对版本关闭危险解析开关配置中心开启鉴权接口层强制校验令牌。固件升级纳入计划。把升级从“出事了才做”变成“按季度滚动做”。这份清单我建议打印出来贴在运维工位上逐项打勾。实测下来全部做完之后一个中型安防园区的暴露面会缩小到原来的十分之一以内且大部分是业务必须保留的通路。4. 授权环境下的验证思路与报告撰写4.1 验证要做到什么程度才算“证据充分”安全圈里有个常见的误区把一个现象截图当作“漏洞证明”。比如看到登录页面返回 200 就断言“未授权访问”但那个页面可能只是个登录壳什么信息都不含。这种结论送到开发那边大概率被打回来。我判断证据是否充分用的是“三要素”标准可复现的操作步骤 可观测的直接结果 明确的边界范围。第一项写清楚从哪个地址、用什么身份、做了哪几步第二项要能看到具体的数据或状态变化比如返回了不该返回的字段、执行了不该执行的操作第三项说明影响的版本范围和前置条件。拿匿名取流这个例子来说合格的证据是在指定网段内对某台设备发起不带凭据的取流请求成功获取到画面同时记录设备型号和固件版本。不合格的证据是只贴一张“能打开页面”的截图不说版本、不说前提条件。对于平台侧的问题验证时更要克制。原则是最小影响能用只读方式验证就不用写操作能用单条请求验证就不批量发送。我见过有人在生产环境上批量触发某个接口做验证结果把服务打崩了这已经超出了授权的边界。注意任何验证动作都要在书面授权范围内执行并在开始前记录时间戳。事后这份记录是保护你自己的重要依据。4.2 报告怎么写才不会被退回写报告这件事我踩过的坑比技术本身还多。最早我写报告喜欢堆技术细节结果开发看不明白后来改成纯业务描述又被安全评审说“证据不足”。最后摸索出一套结构基本上没有被退回过第一段写影响。用一两句话说明“谁能利用、能造成什么后果”。不要写技术名词写业务后果比如“未授权人员可查看指定区域的实时画面”。这一段决定了报告会不会被立刻重视。第二段写范围。明确受影响的资产清单、型号、版本区间以及已验证的数量。范围要精确不能写“全部设备”除非你真的验证过全部。第三段写复现步骤。按操作顺序编号每一步写清楚输入和预期输出。涉及具体地址和账号的做脱敏处理但要保留可复现性。第四段写修复建议。这条最容易写空。“建议加强安全防护”是废话正确的写法是给出可执行动作比如“关闭该接口的匿名访问配置仅允许指定来源地址调用”最好附上配置项名称或文档位置。第五段写验证方式。告诉对方修完之后怎么确认。这一步能大幅减少来回沟通。我整理过一份报告要素表实际使用效果不错模块必须包含常见错误影响描述谁利用、什么后果只写技术名词影响范围资产、型号、版本笼统写“全部”复现步骤编号步骤与预期结果缺前置条件修复建议可执行动作写成口号回归方式验证方法完全省略4.3 修复后的回归验证清单修复完成不等于结束。我做回归验证时会按这份清单走一遍原验证路径重新执行一次确认现象消失检查配置是否已生效而不是只在界面上改了没保存检查同型号的其他设备是否同步修复避免“只修了一台”确认修复没有影响正常业务比如取流账号是否还能正常取流更新台账里的版本和配置记录标注修复时间与修复人。第三项特别容易被漏。批量场景下修复往往只覆盖被报告的那一台剩下的同类设备还在原地。我的做法是在报告里直接附上同型号设备清单让修复方一次改完。第五项看起来是行政工作实际上是资产管理的闭环。没有这一步半年后你再看台账根本不知道哪些修过哪些没修。5. 踩坑记录与常见问题速查5.1 常见问题速查表现象最可能的原因排查动作设备能 ping 通但打不开页面端口未开放或协议不匹配确认端口、确认访问协议页面打开但提示插件不可用浏览器版本与插件不兼容使用匹配版本的浏览器RTSP 取流失败账号权限或地址格式问题核对取流账号与地址格式平台接口返回异常组件版本或配置项问题核对组件版本与鉴权配置升级后功能异常配置未同步迁移恢复配置备份后逐项核对日志里出现异常登录口令泄露或端口暴露立刻轮换口令并收口端口这张表是我平时排查时最常翻的放在手边能省掉大量试错时间。5.2 浏览器打不开摄像头 Web 页面怎么排查这个问题我被问过无数次而且绝大多数时候跟安全没关系纯粹是兼容性问题。经典原因是旧版本的设备 Web 管理页依赖特定类型的浏览器插件来解码视频而新版浏览器默认已经不支持这类插件了。排查顺序我一般这样走先确认网络连通性和端口状态排除最基础的问题再看页面返回的错误信息是超时、拒绝连接还是证书错误如果页面能打开但视频区域黑屏那基本就是插件或解码方式的问题。这种情况下的正确解法是用厂商提供的专用客户端或者匹配的浏览器环境而不是去折腾系统设置。还有一种情况是访问地址写错了。比如把管理端口和取流端口搞混或者用了错误的协议前缀。这类低级错误在实际工作中占比不低建议排查时先确认地址格式再去怀疑更复杂的原因。5.3 夜间全彩灵敏度低、取流地址这类“非漏洞”问题有朋友问过我说设备晚上开全彩模式效果很差怀疑是不是“被入侵了”。这个基本可以排除绝大多数情况下是成像参数的问题。夜间全彩模式依赖补光灯和足够的进光量如果环境光照不足、补光灯功率有限画面自然会噪点多、亮度低。可调的方向包括曝光时间、增益上限、补光策略但这些参数是互相牵制的曝光拉长会拖影增益拉高会噪点增加。实际调参时建议先在固定场景下逐项微调记录每组参数的效果而不是一次性全改。取流地址的问题也是同理。不同型号、不同通道、不同码流类型对应的地址格式不一样主码流和子码流的地址也不同。我习惯的做法是先把地址格式整理成模板标注每个字段的含义需要时按模板拼接而不是每次去猜。这样做的好处是排查问题时能快速定位是格式错误还是权限错误。6. 我个人在实际操作中的几点体会做这一行时间长了我越来越觉得安全工作的核心不是“知道多少漏洞”而是“能不能把基础动作做扎实”。我见过太多团队花大力气研究高级攻击手法却连默认口令都没改干净。真正降低风险的永远是那几件看起来很笨的事资产台账建起来、端口收口、口令轮换、版本跟踪、日志采集。还有一点是关于心态。处理这类问题时不要把“找到问题”当成终点也不要因为没找到高级问题就觉得自己没价值。我做过一次内部自查最后报告里最大的两个发现是“三台设备还在用出厂口令”和“一个管理端口暴露在内网任意可达的位置”技术上一点都不炫但修复之后实际风险下降得非常明显。能把这些平凡的事情持续做到位比偶尔挖出一个漂亮的问题更有意义。如果你现在正准备做一轮自查我的建议是别贪多先选一个网段按第 3 章的流程完整走一遍把台账建起来、把加固项做掉、把验证跑通。走完一轮之后你会对整体情况有非常清晰的判断后面再扩展到其他网段就是复制流程。这套方法我在不同规模的环境里都用过从几十台设备到几千路规模逻辑是一样的区别只在于自动化的程度。