Project

General

Profile

Actions

Feature #2772

open

Add MPLS labels to alert output

Added by Wesley van der Ree over 5 years ago. Updated 5 months ago.

Status:
Assigned
Priority:
Normal
Target version:
Effort:
low
Difficulty:
Label:
Protocol

Description

It would be great if Suricata is capable of providing the mpls labels to the alerts in the eve log ouput the same way as he did for vlan tags.

{"mpls":29}
or {"mpls": [29, 30]}


Related issues 1 (1 open0 closed)

Related to Suricata - Task #6443: Suricon 2023 brainstormAssignedVictor JulienActions
Actions #1

Updated by Victor Julien about 4 years ago

  • Label Protocol added
Actions #2

Updated by Sascha Steinbiss 8 months ago

Just noticed this ticket; in general having these MPLS info would be interesting for us as well. I have prepared a first shot of MPLS logging support by using VLAN support as an inspiration (see https://github.com/satta/suricata/tree/mpls) but I am not sure about some of the details like

  • is it expected (or common) to see multiple sets of labels in the same flow, and/or
  • would it be expected to be able to separate flows based on MPLS labels (like it is done for VLAN tags via "vlan.use-for-tracking")?

I do not have much experience with how this technology is actually used out there and publicly available pcaps are pretty simplistic and do not go beyond the basics. Any comments or input? The current implementation assumes that all packets in a flow share a set of labels.

Also, I have currently limited the number of labels parsed to 3, and if there are more than 3 an event is raised. If anyone can come up with a realistic estimate of how many labels are typically used in common use cases, it would help set a better constraint.

Actions #3

Updated by Sascha Steinbiss 8 months ago

For instance, the current code would produce the following EVE (among others):

{
  "timestamp": "2000-03-03T22:27:46.896814+0100",
  "flow_id": 755564368240102,
  "pcap_cnt": 21,
  "event_type": "alert",
  "mpls": [
    18,
    16
  ],
  "src_ip": "10.31.0.1",
  "src_port": 11001,
  "dest_ip": "10.34.0.1",
  "dest_port": 23,
  "proto": "TCP",
  "pkt_src": "wire/pcap",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 1,
    "rev": 1,
    "signature": "TEST Telnet Activity",
    "category": "",
    "severity": 3
  },
  "direction": "to_server",
  "flow": {
    "pkts_toserver": 1,
    "pkts_toclient": 0,
    "bytes_toserver": 66,
    "bytes_toclient": 0,
    "start": "2000-03-03T22:27:46.896814+0100",
    "src_ip": "10.31.0.1",
    "dest_ip": "10.34.0.1",
    "src_port": 11001,
    "dest_port": 23
  }
}
{
  "timestamp": "2000-03-03T22:27:41.942807+0100",
  "flow_id": 755564368240102,
  "event_type": "flow",
  "mpls": [
    18,
    16
  ],
  "src_ip": "10.31.0.1",
  "src_port": 11001,
  "dest_ip": "10.34.0.1",
  "dest_port": 23,
  "proto": "TCP",
  "app_proto": "telnet",
  "flow": {
    "pkts_toserver": 10,
    "pkts_toclient": 6,
    "bytes_toserver": 648,
    "bytes_toclient": 397,
    "start": "2000-03-03T22:27:46.896814+0100",
    "end": "2000-03-03T22:27:48.998503+0100",
    "age": 2,
    "state": "closed",
    "reason": "shutdown",
    "alerted": true
  },
  "tcp": {
    "tcp_flags": "1b",
    "tcp_flags_ts": "1b",
    "tcp_flags_tc": "1b",
    "syn": true,
    "fin": true,
    "psh": true,
    "ack": true,
    "state": "closed",
    "ts_max_regions": 1,
    "tc_max_regions": 1
  }
}

for the call
suricata -v -S mplstest.rules -v -k none -r mpls-twolevel.cap -c suricata.yaml -l .

and rules:
alert tcp any any -> any 23 (msg:"TEST Telnet Activity"; classtype:policy-violation; rev: 1; gid: 1; sid: 1;)

with this pcap: https://wiki.wireshark.org/uploads/__moin_import__/attachments/SampleCaptures/mpls-twolevel.cap

Actions #4

Updated by Sascha Steinbiss 8 months ago

I also noticed that there are already https://github.com/OISF/suricata/pull/4311 (which is by Wesley who this ticket is assigned to) and https://github.com/OISF/suricata/pull/4977 (which introduces a useful data structure to implement this) but they seem to have stalled a bit.
Any news on that front?

Also, unfortunately, the broader questions about how label gathering and logging generalizes to flows are not addressed there either...

Actions #5

Updated by Sascha Steinbiss 7 months ago

Any comments here? Is there anything anybody is waiting for that I might be able to help with to get this feature going?

Actions #6

Updated by Philippe Antoine 6 months ago

  • Related to Task #6443: Suricon 2023 brainstorm added
Actions #7

Updated by Philippe Antoine 6 months ago

Trying to sum up Sascha at Suricon 2023 :
Also, would same IP with different MPLS labels need to be unified ?

Actions #8

Updated by Philippe Antoine 6 months ago

Suricon 2023 :
- Make Packet structure more compact
- Make it easier to extend decoders without having to update the Packet structure (not only vlan, but mols and other)
see PR quoted above

Actions #9

Updated by Victor Julien 5 months ago

  • Status changed from New to Assigned
Actions #10

Updated by Victor Julien 5 months ago

  • Assignee changed from Wesley van der Ree to Community Ticket
Actions

Also available in: Atom PDF