Alert limit and detection failure in Suricata

Hello dear colleagues,

I am testing rule performance and have encountered several problems. Could you please help me figure out if I am doing something wrong?

The essence of the problem:

I generated signatures (file suricata.rules). They represent all possible combinations of patterns consisting of 6 identical characters: A, B, C, D, E, X, Y, including all possible placements of fast_pattern. In total, there are 5040 possible combinations (rules).

Using the netcat utility, I transmit a file called data.txt (string: AAAAAAQQQBBBBBBQQQCCCCCCQQQDDDDDDQQQEEEEEEEQQQXXXXXXQQQYYYYYY), which, in addition to garbage characters, contains all 6 combinations that do not repeat anywhere else in the file. I then analyze Suricata’s behavior.

I have encountered two problems:

1. Suricata outputs only the first 255 triggers to the fast.log file. However, I have confirmed that the signatures do trigger (as seen in the rule_perf.log file). As I have preliminarily determined, there is a limit set to 255.

Question #1: How can I increase this limit?

2. The rules trigger when the data.txt file is relatively small. However, if the data.txt file is larger (it is the original data.txt, but with an additional 5000 ‘Q’ characters inserted between XXXXXX and YYYYYY), the signatures do not trigger at all. Meanwhile, the rule_perf_date.log file shows 3 checks.

Question #2: Why do the signatures not trigger? And why exactly three checks? Where does this number of checks come from, and what initiates them?

Drawing on your experience, please help me figure this out. I am particularly interested in the analysis of data within the TCP payload that is part of a stream consisting of multiple packets – possibly a very long stream of data.

I cannot attach the profiling files because the forum policy does not allow it.

Thank you!