1. 创建监听器日志外部表。
2. 选择在无口令情况下发出管理命令的记录（可以由非零返回值标识）。
3. 选择根据监听器控制提示发出命令的记录。
4. 如果找到无法由任何 DBA 执行的活动解释的记录，则您可能标识了错误内容。

背景
您对用户的了解程度如何？ 您是否知道他们从哪些计算机连接、他们在连接时的活动等问题？或许您并不知道。 但请注意，一个成功的安全性规划需要了解这些详细信息，或至少了解重要信息。 这正是 Oracle 数据库中的审计功能的用途所在。

Oracle 数据库中的审计功能非常全面。 此处，您只需要启用该功能的一部分来创建数据库的“配置文件”。 您将尝试的所有操作就是查看用户连接、用户连接所使用的用户 ID 以及所使用的验证类型。 您还将发现无效的登录尝试 - 例如，用户 ID/口令组合何时错误。 正如以上所介绍的，查找这些异常事件的模式可以为发现可能的攻击提供线索。

策略
要启用审计，请在数据库初始化参数文件中设置以下参数。

audit_trail = db

这是一个静态参数；您必须重新利用数据库才能使其生效。 执行此操作后，发出以下命令以执行审计。

AUDIT SESSION;

该命令将在用户登录或注销时创建一个记录。 即使登录失败也将创建登录跟踪。 在数据库运行一段时间后，可以在审计跟踪中搜索模式。 列 RETURNCODE 记录用户在执行该操作时收到的 Oracle 错误代码。

SQL> select returncode, count(1)
  2  from dba_audit_trail
  3  group by returncode
  4  /

RETURNCODE   COUNT(1)
---------- ----------
         0    1710880
       604          3
       955         17
       987          2
      1013          2
      1017       1428
      1045          1
      1555          4
      1652          4
      1950          1
      2002          1
      2004          4
     28000          4
     28009          3

以上代码显示了错误模式；大多数操作均成功（其中的返回代码为 0）。 对于剩余代码，您可以通过从 *nix 提示符中发出以下命令获得描述

oerr ora <errorno>

。 例如，要查明错误代码 1017 的含义，请发出

oerr ora 1017

这将返回

01017, 00000, "invalid username/password; logon denied"
// *Cause:
// *Action:

这个最常见的错误是分析的目标，因为它将最有效地显示攻击模式。 无效/口令组合的偶然性如果很高，则可能指示尝试的意外入侵。

现在，您将看到这些会话的来源。 特定用户 ID 的口令无效可能指示对该用户 ID 的攻击。 可以通过以下代码查看用户 ID：

select username, count(1)
from dba_audit_trail
where returncode = 1017
group by username
order by 2 desc;

USERNAME                         COUNT(1)
------------------------------ ----------
ARAO                                  569
DBSNMP                                381
DW_DQS                                181

此处，我们看到用户 ARAO（表面看来是一个实际用户）已经尝试使用无效口令 569 次。 下一个用户 ID DBSNMP（381 次无效的口令尝试）不是一个实际用户；它的用户 ID 为 Enterprise Manager。 这应立即引发警报信号 - —DBSNMP 是一个首选的攻击目标。

为进一步检查它，我们将查看这些攻击的来源：

select userhost, terminal, os_username, count(1)
from dba_audit_trail
where returncode = 1017
and username = 'DBSNMP'
group by userhost, terminal, os_username;

USERHOST                  TERMINAL        OS_USERNAM   COUNT(1)
------------------------- --------------- ---------- ----------
prlpdb01                                  oraprlp           199
prlpdb01                  pts/2           oraprlp             4
prlpdb01                  pts/7           oraprlp             9
prlpdb02                                  oraprlp           130
PRONT\PRANANDAT42         PRANANDAT42     ananda              3
progcpdb                  unknown         oracle             34

注意，此数据库运行所在的服务器为 prlpdb01。 由于这是一个 RAC 数据库，因此还存在第二个节点，且服务器名称为 prlpdb02。 大多数错误连接尝试均来自这些服务器，并使用作为 Oracle 软件拥有者的 OS 用户 (oraprlp)。 如果这是实际的攻击，则用户可以访问 Oracle 软件所有者并可以 SYSDBA 的身份登录。 不需要以 DBSNMP 的身份登录，该口令明显是错误的。 因此，它并不像攻击。

您还可以看到无效登录来自其他两个计算机： PRONT\PRANANDAT42 和 progcpdb。 它们看似可疑，我们可以确认这些计算机的身份 - 第一个计算机属于名为“ananda”的 DBA，另一个计算机是网格控制服务器，它应使用此用户 ID 连接。

接下来，请分析这些失败的模式。 如果这些失败集中在特定时间发生，则可能指示攻击。

SQL> select to_char (timestamp,'mm/dd/yy') ts, count(1)
  2  from dba_audit_trail
  3  where returncode = 1017
  4  and username = 'DBSNMP'
  5  group by to_char (timestamp,'mm/dd/yy')
  6  /

TS                     COUNT(1)
-------------------- ----------
10/14/05                      9
10/16/05                    222
10/27/05                     15
10/28/05                    125
11/09/05                      4
11/11/05                      2
11/12/05                      2
11/14/05                      2

您可以看到，有两个频繁出现失败的时间： 10/16 和 10/28。您应进行全面的调查。

操作计划

1. 通过设置 AUDIT_TRAIL 初始化参数打开审计。
2. 对会话启用审计。
3. 查找无效或失败的登录尝试。
4. 检查失败的模式尝试（日期集群）。

(编辑:aniston)