应急响应-主机安全告警K8s恶意DNS请求排查

应急响应-主机安全告警K8s恶意DNS请求排查

单机场景下的恶意dns请求排查

k8s集群中某台主机请求恶意域名触发主机安全告警,但是排查发现被告警的是负责集群dns解析的主机,并发真正发起恶意请求的主机/容器。这类场景下如何才能快速排查出存在漏洞的业务或服务?

k8s场景下如何应急响应?
k8s场景下的恶意dns请求排查

k8s使用coreDNS或者kube-dns来作为集群内部的dns解析服务,这类云原生场景下的恶意请求排查会相对麻烦些,所有业务都是容器化部署,并且k8s中dns服务默认未开启日志。

思路一:开启coreDNS解析日志

找到coredns所在的容器。

kubectl get pods -A -o wide | grep dns

默认coredns未开启日志,执行logs命令没有解析记录。注意:执行命令要带上 -n kube-system (命名空间)

修改coredns配置文件加入log。

kubectl edit configmap coredns -n kube-system
coredns默认配置
加入log,不添加配置会有默认规则

修改配置coredns会自动重启。

注意开启日志可能的影响:

  • 重启coredns可能短暂影响集群域名解析
  • 域名解析量大,开启日志可能会影响到服务性能

测试域名解析来自哪个pod?

我们在开启日志后,使用另一个容器发起dns请求,可以看到对应的容器ip。

思路二:tcpdump抓包

在coredns的宿主机上抓53端口的流量。但需要结合恶意请求的告警定位到准确时间的报文信息。

但是k8s场景下,容器内部很多命令都是没有。这个时候就需要用到nsenter进行到容器内部的网络空间进行抓包。一个比较典型的用途就是进入容器的网络命名空间。通常容器为了轻量级,大多都是不包含较为基础网络管理调试工具,比如:ip、ping、telnet、ss、tcpdump 等命令,给调试容器内网络带来相当大的困扰。

nsenter 安装

nsenter 位于 util-linux 包中,一般常用的 Linux 发行版都已经默认安装。如果你的系统没有安装,可以使用以下命令进行安装:

 yum install util-linux -y

nsenter 进入容器网络空间

nsenter -t <PID> -n bash
tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

在正常情况下,抓包对业务无影响,仅会增加小部分的CPU负载和磁盘写入。该命令会对抓取到的包进行rotate,最多可以写200个20 MB的.pcap文件。

但是上面的命令将包内容输出到了文件,无法在标准输出上看到记录。不想要完整的数据包,可以用下面的命令。

tcpdump -i any port 53 -vvv | tee -a /tmp/dns.log

此时也能捕获到coredns内部的域名请求ip。

Print Friendly, PDF & Email
赞赏

微信赞赏支付宝赞赏

Zgao

愿有一日,安全圈的师傅们都能用上Zgao写的工具。