记一次 Confluence 被攻击事件

故事开始

4 月 14 日，星期天，天气不好，呆在家玩 LOL，正 Happy 的时候同事打电话给我，说 Confluence 看文档的时候挂了，报错：502。

一寻思，不就挂了吗，小意思，重启呗，于是切出游戏，远程上服务器重服务后继续玩游戏。

结果没几分钟，又发消息过来，Confluence 再次挂掉。我 X，这就有点 B 了狗了。

故障排除

故障发生之时的第一感觉就是 Confluence 资源不够？但仔细一想，也没有两个人在使用啊。于是查看了一下进程：

Confluence 本该只有两个进程运行，现在只剩下一个本身的，而 Confluence 的用户却运行了一堆乱七八糟的进程。

使用 top 命令查看系统资源占用：

有一个进程巨特么占用 CPU，但是 COMMAND 却没有。通过 PID 可以看出，这个进程就是之前的 /boot/vmlinuz

网上去搜索相关进程的信息，说什么内核进程。当时想，难道内核出 BUG 了？这可咋整，不会需要升级内核吧。

出于懒，先将应用启动起来，让别人先用着吧。可就在这时，神奇的一幕发生了，我 X，服务居然启动不起来了。

再次通过 ps 查看进程，发现又出现了一些奇怪的进程正在执行：

一个 curl 一个 wget，而特么的操作都是去一个 51 的 IP 下载文件，百度这个 IP:

眉头一皱，渐渐的意识到这件事情并不这么简单，这是在搞事情啊。

出于本能，第一步要做的事情，就是找出这些文件，先删除，并且不让他再去下载。

于是我将 curl 和 wget 改为只有 root 用户能够使用。

chmod  /usr/bin/wget
chmod  /usr/bin/curl

然后便是查定时任务，因为之前有过被攻击的经验，这些 B 都喜欢在你机器上面添加定时任务。

su - confluence
crontab -l

果然，在定时任务里面有一条 curl 操作，每隔 5 分钟搞一次，还用了 base64 编码。

把这些都删除，顺便去下载了那个脚本，发现他在 /tmp 目录下存放了很多文件，直接全部给他先删除。

然后满心欢喜的启动 Confluence。成功跑起来了。心里还有点小得意。

本以为故事到这里就应该告一段落了，然鹅，这才刚刚开始。

在接下来的一天里，Confluence 一直处于不稳定状态，时不时就挂掉。有时十几分钟，有时半个小时，问题来了，会不会是这台机器的原因？

那还能咋整，迁移呗。于是在一台新的机器上重启部署好服务，将数据重新导入，一且顺顺利利。但没过多久，服务器再度出现上面的症状。

这时心里一万头草泥马奔涌而过。用之前的方法处理，但又一个新的问题诞生了。同时，一个新的域名出现在了我的世界。

pastebin.com

经过一番了解，这是一个可以用户匿名发布纯文本的网站，发布完成以后，文件可以生成一个链接~~~~

于是，接下来的战斗都围绕着类似于这样的地址做斗争：

https://pastebin.com/raw/B5BTS5fm

打开网站，将文件里面 base64 部分解密：

而最终斗争方法包括但不限于修改 curl，wget 权限，修改 DNS 解析等等等等。

127.0.0.1   pastebin.com

结果一番折腾，并没有什么卵用，Confluence 还是隔一段时间就挂掉。为此还专门写了个定时任务让他检测重启。

#!/bin/bash

#################################################################
# 作者：Dylan <@qq.com>
# 日期：--
# 作用：Confluence 状态检测
#################################################################

#################################################################
# Confluence 状态检查
#################################################################
SERVICE_STATUS=$(ps aux | grep "/opt/atlassian/confluence/confluence-6.9" | grep -v grep | wc -l)
if [[ ${SERVICE_STATUS} -ne  ]]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') confluence is not running!\n" >>/tmp/confluence_restart.log
    echo "$(date '+%Y-%m-%d %H:%M:%S') confluence restart!\n" >>/tmp/confluence_restart.log
    /etc/init.d/confluence restart &
fi

日志里面似乎也没啥实质性的东西。全是类似于以下错误，这说明是从程序内部发起的，这可咋整：

org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'https://pastebin.com/raw/B5BTS5fm'
.........................
java.lang.RuntimeException: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe
.........................

我把这些地址都让他不能使用了，总不会出乱子吧，不能访问就不能访问呗。

再后来，通过 JAVA 同事点醒，说的是这样的请求失败会造成程序阻塞。我 X，难道这就是方向了？

于是百度关键词，最终在两篇文章中看到了类似的问题。

一篇是漏洞说明：

https://yq.aliyun.com/articles/698490

一篇是问题解决：

https://yq.aliyun.com/articles/698056

最终办法

widgetconnector-xxx.jar 3.1.4 之前的版本存在该漏洞，所以我们可以换成官网新的：

https://packages.atlassian.com/maven-public/com/atlassian/confluence/extra/widgetconnector/widgetconnector/3.1.4/widgetconnector-3.1.4.jar

删除旧版本的 jar 包，换成新版本，具体目录：

confluence安装目录/confluence/WEB-INF/atlassian-bundled-plugins/

然后重启 confluence，为了更安全，我们可以配合之前的修改 curl 和 wget 权限，修改 DNS 解析使用。

事件小结

这一次故障解决过程其实相当漫长 2- 3 天，在发现问题上面会走很多弯路。所以希望能够帮到有心人。