Writing

HTTPS代理蜜罐

安全, 情报, 蜜罐

0x00 背景

情报系统中，代理蜜罐是非常重要的一环。通过这个蜜罐，我们可以收集到诸如撞库、扫号甚至0day等实时的攻击信息。

目前市面比较通用的有两种代理工具：Squid和Nginx。因为Nginx的配置文件清晰简单、Lua模块非常方便后期功能拓展，所以我们的代理蜜罐里选择了Nginx，但是Nginx并不支持CONNECT方法，而官方在将来也不打算支持^1。HTTPS已经越来越普及，如果一个蜜罐不能代理HTTPS，那么会大大降低其所能收集到的信息量。通过实验，我们采用了Squid和Nginx结合的架构，来实现同时支持HTTP和HTTPS的透明代理。

0x01 HTTP代理

普通HTTP代理原理非常简单，这里不过多赘述。原理见《HTTP权威指南》中图：

web_proxy
图1

0x02 HTTPS代理

HTTP协议中是通过HTTP Tunnel来实现HTTPS代理的。

HTTP 客户端通过 CONNECT 方法请求隧道代理创建一条到达任意目的服务器和端口的 TCP 连接，并对客户端和服务器之间的后继数据进行盲转发。

具体流程，同样见《HTTP权威指南》中图：

web_tunnel
图2

如上图所示，假设我要通过代理访问目标站，首先浏览器发送CONNECT请求到代理服务器（步骤a），代理服务器这个时候会尝试和目标服务器的443端口建立一个TCP连接（步骤b），建立成功代理服务器返回200给客户端（步骤d），之后代理服务器的作用和HTTP代理中一模一样，原封不动地转发数据包即可。

而上述过程虽然可以达到HTTPS代理的效果，但在代理服务器（蜜罐）中，我们获得的只是加密了的HTTP请求，对蜜罐来说没有任何意义。

0x03 蜜罐

Nginx不支持HTTPS代理的唯一原因，就是它不支持CONNECT方法。所以我们让Squid处理完CONNECT请求之后，其余的包再交给Nginx转发。架构如下图：

honeypot

可以看到，过程几乎是和普通HTTPS代理一样的。唯一的trick在于，我们给Squid设置了一个Fake DNS，所谓Fake DNS就是无论解析什么域名，都返回127.0.0.1。这里的Nginx既充当了一个假的目标站，又充当了代理转发的角色。

这里，大家应该会发现存在一个问题。那就是客户端在验证证书的时候会失败，因为真正访问的“伪目标站”的Web服务器Nginx使用的是一个自签名证书。

不过，我们的目标并不是作一个真正的代理服务器，目标用户是那些使用脚本来进行攻击的黑产们，而大部分脚本在处理HTTPS请求里会关闭证书验证，这让我们有机可乘。

既然证书用的是咱们的自签名证书，那么解密流量自然是简单的事情，通过配置Nginx的日志格式，我们可以记录到所有我们需要的信息。

0x04 后续

之后就是把日志发送到我们的分析平台，可以使用flume、rsyslog等等工具。通过机器学习，URL分类我们可以发现流量中的攻击流量……

这些就是另一篇文章该写的了。

参考