可怕！公司部署了一个东西，悄悄盯着你···
我是一个网络监控软件，我被开发出来的使命就是监控网络中进进出出的所有通信流量。这个网络中所有人的上网内容我都看的清清楚楚，是不是很可怕？
我被一家公司老板买来运行在一个配置极高的Linux服务器上，这台服务器上的网卡可不得了，公司进出的网络数据包都得流经它，它源源不断的把数据包抓上来交给我来分析。
你们应该也知道，网络通信是分层的，最常见的就是那个TCP/IP协议体系了。
拿到数据包后，我就得按照这个协议规范，一层层的脱去协议的外壳，拿到它们的负载数据。
TCP会话重组
我重点要照顾的是TCP协议，因为好多应用都要使用TCP来传输，像上网冲浪HTTP、发邮件SMTP、微信聊天等等。
我想要掌控网络中的通信，第一个就要拿TCP开刀，得想办法把TCP传输的一个个数据包给重组起来，形成一个完整的会话，这样我才好知道应用层传了什么东西，这个步骤叫做会话重组。
不过这个TCP协议有点复杂，抛开我们抓到的包本来就存在乱序的情况不说，它本身还有三次握手、四次挥手、超时重传、延迟回复等很多机制，有时候还会遇到时间跨度很久的长连接，这无疑都给我想要重组TCP会话造成了很大的难度。
而我重组TCP会话的唯一线索就是数据包包头中的序列号SEQ和确认号ACK。
不过我还是死磕RFC规范，把这些问题都攻克了，能够成功重组出一个个的TCP会话数据，成功率还蛮高的。
应用协议识别
TCP会话重组出来了，我就可以拿到里面传输的数据了。接下来要做的一件事就是识别应用层到底是什么应用在传输的呢？
用我们的行话说，那就是做应用协议识别，这个时候我就得看一下端口了。
我根据三次握手数据包的方向，就可以确定出谁是客户端，谁是服务端。
再看一下服务端的端口号(这个在TCP包头里面就可以看到)，就能知道这是一个什么服务了。
像常见的有下面这些：
22: SSH远程登陆 25: 邮件服务 53: 域名解析服务 80: HTTP Web服务 3306: MySQL数据库服务 3389: 远程桌面连接服务 ······
最常见的就是80端口的Web服务了，人类每天上网都在用到。有时候Web服务不走80端口，换成了别的，不过这难不倒我，我可以通过分析TCP的负载数据特征，看看有没有HTTP协议的特征出现，因为HTTP协议的特征实在是太明显啦！
到了后来，根据端口的经验出错的概率越来越大了，我就统一根据内容来进行识别判断，不再相信端口。每个应用都有它们各自的协议特征，这个识别我可是下了点功夫，轻易不会透露。
文件还原
现在我知道应用层是什么协议了，我就可以把应用层协议传输的数据给整明白了。
还是拿最常见的Web服务来说吧，HTTP协议是一个基于请求-响应的协议，比如下面的这一次通信：
请求是一个GET包，看请求的资源貌似是一张JPG图片。
再看响应包，状态码是200 OK，看来没啥问题。再看看Content-Type，image/jpeg，是个JPG图片没跑了。
现在我就可以定位到响应包的负载段，就是在HTTP头，两个回车换行(0D0A)后面就是数据了。
找到数据位置，再根据Content-Length的大小，把数据抠出来写成一个PNG格式的文件就大功告成了！
OMG，这是哪个血气方刚的小伙子又在看美女图片了！
上面这个把协议中传输的文件提取出来的过程叫做文件还原，除了HTTP协议，我还支持文件传输协议FTP、邮件传输协议SMTP、文件共享的SMB协议呢。你们通过这些协议传输的文件，我都能给你还原出来，是不是很可怕？
HTTPS解密
有一天，我发现80端口的数据包越来越少了，与此同时，443端口的通信数据不知不觉多了起来。后来才知道原来为了防止被我这样的网络中间人窥探隐私，他们都用上了一个叫HTTPS的技术。
HTTPS把数据进行了加密传输，这样我拿到以后都是加密后的，没办法知道传输了什么内容。
不过这家公司的老板很聪明，他要求公司的员工电脑上都装上了一个“安全软件”，美其名曰保护电脑不被入侵，实际上啊是在他们的电脑上做了一个中间人劫持，进行了HTTPS的证书替换（你不信可以看看这个：谁动了你的HTTPS流量？）。
这个“安全软件”作为中间人把HTTPS证书和密钥告诉我，我就可以解密HTTPS流量了！你们上网干了啥我还是能知道的一清二楚！
网络阻断
你以为我只能在一旁监听吗？图样！
要是你们访问那些敏感的网站，或者尝试把老板交代给我重点看护的数据偷偷传出去，那我就不只是看着那么简单了，这个时候我就要启动阻断功能。
为了不影响公司网络的运转，我一般都是旁路部署的，这样要是我哪天抽风遇到了bug，还可以立即把我撤下去。这个所谓旁路部署呢，就是抓取的包都是一份拷贝，而不是通过我转发。
不过这样一来也给我阻断网络通信带来了一些麻烦，如果我是串联到网络中，那可就简单了，遇到那些可疑的网络连接我直接丢掉数据包，不转发出去就得了。
可现在我不是串联，而是旁路部署，怎么办呢？
聪明如我，怎么可能被这小小的问题难住？我可是深谙TCP协议的行家，在发现可疑的连接建立的时候，就将它掐灭在萌芽状态！
具体来说，TCP连接的建立是要经过三次握手的：
当我发现可疑的SYN数据包时，在服务端回复第二次握手包之前，以迅雷不及掩耳盗铃之势，用服务器IP的名义伪造一个RST的数据包给客户端，这样连接就被我掐断了！
这一招虽然不能保证百分之百成功，但我离客户端更近，我的伪造包一般都能比真正的服务端响应包早一步到达客户端，所以成功率还是蛮高的！
推荐：
