How I Solved Mysql being Unable to be Parsed on Suricata?

本文链接：https://blog.youkuaiyun.com/computerma/article/details/97112173

在扩展Suricata的MySQL检测和解析时，发现在压力测试中stats.log中未出现mysql相关统计，经过排查发现是由于stream.checksum-validation设置为yes导致，通过禁用校验和验证解决了问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

These days, I’m extending Mysql detecting & parser on Suricata. Everything works well while replaying the pcap file with the following command:
bin/suricata -c etc/spiderflow.yaml -r $1 -k none
However, while I want to stress test the new feature, I failed to find app_layer.flow.mysql or app_layer.tx.mysql in stats.log, even after I recheckout the code and rules. I used the below command to start it:
bin/suricata -c etc/spiderflow.yaml -D --netmap=p2p2

The following logs repeated many times in suricata.log. It seemed that MysqlState is allocated properly, but MysqlTx doesn’t:
[29630] 23/7/2019 – 18:03:40 - (app-layer-mysql.c:382) (MysqlStateAlloc) – Allocating mysql state.
[29630] 23/7/2019 – 18:03:40 - (app-layer-mysql.c:1116) (MysqlParseRequest) – No transaction for state 0x7f5893d3dfd0.
[29631] 23/7/2019 – 18:03:40 - (app-layer-mysql.c:484) (MysqlProbingParser) – Detected as ALPROTO_MYSQL.
In my implementation, MysqlTx is allocated while parsing handshake packet from the server. So I deemed it may not be processed by Suricata, or it may be dropped.

So I checked suricata.yaml again and found stream.checksum-validation is set to yes. And I recalled that while replaying pcap files, I used the option -k none which disables checksum validation. And then I changed stream.checksum-validation to no and Suricata happily parsed Mysql packets.