[New Rule] Kubernetes Exposed Service Created With Type NodePort (#2075)

* [New Rule] Kubernetes Exposed Service Created With Type NodePort new rule toml for exposed service created with type nodeport and added all k8s fields to non-ecs-schema * Update rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com> Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com> Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
2022-07-28 13:18:56 -04:00
parent c1486407aa
commit 97f3a8cad2
1 changed files with 66 additions and 0 deletions
@@ -0,0 +1,66 @@
+[metadata]
+creation_date = "2022/07/05"
+integration = "kubernetes"
+maturity = "production"
+min_stack_comments = "Necessary audit log fields not available prior to 8.2"
+min_stack_version = "8.2"
+updated_date = "2022/07/05"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to
+externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster
+that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod
+through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept
+traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers
+within a cluster. This creates a direct method of communication between the cluster and the outside world, which could
+be used for more malicious behavior and certainly widens the attack surface of your cluster.
+"""
+false_positives = [
+    """
+    Developers may have a legitimate use for NodePorts. For frontend parts of an application you may want to expose a
+    Service onto an external IP address without using cloud specific Loadbalancers. NodePort can be used to expose the
+    Service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort Service from
+    outside the cluster, by requesting <NodeIP>:<NodePort>. NodePort unlike Loadbalancers, allow the freedom to set up
+    your own load balancing solution, configure environments that aren't fully supported by Kubernetes, or even to
+    expose one or more node's IPs directly.
+    """,
+]
+index = ["logs-kubernetes.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Kubernetes Exposed Service Created With Type NodePort"
+note = """## Setup
+
+The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types",
+    "https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport",
+    "https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/",
+]
+risk_score = 47
+rule_id = "65f9bccd-510b-40df-8263-334f03174fed"
+severity = "medium"
+tags = ["Elastic", "Kubernetes", "Continuous Monitoring", "Execution", "Persistence"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+kubernetes.audit.objectRef.resource:"services" and kubernetes.audit.verb:("create" or "update" or "patch") and kubernetes.audit.requestObject.spec.type:"NodePort"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1133"
+name = "External Remote Services"
+reference = "https://attack.mitre.org/techniques/T1133/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+