注意，此数据库运行所在的服务器为 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)