安全路透社
当前位置:安全路透社 > 网络转载 > 正文

基于Paramiko的高交互SSH蜜罐

*本文原创作者:addadd

起因

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

SSH蜜罐

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

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

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

  1. 完整的提供ssh各项功能

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

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

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

  5. 记录入侵者的所有行为

  6. 及时通知蜜罐管理人员

高交互要求

TCP服务器

paramiko模块提供ssh server服务需要一个传入已经建立连接的socket

因此直接使用了python自带的SocketServer模块的多线程tcp服务器ThreadingTCPServer

SSH服务

通过重写paramiko的ServerInterface类的各个方法,使一个正常的SSH Server变为一个SSH蜜罐

蜜罐要提供完整的SSH服务,也就是至少要提供:

认证(auth)

  1. 只提供password方式的认证

获取Shell并执行命令(shell)

  1. 最常用的ssh使用方式

单次执行命令(exec)

  1. 不会向系统请求shell,只执行单条命令

  2. 类似ssh root@server ‘netstat -autpn’

  3. scp命令实际上使用的是exec通道

  4. 因此可将scp传输的文件从exec通信中解析出来

正向端口转发(direct)

  1. SSH服务方向与端口转发服务方向相同

  2. ssh -Nf -L 8000:localhost:80 root@server

  3. 访问本地8000即为访问server的80

反向端口转发(reverse)

  1. SSH服务方向与端口服务方向相反

  2. ssh -Nf -R 8000:localhost:80 root@server

  3. 访问server的8000即为访问本地的80

正向SOCKS5代理

  1. SSH服务方向与代理服务方向相同

  2. ssh -Nf -D 0.0.0.0:1080 root@server

  3. 实际上代理每一个连接调用一次direct正向端口转发

SFTP服务

  1. 由于SSH提供了隧道能力,其他不安全的明文协议可基于ssh隧道提供更安全的服务

  2. paramiko提供了subsystem来提供对基于SSH隧道的协议支持

  3. 由于大多数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蜜罐在腾讯云学生机上,四五天可以捕获这么多扫描或攻击

wetland蜜罐捕获的攻击

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

有效入侵ip

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

playlog脚本 重放exec.log

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

效果

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

今天看文章发现,360天眼团队已经在六月份报告过46.218.149.85这个法国ip了

这个服务器是作为各种恶意程序的下载服务器,微步在线上也有相应记录

最后

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

如果有问题希望能发邮件给我,ohmyadd@gmail.com,我会及时回复哒

*本文原创作者:addadd

未经允许不得转载:安全路透社 » 基于Paramiko的高交互SSH蜜罐

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册