阿里云一台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二个版本。升级后，代码访问正常。