1. 先把漏洞合集这四个字拆开看在群里看到有人求海康威视漏洞合集我的第一反应往往不是去转发一份清单而是先问一句你要这个干什么用。如果是自己手里有一批设备想知道该怎么排查、怎么修那这份合集才有意义如果只是想拿去扫别人的设备那方向从一开始就是错的。这篇东西聊的全部是自有资产的漏洞自查、加固与闭环是运维和安服同学干活时能直接抄的作业不含任何攻击性内容。设备类漏洞和我们平时做的网站漏洞差异其实非常大。网站的洞今天发现明天就能发版修掉一套系统迭代周期是周而一台摄像头、一台录像机、一台视觉控制器采购进来装到墙上之后可能三五年都没人再登录过它的管理界面。固件更新慢、默认配置多、入网之后长期在线、往往没有专职运维盯着——这四个特点叠在一起才是设备类安全问题最真实的土壤。你可以把它理解成网站是天天有人打扫的房间而设备是装完就没人再进的储物间落灰是必然的。更麻烦的是看不见。网站资产通常有域名、有备案、有台账设备资产很多时候根本没有清单。我见过一个园区IT 部门说我们只有二十来台摄像头结果网段一扫出来一百多台多出来的是加装、施工队临时接的、还有几台已经没人认领的旧机器。在不知道设备存在的前提下讨论任何漏洞都是空谈。所以这篇内容的组织方式和常见的漏洞列表不一样。我不按 CVE 编号罗列而是按运维能动手的顺序展开先把资产摸清楚再按风险类型逐个自查然后讲固件、配置、暴露面三块加固最后落到检测、复测和报告。你可以把它当成一份工作流而不是一份清单。2. 盘点先行连设备有几台都不知道谈什么漏洞2.1 资产台账至少要有这十个字段做设备安全第一步永远是台账。不要用 Excel 随手记字段定义要提前想清楚不然后面做不了统计。我一般要求台账至少包含下面这些内容字段说明为什么必须记设备型号完整型号不要简写型号决定固件分支简写会导致找错包序列号 SN机身标签上的唯一编号报修、查授权、确认是否同一台设备固件版本当前实际运行的版本判断是否落后于官方最新IP 与 MAC当前地址与网卡地址MAC 相对稳定换 IP 时能对上所属网段设备所在 VLAN 或物理区域后面做访问控制要靠它开放端口实际监听的服务暴露面收敛的基础数据接入平台接入的 NVR / 平台 / 中间件设备改了平台没改是常见坑是否公网可达是 / 否这一项决定风险等级的天花板责任人谁负责这台设备出问题找谁升级找谁上次升级时间日期判断维护节奏是否正常这十个字段里是否公网可达是最容易被忽略、也最致命的一项。很多单位的安全事件起点就是某台设备被做了端口映射然后一直没人管。2.2 怎么把设备找出来四种手段配合用纯靠人工登记一定会漏实际工作中我是几种手段混着来。第一种是主动发现。用设备发现工具或者交换机侧的 ARP 表、DHCP 租约日志把网段里所有存活主机拉出来再按厂商特征过滤。交换机侧的数据最可靠因为设备只要上线就必然有 MAC 记录。第二种是平台侧反查。如果已经接了 NVR 或统一平台平台里的设备列表往往比人工台账还全。把平台导出的列表和主动发现的结果做一次差集差额部分就是没人认领的设备这部分要重点处理。第三种是物理巡检。天花板上的、机柜角落的、门口的凡是能看到的设备型号和 SN 都拍下来。这一步很土但能发现一些网络层面看不到的老设备。第四种是采购与施工记录。翻合同、翻验收单能补上这台设备是谁买的、什么时候装的这类信息。2.3 台账不是一次性工作要挂在变更流程上我踩过最大的坑是台账做完很漂亮三个月后彻底失真。后来改成两条规则就好多了——新增设备必须登记才能入网任何配置变更或固件升级都要回写台账。技术上可以做得更细一点每周跑一次自动发现把新出现的 IP 和台账做比对有差异就发邮件提醒。听起来麻烦但这是唯一能让台账活下来的办法。台账的价值在于当一份新的漏洞信息出来时你能在半小时内回答两个问题我有没有受影响的型号和版本如果有具体是哪几台、在哪个网段、谁负责回答不了这两个问题再全的漏洞信息对你都是噪音。3. 六类高频问题拆解成因、自查点和修复方向设备类安全问题看起来五花八门但真正高频的就那么几类。下面按我实际遇到的频率排序每一类都讲清楚三件事它是怎么来的、你怎么自己确认、往哪个方向修。3.1 账号体系问题弱口令只是表象很多人把这类问题简单归成弱口令其实背后是一整套账号管理的缺失。常见的表现有四种还在使用出厂默认口令多个设备共用同一个口令离职或外包人员用过的账号没人清理以及账号权限给得太大一个只负责看画面的账号拿着管理员权限。自查方法很直接把设备里所有账号列出来逐个确认用途和归属检查口令策略是否开启翻登录日志看有没有长期不用的账号还在被登录。修复方向上我建议做到一设备一账号、一用途一账号关掉出厂默认账号按角色分配权限看画面只给看画面的权限配置修改单独开账号。提示出厂默认口令在很多型号上是公开信息不要认为知道的人不多就没事。设备入网的第一件事就是改掉它。3.2 服务暴露与未授权访问这类问题的成因通常是图方便。施工的时候为了远程调试随手在路由器上做了端口映射调完就忘了撤销或者某个管理接口本身设计上就没做鉴权只要网络能通就能访问。前一种是配置问题后一种是产品问题但后果一样设备的边界直接被抹掉了。自查的关键动作是从外面看自己。在获得授权的前提下从公网侧对自己单位的出口 IP 做一次端口探测看看有哪些端口真的能从外面连进来。很多单位做完这一步会吓一跳因为暴露的端口比想象中多得多。内网侧则要梳理哪些接口没有鉴权重点是各种查询、状态、配置类接口。修复方向上管理面永远不要直接暴露到公网远程运维走专线或统一的内网运维通道必须对外开放的业务端口也要加访问控制列表只放行确切的来源地址。3.3 配置文件与凭据泄露设备或平台的配置文件里经常明文保存着数据库口令、对接凭据、密钥。如果这个文件被放到了 Web 可访问的目录下或者备份时随手丢在了共享盘里就等于把钥匙挂在了门上。另外一类是编辑器留下的痕迹比如临时文件、备份后缀文件扫描器一抓一个准。自查方式搜索 Web 根目录下是否存在常见备份后缀的文件检查配置文件的存放路径是否在对外目录里确认配置文件里的敏感字段是否做了加密或脱敏。修复上敏感配置不要放在可访问目录备份文件统一收口到受控位置配置里的凭据尽量走密钥管理而不是明文。3.4 鉴权与令牌类问题现在的设备和平台越来越多地采用前后端分离架构登录之后发一个令牌后续请求带着令牌走。这类实现里常见的问题包括令牌有效期设得过长、签名密钥用的是默认值或者很短的字符串、服务端只解码不校验、以及令牌里塞了过多信息。自查方法用浏览器开发者工具看登录后的请求和响应观察令牌的结构和有效期然后测试令牌过期后还能不能用换个账号的令牌能不能访问到不属于自己的数据这类问题。这些测试只在自己的系统上做。修复方向很明确签名密钥用足够长度的随机值并且定期轮换令牌有效期压到合理范围服务端必须完整校验签名和有效期敏感操作要二次确认令牌里不要放权限判断所需的全部信息权限判断永远以服务端数据为准。3.5 组件级问题第三方依赖带进来的坑这一类和前面几条性质不同。它不是设备本身逻辑写错了而是引用的第三方库存在已知问题。典型的是日志组件、XML 解析组件、文件上传组件这几类。设备厂商在集成时往往把版本锁死后续不跟随升级于是问题就一直留在那里。自查方式整理一份依赖清单把产品用到的第三方组件和版本列出来对照官方公告确认是否有已知问题。这一步对最终用户来说很难自己做通常要依赖厂商发布的公告和固件更新说明。修复方向上能升级组件的就升级一时升不了的在边界上加防护规则做补偿比如针对特定请求特征做拦截同时把这类设备的网络位置往内收减少可被触达的路径。3.6 SDK 与集成侧引入的风险很多系统不是直接用设备而是通过 SDK 或者对接手册做集成。集成侧最容易出三类问题SDK 版本太旧、示例代码里的凭据被直接搬到了生产环境、集成中间件的权限给得过大。第三类尤其危险因为它意味着一个中间件被拿下后面一整片设备都受影响。自查动作在代码仓库里全局搜索硬编码的地址、账号、密钥确认 SDK 版本检查集成账号的权限范围。修复上凭据一律外置到配置中心或密钥管理集成账号按最小权限建SDK 定期跟进版本。把上面六类整理成一张表方便你自查时打勾类型典型成因自查动作修复方向账号体系默认口令、共用口令、账号未清理列出全部账号与权限、看登录日志一人一号、最小权限、口令策略服务暴露端口映射未撤销、接口无鉴权从公网侧探测自有出口管理面不暴露、访问控制列表配置泄露明文凭据、备份文件残留查可访问目录、搜备份后缀凭据外置、备份收口鉴权令牌密钥弱、有效期长、只解码不校验观察令牌结构与过期行为强密钥、短时效、服务端校验组件依赖第三方库版本滞后整理依赖清单对照公告升级、边界防护、收敛位置SDK 集成硬编码凭据、权限过大仓库全局搜索、查账号权限凭据外置、最小权限、跟进版本4. 固件与补丁版本落后才是覆盖面最广的那条4.1 先把版本号读明白设备固件版本号通常由几段组成主版本、次版本、构建号有的还会带编译日期或分支标识。很多人看版本只看前面一两位结果同一主版本下不同构建号对应的问题完全不一样。我一般的做法是从设备管理界面里读出完整版本字符串和厂商发布的更新说明逐条比对确认自己落在哪个区间。还有一点要提醒不同硬件版本对应的固件包可能不同。同一型号因为批次不同主板或芯片方案有差异刷错包轻则功能异常重则设备变砖。刷之前一定核对型号、序列号和硬件版本三个信息。4.2 升级前必须做的三件准备升级这件事做对了是维护做错了是事故。我在动手前固定做三件事。第一件是导出当前配置。设备侧导出配置文件平台侧导出对接参数网络侧记录 IP、网关、端口。配置文件导出来之后不要放在公共目录加密存放。第二件是记录回滚路径。确认能拿到当前版本的固件包确认降级是否可行。有些设备只支持向上不支持向下这种情况下升级决策要更谨慎最好先在测试设备上验证。第三件是选好时间窗口。别在工作时间动生产设备尤其是需要连续录像的场景。选业务低峰提前通知使用方准备好停机时长。注意不少设备在固件升级后会恢复部分默认配置升级完一定要逐项核对一遍关键配置包括网络参数、账号、录像计划、对接平台的地址和凭据。4.3 分批灰度别一次刷完一次把几十台设备全刷了是最典型的赌运气。我的做法是按每批三到五台推进第一批挑非关键位置的设备刷完观察二十四小时重点看录像是否连续、平台是否正常显示、远程访问是否正常。没问题再推第二批把关键位置放在最后。这样即使某个批次出问题影响面也是可控的。灰度过程中还要注意一件事升级不是终点。很多人刷完就结束了其实真正的闭环在台账更新和复测。把新的固件版本写回台账把这次升级对应的风险点重新验证一遍才算走完流程。5. 配置加固清单默认值一个都不能留5.1 账号与访问控制这一块的加固顺序是先清理账号再定权限最后定策略。清理账号时把设备默认账号测试账号外包临时账号三类优先处理确认无人使用后禁用。权限按角色划分看画面、回放、配置、导出这四类操作分开授权能只给回放的就不给配置。策略上开启登录失败锁定、开启强制口令复杂度、设置会话超时时间超时到了自动退出登录。5.2 关掉不需要的服务设备出厂往往开着一堆你可能永远用不到的服务。原则很简单用不到就关。常见的包括网络自动发现协议、文件传输服务、文件共享服务、远程命令行。云服务也要按需开如果单位没有使用云端服务的场景就关掉需要用的确认是官方渠道并且配好访问控制。关服务这一步有个配套工作关完之后要记录。写清楚哪台设备关了哪些服务、为什么关、什么时候关的。不然后面别人接手看到服务是关的就随手开回来。5.3 时间同步与日志时间同步看起来是小事实际影响很大。设备时间不准日志时间线就是乱的出了问题根本没法溯源。统一配置时间同步服务器让所有设备时间一致。日志方面我建议至少把登录事件、账号变更、配置修改、设备重启这四类记录下来并且把日志集中收集到统一的日志平台不要只留在设备本地。理由很简单设备一旦被入侵攻击者第一件事往往是清本地日志只有集中收集的日志才留得住。下面是配置加固的核心项可以直接拿去对照加固项建议值备注出厂默认账号禁用或改口令入网即处理账号数量一人一号、按用途分禁止共用权限最小权限按角色划分口令策略复杂度 定期轮换长度优先于复杂度登录锁定开启连续失败即锁定会话超时开启建议不超过 15 分钟无用服务关闭逐个确认用途时间同步统一服务器保证日志可溯源日志集中接入日志平台本地日志不可依赖6. 暴露面收敛取流是刚需但不能裸奔6.1 取流端口为什么最容易被忽略做监控集成取流是绕不开的。只要系统要从设备拿视频流就必然有一个可访问的通道。问题在于方便和暴露往往是一枚硬币的两面为了调试方便很多人直接把取流地址连到公网为了省事取流账号用了管理员账号为了快速对接把账号口令写死在配置文件里。取流这件事本身没问题问题在于用谁的账号、从哪条路径、能拿到什么。我的建议是三条取流用独立的专用账号权限只给取流相关的部分取流请求走内网或受控通道不要直接从公网访问账号口令通过配置管理下发不要在地址里明文拼写凭据。6.2 网络分区是性价比最高的收敛手段如果只能做一件事我会选网络分区。把设备单独放在一个网段业务系统放在另一个网段运维终端放在第三个网段然后通过访问控制策略规定谁能访问谁。具体来说设备网段只能被业务平台和运维网段访问不能主动访问外网业务网段可以访问设备网段的指定端口运维网段访问设备网段要经过审批和审计。这样做的效果是即使某台设备出了问题横向移动的路径也被切断了。相比逐台设备打补丁网络分区的覆盖面更广、维护成本更低。6.3 合理规划访问路径实际部署里完全不暴露和必须远程用经常冲突。我的处理方式是分层日常使用走内网直连远程运维走统一运维通道并且要求有身份验证、有操作记录如果确实有对外提供画面的需求只在业务平台上开一个受控的对外入口不要让用户直接连到设备。设备本身永远待在最里层。7. 从告警到闭环检测、复测和两份报告7.1 日志里到底该看什么日志集中在平台之后最怕的是没人看。我一般设几类告警规则同一账号短时间内多次登录失败、非工作时间的管理登录、账号或权限变更、设备重启、配置被修改、设备从设备网段发起了对外连接。这几类事件单独看不一定都是问题但放在一起看往往能拼出一次异常行为的轮廓。提示告警的误报率要控制在能接受的范围。规则设得太宽一天几百条很快就没人看了设得太严真的异常又漏掉。建议先跑一段时间只记录不告警看基线长什么样再定阈值。7.2 漏洞报告怎么写才有人看报告不是写给自己的是写给要动手修的人的。我见过的失败报告通常有两个毛病一是通篇术语看的人不知道要改哪里二是只说问题不说影响看的人不知道为什么要优先处理。一份能推动修复的报告结构大概是这样部分写什么注意点标题一句话说清问题包含设备类型和问题类型影响范围哪些型号、哪些版本、几台设备给出具体台数和网段问题描述现象的客观描述不夸大不臆测风险等级高 / 中 / 低及判断依据依据要说清楚验证方式如何确认问题存在便于对方复现确认影响分析最坏情况下会怎样结合业务场景说明修复建议具体可执行的步骤给方案不给口号复测要求修完怎么验证明确通过标准7.3 修复报告与复测修完之后要出一份修复报告核心是三个对比修复前的版本和修复后的版本、修复前的配置和修复后的配置、复测前后的结果。每一项都要有可核对的证据比如界面截图、日志片段、版本字符串。复测不是点一下已修复就完事要按原报告的验证方式重新走一遍确认现象确实消失。还有一个容易被忽略的点同类问题要批量处理。报告里写了某型号某版本有问题别只修报告里列的那几台同型号同版本的全部一起处理顺便看看有没有同一类问题的其他表现。8. 这些坑我踩过你可以绕开先说最常见的一个只改了暴露面没改账号。把端口映射撤掉之后觉得安全了结果账号还是出厂默认、还是多人共用。边界收回来了里面的门还是开着的。正确顺序是先处理账号和权限再收敛网络两层一起做。第二个坑升级固件把配置冲掉。前面提过一次这里再说一次因为它真的高频。升级前导出配置、升级后逐项核对特别是对接平台的地址和凭据一旦被重置业务系统会直接失联而且排查起来很费时间因为大家第一反应是网络问题。第三个坑把扫描器的结果当结论直接交上去。扫描器报的高危里有不小一部分是误报也有不少是真问题但风险等级被高估了。直接转发会导致两种情况要么对方修了几个发现没用要么真正重要的问题被淹没在一堆噪音里。我一般会把扫描结果做人工确认再出手确认的动作本身也算对报告负责。第四个坑只处理高危中低危一直堆着。很多事故的入口并不是那个被标成高危的洞而是一堆中低危叠在一起形成的通路。比如一个信息泄露接口加上一个弱口令单独看都不算致命合起来就是一条完整路径。我的做法是把所有中低危也录入跟踪表按季度清理至少要做到有结论——要么修掉要么书面接受风险。第五个坑备份文件忘了清。配置文件导出、日志打包、数据库备份做完测试之后随手留在服务器上后面就没人记得了。这类文件往往包含敏感信息是最容易被遗漏的暴露点。建议养成习惯任何导出动作结束当场清理临时文件只保留收口到受控位置的那一份。第六个坑改了设备没改平台。设备侧收紧了口令和权限平台侧的对接账号还是老的或者反过来平台升级了但设备侧没动。设备系统和平台系统是一个整体任何一侧的变更都要同步另一侧并且回到台账上做记录。最后分享一个我自己用的小办法把每个季度固定成设备体检周。这一周里集中做三件事——更新一次资产台账、按加固清单抽查一批设备、把所有未闭环的风险过一遍。不求一次全做完只求节奏不断。设备类的安全工作靠的不是某一次大规模整改而是长期、稳定、有人负责的日常维护。