Project

General

Profile

Actions

Support #2126

closed

IPS Mode & Pseudo Packets

Added by Ryan L almost 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Affected Versions:
Label:

Description

Hi,

I've been studying the source code and see that the engine often creates and enqueues new pseudo packets in a variety of scenarios:

-While handling IP Fragmentation, it will create a packet with the defragmented contents
-While handling tunnels, it will create a new packet for the packet in the tunnel
-When a flow expires, it will create a pseudo packet to force final stream reassembly

My question is: does Suricata keep the "parent" packet around and drop it if the "child" packet matches a signature? For example, if we receive a packet that completes a fragmented IP packet, Suricata creates a pseudo packet with the entire defragmented packet, which is then run through the rest of the pipeline. If this new packet matches a signature, will the original packet that contained the last fragment also be dropped? Similarly, will Suricata drop the tunnel packet if the packet inside of it matches a signature? (I assume this wouldn't happen in the flow timeout case.) This would require keeping the parent packets around in memory, and I can't tell if that is happening or not from looking at the source.

Thank you!

Actions #1

Updated by Victor Julien almost 7 years ago

Yes the pseudo packets keep a connection to their parent through the Packet::root pointer. The root packet will not be verdicted until it's children are all ready.

The flow timeout case is different indeed. But it's mostly needed in IDS mode as there a lot of processing waits for ACK's to come in. So there is a built-in delay for processing things. In this case the flow timeout logic has to see what work is still left to do. In the IPS case we act much more immediate on packets, so the flow manager shouldn't need to do as much.

In 4.0 you'll see a lot less pseudo packets, esp in IPS mode due to some internal restructuring.

Actions #2

Updated by Andreas Herz almost 7 years ago

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

Updated by Victor Julien almost 7 years ago

  • Status changed from New to Closed
  • Assignee deleted (OISF Dev)
Actions

Also available in: Atom PDF