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了这个服务器是作为各种恶意程序的下载服务器,微步在线上也有相应记录
这个项目只是当初的一个想法,目前还在慢慢完善
(来源:红客学院)
标签: hbase客户端管理
评论列表
(direct) SSH服务方向与端口转发服务方向相同 ssh -Nf -L 8000:localhost:80 root@server 访问本地8000即为访问server的80 反向端口转发(reverse) SSH服务方向与端口服务方向
块提供ssh server服务需要一个传入已经建立连接的socket因此直接使用了python自带的SocketServer模块的多线程tcp服务器ThreadingTCPServer >>>> SSH服务 通过重写