suricata 3.1 源码分析23 （数据包解码模块注册及初始化）

Myth丶恋晨 2022-07-16 01:57 179阅读 0赞

简介  
Suricata的解码模块与数据包获取模块是一一对应的，例如DecodePcap对应ReceivePcap，DecodeAFP对应ReceiveAFP。  
然而，我们知道数据包格式都是协议规定的，因此核心的数据包解码流程一定会是固定的。例如，对于常规的以太网包IPV4包TCP包，无非是DecodeEthernet->DecodeIPV4->DecodeTCP->…  
那么，这里为什么需要设置不同的解码模块呢？主要原因是因为，各种数据源对协议的支持可能不同，并且也需要相应对Packet进行些不同设置。为了避免把这些差异处理代码集中放在一个诸如DecodePacket这样的通用函数中，因此Suricata干脆就做了划分，不同数据源对应不同解码模块。其实随着后面分析可以看到，每个解码模块函数都大同小异，在做完针对各自数据源的特殊处理后，都会调用DecodeEthernet、DecodePPP、DecodeSll等通用解码函数进行进一步处理。  
例如，据我用肉眼做diff，DecodePcap和DecodeAFP的内容完全一样，而DecodePfring却相对更简单，只有对Ethernet的解码，因此可以猜测pfring数据源大概只支持以太网。另一方面，DecodePcapFile又完全不同了，其中有些针对Flow的特殊处理，并且解码也是通过回调函数来调用的，具体不知道是调的什么函数。  
与前面数据源的类似，下面我只记录常用的实时pcap模式下的解码模块的实现，也就是DecodePcap模块。若遇到与前面可能重复的内容，这里可能就只简单提一下，避免冗余。

模块注册  
模块注册是跟ReceivePcap模块紧挨着的，与后者不同的是：  
1. 模块flags为TM\_FLAG\_DECODE\_TM，表示这是一个解码模块。  
2. 这次模块执行函数不再是PktAcqLoop了，而是Func，设置为DecodePcap。  
模块初始化  
初始化函数为DecodePcapThreadInit。这个模块并没有初始化数据，因此initdata没有使用。函数内部会新建一个DecodeThreadVars结构体，用于保存该线程模块的上下文。该结构的重要字段如下：

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>udp_dp_ctx</td> 
   <td>用于UDP包的应用层协议检测，通过AlpProtoFinalize2Thread初始化。</td> 
  </tr> 
  <tr> 
   <td>counter_*</td> 
   <td>解码模块所注册的性能计数器ID，例如counter_ipv4计数器用于统计IPV4数据包个数。</td> 
  </tr> 
 </tbody> 
</table>

函数中首先通过DecodeThreadVarsAlloc新建一个DecodeThreadVars，然后调用DecodeRegisterPerfCounters注册所需的计数器。