可怕！网络上有个东西一直悄悄盯着你···

我是一个网络监控软件&＃xff0c;我被开发出来的使命就是监控网络中进进出出的所有通信流量。这个网络中所有人的上网内容我都看得清清楚楚&＃xff0c;是不是很可怕&＃xff1f;

我被一家公司老板买来运行在一个配置极高的Linux服务器上&＃xff0c;这台服务器上的网卡可不得了&＃xff0c;公司进出的网络数据包都得流经它&＃xff0c;它源源不断地把数据包抓上来交给我来分析。

你们应该也知道&＃xff0c;网络通信是分层的&＃xff0c;最常见的就是那个TCP/IP协议体系了。

拿到数据包后&＃xff0c;我就得按照这个协议规范&＃xff0c;一层层地脱去协议的外壳&＃xff0c;拿到它们的负载数据。

TCP会话重组

我重点要照顾的是TCP协议&＃xff0c;因为好多应用都要使用TCP来传输&＃xff0c;像上网冲浪HTTP、发邮件SMTP、微信聊天等等。

我想要掌控网络中的通信&＃xff0c;第一个就要拿TCP开刀&＃xff0c;得想办法把TCP传输的一个个数据包给重组起来&＃xff0c;形成一个完整的会话&＃xff0c;这样我才好知道应用层传了什么东西&＃xff0c;这个步骤叫做会话重组。

不过这个TCP协议有点复杂&＃xff0c;抛开我们抓到的包本来就存在乱序的情况不说&＃xff0c;它本身还有三次握手、四次挥手、超时重传、延迟回复等很多机制&＃xff0c;有时候还会遇到时间跨度很久的长连接&＃xff0c;这无疑都给我想要重组TCP会话造成了很大的难度。

而我重组TCP会话的唯一线索就是数据包包头中的序列号SEQ和确认号ACK。

不过我还是死磕RFC规范&＃xff0c;把这些问题都攻克了&＃xff0c;能够成功重组出一个个的TCP会话数据&＃xff0c;成功率还蛮高的。

应用协议识别

TCP会话重组出来了&＃xff0c;我就可以拿到里面传输的数据了。接下来要做的一件事就是识别应用层到底是什么应用在传输的呢&＃xff1f;

用我们的行话说&＃xff0c;那就是做应用协议识别&＃xff0c;这个时候我就得看一下端口了。

我根据三次握手数据包的方向&＃xff0c;就可以确定出谁是客户端&＃xff0c;谁是服务端。

再看一下服务端的端口号(这个在TCP包头里面就可以看到)&＃xff0c;就能知道这是一个什么服务了。

像常见的有下面这些&＃xff1a;

22: SSH远程登陆
25: 邮件服务
53: 域名解析服务
80: HTTP Web服务
3306: MySQL数据库服务
3389: 远程桌面连接服务
······


最常见的就是80端口的Web服务了&＃xff0c;人类每天上网都在用到。有时候Web服务不走80端口&＃xff0c;换成了别的&＃xff0c;不过这难不倒我&＃xff0c;我可以通过分析TCP的负载数据特征&＃xff0c;看看有没有HTTP协议的特征出现&＃xff0c;因为HTTP协议的特征实在是太明显啦&＃xff01;

到了后来&＃xff0c;根据端口的经验出错的概率越来越大了&＃xff0c;我就统一根据内容来进行识别判断&＃xff0c;不再相信端口。每个应用都有它们各自的协议特征&＃xff0c;这个识别我可是下了点功夫&＃xff0c;轻易不会透露。

文件还原

现在我知道应用层是什么协议了&＃xff0c;我就可以把应用层协议传输的数据给整明白了。

还是拿最常见的Web服务来说吧&＃xff0c;HTTP协议是一个基于请求-响应的协议&＃xff0c;比如下面的这一次通信&＃xff1a;

请求是一个GET包&＃xff0c;看请求的资源貌似是一张JPG图片。

再看响应包&＃xff0c;状态码是200 OK&＃xff0c;看来没啥问题。再看看Content-Type&＃xff0c;image/jpeg&＃xff0c;是个JPG图片没跑了。

现在我就可以定位到响应包的负载段&＃xff0c;就是在HTTP头&＃xff0c;两个回车换行(0D0A)后面就是数据了。

找到数据位置&＃xff0c;再根据Content-Length的大小&＃xff0c;把数据抠出来写成一个PNG格式的文件就大功告成了&＃xff01;

OMG&＃xff0c;这是哪个血气方刚的小伙子又在看美女图片了&＃xff01;

上面这个把协议中传输的文件提取出来的过程叫做文件还原&＃xff0c;除了HTTP协议&＃xff0c;我还支持文件传输协议FTP、邮件传输协议SMTP、文件共享的SMB协议呢。你们通过这些协议传输的文件&＃xff0c;我都能给你还原出来&＃xff0c;是不是很可怕&＃xff1f;

HTTPS解密

有一天&＃xff0c;我发现80端口的数据包越来越少了&＃xff0c;与此同时&＃xff0c;443端口的通信数据不知不觉多了起来。后来才知道原来为了防止被我这样的网络中间人窥探隐私&＃xff0c;他们都用上了一个叫HTTPS的技术。

HTTPS把数据进行了加密传输&＃xff0c;这样我拿到以后都是加密后的&＃xff0c;没办法知道传输了什么内容。

不过这家公司的老板很聪明&＃xff0c;他要求公司的员工电脑上都装上了一个“安全软件”&＃xff0c;美其名曰保护电脑不被入侵&＃xff0c;实际上啊是在他们的电脑上做了一个中间人劫持&＃xff0c;进行了HTTPS的证书替换。

这个“安全软件”作为中间人把HTTPS证书和密钥告诉我&＃xff0c;我就可以解密HTTPS流量了&＃xff01;你们上网干了啥我还是能知道得一清二楚&＃xff01;

网络阻断

你以为我只能在一旁监听吗?

要是你们访问那些敏感的网站&＃xff0c;或者尝试把老板交代给我重点看护的数据偷偷传出去&＃xff0c;那我就不只是看着那么简单了&＃xff0c;这个时候我就要启动阻断功能。

为了不影响公司网络的运转&＃xff0c;我一般都是旁路部署的&＃xff0c;这样要是我哪天抽风遇到了bug&＃xff0c;还可以立即把我撤下去。这个所谓旁路部署呢&＃xff0c;就是抓取的包都是一份拷贝&＃xff0c;而不是通过我转发。

不过这样一来也给我阻断网络通信带来了一些麻烦&＃xff0c;如果我是串联到网络中&＃xff0c;那可就简单了&＃xff0c;遇到那些可疑的网络连接我直接丢掉数据包&＃xff0c;不转发出去就得了。

可现在我不是串联&＃xff0c;而是旁路部署&＃xff0c;怎么办呢&＃xff1f;

聪明如我&＃xff0c;怎么可能被这小小的问题难住&＃xff1f;我可是深谙TCP协议的行家&＃xff0c;在发现可疑的连接建立的时候&＃xff0c;就将它掐灭在萌芽状态&＃xff01;

具体来说&＃xff0c;TCP连接的建立是要经过三次握手的&＃xff1a;

当我发现可疑的SYN数据包时&＃xff0c;在服务端回复第二次握手包之前&＃xff0c;以迅雷不及掩耳盗铃之势&＃xff0c;用服务器IP的名义伪造一个RST的数据包给客户端&＃xff0c;这样连接就被我掐断了&＃xff01;

这一招虽然不能保证百分之百成功&＃xff0c;但我离客户端更近&＃xff0c;我的伪造包一般都能比真正的服务端响应包早一步到达客户端&＃xff0c;所以成功率还是蛮高的&＃xff01;