企业官网建设流程全解析

先说个背景。最近在给一套基于EasyNVR的安防视频接入平台做例行安全巡检，扫描器报了一个高危项：服务端TLS配置中仍启用了3DES加密套件。这类问题在流媒体服务里其实挺常见的，EasyNVR本身负责RTSP拉流、转码、H5页面播放，对外暴露的HTTPS端口走的是内置Nginx，弱加密套件一般就藏在Nginx的SSL配置里。我这边从漏洞确认到修复完成、再到验证通过，前后花了大半个工作日，把过程整理出来，给遇到同样告警的朋友做个参考。

1. 先搞清楚3DES漏洞到底是什么

1.1 3DES加密算法的问题出在哪

3DES是Triple DES的简称，本质上就是把老的DES算法跑三遍，用三个不同的密钥来增加密钥长度。DES本身是1970年代设计的算法，密钥只有56位，分组长度只有64位，放到今天已经非常脆弱。3DES虽然把密钥长度提到了112位或168位，但它的分组长度仍然是64位，这成了它最大的软肋。

问题就出在这个64位分组长度上。如果加密的数据量足够大，碰撞攻击（也就是常说的Sweet32攻击）就能在约320亿次查询中恢复出部分明文信息。这个攻击需要的条件虽然苛刻——攻击者需要截获大量加密流量，但对于HTTPS这种长期保持连接、不断传输数据的场景，理论上是可行的。所以业界在2016年Sweet32攻击公开之后，就基本把3DES判了死刑，PCI DSS等合规标准也明确要求禁用。

放在EasyNVR的场景里，如果管理后台和视频播放页面的HTTPS握手仍然支持3DES套件，扫描器就会直接命中这条告警。实际业务影响倒不是说马上会被攻击，而是等保测评或客户的安全检查这一关过不去，必须整改。

1.2 扫描器为什么会报这个漏洞

安全扫描器检测3DES的逻辑很直接：建立TLS连接时，把自己支持的加密套件列表发给服务端，如果服务端选择了3DES系列套件，就判定为存在风险。常见的扫描器比如Nessus、OpenVAS或者国内一些合规检查工具，检测项里都有SSL/TLS弱加密套件这一条。

EasyNVR的HTTPS端口通常默认是8443或443，具体看部署配置。扫描结果里会明确标出检测到的3DES套件名称，常见的有这几种：

扫描报告里看到任何一个，都说明Nginx的ssl_ciphers配置里没有把3DES排除干净。接下来就是定位配置、确认影响面、动手修复。

2. 漏洞影响面分析与修复思路

2.1 先评估影响范围，别急着改配置

修复之前，我习惯先做一次影响面评估，搞清楚这套EasyNVR对外暴露了哪些端口、哪些业务走了HTTPS。一般来说EasyNVR会有这几个入口：

• 管理后台Web界面，走HTTPS 8443端口；
• H5视频播放页面，走HTTPS 8443端口；
• API接口（登录、获取设备列表、拉流地址生成等），同样走HTTPS；
• 流媒体分发走RTSP/RTMP或HTTP-FLV，这部分不涉及TLS，但也有部分场景会走WebSocket over TLS。

所以3DES漏洞影响的主要是管理后台和H5播放页面的HTTPS握手过程。攻击者如果处在中间人位置，理论上可以降级握手、尝试破解加密流量。对于安防监控这种对安全要求高的场景，整改是必须的，不能拖。

另外要确认一点：EasyNVR内置的Nginx版本是多少。因为我实际遇到过老版本EasyNVR捆绑的是比较旧的Nginx和OpenSSL，有些新配置语法和老版本不兼容。这个决定了后面配置怎么写、TLS版本能开到多高。

2.2 修复方案的选型逻辑

修复3DES漏洞，核心就一句话：在Nginx的SSL配置里，把3DES套件从密码套件列表中排除，同时配置更安全的套件列表和TLS版本。

这里有个常见的误区：以为把ssl_ciphers改成HIGH:!aNULL:!MD5就够了。实际上HIGH这个关键字在老版本OpenSSL里是包含3DES的，必须显式加上!3DES或者用一套明确的现代套件列表。我这次采用的是配置明确套件列表的方式，不依赖OpenSSL的关键字分组，这样无论扫描器怎么变化，返回的套件清单都是可控的。

同时要把TLS版本限制在TLSv1.2和TLSv1.3，关闭TLSv1.0和TLSv1.1。这两个旧版本本身就是扫描器常报的低版本协议问题，顺手一并解决，避免下次扫描又冒出新的弱协议告警。

修复的整体步骤是这样的：

1. 备份原始Nginx配置文件；
2. 确认EasyNVR使用的Nginx配置路径；
3. 修改ssl_protocols和ssl_ciphers配置；
4. 校验配置语法并重新加载；
5. 用openssl和nmap做修复验证；
6. 回归测试管理后台和视频播放是否正常。

3. 修复3DES漏洞的完整实操过程

3.1 定位EasyNVR的Nginx配置

EasyNVR的安装目录通常是/usr/local/easynvr或者/home/easynvr，具体看你是用安装包部署还是Docker部署。我这次遇到的是一台CentOS 7上的传统安装包部署方式，Nginx配置在安装目录下的conf/nginx.conf。

先找到EasyNVR的进程，确认Nginx的配置文件路径：

# 查看EasyNVR相关进程 ps aux | grep -E "easynvr|nginx" # 如果看到nginx进程，用 -V 或 -T 参数查看配置路径 /usr/local/easynvr/nginx/sbin/nginx -V 2>&1 | head -n 2

输出的--conf-path参数会直接告诉你配置文件位置。如果没有这个信息，也可以在EasyNVR的安装目录下用find命令搜：

find /usr/local/easynvr -name "nginx.conf" -type f

拿到配置文件路径后，先备份，这是所有配置修改前的第一动作：

cp /usr/local/easynvr/nginx/conf/nginx.conf /usr/local/easynvr/nginx/conf/nginx.conf.bak-$(date +%Y%m%d)

3.2 修改SSL协议版本和加密套件

找到nginx.conf中HTTPS server的配置块，重点看ssl_protocols、ssl_ciphers和ssl_prefer_server_ciphers这三项。我这次遇到的原始配置是这样的：

server { listen 8443 ssl; server_name _; ssl_certificate /usr/local/easynvr/nginx/conf/cert/server.crt; ssl_certificate_key /usr/local/easynvr/nginx/conf/cert/server.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; ... }

问题很明显：ssl_protocols里带了TLSv1和TLSv1.1，ssl_ciphers用的HIGH关键字在旧版OpenSSL里包含了3DES套件。修改后的配置如下：

server { listen 8443 ssl; server_name _; ssl_certificate /usr/local/easynvr/nginx/conf/cert/server.crt; ssl_certificate_key /usr/local/easynvr/nginx/conf/cert/server.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ... }

这里每一个配置项都是有讲究的：

• ssl_protocols TLSv1.2 TLSv1.3：只保留现代协议版本。TLSv1.0和TLSv1.1在RFC 8996中已经被标记为废弃，扫描器一般也会报；
• ssl_ciphers列表里全都是带GCM或CHACHA20的AEAD套件，支持前向保密，3DES和CBC模式套件一个都没留；
• ssl_prefer_server_ciphers on：让服务端决定使用哪个套件，避免客户端把套件降级到不安全的选项；
• ssl_session_cache和ssl_session_timeout是性能优化项，视频播放页面频繁建立HTTPS连接的情况下，会话复用能明显减少握手开销。

注意一个细节：如果EasyNVR的Nginx编译时OpenSSL版本较低，不支持TLSv1.3，ssl_protocols里写了TLSv1.3会导致Nginx启动失败。遇到这个情况，把TLSv1.3去掉，只保留TLSv1.2就行。判断方法是在服务器上执行：

openssl version

如果OpenSSL版本低于1.1.1，那就不支持TLSv1.3。老版本EasyNVR捆绑的OpenSSL有可能就是这种，配置前先确认一下。

3.3 校验配置并重新加载

改完配置不能直接重启，先做语法校验：

/usr/local/easynvr/nginx/sbin/nginx -t -c /usr/local/easynvr/nginx/conf/nginx.conf

出现Syntax OK和test is successful字样，说明配置没有语法问题。然后平滑重载：

/usr/local/easynvr/nginx/sbin/nginx -s reload

使用reload而不是restart，是为了避免重启导致正在播放的视频流出现闪断。平滑重载会先完成旧连接的收尾，再切换到新配置，实测对在线视频播放的影响很小。

如果你部署的是Docker版EasyNVR，操作方式略有不同。需要进入容器或者通过挂载方式修改宿主机上的配置文件，然后重启容器：

docker exec -it <容器名> bash # 修改容器内nginx.conf nginx -t nginx -s reload

不管哪种部署方式，改完配置之后都要做一次业务回归，确认管理后台能正常登录、视频页面能正常播放。

4. 修复验证与回滚预案

4.1 用OpenSSL命令行验证3DES套件已禁用

配置重载之后，第一时间验证修复效果。先用openssl的s_client命令挨个检查：

# 验证3DES套件是否已禁用 openssl s_client -connect 127.0.0.1:8443 -cipher 'DES-CBC3-SHA' 2>&1 | grep -E "Cipher|error|alert"

如果修复成功，这条命令会返回Cipher is (NONE)或者直接握手失败。最直观的表现是连接被重置，输出信息里出现No ciphers enabled相关提示。

再验证库里没有3DES残留：

# 查看当前OpenSSL支持的3DES套件 openssl ciphers -v '3DES' | wc -l

这只是确认系统OpenSSL里还有3DES定义，关键还是看Nginx有没有启用。更准确的方式是用openssl模拟完整握手：

# 模拟TLSv1.2握手，检查协商到的实际套件 openssl s_client -connect 127.0.0.1:8443 -tls1_2 2>&1 | grep "Cipher is"

正常情况下应该返回类似ECDHE-RSA-AES128-GCM-SHA256这样的现代套件。

4.2 用nmap做一次全面扫描

命令行验证通过之后，我用nmap的ssl-enum-ciphers脚本做了一次系统扫描，这个结果跟安全扫描器的检测逻辑更接近：

nmap --script ssl-enum-ciphers -p 8443 127.0.0.1

扫描结果会列出所有支持的TLS版本和对应的加密套件。重点看两个地方：TLSv1.0和TLSv1.1是否已经彻底消失；TLSv1.2下是否还有3DES套件。如果输出里没有任何3DES相关条目，协议版本只剩TLSv1.2和TLSv1.3，这次修复就算过关了。

我在实际扫描中还发现过一个现象：nmap的ssl-enum-ciphers输出显示TLSv1.2下有一个DES-CBC3-SHA套件，但这时候Nginx配置里明明已经加了!3DES。后来排查下来发现是Nginx配置中存在多个server块，扫描器命中的那个server块没有生效新配置。所以改配置的时候，一定要检查所有监听8443端口的server块，不要只盯着一处改。

4.3 服务起不来和业务异常的回退方案

配置修改后如果Nginx起不来，或者业务出现异常，第一时间恢复备份：

cp /usr/local/easynvr/nginx/conf/nginx.conf.bak-20250101 /usr/local/easynvr/nginx/conf/nginx.conf /usr/local/easynvr/nginx/sbin/nginx -t /usr/local/easynvr/nginx/sbin/nginx -s reload

回滚操作很简单，所以备份一定不能省。我处理过的项目里，遇到最多的回滚场景是：客户那边有老旧的摄像头或者老浏览器，访问H5播放页时只支持TLSv1.0和3DES，一关掉就直接打不开页面了。这种情况最稳妥的做法不是开回3DES，而是跟客户沟通升级浏览器或者换用支持新协议的视频客户端。安防这种场景，安全合规优先级高于兼容老设备，这一点需要提前跟业务方对齐。

5. 修复过程中容易踩的坑

5.1 密码套件语法不兼容老版本OpenSSL

这是我在实践中遇到过最典型的坑。EasyNVR老版本捆绑的OpenSSL可能还是1.0.2甚至更早，这个版本不认识TLSv1.3关键字，也不支持CHACHA20-POLY1305这类套件。配置里硬写进去，Nginx直接起不来。

排查方法很简单，看Nginx错误日志：

tail -n 50 /usr/local/easynvr/nginx/logs/error.log

如果出现invalid value "TLSv1.3"或者unknown cipher "ECDHE-ECDSA-CHACHA20-POLY1305"这类提示，说明当前环境不支持这些新特性。解决办法是把TLSv1.3去掉，套件列表里只保留OpenSSL支持的GCM套件。先保证服务能起来，再考虑后面升级OpenSSL版本的事情。

5.2 只改了密码套件没改协议版本

有不少人在修复3DES时，只把ssl_ciphers里的3DES排除了，但ssl_protocols还留着TLSv1.0和TLSv1.1。这样做虽然3DES的告警可能消除了，但扫描器很快会报出低版本TLS的告警。TLSv1.0和TLSv1.1同样存在已知漏洞，比如BEAST攻击、POODLE攻击，在等保和PCI合规里都是必须整改的项。

所以修复的时候应该一并处理，不要挤牙膏似的，今天改一个明天改一个，搞得每次扫描都有新告警。我在项目里的习惯是：所有SSL配置一次性调整到位，协议版本、密码套件、证书、会话缓存都检查一遍，减少返工。

5.3 多server块配置漏改

EasyNVR的nginx.conf里，有时候会有多个server块，比如一个监听80端口的HTTP跳转配置，一个监听8443的HTTPS管理后台，还有一个监听其他端口的API服务。如果只在其中一个server块里改了SSL配置，其他server块仍然保留旧的套件列表，扫描器照样能扫出3DES。

处理方法是全局搜索nginx.conf中所有listen ... ssl的server块，逐块检查或统一修改。也可以在http块层面配置一份公共的ssl_protocols和ssl_ciphers，这样所有server块都会继承：

http { ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...; ssl_prefer_server_ciphers on; ... }

前提是确认所有server块都适合使用同一套策略。如果存在兼容老客户端的特殊场景，再单独覆盖。整体上用继承机制管理SSL配置，比在多个server块里各写一遍更不容易漏。

6. 修复后的验证结果与后续维护

6.1 本次修复的验证记录

这次修复完成后，我做了两轮验证。第一轮是命令行级别的验证，用openssl和nmap确认3DES套件和TLSv1.0/1.1已经消失；第二轮是业务回归，登录EasyNVR管理后台、打开一路摄像头的H5播放页面、拉一次RTSP流转发，确认功能正常。

第二轮复检我用的是同一款扫描器，重新扫了一遍8443端口，3DES相关告警消失，整体评分提升，整个整改闭环完成。

6.2 后续维护建议和证书策略

修复完成不等于一劳永逸。SSL配置这个东西，随着时间推移会有新的漏洞暴露、新的协议标准发布，建议建立定期检查的习惯。我自己在维护这类安防流媒体平台时，一般按季度做一次安全巡检，重点关注几个方向：

• 确认没有出现新的弱加密套件配置变更；
• 检查TLS证书剩余有效期，提前一个月更换，避免过期导致播放页面打不开；
• 关注EasyNVR官方版本更新，新版本通常会在流媒体分发、鉴权、TLS支持上做优化，有条件就升级；
• 如果平台对外开放了RTSP或RTMP端口，检查一下是否有弱口令或未授权访问问题；
• 各设备的固件版本保持更新，老版本固件可能不支持新的TLS配置。

另外，如果项目后续要做等保测评，TLS配置的整改只是其中一项，还需要关注身份鉴别、访问控制、日志留存、数据完整性等要求。从这次3DES漏洞整改入手，把整个平台的安全基线一起梳理一遍，是最省力的做法。

我个人的操作习惯是，每次做完这类SSL修复，都会把当时的配置改动、验证结果、扫描报告截图归档到一个项目目录里，等保测评或客户问起来，直接拿出整套材料，省去很多解释的功夫。这套EasyNVR的3DES修复，核心改动其实就这么几行配置，但前前后后的确认、验证、回归流程不能少。照着这个流程走一遍，扫描器再报类似弱加密套件问题时，处理起来就很顺手了。