Project

General

Profile

Actions

Feature #6268

open

Recognize related ICMP request/response pairs

Added by Jamie Lavigne over 1 year ago. Updated 12 months ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

Today Suricata's support for any deeper inspection of the ICMP protocol is mostly stateless matching on packet contents, and it does not seem to support stateful request/response pairs by type. Best explained with an example:

These rules allow ICMP requests to be initiated outbound and their responses to come back, and block all other traffic:

pass icmp $HOME_NET any -> $EXTERNAL_NET any (sid:1;)
drop ip any any -> any any (msg:"Drop everything else"; sid:2;)

However, there isn't a way to limit the ICMP types when the request and response type differ. The simplest example is "ping", which uses an ICMP type 8 for its requests and type 0 for replies. It's possible to limit the outbound requests with a rule like this, but Suricata doesn't seem to associate the responses with this session because they use a different ICMP type:
pass icmp $HOME_NET any -> $EXTERNAL_NET any (sid:1; itype:8;)
drop ip any any -> any any (msg:"Drop everything else"; sid:2;)

It's possible to open this up and make the ping work by adding a separate rule filtering on `itype:0` in the opposite direction, but this also allows unsolicited echo replies.

The feature request is to support associating the ICMP replies back to their requests and statefully allow the responses to the allowed request flows. Another similar case is relating ICMP errors associated with TCP connections (i.e. what iptables calls "related" connections), but I haven't tested whether this is already supported.

Actions #1

Updated by Victor Julien 12 months ago

  • Assignee changed from OISF Dev to Victor Julien
Actions

Also available in: Atom PDF