V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yang3121099
V2EX  ›  DNS

关于 DoH 流量的特征获取和恶意流量的防御策略

  •  
  •   yang3121099 · 2022-11-10 22:12:09 +08:00 · 3685 次点击
    这是一个创建于 503 天前的主题,其中的信息可能已经有所发展或是发生改变。

    大家好,小弟最近在研究一个项目,是假设从一个公司内部的 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 特征和用于分类的特征

    https://imgur.com/n6HrciS

    https://imgur.com/zgtUCQ1

    还有一个思路就是训练时不单单检测 DoH 流量,而是直接针对DoH 中的恶意流量学习,但这个不仅仅存在第一个训练后在实际场景准确率检验的问题,而且恶意流量的特征可能并不总一致的,而且不确定是否存在这类公开数据集。

    最后的一个问题,就是各位觉得这项技术的可行性如何啊?我其实觉得这个 idea 很好,也有存在的价值,但是想到 DoH 和 HTTPS 本身就是为了加密而产生的,想要解密肯定不容易,我只在本科的计算机网络里面浅显的了解过 TCP/IP 什么的,并没有实际抓包处理的经验,感觉还是有较大困难的。

    感谢各位,请不吝赐教!

    15 条回复    2022-11-11 16:49:28 +08:00
    learningman
        1
    learningman  
       2022-11-10 22:39:31 +08:00   ❤️ 3
    建议域内所有计算机安装自定义 CA ,这样只要有不能解密的流量扔掉就好了(
    jousca
        2
    jousca  
       2022-11-10 22:48:29 +08:00
    没有可行性。 除非你把 443 全灭。加密包你去判断它里面装的是啥?人家两次加密,你更没辙。解密第一层之后发现还是加密包……
    GFW 都做不到的事情,你做?
    Herry001
        3
    Herry001  
       2022-11-10 23:01:14 +08:00
    DoH 是 DNS over HTTPS ,你可以把问题简单化点,对 HTTPS 做恶意流量分析。
    当然,我不认为这玩意有可行性。
    majula
        4
    majula  
       2022-11-10 23:06:39 +08:00   ❤️ 1
    你又不是 GFW ,搞流量特征分析干啥,吃力不讨好。

    既然是公司内网,那最有效的方案就是像一楼说的一样,直接要求办公用计算机都装 CA ,MITM 分析明文流量。这不比分析加密流量简单多了,甚至可能不需要上机器学习。

    现在很多公司都是这么搞的,不装 CA 内网外网都上不了,上外网看到的证书也是那个 CA 签的

    (说不准哪天 GFW 也要这么搞了)
    Jirajine
        5
    Jirajine  
       2022-11-10 23:21:01 +08:00
    @majula gfw 这么搞没意义,再套一层隧道就是,只要允许任意流量进出就总能打洞。
    当然也不能说没意义,这么搞了以后广大查资料看剧等自以为的“正常”用户很高兴的接受审查,那剩下还坚持用加密隧道的什么成分就不用多说了。
    bigfei
        6
    bigfei  
       2022-11-10 23:47:33 +08:00
    可以解析 SSL 的 SNI ,获得主机域名,然后访问 /dns-query 等常见请求来判断看看。
    Puteulanus
        7
    Puteulanus  
       2022-11-10 23:47:55 +08:00
    公司里需要这种安全级别的场景一般是装 CA ,像银行的 VDI 里,开所有网站证书都是它签发的

    这是在做毕设吗
    H0u5er
        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
    yang3121099
        9
    yang3121099  
    OP
       2022-11-11 01:25:07 +08:00
    谢谢各位回复!

    @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 哈哈哈还没到毕设,现在是人工智能和大数据方向研一,这个是一个小课设,不过是现有的实际业务需求再有的课设自拟题,课内已经通过答辩能结课了,现在想着能不能再进一步实际落地,其实问题也不止这个,模型在公开数据集表现很好但是实际场景并不能直接应用,需要研究域适应和模型封装什么的,只不过那些算是我专业内的东西,预期内努努力可以完成,但计算机网络我是真的没接触过,本科计网和计组分数就不高哈哈哈
    yang3121099
        10
    yang3121099  
    OP
       2022-11-11 01:41:12 +08:00
    @H0u5er 谢谢!!第二个链接我最近也在看哈哈哈,甚至我上一条里面提到的竞品就是他,很有借鉴价值和参考性,因为他做的这些方法和可视化什么的我之前都已经完成了,模型也比他多几个,区别在于数据集不一样,他用的是 DoH 黑白数据集+HTTPS ,我是 HTTPS+DoH 不过规模比他大两个数量级可能,确实只能是基于数学上的统计方法了,没有办法实际验证,但他开头提到的 可以用浏览器同步生成(Pre)-Master-Secret 日志 就是我想去解密 HTTPS 的动机,哎,不过感觉他也没做什么东西,都跟 toy-model 差不多,产品应该还没到商用的程度,实际部署需要再攻克实际场景域迁移等难题,因为我测试下来不同数据集之间参数表现差别巨大,有时候在新的数据集上虽然 80%的 acc ,但 mcc 指标表示和随机猜测的效果差不多,需要再研究研究。
    第一个链接我下来再仔细看看,多谢回复!
    ZRS
        11
    ZRS  
       2022-11-11 01:43:18 +08:00 via iPhone
    可行性很低
    Zy143L
        12
    Zy143L  
       2022-11-11 02:15:19 +08:00 via Android
    恶意流量通过 DoH 传递?
    你先想一下
    DOH 是什么,DNS over HTTPS
    这部分就应该是恶意流量通过 HTTPS 传递
    你最多只能分析出这个流量是 https 流量还是
    doh 的 https 流量
    liuidetmks
        13
    liuidetmks  
       2022-11-11 09:56:06 +08:00   ❤️ 1
    什么是恶意?
    你这个就是恶意。
    yang3121099
        14
    yang3121099  
    OP
       2022-11-11 10:45:07 +08:00
    @ZRS 好,谢谢

    @Zy143L 确实,之前的思路也是如此,目前从 HTTPS 中检测 DoH 的几项指标都达到了 99.9%,但是下一步却遥不可及,就很难过

    @liuidetmks 确实 如果有人入侵某个重点集团的设备 命令设备上的插件只发出低连接时长低延迟的 DoH 混淆 就算用更好的方法也极难区分 因为特征隐藏后他们本质上没有区别 则攻守之势异也
    yaott2020
        15
    yaott2020  
       2022-11-11 16:49:28 +08:00 via Android
    DOH 和普通 HTTPS 网站都是 HTTPS 流量,你能怎么区分? ClientHello 指纹?还是包的大小?又或者是主动探测?以上种种都可以通过诸多方式绕过,但是正常流量就会受到影响。与其费尽心思去识别,不如从其他地方考虑。。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   4697 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 41ms · UTC 10:02 · PVG 18:02 · LAX 03:02 · JFK 06:02
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.