Local Bypass v Capture Bypass

1

Hi

I’m trying to understand the behaviour of bypass when using rules on native Linux compated to when on Suricata in Corelight using the Napatech card.

I’ll explain the scenario;

I have 2 rules;

  1. match good traffic and set bypass
  2. alert

So when a new UDP (good) flow occurs, I then set this to bypass;

In the suricata.yaml I have the UDP bypass set to 900s (the default is 100).

As long as the flow is not idle for >900 seconds I never see any alerts. I’m assuiming that whenever a packet for this bypassed flow comes into Suricata the cache timeout for that flow is refreshed.

If I send a flow that doesn’t match the good signature, it’s not bypass and as such is alerted on.

This works without issue.

On Suricata on Corelight I belive that this uses capture bypass, so once the flow is bypassed Suricata will never see this and as such will never be able to refresh the cache;

From; Suricata bypass feature

In capture bypass, when Suricata decides to bypass it calls a function provided by the capture method to declare the bypass in the capture. For NFQ this is a simple mark that will be used by the ruleset. For AF_PACKET this will be a call to add an element in an eBPF hash table stored in kernel.

If the call to capture bypass is successful, then we set a short timeout on the flow to let time of already queued packets to get out of suricata without creating a new entry and once timeout is reached we remove the flow from the table and log the entry.

So does this mean that for Capture bypass the timeout is hardset on the capture method and doesn’t refresh like it does for local bypass as Suricata will then never see it ?

E.g if using capture bypass and a flow is bypassed, then I need to know how long that flow is going to live for before it is removed from the hardware capture (e.g Napatech). As Suricata will never see this again.

many thanks

2

Hi Graham,

No, Suricata periodically queries the capture bypassed flows from the capture method to determine the flow’s liveness. Suricata still holds the flow record in its internal flow table but has noted that the flow has been capture bypassed. It has additional info noted there as well to know how to query for the flow info from the capture method. The capture methods (e.g., the Napatech card or eBPF/XDP maps) have internal flow tables implemented to be able to respond to Suricata’s queries.

So, e.g., every 30 seconds Suricata asks for the flow update and if the delta of received packets/bytes is non-zero, the bypass remains.

1 Like
3

Hi Lukas - thanks for the reply. Ok this is very interesting and maybe I’m hitting a bug on Corelight as flows that do not trigger an alert using local bypassed are alerted on Corelight.

4

I think you would need to add more details.

But generally, the moment Suricata tries to set capture bypass, the flow should be at least locally bypassed even if you have packets queued to Suricata and the capture method has no way to bypass them in the capture bypass.

Btw, the blog you were reading is almost 10 years old, so I am certain this part doesn’t hold true.

If the call to capture bypass is successful, then we set a short timeout on the flow to let time of already queued packets to get out of suricata without creating a new entry and once timeout is reached we remove the flow from the table and log the entry.

1 Like