Behaviour change with fix to Bug #5403

Developers
1

Hi @vjulien ,
With 6.0.6 released, I saw that you made a change to address #5403 which now silently drops the subsequent packets from a dropped flow (for stateless protocols, e.g. UDP).
This seems reasonable initially, but after testing, it changes the original behaviour for some of our use cases. One issue we hit is that, we have rules that block DNS requests and log the alerts. Since each DNS request is somewhat stateless, it makes more sense that each request is inspected and alerted separately. However with the said change, since suricata sees these requests belong to a single flow (based on the IP tuples), as soon as the client is blocked for a single request, it is no longer able to resolve anything subsequently whether or not the new request is allowed or blocked in the rules, unless the client starts a new flow uses a different source port.
Since we have no control of the client’s behaviour, we’re stuck. Also, we think it is reasonable that the client uses the same port for stateless DNS queries.
For things to work properly, I’m thinking there are a couple of options.

  1. Add a new action type. Instead of reject/drop that applies to the entire flow, a new action to be introduced to act just for that packet.
  2. Add a simple boolean configuration to disable this change.
  3. Add a configuration that specifies a list of app protocols to exempt from this change.

Any thoughts?

Thanks a lot,

Steven

2

Maybe you could customize flow timeout settings to lower values for udp traffic, ad I understand this will mean the flow will be evicted after the timeout and then will considered fresh and the communication will pass throw till a blocked request is seens.

3

Thanks for your recommendation. I don’t know how short I would lower the timeout to tho. Even if we set it to something like 1 second, it still doesn’t revert to the original behaviour, where one DNS client issues multiple requests in a roll and depending on the timing of when the flow is evicted we will either have multiple alerts or a single with rest dropped still, i.e. very inconsistent behaviour.

4

I believe the first option (adding a new rule action that drops that specific packet/request) is the best, however it might require significant development time and reverting the commit might be reasonable thing to do till the new rule action is introduced.

I am not in favor of protocol specific behavior (even via configuration) since it complicates things.

5

That seems reasonable approach, with the commit reverted for now until a more robust solution is figured out.

6

I found a couple of critical bugs in 6.0.6 as well, I’m wondering if 6.0.6 should be pulled given this many issues.