蜜罐学习
蜜罐学习
蜜罐是用来引诱和欺骗攻击者,并且通过记录攻击者的攻击日志来产生价值。
1 蜜罐种类
低交互蜜罐:允许简单的监听,有简单的交互甚至可能没有响应返回(例如21端口,我们访问端口,蜜罐根据请求模拟进行对应的响应返回)
高交互蜜罐:高度模拟服务,允许入侵成功,并且一举一动都会进行监听
1.1 开源蜜罐介绍
https://github.com/desaster/kippo 具有交互的ssh蜜罐 能够记录暴力攻击和shell交互
https://github.com/hacklcx/HFish 北京微步在线科技有限公司产品 可以直接进行docker安装
登陆地址:https://你docker主机的ip:4433/web/
初始用户名:admin
初始密码:HFish2021
登录进来之后有两种模式:既然只是进行测试来用当然使用sqlite,顺便好好看看蜜罐的后台
内部共有40个基础的低交互蜜罐
当我使用本机对mysql进行mysql连接时,Hifsh进行了简单的界面模拟。不论你输入什么密码,都能够进入mysql,之所以是低交互是因为当你输入一些sql命令时蜜罐不能继续进行交互,无法做到高仿
1.2 手敲蜜罐
1.2.1 python
python有这样一个包
https://github.com/twisted/twisted
Twisted 是一个基于事件的互联网应用程序框架,支持 Python 3.6+。它包括用于许多不同目的的模块,包括:
twisted.web
: HTTP 客户端和服务器、HTML 模板和 WSGI 服务器twisted.conch
: SSHv2 和 Telnet 客户端和服务器以及终端仿真器twisted.words
:用于 IRC、XMPP 和其他 IM 协议的客户端和服务器twisted.mail
: IMAPv4、POP3、SMTP 客户端和服务器twisted.positioning
: 与 NMEA 兼容的 GPS 接收器通信的工具twisted.names
: DNS 客户端和工具,用于制作您自己的 DNS 服务器twisted.trial
:与基于 Twisted 的代码很好地集成的单元测试框架。
只需要在对应的位置返回模拟端口服务的响应即可完成低交互
from twisted.internet import reactor, protocol
from twisted.internet.protocol import connectionDone
class TEST(protocol.Protocol):
# 接受到数据后会立即执行的函数
def dataReceived(self, data):
print(data)
# 接收到连接请求立即执行的函数
def connectionMade(self):
pass
# 断开连接会立即执行的函数
def connectionLost(self, reason=connectionDone):
print('客户端断开连接')
def main():
factory = protocol.Factory()
factory.protocol = TEST
reactor.listenTCP(8000, factory)
reactor.run()
if __name__ == '__main__':
main()
python写的 kippo源码就用到了twisted模块
1.2.2 go
《白帽子安全开发实战》赵海峰 第八章蜜罐源代码 https://github.com/netxfly/sec-dev-in-action-src/tree/main/honeypot
推荐环境:ubuntu (windows环境不支持书中一些监听数据包的代码)
这个蜜罐分成了三部分:
第一部分就是用来进行监听和转发,将接受到的指定的某些端口访问的内容转发到高交互模块,同时为了判断攻击者大范围端口扫描也会监听其他所有端口,将端口探测的流量传到日志部分。
第二部分高交互部分,尽可能模拟真实的响应,并且将攻击者进一步的请求传到日志部分
第三部分日志模板,记录分析攻击者
通过读源代码其实发现了有一些小瑕疵(for------go),速度快的电脑不会出现问题,但是电脑如果运行速度慢并且后台开的东西多,并且forwardPolicy很长。go func可能反应不过来导致很多func执行的是同一个item。可能大佬没有注意这一点。
2 蜜罐指纹
- 蜜罐很多都是模拟响应
- 某个蜜罐很火很多人去用
- 既然是模拟那就一定会是代码模拟
- 有代码模拟==一定存在有规律的响应
- 有规律的响应== 可以总结出指纹
- 总结出指纹 == 被网络测绘系统识别
- 蜜罐魔改 改变模拟的响应 接着跳回2.
蜜罐归根结底就是一个能给你返回一些字符串的并且能够记录你交互信息的小程序,有返回的字符串就一定有规律。蜜罐编写者不可能天衣无缝。
这里对隔壁360Quake公众号蜜罐指纹文章进行部分内容引用
这里360的团队对常见的蜜罐部分端口进行了分析
这里将识别方法可以归结为以下几点
2.1 测试遗留的意外代码
HFish蜜罐中实现了Telnet协议,默认监听在23端口。模拟的该协议默认无需验证,并且对各个命令的结果都做了响应的模板来做应答。在命令为空或者直接回车换行时,会响应default模板,该模板内容为test。因此可以利用这个特征进行该蜜罐在telnet服务上的检测如图所示。
2.2 明显特征
比如返回web界面某些特殊的数据、端口响应返回固定的字符串、响应的上下文几乎一模一样等等
2.3 Fuzzing特征
本来想通过一些发送一些数据包对返回的响应进行正则匹配,结果好家伙直接匹配大一匹内容,这种就是把我是蜜罐四个大字贴到了脸上
2.4 协议缺陷蜜罐报错
编写的蜜罐不可能所有版本的协议都百分百支持,当蜜罐遇到不认识的协议请求,很可能就会返回谜之响应或直接爆某些错误
3 欺骗防御系统
传统蜜罐单独部署在业务的内网系统中,在真实网络中部署的比较少。
欺骗防御系统是对蜜罐的进一步利用,可以将传统蜜罐部署在现成的生产系统中,在真实的系统设置大量的虚假服务(可能比真实的服务还要多),攻击者只要触碰到其中任一个服务就会被检测出来。欺骗防御系统是与业务系统安全的融合在一起的。
当虚假服务极其多的时候有时候连攻击者都不知道自己想攻击的是什么?就算知道想攻击什么,蜜罐经过魔改抹除了对应的标志后无法使用工具去识别的时候,愚蠢的攻击者就需要一个接着一个的手动去寻找真实的目标。如果攻击者很聪明且有条件的话就会悄没声进行监听流量,真实的目标一定会有流量经过长时间的潜伏判断出真实的目标。这里又有了其他问题,虽然有些流量是经过加密了,但是加过密的真的安全吗?为什么来自西方的DES对称加密有固定矩阵值,经过数学运算是否会有解密的后门...胡思乱想ing...