本周初的时候，忽然发现部门服务器C盘动不动就满了，导致应用程序全都停止响应了。当时很是奇怪，C盘剩余的十几个G不应该在两天之内就被占满了呀。怀疑归怀疑，因为太忙，就没太管。
直到后来有一天，忽然发现服务器上的虚拟机无法启动了，一查原因居然是文件名被加上了“.id[3887BAE2-2921].[holylolly@airmail.cc].eking”的后缀。我试着把后缀去掉，再改回“.vdi”的格式，可发现改回来虚拟机依旧无法识别文件。因为之前有被虚拟机软件坑过的经历，所以以为又是虚拟机异常关闭造成文件被损坏了。除了有些小郁闷之外(又得重做一遍虚拟机系统、安装各种软件了)，倒也没多想。先放放再说吧，等爷哪天有空了再说。
于是又过了两天，忽然发现服务器上很多文件后缀名都被加上了诸如“.[holylolly@airmail.cc].eking”的后缀。
我试着把原本是txt格式的文件的后缀再改回.txt，发现文件内容依旧是乱码。直觉告诉我，事情没有想象的那么简单了。于是赶紧导出svn服务器里的各种资料文件。还好，svn服务器还能正常使用。就在导出的同时，我发现电脑中所有的exe、bat等可执行文件全部被改名了，还有txt、xml等文件，以及大部分的jpg等图片文件也全部被改名了。而正在运行的可执行程序，也纷纷地停止服务……在这一刻，我直觉得两眼一黑，感觉世界末日都要来临了！就好像三体快到结尾处太阳系被二向箔一点点吞没般恐怖！
幸好，svn服务器上的资料没用太长时间就全部备出来了。为了防止病毒将svn的备份文件也破坏掉，我赶紧把后缀改为黑客们不感兴趣的名字了。为了防止USB接口给备份用的移动硬盘带毒，我特意通过网络共享的方式将备份出的文件拷贝到本机了。
然而，就在我备份完毕后的五分钟之后，svn server也应声倒地，svn server可执行程序所在的文件夹变成了这幅惨状：
真是苍天有眼，谢天谢地！
于是，我赶紧百度，发现原来部门的服务器被勒索了！凭借早年我当“红客”积累的些许经验，我准确的找到了病毒的老巢：
更没想到的是病毒居然是用一个普通权限的账户启动的！瞬间刷新了我的三观！于是果断删掉了病毒。
我们的团队太小，肯定支付不起巨额的赎金，无奈之下只好重做了系统。为了在有生之年能等到解密程序出炉，我没舍得直接格盘。为了防止盘里带毒进而影响到新装的系统，干脆把原来的所有硬盘全卸下来了，买了块新盘搭上了，还把操作系统换成了windows Server 2016。
之前网上一直传说Win7不再升级了，所以安全性不再有保证了。我对这个一直不懈。个人感觉Win7比起之前的XP系统安全性不知提升了多少个层级，所以即便不再更新，也不应该会有多大问题的。更何况还有杀毒软件在保驾护航那。自以为可以高枕无忧了。没想到会栽倒在一个Win7普通用户的权限这里！
当把服务器的操作系统换成了Windows Server 2016后，我果断创建了一个只能执行一般权限，并只对个别目录有读取权限的账户，还安装了小红伞杀毒软件。还把svn备份文件顺利还原了，这颗悬着的心才稍微放下来点儿。
于是这才开始重新安装虚拟机。因为Windows Server 2016有了自带的Hyper-V，微软自家的东西，估计兼容性要比其他虚拟机软件强很多。我便不再尝试之前一直在用的VB和VM了。
第一次用Hyper-V，感觉还可以吧，除了需要配置一个虚拟网络才能让虚拟机联网外，其他概念并没有太大的区别。于是开始安装Ubuntu虚拟机，紧接着又装了ssh-server和Docker，并将原来的各种容器一一恢复。总算可以长舒一口气了！
今早想起另一台数据库服务器也还裸着，就来公司计划给数据库服务器也装一下小红伞。刚到公司，说看看昨天新装的应用服务器的运行状况吧，看了下，运行良好，只是CPU利用率维持在100%左右。职业习惯促使我看了下是哪个程序占用这么高，发现是昨天新装的Ubuntu虚拟机。还好，主机本身是没问题的。于是就开始给数据库服务器安装小红伞。
过了一会儿，我又登录进了应用服务器，发现CPU的利用率还维持在100%。这就奇怪了，这会儿就一个同事在用，而且只是请求一个简单的http，不应该导致虚拟机的CPU利用率飙到这么高呀。
于是我进到Ubuntu里看了下，发现有个名叫kdevtmpfsi的进程导致虚拟机的CPU利用率占满了。因为我对linux不是很熟悉，再加上这个账户是以root身份启动的，我怕是什么系统服务，就没太在意。
过了一会儿，我越想越觉得事有蹊跷，那就看看这个程序的路径吧，发现是在/tmp下，那就不是什么重要的程序了，于是果断将其终止。
然而不到两秒钟，它又来了！我试着再次将其终止后又对可执行程序进行了重命名，发现它又回来了！于是赶紧百度，发现我才装了不到12个小时的新虚拟机竟被当做挖矿机了！
真是命运多舛！我只好重新再来一遍了！
不行！身为一个没落的“红客”，我怎么能受这样的窝囊气哪？于是我赶紧将root的ssh登录权限给去掉了，并将工作用户的密码设为了复杂密码。这下/tmp目录下再也没有矿机了！CPU利用率也终于稳定在到1%左右了。
然而这还没结束，一个小时之后，当我无意中说再看下CPU的利用率吧，竟然又飙到100%了！这次居然是以当前登录的普通用户运行的挖矿程序，还是在/tmp下创建的同名程序。好吧，非得逼爷爷我动粗！
于是，我首先将矿机程序清除，然后创建了一个与矿机程序同名的文件夹，并将其读写及可执行权限全部从当前用户移除了。这里我用到了一个操作系统的一个小技巧——当创建一个文件时，如果有同名的文件夹存在，那么这个文件就无法创建成功。就这样，我成功的把矿机的下脚处给占了，矿机也就无处显形了。
在持续观察了五个多小时后，到目前为止挖矿机再也没启动，应该是没有问题了。
总结一下自己的惨痛“经历”，奉劝大家遵守如下最起码的安全规程：
第一、 机器的密码一定不能设置的太简单
第二、 一定要给机器安装靠谱的杀毒软件，推荐卡巴斯基、小红伞等百年软件
第三、 除非特殊情况下，否则一定不要使用超级管理员账户来工作或操作，最好将超级管理员账户禁用或改名
第四、 工作用户的权限一定要进行严格的限定，防止对系统关键文件产生破坏
最近病毒和木马肆虐，再加上中美贸易战的影响，很多机房都被美国黑客给攻击了。所以请大家做好防护。
希望自己上述的经历能给大家带来一点启发和帮助。
京公网安备 11010802035086号