Proposal for 2 new Falco rules for syscall source, and 4 for Kubernetes audit source. #1122

vicenteherrera · 2020-03-26T11:20:16Z

What type of PR is this?
/kind feature
/kind rule-create

Any specific area of the project related to this PR?
/area rules

What this PR does / why we need it:

These proposed rules detect network and Kubernetes activity that, outside some whitelists, could indicate malicious activity. No other rules perform similar detections, and they are generic so everybody will benefit for having them in their Falco installation. See the proposed release notes for specific details.

Which issue(s) this PR fixes:

Fixes #1121

Special notes for your reviewer:

The Issue is just a description of the proposal of the rules, I don't know if it would have been better to just create de pull request only.

Does this PR introduce a user-facing change?:

Yes, new rules available in falco.yaml and k8s_audit_rules.yaml, one of the enabled by default: "Ingress Object without TLS Certificate Created"

rule(Full K8s Administrative Access): detect any k8s operation by an administrator with full access
rule(Ingress Object without TLS Certificate Created): detect any attempt to create an ingress without TLS certification (rule enabled by default)
rule(Untrusted Node Successfully Joined the Cluster): detect a node successfully joined the cluster outside of the list of allowed nodes
rule(Untrusted Node Unsuccessfully Tried to Join the Cluster): detect an unsuccessful attempt to join the cluster for a node not in the list of allowed nodes
rule(Network Connection outside Local Subnet): detect traffic to image outside local subnet
rule(Outbound or Inbound Traffic not to Authorized Server Process and Port): detect traffic that is not to authorized server process and port

…nd detect traffic that is not to authorized server process and port Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

…des successfully joining the cluster, nodes unsuccessfully attempt to join, creation ingress without TLS certificate Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

vicenteherrera · 2020-03-26T21:24:30Z

/assign @Kaizhe

Kaizhe · 2020-03-26T23:22:52Z

rules/k8s_audit_rules.yaml

+
+
+- list: full_admin_k8s_users
+  items: ["admin", "kubernetes-admin",  "kubernetes-admin@kubernetes", "default", "kubernetes-admin@cluster.local", "minikube-user"]


why default is admin user?

K3s admin user is called "default", when /etc/rancher/k3s/k3s.yaml configuration file is created.

The best direct link I can find to share about this is: k3s-io/k3s#140 (comment)

I don't know whether falco supports k3s ? And also whether the audit events from k3s is compatible with k8s. If you can provide more information here, that would be great!

Maybe they are not, and we overstepped here. k3s have an audit webhook. Let me make some test but it will take some time.

it may be good to remove default in this PR, once you confirm falco support k3s and k3s audit is event is compatible with k8s, then we can add it back.

Remove the default user, and clarified comments on the rule to make clear that we are detecting only usernames and not roles.

Kaizhe · 2020-03-26T23:25:36Z

rules/k8s_audit_rules.yaml

+# # Execute any kubectl command connected using default cluster user, as:
+# kubectl create namespace rule-test
+
+- rule: Full K8s Administrative Access


Full k8s administrative access should be based on the roles granted to the user, not the user name. I would put this rule on hold or disabled by default.

As Falco supported fields indicate, role information is only available in the Kubernetes audit event "when the request object refers to a cluster role binding" or "when the request object refers to a role/cluster role". https://falco.org/docs/rules/supported-fields/

So for any general event, we can only rely on user name to check this.

Also the rule is disabled by default, including a condition "and not allowed_full_admin_users" to a macro that is defined as "k8s_audit_always_true".

The rules works only for k8s audit events. Relying on username is not the right thing to do. And as I suggest, this is something I want to put it on hold or disable by default.

There is a enabled field in the rule you can specify.

The user name that executed the Kubernetes command is part of the k8s event in ka.user.name (but not the role). Another existing rule "Disallowed K8s User" also list allowed user names as a way to get a detection if a different one executes a command (this new rule is more or less the opposite).

I like more the clear semantics of the enabled field, but right now the only way to change a "enabled: false" to true would be to edit the original k8s_audit_rules.yaml. That would lead to problems when rules get updated. Macros, on the other hand, can be overwritten in falco_rules.loca.yaml or other files to enable rules more easily. I should post a feature request for a better way to enable existing disabled rules.

That's the intention for enabled: false and it is up to the user to enable it. In OSS community, we can worry less about the commercial product impact regarding patching rules.

OSS is my concern here. I don't think it should be encouraged to make people modify falco_rules.yaml or k8s_audit_rules.yaml directly for rules activation or customization, as it is going to make it harder for them to keep up with updates. I believe that's why falco_rules.local.yaml and macros with (never_true) and similar values exist on all other rules. enabled:false as it is defined now is not used in any other rule, they all rely on macros for activation.
Just an opinion, of course, tell me if you still think it's necessary.

Kaizhe · 2020-03-26T23:29:44Z

rules/k8s_audit_rules.yaml

+- macro: allow_all_k8s_nodes
+  condition: (k8s_audit_always_true)
+
+- list: allowed_k8s_nodes


most likely the decision shouldn't be made by name. Let's create a list of trusted node labels and only nodes contains any trusted labels can join the cluster.

Ok, but let me try to discuss this a little bit

So, you can add labels to a node at the same time that it joins the cluster. But we feel that if someone has the kind of access level to your cluster to add a node to it, he may well replicate the labels on the existing nodes to the new one, in an effort to make it look similar to the other ones.

The node name is a more unique way to represent trust in nodes. Someone may see other labels in existing nodes, but it's more difficult that he is aware of the specific list of allowed node names before attempting to join. And when that happens, Falco is going to alert you.

Tell me what you think about this. ;-)

Managing by node name will be painful. As this is the first version, I will let it in and we can come back to improve it.

Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

… rule is disabled by default Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

Kaizhe · 2020-04-07T17:22:26Z

/lgtm

poiana · 2020-04-07T17:22:28Z

LGTM label has been added.

Git tree hash: ad8c71b6c9873d2686798bd9eb3e476977683f80

leodido

Thanks for contributing these Vicente! 🎉

I need some time to look deeper at them. In the meantime could you please adjust the release-note block according to our CONTRIBUTING guidelines?

Since this PR regards rules its release-note block should use the guidelines here

leodido · 2020-04-08T13:41:02Z

/hold

need to adjust release-note block
need review

fntlnz

WOW @vicenteherrera - this is great

leodido

Great Job @vicenteherrera, thanks!

poiana · 2020-04-14T11:16:31Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fntlnz, Kaizhe, leodido

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

The pull request process is described here

Needs approval from an approver in each of these files:

~~rules/OWNERS~~ [Kaizhe,fntlnz,leodido]

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

leodido · 2020-04-14T11:17:16Z

This is in!

/milestone 0.22.0

/hold cancel

poiana added release-note kind/feature dco-signoff: no kind/rule-create labels Mar 26, 2020

poiana requested review from Kaizhe and leodido March 26, 2020 11:20

poiana added area/rules size/L labels Mar 26, 2020

vicenteherrera mentioned this pull request Mar 26, 2020

Additional Falco rules, both for syscall and Kubernetes audit sources #1121

Closed

vicenteherrera added 2 commits March 26, 2020 22:23

Added two new rules to detect traffic to image outside local subnet a…

0d4f4a1

…nd detect traffic that is not to authorized server process and port Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

Added four new rules, to detect k8s operation by an administrator, no…

14a04da

…des successfully joining the cluster, nodes unsuccessfully attempt to join, creation ingress without TLS certificate Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

vicenteherrera force-pushed the master branch from b8f9560 to 14a04da Compare March 26, 2020 21:23

poiana added dco-signoff: yes and removed dco-signoff: no labels Mar 26, 2020

poiana assigned Kaizhe Mar 26, 2020

Kaizhe reviewed Mar 26, 2020

View reviewed changes

poiana added dco-signoff: no and removed dco-signoff: yes labels Apr 7, 2020

Removed default K3s admin user from list, clarified comments

c1c4dbe

Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

vicenteherrera force-pushed the master branch from 6a3abc3 to c1c4dbe Compare April 7, 2020 09:45

poiana added dco-signoff: yes and removed dco-signoff: no labels Apr 7, 2020

Introduce missing allowed_full_admin_users macro so its corresponding…

9c22379

… rule is disabled by default Signed-off-by: Vicente Herrera <vicenteherrera@vicenteherrera.com>

poiana added the lgtm label Apr 7, 2020

poiana added the approved label Apr 7, 2020

Kaizhe approved these changes Apr 7, 2020

View reviewed changes

leodido reviewed Apr 8, 2020

View reviewed changes

poiana added the do-not-merge/hold label Apr 8, 2020

fntlnz approved these changes Apr 14, 2020

View reviewed changes

poiana assigned fntlnz Apr 14, 2020

leodido approved these changes Apr 14, 2020

View reviewed changes

poiana assigned leodido Apr 14, 2020

poiana removed the do-not-merge/hold label Apr 14, 2020

poiana added this to the 0.22.0 milestone Apr 14, 2020

poiana merged commit 9fd08ce into falcosecurity:master Apr 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposal for 2 new Falco rules for syscall source, and 4 for Kubernetes audit source. #1122

Proposal for 2 new Falco rules for syscall source, and 4 for Kubernetes audit source. #1122

vicenteherrera commented Mar 26, 2020 •

edited by leogr

Loading

vicenteherrera commented Mar 26, 2020

Kaizhe Mar 26, 2020

vicenteherrera Apr 1, 2020

Kaizhe Apr 1, 2020

vicenteherrera Apr 2, 2020

Kaizhe Apr 2, 2020

vicenteherrera Apr 7, 2020

Kaizhe Mar 26, 2020

vicenteherrera Apr 1, 2020

Kaizhe Apr 1, 2020

Kaizhe Apr 1, 2020

vicenteherrera Apr 2, 2020

Kaizhe Apr 2, 2020

vicenteherrera Apr 7, 2020

Kaizhe Mar 26, 2020

vicenteherrera Apr 2, 2020

Kaizhe Apr 7, 2020

Kaizhe commented Apr 7, 2020

poiana commented Apr 7, 2020

leodido left a comment

leodido commented Apr 8, 2020

fntlnz left a comment

leodido left a comment

poiana commented Apr 14, 2020

leodido commented Apr 14, 2020



		- list: full_admin_k8s_users
		items: ["admin", "kubernetes-admin", "kubernetes-admin@kubernetes", "default", "kubernetes-admin@cluster.local", "minikube-user"]

Proposal for 2 new Falco rules for syscall source, and 4 for Kubernetes audit source. #1122

Proposal for 2 new Falco rules for syscall source, and 4 for Kubernetes audit source. #1122

Conversation

vicenteherrera commented Mar 26, 2020 • edited by leogr Loading

vicenteherrera commented Mar 26, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kaizhe commented Apr 7, 2020

poiana commented Apr 7, 2020

leodido left a comment

Choose a reason for hiding this comment

leodido commented Apr 8, 2020

fntlnz left a comment

Choose a reason for hiding this comment

leodido left a comment

Choose a reason for hiding this comment

poiana commented Apr 14, 2020

leodido commented Apr 14, 2020

vicenteherrera commented Mar 26, 2020 •

edited by leogr

Loading