真实案例：数据库审计在入侵行为审计中的作用

1

事件起因

2015年1月15日16：50，安恒信息的技术工程师接到客户电话：发现业务系统可能被“拖库”，需要协助客户对越权拖库行为进行调查！

17：50，技术工程师到达客户现场的时候，客户自己已经通过“安恒明御数据库审计与风险控制系统”查询出了黑客的IP地址。（虽然1小时就到了现场，但是客户本身对业务、对数据库审计都非常熟悉，效率非常高啊有木有！）

2

事后审计追踪过程

该客户网络中有数千台计算机，客户在查看数据库审计设备时，发现有大批量的返回结果集超过1000行的select数据查询告警，通过查询数据库审计告警日志及原始审计日志，通过会话关联分析，发现大量的非运维网段的IP频繁整表查询行为，最终确定IP为192.168.12.241的客户端使用plsqldev.exe工具在直接拖库！

客户通过安恒数据库审计与风险控制系统定位此次攻击的方式非常简单，如下图：

1) 在告警界面找到对应的返回行数过大的告警行为。

2) 点击查看本次会话的详细信息，如下图所示：

3) 通过交谈了解到，客户方数据库管理员平时都用Toad管理数据库，所以在审计查询里面输入plsqldev.exe、sqlplus.exe等常用客户端工具进行查询（也包括了Toad）

4) 由于数据库管理员都在独立的运维区，实际上输入该区域以外的IP（可以自定义）就极大的缩小了范围，最终直接确定哪些操作是违规行为。

5) 虽然入侵是刚发现的，但为了确定之前是否已经有攻击行为存在，我们将审计追溯的日期选择到2014年10月8日开始。

6) 报文这里，其实意义不太大了，因为将非运维管理区定义好之后，再结合客户端工具，已经可以完整的进行攻击源的锁定。

通过一次“查询”就出来了结果。我们看下图的影响行数、IP、MAC、客户端工具，然后再通过网络认证计费系统查询到该时间段内此IP被分配了哪位用户，一切水落石出！

3

安全策略加固

因此通过本次事件也很好的说明再好的安全设备也需要有效的人机结合，设备需要有正确、有效的策略配置，在这个案例当中，结合客户的业务逻辑，我们重新给客户新增审计告警规则，这样一来，一旦以后再次出现此类问题可以直接发邮件给数据库管理员！

1）、对“非网络运维区”的操作进行告警，也就是只要发生非管理员网段的操作就会告警。客户的业务系统决定了不会有来自非运维区的直接操作数据库的行为，所以一旦出现非管理员网段的操作就是违规行为；

2）、对进行操作之后，影响行数大于1000的行为进行告警。因为在正常的情况下，业务系统不存在如此大批量的数据操作行为；

3）、开启特征检测，针对可能的数据库入侵行为进行检测；

通过上述配置，我们就可以在安恒明御数据库审计与风险控制系统中及时发现入侵行为、以及非合规操作行为，使得DBA能更有效的对数据库安全进行保障。

其实数据库审计能做的事情非常多，未来，安恒信息的安全专家将为您带来更多关于数据库安全方面的文章，感谢您的支持！