Bug #2986
closedstream bypass not making callback as expected
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.)
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
.
Updated by Andreas Herz over 5 years ago
- Assignee set to OISF Dev
- Target version set to TBD
Updated by Andreas Herz over 5 years ago
Are you willing to submit a PR for that?
Updated by Victor Julien over 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