Ignore common UDP ports

[jackmtpt]

443 (http3) and 88 (kerberos) are expected to see UDP traffic

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind feature

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area rules

/area registry

/area build

/area documentation

Proposed rule maturity level

Uncomment one (or more) /area <> lines (only for PRs that add or modify rules):

/area maturity-stable

/area maturity-incubating

/area maturity-sandbox

/area maturity-deprecated

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jackmtpt
Once this PR has been reviewed and has the lgtm label, please assign darryk10 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[poiana]

Welcome @jackmtpt! It looks like this is your first PR to falcosecurity/rules 🎉

[incertum]

Thank you 🎉 , we will check on it soon!

[github-actions]

Rules files suggestions

falco-incubating_rules.yaml

Comparing 3341cb283f91a28fb400d2da944943da27c16a3d with latest tag falco-incubating-rules-4.0.0

Patch changes:

• Rule System procs network activity changed its output fields
• Rule Unexpected UDP Traffic changed its output fields
• Rule Contact EC2 Instance Metadata Service From Container changed its output fields
• Rule Contact cloud metadata service from container changed its output fields
• Rule Network Connection outside Local Subnet changed its output fields
• List expected_udp_ports has some item added or removed

[jackmtpt]

Looks like the linting job failed for a bunch of files that weren't modified in this PR?

[incertum]

Looks like the linting job failed for a bunch of files that weren't modified in this PR?

Yes this is currently always failing as we have not yet reached a consensus wrt to the best linting approach. This CI check is also not required to pass atm.

Re the changes -- I don't see problems with the changes as in many rules we are a bit more conservative. This rule is an "incubating" rule and highly environment specific wrt what is considered unexpected, so it's fair to expect adopters to adjust this rule for their environment anyways.

@darryk10 could you help with the review? Thanks.

[Some of the reviewers may still be on PTO and this review may be delayed].

[leogr]

cc @loresuso

[darryk10]

Hi,
I think both are valid use cases that we might need to whitelist to reduce possible noise.
I wondered if we could whitelist the use case using a port and process using it, instead of removing stopping monitoring the overall port.

[jackmtpt]

To be honest we probably would not bother whitelisting (port, app) pairs in these rules; it's too much duplication from network policies/firewall rules.