案例分析 - 电信访问监控原理分析.docVIP

案例分析 - 电信网页访问监控原理分析 近段时间，一个在电信上班的朋友经常说，他们有办法知道一个NAT网关内部的电脑主机数，而且能够记录里面任何人的上网记录，听得我是心痒痒的，可问他方法，他又死活不说，郁闷。今天比较闲，脑袋里又想起了这事，想来想去，认为电信很可能采用欺骗客户端的方法，让客户端的信息首先发到监控主机，然后再发到目标服务器。 为证实推断是否合理，抱着试试的心态，立即在自己的机器上做了以下实验，步骤如下： 打开机器上的科来网络分析系统。 添加一个图1所示的过滤器，为的是只捕获我的机器（8）和网关（00:D0:41:26:3F:9E）以及外网的数据通讯，即不捕获我与内部网之间的通讯。 （图1　设置过滤器） 为减少数据干扰，在关闭本机上运用的其它应用程序后，开始捕获。 在本机上访问一个网页，这里以访问为例。 在页面出来后，停止捕获，并开始分析系统捕获到的数据包。 此次网页访问系统共捕获到了22个数据包，原始数据包的列表如图2所示。 （图2　原始数据包列表） 从图2中可知，编号1,2,3的数据包是TCP的三次握手数据包，第4个数据包是客户端8发起的HTTP GET请求，后面是服务器端的返回数据。从这些数据包来看，感觉通讯是正常的，于是切换到矩阵视图，查看通讯的节点情况，如图3。 （图3　访问的矩阵图） 在图3中，发现了一个奇怪的地址02，由于我此次的操作仅仅只访问了，所以是不应该出现这个地址的。这个02引起了我的注意，会不会这个地址在作怪呢？ 再切换到数据包视图，发现客户端（8）的确存在和02的通讯。 奇怪了，为什么8会主动和02进行通讯呢，会不会是有人在伪造数据包呢？为确定是否存在伪造数据包的情况，我强制显示数据包的IP层摘要信息，在图2所示的数据包视图中，单击右键，在弹出的菜单中选择“数据包摘要-IP摘要”，查看这些数据包IP层的信息，如图4。 （图4　通过IP层摘要查看02的伪造数据包） 从图4可知，TCP三次握手的服务器返回数据包（编号2）的生存时间是48，而第5个数据包的生存时间却是119，同一个服务器返回的两个数据包生存时间差别如此之大，表示它们经过的路由存在较大的差异，这与正常通讯的状态明显不符，由此我们怀疑编号为5的数据包可能是某个主机伪造的。 查看该数据包的解码（图4中间，红色圈住部份），发现该数据包是由220.267.29.102发起的，这表示220.267.29.102主动向8发起了一个欺骗数据包，双击第5个数据包，打开该数据包的详细解码窗口，如图5。 （图5　02伪造的数据包的详细解码信息） 从图5解码信息中可知，该数据包的TCP标记中，同时将确认位、急迫位、终止位置为1，这表示这个数据包想急于关闭连接，以防止客户端（8）收到服务器（）的正常响应，它这样做的目的是获取客户端（8）传输的数据信息，其获得的信息如图4中的右下角红色圈住部份，这是一个base64的编码信息，其具体的信息我会在后面进行详细说明。 由于客户端（8）被02伪造的数据包5欺骗，所以它向服务器（）确认并发送一个关闭连接请求的数据包，也就是第6和第7这两个数据包 第9和第10这两个数据包，也是02伪造的重置连接数据包，它的目的是欺骗客户端（8）关闭连接。 接着，客户端（8）主动向02发起TCP的三次握手，即第8,11,12这三个数据包，以和02建立连接。 13,14,15,17这几个数据包，是客户端（8）和02之间的数据通讯。从第15这个数据包的解码中，可以清楚地看到02将重新将访问重定向到，从而让客户端（8）向再次发起页面访问请求，以让客户端（8）完成正常的网页访问，其解码如图6。 （图6　02向8发起的数据包） 16,18,19是客户端（8）向服务器（）发起三次握手数据包。 20,21,22是三次握手成功后，客户端和服务器正常的HTTP通讯数据包，也就是传递客户端所请求的页面，这里是。 查看会话，选择TCP，发现此次的网页访问共连接起了3个连接，如图7。这三个连接的TCP流重组信息分别如图7,8,9，通过流的重组信息，我们也可以较为清楚地看到客户端和服务器（），以及客户端和02之间的数据通讯信息。 （图7　此次网页访问产生的三个TCP连接及第一个连接的TCP流信息） 图7中，客户端（8）向发起GET请求，但从服务器端返回的数据可知，返回服务器是02，且带了一串base64编码的参数， “ABcHJvdmluY2VpZD04Jm随机删除部份MTIwNDExJnNvdXJjZXVybD13d3cuY29sYXNvZnQuY29tLw==”， 对其进行反编译后的内容如下：“provinceid=8cityid=2classid=1000541username=adsl拨号用名sourceurl=/” 注意：上面的红色删除部份和adsl