01

　　起因

　　目前较流行的SSH蜜罐有中交互的kippo cowire，高交互的honssh，都是基于twisted框架。在用这些蜜罐的时候想起来之前看python黑帽子用过paramiko库，非常好用，既能当ssh client又能当ssh server，模块的文档也非常详细，所以产生了基于paramiko写一个SSH高交互蜜罐的想法。

　　02

　　SSH蜜罐

　　低交互蜜罐主要实现了部分SSH协议，用于记录黑客爆破ssh的密码和入侵情报。

　　中交互蜜罐会给黑客模拟众多命令和返回结果，但是总是可以找到破绽，达到一条命令识别的效果。

　　高交互蜜罐要将系统做的更加逼真，所以用了一个真实存在的操作系统用于执行黑客的命令，但是SSH通信又是加密的，所以蜜罐需要能够代理SSH并记录黑客的交互。

　　它需要做到：

　　完整的提供ssh各项功能

　　获取入侵者要执行的交互或命令

　　与其他主机交互并执行命令

　　将得到的结果返回给入侵者

　　记录入侵者的所有行为

　　及时通知蜜罐管理人员

　　03

　　高交互要求

　　>>>>

　　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类会打印出两个方向的通信内容

　　04

　　安装

　　可以查看github上的README，只需要安装所需的python库，并选择性的配置p0f、通知插件等额外功能就可以了

　　05

　　效果

　　我部署了一个wetland蜜罐在腾讯云学生机上，四五天可以捕获这么多扫描或攻击

wetland蜜罐捕获的攻击

　　经过clearlog脚本处理后，剩下有效入侵ip

有效入侵ip

　　使用playlog脚本，可以重放exec.log

playlog脚本 重放exec.log

　　可以看到入侵者下载了一波脚本，每个脚本都是另外下载一批木马，适配了各种架构效果

　　逆向的小伙伴可以分析一波

　　今天看文章发现，360天眼团队已经在六月份报告过46.218.149.85这个法国ip了这个服务器是作为各种恶意程序的下载服务器，微步在线上也有相应记录

　　这个项目只是当初的一个想法，目前还在慢慢完善

（来源：红客学院）