最新消息:欢迎您,亲爱的读者!您可以通过QQ号或新浪、腾信微博账号直接在评论处登录,发表评论并选择转发到微博、QQ空间。

2018年的第一场战斗:一场突如其来的病毒遭遇战

案例研究 HIT金子 22796浏览 评论

来源:HIT专家网    作者:江西省妇幼保健院  金忠林

ai(图片来源:http://www.healthcareitnews.com)

南昌的冬天,难得会下雪。1月24日早上,天空下起小雨,预报说夜间会有雨夹雪,2018年的第一场雪,让这个南方湿冷的冬天有些期待。

遭遇勒索病毒

这几天HIS数据库时有异常,每到9-10点高峰期服务器CPU使用率就持续100%,排查了几天,一直没有找到症结。早上一上班,熊工就赶来帮忙,准备仔细排查HIS的外围接口。熊工是个有着18年数据库运维经验的专家,以前供职于我们的维保单位,近期离职,这次算友情帮忙。

8:40左右,门诊反应分诊叫号系统用不了。登录数据库服务器一看——CPU持续100%。一般业务高峰在9点半之后,今天来得有点早。熊工查看用户资源消耗,发现还是电子病历接口的数据库用户开销最大,通过后结束进程的方式试图缓解,效果不明显。一种不祥之兆,如同清晨扑面的寒风,钻衣入领。

近10:00,服务器CPU还是持续100%,多方电话反映系统运行缓慢,电子病历、移动护理、分诊叫号、手术麻醉等系统直接卡死,查来查去还是数据库死锁。

11:10,收到手术室主任发来的一张报错照片,报:“ORA-00604:error occurred resursive SQL lecel 1;ORA-20313,你的数据库已被SQL RUSH Team锁死,发送5个比特币到这个地址……”这是一个让无数信息工程师胆寒的信号——勒索病毒,一场突如其来的病毒遭遇战就此开始。

排查原因

分管院长已经来到科里了解情况,我们简要汇报之后,立即开始应对。首先是请求安全公司专业支持,然后关闭电子病历等系统以减轻HIS数据库压力,多方寻求解决方案。期间按照要求向委信息中心口头汇报。半个小时后,专业病毒响应工程师陆续到场。

13:30,根据网上相似案例判断,我们感染了 Ransom_RUSHQL.A 勒索病毒。这个病毒通过修改PL/SQL Developer工具的脚本文件AfterConnect.sql,注入恶意代码,当PL/SQL Developer连接数据库后会创建多个存储过程和触发器,循环执行创建大量Job,消耗数据库资源。根据存储过程的创建时间,推测中毒时间为上午9:46:16,4个多小时过去了,已经产生了230多万条dba_job记录,数据库CPU使用率持续100%。

接下来的任务,首先是检查所有Oracle数据库。通过检查,发现只有HIS相关的数据库被感染——HIS生产库和测试库。测试库中毒事件为23日16:57:21,此时已经创建了4700多万条Job。据此推测Job的创建速度,我们不禁又惊出一身冷汗:17个小时增加20倍的Job量,如果不能很快清除病毒,HIS数据库很可能被拖死。

根据中毒区域,我们重点排查HIS系统工程师的笔记本电脑,终于在一台电脑里发现了病毒样本,工程师说前天刚重装系统,同事发给他一个破解版的PL/SQL Developer。

化险为夷

原因找到了,如何解决又是一个棘手的问题。首先要保证数据不丢,其次要保证解决方案有效安全。分管院长坐镇指挥:一是对测试库进行病毒反向操作,验证解决方案;二是下午6点下班后停HIS备份数据。必须要有一份完整的数据,必须要保证安全有效解决生产库的问题,必须要保证明早7点半正常开业。

17:00,收费处已经领取了手工发票,急诊、药房、住院部都已做好手工操作的准备,测试库的处理也稳步进行。18:30,断开门诊、住院部等网络连接,开始备份数据库。按部就班,似乎成功就在眼前。

再次研读解密的病毒脚本,发现有一段删除数据的代码,稍安的心又吊了起来。赶紧和HIS工程师一起分析,好在没有业务数据表,删表的存储过程因为数据库版本不同也没有创建。不幸中的万幸。

20:00,因为CPU持续占用,生产库数据导出缓慢。测试库的操作验证也出现问题,此时5200多万个Job查询才完成1/10。数据没有备份出来,处理措施没有验证,生产库的异常Job还在不停地循环创建,已经有500多万条。时间一分一秒地过去,所有人在等待中煎熬。

1月25日凌晨1:00,办公室的空调停机化霜,窗外漆黑的夜空已在飘落雪花,寒气袭人。

等待生产库完全导出,时间已经不允许,决定直接恢复DG数据。拉起DG之后,发现少了几十张表,数据不一致,可能是归档日志不完整。熊工开始用RMAN做基于SCN的差异增量备份追平数据。

2:30,测试库的处理完毕,数据库重启后正常,没有发现数据丢失。但是风险依然存在,生产库与测试库环境有差异,细微的变化都可能导致操作失败,甚至数据丢失。全部的希望都寄托在DG能够追平数据,时间在敲击键盘的指尖溜走。DG服务器I/O不高,备份花费了很长时间,期间出现过“文件头部SCN不一致”等问题,恢复不成功,好在熊工一一解决。

5:30,峰回路转,DG数据恢复完成,对比生产库,数据没有丢失。此时距离开诊只有两个小时,冒险在生产库操作的念头不时挑动我们的神经,数据安全是我们始终坚持的信念。

有数据在,一切都在。

立即开始生产库的操作。大家熬了一天一宿,此时却无比振奋。接下来的一切非常顺利,在测试库处理的同时,我们已经删除了生产库的恶意存储过程,查询导出了异常Job,编辑好了删除的脚本。

7:00,生产库Job删除完成;重启数据库,CPU的曲线终于回落;对比DG备份数据,数据没有丢;陆续开启电子病历、移动护理等服务,服务器CUP使用率正常。7:21,我们发出OA公告:经过一昼夜的紧急处理,医院信息系统将于7:30恢复使用,感谢同事们的理解与配合。

窗外,上班的人群脚步匆匆,依旧寒风细雨,已经没有了雪。

【责任编辑:谭啸】

 

您必须 登录 才能发表评论!