Gatlab 10.4.6中挖矿病毒处理与升级过程记录
阿里云一台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二个版本。升级后，代码访问正常。
