暂无图片
暂无图片
2
暂无图片
暂无图片
暂无图片

SSH恶意程序引发的ORA-03113报错

原创 曾令军 2020-02-12
1213

今年的春节处于全民抗击疫情的特殊时期,IT运维工作者,同样面临不能出门办公的困境,很多公司都会选择开启远程运维办公。这种远程办公的模式,更需要注意网络安全和数据安全防护。以下这个案例就是在这种特殊时期,我们的客户遭遇的一次恶意程序攻击。

问题现象
应用程序运行过程中出现异常,报ORA-03113错误。进入sqlplus对大表进行查询模拟,可以重现。但是查询小表,没有问题。

select count(*) from sjhpt.GRMYCBJFQKNZN103856;
ORA-03113: end-of-file on communication channel

分析过程
既然问题可以重现,第一反应就是开启10046事件跟踪,观察报错发生的时间点:

alter session set events '10046 trace name context forever, level 12';
--------------
WAIT #139806815770144: nam='db file scattered read' ela= 5148 file#=67 block#=3949320 blocks=128 obj#=123676 tim=1581278521654537
WAIT #139806815770144: nam='gc cr multi block request' ela= 256 file#=67 block#=3949575 class#=1 obj#=123676 tim=1581278521657637
WAIT #139806815770144: nam='db file scattered read' ela= 4884 file#=67 block#=3949448 blocks=128 obj#=123676 tim=1581278521662798
WAIT #139806815770144: nam='gc cr multi block request' ela= 414 file#=67 block#=3949627 class#=1 obj#=123676 tim=1581278521666268
WAIT #139806815770144: nam='gc cr multi block request' ela= 632 file#=67 block#=3949691 class#=1 obj#=123676 tim=1581278521667563

日志中存在大量的多块读和gc一致性块请求,这些等待循环出现几万次,可以观察到读取的块号不断在发生变化,说明虽然有等待,但是sql还是在运行的。然后没有任何征兆,就结束了。
这是一套RAC环境,为了验证是否是gc等待引起的问题,接下来做了一个模拟测试,不通过gc,走直接路径读:

alter session set "_serial_direct_read"=always;
select count(*) from sjhpt.GRMYCBJFQKNZN103856;
 COUNT(1)
------------
 134391343  --设置dpr可正常查询

走本地服务器直接读取存储,可以成功,走GC报错。而且小表没问题(小表的全表扫也会走gc),大表才有问题。根据这些信息,推断会不会是节点间的数据交互方面的问题呢?于是找一个本地文件,用scp传到另一个节点,果然,scp的进程被异常中断了:

[oracle@rac1 tmp]$ scp test_cp.log2 rac2:/tmp
test_cp.log2  1%   74MB  73.8MB/s   01:00 ETA              
  lost connection

跟客户反映这个情况后,客户找到系统工程师检查系统配置和网络问题,没有发现任何异常。但他们在检查的时候有了新的发现,除了scp,在本机操作的cp、rm命令也会出现间歇性地时不时发生异常中断:

cp 123.log 456.log
killed   --本机拷贝较大文件时,命令执行过程中被kill
rm -rf *.log
killed   --命令执行过程中被kill

问题分析到这里,已经超出了数据库的范畴了,所以重点放在操作系统的配置排查上,各种测试,以及检查各个用户的ulimit、操作系统版本、crontab。最后在检查crontab的时候发现root用户下存在一个异常的脚本:

crontab -l
* * * * * /usr/games/ssh
--每秒执行一次,脚本内容如下:
#!/bin/bash
cd -- /usr/games/.ssh
mkdir -- .ssh
cp -f -- x86_64 .ssh/ssh
./.ssh/ssh -c
rm -rf .ssh

从脚本所在的位置、名字、执行频率以及内容可以看出,这是一个恶意程序,它会每秒执行一次变更ssh密码规格(ssh -c),在这个过程中,通过ssh连接的操作命令和进程可能会被kill掉(包括oracle进程在节点间传输数据时,也是通过ssh认证的)。最后再做了多次验证测试,确认就是这个脚本的影响。把这条crontab注释掉,问题排除。

看起来很简单的一个脚本,对数据库影响却很大。数据库运行环境的安全稳定至关重要,特殊时期不能做到很好的物理隔离,在远程用户连接和密码管理上要引起足够重视,其次就是做到规格更高的风险预警、健康检查和监控机制,风险早隔离,问题早发现,故障早处理。

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

文章被以下合辑收录

评论