from dba_source
where upper(text) like '%PASSWORD%'
or upper(text) like '%ENC%'
or upper(text) like '%DEC%'
or upper(text) like '%SECRET%'
or upper(text) like '%PASS%'
/
这可能会提供一些线索来帮助您标识可能要检查的代码段。 标识所有此类代码后，应使用 wrap 实用程序包装它并运行包装代码。 可能的影响
不存在任何可能的影响。 但您应该知道一个非常重要的问题： 包装是单项进行的；您可以包装明文代码，但不能从包装代码中创建明文。 因此，应将明文代码保存在某个安全的位置以便进一步编辑。 如果丢失明文代码，则将永远无法更改代码。
操作计划
标识包含机密数据的代码。
如果在 Oracle9i 中，则 |
| |
将值分解为多个部分并将每个部分嵌套在短语中。
创建一个变量以提取短语中的各个部分。
重新构造代码中的值。 |
| 否则 |
| |
不执行任何操作。 |
ENDIF
从明文中创建脚本文件。
包装脚本。
运行包装脚本。 |
2.7 将派生授权转换为直接授权
背景
授予权限时，可以选择使用 with grant option 子句，以便被授权者可以进一步授予权限。 以下是一个有关授予用户 A 拥有的表 TAB1 的权限的示例。 Step1
Connect A/******
Grant select on tab1 to B;
Step 2
Connect B/******
Grant select on a.tab1 to C;
用户收到错误 ORA-01031:insufficient privileges
原因是用户 B 无权授予它本身从某个用户那里收到的权限。 但在第 1 步中，如果语句为 Grant select on tab1 to b with grant option;
则用户 B 将有权进一步授予该权限，且第 2 步将成功。
同样，B 也可以使用 grant option 将该权限授予 C，而 C 随后可以将该权限授予 D，依此类推。
表面看来它似乎是一个不错的规划。 最初所有者 A 不必担心向哪个用户授予或撤销权限；该过程是按需进行自我管理的。 那么，问题是什么呢？
来看看以下情形： Connect A/*****
Revoke select on tab1 from B.
注意，C 从 B 那里获得它对 TAB1 的权限，而并非从 A 那里直接获得；因此，如果 B 丢失了这些权限，那么 C 的权限将如何？ C 也将丢失它的权限，这是因为该权限是一个派生的权限。
我们进一步假设 A 已经向 C 直接授予了对 TAB1 的 select 权限。 C 现在对 TAB1 有两个权限，一个来自 B，一个来自 A。当您撤销某个权限时，另一个权限仍然有效，从而使您错误地认为该权限不存在。
尽管该过程表面看来很不错，但实际上缺产生混淆和安全漏洞，并带来难于跟踪的错误。 一种更有意义的做法是在无中间方的情况下直接授予权限。
策略
您的目标是标识哪些权限是通过其他用户授予的，然后直接授予权限。 可以从视图 DBA_TAB_PRIVS 中清楚地看到这些权限，其中的列 grantor 显示了授予权限的用户。 SQL> col grantee format a15
SQL> col privilege format a15
SQL> col owner format a20
SQL> col table_name format a20
SQL> select grantee, privilege, owner, table_name
2 from dba_tab_privs
3* where grantor != owner
4 /
下面显示了一个简单的输出。 PUBLIC EXECUTE XDB.DBMS_XMLSCHEMA SYS
PUBLIC EXECUTE XDB.XDB_PRIVILEGES SYS
PUBLIC EXECUTE XDB.DBMS_XMLSCHEMA_INT SYS
APP1 SELECT ANANDA.MP RUSER
前三行可以忽略，在这三行中授权是由用户 SYS 向角色 PUBLIC 发出的。 该权限是模式 XDB 拥有的程序包 DBMS_XMLSCHEMA 的权限。 作为由 Oracle 提供的特殊程序包，这样做是允许的；但应注意第四行。 由 ANANDA 拥有的表 MP 是由 RUSER 授予的，因此应对其进行更正。 修复方法其实很简单： 将该对象的 select 直接授予 APP1，即使 RUSER 拥有 with grant option 权限。
执行该操作有两种方法：
- 对象拥有者直接授予该权限。
- SYS 这样的超级用户授予该权限。
第二种方法更易于实施。 SYS 用户实际上并不继承授权；它通过使用系统权限 grant any object privilege 授予权限。 当 SYS 使用以下代码授予权限时： grant select on a.tab1 to c;
GRANTOR 列将显示 A 而不是 SYS；这正是您所需要的。 set lines 300
set pages 0
spool grant_direct.sql
select 'grant '||privilege||' on '||owner||
'.'||table_name||' to '||grantee||';'
from dba_tab_privs
where grantor != owner
/
spool off
现在，运行文件 grant_direct.sql 以直接授予权限。
成功授予权限后，必须撤销间接授予的权限。 该操作无法在单个语句中实现，原因是您还必须以授权者的身份连接。 break on conn skip 2
select 'connect '||grantor conn,
'revoke '||privilege||' on '||owner||
'.'||table_name||' from '||grantee||';' line
from dba_tab_privs
where GRANTOR != 'SYS'
and grantor != owner
order by 1,2
/
将该脚本假脱机到某个文件，编辑该脚本以为每个用户提供口令，然后执行它以撤销授权。 可能的影响
有两个可能的影响。 首先，由于您要撤销权限并重新授予它们，因此可能由于无法重新授予权限而引起错误。 因此，必须在此更改的前后获得权限快照以确保成功。 使用以下脚本查找权限： SQL> select grantee, privilege, owner, table_name
2 from dba_tab_privs
3* where grantor != owner
4 /
在更改的前后运行该脚本，保存输出，然后比较它们以确保权限保持原样。
第二个可能的影响更明显。 授予和撤销周期将使这些对象的游标在库缓存中无效并将迫使对游标进行重新分析，从而将临时降低性能。
此外，某些相关对象将失效。 由于再次授予了权限，因此对象在被引用时将正常编译，但您可能需要采取某个主动式操作并事先重新编译它们。 操作计划
- 查找由其他用户使用 grantable 选项授予的权限。
- 撤销权限。
- 在不使用 grant 选项的情况下重新授予权限。
- 检查无效对象并重新编译它们。
2.8 限制表空间份额
背景
用户可以使用表空间内部多大的空间？用户可以写入多少个表空间？ 答案取决于可供用户使用的表空间的份额。 可以按如下所示指定份额： alter user ananda quota 12M on users;
此代码允许用户 ananda 创建总大小不超过 12MB 的存储对象，如表、索引以及物化视图。 要确认或查明用户已经使用的空间大小，请发出以下查询 SQL> col used format 999,999.999 head "Used (MB)"
SQL> col quota format 999,999.999 head "Quota (MB)"
SQL> col tablespace_name format a15
SQL> select username, tablespace_name,
2 bytes/1024/1024 used,
3 max_bytes/1024/1024 quota
4 from dba_ts_quotas
5 order by username
6 /
示例输出如下。 USERNAME TABLESPACE_NAME Used (MB) Quota (MB)
------------------- --------------- ------------ ------------
USER1 USERS .000 100.000
USER1 APP1_INDEX 504.875 -.000
USER2 USERS .125 5.000
我们需要对以上输出进行一下说明。 该输出表明用户 USER1 在表空间 USERS 中的份额为 100MB（显示在列 Quota 的下面）。 而用户未使用该分额中的任何表空间（显示在列 Used 的下面）。 第二行很有趣 - 您可以看到 Quota 列显示“-0”。 它指示用户在该表空间 (APP1_INDEX) 中具有无限的表空间权限。 用户 USER2 在表空间 USERS 中的份额为 5MB，并只使用了其中的 0.125 MB。
您应监视的是无限的表空间。 可以使用以下代码向用户提供无限份额： alter user ananda quota unlimited on users;
但该操作可能对安全性产生影响；如果常规用户对业务关键的表空间具有无限的表空间份额，则该用户可能会用尽该表空间 - 这一点类似于拒绝服务攻击。
一个更严重的风险是系统权限 UNLIMITED TABLESPACE，它使用户在所有表空间中均具有无限份额，而没有向他们授予特定份额。 请让我再次重申一下： 用户在所有表空间（包括 SYSTEM）中均具有无限的份额，因此用户可以从中创建对象。 这样并不好。
首先，检查 SYSTEM 上的任何显式表空间份额： select
username,
bytes/1024/1024 used,
max_bytes/1024/1024 quota
from dba_ts_quotas
where tablespace_name = 'SYSTEM'
order by username;
如果该查询显示某些内容，则应对其进行评估并在必要情况下撤销该份额。
下一步是标识具有无限表空间系统权限的用户。 select grantee
from dba_sys_privs
where privilege = 'UNLIMITED TABLESPACE';
由于该系统权限也包含 SYSTEM 表空间的权限，因此应对该列表进行仔细评估。
策略
您现在已经标识了所有用户及其表空间份额，下一个任务就是降低它们的风险。 此处有两个任务，一个任务比另一个任务更具破坏性。
首先，尝试删除 SYSTEM 表空间中的无限份额。 执行该操作不会对应用程序造成严重的破坏。 但在执行该操作之前，您需要确保 SYSTEM 表空间不包含 SYS 模式外部的对象。 以下查询可以实现此目的。 select owner, segment_type, segment_name
from dba_segments
where tablespace_name = 'SYSTEM'
and owner not in ('SYS','SYSTEM');
输出如下 OWNER SEGMENT_TYPE SEGMENT_NAME
--------------- --------------- --------------
OUTLN INDEX OL$HNT_NUM
OUTLN INDEX OL$SIGNATURE
OUTLN INDEX OL$NAME
OUTLN TABLE OL$NODES
OUTLN TABLE OL$HINTS
OUTLN TABLE OL$
在该示例中，只有 OUTLN 对象位于 SYSTEM 表空间中，这是可以接受的。 如果看到任何其他对象，则应移动它们。
该问题的根本原因可能是 select username
from dba_users
where default_tablespace = 'SYSTEM';
它将只返回以下内容。 USERNAME
----------
SYSTEM
SYS
OUTLN
如果它显示其他用户名，请将该用户更改到其他表空间。 例如，要将用户 SCOTT 的默认表空间更改为 USER_DATA，请发出以下命令 alter user scott default tablespace user_data;
然后将所有对象移出系统表空间。 alter table scott.tab1 move tablespace user_data;
现在，您的下一个任务是确保所有用户在 SYSTEM 表空间中的份额为 0。 份额无限有两个基本原因，其中之一就是直接授予了无限的表空间。 另一个原因是授予了角色 RESOURCE，该角色在 Oracle9i 数据库和更早版本中具有系统权限 UNLIMITED TABLESPACE。 相比之下，Oracle 数据库 10g 并不将系统权限授予 RESOURCE 角色。
对于 Oracle9i 数据库
确保实际上已将 UNLIMITED TABLESPACE 授予 RESOURCE 角色。 SQL> select *
2 from dba_sys_privs
3 where grantee = 'RESOURCE';
GRANTEE PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
RESOURCE CREATE TYPE NO
RESOURCE CREATE TABLE NO
RESOURCE CREATE CLUSTER NO
RESOURCE CREATE TRIGGER NO
RESOURCE CREATE OPERATOR NO
RESOURCE CREATE SEQUENCE NO
RESOURCE CREATE INDEXTYPE NO
RESOURCE CREATE PROCEDURE NO
RESOURCE UNLIMITED TABLESPACE NO
如果未列出 UNLIMITED TABLESPACE，则您不必在此阶段执行任何操作。 向前转至“常见任务”。
对于 Oracle 数据库 10g
确保未将 UNLIMITED TABLESPACE 授予 RESOURCE 角色。 SQL> select *
2 from dba_sys_privs
3 where grantee = 'RESOURCE';
GRANTEE PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
RESOURCE CREATE TYPE NO
RESOURCE CREATE TABLE NO
RESOURCE CREATE CLUSTER NO
RESOURCE CREATE TRIGGER NO
RESOURCE CREATE OPERATOR NO
RESOURCE CREATE SEQUENCE NO
RESOURCE CREATE INDEXTYPE NO
RESOURCE CREATE PROCEDURE NO
常见任务
标识具有 UNLIMITED TABLESPACE 权限的用户，并将其份额更改为在所有表空间中均为 unlimited。 set lines 300
set pages 0
spool quota.sql
select 'alter user '||grantee||' quota unlimited on '||
tablespace_name||';'
from dba_sys_privs p, dba_tablespaces t
where p.grantee in (
select username
from dba_users
)
and p.privilege = 'UNLIMITED TABLESPACE'
and t.tablespace_name not in ('SYSTEM','SYSAUX')
order by grantee, tablespace_name
/
spool off
此代码创建一个包含类似如下内容的文件 alter user ORAAGENT quota unlimited on INDEX01;
alter user ORAAGENT quota unlimited on INDEX02;
alter user ORADBA quota unlimited on INDEX02;
接下来，您可以执行此脚本文件以拥有这些用户的无限份额。 最后，删除 UNLIMITED TABLESPACE。 set lines 300
set pages 0
spool revoke_ut.sql
select 'revoke unlimited tablespace from '||grantee||';'
from dba_sys_privs
where privilege = 'UNLIMITED TABLESPACE'
/
spool off
然后，执行此脚本文件以撤销权限。 可能的影响
删除这些权限以及将 SYSTEM 表空间的份额减少为 0 不会产生影响。 但如果 SYSTEM 表空间中存在段，并且您将其移动到其他表空间，则将产生两个结果：
- rowid 将因为物理移动而更改。 如果您有一个基于 rowid 的应用程序，则应注意这一点。
- 表索引将不可用 - 您必须重建它们。
此更改还可以使某些独立过程无效。
操作计划
|
找到 SYS、SYSTEM 和 OUTLN 之外的用户的默认表空间。
如果默认表空间为 SYSTEM，则将其更改为非 SYSTEM 表空间。
找到属于 SYS、SYSTEM 和 OUTLN 之外的用户的 SYSTEM 表空间段。
如果找到，则 |
| |
将它们移出到它们的表空间
重新构建索引、物化视图等。 |
ENDIF
找到具有 UNLIMITED TABLESPACE 系统权限的用户
如果找到，则 |
| |
向他们授予所有表空间（SYSTEM 和 SYSAUX 除外）的无限份额
撤销系统权限 UNLIMITED TABLESPACE |
| ENDIF |
2.9 监控监听器日志以获知尝试的非法入侵
背景
在阶段 1.7 中，您了解了如何通过限制在线更改参数的能力来保护 Oracle Listener。 这样做很不错，但您如何知道是否有人尝试非法入侵以及何时尝试非法入侵？ 防止入侵只是预防措施的一部分；跟踪防御的有效性同样重要。
您可以从监听器日志文件中浏览已尝试的失败登录。 当用户提供错误口令并尝试修改监听器时，以下消息将写入监听器日志： 12-NOV-2005 23:23:12 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=prolin01)(USER=ananda
))(COMMAND=stop)(ARGUMENTS=64)(SERVICE=LISTENER_PROLIN01)(VERSION=168821760)) * stop * 1190
TNS-01190: The user is not authorized to execute the requested listener command
该消息表明 11 月 12 日晚上 11:23，用户“ananda”尝试停止监听器（注意 (COMMAND=stop) 的存在），但提供了错误的口令。 这是否表示尝试的非法入侵？ 有可能。 ananda 也可能是一个合法用户，但在输入口令时出现输入错误，从而产生此错误。 但如果您多次看到此错误，则它实际上可能指示尝试的非法入侵。应访问用户 ananda 并验证它实际上是否尝试停止监听器。
同样，在监听器中限制 admin 选项时，用户无法只从命令行设置参数。 如果用户尝试使用以下命令： $ lsnrctl
LSNRCTL> set trc_level support
他将立即获得错误。 TNS-12508: TNS:listener could not resolve the COMMAND given
以下条目将出现在监听器日志文件中。 12-NOV-2005 23:26:34 * trc_level * 12508
TNS-12508: TNS:listener could not resolve the COMMAND given
该条目指示某人曾尝试直接对 LSNRCTL 提示设置 trc_level。 这可能也是个正常的错误，但重复尝试可能表示存在攻击。
策略
最好的方法是定期检查这些模式的监听器日志文件。 可以通过多种方法执行该操作。
首先，您可以使用以下代码编写一个 shell 脚本： $ grep "(COMMAND=stop)" listener.log | cut -f4 -d"*"
以下输出将指示监听器命令 STOP 已发出三次： 0
0
0
还可以使用复杂工具（如 awk）或脚本语言（如 PERL）使该脚本提供更丰富的信息。 但如果您对 SQL 最熟悉（这种情况很有可能），则使用 SQL 从此日志文件中提取信息将更具有吸引力。
此处的技巧是将监听器日志用作外部表。 首先，为监听器日志所在的目录创建一个 directory 对象。 create directory listener_log_dir
as
'/u01/app/oracle/10.1/db1/network/log'
/
然后，为日志文件创建外部表。 仔细留意日志文件的内容；它通常包含六个由“*”字符分隔的信息部分。 这些部分将成为外部表的列。 create table listener_log
(
log_date date,
connect_data varchar2(300),
protocol_data varchar2(300),
command varchar2(15),
service_name varchar2(15),
return_code number(10)
)
organization external (
type oracle_loader
default directory LISTENER_LOG_DIR
access parameters
(
records delimited by newline
nobadfile
nologfile
nodiscardfile
fields terminated by "*" lrtrim
missing field values are null
(
log_datechar(30) date_format
date mask "DD-MON-YYYY HH24:MI:SS",
connect_data,
protocol_data,
command,
service_name,
return_code
)
)
location ('listener_prolin01.log')
)
reject limit unlimited
/
创建表后，可以从中进行选择以确保定义正确。
这些行的描述性很高，但嵌入的命令（如 (COMMAND=stop)）可能使它难于破解。 这种情况下，编写另一个函数以提取字符串中的值： create or replace function extract_value
(
p_in varchar2,
p_param in varchar2
)
return varchar2
as
l_begin number(3);
l_end number(3);
l_val varchar2(2000);
begin
l_begin := instr (upper(p_in), '('||p_param||'=');
l_begin := instr (upper(p_in), '=', l_begin);
l_end := instr (upper(p_in), ')', l_begin);
l_val := substr (p_in, l_begin+1, l_end - l_begin - 1);
return l_val;
end;
这样，监控将变得非常简单。 发现失败登录尝试所要执行的操作就是发出 col l_user format a10with the embedde
col service format a20
col logdate format a20
col host format a10
col RC format a5
select to_char(log_date,'mm/dd/yy hh24:mi:ss') logdate,
extract_value (connect_data,'HOST') host,
extract_value (connect_data,'USER') l_user,
extract_value (connect_data,'SERVICE') service,
action RC
from listener_log
where extract_value (connect_data, 'COMMAND') in
(
'password',
'rawmode',
'displaymode',
'trc_file',
'trc_directory',
'trc_level',
'log_file',
'log_directory',
'log_status',
'current_listener',
'inbound_connect_timeout',
'startup_waittime',
'save_config_on_stop',
'start',
'stop',
'status',
'services',
'version',
'reload',
'save_config',
'trace',
'spawn',
'change_password',
'quit',
'exit'
)
这返回类似如下所示的输出 LOGDATE COMMAND HOST L_USER SERVICE RC
-------------------- --------------- ---------- ---------- -------------------- -----
10/02/05 02:57:36 stop prlddb01 oraprld LISTENER_PRLDDB01 0
10/02/05 04:47:03 stop prlddb01 oraprld listener_prlddb01 0
10/03/05 15:14:53 stop prlddb01 oraprld LISTENER_PRLDDB01 0
11/18/05 23:48:26 reload prlddb01 oraprld LISTENER_PRLDDB01 0
您可以看到，该输出显示了命令的日期和时间以及返回代码。 也可以修改此查询以只显示返回代码不为 0 的值。此外，还可以添加一个谓词以只显示某个日期之后的记录，以便只显示当天的尝试。 如果每天均运行此脚本，则只能看到当日的尝试。
上面只显示了无效口令的数据。 对于管理限制的监听器，该错误字符串只显示三个字段，因此表 LISTENER_LOG 的列具有不同的含义： 第二列显示用户发出的命令，第三列显示返回代码。 select
log_date,
connect_data command,
protocol_data return_code
from listener_log
where connect_data in
(
'password',
'rawmode',
'displaymode',
'trc_file',
'trc_directory',
'trc_level',
'log_file',
'log_directory',
'log_status',
'current_listener',
'inbound_connect_timeout',
'startup_waittime',
'save_config_on_stop',
'start',
'stop',
'status',
'services',
'version',
'reload',
'save_config',
'trace',
'spawn',
'change_password',
'quit',
'exit'
)
/
这返回： LOG_DATE COMMAND RETURN_CODE
--------- -------------------- ---------------
06-NOV-05 change_password 0
06-NOV-05 save_config 0
06-NOV-05 log_file 0
06-NOV-05 trc_level 12508
06-NOV-05 save_config_on_stop 12508
06-NOV-05 log_directory 12508
06-NOV-05 log_directory 12508
06-NOV-05 stop 1169
06-NOV-05 stop 1169
06-NOV-05 services 1169
06-NOV-05 status 1169
06-NOV-05 reload 1169
06-NOV-05 status 1169
06-NOV-05 stop 1169
06-NOV-05 status 1169
06-NOV-05 stop 1169
可能的影响
无；该活动只是一个诊断活动。
操作计划
- 创建监听器日志外部表。
- 选择在无口令情况下发出管理命令的记录（可以由非零返回值标识）。
- 选择根据监听器控制提示发出命令的记录。
- 如果找到无法由任何 DBA 执行的活动解释的记录，则您可能标识了错误内容。
2.10 审计和分析用户访问
背景
您对用户的了解程度如何？ 您是否知道他们从哪些计算机连接、他们在连接时的活动等问题？或许您并不知道。 但请注意，一个成功的安全性规划需要了解这些详细信息，或至少了解重要信息。 这正是 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。您应进行全面的调查。 可能的影响
审计对性能的影响最低；但仍存在一定程度的影响。 此外，请注意，审计跟踪写入表空间 SYSTEM（可能已被填满）中。 因此，您必须注意 SYSTEM 表空间内部的可用空间。
操作计划
- 通过设置 AUDIT_TRAIL 初始化参数打开审计。
- 对会话启用审计。
- 查找无效或失败的登录尝试。
- 检查失败的模式尝试（日期集群）。
|
网友评论：（只显示最新10条。评论内容只代表网友观点，与本站立场无关！） 