这几天在搞BCTF，是一个简单的内网环境，放到国内，基本小厂的网络拓扑也就这个。
环境详情
- 攻击端192.168.16.103
- 外部的防火墙（出口主机）192.168.16.118
- Web端172.16.10.2 对外映射80端口到192.168.16.118
- Sever端172.16.10.3
内网里面就两台主机一台Server和一台Web，Sever仅对Web开放3306端口，攻击者只能通过访问Web主机映射到防火墙的80端口。
攻击思路：通过web端的RCE设置一个反向代理，进一步实现对Sever主机的攻击。
由于外部无法直接与172.16.10.3通信。但是172.16.10.2可以与192.168.16.111通信（此处解释一下
- 主要是172处于内网环境，攻击者只能攻击处于公网（192）上的机器，但是内网的机器只要网络出口处没有限制对外面的访问时没有限制的）
进入本文的主题：反向代理的解决思路
开源工具：frp https://github.com/fatedier/frp/releases
稍微介绍一下这个脚本
frpc 是放在客户端的，配置文件frpc.ini 里面需要指定请求的代理服务器的IP地址：
frpc.ini内容如下：
frps是放在服务端的，配置文件 frps.init里面需要指定服务端监听的端口
frps.init内容如下
此处需要反向代理建立socke5通道，实现代理访问内网中的sever服务器。
所以需要填写请求IP的客户端需要放在Web机器上面，去请求外部的攻击者的主机建立隧道实现代理攻击。
使用prxoychains + namp测试代理连接的强度
proxychains nmap -sT -Pn 172.16.10.3
可以成功扫描Server主机的端口，连接强度能够应对多个nmap扫描脚本的扫描。
--------------------------------------------------------------------------------------------------------------------------------
另外一种实现入侵内网的思路是：只开放80端口的主机拿到权限之后上传木马后，上传frps
补充一下socke5和http代理的知识：
- SOCKS作用在OSI模型的第五层也就是会话层上
- socke5使用的tcp与udp包转发，socke4使用的是tcp的包转发
- Socks 代理与应用层代理、 HTTP 在应用层，层代理不同，Socks 代理只是简单地传递数据包，而不必关心是何种应用协议（比如FTP、HTTP和NNTP请求）。所以，Socke代理比其他应用层代理要快得多。
这也是我一开始想要验证socke5代理是否真正能够传输数据的碰到的一个坑，我直接连接之后，使用proxychains ping 172.16.10.2发现根本ping不通，原因在于ping命令使用的是icmp协议，
亟待需要静静看看网络七层协议，时间都是挤出来的。
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------