New use case: Firewall

[Woudan]

A lot fields are already present but a few are missing for basic traffic logging of a zone based firewall.

I don't thinks it's necessary to add specific firewall fields but i'm not sure. I've got the following proposition:

• from Zone : destination.zone
• to Zone : source.zone
• rule : event.rule
• action : event.action (reuse)

[webmat]

action : event.action (reuse)

Yes, this is precisely how event.action should be used. This is where your firewall's deny and allow would go.

rule: event.rule

Can you give examples of what would go in there? Is it a rule ID or a textual representation of the rule?

source.zone and destination.zone (also valid for event.rule)

We're in the process of documenting how to go about using fields that aren't defined in ECS in your event stream. I don't see a problem with you using these fields in your stream and it being ECS compliant.

Of course we may eventually decide to add them to ECS if it's a common enough use case. But you shouldn't feel blocked from using these fields in your stream.

[Woudan]

Can you give examples of what would go in there? Is it a rule ID or a textual representation of the rule?

The "rule" will be the firewall rule name that is hit and that generates this log/event and denies or permits the traffic.

Of course we may eventually decide to add them to ECS if it's a common enough use case. But you shouldn't feel blocked from using these fields in your stream.

Of course I can add those fields but these fields are used quite commonly in the big firewall vendors (Juniper, PaloAlto, Cisco etc.). That's why I would say they earn a well documented spot with the correct naming here.

[webmat]

Yes, agreed.

The context of my comment is that are working on making ECS GA soon (a minimum viable version of it). This means we must focus on firming up the fundamentals and keep the work on some of the use cases for later.

[ruflin]

@Woudan Because you could open a PR against use-cases for this: https://github.com/elastic/ecs/tree/master/use-cases There we have other fields which are not in ECS yet but should be taken into consideration.

[kleekai-gsd]

Came here looking for this as I was looking at how to work with my firewall logs. Searching around led me to packetbeat and here: https://www.elastic.co/guide/en/beats/packetbeat/current/exported-fields-flows_event.html

[willemdh]

Just wanted to add that I'm also missing the following 'firewall' related fields:

event.reason

source.region
destination.region

Some example globalprotect palo alto logs:

GlobalProtect portal user authentication failed. Login from: 1.55.1.162, Source region: 10.0.0.0-10.255.255.255,  User name: pre-logon, Reason: Cookie expired, Auth type: cookie.
GlobalProtect portal user authentication failed. Login from: 1.240.70.10, Source region: BE,  User name: bwzd45, Reason: Cookie expired, Auth type: cookie.

Or is there already any existing field I should put the reason of the event? About source and destination region, these can be populated with an ip range (internal regions) or land codes. SO I probably should create a conditional and set geo.country_iso_code if it's a country code...

But can I set 10.0.0.0-10.255.255.255 in source.ip? Or will this casue a mapping conflict?

auth_type seems more like a custom Palo Alto field, not sure yet where I should put that.

Also I can find a field host.architecture, but not a device.architecture or an os.architecture?

[praseodym]

Some other fields that I came across in firewall logging are:

• NAT information (xlate) src+dst ip+port
• Protocol level information (TCP flags, ICMP type+code)
• Firewall policy id, name and date

[zlammers]

I also need to retain zone info for source|destination, as well as a rule(/+policy) field. Rules should be keyword, as though it's often numeric, it's not always, depending on vendor.

Examples:

Checkpoint syslog: rule:"604" and inzone:"External" and outzone:"External"
Fortigate syslog: policyid=186 policytype=policy
Juniper syslog: policy-name=REDACTED

[Aqualie]

Some other fields that I came across in firewall logging are:

• NAT information (xlate) src+dst ip+port
• Protocol level information (TCP flags, ICMP type+code)
• Firewall policy id, name and date

We currently have the RULE category being added in 1.4 which addresses point #3.
INTERFACE category is being added in 1.4 as well which addresses point #1.
That leaves point #2, is there any plans on adding support for protocol level information? I'm currently tagging all of this under labels at the moment. To list a few(varies for IPv4 vs IPV6 BTW):
IPv4:

• TOS
• ECN
• TTL
• ID
• Offset
• Flags

IPv6:

• Class
• Flow Label
• Hop Limit

Then we get into more granular protocol level details... This can be found under https://docs.netgate.com/pfsense/en/latest/monitoring/filter-log-format-for-pfsense-2-2.html

after the IPV4 & IPV6 section.

[abraxxa]

I just came across this issue while looking for icmp(v6) type and code fields. Please add those to a future ECS version please.

[ebeahan]

Hi @abraxxa - a stage 0 RFC proposal was recently merged as a first step towards introducing ICMP/ICMPv6 fields in addition to network headers. We expect to continue moving the proposal forward soon.

[ebeahan]

As summarized here, many of the original discussion points have been introduced into ECS since this discussion started.

Let's close this discussion in favor of network headers RFC.