摄像头安全自查与加固：从海康威视漏洞合集到长期管理

1. 摄像头设备为什么总在安全问题里上榜做弱电和安防运维这行的朋友大概率都遇到过同一个场景客户单位的内网里有几十上百台网络摄像机装好之后几年没人动过默认密码没改固件版本停留在出厂那一版摄像机直接挂在能通外网的路由器下面。等到某天被上级单位的安全检查点名才慌慌张张来找人处理。海康威视漏洞合集这个说法其实在圈子里流传了很多年。它指的并不是某一份官方发布的漏洞清单而是从业人员在长期运维和检测过程中把这类网络摄像机、NVR、CVR、平台软件上反复出现的一系列同类风险总结成的话题合集。这些风险有个共同特点单个技术点看起来都不复杂但它们扎堆出现在同一类设备上而且这类设备数量极多、部署极分散、生命周期极长于是整体风险被成倍放大。这篇文章我打算换个角度来写。不写哪里有漏洞、怎么打进去那是对着别人的资产动手越过线了。我写的是防御侧的自查视角假设你就是那个要对自己负责的资产做体检的人面对一整套摄像头和存储设备怎么把底账摸清楚、怎么判断哪些地方存在风险、按什么顺序加固、踩过哪些坑。这套方法对单位的系统管理员、集成商工程师、安全运维岗都适用哪怕你手上只有几台家用级别的设备也能照着走一遍。本文适合谁看手里有摄像头资产需要交付或维护的工程师被要求出具设备安全整改报告的运维人员想了解物联网设备安全基本盘的入门者。不需要你是渗透测试高手但需要你会基本的网络命令和一点点脚本能力。1.1 一张照片背后的暴露面到底有多大先说个数字感受一下。这类设备在公网上能被搜索引擎检索到的数量长期维持在百万量级而且这个数字并不是因为设备多而是因为配置习惯导致的。我见过太多项目交付时的默认操作施工队把摄像机装好交换机一插路由器上开个端口映射方便远程看画面然后密码还是默认的或者统一设成 123456全单位的设备用同一个。这个习惯带来三个连锁反应。第一暴露面从内网扩展到了公网任何能扫端口的人都能发现它。第二认证强度被拉到最低弱口令在批量爆破面前几乎等于没有。第三横向风险因为密码统一攻破一台往往意味着同一批设备全部失守。所以谈风险之前先问自己三个问题我这些设备有几台能从公网访问它们的口令强度如何它们的固件版本是哪一年的这三个问题答不上来后面所有的加固都是空谈。1.2 高发问题的三个共性根因把历史上反复出现的问题归类根因其实就三条理解这三条你能自己推导出大部分风险点不用死记清单。第一条根因是出厂即能用的设计取舍。设备为了降低部署门槛出厂时一定带着可用的默认账号Web 服务、RTSP 服务、ONVIF 服务、SDK 服务默认全部打开。这在封闭内网里是便利一旦接入更大网络就变成了默认攻击面。任何一次交付只要没人主动去关这些服务就一直开着。第二条根因是鉴权逻辑不统一。同一个设备上Web 后台的鉴权、RTSP 取流的鉴权、SDK 接口的鉴权、ONVIF 的鉴权是几套独立实现的代码路径。只要其中一条路径的校验写得松一点——比如某个接口只检查了会话 cookie 的有效性却没校验权限、某个请求参数可以绕过校验——整机就等于被开了后门。历史上大量所谓越权未授权访问类问题本质都是这条根因。第三条根因是更新链路断裂。设备装到墙上之后很少有人再去管固件。厂商发了新版本集成商不知道客户更不知道。一台设备的安全水平在出厂那一刻就定格了而攻击手法每年都在进步。这个时间差就是风险的温床。注意以上三条根因的推导基于我参与的多个安防项目交付经验是常见实践的归纳不代表某一具体型号的实际实现。2. 高发风险分类拆解与自查方法接下来按类型拆开讲。每一类我都给你判断方法——不是怎么打而是怎么看出来自己有没有这个问题。这才是运维真正需要的。2.1 身份认证类弱口令、默认账号与越权这是最常见、危害也最直接的一类。具体表现有三层从浅到深第一层口令本身太弱。出厂默认口令、纯数字口令、设备型号年份这类规律口令都在批量尝试的射程内。自查方式很简单把设备清单拉出来看看有多少台用的是初始口令有多少台的口令长度低于 12 位、不含大小写和符号。第二层认证机制本身有缺陷。比如登录失败没有锁定、没有验证码、没有频率限制理论上可以无限次尝试。这类问题的自查方法不太直观需要看设备的管理界面连续输错几次密码看它是否出现锁定或延迟。如果没有就要通过其他手段补——比如在网络层做访问控制别让登录接口随便可达。第三层越权访问。这是最隐蔽的一类。表现是某个接口在已登录的低权限账号下能读到本不该读的数据或者能改本不该改的配置。还有一种形式是接口设计时只校验了是否携带凭证没有校验凭证是否属于这个对象。自查这类问题最朴素的办法是做权限矩阵演练建两个账号一个管理员、一个普通操作员用操作员账号去逐项点一遍管理菜单看有没有能进去的。再配合接口层面的检查——如果你们有开发能力抓一遍后台的请求把请求里的会话标识换成另一个账号的看服务端认不认。实操心得很多单位只改 Web 后台的密码忘了改 RTSP 取流和 ONVIF 的密码。这几个服务的凭证在某些设备上是独立的改一个不影响另一个。交付验收时一定要逐个服务验证。2.2 网络服务与接口暴露类RTSP、ONVIF、SDK 与 Web 后台一台网络摄像机对外提供的服务比很多人想的多常见的至少有这些服务默认端口用途风险点Web 管理80 / 443 / 8000浏览器配置界面弱口令、越权、接口未授权RTSP 取流554视频流拉取明文传输、口令可爆破、地址规律可猜ONVIF80 / 8080设备发现与控制认证强度不一、部分实现允许匿名探测SDK 服务8000 / 自定义二次开发对接端口固定、协议明文、接口权限颗粒度粗存储设备后台视型号而定NVR/CVR 管理默认账号、后台可达性服务端口自定义平台软件通信未授权访问、组件版本老旧RTSP 地址是有规律的这是运维常识也是风险点。海康设备的取流地址通常是rtsp://用户名:密码设备地址:554/Streaming/Channels/101这样的结构主码流是 101子码流是 102。地址结构公开、端口固定、凭证直接明文写在 URL 里——这三点加起来意味着只要口令能被猜到视频流就是敞开的。而且 RTSP 本身不做加密传输同一网段里只要有抓包能力画面就是裸奔的。自查方法从外部网络尝试访问设备的 554、8000 端口看看是否可达。可达就是问题不管口令强弱先把可达性收掉。2.3 配置与固件类加密存储、升级链路与隐性账号设备上存着配置文件里面有网络参数、账号信息、平台对接凭证。这类文件通常是加密或者编码存储的这是合理设计——毕竟厂商也不希望用户的凭证被随便读走。但这里面有个必须说清楚的原则配置文件的加密强度取决于密钥管理而不是取决于算法本身。如果一份配置文件的解密逻辑完全在设备本地、密钥硬编码在固件里那么拿到固件的人理论上可以还原出配置内容。这就是为什么网上会有各种配置文件处理工具流传。我不打算在这里展开这类工具的任何细节。作为运维方你真正该做的是不要让配置文件离开设备备份文件保存在受控的存储里不要随手发到聊天工具里不要放在共享盘上。这才是控制风险的正确姿势。固件这条线更值得花时间。检查三件事当前固件版本是多少用设备信息接口或者后台的版本页面确认记录型号版本号厂商官网有没有更新的版本定期比对升级通道怎么走是本地导入固件包还是通过平台批量升级升级过程中断怎么恢复。还有一类是隐性账号厂商为了售后维护预留的账号、设备出厂时的服务账号、第三方平台对接时创建的账号。这些东西往往不在资产管理台账里但它们是实实在在存在的入口。自查办法是定期导出设备上的账号列表跟人员名单比对把无法对应到具体责任人的账号全部清理。2.4 前端与插件类浏览器端的老问题这一类问题很特别因为它不影响设备本体的安全但影响使用体验而且经常被误判成设备坏了。典型现象是在浏览器里输入摄像头地址页面加载了但视频区域一片空白或者提示要安装插件。原因是很多设备的 Web 界面依赖 NPAPI 类型的浏览器插件来解码视频流而这个插件机制在主流浏览器的新版本里早就被移除了。这就是浏览器打不开海康威视摄像头这个搜索词背后的真实原因绝大多数情况下不是故障是兼容性。处理办法有这么几条一是使用厂商提供的专用客户端或者新版插件方案二是使用厂商推出的浏览器扩展来承接解码工作三是在设备侧启用不依赖插件的播放方式比如 RTSP 转 WebRTC 的中间件方案四是退回较老的浏览器内核环境但这只能作为临时手段不能长期依赖。自查清单设备固件是否支持新版插件体系现场使用的浏览器版本与插件是否匹配是否有 HTTPS 证书问题导致页面加载不完整端口是否被改过URL 是否需要带端口号。2.5 一张速查表把设备风险梳理清楚把上面四类合并成一张表你可以直接拿去对照自己手上的资产检查维度具体动作合格标准不合格的处理口令强度导出账号清单逐一核对无默认口令长度 ≥ 12 位含多字符类型立即重置禁止批量复用同一口令服务可达性从外网检测 80/443/554/8000全部不可达关闭映射改走内部访问通道固件版本记录型号版本与官网比对在厂商支持的版本区间内制定升级计划分批执行账号台账导出设备账号与人员名单比对每个账号能对应责任人清理无人认领账号日志能力检查登录、配置变更是否留痕关键操作有记录且可导出接入集中日志或定期导出网络分区确认设备网段与办公网隔离设备在独立 VLAN调整网络架构3. 从零搭建一套可复用的资产自查流程上面讲的是看什么这一章讲怎么做。这套流程我在几个项目里跑过从几十台到上千台的规模都适用区别只在于要不要脚本化。3.1 第一步把资产底账摸清楚这是最容易被跳过、也最不能跳过的一步。没有底账后面所有工作都是盲人摸象。底账要记的字段至少有这些设备型号、序列号、安装位置、IP 地址、MAC 地址、固件版本、责任人、所属网段、用途分类点位摄像机/存储设备/平台服务器。获取方式有几种一是通过平台的设备管理功能批量导出这是最省事的前提是设备已经接入平台二是通过交换机或者路由器的 ARP 表、DHCP 租约记录反推在线设备三是用扫描工具在授权网段内做主机发现。第二步和第三步有前提必须是你有管理权限的网段。在别人的网络里做扫描哪怕只是主机发现也是不该做的事。这个边界要守住。提示资产底账建议做成表格并纳入变更流程新装、拆除、换机都要更新。我在一个项目里见过台账落后实际部署两年多的情况结果排查时发现十几台设备根本不在名单上。3.2 第二步端口与服务测绘的正确姿势有了 IP 清单下一步是搞清楚每台设备开了什么服务。这一步的目的不是找漏洞是确认哪些服务不该开。在自有网段内可以用常规的端口扫描方式对设备做服务识别。重点看这几个端口的状态80、443、554、8000、8080以及厂商文档里提到的其他通信端口。扫描结果整理成表格跟应该开放的服务做对比多出来的就是待处理的暴露面。这里有个经验很多设备在实现上会开一些文档里没写的辅助端口用于设备发现、时间同步、平台注册。这些端口往往也没做严格鉴权。发现这类端口不要急着下结论先查厂商的对接手册确认它的用途再决定是关闭还是加访问控制。3.3 第三步用脚本批量核对固件与配置设备多了之后一台台点开后台看版本号是不现实的。这时候需要脚本。合规的做法是调用厂商公开的设备信息接口或者用厂商官方 SDK 封装的接口去读取设备的基本信息。下面给一个思路性的脚本骨架用的是厂商 Web 接口的常规调用方式仅用于读取设备信息不做任何修改动作import requests from requests.auth import HTTPDigestAuth # 仅对自有或已获书面授权的设备执行此脚本 DEVICE_LIST [ {ip: 192.168.1.64, user: admin, pwd: 此处填你的口令}, # 按实际清单补充 ] def get_device_info(ip, user, pwd, timeout5): url fhttp://{ip}/ISAPI/System/deviceInfo try: resp requests.get( url, authHTTPDigestAuth(user, pwd), timeouttimeout ) if resp.status_code 200: return resp.text return fHTTP {resp.status_code} except requests.exceptions.RequestException as e: return f连接失败: {e} if __name__ __main__: for dev in DEVICE_LIST: info get_device_info(dev[ip], dev[user], dev[pwd]) print(f[{dev[ip]}] {info[:200]})这段代码的价值在于批量和留痕跑一遍就能拿到所有设备的型号和版本信息输出结果直接进台账。要扩展的话可以把返回内容解析成结构化的字段自动跟最新固件版本对照生成待升级清单。需要注意两点一是不同型号的设备接口路径和认证方式可能不一样摘要认证和基础认证都要试二是脚本里的口令不要硬编码在文件里长期保存测试完就清掉生产环境应该走密钥管理。3.4 第四步加固动作清单与执行顺序加固不能想到哪做到哪顺序错了会造成业务中断。我建议按这个顺序推进先做不影响业务的。关闭公网映射、关闭多余服务端口、清理无人认领账号、调整日志级别。这些动作不会导致画面丢失但对风险的削减最直接。再做影响可控的。统一重置口令这个动作会导致正在使用旧口令的客户端掉线所以要提前通知选在业务低谷期执行。重置之后第一时间更新所有对接方的配置——上级平台、存储设备、第三方系统一个都不能漏。最后做需要计划的。固件升级必须分批做先拿一台非关键点位试观察一周再推全量。升级前要备份配置升级后要验证取流、录像、平台对接三项功能。注意设备升级和口令重置这两件事是导致升级完就联系不上设备的高发原因。执行前一定要确认你手上有带外访问手段或者现场有人能配合断电重启。4. 常见问题与排查技巧实录这一章是纯经验都是我或者身边同行实际遇到过的。4.1 现场现象速查表现场现象可能原因排查顺序浏览器打开页面但视频区空白解码插件未安装或浏览器不支持换用厂商客户端 → 安装对应插件 → 检查固件是否支持新版方案输入地址显示无法访问端口被改、IP 变动、服务未启动ping 通断 → 扫描端口 → 查设备实际配置平台显示设备离线但能 ping 通平台注册端口不通、凭证失效查注册配置 → 核对账号口令 → 查防火墙策略部分设备时间与实际不一致时间同步源不可达检查 NTP 配置与网络可达性设备频繁掉线重启供电不稳、固件异常、网络环路查电源 → 查固件版本 → 查交换机端口状态夜间移动侦测响应变慢侦测灵敏度与补光模式不匹配调整灵敏度阈值 → 核对补光模式与场景适配关于最后一条展开一句夜间全彩模式下侦测灵敏度下降是很常见的现场反馈。原因是全彩模式需要持续补光传感器的曝光参数、增益参数都跟白天不同算法对画面变化的判定阈值也要相应调整。处理方向是调整侦测区域划分、调整灵敏度档位、评估补光方案是否与安装环境匹配。这跟安全漏洞没关系属于产品调试范畴但很多人在搜索时会把两类问题混在一起这里顺手澄清一下。4.2 我踩过的几个坑第一个坑以为改了 Web 密码就万事大吉。有个项目后台密码改得很规范但 RTSP 的凭证还是出厂值。后来做自查才发现取流这条路完全是敞开的。教训是凡是能认证的地方都要单独验证一遍不要假设它们共享凭证。第二个坑升级固件后配置被重置。有一次升级完设备的网络参数恢复了出厂值因为 IP 是静态配置的设备直接失联。后来我们定了规矩升级前必须导出配置文件升级后逐项比对网络、账号、平台对接三项配置。第三个坑把通用组件漏洞和摄像头风险混为一谈。圈里经常有人搜某某组件漏洞然后往摄像头上套。实际情况是绝大多数网络摄像机跑的是嵌入式系统根本不带通用应用服务器环境那些组件级问题跟它们没关系。真正该关注的是设备自己的服务实现。分类要清楚不然时间全浪费在错误的方向上。第四个坑忽略日志。很多设备的日志功能默认级别很低登录失败、配置变更都不记录。等到出事了想回溯什么都查不到。后来我在交付清单里加了一条必须确认登录和配置变更两类事件有记录并且能导出保存。第五个坑资产台账和实际部署脱节。有的设备是临时加装的没进台账出了事才发现。解决办法是把台账更新写进变更流程谁装谁登记不登记不给验收。4.3 关于风险报告的写法不管你是做内部整改还是对外提交报告的质量决定别人愿不愿意处理。一份能推动事情的报告至少要包含这几块内容资产标识设备型号、固件版本、部署位置、责任部门越具体越好问题描述用运维能听懂的话讲清楚现象不要只丢一个术语影响判定这个问题被利用后会带来什么后果是画面泄露、配置被改还是设备失联复现条件在什么前提下能触发需不需要特定网络位置修复建议给出可执行的动作最好分临时缓解和根本解决两步验证方法修完怎么确认修好了。我见过太多报告只写了第二项结果收报告的人看不懂、不敢动事情就搁置了。把怎么验证写清楚处理意愿会高很多。5. 把一次性排查变成长期管理自查做完不等于结束。设备网络的风险是动态的今天关掉的端口明天可能因为一个临时需求又被打开。所以最后聊聊怎么把这件事变成常态。5.1 变更管理让每一次改动都留痕核心原则是一句话任何对设备网络、账号、服务的改动都要有记录、有审批、有回退方案。具体落地可以这么做建立一份变更记录表字段包括变更时间、执行人、涉及设备、变更内容、变更原因、回退方式。临时开放端口必须设定有效期到期自动回收。账号创建必须绑定责任人人员离职时同步清理。这套东西听起来麻烦但比起出事后排查的代价成本低得多。我在一个单位推行之后最直观的变化是再也不会出现这台设备是谁装的、为什么开着这个端口这种没人答得上来的问题。5.2 网络分区把设备关进该在的地方技术上最有效的一招是把设备网络和办公网络、互联网彻底分开。推荐的结构是设备单独一个 VLAN通过防火墙或访问控制策略限制进出流量只允许必要的通信——比如平台服务器到设备的注册和取流、运维终端到设备的配置访问。运维访问走内部通道不直接从互联网进入。这样做的好处是即使某台设备存在认证层面的问题攻击面也被限制在设备网段内很难扩散到其他地方。这是纵深防御思路在物联网场景里的直接应用不指望每个环节都完美而是让单点失守不至于全盘崩溃。如果确实需要远程查看画面优先走内部平台的中转方式由平台统一对外提供服务而不是让每台设备各自对外暴露。平台侧可以集中做认证加固、访问日志、权限控制管理成本远低于管理几百台分散设备。5.3 我个人的一点体会干了这些年我最大的感受是设备安全这件事八成的问题出在流程上两成出在技术上。技术上能做的事情其实很明确——改口令、关端口、升固件、分网络、留日志。这五件事做完能覆盖绝大多数常见风险。难的是让这五件事在设备装到墙上的那一刻就发生并且在之后的五年里持续发生。所以我现在的习惯是把安全检查做成交付流程的一部分设备上架时必须完成口令初始化、服务收敛、固件登记、台账录入缺一项不签字。听上去很笨但这是唯一能让事情真正落地的方式。还有一个很小的技巧分享给做现场交付的朋友在设备标签上写清楚初始化日期和当时的固件版本。我在几个项目里推广了这个做法后来复查时效率提升非常明显——不用登录设备就能判断这台机器是不是该升级了。这个内容往后还能扩展的方向也很清楚把设备台账和网络监控打通端口状态一变就告警把固件版本比对做成定期任务有新版自动提醒把账号台账和人员系统对接离职即清权。这些都不复杂但需要在流程上先立住技术才有落点。