记一次 Confluence 被攻击事件

本文记录了一次Confluence服务器频繁出现502错误的故障排查过程,涉及资源不足、恶意进程、定时任务、DNS解析及软件漏洞等多方面问题,最终通过升级widgetconnector组件和调整系统配置解决了稳定性问题。

故事开始

 

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 700 /usr/bin/wget
chmod 700 /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 <1214966109@qq.com>
# 日期:2019-04-15
# 作用:Confluence 状态检测
#################################################################

#################################################################
# Confluence 状态检查
#################################################################
SERVICE_STATUS=$(ps aux | grep "/opt/atlassian/confluence/confluence-6.9" | grep -v grep | wc -l)
if [[ ${SERVICE_STATUS} -ne 2 ]]; 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 天,在发现问题上面会走很多弯路。所以希望能够帮到有心人。

转载于:https://www.cnblogs.com/Dy1an/p/10724838.html

<think>嗯,用户让我生成一个代码审查的流程。首先,我需要确认代码审查的基本步骤,然后考虑如何结构化这些步骤,让用户容易理解和应用。代码审查的流程通常包括准备、执行、反馈和跟进几个阶段,但具体细节可能因团队而异。 首先,用户可能需要一个清晰的步骤指南。我应该从审查前的准备工作开始,比如确保代码符合基本要求和文档是否齐全。然后进入正式审查阶段,可能需要使用工具或者会议形式。接下来是问题录和分类,区分严重程度,比如阻塞性问题、建议等。沟通反馈环节也很重要,要强调建设性的沟通方式。然后是迭代修改和最终确认,确保问题都解决了。最后,可能还需要后续的复盘和流程优化。 需要考虑用户可能不太清楚每个步骤的具体内容,所以每个步骤需要详细说明,例如在准备阶段,需要检查编译通过、单元测试、文档更新等。同时,要提醒使用代码审查工具,比如GitHub的PR或者Gerrit,这能帮助实际操作。 另外,用户可能希望流程既适用于个人也适用于团队,所以需要区分个人自查和团队审查的不同点。比如,个人先做静态检查,团队审查可能用会议或异步方式。 可能还需要注意事项,比如沟通态度,避免人身攻击,保持高效会议时间,录问题以便后续跟踪。这些都能帮助用户避免常见问题,提升审查效率。 需要确保回答结构清晰,分步骤说明,每个步骤有子项或示例。例如,在问题分类时,用列表形式说明严重、建议、讨论点,这样用户容易理解优先级。同时,使用代码审查工具的例子,让用户知道如何具体操作。 最后,检查流程是否符合用户的需求,是否覆盖了从准备到复盘的整个周期,是否具备可操作性和实用性。还要确保用中文表达准确,术语正确,比如“阻塞性问题”这样的表述是否合适。可能需要调整用词,让非技术用户也能明白。 总结下来,整个流程应该分七个步骤,从准备到复盘,每个步骤详细展开,注意事项部分强调沟通和效率。这样用户能有一个全面的指导,实施代码审查时更有条理。</think>以下是一个结构清晰的代码审查流程,分为7个核心步骤,包含注意事项和工具建议: 一、审查前准备 1. 提交者准备 - 确保代码编译通过 - 完成单元测试(覆盖率建议>80%) - 更新/补充相关文档(如API文档、README) - 使用静态检查工具(如ESLint、Pylint) 2. 创建审查请求 - 通过平台提交(GitHub PR/GitLab MR/Gerrit等) - 包含必要信息: $$ \text{变更目的} = \text{需求编号} + \text{修改背景} $$ $$ \text{影响范围} = \text{模块列表} + \text{数据库变更} $$ 二、正式审查阶段 1. 初步筛选(负责人操作) - 检查基础规范: ```python if (命名规范 and 格式统一 and 无调试代码): 分配审查人员 else: 退回修改 ``` 2. 深度审查(建议2-3人参与) - 重点检查项: ▫️ 业务逻辑正确性 ▫️ 边界条件处理 ▫️ 安全漏洞(如SQL注入) ▫️ 性能瓶颈(时间复杂度评估) ▫️ 可测试性(是否包含Mock接口) 三、问题录与分类 使用标系统区分问题等级: ```markdown [严重] 导致系统崩溃的逻辑错误 [建议] 可选的优化方案 [讨论] 需要团队共识的设计决策 ``` 四、沟通反馈 1. 异步沟通(推荐) - 在PR评论中@相关人员 - 使用代码片段引用: ```java // 待优化处 public void process() { // 建议添加缓存机制 ← [建议][性能] } ``` 2. 同步会议(适用于复杂修改) - 控制时长(建议<60分钟) - 提前24小时发送会议议程 五、迭代修改 1. 修改策略: - 紧急问题:立即修复 - 争议问题:创建新的issue跟踪 - 架构问题:发起设计评审 六、最终确认 通过检查清单验证: $$ \sum_{i=1}^{n}(问题是否解决) = 0 $$ $$ \exists 回归测试报告 $$ 七、后续跟进 1. 合并后监控 - 观察CI/CD流水线状态 - 录生产环境异常日志 2. 复盘优化 - 每月统计审查指标: $$ \text{问题密度} = \frac{\text{发现问题数}}{\text{代码行数}} $$ $$ \text{平均周转时间} = \frac{\sum \text{审查耗时}}{\text{PR总数}} $$ 注意事项: 1. 沟通准则: - 使用"建议采用..."替代"你这样写不对" - 对事不对人,避免出现"你总是..." 2. 效率控制: - 单次审查代码量建议 < 400行 - 复杂模块实施分阶段审查 工具推荐: - 自动化工具:SonarQube, Crucible - 协作平台:GitHub Code Owners, Phabricator - 知识沉淀:Confluence审查案例库 这个流程可根据团队规模调整,小型团队可简化文档步骤,金融/医疗等强合规领域建议增加审计跟踪环节。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值