文章总结： 文档讨论了运维安全的三大挑战：动态IP管控、Redis漏洞治理和加密架构设计。对于动态IP问题，建议使用代理工具或脚本动态更新防火墙策略；Redis漏洞修复需根据实际环境评估优先级；加密架构优化可考虑客户端加密或服务端加密方案，同时需注意密钥管理和访问控制。 综合评分： 87 文章分类： 网络安全,漏洞分析,数据安全,安全建设,解决方案

运维安全三大挑战：动态IP管控、漏洞治理与加密架构实战解析｜总第302周

原创

群秘

君哥的体历

2025年10月23日 08:01 北京

0x1本周话题

话题一：现在很多应用都用飞书、企微的机器人进行告警，需要飞书、企微的域名访问这些机器人服务，而这些域名都是解析到很多个ip地址，防火墙acl策略时好时坏，必须要开成any策略，大家有什么好的代理工具对这些出向的访问进行统一管理吗？

A1：可以引入正向代理集中管控对外访问，避免每台服务器直连外网域名。

Q：具体有哪些工具推荐啊？需要在服务器安装客户端吗？

A2：传统防火墙通常不支持基于域名的策略，可以编写脚本定期解析域名并动态更新防火墙策略组。

A3：下一代防火墙或七层防火墙理论上支持域名策略，但飞书、企微的域名数量多、变化频繁，实际操作难度会更大。

A4：实际场景中域名策略的维护成本也比较高。

A5：（AI工具建议）：可采用Nginx反向代理，通过配置将内网请求转发至飞书/企微Webhook；也可使用AlertFusion、PrometheusAlert等告警中台，统一对接机器人服务，收敛出口IP。

A6：问题的本质是怎么在防火墙上收敛策略，而不是单纯选型工具。AI的回答其实也偏离了。

A7：但是也可以考虑使用WebSocket长连接替代Webhook，通过飞书API主动拉取告警，避免服务端主动出向访问。

A8：我个人觉得，Nginx作为代理较为稳定，尤其适合长连接场景，但需解决域名解析与证书问题。但是Nginx方案需在每台服务器配置hosts劫持域名，且缺乏企微/飞书的有效证书；此外，若使用SOCKS代理，会代理全部流量，不够灵活。

A9：这里的需求是服务器主动调用飞书/企微机器人接口，而非接收外网Webhook。

A10：服务器通常不允许直接出公网，而飞书作为SaaS服务，其域名对应IP频繁变化，造成策略维护困难。

A11：类似场景还包括腾讯会议等多IP域名服务。

A12：这几个方面可以考虑下：

• grafana配Webhook地址处配成：aaa.XXXXX.local

• aaa.XXXXX.local的DNS解析地址指向Nginx的地址

• Nginx中增加vhost配置文件，核心配置如下：

  server { listen 80; server_name aaa.XXXXX.local; # 填写你的域名 location / { proxy_pass https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=XXXX } }

A13：你的服务器，正常的话，其实就2个域名必须访问： wss://msg-frontier.feishu.cn https://open.feishu.cn

A14：把nginx这个配置配置，试试看。

话题二：Redis RCE漏洞CVE-2025-49844：风险真的可控吗？

A1：如果Redis启用了认证，风险就相对可控；要是没有认证，漏洞影响也有限吧。

A2：但是也可能引发合规风险，这就是例子。

《DPC重罚TikTok：5.3亿欧元裁决重塑跨境数据规则》

A3：关键是身份验证呀。

A4：实际环境中很多Redis实例使用空口令，漏洞在内网渗透中也是有利用价值的。

A5：攻击者可能就是写入authorized_keys/计划任务来实现权限维持。

A6：这个要猜测用户名，计划任务要root权限，实战的话并不一定能成功。

A7：修复是必要的，但也要客观评估优先级。独立部署的Redis可以循序渐进去修复，但是云上Redis服务就要尽快处理。

A8：不过从安全的角度，可以提要求，能不能实现升级还要看公司有没有资源支持这方面的升级测试。有多少单位能为安全升级提供充足的资源进行测试？

A9：兼容性测试只能产品团队自己做，产品的管道年初就排好了，哪能马上有资源，见缝插针慢慢来吧。

A10：除了特定漏洞补丁，服务器端os、中间件、组件基础软件版本定期升级是不小的变更，每年的演习是个契机。大部分服务器一年只能有一次打补丁机会。

话题三：加密方案怎么设计更安全高效：我的视频先由客户端C上传给服务端B，由B使用aes加密之后再传给minio服务。之后访问时由B从A获取加密视频，然后在B处解密，最后传输给C查看。minio本身是存储加密的。minio是A。

A1：为什么不直接在客户端加密后上传至Minio？这样可以避免服务间传输，减少延迟与依赖啊。

A2：原方案中服务端B进行AES加密再传至Minio，计划改为直接使用Minio服务端加密，以减轻服务端负担。

A3：Minio支持服务端加密，类似于AWS S3。如果Minio的AK/SK泄露，那加密数据也可能被解密。

A4：也可以考虑把解密环节下放至客户端啊，减轻服务端压力。

A5：客户端解密需要配合访问权限控制，要是在客户端解密，密钥就必须根据用户来随机化，不然就没意义了啊。

A6：也可以配置Minio（或S3）策略，限制只允许来自指定IP的请求来降低泄露风险。

0x2 群友分享

【安全管理】

《特拉维夫大学 | POPS：基于历史数据的DNS缓存投毒攻击缓解措施》

【安全事件通告】F5 BIG-IP遭国家级黑客渗透，潜在漏洞与供应链威胁，尽快采取行动！

《数据要素流通破局：新基建与新流通》

【安全资讯】

《国家安全机关破获美国国家安全局重大网络攻击案》

《CVE-2025-11230：HAProxy mjson 库中的拒绝服务漏洞攻击（2025.10.03）》

适用《数安法》《网安法》《网数条例》的行政处罚典型案例（126个）

由于微信修改了推送规则，需读者经常留言或点“在看”“点赞”，否则会逐渐收不到推送！如果你还想看到我们的推送，请点赞收藏周报，将【君哥的体历】加为星标或每次看完后点击一下页面下端的“在看”“点赞”。

【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。

往期群周报：

CDN恶意流量防御方案与企业网络安全定责探讨｜总第301周

金融系统数据脱敏、环境隔离、链路加密与BYOD管控的合规实践与落地平衡｜总第300周

企业软件治理挑战：管控非授权下载与破解软件的有效措施｜总第299周

如何进群？

如何下载群周报完整版？

请见下图：

‍

‍

‍

‍

‍

‍