Ecs: Question: Fields for interfaces?

[MikePaquette]

source.interface and destination.interface fields missing? (Like to house “eth0”.)

No. 9 of 16. This question was asked by a new ECS user, who is familiar with mapping IT events to data models and use cases in other schemas. These questions are being posted as a GitHub issue, because a) they may offer valuable insights. b) we expect that many new users will have similar questions.

[MikePaquette]

Good point, these fields are indeed common for existing devices and event formats.

[adriansr]

Yep, we need this fields.

[ruflin]

This discussion here is also related: https://github.com/elastic/beats/pull/10218/files#r249520349

[zlammers]

Yes, definitely necessary. I am working on a project to parse/map FW data (right now, Cisco, Palo Alto, Checkpoint, Juniper, and Fortigate) to ECS instead of our current schema, and noticed yesterday that I couldn't find interface fields.

However, in addition to an interface field for source|target, the host (or observer?) object would need multiple interface fields as well. In the case of a firewall, you would often want to track the north/south interfaces which belong to the FW host itself, not the source|destination.

In our current schema we utilizedevice.interface.(in|out) fields to retain such. Swap device with host|observer and it's roughly the same - I would recommend both this and adding interface to source|destination.

Examples:

Fortigate FW syslog data contains: srcintf=port2 and dstintf=port6
Juniper: packet-incoming-interface=reth0.0
Palo Alto (csv in syslog): InboundInterface and OutboundInterface fields
Cisco syslog: ...on interface outside, ...on INSIDE interface, ...on interface outside to ...
Checkpoint syslog: ifname:"bond1"

[willemdh]

And what about switch interfaces...? Currently sflow counter_sample data contains:

 input_broadcast_packets |   | 28,465

 input_discarded_packets |   | 13

 input_errors |   | 380

 input_multicast_packets |   | 0

 input_octets |   | 8,368,639

 input_packets |   | 86,749

 input_unknown_protocol_packets |   | 0

 interface_direction |   | 0

 interface_index |   | 201,038

 interface_speed |   | 10,000,000

 interface_status |   | 3

 interface_type |   | 6

 ip_version |   | 1

 output_broadcast_packets |   | 12,686,647

 output_discarded_packets |   | 0

 output_errors |   | 0

 output_multicast_packets |   | 32,668,239

 output_octets |   | 4,140,427,418

 output_packets |   | 166,009

 promiscous_mode |   | 0

Not sure if there is already a plan to put this kind of data?

[webmat]

I'd like to get log samples for this.

Also, what fields specifically are we talking about? This one seems straightforward:

• [source|destination|client|server].interface (keyword): name of the interface, if known. E.g. eth0

Anything else?

@zlammers' suggestion of adding [host|observer|agent].interface.[in|out] is unclear to me. Is this meant to contain the same interface names? Like an array of all of interface names in .out for a normal computer or network device, and then internal-facing interface names in .in for network devices?

• If my understanding is wrong, could you clarify with sample values, and a quick description of the field?

[adriansr]

{source|destination|client|server}.interface are a must. Currently we're using custom fields for this:

cisco.asa:

"cisco.asa.source_interface": "outside",
"cisco.asa.destination_interface": "inside",

panw.panos:

"panw.panos.source.interface": "ethernet1/2",
"panw.panos.destination.interface": "ethernet1/1",

iptables.ubiquiti:

"iptables.input_device": "eth0",
"iptables.output_device": "eth2",

For iptables.log there's only one interface associated with events:

"iptables.input_device": "eth0",
"iptables.output_device": "",

NetFlow can have src&dst (numeric) interfaces:

"netflow.ingress_interface": 110,
"netflow.egress_interface": 158,

and sometimes a single interface:

"netflow.ingress_interface": 103,
"netflow.interface_description": "TenGigE0_6_0_1"

suricata.eve has only input interface:

"suricata.eve.in_iface": "enp0s3"

I think for some events it could be useful to have a direction-agnostic network.interface, but I'm not so sure. Maybe source.interface is enough.

[michieldetailleur]

@webmat
I would use (source|destination).interface for, obviously the interface on which a packet/flow/session came in and went out.

And would use interface.(in|out) when taking about paramaters/counters of a specific interface. Such as sFlow or SNMP information like @willemdh is talking about.
Or maybe interface.(input|output) is even more clear for this purpose.
Eg:
interface.in.packets: 30193
interface.out.octets: 9839

[zlammers]

@zlammers' suggestion of adding [host|observer|agent].interface.[in|out] is unclear to me. Is this meant to contain the same interface names? Like an array of all of interface names in .out for a normal computer or network device, and then internal-facing interface names in .in for network devices?

As @michieldetailleur and @adriansr referenced, host|observer|agent.(in|out) (or input|output) covers traffic flow through devices. In my specific case, I'm often looking at firewall data, and when traffic traverses the firewall, many devices report both the inbound and outbound interfaces utilized for that traffic, along with packets/bytes on each. I was only going to have a simple keyword value in interface, but there are good reasons above to make it a nested field that would have multiple keys interface.(in|out).(packets|bytes|name|description|etc) (in|out can be ingress|egress, inbound|outbound, whatever).

[BFLB]

@willemdh, the fields below are contained in a 7.1.1 metricbeat event

t metricset.name | network
t service.type | system

 system.network.in.bytes | 3,445,419,280

 system.network.in.dropped | 0

 system.network.in.errors | 0

 system.network.in.packets | 2,665,473

t system.network.name | eth0

 system.network.out.bytes | 2,352,320,431

 system.network.out.dropped | 0

 system.network.out.errors | 0

 system.network.out.packets | 1,802,388

Maybe this could be used / enhanced for switch, router, fw etc. interfaces as well.
Are they part of the ECS or custom fields?

[michieldetailleur]

@BFLB, that looks like a good design. Bonus points for it already being in use in metricbeat.

[enotspe]

@zlammers

ingress | egress

sounds more accuarate to me.

Like:
observer.ingress.interface.name

Or network can be reused (nested) instead of interface

observer.ingress.network.name