技术干货 | 网络入侵检测系统之suricata协议解析流程介绍

admin 2023年5月19日18:45:25评论85 views字数 3750阅读12分30秒阅读模式

Suricata是一个免费、开源、成熟、快速、健壮的网络威胁检测引擎,我们在上集《技术干货 | 网络入侵检测系统之suricata概要介绍》分享了它的安装、搭建及工作模式,相信大家对Suricata已经有了一定的了解,今天将继续给大家介绍它的协议解析流程。 


在介绍协议之前我们先看一下TCP/IP网络结构,为了方便后面更好理解协议解析流程:

技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


要对数据包进行解包,我们首先要了解数据包是怎么封装,此处我们应该从上往下看,应用层准备好应用层的数据->传输层封装上TCP/UDP头部-〉IP层加上IP头->物理层将其封装成对应的以太网帧,加上以太网帧头

技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


以上就是wireshark显示的一个dns数据包,跟上述的数据包分层结构一致。要接包必须了解每一个包头的结构,下面将介绍一下各种数据包的包头结构



以太网帧


技术干货 | 网络入侵检测系统之suricata协议解析流程介绍

以太网帧头部为14个字节


从以太网帧中我们可以获取到以太网帧头、IP数据报文、数据包校验和


目的MAC:长度是6个字节用于标记数据包目的地址的MAC,目的MAC主要用于收包时来校验该数据包是否为发送给自己,同时在传输过程中经过路由交换时目的MAC是会变的


源MAC:长度为6个字节用于标识上一条的MAC地址,在数据包的传输过程中也可能会发生改变,注意该MAC地址不一定是源IP的MAC地址


类型:长度为2个字节,用于说明后面的数据报文类型,比如字段为0x0800代表的就是IP报文


IP数据包:指的的IP报文,长度是46-1500,其长度主要是有以太网的帧长度规定计算出来的,网络上规定的以太网帧长为64-1518


FCS:帧校验和,主要是用于校验数据包是否修改过,保证内容的准确性


IP报文


技术干货 | 网络入侵检测系统之suricata协议解析流程介绍

整个IP报文头固定长度占20个字节


版本:占4位,用于标识IP协议的版本

首部长度:占 4 位,可表示的最大十进制数值是 15。这个字段所表示数的单位是 32 位字长(1 个 32 位字长是 4 字节)。因此,当 IP 的首部长度为 1111 时(即十进制的 15),首部长度就达到 60 字节。当 IP 分组的首部长度不是 4 字节的整数倍时,必须利用最后的填充字段加以填充。

数据部分永远在 4 字节的整数倍开始,这样在实现 IP 协议时较为方便。首部长度限制为 60 字节的缺点是,长度有时可能不够用,之所以限制长度为 60 字节,是希望用户尽量减少开销。最常用的首部长度就是 20 字节(即首部长度为 0101),这时不使用任何选项。


区分服务:占 8 位,用来获得更好的服务。这个字段在旧标准中叫做服务类型,但实际上一直没有被使用过。1998 年 IETF 把这个字段改名为区分服务(Differentiated Services,DS)。只有在使用区分服务时,这个字段才起作用。


总长度:占16位,表示首部和数据之和,单位为字节。因此数据报的最大长度为 2^16-1=65535 字节,这个数值大于以太网帧的长度,因此才出现了IP报文大包分片,这个长度是指IP报文的长度,当IP报文长度大于以太网帧长度时就会进行IP分片。


标识:占 16 位,用来标识数据报 ,IP 协议在存储器中维持一个计数器。每产生一个数据报,计数器就加 1,并将此值赋给标识字段。当数据报的长度超过网络的 MTU,而必须分片时,这个标识字段的值就被复制到所有的数据报的标识字段中。具有相同的标识字段值的分片报文会被重组成原来的数据报。


标志:占 3 位,第一位未使用,其值为 0。第二位称为 DF(不分片),表示是否允许分片。取值为 0 时,表示允许分片;取值为 1 时,表示不允许分片。第三位称为 MF(更多分片),表示是否还有分片正在传输,设置为 0 时,表示没有更多分片需要发送,或数据报没有分片。


片偏移:占 13 位,当报文被分片后,该字段标记该分片在原报文中的相对位置。片偏移以 8 个字节为偏移单位。所以,除了最后一个分片,其他分片的偏移值都 8 字节(64 位)的整数倍。


生存时间:占 8 位,表示数据报在网络中的寿命, 该字段由发出数据报的源主机设置。其目的是防止无法交付的数据报无限制地在网络中传输,从而消耗网络资源。路由器在转发数据报之前,先把 TTL 值减 1。若 TTL 值减少到 0,则丢弃这个数据报,不再转发。因此,TTL 指明数据报在网络中最多可经过多少个路由器。TTL 的最大数值为 255。若把 TTL 的初始值设为 1,则表示这个数据报只能在本局域网中传送。


协议:占 8 位,表示该数据报文所携带的数据所使用的协议类型,该字段可以方便目的主机的 IP 层知道按照什么协议来处理数据部分。不同的协议有专门不同的协议号。例如,TCP 的协议号为 6,UDP 的协议号为 17,ICMP 的协议号为 1。


首部校验和:占 16 位,用于校验数据报的首部,数据报每经过一个路由器,首部的字段都可能发生变化(如TTL),所以需要重新校验。而数据部分不发生变化,所以不用重新生成校验值。


源地址:占32位,表示数据报的源 IP 地址。


目的地址:占32位,表示数据报的目的 IP 地址。


可选字段:该字段用于一些可选的报头设置,主要用于测试、调试和安全的目的。这些选项包括严格源路由(数据报必须经过指定的路由)、网际时间戳(经过每个路由器时的时间戳记录)和安全限制。


填充:由于可选字段中的长度不是固定的,使用若干个 0 填充该字段,可以保证整个报头的长度是 32 位的整数倍。


数据部分:表示传输层的数据,如保存 TCP、UDP、ICMP 或 IGMP 的数据。数据部分的长度不固定。



TCP报文


技术干货 | 网络入侵检测系统之suricata协议解析流程介绍

tcp报文头部固定长度为20个字节


源端口:占16位,表示源端口

目的端口:占16位,表示目的端口

序列号:占32位,用于标识发送端向接收端发送的数据字节流

确认号:占32位,用于标识接收端接收到的报文数

头部长度:占4位,用于表示报文首部长度

预留位:占4位,目前是0

标志位:占8位,tcp标志的说明

窗口大小:占16位,用于流量控制

TCP校验位:占16位,用于校验tcp数据是否完整

紧急指针字段:占16位,当urg字段为1才有效,用于表示数据段中紧急数据字节数

可选字段:长度不定,但是必须为32位的整数倍


UDP报文


技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


UDP报文头部为8个字节


源端口:占16位,表示源端口

目的端口:占16位,表示目的端口

长度:占16位,报文长度

校验位:占16位,用于校验数据是否完整


分析的源码版本是suricata 7.0.0,数据包发包过程是自上而下一层层封装的,解码则是反向,自下而上一层层解析,因为底层有字段表面上层的协议,比如在IP层就有一个字段说明传输层协议是tcp还是udp,下面就从源码的角度看看是怎么一层层解析的。


首先找到以decode开头的文件,该文件的代码就是解包的源码


技术干货 | 网络入侵检测系统之suricata协议解析流程介绍
技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


DecodeLinkLayer是所有数据包解包的入口函数,此处我们只需要关注LINKTYPE_ETHERNET类型的数据,也就是我们说的以太网帧数据

技术干货 | 网络入侵检测系统之suricata协议解析流程介绍
typedef struct EthernetHdr_ {
uint8_t eth_dst[6];    //目的MAC
uint8_t eth_src[6];    //源MAC
uint16_t eth_type;    //协议类型
} __attribute__((__packed__)) EthernetHdr;


该头部结构跟上面介绍的以太网帧头是一致的,可以获取到源目的mac,以及协议类型

技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


此处我们跟着IPv4协议往下走,其他协议也是类似的

技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


typedef struct IPV4Hdr_
{
uint8_t ip_verhl;     /**< version & header length */
uint8_t ip_tos;       /**< type of service */
uint16_t ip_len;      /**< length */
uint16_t ip_id;       /**< id */
uint16_t ip_off;      /**< frag offset */
uint8_t ip_ttl;       /**< time to live */
uint8_t ip_proto;     /**< protocol (tcp, udp, etc) */
uint16_t ip_csum;     /**< checksum */
union {
struct {
struct in_addr ip_src;/**< source address */
struct in_addr ip_dst;/**< destination address */
} ip4_un1;
uint16_t ip_addrs[4];
} ip4_hdrun1;
} IPV4Hdr;


头部内容也是跟上述说明的IP头字段一致

在IP头部中可以获取到传输层协议

技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


根据传输层协议解析对应的udp报文或者tcp报文

技术干货 | 网络入侵检测系统之suricata协议解析流程介绍
技术干货 | 网络入侵检测系统之suricata协议解析流程介绍


payload解析完之后,就是根据payload解析出对应的应用层协议,应用层协议的识别主要在函数AppLayerProtoDetectGetProto中匹配,应用层整体协议识别相对更复杂点,后续有空了再做介绍。



往期精彩推荐

技术干货 | 网络入侵检测系统之suricata概要介绍

技术干货 | 恶意Bot流量的检测分析与防护

技术干货 | 基于Linux连接器的审计进程事件实现方案

技术干货 | 邮件安全培训演练工具Gophish的介绍

干货 | 记一次DarkKomet synaptics 病毒应急响应事件

干货 | 混合云环境下流量采集方案分析



原文始发于微信公众号(货拉拉安全应急响应中心):技术干货 | 网络入侵检测系统之suricata协议解析流程介绍

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年5月19日18:45:25
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   技术干货 | 网络入侵检测系统之suricata协议解析流程介绍http://cn-sec.com/archives/1747778.html

发表评论

匿名网友 填写信息