阿里云一臺ECS中招，中招原因可能為版本底，并且WEB界面允許外部訪問，因為我們有外部程序員需要上傳代碼。
受影響的版本：
現像：
CPU一直50%，很聰明！！！
查看進程，有一個GIT用戶運行的exe程序持續占有50%的CPU，程序結束后會馬上自動拉起。
處理過程：
切換到Gti用戶下，查看計劃任務：
計劃任務為空
/tmp/目錄下，沒有發現和阿里提示相同的文件夾。
通過lsof -p查看進程，發現境外連接地址，通過IPTABLES禁止訪問此地址后，會自動更換其它地址進行自動連接。
[root@~]# lsof -p 9119
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
exe 9119 git cwd DIR 253,1 4096 2 /
exe 9119 git rtd DIR 253,1 4096 2 /
exe 9119 git txt REG 253,1 1709100 1179650 /tmp/kami (deleted)
exe 9119 git 0r CHR 1,3 0t0 1028 /dev/null
exe 9119 git 1w CHR 1,3 0t0 1028 /dev/null
exe 9119 git 2w CHR 1,3 0t0 1028 /dev/null
exe 9119 git 3r CHR 1,3 0t0 1028 /dev/null
exe 9119 git 4u REG 253,1 4 1188868 /tmp/.x11-unix (deleted)
exe 9119 git 5u a_inode 0,10 0 6387 [eventpoll]
exe 9119 git 6r FIFO 0,9 0t0 1319801218 pipe
exe 9119 git 7w FIFO 0,9 0t0 1319801218 pipe
exe 9119 git 8r FIFO 0,9 0t0 1319801219 pipe
exe 9119 git 9w FIFO 0,9 0t0 1319801219 pipe
exe 9119 git 10u a_inode 0,10 0 6387 [eventfd]
exe 9119 git 11u a_inode 0,10 0 6387 [eventfd]
exe 9119 git 12u a_inode 0,10 0 6387 [eventfd]
exe 9119 git 13r CHR 1,3 0t0 1028 /dev/null
exe 9119 git 14u IPv4 1319801220 0t0 TCP nexus.****.com:48948->504e189a.host.njalla.NET:https (ESTABLISHED)
iptables -I OUTPUT -d 80.78.24.154 -j DROP
Chain OUTPUT (policy ACCEPT 108 packets, 114K bytes)
pkts bytes target prot opt in out source destination
6 372 DROP all -- * * 0.0.0.0/0 80.78.24.154
因為本人處理過一起類似的問題，所以知道系統里本身的默認命令應該是無法查看到此程序，使用busybox來可以很容易的清理，因為時間有限，我給大家一個小妙招，如果找到busybox,可以下載一個Docker鏡像，拉起來后，把busybox復制到本機，然后通過busybox進行病毒的清理工作，就易如反掌。
- 清空整個/tmp目錄
- 結束所有已經打上deleted標記的進程，通過busybox可以很容易的發現進程信息，阿里的提示是準確的，只不過系統被感染，所以不易查看到相關信息。
[root@ ~]# busybox lsof -p |grep 9459
9459 /tmp/kami (deleted) 0 /dev/null
9459 /tmp/kami (deleted) 1 /dev/null
9459 /tmp/kami (deleted) 2 /dev/null
9459 /tmp/kami (deleted) 3 /dev/null
9459 /tmp/kami (deleted) 4 /tmp/.x11-unix (deleted)
9459 /tmp/kami (deleted) 5 anon_inode:[eventpoll]
9459 /tmp/kami (deleted) 6 pipe:[1319802797]
9459 /tmp/kami (deleted) 7 pipe:[1319802797]
9459 /tmp/kami (deleted) 8 pipe:[1319802798]
9459 /tmp/kami (deleted) 9 pipe:[1319802798]
9459 /tmp/kami (deleted) 10 anon_inode:[eventfd]
9459 /tmp/kami (deleted) 11 anon_inode:[eventfd]
9459 /tmp/kami (deleted) 12 anon_inode:[eventfd]
9459 /tmp/kami (deleted) 13 /dev/null
9459 /tmp/kami (deleted) 14 socket:[1319806273]
9459 /tmp/kami (deleted) 15 socket:[1319803995]
至此，進程再也不會被拉起來。
接下來是升級工作。
- 備份
gitlab-rake gitlab:backup:create #自動備份代碼相關內容
手動備份下面文件
/etc/gitlab/gitlab.rb #配置文件須備份
/var/opt/gitlab/Nginx/conf #nginx配置文件
/etc/postfix/main.cfpostfix #郵件配置備份
/etc/gitlab/gitlab-secrets.json #存儲了gitlab的db secret信息
- 準備gitlab源，本機為centos7
[gitlab-ce]
name=gitlab-ce
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
repo_gpgcheck=0
gpgcheck=0
enable=1
gpgkey=https://packages.gitlab.com/gpg.key
- 停相關服務
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-ctl stop nginx
- yum安裝升級
yum install -y gitlab-10.8.7
yum install -y gitlab-11.3.4
- 啟動服務
gitlab-ctl restart
查看可升級的路線圖
8.11.Z -> 8.12.0 -> 8.17.7 -> 9.5.10 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15 -> 14.0.12 -> 14.3.6 -> 14.9.5 -> 14.10.Z -> 15.0.Z -> 15.4.0 -> latest 15.Y.Z
上圖為gitlab官網公司的升級路線圖。
因為時間關系，我司的Gitlab暫升級到11.3.4，其間升到了10.8.7和11.3.4二個版本。升級后，代碼訪問正常。
