Project

General

Profile

Actions
Copy link

Feature #8566

open
VJ VJ

firewall: support generating alerts on default policy

Feature #8566: firewall: support generating alerts on default policy

Added by Victor Julien 5 days ago. Updated 1 day ago.

Status:
In Review
Priority:
Normal
Assignee:
Victor Julien
Target version:
9.0.0-beta1
Effort:
Difficulty:
Label:

Description

Currently this won't work as the default policy does not have a Signature object.

firewall:
  policies:
    http:
      request-started: [ "accept:hook" ]

      request-body: [ "accept:hook" ]
      request-trailer: [ "accept:hook" ]
      request-complete: [ "accept:tx" ,"alert" ]

Related issues 3 (3 open — 0 closed)

Related to Suricata - Feature #7701: firewall: configurable default policiesResolvedVictor JulienActions
Related to Suricata - Feature #8479: eve/firewall: dedicated log record typeNewActions
Blocks Suricata - Story #7583: 9.0.0: usecase: improve firewall usecaseAssignedVictor JulienActions

VJ Updated by Victor Julien 5 days ago Actions
Copy link
 #1

  • Related to Feature #7701: firewall: configurable default policies added
  • Related to Feature #8479: eve/firewall: dedicated log record type added

VJ Updated by Victor Julien 5 days ago Actions
Copy link
 #2

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

VJ Updated by Victor Julien 4 days ago Actions
Copy link
 #3

  • Status changed from Assigned to In Progress

VJ Updated by Victor Julien 4 days ago Actions
Copy link
 #4

  • Status changed from In Progress to In Review

https://github.com/OISF/suricata/pull/15402 with tests in https://github.com/OISF/suricata-verify/pull/3095

Example:

{
  "timestamp": "2022-08-04T13:41:13.160545+0000",
  "flow_id": 408062294761793,
  "pcap_cnt": 1,
  "event_type": "alert",
  "src_ip": "10.20.0.14",
  "src_port": 38576,
  "dest_ip": "142.251.111.105",
  "dest_port": 443,
  "proto": "TCP",
  "ip_v": 4,
  "pkt_src": "wire/pcap",
  "alert": {
    "action": "allowed",
    "engine": "fw",
    "gid": 0,
    "signature_id": 0,
    "rev": 0,
    "signature": "default packet policy accept:hook for packet:filter",
    "category": "",
    "severity": 0
  },
  "firewall": {},
  "direction": "to_server",
  "flow": {
    "pkts_toserver": 1,
    "pkts_toclient": 0,
    "bytes_toserver": 74,
    "bytes_toclient": 0,
    "start": "2022-08-04T13:41:13.160545+0000",
    "src_ip": "10.20.0.14",
    "dest_ip": "142.251.111.105",
    "src_port": 38576,
    "dest_port": 443
  }
}


{
  "timestamp": "2016-07-13T22:42:07.199844+0000",
  "flow_id": 2019295794668825,
  "pcap_cnt": 4,
  "event_type": "alert",
  "src_ip": "10.16.1.11",
  "src_port": 54186,
  "dest_ip": "82.165.177.154",
  "dest_port": 80,
  "proto": "TCP",
  "ip_v": 4,
  "pkt_src": "wire/pcap",
  "tx_id": 0,
  "alert": {
    "action": "allowed",
    "engine": "fw",
    "gid": 0,
    "signature_id": 0,
    "rev": 0,
    "signature": "default app policy accept:hook for http:request_started",
    "category": "",
    "severity": 0
  },
  "firewall": {
    "hook": "request_started" 
  },
  "ts_progress": "request_complete",
  "tc_progress": "response_started",
  "http": {
    "hostname": "www.testmyids.com",
    "url": "/",
    "http_user_agent": "curl/7.43.0",
    "http_method": "GET",
    "protocol": "HTTP/1.1",
    "length": 0
  },
  "app_proto": "http",
  "direction": "to_server",
  "flow": {
    "pkts_toserver": 3,
    "pkts_toclient": 1,
    "bytes_toserver": 263,
    "bytes_toclient": 62,
    "start": "2016-07-13T22:42:07.011401+0000",
    "src_ip": "10.16.1.11",
    "dest_ip": "82.165.177.154",
    "src_port": 54186,
    "dest_port": 80
  }
}

JI Updated by Jason Ish 1 day ago Actions
Copy link
 #5

Worth noting I think: With respect to logging on the default policies, this introduces variance in the alert.signature over the same sid, which is not something we've seen before.

VJ Updated by Victor Julien 1 day ago · Edited Actions
Copy link
 #6

I suppose we could simply omit the signature_id, and rev and gid etc. But that is somewhat a breaking pattern too.

JI Updated by Jason Ish 1 day ago Actions
Copy link
 #7

Victor Julien wrote in #note-6:

I suppose we could simply omit the signature_id, and rev and gid etc. But that is somewhat a breaking pattern too.

I think what I would like to see as someone who might be parsing and building around this alerts are a static "alert.signature" like we are used to. Something like "default firewall policy". Then enough info in the firewall object to build out a description like "default firewall policy: hook=http1:request_started action=accept:hook" or something along those lines.

VJ Updated by Victor Julien 1 day ago · Edited Actions
Copy link
 #8

Makes sense. I did start something in that direction, but it needs to get fleshed out

In the branch

{
  "timestamp": "2016-07-13T22:42:07.199844+0000",
  "flow_id": 2019292896736677,
  "pcap_cnt": 4,
  "event_type": "alert",
  "src_ip": "10.16.1.11",
  "src_port": 54186,
  "dest_ip": "82.165.177.154",
  "dest_port": 80,
  "proto": "TCP",
  "ip_v": 4,
  "pkt_src": "wire/pcap",
  "tx_id": 0,
  "alert": {
    "action": "allowed",
    "engine": "fw",
    "gid": 0,
    "signature_id": 0,
    "rev": 0,
    "signature": "default app policy accept:hook for http:request_body",
    "category": "",
    "severity": 0
  },
  "firewall": {
    "hook": "request_body" 
  },

But maybe the firewall object should look something like

  "firewall": {
    "policy": "accept:hook,alert" 
    "hook": "http:request_body" 
  }

JI Updated by Jason Ish 1 day ago Actions
Copy link
 #9

Yes, this is better:

"firewall": {
    "policy": "accept:hook,alert" 
    "hook": "http:request_body" 
}

Then I wonder if the alert.signature should be more like "SURICATA FW default policy", just to fit our existing patterns.

Actions
Copy link

Also available in: PDF Atom