应对“比特币勒索”经验分享
近期，比特币勒索攻击卷土重来，用户在登陆数据库时出现勒索警告信息，被要求上交比特币来换取解锁数据库的服务。这一般是由于用户下载了非官方的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天时间，不到万不得已，大概没有人愿意采用这种恢复方式。关于数据保护，业界有很多的成熟方案。天玑科技数据库专业服务团队，结合自身丰富的数据保护经验，结合客户实际情况和需求，帮助众多的客户进行方案选型、规划设计及最终实施，取得了良好的效果。
