Suricata reacts only to the first run of the same dump

Help
,
1

I can’t detect packets that I send more than once using tcpreplay.

My rule:
alert modbus any any <> any any (modbus: function 8; sid:1; rev:1;)

I’m running suricata:
suricata -k none -c test/suricata.yaml -i eth0

And I send the dump 3 times to the interface:
tcpreplay -K -t -l 3 --stats=1 -i eth0 "test/modbus_test_data_part1_CHANGED.pcap"

Packets are only detected the first time a dump is sent.

I’m guessing that packages with the same seq are not being detected again.
How to fix it?

  • Suricata version
    Suricata 6.0.16-dev
  • How you installed Suricata (from source, packages, something else)
    From source inside the docker container with Ubuntu 18.04.6 LTS

modbus_test_data_part1_CHANGED.pcap (4.0 KB)

2

Hi there, welcome to our forum ^^

Thanks for providing details in your question :slight_smile:

I’ve noticed that you are using an older, unsupported version of Suri. Do you have to stick to it, or would you be able to update to at least the most recent 6.0.x version?

When you look at eve logs, if you check the flow event type or field, can you see how many packets are sent for the modbus flow - to compare with what you see in the pcap?

(I don’t have an answer yet, trying to understand how Suri is interpreting the traffic it sees.)

1 Like
3

Hi,
I’m using your rule and pcap.

I’m running suricata with: suricata -r </path/to/modbus_pcap_file> -S </path/to/modbus_rule_file>

This generates 8 alerts>

6.0.x, 7.0.x and master all generate 8 hits.

1 Like
4

Thank you for the warm welcome! :innocent:

I just cloned the master-6.0.x branch and expected it to be the latest 6.0.x version.

Isn’t 6.0.16 the latest version?

According to the list of releases (Releases · OISF/suricata · GitHub ) the latest release for 6.0.x is 6.0.15.

5

I attached eve.json (17.1 KB)

Explanation.
There are 8 packages in the dump that match the rule.

I am sending the dump 3 times:
tcpreplay -K -t -l 3 --stats=1 -i eth0 "test/modbus_test_data_part1_CHANGED.pcap"

Thus, Suricata should detect 8+8+8 packages.

But it only detects the first run of the dump.
The second and third are ignored.

P. S. However, in general, Suricata sees all three dump sending (51 + 51 + 51 = 153 packages).
In eve.json can see this in "stats" → "capture" → "kernel_packets".

But there are only 8 detections.
Can be seen in "detect" → "alert": 8.

But it should be 8+8+8 = 24.

6

Yes, it is.
The only problem is detecting packets when listening to the interface.

I gave more information in the post above.

7

I’m very sorry, my brain stopped working properly and I read that as 6.0.1 T_T
Sorry for that noise, but would be good if you could move to Suricata 7, as that’s more up to date, and 6 will go EOL in about six months. :slight_smile:

1 Like
9

I switched to main-7.0.x.
I chose version 6 only because modbus is written in C.
(I don’t know Rust).

But the problem persisted.
If you send the dump 3 times, Suricata will only detect 8 packets.

A should detect 8+8+8.

Suricata ignores packets that match the rule that are sent the second and third time.

Can you tell me what could be the matter?

Could it be that they have the same Seq as previously detected packets?

Is it possible to disable this check?

10

I noticed the following.
If you send the dump 4 times, the stream.est_syn_resend field = 3.
dump_sent_4_times_51x4_packets.log (9.3 KB)

If you send the dump 7 times, the stream.est_syn_resend field = 6.
dump_sent_7_times_51x7_packets.log (11.7 KB)

Does this mean that the first TCP session is not closed?

Could this be due to missing FIN?
The dump contains only FIN, ASK and ASK at the end.

P. S. Just in case, I used single-threaded mode:
suricata -k none -c test/suricata.yaml -i eth0 --runmode single

I also removed other TCP sessions from the dump, but this did not help:
modbus_test_data_part1_CHANGED_trimmed.pcap (2.5 KB)
trimmed_dump_sent_4_times_32x4_packets.log (10.4 KB)