http/https镜像流量的解析问题

最新推荐文章于 2024-04-15 15:12:09 发布

weixin_33989780

最新推荐文章于 2024-04-15 15:12:09 发布

阅读量3.1k

点赞数 1

文章标签：网络运维数据库

原文链接：http://blog.51cto.com/leejia/2125470

版权

场景

由于业务需要，客户提供http/https的流量镜像，让我们分析是否有异常行为。由于我们的系统的输入源只能是日志，故最快捷的办法是把http/https流量转换成http日志已满足异常分析的需求。

流量镜像或者复制方式

端口镜像

通过交换机或路由器上的端口镜像功能，将一个或多个源端口的数据流量转发到某一个指定端口来实现对网络的监听，指定端口称之为“镜像端口”或“目的端口”，在不严重影响源端口正常吞吐流量的情况下，可以通过镜像端口对网络的流量进行监控分析。由于要获取http/https的request和response数据，故要做双向镜像。

优点：
1、成本低廉，不需要增加任何网络设备；
2、启动端口镜像会话(Session)时，对交换机的性能基本无影响；
3、可从交换机上采集到所有用户访问请求数据；
4、故障保护，当采集系统或前置机出现故障时，对现有的网络和业务没有任何影响。

缺点：
1、占用交换机端口：采集系统需要和交换机直连，将占用交换机一定数量的GE和FE端口；
2、需要修改交换机配置：需要修改交换机的配置，将合适的流量复制到镜像端口，但在修改配置时不会对交换机性能和业务有影响；

分光器

对于某些节点，宽带接入服务器通过光口GE链路直接与核心路由器（一般为Cisco GSR）相连，宽带接入服务器及GSR均不支持端口镜像，这时采用分光器进行流量采集是最合适的方法。当某些节点的核心交换机、汇聚层交换机没有足够的GE端口，不适合采用端口镜像进行流量采集时，或希望在出口采集网络流量，就可以采分光器进行流量采集。分光器是一种无源光器件，通过在物理层上进行光复制来进行用户访问请求数据的采集，其优缺点如下。

优点：
1、性能优异：可支持GE甚至在2.5Gbps POS链路上通过分光器进行流量采集；
2、故障保护：当采集系统故障时，对现有网络及业务无任何影响；
3、无需修改现有网络设备的任何配置，不改变网络结构，可采集到所有的网络流量，和网络无缝集成；
4、可靠性高：分光器是一种无源光器件，可以看作是一种特制的光纤，可靠性高；
5、不占用网络设备端口，投入成本低。

缺点：
需要将设备的上联光纤改为分光器，这涉及到一次简单的网络割接，这将导致网络瞬时中断（不超过5秒钟），对业务有细微的影响；

iptables TEE模块

使用iptables即可实现把web服务器上的流量镜像到同一个网段的其它机器做分析

优点：
1，纯软件，使用方便
2，对现有网络及业务无任何影响
3，保留的原数据包的大部分原始信息

缺点：
1，会改变包的源mac和目的mac地址
2，必须同一个网段才能做流量镜像

流量复制相关软件工具

使用tcpcopy，gor工具，只能用于http协议的流量copy，需要真实业务的后端才能获取的response数据，并且需要在客户的web server上安装agent，一般用于测试环境的引流测试。

http流量镜像转化为日志

通过交换机的端口镜像把进入web服务器的流量给镜像到分析服务器的一个空闲网口。使用bro工具，监听流量镜像过来的分析服务器的网口，默认会自动抓取http流量，并且记录http相关数据到默认的http log文件，且日志格式中包含了http request和response的大部分数据。但是，此工具不支持https。

官方地址如下：
https://www.bro.org/
https://github.com/bro/bro

https流量镜像转化为日志

研究了Bro，snort，wireshark等网络监控工具，得出如下结论：

1，像Bro，snort这种IDS工具都不支持https
2，wireshark(命令行有tshark工具)可以通过导入https server端私钥，来解密密钥交换算法是RSA的流量，从而解密https流量。
官方文档：https://wiki.wireshark.org/SSL

既然，wireshark能满足部分的需求，故我们继续跟踪了解一下。密钥交换算法是CipherSuite里面的东西，故我们先了解一下CipherSuite。

加密套件

加密套件（CipherSuite），是在 SSL 握手中需要协商的很重要的一个参数。客户端会在 Client Hello 中带上它所支持的 CipherSuite 列表，服务端会从中选定一个并通过 Server Hello 返回。如果客户端支持的 CipherSuite 列表与服务端配置的 CipherSuite 列表没有交集，会导致无法完成协商，握手失败。

CipherSuite 包含多种技术，例如认证算法（Authentication）、加密算法（Encryption）、消息认证码算法（Message Authentication Code，简称为 MAC）、密钥交换算法（Key Exchange）和密钥衍生算法（Key Derivation Function）。

SSL 的 CipherSuite 协商机制具有良好的扩展性，每个 CipherSuite 都需要在 IANA 注册，并被分配两个字节的标志。全部 CipherSuite 可以在 IANA 的 TLS Cipher Suite Registry 页面查看。

OpenSSL 库支持的全部 CipherSuite 可以通过以下命令查看：

# openssl ciphers -V
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

1，0xC0,0x30是CipherSuite的编号，在SSL握手中会用到
2，ECDHE-RSA-AES256-GCM-SHA384是加密套件的名称
3，TLSv1.2标识用于TLSv1.2协议。TLS（Transport Layer Security，传输层安全）的前身是 SSL（Secure Sockets Layer，安全套接字层），它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL 1.0 从未公开过，而 SSL 2.0 和 SSL 3.0 都存在安全问题，不推荐使用。Nginx 从 1.9.1 开始默认只支持 TLS 的三个版本
4，Kx=ECDH标识使用ECDH做密钥交换
5，Au=RSA标识使用RSA做认证
6，Enc=AESGCM(256)标识使用AESGCM(256)做对称加密
7，Mac=AEAD标识ChaCha20-Poly1305是一种AEAD模式，不需要MAC算法

以nginx和firefox为例，来看看server端和client端支持的加密套件

1，查看配置nginx服务器端加密套件的指令如下：

Syntax: ssl_ciphers ciphers;
Default:    
ssl_ciphers HIGH:!aNULL:!MD5;
Context:    http, server

Specifies the enabled ciphers. The ciphers are specified in the format understood by the OpenSSL library, for example:
      ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

The full list can be viewed using the “openssl ciphers” command.The previous versions of nginx used different ciphers by default.

关于ssl_ciphers中的关键字HIGH,MEDIUM,LOW等配置，可以通过如下命令获取详情：

# openssl ciphers -V 'HIGH:!aNULL:!MD5'
# man ciphers //可以获取具体HIGH,MEDIUM,LOW等的具体解释

2，对应https的client端，也会有对应支持的加密套件，像curl，浏览器等都会有相关的标准。如下为firefox支持的加密套件：
https://wiki.mozilla.org/Security/Server_Side_TLS

了解了加密套件，我们就能知道哪些CipherSuite是使用了RSA密钥交换算法的。而下一个问题是为什么拿到server端的https证书之后，只有RSA密钥交换算法的CipherSuite能破解。像主流的DH/ECDH密钥交换算法不能破解呢？下面我们来看看他们的区别。

RSA和DH密钥交换算法的区别

密钥交换算法的作用：（在身份认证的前提下）规避【偷窥】的风险。通俗地说，即使有×××者在偷窥你与服务器的网络传输，客户端（client）依然可以利用“密钥协商机制”与服务器端（server）协商出一个用来加密应用层数据的密钥（也称“会话密钥”）。

1，RSA密钥交换算法
RSA 是一种【非】对称加密算法。在本系列第1篇的背景知识介绍中，已经聊过这种算法的特点——加密和解密用使用【不同的】密钥。并且“非对称加密算法”既可以用来做“加密/解密”，还可以用来做“数字签名”。

握手过程：

密钥协商的大概步骤：

1. 客户端发送client hello，client随机数以及客户端支持的加密套件等信息到服务端
2. 服务端发送server hello，发送服务端端随机数和CA证书等信息给客户端
3. 客户端验证该证书的可靠性，并从 CA 证书中取出公钥。客户端生成一个随机密钥 Premaster Secret k，并用这个公钥加密得到 k'，客户端把 k' 发送给服务端
4. 服务端收到 k' 后用自己的私钥解密得到Premaster Secret k
5. 这时，客户端和服务端拥有相同的 client随机数、server随机数和 Premaster Secret，可以各自算出相同的后续所需的用于对称加密的session key。这个session key用于后期传输数据的加密和解密。

如何防范偷窥（嗅探）

×××方式1:×××者虽然可以监视网络流量并拿到公钥，但是【无法】通过公钥推算出私钥（这点由 RSA 算法保证）

×××方式2:×××者虽然可以监视网络流量并拿到 k'，但是×××者没有私钥，【无法解密】 k'，因此也就无法得到Premaster Secret k

如何防范篡改（假冒身份）

×××方式1:如果×××者在第2步篡改数据，伪造了证书，那么客户端在第3步会发现（这点由证书体系保证）

×××方式2:如果×××者在第6步篡改数据，伪造了k'，那么服务端收到假的k'之后，解密会失败（这点由 RSA 算法保证），服务端就知道被×××了。

根据以上的原理，我们知道只要我们拿到服务端的private key，就可以解密得到client随机数、server随机数和 Premaster Secret，故就可以计算得到session key，故也可以解密传输的数据了。

2，DH密钥交换算法
DH 算法又称“Diffie–Hellman算法”。这是两位数学牛人的名称，他们创立了这个算法。该算法用来实现【安全的】“密钥交换”。它可以做到——“通讯双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥”。这句话比较绕口，通俗地说，可以归结为两个优点：

通讯双方事先【不】需要有共享的秘密。
用该算法协商密码，即使协商过程中被别人全程偷窥（比如“网络嗅探”），偷窥者也【无法】知道协商得出的密钥是啥。

但是，DH 算法本身也有缺点——它不支持认证。也就是说：它虽然可以对抗“偷窥”，却无法对抗“篡改”，自然也就无法对抗“中间人×××/MITM”。为了避免遭遇MITM×××，DH需要与其它签名算法（比如RSA、DSA、ECDSA）配合——靠签名算法帮忙来进行身份认证。当DH与RSA配合使用，称之为“DH-RSA”，与DSA配合则称为“DH-DSA”等。

握手过程：

DH的算法模型：

DH利用了数学上的一个“不可逆”的运算，就是离散对数。最终两个人得到的秘密数字都是g^(ab) mod p，而窃听者仅从p,g,A,B四个公开信息，是无法得到这个秘密数字的！
举个例子，假如p=23,g=5,Alice选取的秘密数字a=6,那么A=5^6 mod 23 =8，Bob选取的秘密数字是15，那么B=5^15 mod 23 = 19, 交换A和B后，Alice计算出的密钥S=19^6 mod 23=2,Bob计算出的密钥S=8^15 mod 23=2
当然，实际运算中不可能取这么小的数值，比如如果需要128bit长度的密钥，那么p值需要是128bit长度的质数，由于有模运算，所获得的密钥不会大于p，所以p值可以是128bit数字中最大的一个质数，g可以随便设置一个小的质数即可。

密钥协商的大概步骤：

1. 客户端发送client hello，client随机数以及客户端支持的加密套件等信息到服务端
2. a：服务端发送server hello，发送服务端端随机数和CA证书等信息给客户端。
   b: 服务端利用私钥将客户端随机数，服务端随机数，服务端DH参数签名，生成服务端的签名。
3. 服务端向客户端发送服务端DH参数以及服务器签名(Server Key Exchange)
4. 客户端验证签名的有效性，然后向服务端发送客户端DH参数(Client Key Exchange)。
5. 客户端与服务端各自利用服务端DH参数、客户端DH参数生成预主密钥Premaster Secret。然后，客户端和服务端各自再通过预主密钥、客户端随机数、服务端随机数生成session key。这个session key用于后期传输数据的加密和解密。

通过以上对RSA和DH密钥交换算法的了解，我们知道Premaster Secret是通过客户端和服务端根据某些算法算出来而通过传输的数据不能算出来Premaster Secret，并且Premaster Secret不会再客户端和服务器端进行传输，所以是安全的，即使拿到了私钥也解密不了DH密钥交换算法的流量。

wireshark用私钥解析密钥交换算法为RSA的流量

1，wireshark版本为2.4.2
2，打开已经准备好的pcap文件，我们可以看到数据是加密的

3，选择wireshark中的perferences>Protocols->ssl

4，配置ssl相关设置

ip address：ssl服务端的ip地址
port：ssl服务端的端口
protocol：加密协议被解密之后所使用的协议。如果是https的话，解密之后是http协议
key file：私钥的路径
password：私钥是pem格式的话，一般设置为空即可

5，查看解密之后的流量

wireshark的命令行工具tshark用私钥解析密钥交换算法为RSA的流量

官方连接：https://wiki.wireshark.org/SSL

# tshark -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" -o "ssl.keys_list: 1.1.1.2,443,http,/usr/local/openresty/nginx/conf/STAR.key" -o "ssl.debug_file: /root/wireshark-log" -i em1 -R "tcp.port == 443"
tshark: -R without -2 is deprecated. For single-pass filtering use -Y.
Running as user "root" and group "root". This could be dangerous.
Capturing on 'em1'
482 5.919169492 1.1.1.1 -> 1.1.1.2 TCP 78 58299 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1069340243 TSecr=0 SACK_PERM=1
483 5.919225218 1.1.1.2 -> 1.1.1.1 TCP 74 https > 58299 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=2066693868 TSecr=1069340243 WS=128
484 5.923009324 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=1069340247 TSecr=2066693868
485 5.928874631 1.1.1.1 -> 1.1.1.2 SSL 302 Client Hello
486 5.928911090 1.1.1.2 -> 1.1.1.1 TCP 66 https > 58299 [ACK] Seq=1 Ack=237 Win=30080 Len=0 TSval=2066693878 TSecr=1069340251
487 5.929678631 1.1.1.2 -> 1.1.1.1 TLSv1.2 4727 Server Hello, Certificate, Server Hello Done
488 5.933984079 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=237 Ack=2897 Win=128832 Len=0 TSval=1069340256 TSecr=2066693879
489 5.934407243 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=237 Ack=4662 Win=127104 Len=0 TSval=1069340256 TSecr=2066693879
490 5.934426509 1.1.1.1 -> 1.1.1.2 TCP 66 [TCP Window Update] 58299 > https [ACK] Seq=237 Ack=4662 Win=131008 Len=0 TSval=1069340256 TSecr=2066693879
491 5.950389947 1.1.1.1 -> 1.1.1.2 TLSv1.2 424 Client Key Exchange, Change Cipher Spec, Finished
493 5.958089813 1.1.1.2 -> 1.1.1.1 TLSv1.2 157 Change Cipher Spec, Finished
494 5.961313957 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=595 Ack=4753 Win=130944 Len=0 TSval=1069340282 TSecr=2066693907
495 5.962071856 1.1.1.1 -> 1.1.1.2 HTTP 215 GET / HTTP/1.1
496 5.962380525 1.1.1.2 -> 1.1.1.1 HTTP 935 HTTP/1.1 200 OK  (text/html)
497 5.966018287 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=744 Ack=5622 Win=130176 Len=0 TSval=1069340286 TSecr=2066693911
498 5.966451735 1.1.1.1 -> 1.1.1.2 TLSv1.2 135 Alert (Level: Warning, Description: Close Notify)
499 5.966560747 1.1.1.2 -> 1.1.1.1 TCP 66 https > 58299 [FIN, ACK] Seq=5622 Ack=813 Win=32256 Len=0 TSval=2066693916 TSecr=1069340286
500 5.967596840 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [FIN, ACK] Seq=813 Ack=5622 Win=131072 Len=0 TSval=1069340287 TSecr=2066693911
501 5.967625107 1.1.1.2 -> 1.1.1.1 TCP 66 https > 58299 [ACK] Seq=5623 Ack=814 Win=32256 Len=0 TSval=2066693917 TSecr=1069340287
502 5.970093517 1.1.1.1 -> 1.1.1.2 TCP 66 [TCP Out-Of-Order] 58299 > https [FIN, ACK] Seq=813 Ack=5623 Win=131072 Len=0 TSval=1069340289 TSecr=2066693916

转载于:https://blog.51cto.com/leejia/2125470

weixin_33989780

关注

1
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
http/https镜像流量的解析问题

场景由于业务需要，客户提供http/https的流量镜像，让我们分析是否有异常行为。由于我们的系统的输入源只能是日志，故最快捷的办法是把http/https流量转换成http日志已满足异常分析的需求。流量镜像或者复制方式端口镜像通过交换机或路由器上的端口镜像功能，将一个或多个源端口的数据流量转发到某一个指定端口来实现对网络的监听，指定端口称之为“镜像端口”或“目的端口”，在不严重影响源端口...
复制链接

扫一扫