Open L-codes opened 3 years ago
首先,目前的正向代理是可以加密的(iox proxy -l
的参数支持加*),但需要本地用iox fwd起一个agent
你的需求可以通过上述类似的方法实现多路复用,但这样非多路复用的正向代理就没法用了(类似反向代理仅支持多路复用,但正向代理是不需要双端配合的)
新增子命令可行,但容易增加复杂度和造成参数上的混乱,也不够统一
初步构想,通过提供一个新的flag(例如at)来表示开启socket的多路复用,做到所有模式下的统一,比如
iox proxy -l @*0.0.0.0:9999 -k ff
iox fwd -l 1080 -r @*1.1.1.1:9999 -k ff
结合 pwd
让 socks5
加密这个可以!
随便想提提 *
标记作为加密这个设计不太好,因为在 zsh 中会当做是通配符,则需要添加单引号 '*0.0.0.0:9999'
并且还有 *:9999
的歧义问题
换成字母形等表示会否更加好?如 m = Multiplexing, s = secret 则加密复用端 ms:0.0.0.0:9999
确实星号属于设计失误,最初没有考虑到bash的解析。也导致了与Go接受:PORT
参数结合而产生的歧义
用字母表示确实是更优的设计,感谢
思考了一下,换成字母标记也不够好,建议重新设计UI逻辑,因为加密和多路复用功能是 iox 私有的通讯协议,即 iox 两端连接的协议才支持加密和多路复用,并且在 iox 需要两端连接时,由于多路复用的优势明显应默认开启,那有两个方案:
方案一 (即目前上面讨论的方案) iox 自动识别连接端是否 iox,自动启用多路复用,检测是否有 -k 参数存在则自动对 iox 间尝试进行加密通讯 但是存在 正反向 socks 不统一的问题,(并且反向 socks 还需要按顺序。。。我老是记错),如:
反向 socks 使用
./iox proxy -l @*0.0.0.0:9999 -k ff
./iox fwd -l 1080 -r @*1.1.1.1:9999 -k ff
正向 socks 使用
./iox proxy -r 1.1.1.1:9999
./iox proxy -l 9999 -l 1080 // notice, the two port are in order
方案二 类似 socat 一样,为连接端标记类型,这样所见即所得,并且不区分两端参数左右顺序
两端的链接格式,类似 socat
<mark>:[ip:]<port>
mark:
tcp -- TCP 连接(协议命名,也方便后续如果有 udp 协议等)
tcp-l -- TCP 监听
proxy -- proxy 监听 (因为 proxy 暂时只有监听,后续要是考虑支持 socks 连接转发隧道,则可以恢复 proxy-l 的命名; 如果还考虑更多的 socks4a 等协议,建议 proxy 改名为 socks5)
iox -- 这里说的是 iox 自己的通讯协议连接,即 `-k` 可选的加密并默认的就是多路复用协议(也可以通过添加参数禁用多路复用),但是这是 iox 自己的协议,命名暂未想到好的这里称叫 iox...
iox-l -- iox 私自可加密的多路复用协议监听
TCP 端口转发 (没有过多的变化)
./iox fwd -l 8888 -l 9999 => ./iox tcp-l:8888 tcp-l:9999
./iox fwd -l 8888 -r 1.1.1.1:9999 => ./iox tcp-l:8888 tcp:1.1.1.1:9999
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999 => ./iox tcp:1.1.1.1:8888 tcp:1.1.1.1:9999
本地 proxy (没有过多的变化)
server: ./iox proxy -l 1080 => ./iox proxy:1080
反向 proxy (不会搞混 socks 是连 9999 还是 1080,`proxy:1080` 已经标记了)
server: ./iox proxy -l 9999 -l 1080 => ./iox iox-l:9999 proxy:1080
client: ./iox proxy -r 1.1.1.1:9999 => ./iox iox:1.1.1.1:9999
正向 proxy (其实与反向是相对的,仅 iox 协议两端连接方向发生变化,也清晰知道 socks 是 cilent 端的 1080)
server: ./iox proxy -l 0.0.0.0:9999 => ./iox iox-l:9999
client: ./iox fwd -l 1080 -r 1.1.1.1:9999 => ./iox proxy:1080 iox:1.1.1.1:9999
补充说明:
-k 参数仅对 iox iox-l 端协议生效
如有必要后续可以补充一个参数,让 iox 自己的协议,关闭多路复用
对比之下,方案一要实现自动检测才能省去标记加密和多路复用的麻烦,并且正反向代理的不统一,两端参数还需要有序要求,暴露出很多设计问题,而方案二简单理解就是给 socat 添加了,两个协议 proxy 和自己的可加密多路复用协议 iox,也同样方便后续的协议支持扩展,建议重新设计使用第二个方案,使用逻辑更加简单,扩展性也更加好~
针对上面的方案二,加一个补充
因为 iox 协议是计划作为 iox 多端间通讯的协议,目前是基于 tcp 的,而我看该项目 github 的标签中包含 pentest
的定位,应当考虑,后续 iox 间通讯要有 kcp
(UDP的RRQ协议)、icmp
等支持,在渗透中才能发挥出更大的作用,所以 iox 协议,可能改成 itcp 表示基于 tcp 的 iox 协议,则 kcp icmp 等可以为 ikcp
iicmp
等。
但如果考虑编译后文件大小的问题,也可以将基于 tcp kcp icmp 等各个分开编译版本,这样 iox 协议的命名任可以直接使用,而无需 ikcp itcp 等不同命名
方案二有些混乱,比如正向代理iox proxy:1080 iox:1.1.1.1:9999
只是把本地流量处理后转发到远端,和上层协议是无关的。把加密和多路复用看作新协议有违直觉,而应该视作iox构建了一个传输层信道,这样对每一个socket都可以通过flag指定信道特性,并且特性可以自由组合(或扩展新特性,比如压缩、使用不同协议传输)
方案一不需要自动识别的,完全由用户指定的flag决定
至于扩展其他协议的通信信道,icmp/dns可行,但因为是包协议,项目逻辑需要大改,并且需要自实现ARQ。kcp虽然是现成的ARQ协议,但由于它会发送大量冗余流量提高速度,并不适合渗透中使用
”方案一不需要自动识别的,完全由用户指定的flag决定“ 我是觉得不加flag进行使用的设计,则需要自动识别
方案二 没明白混乱的点,逻辑确实是 上面拟作的 iox协议 只作为连接两端,实现 proxy的转发,逻辑应该是没错的
正向 proxy (其实与反向是相对的,仅 iox 协议两端连接方向发生变化,也清晰知道 socks 是 cilent 端的 1080)
server: ./iox proxy -l 0.0.0.0:9999 => ./iox iox-l:9999
client: ./iox fwd -l 1080 -r 1.1.1.1:9999 => ./iox proxy:1080 iox:1.1.1.1:9999
正向代理中 ./iox iox-l:9999 这一端,只有一个参数,没有进行转发等,所以 另一端的 proxy:1080 收集socket 进行转发到 iox-l:9999 这一端服务器上进行连接
kcp 的 ARQ 发送大量冗余提高速度这个确实不知道,感谢提醒~
另外,如采用方案二确实项目逻辑需要大改,方便的话可否发送 wechat
账号给我邮箱(bC1jb2Rlc0BxcS5jb20K),方便交流?
你感受一下,正向代理只做单端
server: iox proxy -l m:0.0.0.0:9999
client: iox fwd -l :1080 -r m:1.1.1.1:9999
想了想,不同协议传输信道也不需要大改,为ARQ协议实现Ctx.Read /Write
即可
情况:A 端能正向访问 B 端的某个端口,想通过 A 端走 socks 服务访问 B 端后的网络,如果在 B 段
iox proxy -l xxx
可以满足需求,但这样如果连接过多 A 端与 B 端的TCP连接会很多,并且 A -> B 的socks 暂时是明文的解决思路:iox 支持正向 proxy 功能, A -> B 建立 iox 的多路复用连接,在 A 端开启 socks 连接到 B 端 如: