Project

General

Profile

Actions
Copy link

Feature #7699

open
VJ JF

firewall: separate stats for ips and firewall

Feature #7699: firewall: separate stats for ips and firewall

Added by Victor Julien 11 months ago. Updated about 12 hours ago.

Status:
In Progress
Priority:
Normal
Assignee:
Juliana Fajardini Reichow
Target version:
9.0.0-beta1
Effort:
Difficulty:
Label:

Description

Similar to logs, the eve stats are also reported combined (for example with firewall blocked counts reporting under "ips") that would be very useful to count separately.

Currently we have

{
  "accepted": 8,
  "blocked": 54,
  "rejected": 0,
  "replaced": 0,
  "drop_reason": {
    "decode_error": 0,
    "defrag_error": 0,
    "defrag_memcap": 0,
    "flow_memcap": 0,
    "flow_drop": 52,
    "applayer_error": 0,
    "applayer_memcap": 0,
    "rules": 1,
    "threshold_detection_filter": 0,
    "stream_error": 0,
    "stream_memcap": 0,
    "stream_midstream": 0,
    "stream_reassembly": 0,
    "stream_urgent": 0,
    "nfq_error": 0,
    "tunnel_packet_drop": 0,
    "default_packet_policy": 0,
    "default_app_policy": 1
  }
}

I think it could be sufficient to expand the drop reason a bit?

{
  "accepted": 8,
  "blocked": 54,
  ...
  "drop_reason": {
    ...
    "rules": 1,
    "firewall_rules": 1,
    ...
    "default_packet_policy": 0,
    "default_app_policy": 1
  }
}

default_packet_policy and default_app_policy imply firewall, so we'd only need a counter to indicate a firewall drop rule matched? firewall_rules here.

Could also break it out

{
  "accepted": 8,
  "blocked": 54,
  ...
  "drop_reason": {
    ...
    "rules": 1,
    ...
    "firewall": {
       "rules": 1,
       "default_packet_policy": 0,
       "default_app_policy": 1
    }
  }
}

Related issues 2 (1 open — 1 closed)

Has duplicate Suricata - Task #7850: stats: add dedicated counters for firewall modeRejectedOISF DevActions
Blocks Suricata - Story #7583: 9.0.0: usecase: improve firewall usecaseAssignedVictor JulienActions

JL Updated by Jamie Lavigne 11 months ago Actions
Copy link
 #1

I think that last one would be great, that groups all firewall drops together and breaks out rules from default policy drops.

VJ Updated by Victor Julien 8 months ago Actions
Copy link
 #2

  • Blocks Story #7583: 9.0.0: usecase: improve firewall usecase added

VJ Updated by Victor Julien 7 months ago Actions
Copy link
 #3

  • Status changed from Feedback to Assigned
  • Target version changed from TBD to 9.0.0-beta1

JF Updated by Juliana Fajardini Reichow 5 months ago Actions
Copy link
 #4

  • Has duplicate Task #7850: stats: add dedicated counters for firewall mode added

JF Updated by Juliana Fajardini Reichow 5 months ago Actions
Copy link
 #5

What was originally #7850 could be covered by this one, too:
"As part of this task, also make alert_queue_overflow counter dedicated to the alert queue overflow again
(cf https://github.com/OISF/suricata/pull/13700#discussion_r2264587964)."

JF Updated by Juliana Fajardini Reichow 15 days ago Actions
Copy link
 #6

  • Assignee changed from Victor Julien to Juliana Fajardini Reichow

JF Updated by Juliana Fajardini Reichow 8 days ago Actions
Copy link
 #7

  • Status changed from Assigned to In Progress

JF Updated by Juliana Fajardini Reichow 8 days ago Actions
Copy link
 #8

Draft for review/ discussion: https://github.com/OISF/suricata/pull/15166

JF Updated by Juliana Fajardini Reichow 4 days ago Actions
Copy link
 #9

We're looking for feedback on accepted packets, especially: if a packet is accepted by the Firewall, and later on dropped by the IPS engine, do you have suggestions on how this should be reported?

About the other counters, to make it easier to filter for firewall-related counters, we are thinking of two possibilities, for now:
- stats.ips.firewall :

stats.ips.firewall.accepted
stats.ips.firewall.blocked
stats.ips.firewall.detect.discarded_alerts
stats.ips.firewall.drop_reason {...}

- stats.firewall :
stats.firewall.accepted
stats.firewall.blocked
stats.firewall.detect.discarded_alerts
stats.firewall.drop_reason {...}

Insights are welcome! :)

AP Updated by Aneesh Patel about 20 hours ago Actions
Copy link
 #10

I believe we should treat the stats on the two engines independently. So that would mean if a packet passed firewall mode, but then got dropped by ips, it would report an incremented on accepted counter for stats.firewall and increment a blocked counter for stats.ips. If a packet was passed on a flow level in firewall, it can just increment counter in stats.firewall for accept and not touch the ips counters. So of the two examples above, I would be more in favor of stats.firewall as opposed to stats.ips.firewall

JL Updated by Jamie Lavigne about 12 hours ago Actions
Copy link
 #11

My mental model with this is two separate devices, a firewall with an IPS chained immediately downstream. I find that model is useful for reasoning about what the behavior should be in cases like these - in this case, incrementing a counter for accepted in firewall and dropped in IPS makes sense because that would be the outcome if they were separate appliances.

Actions
Copy link

Also available in: PDF Atom