数据流量是数据资产的重要组成部分，也是数字化业务的核心，但在网络攻击事件频繁、攻击手段层出不穷的现状之下，流量加密已经愈加常态化，安全团队面临的考验也随之而来，如何从海量加密流量中检测出恶意流量成为一项不小的挑战。本期话题，我们就围绕如何在加密流量中进行安全威胁检测，就相关问题展开讨论。

目前加密流量越来越多，对于加密流量中的恶意流量检测，大家的应用和部署目前到了什么程度？检测效果如何？

A1：

目前对这一块大多数安全设备都采用了基于特征的检测方法，即通过对恶意流量的特征进行检测，如基于恶意IP地址、恶意域名等。这种方法的检测效果一般。

A2：

我这边都没做过，就聊一点吧，现在有Ebpf的方式分析加密流量，大家可以考虑一下，但是就是对内核版本有要求。这点安卓上已经有人做了（安卓的内核版本可以比较新）。

A3：

现在有些交换机直接集成了加密流量威胁分析。

A4：

路由交换产品要提升产品价值，感觉现在交换机的转发性能已经不会成为整体性能的瓶颈了。

A5：

它信道设备咋解信源的加密？

A6：

玩一些侧信道吧，也还是有特征可以提取的，就算是能把加密流量分类摘出来，也算是个进步。

A7：

目前加密流量的识别方法有基于有效载荷、基于流量行为、基于机器学习、多种策略混合方法，因为能力或成本问题解不开流量，因此多采用侧信道。

A8：

需要被关注的加密恶意流量特征有几类？

A9：

这些特征也无非就是那些侧信道的东西，包长度和数量、流量速率、协议特征、证书特征、域名之类，传输方向、负载长度、窗口大小、到达时间间隔这些玩意拿出来建模，最后算法说异常，你也没法判定是不是真的异常。

A10：

这些特征要隐藏还是比较容易的。

A11：

所以不会用单一特征建模，关键是这一套做下来，计算成本也不低，效果又很难说。之前某厂商搞过解应用层的SDK，但也只是个探索。

A12：

我们这有个场景，是API之间的参数加密，很惨，常规的WAF完全没用，得上Rasp。

A13：

Rasp也是解法之一，不一定非得在流量层做功。

A14：

Tls流量检测更多的场景还是在办公网络，生产网络都在网关层就卸载证书了。

A15：

既然是办公网，你就可以有更大的权力，与其在那折腾流量侧信道，不如你在端上做点手脚？

A16：

是的。所有的解密相关必须全控在安全手里，KMS端控，不然WAF、SIP这种的形同虚设。

A17：

Rasp倾向结果了 ，如果可管、可控、可视，流量解密好像是必须的。

A18：

用Rasp需要考虑一个是对业务的性能影响问题，另一个是Rasp对业务改造比较多，极端情况下Bypass策略启用的时间。

Q：攻击者将恶意流量混入网站或平台的合法流量中躲过审查，而这些网站通常会使用SSL/TLS进行通信加密，为恶意流量提供了天然的通讯保护，即便攻击行为暴露，样本被分析，也很难溯源攻击者的真实IP。对此，如何辨明来自合法网站的恶意流量？

A1：

对于将恶意流量混入网站或平台的合法流量中，可以采用基于行为的检测方法，通过对流量的行为特征进行分析，如是否存在恶意请求、是否访问了危险网站等。

A2：

传统基于端口与有效载荷的方法很难对SSL/TLS进行精准分类，所以主要通过SSL/TLS认证过程中的特征数据进行识别。HTTPS加密流量中能做到识别用户的操作系统，浏览器，应用，可以基于突发行为和SSL行为做一些特征模型，加密恶意流量特征可以通过解析HTTPS数据包头部信息来获取，因为TLS握手协议在网络中通过明文传输，总体来说，还是隔靴搔痒。

话题二：漏洞管理平台你们用的哪个，洞察满足不了了，有没有推荐？个漏洞能牵扯出好几个部门，没办法指定给单个部门。

A1：

直接对接你们OA，落实到个人，要不然只是落实到组织个人没啥用，还有对接你们的邮件系统，通过下发方式勾选，邮件、OA、手机短信，都行。

A2：

落实到组织也得有人对接啊，不然没人认领都当不存在。

A3：

有人对接也不行，缺乏时效性，等通知下去，都不知道什么时候了。

Q：正好我也想问下，对接OA，你们是下发工具导出格式，还是自己拟定报告，还是做在流程里字段固化？

A1：

我之前做，是拟定报告下发，因为有些问题多问题少，固定下去怕有问题。

A2：

漏洞信息手动填还是对接漏洞扫描器？

A3：

对接扫描器报告标准化格式，你们要自己做好上传样式和后台字段设计。

A4：

我们现在是自己编个报告，对接方式感觉有问题，比如扫描器告诉你十几个tomcat版本漏洞，其实我只要一句话就完了。

A5：

我们现在是编报告的话，没法对应到不同部门，而且还太慢了。

A6：

看你们的设计需求，我们当时的设计需求是每个漏洞都必须下发下去，所以对接某厂商RSAS的标准导出格式，然后自己设计样式和字段录入。

A7：

发报告，还是发漏洞是有点区别，发报告的话，处理人员只对报告内容负责，闭环；如果是面向漏洞，跟现在的OA系统兼容性，流程能不能处理下去，细节上总感觉有很多问题。特别版本性的，归总为一个叫版本漏洞，比发几十个什么什么漏洞简洁明了多了。

A8：

个人感觉你的方向有问题，报告和漏洞本质对我们来说都是一样的，工作应该做细致，你可以私下和系统负责人沟通，大版本升级，但是你下发下去，不能漏发扫描出来的漏洞。

A9：

这个可能大家理解和工作形式有点区别吧，从扫描器到oa有个漏洞数据清洗的过程，我认为把几十个php版本漏洞名称告诉管理员没有价值。

A10：

正常，每个人工作都有自己的方式，我认为工作要细致，也是为了防止背锅，有问题可以私下沟通，但是流程一定要走规范。

——————————————————

本期精彩观点到此结束啦~此外，FreeBuf会定期开展不同的精彩话题讨论，想了解更多话题和观点，快来扫码免费申请加入FreeBuf甲方群吧！

加入即可获得FreeBuf月刊专辑，还有更多精彩内容尽在FreeBuf甲方会员专属社群，小助手周周送福利，社群周周有惊喜，还不赶快行动？

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！

FreeBuf甲方群成员（因篇幅限制仅展现部分行业成员）：

金融行业：贝宝金融 安全负责人、成都农商银行 信息安全负责人、晋商银行 安全负责人、北京银行 安全负责人、君龙人寿 技术负责人、合合信息 合规负责人、合生 信息安全负责人、航天产业投资基金IT负责人、工银金融 信息安全负责人、前海联合基金 信息安全负责人、天弘基金 安全负责人、阳光保险 信息安全部负责人、南京证券 安全负责人、宝马金融 信息安全经理  

运营商：中国联通 网络安全主管、中国电信 信息安全技术主管、上海电信 网络安全主管、天津电信SOC主管、太平洋电信 研发总监