Bug #2522: The cross-effects of rules on each other, without the use of flowbits. - Suricata - Open Information Security Foundation

Actions

Copy link

Bug #2522

closed

The cross-effects of rules on each other, without the use of flowbits.

Added by Jane Ostin almost 6 years ago. Updated over 5 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Victor Julien

Target version:

4.1rc2

Affected Versions:

4.1beta1

Effort:

Difficulty:

Label:

Description

There is an opportunity to influence the operation of one rule by another, even if they are not unified by flowbits. This happens if the signature is affected, use both http and tcp buffers, and in the signature of which we will act, use the stream.
An eerie action at a distance stops, if in the signature of which we manage add "no_stream". Or, place all checks in the managed signature in the http buffers.

alert http $HOME_NET any -> $EXTERNAL_NET any (msg: "test1";
flow: established, to_server;  
content: "Accept-Encoding: identity";                       <- place here "http_header" for disable effect
content: "data="; http_client_body; depth:5;  
classtype: misc-activity; sid: 1; rev: 1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "test2";
flow: established, to_server;                               <- or place here "no_stream" 
content: "|6c55554503104840|"; offset:4;depth:8;
classtype: misc-activity; sid: 2; rev: 1;)

Pcap in attachment.
This is Suricata version 4.1.0-beta1 RELEASE

Files

f1b8a712ee9fb5eac9513fe21bfd6a3a964c0a3c328d5209fc0ee87d0c93fcea.pcap (34.9 KB) f1b8a712ee9fb5eac9513fe21bfd6a3a964c0a3c328d5209fc0ee87d0c93fcea.pcap

Jane Ostin, 06/25/2018 05:58 PM

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Victor Julien almost 6 years ago

Status changed from New to Assigned
Assignee changed from Anonymous to Victor Julien

Actions

Copy link

Updated by Victor Julien over 5 years ago

Related to Bug #2570: Signature affecting another's ability to detect and alert added

Actions

Copy link

Updated by Victor Julien over 5 years ago

This seems to be an interaction between the stream and client body inspection. The client body is not inspected until app-layer.protocols.http.libhtp.default-config.request-body-minimal-inspect-size is reached. This defaults to 32k. As the http_client_body pattern is the MPM, this means that the signature is not evaluated until the body reaches 32k (or is complete).

At the same time, the sid 2 is evaluated against the raw stream and it moves the 'raw stream progress' forward. The point in the stream were it starts doing this is determined by stream.reassembly.toserver-chunk-size, which defaults to ~2.5k.

The reason 'no_stream' works is that with this option sid 2 doesn't touch the stream progress tracker.

The reason 'http_header' works is that this makes sid 1 independent from the stream tracker.

In IPS mode this all works very differently and the effect is not observed. Both stream inspection and http body inspection is much more instantaneous, at the cost of some performance.

I'm thinking about ways to improve this, but in general when possible, do use the http_* keywords as much as possible.

Actions

Copy link

Updated by Victor Julien over 5 years ago

Related to deleted (Bug #2570: Signature affecting another's ability to detect and alert)

Actions

Copy link

Updated by Victor Julien over 5 years ago

Status changed from Assigned to Closed
Target version set to 4.1rc2

I've created a solution where the body is inspected earlier together with raw stream data. The 'min inspect size' will still be respected in the sense that the body tracker won't move forward until we've reached it. So some reinspection will happen in this case.

See https://github.com/OISF/suricata/pull/3451

Actions

Copy link