近段时间,黑盒测试的工作越来越多,packetdrill用到的也就水涨船高,脚本量在不断地膨胀。可是,网上的资料依旧是少的可怜,只好在摸索中前进。咦嘘乎!只得在碰壁中不断进化。
对于packetdrill,大量的写脚本并非难事,可恶的是对脚本的理解。 Google对待packetdrill的态度不比它其他的孩子,除了书写规范和一堆范例,很难找到其他的脚本指南。于是,在脚本这点上吃尽了苦口。
但没办法,除非我愿意花大量时间去解构代码,但我没有,我的目的只是用packetdrill去达到我的目的罢了,仅此而已!
但大量试错和脚本分析后,我还是摸到了packetdrill在脚本定义和分析上的一些脉络,于是我等不及Google的更新,在它之前就打算披露出来,原因无外乎是,想让packetdrill被更多人认识和使用,既然Google还没做,我就先一点点补充好了。
一个正确的脚本,关键点在于注入包和检验包的书写。 其他的部分,方便被“终端”检查出来。只有这里,在掌握了一定的逻辑后,就能很轻松的写自己需要的脚本和分析别人的脚本了。
根据图解,一点点来解构下packetdrill脚本。
还是拿了TCP举例。
首先,packetdrill在写一个脚本时,都会扮演C/S的一个角色,可能是客户端,或是接收端。在确认角色后,都应该学会站在这个角度上看问题。
对于三次握手而言,packetdrill总是从client到server的握手,这里不需要担心,在脚本中这里几乎保持一致。
在TCP established中,发包操作是从角色处触发,而 “ACK应答” 自然是对端触发的。所以packetdrill对于注入包,是两端都可以注入,只需要注意“发包操作”和“ACK应答”的规范即可。
而packetdrill对于检验包,是与注入包有些许不同的。
检验包时,packetdrill总是只在自己扮演的角色处有检验点,只对自己的端验证。而因为对端是不可掌握的(没有检验点),所以不能对对端的“包行为”检验。
按图解,如果我们站在了server端。
+0 > . 1:1(0) ack 7001 win 257
这样的写法是错误的。但我们总会犯下这样的错误,却浑然不知。
最后,packetdrill四次挥手亦是从client到server,没有什么好说道的,就此画个句号。
写在最后
packetdrill 是一个好用的黑盒网络验证工具,搭配上EBPF基本是事半功倍的。
痛点嘛,无外乎是Google对于packetdrill的忽视。但这也不影响什么,packetdrill借力于开源,必然还是大有可期的。
写完后,发现也并不像是一篇指南,但貌似又想不出什么切合的标题,遂作罢。