Project

General

Profile

Actions

Bug #2986

closed

stream bypass not making callback as expected

Added by Phil Young over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

I've been testing the bypass callback in the Napatech capture method. This callback works well when using the bypass option in the rule set. I'm trying to get this to work with tcp stream thresholds and think there may be a bug.

In my conf file I have modified the following options:

stream:
bypass: true
reassembly:
depth: 1kb

With this configuration I do not get callbacks when I input large flows from a pcap file.

Looking at the code in stream-tcp.c (line 4843) I noticed this code:

/* streams that hit depth */
if ((ssn->client.flags & STREAMTCP_STREAM_FLAG_DEPTH_REACHED) &&
(ssn->server.flags & STREAMTCP_STREAM_FLAG_DEPTH_REACHED)) {
/* we can call bypass callback, if enabled */
if (StreamTcpBypassEnabled()) {
PacketBypassCallback(p);
}
}
if ((ssn->client.flags & STREAMTCP_STREAM_FLAG_DEPTH_REACHED) ||
(ssn->server.flags & STREAMTCP_STREAM_FLAG_DEPTH_REACHED)) {
p->flags |= PKT_STREAM_NOPCAPLOG;
}

It appears that the first "if" statement is requiring the stream depth to reach the depth threshold on both directions of the flow before making the callback. I would expect this to trigger if only one direction of the flow reaches depth as it is in the second "if" statement. When I changed the && to || on my system I got the callback as expected.

Am I correct that this is a bug? Or, am I doing something wrong in my configuration? (If it is a bug the code a few lines down at 4872 is likely also a bug.)

Actions #1

Updated by M Schröder over 5 years ago

Phil Young wrote:

It appears that the first "if" statement is requiring the stream depth to reach the depth threshold on both directions of the flow before making the callback. I would expect this to trigger if only one direction of the flow reaches depth as it is in the second "if" statement. When I changed the && to || on my system I got the callback as expected.

Am I correct that this is a bug? Or, am I doing something wrong in my configuration? (If it is a bug the code a few lines down at 4872 is likely also a bug.)

I hit the very same issue diagnosing a stream not being bypassed after hitting the configured stream depth. With the patch (change 'and' to 'or'), the setup worked as expected.

Not sure if the assumptions the code makes (both sides must reach stream.depth) or my expectations (the traffic-heavy side is sufficient) are buggy. Maybe a stream.depth has to be superseded by stream.depth_min and stream.depth_max to allow quicker bypassing without allowing evasion by one-sided spam.

I am facing a rather weak device that nonetheless should perform as a complete IPS. This makes it important to bypass large streams for efficiency's sake. And for highly asymmetric workloads like an http download, all the ACKs combined probably never reach stream.depth.

Actions #2

Updated by Andreas Herz over 5 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #3

Updated by Andreas Herz over 5 years ago

Are you willing to submit a PR for that?

Actions #4

Updated by Victor Julien about 5 years ago

  • Status changed from New to Closed
  • Assignee changed from OISF Dev to Phil Young
  • Target version changed from TBD to 5.0rc1
Actions

Also available in: Atom PDF