Kubernetes Exposed Service Created With Type NodePort

  1[metadata]
  2creation_date = "2022/07/05"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to
 11externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster
 12that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod
 13through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept
 14traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers
 15within a cluster. This creates a direct method of communication between the cluster and the outside world, which could
 16be used for more malicious behavior and certainly widens the attack surface of your cluster.
 17"""
 18false_positives = [
 19    """
 20    Developers may have a legitimate use for NodePorts. For frontend parts of an application you may want to expose a
 21    Service onto an external IP address without using cloud specific Loadbalancers. NodePort can be used to expose the
 22    Service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort Service from
 23    outside the cluster, by requesting <NodeIP>:<NodePort>. NodePort unlike Loadbalancers, allow the freedom to set up
 24    your own load balancing solution, configure environments that aren't fully supported by Kubernetes, or even to
 25    expose one or more node's IPs directly.
 26    """,
 27]
 28index = ["logs-kubernetes.*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "Kubernetes Exposed Service Created With Type NodePort"
 32note = """## Triage and analysis
 33
 34> **Disclaimer**:
 35> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 36
 37### Investigating Kubernetes Exposed Service Created With Type NodePort
 38
 39Kubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks.
 40
 41### Possible investigation steps
 42
 43- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is "services" and kubernetes.audit.verb is "create", "update", or "patch".
 44- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized.
 45- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name.
 46- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally.
 47- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception.
 48- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent.
 49
 50### False positive analysis
 51
 52- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly.
 53- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters.
 54- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts.
 55- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms.
 56- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period.
 57
 58### Response and remediation
 59
 60- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception.
 61- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service.
 62- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service.
 63- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed.
 64- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture.
 65- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited.
 66- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly.
 67
 68## Setup
 69
 70The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 71references = [
 72    "https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types",
 73    "https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport",
 74    "https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/",
 75]
 76risk_score = 47
 77rule_id = "65f9bccd-510b-40df-8263-334f03174fed"
 78severity = "medium"
 79tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Persistence", "Resources: Investigation Guide"]
 80timestamp_override = "event.ingested"
 81type = "query"
 82
 83query = '''
 84event.dataset : "kubernetes.audit_logs"
 85  and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
 86  and kubernetes.audit.objectRef.resource:"services"
 87  and kubernetes.audit.verb:("create" or "update" or "patch")
 88  and kubernetes.audit.requestObject.spec.type:"NodePort"
 89'''
 90
 91
 92[[rule.threat]]
 93framework = "MITRE ATT&CK"
 94[[rule.threat.technique]]
 95id = "T1133"
 96name = "External Remote Services"
 97reference = "https://attack.mitre.org/techniques/T1133/"
 98
 99
100[rule.threat.tactic]
101id = "TA0003"
102name = "Persistence"
103reference = "https://attack.mitre.org/tactics/TA0003/"