聊聊DPI
DPI即深度数据包检测，这种技术一般是针对应用层的流量进行检测和控制。当有流量经过时基于DPI的监控系统后，系统需要读取报文中OSI七层协议中应用层的信息进行分析并根据策略进行相应的反馈。
在如今的网络环境下，针对Web应用层的攻击越来越常见，一般的防火墙只能针对指定的IP地址、端口、协议来进行防护，而那些恶意软件在偷偷传输个人隐私时或者接收外部攻击指令时，传统的防火墙并无法阻止这类攻击。
另外，对于应用程序的识别，如果想对QoS进行更细致的设置，也可以通过解析报文的内容，针对不同应用配置不同的QoS，起到节省带宽或者程序网络性能优化之类的作用。
像常见的迅雷、百度云管家这类下载软件，基于P2P下载的时候基本上都会把网速占满，尤其是上行速度，如果在同一个网络中有某些对于网速敏感的应用，此时如果没有人工干预就会导致网络阻塞，其他应用无法顺利发送数据。那么，想无人干预、智能化地解决这类问题的最好方法就是使用DPI识别应用，自动进行网络性能优化。
一般来说，DPI在控制管理上可以使用以下几项特征：
1.URL
2.端口
3.承载协议
4.承载的协议特征值
5.承载的数据内容
在笔者前面的那篇文章——用机器学习做流量分类（https://www.sdnlab.com/17324.html）的思路也和这个类似，不过我那篇文章使用的实验应用都是明文传输的，如果被加密，则需要其他技术对数据进行解密才能分析报文内容。
DPI解析引擎一般需要提供以下功能：
1.确认协议的种类：不同的协议会使用不同的端口，比如SSH的22，HTTP的80等常用协议会使用固定的端口，然而P2P应用一般采用的是随机端口，为了保证不会漏掉这些应用的报文，有必要通过分析其协议以进行控制。
2.切分协议：比如对于SOAP service，客户端传递一个SOAP Envelope，需要先发送一个HTTP包指明content-type、SOAPAciton等数据，然后在跟着的下一个包发送SOAP Envelope，没问题的话，SOAP service就返回200。简单地说，协议切分要做到是通过细分流，从而辨别出应用的一个行为，比如上面的客户端发送SOAP Envelope的行为。了解应用的行为，对于审计或者提高解析效率都有不小的意义。
3.切分协议域：简单而言就是把报文的内容划分为不同的块，比如在scapy中，读入一个pcap文件并选出特定的行，这时scapy返回的数据就已经把报文划分好，转化为python对象：
上图是LLMNR协议的抓包结果，用户可以直接访问该行的Ether键来得到抓包数据中的以太网部分数据。对于DPI引擎来说，切分报文也是进一步解析所承载的数据的重要步骤。
4.SSL卸载：加密的流量必须先解密，否则难以进行深入解析。
5.payload分析：大部分应用发送的数据有可能被处理过（加密、压缩等），而这些数据又是针对报文分析应用的关键，所以如何把分开的数据提取、合并、解密也是个难点。
6.识别协商协议：不少P2P应用使用协商的方式来传输数据，如果能识别出这个协商过程，就可以找出该应用的数据传输通道以进行进一步解析。
在接下来的内容中，我将会介绍几个包含了DPI技术的实现，以供读者研究。
L7-filter
L7-filter是作为linux Netfilter的应用层数据包分类器，可以检测Kazaa, HTTP, Jabber, Citrix, Bittorrent, FTP, Gnucleus, eDonkey2000等应用的报文。L7-filter从2003年开始开发，当然那时对于QoS配置并没有什么性价比高的方案，于是L7-filter作为开源软件诞生。
L7-filter提供了让用户自定义协议的功能。L7-filter支持的全部协议请看：http://l7-filter.sourceforge.net/protocols
L7-filter的思路就是使用正则表达式来匹配应用层的数据来判断报文使用的是什么协议。L7-filter并不是把全部包都解析一次，而是通过分析关键的包，解析payload或者连接信息来判断应用类别：L7-filter基于数据流工作，对于一个应用，可能会有多个数据流，但L7-filter并不针对所有数据包进行匹配，只选一个流的前面几个数据包，如果没有识别出任何特征信息，则此数据流无法被识别，停止匹配。
L7-filter提供了内核和用户空间的两种实现，但是似乎基于内核的比较被重视，因为用户空间的版本效率很低（由于做匹配消耗计算资源）。
关于L7-filter的现状：
L7-filter原本在sourceforge上托管（那里还保留着旧的文档），不知什么原因后来迁移到一个叫做Clear Foundation的组织下，然而我在新的主页上找不到任何可供参考的文档，我想这个项目大概已经没人维护，状态和OpenContrail差不多吧。
Libprotoident
这个库是由新西兰怀卡托大学网络研究组（WAND）开发的一个DPI库，这个研究组有不少成果，主页：http://research.wand.net.nz/
这个库有个最大的特点就是仅使用4bytes的payload数据就能进行流量分类，节省储存空间之余还在一定程度上降低DPI技术对个人隐私的侵害。使用libprotoident时，需要先通过抓包工具收集数据，并确认数据包的方向：因为在网络应用的双向交互中，会产生向不同方向的流量，这个需要用户程序进行判断，判断一个每个包的方向才能交给libprotoident。
使用libprotoident前要求监控程序在双向流开始时就要初始化一个LPI数据结构并由始至终地监测到双向流的结束。
上面的话，简单地举个例就是：一个用户、一个服务器，两者之间运行着一个监控程序。用户浏览一个页面，此时浏览器发送第一个请求数据，从监控程序监测到请求数据的时候就创建一个lpi_data_t structure，并一直保持监控服务器和浏览器的交互过程，直到最后交互结束。
什么是LPI数据？LPI数据储存着libprotoident用来判断应用协议种类的所需的双向流的信息，包含以下信息：
1.每个方向的payload的前4个字节的数据
2.每个方向的首个承载payload数据的包大小，忽略TCP/UPD/IP头
3.传输协议
4.使用的端口号
5.流所使用的IPv4地址
6.每个方向的首个承载payload数据的包的TCP序列号
7.每个方向的payload总数，最多去到32KB
为了保证重新排序TCP片段，因而需要TCP序列号和总载荷。这个库处理抓包数据的方式和笔者之前的机器学习的文章中处理数据的方式差不多是一样的，libprotoident只关心首个承载了数据的包，直接忽略其他的包。（提前说明啊，笔者那篇文章的数据处理思路可不是抄libprotoident的啊，纯粹是巧合 ╮(╯▽╰)╭ ）
对于如何定义一个数据包的方向，libprotoident使用0和1来作为方向的值，一个方向定义为0，那么另一个方向肯定为1，至于具体是什么节点到什么节点、究竟是客户端到server还是server到客户端都不重要。
当方向都定义好，LPI数据也准备好，就可以传给libprotoident进行处理。
libprotoident需要先把一个包、该包所属的流的LPI数据和包的方向传给lpi_update_data函数，然后该函数会从包抽取必要的信息存进LPI数据。
最后，lpi_guess_protocol函数读取该双向流的LPI数据，以判断双向流中使用了何种应用层协议。
和笔者的流量分类方式不同，libprotoident使用匹配的方式来进行判断，在libprotoident中，针对每个协议都有一个模块。在判断协议时，首先使用所有协议模块对LPI数据进行匹配，直到匹配成功。
而每个模块都可能会使用以下几项规则来进行匹配：
1.payload字段匹配：比如BT协议，如果在payload中出现'B'，'i','t'这样的字段就判断为BT协议。
2.payload大小：网络应用的某些数据包的大小可以用来用来进行判断，因为这些包是关键而且大小几乎是固定的，比如一些P2P应用进行初始化的包。
3.端口号：端口号就不多介绍了，这是很基本的匹配规则，对于使用固定端口的应用来说几乎很少会误判。
4.IP地址：这个规则比较少用，但有必要保留。
关于libprotoident所支持的应用可以从这里查看：https://secure.wand.net.nz/trac/libprotoident/wiki/SupportedProtocols
关于libprotoident现状：
该项目还在持续开发，最新的版本于今年4月释出，目前支持的协议已经达到300种以上，感兴趣的读者可以从这里下载使用：http://research.wand.net.nz/software/libprotoident.php
项目基于GPLv2开源，github地址：https://github.com/wanduow/libprotoident,libprotoident并不是一个单一的库，还有其他用于支撑整个DPI流程的其他库，感兴趣的读者请查看WAND的主页。
整体来说，这是个值得研究或者二次开发的DPI工具。
nDPI
nDPI的前身的OpenDPI，但是如今OpenDPI已经停止开发多年，nDPI作为OpenDPI的超集，现在由ntop.org负责维护，使用LGPLv3协议开源。nDPI是为了实现过去只有在付费版的OpenDPI才有的功能和额外的协议支持，现在在跨平台支持上，除了支持Linux平台，还支持Windows和Mac。
前面介绍提到，现在越来越多的应用是无法单纯靠端口来识别，nDPI可以识别出那些用随机端口的应用的流量或者在常用端口上的非常规协议的流量。
目前nDPI支持多达185种流量的识别，而且很接地气，比如QQ、Apple iCloud、Tor等，全部支持协议可以查看这里:http://www.ntop.org/products/deep-packet-inspection/ndpi/，而且针对加密流量的处理也做了支持。
在nDPI中，针对不同的应用程序协议是通过一个唯一数值作为协议ID和一个协议名来定义。nDPI采取了和OpenDPI一样的设计，库主要是一些通用函数的实验，而针对不同的协议的解析器则通过插件实现，这样一来用户想自定义协议支持就非常方便。
对于某些与外部服务器（比如xxx.google.com)交互的应用，针对这类会与特定的服务器连接的应用，不仅会通过流量的解析，还会把包含服务器地址的Host字段用于分类。
整个nDPI是可重入的，即可以中断，高层应用无需使用锁或者其他手段进行serialise操作。所有库只会在刚启动时初始化一次，如果一个新的包需要解析也不会产生额外开销。
目前，nDPI作为ntop和nProbe的基础库存在，当然，单独使用它也没问题。
nDPI现状:
持续开发中，官方支持良好，但是具体的nDPI的文档不多。支持的协议多也比较新，是个值得研究的库。
思考
上面，我介绍了三种比较有代表性的DPI工具，然而技术是个双刃刀，用在安全领域或者纯技术领域，会带来不少的好处，然而针对个人数据进行解析的时候，尤其是被别有用心的人使用DPI技术监控他人的通讯时，问题就会出现。
本来人在线上就没什么隐私可言，假设DPI技术发展到一个“秒天秒地秒空气”的程度，那么情况就更严重了。不知读者们有没有读过一本书《1984》，描述一个恐怖的窒息的极权主义的社会和主角一个人的悲剧。书中描述了一个称之为“电幕”的兼具监控和宣传的类似电视的东西，在大部分人的家里都有一块，“大洋国”的唯一政党“英社”用电幕进行政治宣传、监控着每一个人的言行，就算在家里也没有任何隐私可言...
DPI技术发展到一定程度后会不会成为另一种“电屏”？很难说，不少网络安全方面的工具，比如Kail Linux，都差不多可以称作“电子军火库”。不过，笔者还是很欣赏libprotoident这样考虑到信息伦理的工具的。
DPI和加密技术就好像矛和盾，一个技术升级了，另一个技术也会跟着升级，互相制约。希望在将来，不会出现个“2084”、“2184”。
这里额外提供两个阅读资料：
A Comparison of Popular DPI Engines for Traffic Classification：
http://blog.polygraph.io/2015/02/26/a-comparison-of-popular-dpi-engines-for-traffic-classification/
Independent comparison of popular DPI tools for traffic classification：
http://www.sciencedirect.com/science/article/pii/S1389128614003909
结语
DPI技术是一个相当有看点的领域，希望本文能为那些对DPI技术感兴趣的读者有所帮助。本人水平有限，如有缺点和漏洞，还请各位读者指出。
参考：
https://www.sdnlab.com/14017.html
http://l7-filter.sourceforge.net/
http://research.wand.net.nz/software/libprotoident.php
https://secure.wand.net.nz/trac/libprotoident/wiki/WikiStart
作者简介：
何智刚，2015至今，暨南大学经济统计学专业16届新生，主要研究云计算、SDN、机器学习，对各种领域都有所涉猎，目标是迈向full stack。
qq：1097225749
github：https://github.com/Hochikong
