如何检测猥琐的私有SDWAN隧道协议

在前面的一篇文章中,我给出了一种创建相对猥琐的假TCP隧道的POC:
https://blog.csdn.net/dog250/article/details/107025091

在运营商网络上玩overlay,有多种玩法。在私有协议之外,当然首选TCP,毕竟运营商待见啊!私有协议搞不好会被限制的。

所以TCP协议大有文章可做,传统的观点是对TCP做加法,比如优化其CC算法,增加其丢包探测等,但是这玩意儿有技术门槛啊,不如做减法!把TCP掏空到只剩下运营商设备能认出来的一个空壳子…

这种隧道可以欺骗中间转发设备相信它们是真正的TCP流,而这些设备同时一厢情愿地相信TCP会对它们的丢包,限速等行为作出有益的反馈。但是很显然,这是一场骗局。

最终,这种猥琐的隧道非但不会自我收敛,还会持续侵占大量的资源。

还有一些同样猥琐的隧道协议,美其名曰各类 自研协议

  • 标准UDP隧道,但将UDP协议号改成TCP协议号或者别的。
  • 标准TCP隧道,但将TCP协议号改成UDP协议号或者别的。
  • Raw IP隧道。

那么,中间转发设备就这么忍受被欺骗吗?它如何检测出类似这种假TCP隧道呢?

也不难:

  • 定期往两端发一些已经被ACK的数据,按照TCP规范,TCP应该回复dupACK/SACK。
  • 定期故意丢包,按照TCP规范,重传包总是会到来。

总之,就是按照TCP的规范,发送一些 端系统TCP一定会回应的报文 ,然后等待预期的回应,若没有收到,就知道自己大概率受骗了。

此时,中间设备即便是发送RST也不会有用,毕竟这可能是一条私有隧道,而两端运行的只是 看起来像TCP的协议 ,它们不是真正的TCP…

不过,隧道端点如果真的收到了RST,还是哎哟一下的好,以表示我被你打死了,适当配合一下没坏处。具体来讲就是,再也不用RST报文指示的四元组发包,稍微换个IP或者端口,然后假装来个SYN/SYNACK来回,以表示臣服。


浙江温州皮鞋湿,下雨进水不会胖。

©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值