通过一个本地的RTSP/ONVIF控制项目，展示低成本IP摄像头的实用性和固有的安全隐患

消费级IP摄像头通常以支持云连接的设备形式出售。

你安装供应商的应用程序，创建账户，配对设备，从那一刻起，相机就成为了他人生态系统的一部分。

我想回答一个简单的问题：

低成本的Tenda CP3摄像头能否在本地使用，而无需依赖供应商的云服务?

答案是肯定的。

Tenda CP3 提供本地 RTSP 和 ONVIF 服务，可实现：

•本地视频流媒体

•媒体资料发现

•PTZ 控制

•设备信息检索

•安全行为验证

实际上，这款相机在技术上并非仅限于云服务。

这是一款功能强大的嵌入式Linux设备，其上叠加了一个受限的消费级接口。

项目目标

本项目的目标并非利用或绕过任何事物。

目标是验证是否能够使用标准协议，将个人拥有的Tenda CP3相机集成到本地自托管环境中。

目标架构是：

这使得相机可以在家庭实验室或私人监控系统中使用，而无需直接暴露在互联网上。

硬件已测试

测试的设备是：

•制造商：Tenda

•型号：CP3V3.0

•固件版本：V31.1.9.63

•硬件ID：V1.0

此信息是通过ONVIF直接从设备获取的。

网络发现

第一步是扫描本地网络上的摄像头。

完整的TCP扫描显示了多个暴露的服务：

•22/tcp SSH Dropbear

•23/tcp Telnet BusyBox

•80/tcp HTTP

•554/tcp RTSP

•8000/tcp ONVIF / SOAP SOAP SOAP 端点

这已经很有趣了。

对于一款低成本的消费级相机来说，这是一个相当宽广的局部曝光区域。

该项目的重要服务包括：

•554/tcp 用于 RTSPSP 视频

•ONVIF SOAP SOAP SOAP 端点用于设备管理、媒体发现和 PTZ 控制

RTSPSP 流媒体

摄像头可显示正在运行的RTSP流。

通过ONVIF媒体发现，识别出以下配置文件：

ProfileToken_主流

ProfileToken_子流

它们映射到：

主流提供最高品质。

子流的分辨率较低，更适合交互式控制，因为它具有更低的延迟和更低的解码成本。

使用 `ffprobe`` 进行简单的验证确认了该流：

流体特性如下：

•RTSP服务器：ZNRTSPServer

•视频编码：HEVC / H.265

•分辨率：2304x1296

•帧率：20 FPS

•音频编解码器：PCM A-law

•音频采样率：8000 Hz Hz 单声道

这证实了该设备无需使用厂商云即可提供真实的本地视频流。

ONVIF 发现

该摄像头支持多种ONVIF服务：

•设备管理

•媒体服务

•PTZ 服务

•影像服务

•活动服务

•分析服务

使用 ONVIF 设备管理服务来获取设备信息和功能。

媒体服务用于获取可用的配置文件和RTSP URI。

PTZ服务用于在本地移动摄像机。

这是使用 Python 和 onvif-zeep 实现的。

本地PTZ控制

一旦发现媒体配置文件，就可以使用PTZ服务来移动摄像机。

已验证的运动：

•向左转

•向右移动

•向上倾斜

•向下倾斜

实现时先使用 ONVIF 的 `ContinuousMove`，然后执行 `Stop`。

为了手动控制，我创建了一个基于键盘的PTZ控制器：

这使得相机更容易精确控制。

交互式演示模式

为了便于演示项目，我编写了一个单一的脚本：

脚本做了两件事：

1. 在当前 shell 中启动低延迟 RTSP 播放

2. 打开第二个终端，使用键盘PTZ控制器

这创建了一个简单的本地操作员控制台。

视频流由 `ffplay` 处理。

PTZ控制器由Python和ONVIF控制。

低延迟RTSP播放

默认的RTSP播放导致延迟过高，影响了PTZ的舒适控制。

经过测试多种组合后，最佳的实用配置是：

关键细节如下：

保持音频启用可改善感知延迟。

这看似不合常理，但却可以重复验证。

ffplay 使用音频流作为同步时钟。启用音频后，PTZ控制过程中的视频反馈变得响应更快。

没有音频时，仅视频流的播放容易出现缓冲，且在移动过程中摄像头感觉迟缓。

对于交互式控制，建议使用子流：

用于观察或记录时，主流效果更好：

测试过程中出现了一种重要行为。

相机似乎对同时初始化协议较为敏感。

如果RTSP回放和ONVIF PTZ连接在完全相同的时间开启，ONVIF可能会出现以下错误：

连接已中断

错误状态行

这表明嵌入式固件在并发会话启动方面存在问题。

演示脚本通过按顺序启动来缓解此问题：

1. 先开始RTSP播放

2. 稍等几秒钟

3. 启动 ONVIF PTZ 控制器

这使得演示变得稳定且可重复。

安全观察

该项目还收集了若干与安全相关的观察结果。

相机曝光：

其他观察：

•RTSP流量未加密

•ONVIF 通过普通 HTTP 运行

•ONVIF未暴露TLS支持

•HTTP 重定向到 HTTPS，但端口 443 的 HTTPS 无法访问

•默认凭据仍然有效

•SSH 已暴露

•Telnet 已被暴露

这就是为什么我不会将此设备连接到可信网络。

安全态势：实用但本质上不可信

从这个项目中可以得出一个重要结论：低成本的消费级物联网摄像头应被视为本质上不可信的设备。

Tenda CP3 本地暴露 RTSP 和 ONVIF 的事实有助于互操作性，但也凸显了这类设备所面临更广泛的安全问题。

测试期间，相机曝光了：

•工厂默认凭据

•RTSP 通过明文传输

•通过普通HTTP实现ONVIF

•SSH

•Telnet

•用户管理行为不一致

•没有有效的本地TLS保护

这并不意味着该设备毫无用处。

这意味着它只能在正确的语境中使用。

这种设备可能适用于以下情况：

•非关键监控

•家庭实验

•本地自动化

•智能镜像集成

•临时视频检查

•独立的业余项目

不应将其用作关键环境中可信赖的安全组件。

我不会将这类摄像头直接连接到可靠的局域网，也绝不会将其直接暴露在互联网上。

正确的做法是隔离。

更安全的部署模式是：

在实践中：

•摄像头应仅与受控的本地主机通信

•应阻止RTSP和ONVIF从网络其他部分访问

•不应允许入站互联网访问

•远程访问应通过 Tailscale 等 VPN 实现

该设备应被视为可更换且不可信的。

主要的教训不仅仅是相机可以本地控制。

教训是，本地控制必须与适当的网络隔离相结合。

廉价的消费级物联网设备通常功能强大，但很少被设计成具备强大的安全防护能力。

该项目不会使设备变得安全。

这使得设备更易于理解、控制，并能更准确地进行隔离。

默认凭据和用户管理

本项目中显示的凭据并非泄露的私人信息。

这些是测试期间发现的工厂默认凭据，其持续存在属于本项目中记录的安全问题。

测试的凭据如下：

他们曾为以下机构工作：

•RTSP 访问

•ONVIF 访问

然而，密码并未得到有效更改。

专用脚本验证了此行为

该测试执行：

1. 使用已知的有效凭据登录

2. 调用 ONVIF `SetUser()`

3. 测试新密码

4. 再次测试原始密码

观察结果：

•SetUser 返回 OK

•新密码设置失败

•旧密码仍然有效

这表明 ONVIF 用户管理不完整、无效，或与摄像头实际使用的认证后端脱节。

RTSP质量说明

RTSP 流可以正常工作，但实现并不完美。

在实时播放过程中，可能会出现解码器警告：

rtsp：CSeq 期望值不匹配

hevc：重复的POC

hevc：未找到具有POC的参考

解析NAL单元时出错

流媒体仍然可以正常播放。

这通常是低成本嵌入式RTSP实现的典型特征：功能完整，但不一定完全符合标准。

仓库结构

项目仓库包含：

•主脚本：

•启动实时视频和键盘PTZ控制

•交互式键盘PTZ控制器

•收集服务暴露和协议证据

•检索 ONVIF 设备信息和功能

•验证 ONVIFIF 密码更改行为

运行演示

安装依赖项：

创建 Python Python Python 虚拟环境：

验证 ONVIF 依赖关系：

运行交互式本地演示：

示例：

结论

Tenda CP3 在技术上并非仅限于云端的设备。

它暴露了标准的本地协议，允许：

•RTSP视频访问 - ONVIF发现

•ONVIF PTZ 控制

•本地集成到自托管环境中

硬件性能比官方产品体验所暗示的要强大。

云依赖似乎主要是一个产品层的设计决策。

同时，从安全角度来看，该设备应受到谨慎对待。

默认凭据、暴露的 Telnet/SSH、普通的 HTTP ONVIF 以及不一致的用户管理，使得网络隔离成为必要措施。

对于我的使用场景，合适的架构是：

这提供了本地控制的优势，而无需直接信任摄像头。

这个设备虽然有用，但绝不能轻信。

本地控制使其更加灵活，但必须确保适当的隔离。

本文编译自hackster.io