Project

General

Profile

Actions
Copy link

Feature #8566

closed
VJ VJ

firewall: support generating alerts on default policy

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

Added by Victor Julien about 2 months ago. Updated 18 days ago.

Status:
Closed
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" ]

Subtasks 1 (0 open — 1 closed)

Feature #8609: firewall: support generating alerts on default policy (8.0.x backport)ClosedVictor JulienActions

Related issues 3 (2 open — 1 closed)

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

VJ Updated by Victor Julien about 2 months 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 about 2 months ago Actions
Copy link
 #2

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

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

  • Status changed from Assigned to In Progress

VJ Updated by Victor Julien about 2 months 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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.

VJ Updated by Victor Julien about 1 month ago Actions
Copy link
 #10

  • Status changed from In Review to Resolved

VJ Updated by Victor Julien about 1 month ago Actions
Copy link
 #11

  • Label Needs backport to 8.0 added

OT Updated by OISF Ticketbot about 1 month ago Actions
Copy link
 #12

  • Subtask #8609 added

OT Updated by OISF Ticketbot about 1 month ago Actions
Copy link
 #13

  • Label deleted (Needs backport to 8.0)

VJ Updated by Victor Julien 18 days ago Actions
Copy link
 #14

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: PDF Atom