这是一个创建于 269 天前的主题，其中的信息可能已经有所发展或是发生改变。
（以下是情况假设）有一台电脑，我设置了 wireshark 只抓浏览器的包，随后我通过浏览器访问 baidu.com ，抓到了访问百度首页的所有数据包。随后，设置 wireshark 抓取电脑全局流量，并随机使用电脑上安装的软件，其中我可能会访问 baidu.com 。最终，我想通过这个浏览器访问百度的流量包（全局流量的子集），解析出所有 TCP 包的时间大小相对时间协议等，在全局流量中通过滑动窗口去匹配哪个时间段访问了百度首页。这可能很麻烦，因为某些包可能并不一定会发出，其次，因为中间可能掺杂着其他流量，所以对于访问百度首页的数据包还要进行适当的 X 轴拉伸匹配。在此请教大家一下有没有什么好的实现方法或者类似的方案。
53 条回复 • 2024-03-20 08:39:09 +08:00
 |
1
rrfeng 269 天前
首先说明你为什么要抓包
|
 |
2
lambdaq 269 天前
wireshark 怎么实现只抓浏览器的包的。。。？
|
 |
3
rev1si0n OP |
 |
4
F7TsdQL45E0jmoiG 269 天前
自己弄个代理，浏览器配代理，然后抓代理的包
|
 |
5
liuhan907 269 天前
你首先应该想一下怎么解 https 的流量
|
 |
6
tool2d 269 天前  1
我会选择用 windows 系统的防火墙来过滤，有一个 API 参数是 FWPM_CONDITION_ALE_APP_ID ，可以匹配浏览器的运行 PID 。
可能还需要装一个开源 VPN 虚拟网卡，作为抓包和转发的中转节点。 想想还是 linux 简单，iptables 需要匹配进程，一句--uid-owner 就搞定了。 |
 |
8
lxyv 269 天前
可以考虑用微软的 network monitor 抓包，根据应用进程 pid 筛选
|
 |
10
rekulas 269 天前
不如说说你真正想实现的是什么功能
|
|
12
tool2d 269 天前
@rev1si0n "解析出所有 TCP 包的时间大小相对时间协议等，在全局流量中通过滑动窗口去匹配哪个时间段访问了百度首页。"
TCP 滑动窗口值是动态变换的，网速好就大一点，网速卡就小一点，这个和用户是否访问百度又没必然联系。 用时间协议去匹配网站特征? 那你还不如用 TLS 浏览器指纹匹配，更靠谱一点。 |
 |
13
thevita 269 天前
你需要个 DPI, 比如 suricata, 给你解析到协议(会重组 tcp ，不用你自己“根据一段特征流量从当日流量匹配出特征流量出现的时间点”, 把各种你可能需要的内容提取出来，也能自己加些检测规则)
产生的数据流，要可用，可后面接写时序分析什么的，自由发挥 |
 |
14
kkocdko 269 天前
这种问题你应该去问代理协议的开发者相关的社区，在这里你只能获得上边几楼的那种质量的回答。
如果只是想拿来用，可以 OpenGFW ，由 hysteria 团队开发的 GFW 实现。 一般来说是 tls sni ，tls 指纹，dns 查询的 re-mapping 等。如果是你个人做着玩，我建议你选择类似 fakeip 的思路，然后劫持 dns ，弄一个比较大的地址池，这样的话比较不容易跟丢。 |
|
15
kkocdko 269 天前
13 楼的回答也不错，dpi 的话考虑到楼主刚入门不一定能玩得来。
|
 |
16
czfy 269 天前
这题目让我想到这个帖子
🧱的测试 IP 和最近的新研究 https://v2ex.com/t/1021128 |
|
17
rev1si0n OP @tool2d 确实网速是个因素，以及由于其他不需要的掺杂流量的影响，所以需要再对这个子集的流量进行时间上的伸缩（举个例子就像橡皮筋，橡皮筋上有 N 个不同间隔和大小的点，我可以拉伸或者缩短，就是每个包发送的时间变大或者变小再拿过去和当日流量匹配，如果包大小，间隔，协议等都能模糊匹配上，那就认定匹配成功了。当然这样做也不太现实），指纹的话，服务器 tls 指纹倒是可以引用一下，但是精细度就没法和直接流量级的比了（虽然能不能实现还是个问题）。
@thevita 多谢多谢，我看看，除了 GFW 里听说过还没了解过这个。 @kkocdko 今天至少没白问，这里开始涉及到盲区了，个人研究下是不是有可能，劫持只能对自己做，但是是想这个是可以做到通用的，指纹确实可以做到一些，但是精细度不够，或许也可以试一下指纹配合 TCP 特征。 |
 |
19
fano 269 天前
你研究的问题是 Encrypted Traffic Fingerprinting / Website Fingerpinting ，可以 Google Scholar 一下研究现状
|
 |
21
DefoliationM 269 天前 via Android
tls 加密的东西你怎么匹配，aead 加密后的数据都是随机字节流，没有特征，sni 倒是能匹配，不过现在也有 esni 了。
|
 |
22
Jirajine 269 天前
能说说你的目的是什么吗？看主贴感觉像 GFW 的工作人员。
@liuhan907 #18 加密仅仅只是加密，一些其他信息，比如时序特征是单纯加密无法掩盖的。比如你用过 n 层加密代理发布消息，攻击者就可能通过你消息发布的时间、字数来定位到发送消息的人，一些专注安全的 IM 会自动加 padding ；再比如主流浏览器的建立 tls 连接时发送的握手包非常固定，当这个包被另一个 tls 隧道传输时，可以很容易识别出特征来，也就是 tls in tls 识别。 |
|
23
rrfeng 269 天前
我很好奇楼上各位是怎么读懂 op 想干什么的……明显 op 问了个 X-Y problem
|
 |
24
sampeng 269 天前
我也没太搞懂。唯一我只知道像 GFW 一样的做流量识别，但我不觉得从来没研究这一块只是知道 tcp 的人能搞的出来的。那 GFW 就是个笑话了。。在不讨论 GFW 一样牛逼的流量识别算法下，按朴素的技术理解，普通大众看到的 tls 数据完全是无序随机的。
|
|
28
rrfeng 269 天前
@sampeng 姑且理解为「从流量中识别某个网站」
http 不说了，https 也根本不用学习特征的…… sni 会暴露一切。虽然只能识别到「域名」维度，但「页面」维度无论如何也无能为力了。 所以要怎么做取决于要做什么，只做阻断的话干嘛不搞 dns 。 |
|
30
Jirajine 269 天前
@liuhan907 #25 其实是能的，把过滤放到可信终端进行，不可信终端不可联网就行了，可以在密码学意义上保证其无法绕过。
只是没有必要，显然现在的 GFW 工作的很符合它的预期。 |
 |
32
hefish 269 天前
OP 考虑的非常全面。感谢 OP 的研究。
|
|
33
Jirajine 269 天前
@liuhan907 #31 可信终端指的是基于 trusted computing/attestation ，一个没有权限经过签名的系统除非你 exploit 了不然就是密码学意义上的无法绕过。
|
 |
34
deorth 269 天前 via Android
得加钱
|
|
35
liuhan907 269 天前
@Jirajine 那终究还是要在终端机器上做手脚，无非就是现在 Android bootloader 加现在 Google 商店那套验证。但那就已经是完全和现在的网络环境隔离开了，没有什么可行性。
|
 |
36
neoblackcap 269 天前
@rekulas 也不一定是 GFW ，很多企业防火墙都要提供审计功能。相当于识别你系统的流量，检测打工人是否在一直工作，有没有摸鱼呗
|
 |
37
iceheart 269 天前 via Android
这就是墙的需求吧。
如果只抓浏览器请求，ssl 用 sni ，http 抓头就够了 |
 |
38
cczh678 269 天前
想要做应用识别、用户行为识别？
|
|
39
rev1si0n OP |
|
41
rev1si0n OP @liuhan907
@DefoliationM @sampeng 话是这么说，TCP 内容层面看到的内容确实是无序随机的，但是，每个请求或者每个包，发出的接收到的流量，以及每个包之间的相对间隔通信端口地址等，大量数据去学习的话，应该是有一定规律的。 |
 |
42
shilyx 269 天前
访问百度同域名其他页面和访问首页在流量上没什么区分
域名不同还有点区分，https 里有明文域名信息 但 tls 的握手不会总是发生，有缓存的。因此包里没有也不代表没有访问 正解： 本机做透明代理，代理层做 tls 卸载 创建一个根证书，安装到系统受信任证书位置。根据 tls 握手包自动签发当前 dns 名称的证书，实现中间人攻击 浏览器层面无察觉  |
|
43
Jirajine 269 天前
@rev1si0n #41 能否识别取决于你要识别的到底是什么。如果只是站点域名，那有明文 sni 和 dns ，不用自己识别。以百度首页为例，百度首页的返回 body 大小应该是固定的，引用的其他资源应该也是固定大小的，根据这个特征可以大概判断访问的是百度首页还是其他页面。
|
 |
44
GenericT 269 天前
@Jirajine “百度首页的返回 body 大小应该是固定的”
你忘了 Content-Encoding 了，不同的 Accept 回来的东西不一样的，brotli 和 gzip 的长度显然不一样，不同的 CDN 节点的 compression level 也可能不一样 |
|
46
rev1si0n OP @Jirajine 并不是站点级别，是比站点更加详细的信息，比如，在看百度贴吧的帖子，那么看帖子出现的流量就是一个特征，不需要知道具体是访问了什么帖子，只需要知道在访问帖子。
|
|
49
shilyx 268 天前
特征只在于 tsl 握手环节，和 ip 地址
其他部分都是加密流量，即便认定了什么特征也不可靠，缘木求鱼 |
 |
51
NeedI09in 268 天前
在你能 proxy 这些请求的前提下。
1.中间人攻击，需要信任证书 2.抓 connect 请求，connect 请求是明文，能知道 host ，缺陷：连接层面的 connect 量，不能知道实际发了多少个请求，只知道实际 connect 了多少次。 |
 |
53
ben666 256 天前
TLS 连接握手部分是可以看到域名的明文的
方法 1： 网关上连接跟踪每个报文 方法 2：交换机上镜像一份报文，离线 现在网络上的报文处理很多用 DPDK 技术，可以看一些知名的 DPDK 项目，学习一下怎么用： 1. 测试仪 https://github.com/baidu/dperf 2. 4 层负载均衡 https://github.com/iqiyi/dpvs |
Select Language