chisel工具的使用
正向转发和反向转发:
正向转发:客户端(本地机器)主动连接目标服务器,然后将本地端口的流量转发到目标服务器的指定端口。
反向转发:被控制端(通常在内网的机器,比如靶机)主动连接控制端(如攻击者的服务器),然后控制端将指定端口的流量反向转发回被控制端的指定端口。具体来说:被控制端(靶机)通过建立连接告知控制端(kali)在其自身的某个端口上监听,当有外部流量访问控制端的这个监听端口时,控制端就把流量通过已建立的连接转发给被控制端。
靶机不出网的情况:利用中间人主机(跳板机)
1 | |
端口转发:
正向转发:(外部请求 → Kali的1111端口 → chisel隧道 → 靶机的8000端口)
1 | |
kali(服务器)
反向转发:(服务端(Kali)接收请求 → 转发到客户端(靶机))
1 | |
靶机(客户端)
反向转发:
1 | |
192.168.215.222 ==>kali_IP地址
7080 ==> Kali 上 chisel 服务器监听的端口
R ==>反向转发
1111 ==> kali上监听的端口
127.0.0.1:80 ==> 靶机(客户端)的本地服务地址的 80 端口 (需要转发的端口)
& ==> 后台执行 //可通过
jobs命令查看后台任务,用fg恢复到前台。
执行此命令后:
靶机会主动连接到 Kali 的
7080端口。Kali 会监听本地的
1111端口。当有流量访问 Kali 的
1111端口时,数据会通过隧道转发到靶机的 80 端口(如 Web 服务)。Kali 知道监听
1111端口是因为:- 规则明确指定:在靶机执行的
chisel命令中,R:1111:127.0.0.1:80直接告诉 Kali 要监听1111端口。 - 隧道通信机制:
chisel通过已建立的连接(7080端口),将转发规则从靶机传递给 Kali。
- 规则明确指定:在靶机执行的
理解:
正向是指:靶机主动连接服务器,kali是按照靶机的指示监听端口(1111)并转发,不主动做任何事情。(控制权在靶机)
反向是指:靶机也主动连接服务器,kali主动帮你监听端口(1111),主动等待用户上门,收到请求后再通过端口告诉靶机(控制权在服务端)
| 场景 | 正向转发(客户端教服务端) | 反向转发(客户端委托服务端) |
|---|---|---|
| 你(客户端) | 在小区里(内网),能出门给总店送蛋糕 | 被封在小区里(严格内网),出不去 |
| 总店(服务端) | 在马路边(公网),等你留指令 | 在马路边(公网),你让它主动摆摊 |
| 如何卖蛋糕 | 你告诉总店:“有人在你这订 1111 蛋糕,喊我来送!”(总店被动转发) |
你让总店:“你摆个 1111 摊位,有人来买蛋糕,你喊我,我从小区里递出来!”(总店主动摆摊等客) |
| 谁更主动 | 客户端主动留指令,服务端被动执行 | 客户端主动委托,服务端主动 “揽客” |
Socks5代理:
和端口转发的区别:
- Socks5 代理 是「替你做事的中间人」,全程代表你与目标服务器交互,隐藏你的身份并处理所有协议细节;
- 端口转发 是「数据管道的搬运工」,仅按端口号把数据从 A 传到 B,不关心你在做什么,也不隐藏你的身份(除非配合 NAT 等机制)。
chisel默认端口是1080
基础使用:
kali: (需要使用kali自带工具proxychains4)
改一下proxychains4的配置文件(vim /etc/proxychains4.conf)默认是9050端口,需要改为
1 | |
kali:
1 | |
靶机:
1 | |
进行攻击:
1 | |
何时选择哪种方式?
- 选端口转发:
- 仅需访问特定服务(如单个 Web 应用或数据库)。
- 需要精确控制端口映射。
- 安全性要求高(仅开放必要端口)。
- 选隧道:
- 需要全局访问内网资源(如测试整个内网环境)。
- 不确定具体需要访问哪些服务。
- 希望简化配置(避免为每个服务单独设置转发)。