CN117793090A - 一种ftp流量的文件还原方法、装置以及处理设备 - Google Patents

Abstract

本申请提供了一种ftp流量的文件还原方法、装置以及处理设备，用于对ftp流量进行深度解析完控制面协议后，将数据面的关联数据即三元组信息增加到cache表中，再基于该cache表展开数据面协议的识别与关联，如此对于ftp流量的文件可以增加数据面协议的识别与数据面文件的还原功能，进而有助于使得后续的ftp流量监控可以更为精确、顺畅的展开，有助于提高网络安全。

Description

一种ftp流量的文件还原方法、装置以及处理设备

技术领域

本申请涉及ftp流量还原领域，具体涉及一种ftp流量的文件还原方法、装置以及处理设备。

背景技术

随着网络安全问题的日益增加，对网络威胁的溯源工作显得格外重要。ftp协议的使用率在网络传输文件中的占比相对较高，因此需要将基于ftp协议传输的相关文件进行还原存储，以便后续发生网络安全事故时，可以追溯相关日志以及文件，为网络安全提升更加牢固的保障。

而基于ftp协议传输的数据，由控制连接以及数据传输两部分组成，而本申请发明人发现，目前各大流量产品对ftp控制协议的识别还是较为轻松的，控制面协议一般通过21端口通信，而且有较多特定的控制命令，但是数据面协议在进行数据传输时，没有任何特征，仅仅通过20端口来识别数据面协议会存在较多误差，而且在面临多个ftp传输时，数据面协议也不知道与哪个控制面协议相关联。

具体来说，现有技术中对于ftp流量的文件还原处理，对数据面协议的识别存在精确性较差的问题，缺乏数据面的精确文件还原，则会对后续开展的网络安全工作造成一定的局限性，难以满足更高质量的网络安全工作的数据使用需求。

发明内容

本申请提供了一种ftp流量的文件还原方法、装置以及处理设备，用于对ftp流量进行深度解析完控制面协议后，将数据面的关联数据即三元组信息增加到cache表中，再基于该cache表展开数据面协议的识别与关联，如此对于ftp流量的文件可以增加数据面协议的识别与数据面文件的还原功能，进而有助于使得后续的ftp流量监控可以更为精确、顺畅的展开，有助于提高网络安全。

第一方面，本申请提供了一种ftp流量的文件还原方法，方法包括：

处理设备获取ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果，其中，控制面协议解析处理结果包括三元组信息；

处理设备创建一个全局cache表，并通过全局cache表缓存三元组信息，其中，全局cache表为哈希表；

处理设备将控制面协议解析处理未识别且目的端口为20的目标流量报文经过哈希处理后的数据流，与全局cache表对应的控制流进行初次匹配，得到源ip地址和目的ip地址相同的初始匹配结果；

处理设备将目标流量报文与初始匹配结果进行二次匹配，得到三元组信息相同的目标匹配结果，其中，目标匹配结果对应具有关联关系的目标数据流和目标控制流，目标数据流的master指针在匹配后配置成指向目标控制流；

处理设备以目标数据流的第一个包为开始位置，以目标数据流的fin包为结束位置，对目标数据流进行文件还原处理，得到ftp流量的文件还原结果。

结合本申请第一方面，在本申请第一方面第一种可能的实现方式中，文件还原处理包括以下处理内容：

1)判断当前报文是否为tcp报文，若不是tcp报文直接退出；

2)根据syn ack确定首包期望的seqnum；

3)判断seqnum是否为期望seqnum，

4)如果seqnum是期望seqnum，说明未乱序，直接退出进行包处理；

5)如果seqnum不是期望seqnum，进行乱序表查找，找到连续的seqnum报文，拷贝到全局缓存中，如果还是未找到，则缓存当前报文到乱序表，然后退出。

结合本申请第一方面，在本申请第一方面第二种可能的实现方式中，在控制面协议解析处理的过程中，采集到的ftp流量通过软哈希方式，将相同五元组信息的报文哈希到相同的线程上进行处理。

结合本申请第一方面第二种可能的实现方式，在本申请第一方面第三种可能的实现方式中，在控制面协议解析处理的过程中，ftp流量进入系统处理后，根据当前报文的五元组信息创建流表时，使用jhash2方式。

结合本申请第一方面第三种可能的实现方式，在本申请第一方面第四种可能的实现方式中，在控制面协议解析处理的过程中，在ftp控制面协议初步识别过程中，判断当前报文的目的端口是否为21端口，如果是21端口，则继续以逐包方式将当前报文的payload与特征库进行匹配，若匹配则进入ftp控制协议深度解析进行处理。

结合本申请第一方面第四种可能的实现方式，在本申请第一方面第五种可能的实现方式中，ftp控制协议深度解析在主动模式下，客户端随机打开一个大于1024的端口向服务器的21端口发起连接，同时开放N+1端口监听，并向服务器发出port N+1命令，由服务器从自己的20端口主动连接到port N+1命令指定的数据端口，以此获得对应的三元组信息。

结合本申请第一方面第四种可能的实现方式，在本申请第一方面第六种可能的实现方式中，ftp控制协议深度解析在被动模式下，当开启一个FTP连接时，客户端打开两个任意的本地端口，第一个端口连接服务器的21端口，提交PASV命令，使得服务器开启一个任意的端口，返回227开头的信息，基于227开头的信息获得对应的三元组信息，其中，对应的三元组信息的括号中有以逗号隔开的六个数字，前四个数字为服务器的地址，将倒数第二个数字乘256再加上最后一个数字，为服务器开放的、用来进行数据传输的端口。

第二方面，本申请提供了一种ftp流量的文件还原装置，装置包括：

获取单元，用于获取ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果，其中，控制面协议解析处理结果包括三元组信息；

缓存单元，用于创建一个全局cache表，并通过全局cache表缓存三元组信息，其中，全局cache表为哈希表；

初次匹配单元，用于将控制面协议解析处理未识别且目的端口为20的目标流量报文经过哈希处理后的数据流，与全局cache表对应的控制流进行初次匹配，得到源ip地址和目的ip地址相同的初始匹配结果；

二次匹配单元，用于将目标流量报文与初始匹配结果进行二次匹配，得到三元组信息相同的目标匹配结果，其中，目标匹配结果对应具有关联关系的目标数据流和目标控制流，目标数据流的master指针在匹配后配置成指向目标控制流；

还原单元，用于以目标数据流的第一个包为开始位置，以目标数据流的fin包为结束位置，对目标数据流进行文件还原处理，得到ftp流量的文件还原结果。

结合本申请第二方面，在本申请第二方面第一种可能的实现方式中，文件还原处理包括以下处理内容：

1)判断当前报文是否为tcp报文，若不是tcp报文直接退出；

2)根据syn ack确定首包期望的seqnum；

3)判断seqnum是否为期望seqnum，

4)如果seqnum是期望seqnum，说明未乱序，直接退出进行包处理；

5)如果seqnum不是期望seqnum，进行乱序表查找，找到连续的seqnum报文，拷贝到全局缓存中，如果还是未找到，则缓存当前报文到乱序表，然后退出。

结合本申请第二方面，在本申请第二方面第二种可能的实现方式中，装置还包括控制面协议解析单元，用于执行控制面协议解析处理；

在控制面协议解析处理的过程中，采集到的ftp流量通过软哈希方式，将相同五元组信息的报文哈希到相同的线程上进行处理。

结合本申请第二方面第二种可能的实现方式，在本申请第二方面第三种可能的实现方式中，在控制面协议解析处理的过程中，ftp流量进入系统处理后，根据当前报文的五元组信息创建流表时，使用jhash2方式。

结合本申请第二方面第三种可能的实现方式，在本申请第二方面第四种可能的实现方式中，在控制面协议解析处理的过程中，在ftp控制面协议初步识别过程中，判断当前报文的目的端口是否为21端口，如果是21端口，则继续以逐包方式将当前报文的payload与特征库进行匹配，若匹配则进入ftp控制协议深度解析进行处理。

结合本申请第二方面第四种可能的实现方式，在本申请第二方面第五种可能的实现方式中，ftp控制协议深度解析在主动模式下，客户端随机打开一个大于1024的端口向服务器的21端口发起连接，同时开放N+1端口监听，并向服务器发出port N+1命令，由服务器从自己的20端口主动连接到port N+1命令指定的数据端口，以此获得对应的三元组信息。

结合本申请第二方面第四种可能的实现方式，在本申请第二方面第六种可能的实现方式中，ftp控制协议深度解析在被动模式下，当开启一个FTP连接时，客户端打开两个任意的本地端口，第一个端口连接服务器的21端口，提交PASV命令，使得服务器开启一个任意的端口，返回227开头的信息，基于227开头的信息获得对应的三元组信息，其中，对应的三元组信息的括号中有以逗号隔开的六个数字，前四个数字为服务器的地址，将倒数第二个数字乘256再加上最后一个数字，为服务器开放的、用来进行数据传输的端口。

第三方面，本申请提供了一种处理设备，包括处理器和存储器，存储器中存储有计算机程序，处理器调用存储器中的计算机程序时执行本申请第一方面或者本申请第一方面任一种可能的实现方式提供的方法。

第四方面，本申请提供了一种计算机可读存储介质，计算机可读存储介质存储有多条指令，指令适于处理器进行加载，以执行本申请第一方面或者本申请第一方面任一种可能的实现方式提供的方法。

从以上内容可得出，本申请具有以下的有益效果：

面对ftp流量的文件还原需求，本申请在对ftp流量进行深度解析完控制面协议后，将数据面的关联数据即三元组信息增加到cache表中，再基于该cache表展开数据面协议的识别与关联，如此对于ftp流量的文件可以增加数据面协议的识别与数据面文件的还原功能，进而有助于使得后续的ftp流量监控可以更为精确、顺畅的展开，有助于提高网络安全。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请ftp流量的文件还原方法的一种流程示意图；

图2为本申请数据面协议识别的一种场景示意图；

图3为本申请ftp流量文件还原结果的一种实例示意图；

图4为本申请还原文件的一种流程示意图；

图5为本申请ftp流量的文件还原装置的一种结构示意图；

图6为本申请处理设备的一种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。在本申请中出现的对步骤进行的命名或者编号，并不意味着必须按照命名或者编号所指示的时间/逻辑先后顺序执行方法流程中的步骤，已经命名或者编号的流程步骤可以根据要实现的技术目的变更执行次序，只要能达到相同或者相类似的技术效果即可。

本申请中所出现的模块的划分，是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个系统中，或一些特征可以忽略，或不执行，另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合或通信连接可以是电性或其他类似的形式，本申请中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请方案的目的。

在介绍本申请提供的ftp流量的文件还原方法之前，首先介绍本申请所涉及的背景内容。

本申请提供的ftp流量的文件还原方法、装置以及计算机可读存储介质，可应用于处理设备，用于对ftp流量进行深度解析完控制面协议后，将数据面的关联数据即三元组信息增加到cache表中，再基于该cache表展开数据面协议的识别与关联，如此对于ftp流量的文件可以增加数据面协议的识别与数据面文件的还原功能，进而有助于使得后续的ftp流量监控可以更为精确、顺畅的展开，有助于提高网络安全。

本申请提及的ftp流量的文件还原方法，其执行主体可以为ftp流量的文件还原装置，或者集成了该ftp流量的文件还原装置的网络设备、服务器、物理主机或者用户设备(User Equipment，UE)等不同类型的处理设备。其中，ftp流量的文件还原装置可以采用硬件或者软件的方式实现，UE具体可以为智能手机、平板电脑、笔记本电脑、台式电脑或者个人数字助理(Personal Digital Assistant，PDA)等终端设备，处理设备可以通过设备集群的方式设置。

可以理解的是，搭载本申请所提供的ftp流量的文件还原方法的应用服务的处理设备，通常是在公司网络架构中或者运营商网络架构中，专门负责ftp流量文件还原工作的网络节点，或者在负责其他方面网络工作的同时还负责ftp流量文件还原工作的网络节点，其中，网络节点可以为网络设备、服务器等，而随着更为灵活的应用需求，考虑到执行本申请提供的ftp流量的文件还原方法并不需要特别的硬件结构或者说更依赖于数据处理能力，因此在实际情况下，处理设备也可能配置为相关的物理主机、UE等设备，这在实际情况下也是可能的。

下面，开始介绍本申请提供的ftp流量的文件还原方法。

首先，参阅图1，图1示出了本申请ftp流量的文件还原方法的一种流程示意图，本申请提供的ftp流量的文件还原方法，具体可包括如下步骤S101至步骤S105：

步骤S101，处理设备获取ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果，其中，控制面协议解析处理结果包括三元组信息；

可以理解，对于现有技术而言，其涉及有对ftp流量展开控制面协议的解析识别，因此，本申请可以直接在沿用了现有技术来对当前所要还原的ftp流量进行控制面协议解析处理的处理结果的基础上，来展开本申请考虑数据面协议的后续处理。

其中，对于控制面协议解析处理而言，其处理得到的控制面协议解析处理结果包括了三元组信息，三元组信息是通信领域较为常见的一种信息，包括源IP、目的IP以及源端口三个元素。

在进行了控制面协议解析处理后，存在一个本申请发明人发现的情况，即，一条ftp控制流中可能包含多条数据流的信息，存在一对多的关系，而在现有技术中，针对多条数据流时，控制流中解析出来的ip以及端口会存在多组，从而也就导致了本申请归纳的现有技术问题，即，现有技术仅仅通过20端口来识别数据面协议会存在较多误差，而且在面临多个ftp传输时，数据面协议也不知道与哪个控制面协议相关联，在该情况下，仅仅只做了ftp的控制面协议深度解析与命令审计工作，至于数据面传输的文件是否存在病毒或者涉密文件就不得而知了，也就存在着安全隐患，而这也是本申请后续数据面协议解析处理所要解决的问题。

步骤S102，处理设备创建一个全局cache表，并通过全局cache表缓存三元组信息，其中，全局cache表为哈希表；

面对数据面协议解析需求，本申请配置了一个全局的cache表，其表结构为三元组，具体为哈希(hash)表，如此可以将数据面的关联数据即前面获得的三元组信息增加(缓存)到该cache表中，再基于该cache表展开数据面协议的识别与关联。

步骤S103，处理设备将控制面协议解析处理未识别且目的端口为20的目标流量报文经过哈希处理后的数据流，与全局cache表对应的控制流进行初次匹配，得到源ip地址和目的ip地址相同的初始匹配结果；

可以理解，在ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果中，或者，在ftp流量展开的控制面协议解析处理的过程中，可以得到控制面协议解析处理未识别且目的端口为20的目标流量报文(前面控制面协议解析处理针对的是目的端口为21端口的流量报文)，针对该目标流量报文展开本申请的数据面协议解析处理。

通俗来讲，本申请所涉及的数据面协议解析处理，也可以用cache表的匹配流程来理解，其涉及到两次的匹配环节。

在初次匹配环节中，需要将目标流量报文对照哈希表性质的cache表，进行哈希(hash)，所得到的数据流再基于cache表所写入的三元组信息，进行源ip地址和目的ip地址的匹配，如此可以得到相同源ip地址和目的ip地址的目标三元组信息(可以简称为sip+dip相同的桶)，从而也就可以确定目标三元组信息对应的控制流，形成初次匹配结果。

步骤S104，处理设备将目标流量报文与初始匹配结果进行二次匹配，得到三元组信息相同的目标匹配结果，其中，目标匹配结果对应具有关联关系的目标数据流和目标控制流，目标数据流的master指针在匹配后配置成指向目标控制流；

在得到初次匹配环节确定的初次匹配结果后，接着就可以展开二次匹配环节，将当前的目标流量报文与初始匹配结果进行三元组信息的二次匹配，如此可以确定(命中)相同三元组信息的控制流，此时匹配就可以获得关联的目标数据里和目标控制流，完成数据面协议的解析目标，并且，还可以将目标数据流的master指针指向所关联的目标控制流。

具体的，对于此处处理，还可以参考图2示出的本申请数据面协议识别的一种场景示意图，来进行更为形象的理解。

步骤S105，处理设备以目标数据流的第一个包为开始位置，以目标数据流的fin包为结束位置，对目标数据流进行文件还原处理，得到ftp流量的文件还原结果。

而通过前面的步骤S104完成了ftp的数据流识别后，接下来就要对ftp的数据进行文件还原，ftp数据面的还原主要是tcp重组，开始位置为数据报文的第一个包，重组结束为数据包的fin包则完成还原、可以结束，此时将重组的数据流写入文件即可获得当前ftp流量的文件还原结果。

为方便理解以上的方案内容，作为一个实例，可以参考图3示出的本申请ftp流量文件还原结果的一种实例示意图，从中可以看到，当前ftp流量的文件还原结果，即当时基于ftp协议传输的文件，名为《11-用户和用户认证.docx》，文件的动作为下载，文件的大小为9.28M，还原的文件还可以通过下载按钮进行下载，供安全分析使用。

对于上述图1所示的实施例内容，可以看出，面对ftp流量的文件还原需求，本申请在对ftp流量进行深度解析完控制面协议后，将数据面的关联数据即三元组信息增加到cache表中，再基于该cache表展开数据面协议的识别与关联，如此对于ftp流量的文件可以增加数据面协议的识别与数据面文件的还原功能，进而有助于使得后续的ftp流量监控可以更为精确、顺畅的展开，有助于提高网络安全。

继续对上述图1所示实施例的各个步骤及其在实际应用中可能的实现方式进行详细阐述。

作为一种示例性的实施例，前面步骤S105执行的文件还原处理，参考图4示出的本申请还原文件的一种流程示意图，具体可以包括以下处理内容：

1)判断当前报文是否为tcp报文，若不是tcp报文直接退出；

2)根据syn ack确定首包期望的seqnum；

3)判断seqnum是否为期望seqnum，

4)如果seqnum是期望seqnum，说明未乱序，直接退出进行包处理；

5)如果seqnum不是期望seqnum，进行乱序表查找，找到连续的seqnum报文，拷贝到全局缓存中，如果还是未找到，则缓存当前报文到乱序表，然后退出。

可以理解，考虑到本申请重点是如何精确地筛选、确定出需要进行还原的文件范围，以此达到精确的ftp流量还原效果，而在确定了具体流量文件的情况下，所展开的文件还原处理在技术实现上是较为简单的，如此处实施例，是从实际应用角度提供了一套具体的落地配套方案。

此外，对于前面所执行的控制面协议解析处理，或者说在控制面协议解析处理的过程中，本申请在细节方面也有着相应的优化改进。

作为又一种示例性的实施例，对于将采集到的ftp流量传入系统的具体环节，本申请可配置为采集到的ftp流量通过软哈希方式，将相同五元组信息的报文哈希到相同的线程上进行处理。

在该设置下，控制面协议和数据面协议的所有报文都会在同一个线程上处理，如此可以大大提升业务处理的性能。

其中，此处所涉及的软哈希方式，具体可以为先计算源ip加目的ip的和，然后对线程数取余。

作为又一种示例性的实施例，当ftp流量传入系统、ftp流量进入系统处理后，会根据当前报文的五元组信息(源ip、目的ip、源端口、目的端口以及三层协议)建流(创建流表)，而根据当前报文的五元组信息创建流表时，具体可以使用jhash2方式。

在该设置下，可以有效使得五元组的哈希(hash)更加均匀，后续对控制面协议的识别，只需要识别一次即可。

其中，控制面协议的识别，使用端口加特征的方式进行组合识别，让ftp控制协议的识别更加精确。

在建流后进行的具体控制面协议解析处理，作为又一种示例性的实施例，本申请可以设计为三层架构，具体的，有：

在ftp控制面协议初步识别过程中，判断当前报文的目的端口是否为21端口，如果是21端口，则继续以逐包方式将当前报文的payload与特征库进行匹配，若匹配则进入ftp控制协议深度解析进行处理。

从这里也可以清楚地看到，控制面协议的识别，针对的是目的端口为21端口的报文，与前面提及的控制面协议解析处理未识别且目的端口为20的目标流量报文(前面控制面协议解析处理针对的是目的端口为21端口的流量报文)相对应上。

通过前面21端口匹配还有特征库匹配的两层筛选后，再进行ftp控制协议深度解析来获得精确的ftp控制协议解析识别。

其中，在基于特征库的匹配过程中，所采用的快速匹配算法，具体可以采用ac引擎。

进一步的，对于后面展开的ftp控制协议深度解析，作为又一种示例性的实施例，其主要可以分为主动模式和被动模式两类处理方式，具体的有：

1)主动模式

ftp控制协议深度解析在主动模式下，客户端随机打开一个大于1024的端口向服务器的21端口(如命令端口P)发起连接，同时开放N+1端口监听，并向服务器发出port N+1命令，由服务器从自己的20端口主动连接到port N+1命令指定的数据端口(即与port N+1命令相对应的N+1端口)，以此获得对应的三元组信息。

主动模式下，数据面报文的端口和IP直接跟在port命令后，直接解析获取即可获得相应的三元组信息。

2)被动模式

ftp控制协议深度解析在被动模式下，当开启一个FTP连接时，客户端打开两个任意的本地端口(N>1024和N+1)，第一个端口连接服务器的21端口，提交PASV命令，使得服务器开启一个任意的端口(P>1024)，返回227开头的信息(例如227entering passive mode(127,0,0,1,4,18))，基于227开头的信息获得对应的三元组信息，其中，对应的三元组信息的括号中有以逗号隔开的六个数字，前四个数字为服务器的地址，将倒数第二个数字乘256再加上最后一个数字，为服务器开放的、用来进行数据传输的端口。

具体来说，若是得到227entering passive mode(h1,h2,h3,h4,p1,p2)，那么端口号为p1*256+p2，ip地址为h1.h2.h3.h4，被动模式下，数据面的ip和端口即为h1.h2.h3.h4和p1*256+p2。

以上是本申请提供的ftp流量的文件还原方法的介绍，为便于更好的实施本申请提供的ftp流量的文件还原方法，本申请还从功能模块角度提供了一种ftp流量的文件还原装置。

参阅图5，图5为本申请ftp流量的文件还原装置的一种结构示意图，在本申请中，ftp流量的文件还原装置500具体可包括如下结构：

获取单元501，用于获取ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果，其中，控制面协议解析处理结果包括三元组信息；

缓存单元502，用于创建一个全局cache表，并通过全局cache表缓存三元组信息，其中，全局cache表为哈希表；

初次匹配单元503，用于将控制面协议解析处理未识别且目的端口为20的目标流量报文经过哈希处理后的数据流，与全局cache表对应的控制流进行初次匹配，得到源ip地址和目的ip地址相同的初始匹配结果；

二次匹配单元504，用于将目标流量报文与初始匹配结果进行二次匹配，得到三元组信息相同的目标匹配结果，其中，目标匹配结果对应具有关联关系的目标数据流和目标控制流，目标数据流的master指针在匹配后配置成指向目标控制流；

还原单元505，用于以目标数据流的第一个包为开始位置，以目标数据流的fin包为结束位置，对目标数据流进行文件还原处理，得到ftp流量的文件还原结果。

在一种示例性的实施例中，文件还原处理包括以下处理内容：

1)判断当前报文是否为tcp报文，若不是tcp报文直接退出；

2)根据syn ack确定首包期望的seqnum；

3)判断seqnum是否为期望seqnum，

4)如果seqnum是期望seqnum，说明未乱序，直接退出进行包处理；

5)如果seqnum不是期望seqnum，进行乱序表查找，找到连续的seqnum报文，拷贝到全局缓存中，如果还是未找到，则缓存当前报文到乱序表，然后退出。

在又一种示例性的实施例中，装置还包括控制面协议解析单元506，用于执行控制面协议解析处理；

在控制面协议解析处理的过程中，采集到的ftp流量通过软哈希方式，将相同五元组信息的报文哈希到相同的线程上进行处理。

在又一种示例性的实施例中，在控制面协议解析处理的过程中，ftp流量进入系统处理后，根据当前报文的五元组信息创建流表时，使用jhash2方式。

在又一种示例性的实施例中，在控制面协议解析处理的过程中，在ftp控制面协议初步识别过程中，判断当前报文的目的端口是否为21端口，如果是21端口，则继续以逐包方式将当前报文的payload与特征库进行匹配，若匹配则进入ftp控制协议深度解析进行处理。

在又一种示例性的实施例中，ftp控制协议深度解析在主动模式下，客户端随机打开一个大于1024的端口向服务器的21端口发起连接，同时开放N+1端口监听，并向服务器发出port N+1命令，由服务器从自己的20端口主动连接到port N+1命令指定的数据端口，以此获得对应的三元组信息。

在又一种示例性的实施例中，ftp控制协议深度解析在被动模式下，当开启一个FTP连接时，客户端打开两个任意的本地端口，第一个端口连接服务器的21端口，提交PASV命令，使得服务器开启一个任意的端口，返回227开头的信息，基于227开头的信息获得对应的三元组信息，其中，对应的三元组信息的括号中有以逗号隔开的六个数字，前四个数字为服务器的地址，将倒数第二个数字乘256再加上最后一个数字，为服务器开放的、用来进行数据传输的端口。

本申请还从硬件结构角度提供了一种处理设备，参阅图6，图6示出了本申请处理设备的一种结构示意图，具体的，本申请处理设备可包括处理器601、存储器602以及输入输出设备603，处理器601用于执行存储器602中存储的计算机程序时实现如图1对应实施例中ftp流量的文件还原方法的各步骤；或者，处理器601用于执行存储器602中存储的计算机程序时实现如图5对应实施例中各单元的功能，存储器602用于存储处理器601执行上述图1对应实施例中ftp流量的文件还原方法所需的计算机程序。

示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器602中，并由处理器601执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机装置中的执行过程。

处理设备可包括，但不仅限于处理器601、存储器602、输入输出设备603。本领域技术人员可以理解，示意仅仅是处理设备的示例，并不构成对处理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如处理设备还可以包括网络接入设备、总线等，处理器601、存储器602、输入输出设备603等通过总线相连。

处理器601可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是处理设备的控制中心，利用各种接口和线路连接整个设备的各个部分。

存储器602可用于存储计算机程序和/或模块，处理器601通过运行或执行存储在存储器602内的计算机程序和/或模块，以及调用存储在存储器602内的数据，实现计算机装置的各种功能。存储器602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据处理设备的使用所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(SecureDigital，SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器601用于执行存储器602中存储的计算机程序时，具体可实现以下功能：

处理设备获取ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果，其中，控制面协议解析处理结果包括三元组信息；

处理设备创建一个全局cache表，并通过全局cache表缓存三元组信息，其中，全局cache表为哈希表；

处理设备将控制面协议解析处理未识别且目的端口为20的目标流量报文经过哈希处理后的数据流，与全局cache表对应的控制流进行初次匹配，得到源ip地址和目的ip地址相同的初始匹配结果；

处理设备将目标流量报文与初始匹配结果进行二次匹配，得到三元组信息相同的目标匹配结果，其中，目标匹配结果对应具有关联关系的目标数据流和目标控制流，目标数据流的master指针在匹配后配置成指向目标控制流；

处理设备以目标数据流的第一个包为开始位置，以目标数据流的fin包为结束位置，对目标数据流进行文件还原处理，得到ftp流量的文件还原结果。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的ftp流量的文件还原装置、处理设备及其相应单元的具体工作过程，可以参考如图1对应实施例中ftp流量的文件还原方法的说明，具体在此不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请如图1对应实施例中ftp流量的文件还原方法的步骤，具体操作可参考如图1对应实施例中ftp流量的文件还原方法的说明，在此不再赘述。

其中，该计算机可读存储介质可以包括：只读存储器(Read Only Memory，ROM)、随机存取记忆体(Random Access Memory，RAM)、磁盘或光盘等。

由于该计算机可读存储介质中所存储的指令，可以执行本申请如图1对应实施例中ftp流量的文件还原方法的步骤，因此，可以实现本申请如图1对应实施例中ftp流量的文件还原方法所能实现的有益效果，详见前面的说明，在此不再赘述。

以上对本申请提供的ftp流量的文件还原方法、装置、处理设备以及计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种ftp流量的文件还原方法，其特征在于，所述方法包括：

处理设备获取ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果，其中，所述控制面协议解析处理结果包括三元组信息；

所述处理设备创建一个全局cache表，并通过所述全局cache表缓存所述三元组信息，其中，所述全局cache表为哈希表；

所述处理设备将所述控制面协议解析处理未识别且目的端口为20的目标流量报文经过哈希处理后的数据流，与所述全局cache表对应的控制流进行初次匹配，得到源ip地址和目的ip地址相同的初始匹配结果；

所述处理设备将所述目标流量报文与所述初始匹配结果进行二次匹配，得到三元组信息相同的目标匹配结果，其中，所述目标匹配结果对应具有关联关系的目标数据流和目标控制流，所述目标数据流的master指针在匹配后配置成指向所述目标控制流；

所述处理设备以所述目标数据流的第一个包为开始位置，以所述目标数据流的fin包为结束位置，对所述目标数据流进行文件还原处理，得到所述ftp流量的文件还原结果。

2.根据权利要求1所述的方法，其特征在于，所述文件还原处理包括以下处理内容：

1)判断当前报文是否为tcp报文，若不是tcp报文直接退出；

2)根据syn ack确定首包期望的seqnum；

3)判断所述seqnum是否为期望seqnum，

4)如果所述seqnum是所述期望seqnum，说明未乱序，直接退出进行包处理；

5)如果所述seqnum不是所述期望seqnum，进行乱序表查找，找到连续的seqnum报文，拷贝到全局缓存中，如果还是未找到，则缓存所述当前报文到乱序表，然后退出。

3.根据权利要求1所述的方法，其特征在于，在所述控制面协议解析处理的过程中，采集到的所述ftp流量通过软哈希方式，将相同五元组信息的报文哈希到相同的线程上进行处理。

4.根据权利要求3所述的方法，其特征在于，在所述控制面协议解析处理的过程中，所述ftp流量进入系统处理后，根据当前报文的五元组信息创建流表时，使用jhash2方式。

5.根据权利要求4所述的方法，其特征在于，在所述控制面协议解析处理的过程中，在ftp控制面协议初步识别过程中，判断所述当前报文的目的端口是否为21端口，如果是21端口，则继续以逐包方式将所述当前报文的payload与特征库进行匹配，若匹配则进入ftp控制协议深度解析进行处理。

6.根据权利要求5所述的方法，其特征在于，所述ftp控制协议深度解析在主动模式下，客户端随机打开一个大于1024的端口向服务器的21端口发起连接，同时开放N+1端口监听，并向所述服务器发出port N+1命令，由所述服务器从自己的20端口主动连接到所述port N+1命令指定的数据端口，以此获得对应的所述三元组信息。

7.根据权利要求5所述的方法，其特征在于，所述ftp控制协议深度解析在被动模式下，当开启一个FTP连接时，客户端打开两个任意的本地端口，第一个端口连接服务器的21端口，提交PASV命令，使得所述服务器开启一个任意的端口，返回227开头的信息，基于所述227开头的信息获得对应的所述三元组信息，其中，所述对应的所述三元组信息的括号中有以逗号隔开的六个数字，前四个数字为所述服务器的地址，将倒数第二个数字乘256再加上最后一个数字，为所述服务器开放的、用来进行数据传输的端口。

8.一种ftp流量的文件还原装置，其特征在于，所述装置包括：

获取单元，用于获取ftp流量通过控制面协议解析处理后得到的控制面协议解析处理结果，其中，所述控制面协议解析处理结果包括三元组信息；

缓存单元，用于创建一个全局cache表，并通过所述全局cache表缓存所述三元组信息，其中，所述全局cache表为哈希表；

初次匹配单元，用于将所述控制面协议解析处理未识别且目的端口为20的目标流量报文经过哈希处理后的数据流，与所述全局cache表对应的控制流进行初次匹配，得到源ip地址和目的ip地址相同的初始匹配结果；

二次匹配单元，用于将所述目标流量报文与所述初始匹配结果进行二次匹配，得到三元组信息相同的目标匹配结果，其中，所述目标匹配结果对应具有关联关系的目标数据流和目标控制流，所述目标数据流的master指针在匹配后配置成指向所述目标控制流；

还原单元，用于以所述目标数据流的第一个包为开始位置，以所述目标数据流的fin包为结束位置，对所述目标数据流进行文件还原处理，得到所述ftp流量的文件还原结果。

9.一种处理设备，其特征在于，包括处理器和存储器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时执行如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有多条指令，所述指令适于处理器进行加载，以执行权利要求1至7任一项所述的方法。