Kubernetes环境下的DNS应急响应指南<\/h1>

背景与概述<\/h2>
容器化架构的普及使得攻击面增大，传统安全方法在Kubernetes动态环境中存在局限性。本文将以Docker作为基础，逐步过渡到Kubernetes业务环境下的应急响应，特别是针对DNS恶意请求的排查方法。<\/p>

Docker网络基础<\/h2>

Docker网络模式<\/h3>

Docker有四种网络模式，通过启动容器时指定：<\/p>

网络模式<\/th> 参数<\/th> 说明<\/th> <\/tr> <\/thead>

Bridge<\/td> --net=bridge<\/code><\/td> 默认模式，通过-p<\/code>指定端口映射<\/td> <\/tr>

None<\/td> --net=none<\/code><\/td> 容器有独立Network namespace但无网络设置<\/td> <\/tr>

Host<\/td> --net=host<\/code><\/td> 容器和宿主机共享Network namespace<\/td> <\/tr>

Container<\/td>

--net={id}<\/code><\/td>

容器和另一个容器共享Network namespace<\/td> <\/tr> <\/tbody> <\/table>

Kubernetes中的Pod就是多个容器共享一个Network namespace的实现。<\/p>

Network Namespace<\/h3>

Network namespace(网络命名空间)<\/strong>是Linux内核提供的一种网络隔离机制，它允许在同一台主机上创建多个独立的网络栈。<\/p>

关键特性<\/strong>：<\/p>

独立的网络栈：每个都有自己独立的网络接口、IP地址、路由表等<\/li>
进程级隔离：进程只能访问所在Network namespace的网络资源<\/li>
轻量级实现：仅依赖Linux内核特性，比传统虚拟机更轻量<\/li> <\/ul>
Cgroups<\/h3>
Cgroups(Control Groups)是Linux内核提供的资源管理机制，允许限制、隔离和监控一组进程对系统资源的使用。它是Docker容器、Kubernetes资源管理的核心技术之一。<\/p>
各网络模式详解<\/h3>
Bridge模式<\/h4>

Docker会在主机上创建名为docker0<\/code>的虚拟网桥<\/li>
每个容器都有虚拟网卡eth0<\/code><\/li>
容器间可以通过172.17.x.x<\/code>相互通信<\/li>
逻辑上与VMware Workstation的桥接模式类似<\/li> <\/ul> None模式<\/h4> 容器只有lo<\/code>回环网络，没有其他网卡<\/li> 无法联网，外部也无法访问<\/li> 封闭的网络能很好保证容器安全性<\/li> <\/ul> Host模式<\/h4> 容器与主机共享网络<\/li> 映射端口可能会产生冲突<\/li> 文件系统、进程等依然是隔离的<\/li> <\/ul> Container模式<\/h4> 多个容器之间共享网络<\/li> 首先启动一个bridge网络的容器A<\/li> 其他容器使用--net={id}<\/code>连接到A中<\/li> <\/ul> Kubernetes核心概念<\/h2> Pod<\/h3> 将多个容器打包一起运行的执行单元<\/li> 通过Docker的container模式实现容器间网络共享<\/li> 是Kubernetes集群中最小的执行单位<\/li> 所有容器共享相同的资源和本地网络<\/li> <\/ul> Pod与docker-compose的对比：<\/p> 特性<\/th> docker-compose<\/th> Kubernetes Pod<\/th> <\/tr> <\/thead> 作用范围<\/td> 一组独立容器组成应用<\/td> 最小单位，内部容器紧密协作<\/td> <\/tr> 网络<\/td> 通过networks实现连接<\/td> 共享同一IP，localhost直接通信<\/td> <\/tr> 存储<\/td> volumes定义<\/td> emptyDir、PersistentVolume<\/td> <\/tr> 运行环境<\/td> 容器各自运行<\/td> 由Kubernetes管理<\/td> <\/tr> 扩展<\/td> 手动scale<\/td> 自动扩展(HPA、Replicas)<\/td> <\/tr> <\/tbody> <\/table> Node<\/h3> Kubernetes中最小的计算硬件单元<\/li> 可以是物理服务器或虚拟机<\/li> 每个节点运行kubelet组件<\/li> 分为master节点和worker节点<\/li> <\/ul> Kubernetes架构组件<\/h3> API Server：集群核心，所有操作必经<\/li> Worker节点：运行Pod，使用kube-proxy处理网络通信<\/li> kubectl：命令行管理工具<\/li> proxy组件：确保集群内部服务流量正常转发<\/li> <\/ul> 环境部署<\/h2> Minikube<\/h3> Kubernetes的轻量级实现<\/li> 提供本地开发和测试环境<\/li> 在单一节点上运行完整Kubernetes集群<\/li> <\/ul> 部署步骤：<\/p> 启动minikube<\/li> 通过kubectl get nodes<\/code>验证部署<\/li> 编写deployment.yaml和service.yaml<\/li> 创建Deployment和Service<\/li> 查看Pod和Service状态<\/li> <\/ol> DNS应急响应场景<\/h2> 场景描述<\/strong>： Kubernetes集群触发主机安全告警，显示某台主机尝试解析并访问已知恶意域名。排查发现被标记的主机实际承担了集群DNS解析功能(CoreDNS)，而非真正恶意流量发起者。<\/p> 方法一：开启CoreDNS日志<\/h3> CoreDNS介绍<\/h4> Kubernetes默认DNS解析组件<\/li> 解析Kubernetes服务和Pod的域名<\/li> 代理集群外部DNS请求<\/li> 提供负载均衡和缓存功能<\/li> <\/ul> CoreDNS架构<\/h4> 以Deployment形式运行<\/li> 通过Service(kube-dns)供集群内Pod使用<\/li> <\/ul> 解析流程<\/strong>：<\/p> Pod内部的resolv.conf指向kube-dns service<\/li> DNS查询请求发送到CoreDNS<\/li> CoreDNS判断内部\/外部域名<\/li> 返回解析结果至请求Pod<\/li> <\/ol> 开启日志配置<\/h4> kubectl edit configmap coredns -n kube-system <\/span><\/span><\/code><\/pre>添加log<\/code>指令后，Kubernetes会自动重启CoreDNS<\/p> 排查步骤<\/h4> 在Pod中发起对恶意域名的请求<\/li> 查看CoreDNS日志定位Pod IP<\/li> 通过IP过滤定位对应Pod<\/li> <\/ol> 方法二：使用nsenter抓包<\/h3> 适用于：<\/p> 业务流量庞大的场景<\/li> 容器缺少网络调试工具的情况<\/li> <\/ul> nsenter介绍<\/h4> Linux命令行工具，用于进入另一个Namespace<\/li> 可以进入任何类型的Linux Namespace<\/li> <\/ul> 常用参数：<\/p> 参数<\/th> 解释<\/th> <\/tr> <\/thead> -n<\/td> 网络(Network Namespace)<\/td> <\/tr> -p<\/td> 进程(PID Namespace)<\/td> <\/tr> -m<\/td> 挂载(Mount Namespace)<\/td> <\/tr> -u<\/td> UTS(主机名和域名Namespace)<\/td> <\/tr> -i<\/td> IPC(进程间通信Namespace)<\/td> <\/tr> -c<\/td> Cgroup(控制组Namespace)<\/td> <\/tr> -U<\/td> 用户(User Namespace)<\/td> <\/tr> <\/tbody> <\/table> 排查步骤<\/h4> 在Pod宿主机(Node)上进入CoreDNS的namespace<\/li> <\/ol> nsenter -t <PID> -n bash <\/span><\/span><\/code><\/pre> 使用tcpdump抓取53端口流量<\/li> 同时在Pod向恶意域名发起请求<\/li> 通过流量分析定位IP和Pod<\/li> <\/ol> 总结<\/h2> 在Kubernetes环境下进行DNS应急响应时：<\/p> 理解Docker和Kubernetes的网络基础是关键<\/li> CoreDNS是集群DNS解析的核心组件<\/li> 两种主要排查方法：开启CoreDNS日志（适合流量不大的场景）<\/li> 使用nsenter抓包（适合生产环境）<\/li> <\/ul> <\/li> 掌握这些技术可以快速定位恶意请求来源Pod<\/li> <\/ol> 通过本文介绍的方法，可以有效应对Kubernetes环境下的DNS安全事件，提高集群安全性。<\/p>

Kubernetes环境下的DNS应急响应指南<\/h1>

背景与概述<\/h2> 容器化架构的普及使得攻击面增大，传统安全方法在Kubernetes动态环境中存在局限性。本文将以Docker作为基础，逐步过渡到Kubernetes业务环境下的应急响应，特别是针对DNS恶意请求的排查方法。<\/p>

Docker网络基础<\/h2>

Cgroups<\/h3> Cgroups(Control Groups)是Linux内核提供的资源管理机制，允许限制、隔离和监控一组进程对系统资源的使用。它是Docker容器、Kubernetes资源管理的核心技术之一。<\/p>

各网络模式详解<\/h3>

Kubernetes核心概念<\/h2>

环境部署<\/h2>

DNS应急响应场景<\/h2> 场景描述<\/strong>： Kubernetes集群触发主机安全告警，显示某台主机尝试解析并访问已知恶意域名。排查发现被标记的主机实际承担了集群DNS解析功能(CoreDNS)，而非真正恶意流量发起者。<\/p>

背景与概述<\/h2>
容器化架构的普及使得攻击面增大，传统安全方法在Kubernetes动态环境中存在局限性。本文将以Docker作为基础，逐步过渡到Kubernetes业务环境下的应急响应，特别是针对DNS恶意请求的排查方法。<\/p>

Cgroups<\/h3>
Cgroups(Control Groups)是Linux内核提供的资源管理机制，允许限制、隔离和监控一组进程对系统资源的使用。它是Docker容器、Kubernetes资源管理的核心技术之一。<\/p>

DNS应急响应场景<\/h2>
场景描述<\/strong>：
Kubernetes集群触发主机安全告警，显示某台主机尝试解析并访问已知恶意域名。排查发现被标记的主机实际承担了集群DNS解析功能(CoreDNS)，而非真正恶意流量发起者。<\/p>