本文作者：addadd，转载自FreeBuf.com
http://www.freebuf.com/sectool/145527.html
起因
目前较流行的SSH蜜罐有中交互的kippo cowire，高交互的honssh，都是基于twisted框架。在用这些蜜罐的时候想起来之前看python黑帽子用过paramiko库，非常好用，既能当ssh client又能当ssh server，模块的文档也非常详细，所以产生了基于paramiko写一个SSH高交互蜜罐的想法。
SSH蜜罐
低交互蜜罐主要实现了部分SSH协议，用于记录黑客爆破ssh的密码和入侵情报。
中交互蜜罐会给黑客模拟众多命令和返回结果，但是总是可以找到破绽，达到一条命令识别的效果。
高交互蜜罐要将系统做的更加逼真，所以用了一个真实存在的操作系统用于执行黑客的命令，但是SSH通信又是加密的，所以蜜罐需要能够代理SSH并记录黑客的交互，也就是它需要做到：
完整的提供ssh各项功能
获取入侵者要执行的交互或命令
与其他主机交互并执行命令
将得到的结果返回给入侵者
记录入侵者的所有行为
及时通知蜜罐管理人员
高交互要求
TCP服务器
paramiko模块提供ssh server服务需要一个传入已经建立连接的socket
因此直接使用了python自带的SocketServer模块的多线程tcp服务器ThreadingTCPServer
SSH服务
通过重写paramiko的ServerInterface类的各个方法，使一个正常的SSH Server变为一个SSH蜜罐
蜜罐要提供完整的SSH服务，也就是至少要提供：
认证(auth)
只提供password方式的认证
获取Shell并执行命令(shell)
最常用的ssh使用方式
单次执行命令(exec)
不会向系统请求shell，只执行单条命令
类似ssh root@server ‘netstat -autpn’
scp命令实际上使用的是exec通道
因此可将scp传输的文件从exec通信中解析出来
正向端口转发(direct)
SSH服务方向与端口转发服务方向相同
ssh -Nf -L 8000:localhost:80 root@server
访问本地8000即为访问server的80
反向端口转发(reverse)
SSH服务方向与端口服务方向相反
ssh -Nf -R 8000:localhost:80 root@server
访问server的8000即为访问本地的80
正向SOCKS5代理
SSH服务方向与代理服务方向相同
ssh -Nf -D 0.0.0.0:1080 root@server
实际上代理每一个连接调用一次direct正向端口转发
SFTP服务
由于SSH提供了隧道能力，其他不安全的明文协议可基于ssh隧道提供更安全的服务
paramiko提供了subsystem来提供对基于SSH隧道的协议支持
由于大多数SSH服务器都提供了SFTP子系统，所以作为SSH蜜罐SFTP也要支持，还要能够保存下来黑客上传的文件。
Wetland
wetland是这个蜜罐的名字，起的比较随意。
github地址 https://github.com/ohmyadd/wetland
Docker
docker作为轻量级虚拟化工具，很方便又提供了隔离能力
有些ssh蜜罐利用docker的python api，为每一个入侵者建立一个新的sshd容器
wetland没有采用这样的方式，一方面因为懒。。另一方面觉得这样做有些缺点
在wetland公网测试的过程中，发现入侵的往往是一个团队，会从不同的ip登陆，如果采用上述的方式很可能出现两人同时在线却找不到对方的情况，这样会暴露蜜罐服务
所以wetland简单的使用手动建立的一个sshd容器，不管谁登陆都能看到前人留下的痕迹
必要时可导出当前的docker容器取证，重建容器、更换公网ip，这样又是一条好汉(蜜罐)了
Auth
wetland只采用了password认证，方便攻击者爆破
服务器返回允许的认证方式使用paramiko.ServerInterface的get_allowed_auth方法
若认证成功会通过output插件通知管理者，通知方式我喜欢bearychat，还可以是email、短信之类的
Shell
当攻击者认证成功后可以请求一个shell
此时wetland会另开线程保持攻击者的shell和ssh容器shell间的通信。
在转发数据的同时会将其记录进shell.log中，可通过后文介绍的playlog脚本重放查看
Exec command
exec request只执行一条命令，会打开三条通道：stdin stdout stderr
如果命令立即执行完毕，三条通道会直接关闭
scp有自己的简单的协议格式，并通过这三条通道传输文件
wetland不会在exec通信进行中实时解析文件，而是通过playlog脚本解析出exec.log中攻击者上传的文件，并保存到相应的文件夹
Direct forward & Socks forward
执行ssh -fN -L 8000:localhost:80 8000:localhost:80 xxx操作后，实际只在本地开启服务器并监听8000端口
当有程序连接8000端口时，ssh客户端才会发送一个direct_tcpip_request
当收到一个request，正常的ssh服务器判断目的ip的目的端口(localhost:80)可以连接时，会建立两者间的通信
当收到一个request，wetland蜜罐会向ssh容器发送相同的请求，如果成功就建立并记录两者间的通信
Socks代理与正向端口转发的区别在于，代理每次请求访问的ip、端口可以是不同的
Reverse forward
执行ssh -fN -R 8000:localhost:80 xxx操作后，实际只在server端监听了8000端口
与正向端口转发类似，wetland只转发并记录通道中的通信
SFTP
wetland的sftp模块主要重写SFTPServerInterface
主要将入侵者的请求翻译为wetland作为sftp客户端的相应函数，在ssh容器中执行并记录
如果攻击者通过SFTP上传了文件，wetland会另外保存一份在download文件夹
Network
ssh代理的一个弊端就是，当在ssh容器中查看网络连接，比如netstat命令，看到的会是wetland主机的IP
当时意识到问题后没有想出好的解决办法，后来查看honssh的wiki发现他已经找到了解决方案，叫做高级网络设置
具体操作是为每个攻击者建立一个虚拟网卡，ip为随机值叫做fake ip
然后利用iptables的SNAT和DNAT，修改fake ip和ssh容器间tcp 22端口流量的src和dst，其他的通信走正常的路由，这样一来ssh容器中看到的ssh连接的源地址和攻击者的ip就一样了
wetland和ssh容器间建立socket连接前，需要先有一个bind操作 sock.bind((fake_ip, haker_port))
最后尽管ifconfig看到的ip是内网的，这也是比较正常的，外网的请求都是转发进来的
Playlog Clearlog
由于有的ip只爆破的密码或爆破成功但没有登陆执行命令，这样的日志还不在少数
util文件夹中的clearlog.py工具，可清理log文件夹，只留下含有实际操作的日志，并把用于爆破的账号密码集中整理保存
util文件夹中的playlog.py可以重放入侵者的各种命令、流量
重放日志分为四类，shell、exec、direct、reverse
shell类会输出所有ssh服务返回的字符，也就是能看到所有入侵者能看到的字符，输出分割为单条命令，回车输出下条命令的结果
exec类会解析保存log中所有通过scp传输的文件，并且打印所有的命令和结果
reverse、direct类会打印出两个方向的通信内容
安装
可以查看github上的README，只需要安装所需的python库，并选择性的配置p0f、通知插件等额外功能就可以了
效果
我部署了一个wetland蜜罐在腾讯云学生机上，四五天可以捕获这么多扫描或攻击
经过clearlog脚本处理后，剩下有效入侵ip
使用playlog脚本，可以重放exec.log
可以看到入侵者下载了一波脚本，每个脚本都是另外下载一批木马，适配了各种架构
逆向的小伙伴可以分析一波
今天看文章发现，360天眼团队已经在六月份报告过46.218.149.85这个法国ip了
这个服务器是作为各种恶意程序的下载服务器，微步在线上也有相应记录
最后
这个项目只是当初的一个想法，目前还在慢慢完善
如果有问题希望能发邮件给我，ohmyadd@gmail.com，我会及时回复哒