首页 > 生活杂谈 > webshell木马攻坚战(非技术分析)

webshell木马攻坚战(非技术分析)

初见端倪

前几天客户告我说网站显示不对,我打开一看确实有点别扭,但又说不出哪里不对,但是超链接都死循环了,我琢磨了半天可能是nginx死掉了,某些css没加载出来 或CDN坏了,于是重启服务,可以还是老样子,客户补充了一句,还显示菠菜和堵厂(你懂得)之类的,我一下反应过来,这肯定是中招了。

第一招

我排除了是系统问题,就开始找木马,也不知道是我经验比较丰富,还是运气好,

在几百个目录中 竟然一下点到了木马所在的文件夹(事后想想还是自己太嫩了),还是蛮有成就感的。于是删掉文件,重启服务,系统恢复

再出招

第二天一上班,职业习惯的驱使下 ,结果发现网站又被篡改了,而且木马还是出现在相同的位置,这时候我才反应过来,这肯定不止有一个木马文件,于是开启了手动抓虫模式。

经过半天的找出了6个异常文件,也不确定是否有漏杀的,转念一想,我有svn版本控制啊!还能让它漏掉吗?于是彻底清空项目目录,管它有用的没用的统统删掉。然后svn更新版本库,项目瞬间满血复活,我也没想到SVN还有这个作用,接下来该想想到底是哪里出了问题

拆招

webshell文件下载到本地 开始艰难的破解之旅,当然最后根据某段特征搜到了破解办法,后门文件就是 gzinflate +base64_decode+正则+eval 混淆过的结果。本来这些非常好用的字符串处理函数, 是用来传递数据保证加密安全,没想到却被木马用来伪装自己,真是坑爹啊,更可气的是 这些后门的作者都在皮,先说自己是百度蜘蛛,自己的署名还是你的英雄。这就是赤裸裸的打脸加嘲讽啊。

webshell木马攻坚战(非技术分析) - 第1张  | 博客一个

 

刨根问底

问谁呢? 这时候就要问http服务的灵魂了 :日志

日志这东西,不出问题的时候就是垃圾文件占地方,出了问题只能靠它来救命。

于是开始下载日志进行分析,从1G多的日志文件里进行筛选,640万行日志把IDE都卡死了,平时不合理规划日志,现在要付出代价了。

搜索后门文件名称开始检索,最终还是顺利发现了 是因为路由没有严格过滤地址栏参数导致被导致注入,而我又没把框架框架升级到最新版本,根据日志查看该项目每天能被扫描上千次。

既然是框架漏洞,那说明其他服务器也不保了。

于是排查其他服务器,果然全军覆没。然后逐一排查,最后木马后门清除掉了,但是不知道是否留下了其他后门程序。扎心凉凉

痛定思痛

这可能是我入行以来,第一次被如此打击,其实这也是理所当然,之前我还会设置一些安全防护,可是几年一直都平安无事,后来干脆就裸奔了,更没有经常巡检的习惯,所以直到客户提出才发现。

更可怕的是公司某个车管交易业务的服务器也被入侵,幸好上面还没有部署隐私信息,否则后果不堪设想。

人啊就是这样,不吃亏永远不会记得痛。

我一直认为这些项目流量不大,有没有人知道这个项目都不好说,怎么会有人盯上呢,

图样啊自己就是搞开发的竟然忽略了计算机的力量,自己写爬虫的时候,单线程情况下半个小时 就足以把别人网站5年的内容全部抓取回来,如果多线程可能只需几分钟而已。

同理,工具按ip段或域名多线程扫描 ,扫大半个中国的服务器漏洞,可能半天也足够了

安全防护

 

  1. 对外暴露端口越少越好
  2. ssh mysql redis 等软件默认端口 必须修改
  3. 关闭软件的调试模式
  4. 严格控制 用户组权限 和 软件目录权限
  5. 上传文件务必过滤
  6. 开启强制路由,路由类似白名单机制

要明白 什么安全防护软件都不是一劳永逸的,因为先有病才有药,所以要从预防开始,假如当初启用了强制路由,本次就可以幸免于难了,

但是哪有什么如果,感谢这哥们给我上了生动的一课,让我明白网络安全的重要性。