Drop log false positive records possible since 6.0.6?

Hi!
we have two opnsense instances with Suricata in IPS mode on both. one with 6.0.5 and one with 6.0.9.
both have eve-log drop alerts enabled with:

  • drop:
    alerts: yes # log alerts that caused drops
    flows: start

both instances have two test rules like:
pass tcp 172.17.1.0/24 any → any 225 (msg:“PASS LOCAL NET Port 225::no flags::flow to_server::no thresholds”; flow:to_server; classtype:misc-activity; sid:1000100; rev:1; metadata:created_at 2023_02_07, updated_at 2023_02_07;)
and
drop tcp 172.17.1.0/24 any → any 225 (msg:“DROP LOCAL NET Port 225::A12flags::flow established: to_server::no thresholds”; flow:to_server,established; flags: A,12; classtype:misc-activity; sid:1000103; rev:1; metadata:created_at 2023_02_07, updated_at 2023_02_07;)

both instances have test smtp server listening on tcp 225
smtp session works on both instances. but…on 6.0.9 it produces “drop” event_type records in eve-log for sid:1000103.

can it be related to Optimization #5127: alerts: use alert queing in DetectEngineThreadCtx (6.0.x backport) - Suricata - Open Information Security Foundation (and setting drop action in AlertQueueAppend())?
thanks!

Hey there!

I’m trying to better visualize this. Would it be possible for you to share logs and/or a pcap where you observe this happening?

I’m not sure if it could be related, but we did find this bug: Bug #5806: exceptions: midstream flows are dropped if midstream=true && stream.midstream-policy=drop-flow (6.0.x backport) - Suricata - Open Information Security Foundation that led to unexpected drops in case of packets detected as midstream (and this was only fixed in 6.0.10). Do you have the exception policy for midstream set to drop-flow or drop-packet?

If we do confirm this is a bug, we’ll ask you to report it on: Issues - Suricata - Open Information Security Foundation

Thanks in advance for any info you can add :slight_smile:

To complement my answer: I wouldn’t expect the issue to be in setting the drop action in the AlertQueueAppend() function, because that’s called after Suri has decided the signature alerted, already…

Hi!
Thanks for the quick response!
packets not actually dropped - just reported as dropped in drop log.
To make the example more clear, I changed the drop rule. so now the rules look like this:

pass tcp 172.17.1.0/24 any → any 225 (msg:“PASS LOCAL NET Port 225::no flags::flow to_server::no thresholds”; flow:to_server; classtype:misc-activity; sid:1000100; rev:1; metadata:created_at 2023_02_07, updated_at 2023_02_07;)

and

drop tcp 172.17.1.0/24 any → any 225 (msg:“DROP LOCAL NET Port 225::no flags::flow established to_server::no thresholds”; flow:to_server,established; classtype:misc-activity; sid:1000101; rev:1; metadata:created_at 2023_02_07, updated_at 2023_02_07;)

drop_only.zip (2.2 KB)
pass_and_drop.zip (16.3 KB)
I attach two pcap files: the first for the case when only the drop rule is enabled (no complaints here. The smtp session hangs after receiving the server header. all as expected), the second - when both rules are enabled (the smtp session runs without problems, but messages about packet drops appear in the log)

messages in eve-log looks like:
{“timestamp”:“2023-02-15T18:49:10.169185+0000”,“flow_id”:662827960784155,“in_iface”:“hn0”,“event_type”:“drop”,“src_ip”:“172.17.1.80”,“src_port”:1709,“dest_ip”:“172.17.1.105”,“dest_port”:225,“proto”:“TCP”,“drop”:{“len”:40,“tos”:0,“ttl”:127,“ipid”:27476,“tcpseq”:1500042227,“tcpack”:1787298342,“tcpwin”:65252,“syn”:false,“ack”:true,“psh”:false,“rst”:false,“urg”:false,“fin”:false,“tcpres”:0,“tcpurgp”:0},“alert”:{“action”:“blocked”,“gid”:1,“signature_id”:1000101,“rev”:1,“signature”:“DROP LOCAL NET Port 225::no flags::flow established to_server::no thresholds”,“category”:“Misc activity”,“severity”:3}}.

opnsense does not set exception policy afaik: https://github.com/opnsense/core/blob/master/src/opnsense/service/templates/OPNsense/IDS/suricata.yaml

sorry, just trying to understand how this condition can be met (if I understand correctly the reason for the entry in the log)

Thanks again!

1 Like

Hi again,

Thanks for more input. I’m sorry, I didn’t consider in my answer the possibility that the same packet would be triggering both rules.

This reminds me a bit of Bug #5458: Reject action is no longer working - Suricata - Open Information Security Foundation, but that was fixed in 6.0.7. I’ll investigate this furhter. Could you please create a bug report?

1 Like

sure, thanks!

1 Like

Thanks a lot for your help!
for the ref. issue is fixed by https://github.com/OISF/suricata/commit/517132b6ad0347c8402b3aace885d1b734609fec

1 Like