应对“比特币勒索”经验分享

近期,比特币勒索攻击卷土重来,用户在登陆数据库时出现勒索警告信息,被要求上交比特币来换取解锁数据库的服务。这一般是由于用户下载了非官方的pl/sql软件(其中被植入了恶意代码)导致的,数据中心一旦“中招”,其表数据将遭受被删除,或者被加密,导致企业业务连续性受阻。 
2016年11月22日的深夜,天玑突然接到某客户的紧急求救电话:系统无法登陆,业务系统受到影响。我们登陆到服务器进行检查发现: 
图片描述
这两天网络上热炒的“比特币勒索”,一下子扑进了现实。病毒的实现原理这里就不详细说了,网上很多这样的帖子,已经写的很清楚。这里仅仅讲一下这个案例的简单处理过程,以及这次事件给我们带来的思考。 
处理过程当然首先是找出“比特币勒索”相关的触发器、存储过程以及后台JOB。 
4个存储过程如下: 
DBMS_SUPPORT_INTERNAL

DBMS_SYSTEM_INTERNAL

DBMS_STANDARD_FUN9

DBMS_CORE_INTERNAL 
三个触发器则是: 
数据库启动后触发器DBMS_SUPPORT_INTERNAL

数据库登陆触发器DBMS_SYSTEM_INTERNAL

DBMS_CORE_INTERNAL 
确认问题后,采取手段紧急进行处理。 
1. 发生故障时千万不要慌张的去着急重启数据库,”DBMS_SUPPORT_INTERNAL “通过“after startup on database”触发器触发; 
2. 禁用数据库监听(RAC环境下,监听会自动重启,为了安全起见禁用监听),”DBMS_SYSTEM_INTERNAL “和”DBMS_CORE_INTERNAL “分别通过数据库登录行为和应用登录行为触发; 
3. 杀掉所有的外部连接, 
4. 禁用病毒触发器; 
5. 设置数据库job_queue_processes参数设置为0,禁用所有JOB执行。这个案例中,病毒在数据库中创建了300多万个“TRUNCATE TABLE”JOB,一旦全部执行,后果不堪设想; 
6. 找出病毒存储过程和触发器将其彻低删除,删除病毒JOB; 
7. 删除了病毒程序后,重启数据库并已只读模式打开,尽量减少截断表的使用空间被其他对象覆盖的可能。 
经过一系列的处理后,躁动的系统安静了下来。我们开始进行系统受损程度的评估。 
这是客户的ERP系统,系统中大概10多个SCHEMA,中毒的是其中第二大用户。该用户共有近2T的数据,接近6000张表,被截断的表多达2800张。看到这个场景,即便是老司机如我们,也不由得瞠目结舌。 
专家组短暂的讨论后,开始寻求解决方案。 
摆在我们面前有两条路: 
 第一种是通过数据备份进行不完全恢复,将数据库恢复到故障前的正常时间点,但这个方案实施成功的难度非常大。通过抽样调查,2800多张表并不是同一个批次被截断,需要精确定位每张表的截断时间,并在恢复过程不断推进,按批次导出被截断的表。不论是恢复时间还是技术手段上,都难以保障数据及时有效的恢复; 
 第二是通过DUL等数据抽取软件,直接扫描数据文件,将扫描出的数据导入到数据库。这种方式恢复时间相对较短,但不能完全保证数据的完整性,有些表数据可能无法恢复,前景也是充满了变数。 
讨论下来,决定两条路并行实施。划分新的存储空间,使用备份软件进行数据恢复;同步的使用数据抽取软件进行数据扫描。最终经过不懈的努力,终于在尽可能短的时间恢复了所有被截断的表,而RMAN恢复,由于恢复速度只有不到20M,仍然在龟速进行中。 
前事不忘后事之师,虽然最终是将数据找了回来,但这个案例中,仍然有很多地方值得我们总结: 
 首先,应用账号权限分配过大。运维人员或者开发人员为了图方便省事,通常赋予应用账号DBA权限。如此给系统埋下了巨大的隐患,我们遇到很多开发人员误删数据库表的案例,或多或少的都对业务系统造成了影响。本例中的病毒程序也是通过应用账号创建了数据库登录触发器,从而导致事故的发生; 
 其次,系统管理不规范。开发人员随意使用第三方软件连接生产数据库进行操作,而这个过程没有受到任何监督和管控。这个案例中,我们通过监听日志定位到故障时间段连接的主机,才找出事故的始作俑者; 
 再次,数据备份非常的重要。随着数据量的快速增长,传统的备份技术已经难以满足业务系统的需要。数据备份在很多客户的体系中都是一个摆设,关键时候难以发挥作用。这个案例中,客户的数据库备份要花3天时间,加上归档备份,耗时将近5天时间,不到万不得已,大概没有人愿意采用这种恢复方式。关于数据保护,业界有很多的成熟方案。天玑科技数据库专业服务团队,结合自身丰富的数据保护经验,结合客户实际情况和需求,帮助众多的客户进行方案选型、规划设计及最终实施,取得了良好的效果。

你可能感兴趣的:(极客头条整理,oracle)