[ssl]解密-网络监控 -

j4s0nh4ck

浏览: 285041 次

最近访客更多访客>>

XiaoPY

zhanchaomao1987

vicen888

prontosil

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

[ssl]解密-网络监控

博客分类：

原文：http://resources.infosecinstitute.com/ssl-decryption/

SSL和网络监控是最不搭的一对的基友-即使是最高端的监控架构。从被加密的数据流中不会获得很多有价值的信息。考虑到如下图所示的Sguil sensor的处境：

web服务器使用SSL意味着基于事件监控的网络很头疼。Snort也不能很好的帮助发现入侵-它只看到HTTPS。同时，如果一个事件被其他方法发现(通知，web服务器log等)，Sguil的全包截获的调查价值也很少。
通过窃取SSL，可以可视化这些捕获的数据流。可以使用下面的方法：
1. 在web server前端结束SSL，可以使用反向代理负载均衡或WAF。然后可以在负载均衡和web server之间监控流量。
2. 在web service进行流量监控，可以增加web和应用程序的log级别
3. 给现存的监控平台提供SSL session解密的方法
每种技术都有优缺点，本文将介绍如何使用最新的技术来让Sguil透明监控流量。

SSL解密
首先需要了解关于SSL解密的一些基本知识。总体来说，需要满足两个条件：
1. 服务器必须使用RSA密钥交换机制，幸运的是大多数基于SSL的服务器都是使用这种机制；如果使用的是DSA密钥对或Diffie-Hellman密钥交换机制，那么可能失败
2. 必须能访问服务器的私有密钥，可以把它拷贝到你的Sguil监控器上。
第二条是说我们只能解密源/目的是我们拥有的server的流量-我们不可能解密任意流量。然而从入侵发现和网络取证的角度来说，已经足够了。
Now, where did I leave my keys…?
导入私有密钥到Sguil监控器需要一些工作。密钥可能存在服务器上的一个.pem文件中，把它copy到Sguil监控器中。然而某些OS例如Windows存储认证和密钥在"certificate store"中而不是.pem文件。为了获得私有密钥，我们需要导出certificate和私有密钥到一个PKCS12文件。一旦我们导出certificate，我们可以像这样使用openssl提取私有密钥。
C:>openssl pkcs12 -in c:myExportedCertificate.pfx –out c:myExportedCertificate.pem -nodes
输入导出certificate和密钥时的密码，myExportedCertificate.pem文件将会包含类似下面的块
—–BEGIN PRIVATE KEY—–
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCvHJFIpFwXZJ0x
2DzEY2B4MDBBu/+jbfUriFI+GKh6Q5oEGTAARh3OAP+UMedNf2t8/MVJdEEAM7TQ
<snip>
EZq3TiCB3e+GSjVRorB0YGvDzHR1V098LEPOvPIKNMcLCC4lGQeTg+usZmtcx4VI
wGI70e4Byd+Lba0lUKY8UIU=
—–END PRIVATE KEY—–
复制粘贴到名为myPrivateKey.pem的文件然后保存到Sguil上。
A word of warning
服务器的私有密钥是敏感信息。通过它，黑客可以解密服务器的SSL流量以及使用它和certificate来伪装成一个合法的服务器。必须小心处理私有密钥-不要放到临时文件夹，确保不会泄露到互联网上，确保Sguil上的密钥也受到保护。
Putting the key to work
拥有了私有密钥，我们可以将Wireshark指向我们捕获全文本的文件夹。这种方法的性能不是很好；如果能够通过使用管道我们可以把我们解密后的流量实时的导入Sguil，充分利用Snort，SANCP，PADS。
Dmitry Plashchynski的 viewssld就是这样的工具。基本上viewssld工作原理如下：

viewssld通过libpcap来监听一个给定的接口。捕获的数据帧传递给Atomic Lab的libdssl库来解密。libdssl是只有解密后的package内容，所以使用libnet来构造伪造的解密后的流量。伪造的流量然后定向到Sguil。
viewssld包含：
1. 输出解密后的TCP三路握手
2. 输出解密后的客户请求和服务响应，保持更新(伪装的)TCP序列号。序列号和其他的TCP/IP头是虚假的一一对应的-因为解密后的流量和压缩的流量大小不一样，所以不可能使用真实的值。解密后的流量可能会不同于原始流量的分包/分段
3. 当一个session结束时输出一个伪造的RST
4. 使用一个简单的标识表明哪些是viewssld的输出
5. 输出的解密帧到不同于他们被截获的端口。
第五条整合viewssld和Sguil如下图：

它的流程如下
1. 原始数据(蓝色)进入Sguil监控接口
2. 这些流量被Sguil和viewssl同时截获
3. viewssl解密数据，然后送回它截获的接口。只用通过使用一个不用的TCP端口接收解密的数据帧才能实现--如果使用相同的端口那么将会重新进入viewssl。
4. 解密的SSL数据流有Sguil捕获
所以可以同时看到加密/解密的数据流。如下图所示：最后面可以看见两行SANCP查询结果。第一行是Sguil捕获的原始SSL数据包。第二行是对应的有viewssld解密的端口号为80的数据包。

一个参考的配置文件：
# PID-file path (default: /var/run/viewssl.pid)
pid = /var/run/viewssl.pid

# daemonize? on/off (default: off)
daemon = on

# loglevel 0-10 (default: 0)
loglevel = 10

# SSL protocols to decrypt

[webserver]
src = eth1
dst = eth1
ip = 10.11.12.13
port = 443
key = /etc/viewssld/webserver.key
dsslport = 80

[mailserverSMTP]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 465
key = /etc/viewssld/mailserver.key
dsslport = 25

[mailserverIMAP]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 993
key = /etc/viewssld/mailserver.key
dsslport = 143

[mailserverPOP3]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 995
key = /etc/viewssld/mailserver.key
dsslport = 110

警告：
在部署viewssl到Sguil监控器上时需要考虑：
1. SSL解密需要耗费大量的CPU计算。如果你的监控器的CPU已经很忙碌，那么额外的负载可能使他崩溃。
2. 解密过程对于package丢失很敏感。如果viewssld缺少一个package，该流量解密将会停止。如果SSL握手丢失，那么根本不会解密。
4由于需要存储加密/解密后的流量，硬盘很重要。