这是一个创建于 744 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家好，小弟最近在研究一个项目，是假设从一个公司内部的 443 端口获取流量并筛选出可疑的 DoH 流量，希望能防止恶意软件通过 DoH 连接主机传输数据，目前在讨论这个策略是否有可行性，学识尚浅，有很多不确定的部分，想请教各位。
动机
明文传输 DNS 请求可以尝试直接检测恶意流量，而 DoH 可以把请求加密后混淆在 HTTPS 流量中，应该也存在攻击者利用这个加密进行特定传输，但是转了一圈好像国内并没有厂商的对应安全防御产品？
过程
于是我就开始找相关的论文学习，分析了一个公开的 DoH 数据集，从 pcap 开始处理，整理出 flow 信息后进行特征提取，目前在验证集上判断 is_doh 这个标签已经达到了较高的准确率，但是遇到了两个问题。
面临的问题
第一个就是如何在实际的本地数据上进行验证呢，直接把模型应用到本地数据上，有很多预测为 DoH 的流量，但是没有办法实际检验是否准确。
论文中的数据集是根据 DSP_IP 是否是公开的 DoH 服务商名单来标注的，但是这个名单有很多遗漏，而且实际中攻击者可能并不会用这些公开的 DoH 服务商，我想通过本地获取所有的 HTTPS 的请求内容来判断是否在使用 DoH 请求 DNS ，pcap 中加密的 HTTPS 请求数据有条件解密成明文吗，实际涉及的设备众多，如果这个思路可行的话想先通过一两台进行数据模拟，判断已有模型的准确性，再进行调整和训练。
另一个思路是抓包的 pcap 文件中有没有其他的有用信息啊，小弟第一次接触 pcap 格式，把预处理工具编译成能提取特征的 csv 然后移植就花了半个月的时间，再从头解密 HTTPS 想必也有难度，如果有其他的方法，我也想去尝试。
以下是提取的 flow 特征和用于分类的特征
还有一个思路就是训练时不单单检测 DoH 流量，而是直接针对DoH 中的恶意流量学习，但这个不仅仅存在第一个训练后在实际场景准确率检验的问题，而且恶意流量的特征可能并不总一致的，而且不确定是否存在这类公开数据集。
最后的一个问题，就是各位觉得这项技术的可行性如何啊？我其实觉得这个 idea 很好，也有存在的价值，但是想到 DoH 和 HTTPS 本身就是为了加密而产生的，想要解密肯定不容易，我只在本科的计算机网络里面浅显的了解过 TCP/IP 什么的，并没有实际抓包处理的经验，感觉还是有较大困难的。
感谢各位，请不吝赐教！
 |
1
learningman 2022-11-10 22:39:31 +08:00  3
建议域内所有计算机安装自定义 CA ，这样只要有不能解密的流量扔掉就好了（
|
 |
2
jousca 2022-11-10 22:48:29 +08:00
没有可行性。 除非你把 443 全灭。加密包你去判断它里面装的是啥？人家两次加密，你更没辙。解密第一层之后发现还是加密包……
GFW 都做不到的事情，你做？ |
 |
3
Herry001 2022-11-10 23:01:14 +08:00
DoH 是 DNS over HTTPS ，你可以把问题简单化点，对 HTTPS 做恶意流量分析。
当然，我不认为这玩意有可行性。 |
 |
4
majula 2022-11-10 23:06:39 +08:00 1
你又不是 GFW ，搞流量特征分析干啥，吃力不讨好。
既然是公司内网，那最有效的方案就是像一楼说的一样，直接要求办公用计算机都装 CA ，MITM 分析明文流量。这不比分析加密流量简单多了，甚至可能不需要上机器学习。 现在很多公司都是这么搞的，不装 CA 内网外网都上不了，上外网看到的证书也是那个 CA 签的 （说不准哪天 GFW 也要这么搞了） |
 |
5
Jirajine 2022-11-10 23:21:01 +08:00
@majula gfw 这么搞没意义，再套一层隧道就是，只要允许任意流量进出就总能打洞。
当然也不能说没意义，这么搞了以后广大查资料看剧等自以为的“正常”用户很高兴的接受审查，那剩下还坚持用加密隧道的什么成分就不用多说了。 |
 |
6
bigfei 2022-11-10 23:47:33 +08:00
可以解析 SSL 的 SNI ，获得主机域名，然后访问 /dns-query 等常见请求来判断看看。
|
 |
7
Puteulanus 2022-11-10 23:47:55 +08:00
公司里需要这种安全级别的场景一般是装 CA ，像银行的 VDI 里，开所有网站证书都是它签发的
这是在做毕设吗 |
 |
8
H0u5er 2022-11-11 00:58:48 +08:00
两年前研究 Domain Fronting 和 Domain generation algorithms 的时候也跟你有过一样想法，已经有安全厂商是基于 Machine Learning 的方式实现商业化产品，简单来说是通过建模和统计原理来判断恶意 DNS 流量。
http://blog.nsfocus.net/dns-tunnel-communication-characteristics-detection/ https://www.4hou.com/posts/7VMG |
 |
9
yang3121099 OP 谢谢各位回复！
@learningman 这个也考虑过， 但是落地的场景中可能不仅仅是计算机，还有打印机等其他联网设备，数量多的话就有一些难度 @jousca 不打算封掉 443 端口，考虑实在不行，就在 DoH 检测率准确较高的基础上，禁掉所有的 DoH 流量 DSP_IP ，强制普通的 DNS 访问，不过算是下下策 @Herry001 确实 最开始的需求就是从一堆 HTTPS 中检测 DoH 流量的模型就行，训练的准确性和召回率达到了 99.9%，但是发现甲方自己没有验证的方式，我只好帮忙想一想办法了 @majula 特征分析甲方可以当做卖点吧哈哈哈，能显得他这款产品更有技术竞争力，因为市面上能搜到的最相近的一款产品，完成的算法包括数据集准确性什么的都不一定比我做的好，我也不想看着只能是一个半成品，要是有机会落地还是想试一下哈哈哈 @Jirajine 我感觉 GFW 还是有技术裕量的，至少重要会议期间大多都不 work 了，还是有点游刃有余的意味吧哈哈哈 @bigfei 好的，我去了解一下 SNI ，我也想着既然有了目的 ip ，能不能主动再次向他请求 DNS 解析判断是不是真的 DoH ，但是对接的甲方说请求了 /dns-query 什么的并不响应？ 443 端口倒是都开的，怀疑只提供部分 DNS 服务吗？我也不太懂这个，所以只能现学现卖哈哈哈 @Puteulanus 哈哈哈还没到毕设，现在是人工智能和大数据方向研一，这个是一个小课设，不过是现有的实际业务需求再有的课设自拟题，课内已经通过答辩能结课了，现在想着能不能再进一步实际落地，其实问题也不止这个，模型在公开数据集表现很好但是实际场景并不能直接应用，需要研究域适应和模型封装什么的，只不过那些算是我专业内的东西，预期内努努力可以完成，但计算机网络我是真的没接触过，本科计网和计组分数就不高哈哈哈 |
|
10
yang3121099 OP @H0u5er 谢谢！！第二个链接我最近也在看哈哈哈，甚至我上一条里面提到的竞品就是他，很有借鉴价值和参考性，因为他做的这些方法和可视化什么的我之前都已经完成了，模型也比他多几个，区别在于数据集不一样，他用的是 DoH 黑白数据集+HTTPS ，我是 HTTPS+DoH 不过规模比他大两个数量级可能，确实只能是基于数学上的统计方法了，没有办法实际验证，但他开头提到的 可以用浏览器同步生成(Pre)-Master-Secret 日志 就是我想去解密 HTTPS 的动机，哎，不过感觉他也没做什么东西，都跟 toy-model 差不多，产品应该还没到商用的程度，实际部署需要再攻克实际场景域迁移等难题，因为我测试下来不同数据集之间参数表现差别巨大，有时候在新的数据集上虽然 80%的 acc ，但 mcc 指标表示和随机猜测的效果差不多，需要再研究研究。
第一个链接我下来再仔细看看，多谢回复！ |
 |
11
ZRS 2022-11-11 01:43:18 +08:00 via iPhone
可行性很低
|
 |
12
Zy143L 2022-11-11 02:15:19 +08:00 via Android
恶意流量通过 DoH 传递？
你先想一下 DOH 是什么，DNS over HTTPS 这部分就应该是恶意流量通过 HTTPS 传递 你最多只能分析出这个流量是 https 流量还是 doh 的 https 流量 |
 |
13
liuidetmks 2022-11-11 09:56:06 +08:00 1
什么是恶意？
你这个就是恶意。 |
|
14
yang3121099 OP @ZRS 好，谢谢
@Zy143L 确实，之前的思路也是如此，目前从 HTTPS 中检测 DoH 的几项指标都达到了 99.9%，但是下一步却遥不可及，就很难过 @liuidetmks 确实 如果有人入侵某个重点集团的设备 命令设备上的插件只发出低连接时长低延迟的 DoH 混淆 就算用更好的方法也极难区分 因为特征隐藏后他们本质上没有区别 则攻守之势异也 |
 |
15
yaott2020 2022-11-11 16:49:28 +08:00 via Android
DOH 和普通 HTTPS 网站都是 HTTPS 流量，你能怎么区分？ ClientHello 指纹？还是包的大小？又或者是主动探测？以上种种都可以通过诸多方式绕过，但是正常流量就会受到影响。与其费尽心思去识别，不如从其他地方考虑。。。
|
Select Language