rules
rules copied to clipboard
Ignore common UDP ports
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:
[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.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Welcome @jackmtpt! It looks like this is your first PR to falcosecurity/rules 🎉
Thank you 🎉 , we will check on it soon!
Rules files suggestions
falco-incubating_rules.yaml
Comparing 3341cb283f91a28fb400d2da944943da27c16a3d with latest tag falco-incubating-rules-4.0.0
Patch changes:
- Rule
System procs network activitychanged its output fields - Rule
Unexpected UDP Trafficchanged its output fields - Rule
Contact EC2 Instance Metadata Service From Containerchanged its output fields - Rule
Contact cloud metadata service from containerchanged its output fields - Rule
Network Connection outside Local Subnetchanged its output fields - List
expected_udp_portshas some item added or removed
Looks like the linting job failed for a bunch of files that weren't modified in this PR?
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].
cc @loresuso
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.
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.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
cc @darryk10 @loresuso
/help
cc @darryk10 @loresuso
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
We don't use Falco anymore so I no longer care about this. Feel free to just close it.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closed this PR.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with
/reopen.Mark the issue as fresh with
/remove-lifecycle rotten.Provide feedback via https://github.com/falcosecurity/community. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.