风雪交加的日子遭遇勒索病毒，最终化险为夷。
其他
2018年的第一场战斗：一场突如其来的病毒遭遇战
（图片来源：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恢复使用，感谢同事们的理解与配合。
窗外，上班的人群脚步匆匆，依旧寒风细雨，已经没有了雪。
近期热门文章：【回顾展望】系列
HIT专家网∣最新鲜的医疗信息化资讯，不一样的专家视角
微信：HIT180com
投稿： public@hit180.com
商务合作：(010)82373062