基于DPI(深度报文解析)的应用识别2------实际分析

新浪微博的分析

早上刚刚起床先刷微博,打算就分析一下新浪微博。登陆之后抓取发布微博的数据包,进行分析。

1.抓包的要点:

1.关闭其他网络应用,保证本机网络流量的干净,便于分析。

2.先开启wireshark,后发布微博,微博发布成功立即停止,其他的应用类似。

3.查看conversion list ,太小的包没必要检查。

4.最关键的一点:一定抓取到3次握手,切记切记。

5.大部分应用都是基于TCP的,所以TCP优先分析,其次是UDP。

2.实际分析

1.筛选出TCP的回话列表,如图

我本地的流量比较干净,而且这次的分析比较明显,低于500Byte的数据包基本不含什么有用的信息,所以本次分析直接选择大小为6563的数据包就可以,实际情况可没这么少,应该会有很多干扰的回话,需要去仔细分析。

2.以下对65563的数据包进行分析:

确定这次回话有三次握手,图红框内的部分,这样就能准确的在建立链接的时候就能识别应用。

3.PC的web 微博基于http的,接下来就是分析HTTP报文内容,写出正确的正则表达式,以准确识别应用。

实际发得微博内容:

1.实际发的微博内容是n个a,在解析出的报文内容中text=aaaaaaaaaaaaaaaaaaaaaaaaaaa。明显是我们发的微博内容。这样就可以更进一步确定这是我们发的微博的数据包。

2.Host对应的是weibo.com

4.写出正确的正则表达式,以准确识别应用。

1.确保一个公司的相同产品直接不能产生误识别,或者正则表达式之间没有包含关系。举个例子:你想识别微博,然后你只写一个weibo.com。这样所有的微博产品都被识别,或者影响了。

2.正则表达式的面不能太大,这样就产生应用之间的误识别。

正则表达式的面也不能太小,这样网络报文随应用的细小变化,都会引起应用识别的不准确或者失效。、

根据http报文内容进行分析,本例子中需要注意几个关键点:POST/GET、 Host、还有微博内容前面带着的关键词text,这个可能是区别与其它应用的关键点。

本例正则表达式:

1.regex=^POST\x20\/aj\/mblog\/add.*weibo.*text

2.regex=^POST\x20.*weibo.*text

3.regex=^POST\x20.*add.*weibo.*text

4.regex=^POST\x20\/aj\/mblog\/add.*weibo

注:正则表达式的写法这里不详细解释,可以参考关于应用识别的上一篇文章。

这里我写几种范围不同的正则表达式,这就涉及到正则表达式范围大小的问题,根据实际情况把握。

这里我根据实习公司的规则要求写一个识别发微博应用的规则,这有点不好意思。我做一下调整,避开不必要的麻烦。很多应用的规则组成应用的协议库,以便识别应用。

ApplicationId: SG_APP_SINA_WEIBO_LOGIN

ApplicationName:SinaWeiboPublish

name_cn: 新浪微博发布

ApplicationType: APP_SOCIAL_NETWORK

ApplicationProtocol: TCP

ScanLength: ^POST\x20.*add.*weibo.*text

				
时间: 2024-11-03 01:16:11

基于DPI(深度报文解析)的应用识别2------实际分析的相关文章

基于DPI(深度报文解析)的应用识别

一.概述 1.DPI(Deep packet inspection,深度报文解析) 所谓"深度"是和普通的报文分析层次相比较而言的,"普通报文检测"仅分析IP包4 层以下的内容,包括源地址.目的地址.源端口.目的端口以及协议类型,而DPI 除了对前面的层次分析外,还增加了应用层分析,识别各种应用及其内容,主要实现一下功能: 1)应用分析--网络流量构成分析.性能分析.流向分析等: 2)用户分析--用户群区分.行为分析.终端分析.趋势分析等: 3)网元分析--根据区域

通用报文解析服务的演进之路(基于磁盘目录的分布式消息消费者服务)之一

通用报文解析服务,用C#开发,经历了三版更新,支撑起了关区内的绝大多数数据交换业务,截止至今,每日收发报文约20万,数据量约5G,平均延迟在1分钟内. 回想起那些半夜处理积压报文的场景,不胜唏嘘,决定把这个演进过程向大家讲述一下.回顾历史,展望未来,如果能给大家一些启发,是再好不过的了. 由于某些历史和非历史原因,我们的数据交换在已经有IBMMQ等中间件做支撑的情况下,还需要将报文落地到磁盘目录下再做下一步解析.入库.因此就有了这么一个需求,基于磁盘目录的报文解析服务. 初步计划,按照演进过程中

移动支付平台间接口报文解析技术核心架构实现、及平台交易处理项目全程实录教程

<基于移动支付平台间接口报文解析技术核心架构实现.及平台交易处理项目全程实录>课程讲师:MoMo 课程分类:Java框架适合人群:中级课时数量:52课时用到技术:JavaBean .Spring3.X. SpringMVC. Hibernate3.X.Apache HttpClient 3.x.JUnit4.x.自定义Annotation + java反射技术涉及项目:移动支付平台间接口咨询QQ:1337192913 课程介绍:   本课程抛开理论.以项目为驱动,适用于初次接触报文收发.组装解

Python:使用基于事件驱动的SAX解析XML

SAX的特点: 是基于事件的 API 在一个比 DOM 低的级别上操作 为您提供比 DOM 更多的控制 几乎总是比 DOM 更有效率 但不幸的是,需要比 DOM 更多的工作 基于对象和基于事件的接口 您可能已经知道语法分析器有两类接口 - 基于对象的(如:DOM)和基于事件(如:SAX)的接口. DOM是基于对象的语法分析器的标准 API. 作为基于对象的接口,DOM 通过在内存中显示地构建对象树来与应用程序通信.对象树是 XML 文件中元素树的精确映射. DOM 易于学习和使用,因为它与基本

【基于WPF+OneNote+Oracle的中文图片识别系统阶段总结】之篇三:批量处理后的txt文件入库处理

篇一:WPF常用知识以及本项目设计总结:http://www.cnblogs.com/baiboy/p/wpf.html 篇二:基于OneNote难点突破和批量识别:http://www.cnblogs.com/baiboy/p/wpf1.html 篇三:批量处理后的txt文件入库处理:http://www.cnblogs.com/baiboy/p/wpf2.html 篇四:关于OneNote入库处理以及审核:http://www.cnblogs.com/baiboy/p/wpf3.html [

KINECT+opencv基于骨骼信息对视频进行动作识别

KINECT+opencv基于骨骼信息对视频进行动作识别 环境:kinect1.7+opencv2.4+vc2015 使用kinect获取并按批处理三维空间内的骨骼信息 基于视频帧差计算各关节运动向量并与本地模板匹配 目录 KINECTopencv基于骨骼信息对视频进行动作识别 目录 写在前面 对当前帧处理并匹配 kinect对帧的处理 与模板的向量余弦计算 根据动态时间规划法匹配 记录并保存模板到本地 使用opencv的FileStorage类生成xml文件 写在前面 自前一篇过去一周了.这次

移动支付平台间接口报文解析核心架构及平台交易全程实录

移动支付平台间接口报文解析核心架构及平台交易全程实录 (HttpClient+SpringMVC+Spring3+Hibernate3+自定义Annotation) 课程分类:Java框架 适合人群:中级 课时数量:52课时 用到技术:JavaBean .Spring3.X. SpringMVC. Hibernate3.X.Apache HttpClient 3.x.JUnit4.x.自定义Annotation + java反射技术 涉及项目:移动支付平台间接口 咨询qq:1840215592

用深度学习做命名实体识别(四)——模型训练

通过本文你将了解如何训练一个人名.地址.组织.公司.产品.时间,共6个实体的命名实体识别模型. 准备训练样本 下面的链接中提供了已经用brat标注好的数据文件以及brat的配置文件,因为标注内容较多放到brat里加载会比较慢,所以拆分成了10份,每份包括3000多条样本数据,将这10份文件和相应的配置文件放到brat目录/data/project路径下,然后就可以从浏览器访问文件内容以及相应的标注情况了. 链接:https://pan.baidu.com/s/1-wjQnvCSrbhor9x3G

使用Scala基于词法单元的解析器定制EBNF范式文法解析

一.前言 近期在做Oracle迁移到Spark平台的项目上遇到了一些平台公式翻译为SparkSQL(on Hive)的需求,而Spark采用亲妈语言Scala进行开发.分析过大概需求过后,拟使用编译原理中的EBNF范式模式,进行基于词法的文法解析.于是拟采用传统的正则词法解析到EBNF文法解析的套路来实现,直到发现了StandardTokenParsers这个Scala基于词法单元的解析器类. 二.平台公式及翻译后的SparkSQL 平台公式的样子如下所示: 1 if(XX1_m001[D003