安全保护项目: 一种分阶段的数据库基础架构保护方法 (第一阶段）
(原文地址：http://www.oracle.com/technology/global/cn/pub/articles/project_lockdown/phase1.html）
第 1 阶段
持续时间：一天
这是安全性和合规性项目的第 1 阶段。 看看如何在 24 小时内保护您的基础架构。
这一部分涉及：
· 1.1 删除默认密码
· 1.2 配置 Oracle 二进制权限
· 1.3 保护其他可执行文件
· 1.4 使用 umask
· 1.5 限制 SYSDBA 登录
· 1.6 创建监听程序密码
· 1.7 保护监听程序
· 1.8 调整清除权限
· 1.9 更改 DBSNMP 密码
1.1 删除默认密码
背景
在 Oracle 软件安装和数据库创建期间，创建了一个帐户之后又忘记了该帐户是很常见的。 这些帐户通常都使用默认密码（例如 SCOTT 的密码是“tiger”），很容易成为入侵者青睐的入口点。您可能会惊讶于有如此多的生产数据库安装程序（经过审核后发现）使用“change_on_install”或“oracle”作为 SYS 的密码。您的首要任务就是应该立即识别并删除这些默认密码。
策略
如何识别使用默认密码的帐户？ 一种方法是尝试使用默认密码登录该帐户，但是这种方法无疑是很麻烦的，不用说也是很浪费时间的。
幸运的是，还有一种更好的方法。 请查看以下视图 DBA_USERS 中的密码列：
SQL> select username, password 2 from dba_users 3 where username = 'SCOTT'; USERNAME PASSWORD ------------------------------ ------------------ SCOTT F894844C34402B67
密码是结果哈希算法处理过的，因此不容易破解，但是，我们知道 SCOTT 的密码是“tiger”。 因此，当用户 ID 为“scott”时，“tiger”的哈希值为 F894844C34402B67。现在，如果更改 SCOTT 的密码，该哈希值也会更改。 然后，您可以在视图 DBA_USERS 中确认，查看 SCOTT 的密码是否与该哈希值匹配，这将验证该密码为“tiger”。但是，请注意，该哈希值不是密码自身的哈希值，如果其他用户的密码为“tiger”，该哈希值将不同。
SQL> create user scott2 identified by tiger; User created. SQL> select username, password 2 from dba_users 3 where username = 'SCOTT2'; USERNAME PASSWORD ------------------------------ -------------------- SCOTT2 C44C11D4C34DB67D
请注意，即使密码完全相同，哈希值 (C44C11D4C34DB67D) 仍然不同。
那么您如何利用该信息呢？ 很简单。 如果您使用默认密码创建了这些默认用户，您会知道这些密码的哈希值。 然后，您可以建立一个此类帐户和默认密码哈希值的表，将它们与存储在数据字典中的密码哈希值相比较。
2006 年 1 月，Oracle 提供了可下载的实用工具，以用于识别默认密码及其用户。 该实用工具在 MetaLink 上提供，如文档 ID 340009.1 中所述。截至本文撰写之日，该实用工具以类似上述方式的方法检查一组默认帐户；但是，等到您读到该文章时，该工具的功能可能已经得到了进一步的扩展。
此外，安全专家 Pete Finnigan 还对此作出了卓越贡献，他将在各种 Oracle 和第三方软件安装期间创建的此类默认帐户收集到了一起，并公开发表在了其网站中。 （标准免责声明： Oracle 不对第三方网站的内容进行验证。） 为了避免重复工作，我们将使用 Pete 的工作成果，并对他表示由衷的感谢。 然而，我对他的方法做了些许的改动。
首先，创建存储默认帐户和默认密码的表。
CREATE TABLE osp_accounts ( product VARCHAR2(30), security_level NUMBER(1), username VARCHAR2(30), password VARCHAR2(30), hash_value VARCHAR2(30), commentary VARCHAR2(200) )
然后，您可以使用 Pete 收集的数据加载该表。 （单击此处下载脚本。） 加载该表后，您就可以搜索默认密码了。 我将使用一个很简单的 SQL 语句找出这些用户：
col password format a20 col account_status format a20 col username format a15 select o.username, o.password, d.account_status from dba_users d, osp_accounts o where o.hash_value = d.password /
USERNAME PASSWORD ACCOUNT_STATUS --------------- -------------------- -------------------- CTXSYS CHANGE_ON_INSTALL OPEN OLAPSYS MANAGER OPEN DIP DIP EXPIRED & LOCKED DMSYS DMSYS OPEN EXFSYS EXFSYS EXPIRED & LOCKED SYSTEM ORACLE OPEN WMSYS WMSYS EXPIRED & LOCKED XDB CHANGE_ON_INSTALL EXPIRED & LOCKED OUTLN OUTLN OPEN SCOTT TIGER OPEN SYS ORACLE OPEN
这里，您可以看到一些最容易受到攻击的情况，尤其是最后一行，即用户 SYS，其密码是“ORACLE”（与 SYSTEM 的密码相同）！ 该密码可能不是“change_on_install”，但是完全可以预知。
该漏洞在各个版本中有所不同。 在 Oracle 数据库 10g 和更高版本中，数据库安装程序有一个提示，询问密码应该是什么，而不是将其假定为“change_on_install”或其他内容。由于用户被迫做出决定，因此该密码可能为非默认密码。 但是，如果用户选择象“oracle”之类可以预知的内容，则该提示就变得毫无意义了。（也许，在运行之前建立数据库时选择“oracle”对 DBA 很方便。 进入运行之后，该密码仍然沿用。）
在 Oracle 数据库 10g 之前的版本中，并不会提示输入密码，因此可能默认密码（例如“change_on_install”是 SYS 的默认密码，“manager”是 SYSTEM 的默认密码）是有效的。 该工具将帮助您识别此类情况。
此外，请注意用户 ID SCOTT（用于了解 SQL 技术的演示帐户）对开发数据库可能很适合，但是对生产数据库却并非如此。 它可能会给入侵者以可乘之机，您应该立即将其删除。
而 CTXSYS、DMSYS 和 OLAPSYS 等帐户则是 Oracle 工具必需的。 如果您不使用这些选项，最好的策略是删除这些用户。如果不确定是否使用这些选项，或者只是希望保留这个机会，您可以保留这些帐户，但是请将它们锁定使其无法连接。要锁定帐户并使密码过期，您可以发出以下命令：
alter user dmsys account lock expire password;
该命令会将帐户状态设置为 EXPIRED & LOCKED。 当用户尝试登录时，会显示以下错误：
ERROR: ORA-28000: the account is locked Warning: You are no longer connected to ORACLE.
更改不能锁定的所有帐户的密码。 DBNSMP 就是这样一个帐户，但是我们将在以后对其进行讨论。
结论
锁定未使用的帐户不会引起任何问题。
操作计划
识别未使用的帐户。
锁定这些帐户并使其密码过期。
1.2 配置 Oracle 二进制权限
背景
Oracle 数据库使用若干二进制文件。 当然，最重要的是 UNIX 和 Linux 中的可执行文件“oracle”以及 Windows 中的“oracle.exe”。
注意这些文件的权限。 例如，在 UNIX 中，您可以看到类似下面的内容。
# cd $ORACLE_HOME/bin # ls -l oracle -rwsr-s--x 1 oracle oinstall 69344968 Jun 10 14:05 oracle
这些权限（所有相关的 Oracle 版本都一样）是默认的。 让我们来看一下它们的含义。 （如果您熟悉 UNIX 权限，可以跳过本部分，直接转至“双任务体系结构”。）
第一个位置指示文件类型。 在 UNIX 中，常规文件、目录、设备等所有事物都被看作文件。 这是一个真文件，因此第一个位置显示“-”。 如果是一个目录，该位置将显示“d”；如果是一个字符特殊设备，该位置将显示“c”，等等。
第二个位置显示授予该文件的权限。 权限通过三块显示，分别指示以下状态：读、写和执行。 前三个位置显示所有者的权限，接下来三个位置显示授予该文件所属的组的权限，最后三个位置指定提供给所有其他用户的权限。
| 位置 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
| 值 |
- |
r |
w |
s |
r |
- |
s |
- |
- |
x |
| 所有者 |
组 |
其他 |
||||||||
在每个权限集中，权限都显示为一个值或“-”。 如果该位置显示“-”，表示该位置的未授予权限。例如，在上述情况中，注意第六个位置，指示组的写权限设置为“-”，表示组“dba”（文件所属的组）不能向文件写入。如果授予该权限，则该值设置为相应的字母。 还是在上面的示例中，组的读权限（由位置 5 表示）显示“r”，表示组“dba”可以读取该文件。
注意后三个位置，它们指示其他用户（不包括所有者、oracle 或者属于“dba”组的用户）的权限。 通过权限，您可以看到其他用户只能执行该文件，但是不能读取该文件或者向其写入。
这说明“r”、“w”和“x”分别表示读、写和执行，但是，“s”表示什么呢，这个位置本该显示“x”呀？ 这是有关执行权限的一个有趣技巧。上述情况在权限上显示“s”表示该程序启用了 setuid。当程序运行时，无论运行该程序的用户是哪一个，该程序都将以程序所有者的用户身份即“oracle”运行。 利用这种方式，程序可以由 Oracle 软件拥有，但是由连接到它的任何用户来运行。因此，程序可以在“oracle”权限下（而不是运行它的用户）运行，从而可以进行打开数据库文件等操作。
双任务体系结构。 记住 Oracle 数据库进程的运行方式是使用户进程与服务器进程分离。 如果您没有完全记住，我强烈建议您重新阅读 Oracle 数据库 10g 概念手册的前几章。 考虑到时间的问题，这里提供交互的高度精华版本，其中只是介绍了权限的基础，并不能替代手册中的内容。
当用户连接到 Oracle 数据库时（假定使用的是 SQL*Plus），Oracle 会创建一个新的进程来为该用户的程序提供服务。 该新进程名为 Oracle 服务器进程，它同用户进程（sqlplus、sqlplus.exe、TOAD.exe 或者可能的其他任何进程）不同。 如果在系统全局区域 (SGA) 等数据块缓冲区中未发现数据，该服务器进程与 SGA 等内存结构交互并从数据文件中读取数据。 在任何情况下，都不允许用户进程 (sqlplus) 直接与 Oracle 数据库交互。 由于有两个进程（用户进程和服务器进程）协同工作，因此有时称其为双任务体系结构。 如果用户进程执行了一些破坏性操作（例如违反主机中的内存管理），Oracle 数据库本身不会受到影响，损坏限于用户进程。
（请注意，上述内容适用于专用服务器环境中的 Oracle 连接。 在多线程服务器环境中，该模型会有所不同，因为在这种情况下，一个服务器进程可以向多个用户进程提供服务。 这仍然双任务，但是服务器进程和用户进程之间不是一对一的关系，而是一对多的关系。）
服务器进程在拥有 Oracle 软件的用户权限下运行。下面是一个例子。 假设用户使用 SQL*Plus 登录到数据库。
$ sqlplus arup/arup
此后，如果搜索该进程：
$ ps -aef|grep sqlplus
将显示：
oracle 6339 6185 0 13:06 pts/0 00:00:00 sqlplus
当然，这是假设服务器上一直没有运行其他 SQL*Plus 会话。
注意进程 ID (6339)。 现在，如果搜索该进程 ID
$ ps -aef|grep 6339
您将获得两个进程：
oracle 6339 6185 0 13:06 pts/0 00:00:00 sqlplus oracle 6340 6339 0 13:06 ? 00:00:00 oracleDBA102 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
第一个进程您之前已经看到，即 SQL*Plus 会话进程。 第二个进程的 ID 为 6340，它是 Oracle 为用户创建的服务器进程。 请注意，该进程的父进程 ID 为 6339，是 SQL*Plus 会话的进程 ID。
进程名称为“oracleDBA102 (DESCRIPTION=(LOCAL=YES) (ADDRESS=(PROTOCOL=beq)))”，其中包含了许多有用的信息。 首先，子句 LOCAL=YES 的存在表明该进程由于与数据库本身在同一个服务器上本地运行的另一个进程而启动。 名称中的 PROTOCOL=beq 还意味着该连接是通过 bequeath 连接构建的。
您还可以从动态视图中找到关于该服务器进程的信息。
select spid from v$session s, v$process p where s.sid = (select sid from v$mystat where rownum <2) and p.addr = s.paddr;
上述查询返回的值是服务器进程的进程 ID。 如果客户端进程在另一个服务器上（例如，某人在连接到数据库的笔记本电脑上运行 SQL*Plus），这是获得进程 ID 的唯一方法。
现在，假设用户通过稍有改动的方式进行连接。 她不是直接在服务器上连接，而是使用了 TNS 字符串。 假设 TNS 字符串类似以下内容（在服务器 oradba 上）。
DBA102 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradba)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DBA102)
)
)
现在，用户按照以下方式进行连接（在同一服务器 oradba 上）：
sqlplus arup/arup@dba102
从动态视图中检查进程 ID：
SQL> select spid 2 from v$session s, v$process p 3 where s.sid = (select sid from v$mystat where rownum <2) 4 and p.addr = s.paddr 5 / SPID ------------ 6428
进程 ID 为 6428。在服务器上搜索该进程：
$ ps -aef|grep sqlplus | grep -v grep oracle 6426 6185 0 13:20 pts/0 00:00:00 sqlplus
现在，当在数据库服务器上搜索服务器进程时：
$ ps -aef|grep 6426 | grep -v grep oracle 6426 6185 0 13:20 pts/0 00:00:00 sqlplus
....您不会看到服务器进程。 用户进程 6426 没有子进程。但是，从动态性能视图，您可以知道服务器进程为 6428，那么该进程的父进程是什么？
$ ps -aef|grep 6428 | grep -v grep oracle 6428 1 0 13:20 ? 00:00:00 oracleDBA102 (LOCAL=NO)
父进程为“1”。 但是为什么不是 6426 呢？
要理解该答案，需要了解不同的 Oracle 服务器进程的创建方式。 在第一种情况下，当用户未使用 TNS 连接字符串时，连接被直接路由到数据库，而不是首先经过监听程序。 数据库创建了一个用户进程，然后将该进程（称为 bequeathing）的控制权传递给进程所有者，以下使用术语 bequeath 进程，这显示在进程名称中。
第二种情况下，当用户仍然在同一服务器上但通过监听程序连接时，监听程序创建了称为 forking 的用户进程。 同样，如果用户进程在另一台计算机（例如笔记本电脑）上运行，连接需要通过监听程序，监听程序可能已经创建了该进程。 该进程是由远程服务器创建的，因此进程名称包含子句 LOCAL=NO。 即使 SQL*Plus 会话在同一服务器上运行，但它是一个非 bequeath 连接的事实使其成为非 LOCAL 连接。
（请注意： 根据 OS 的不同，您不能象在 bequeath 连接中查看 SQL*Plus 会话那样查看服务器进程的父 ID。在某些情况下，即使连接为 bequeath，父 ID 仍将显示为“1”。 因此，不要依赖父 ID 来决定服务器进程的类型；请通过进程名称来决定。
既然您理解了双任务模型；让我们来看一下您是否抓住了整个讨论的重点。 服务器进程由数据库创建并运行，而不是启动了 SQL*Plus 等客户端进程的用户。服务器进程使用可执行文件“oracle”或“oracle.exe”，因此仅名为“orasoft”（这样命名是为了避免与可执行文件的名称 “oracle”这个术语冲突）的 Oracle 软件所有者应该有权执行它们，其他任何人都不可以。 那么，您为什么需要其他用户的权限呢？
简短回答是： 您不需要。您可以通过发出以下命令删除不需要的权限：
$ chmod 4700 $ORACLE_HOME/bin/oracle
执行该命令后，权限将和下面的类似。
-rws------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle
现在我们可以通过 SUID 位转到策略。 在本例中，SUID 位设置为 ON（通过所有者的 rws 权限指示）。
策略
由于您不需要除 Oracle 软件所有者（本例为“orasoft”）之外的任何用户的权限来运行 Oracle 可执行文件，因此应该从可执行文件中删除 SUID 位，使其仅供所有者访问，其他任何人都不可访问。
$ chmod 0700 $ORACLE_HOME/bin/oracle
权限现在看起来与下面的类似：
-rwx------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle
结论
这是较大的改动，理解其影响很重要。 当服务器上的用户（非 Oracle 软件所有者）尝试连接一个本地连接时，可执行文件“oracle”将以该用户的名义运行，就好像用户“orasoft”正在运行该文件一样。这很重要；因为服务器进程将打开“orasoft”拥有的数据文件，该进程必须以“orasoft”身份运行，或者用户必须具有打开数据文件的权限。
例如，假设 UNIX 用户“ananda”登录到数据库所在的服务器，并进行本地连接：
$ sqlplus arup/arup
该用户将立即收到一条错误信息。
ERROR: ORA-12546: TNS:permission denied Enter user-name:
原因很简单： 您删除了文件“oracle”上的 SUID 权限。 当用户执行本地连接时，实质上是尝试运行可执行文件“oracle”，但是由于 SUID 未设置，因此不会以用户“orasoft”身份尝试而是以“ananda”身份尝试。 由于用户 ananda 没有运行该文件的权限，因此该文件也不会得到执行，因此出现了 ORA-12546 错误。
那么，ananda 怎样才能连接数据库呢？ 有两种方法。一个方法是，使所有用户进程在数据库服务器本身之外的服务器上运行，如此就不会存在到数据库的 bequeath 连接，只有非 LOCAL 连接。因为非 LOCAL 连接经过监听程序进程，监听程序为其衍生了服务器进程，所以服务器进程的所有者是“orasoft”（Oracle 软件所有者），而不是运行客户端进程的用户。 没有需要发布的权限。
或者，如果必须在数据库服务器本身上运行某些用户进程，您可以使用以下命令通过监听程序连接
$ sqlplus arup/arup@dba102
这与从服务器外部连接的用户具有同样的效果。 现在，只有拥有 Oracle 软件的用户（本例为 orasoft）可以通过 bequeath 连接来连接到数据库。
具有单独的操作系统 ID 的 DBA 将不能使用命令 connect / as sysdba 来关闭或启动数据库，即使他们属于 dba 组。 他们可以通过以下命令执行该操作
$ sqlplus /nolog SQL> connect sys/Password_of_SYS@dba102 as sysdba
是的，该方法使用了 SYS 密码；但是无论如何，与 / as sysdba 相比，该方法要好些。 但是，一种更好的方法是为各个 DBA 创建 Oracle 用户 ID：
connect ANANDA/Password_of_ANANDA@dba102 as sysdba
黑客惯用的伎俩是使用任意帐户登录服务器，然后尝试强行进入数据库。（典型的“松散门户”是用户“nobody”。） 即使黑客没有进入数据库，他也可以通过 oracle 可执行文件的缓冲区溢出创建拒绝服务攻击。如果删除了执行该文件的功能，那么该攻击的效果将受到严格限制。 同时，正如所见，您没有删除合法用户的任何功能。总之，大多数用户使用监听程序连接到数据库，而且并不会受到太大影响。
操作计划
准备
查看系统上是否有任何用户构建了 bequeath 连接。 为此，您可以执行以下操作：
- 通过询问
- 在服务器上搜索进程，查看是否有象 SQL*Plus 一样明显的内容
- 查看 V$SESSION 的 MACHINE 列
select program from v$session where machine = '
'; 如果出现一些这样的内容，您可以通过打开审计（在后续阶段将学习该功能）并捕获来自该服务器的所有程序来识别运行的确切程序。
操作
| IF 没有程序连接到服务器，THEN | |
| 更改 oracle 可执行文件的权限 chmod 0700 $ORACLE_HOME/oracle |
|
| ELSIF 某些程序从服务器进行连接 | |
| 将连接从 UserID/Password 更改为 UserID/Password@Connect_String | |
| END IF IF 您频繁从 shell 脚本作为 sqlplus / as sysdba 进行连接 THEN |
|
| 将其更改为使用 DBAUser/Password@Connect_String | |
| END IF | |
1.3 保护其他可执行文件
背景
看看 $ORACLE_HOME/bin 目录中的其他可执行文件；有些看起来很熟悉，例如 sqlplus 或 lsnrctl（启动监听程序的实用工具）；有些您可能并不熟悉。
其中一些文件（例如监听程序进程运行的实用工具 tnslsnr 或在 Oracle Intelligent Agent 中使用的 dbsnmp）最终用户不会直接接触到。 要正确保护这些文件，您必须了解它们的作用，从而采取相应的措施。
请记住，如果为文件设置了 SUID 位，则无论哪个用户运行该文件，该文件都在所有者的权限下运行，而不是在执行者的权限下运行。 您还应清楚，设置 SUID 是一种危险行为，不应给予鼓励。
还有一些文件将 SUID 设置为 on。 让我们将它们找出来。
$ cd $ORACLE_HOME
$ find . -type f /( -perm -2000 -o -perm -4000 /) -exec ls -l {} /;
在 Oracle 数据库 10g 第 1 版和更高版本中，上述命令应仅返回以下可执行文件：
-rwsr-s--x 1 orasoft dba 93300507 Jul 22 11:20 ./bin/oracleO -r-sr-s--- 1 root dba 0 Jul 1 23:15 ./bin/oradism -rwsr-s--x 1 orasoft dba 94492 Jul 22 11:22 ./bin/emtgtctl2 -rwsr-s--- 1 root dba 18944 Jul 22 11:22 ./bin/nmb -rwsr-s--- 1 root dba 20110 Jul 22 11:22 ./bin/nmo -r-sr-sr-x 1 nobody nobody 58302 Jul 22 11:23 ./bin/extjob
我们来看看这些文件是哪些：
| 程序 |
说明 |
| ./bin/oracleO | 该文件是可执行文件“oracle”的副本。 当您使用重新链接命令重新编译 oracle 可执行文件时，旧版本将另存为 oracle0。这是一个潜在的安全隐患；大多数 DBA 的忽略使其可能成为黑客的入侵途径。 因此，您应该采取措施删除这些权限。 最好的方法是让其没有任何权限： $ chmod 0000 oracleO 现在，如果您查看权限： $ ls -l oracleO |
| ./bin/oradism | 用于动态隐私共享内存。 可以在您的平台上使用。 并不是在所有情况下都出现。 如果出现，保持原样。 |
| ./bin/emtgtctl2 | 用于 Enterprise Manager Agent。 无需使用 SUID 设置它。 原因和“oracle”可执行文件一样。 删除权限。 $ chmod 0700 emtgtctl2 |
| ./bin/nmb | Oracle 10g 网格控制代理用其来收集目标服务器上的统计信息。 保持原样。 |
| ./bin/nmo | Oracle 10g 网格控制代理用其来收集目标服务器上的统计信息。 保持原样。 |
| ./bin/extjob | 这是 EXTJOB（外部作业，可用来从企业管理器内部执行基于 OS 的程序）的可执行文件。 您应当给予注意。 您是否经常使用外部作业？如果不是，那么您甚至不应该保留该可执行文件。 在这种情况下，您可以将其保留在目录中，但要更改权限和所有权关系。 所有者可以是 Oracle 软件所有者（本例为 orasoft），权限应该为 rwx------。 $ chown orasoft:oinstall extjob 可能还会存在另一个程序 extjobO，它是同一程序的先前编译。 该程序的权限也要改。 $ chown orasoft:oinstall extjobO |
在 Oracle9i 数据库第 2 版中，您将发现另一个文件 ./bin/dbsnmp，它是 Oracle Intelligent Agent 可执行文件。 权限的设置如下：
-rwsr-s--- 1 root dba 2986836 Jan 26 2005 dbsnmp
该文件的问题是它需要 root 权限才能正常工作，因此必须将 SUID 位设置为 on。 但是，由于该文件的所有者是 root，因此黑客通常利用它以 root 身份获得访问。 最好的方法是消除它，或者将其所有者改为 Oracle 软件所有者，将权限设置为 700。您将失去一些功能，但是为了消除风险，这是值得的。
另一个要考虑的可执行文件是 tnslsnr，它是 Oracle 网络监听程序。 有两个可执行文件：
tnslsnr - 实际的监听程序可执行文件
lsnrctl - 用于管理监听程序（例如启动、停止等）的实用工具。
如果您查看权限：
$ ls -l *lsnr* -rwxr-x--x 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl -rwxr-xr-x 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0 -rwxr-x--x 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr -rwxr-xr-x 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0
这些文件全都具有执行权限。 与可执行文件 oracleO 一样，通过重新链接 Oracle 软件创建新文件 tnslsnr 时，已有的文件被重命名为 tnslsnr0。 这样做是因为，如果需要回退该进程，可以将旧的可执行文件复制到新的可执行文件上。因为是旧的可执行文件的副本，因此文件 tnslsnr0 可能包含原来的 tnslsnr 的功能。 lsnrctl0 也是一样。
策略
既然您了解了每个可执行文件的作用，让我们来看看您如何能够保护数据库基础架构。 大部分策略已经在前面部分的背景信息中进行了讨论。 因此，实际上，您的策略措施是：
- 删除不需要的文件（例如 lsnrctl0）的所有权限。
- 限制仅 Oracle 软件具有可执行文件的权限。
- 如果 Oracle 软件所有者启动进程，删除 SUID 位。
因此，您希望更改与监听程序相关的文件的权限，如下所示：
$ chmod 700 lsnrctl tnslsnr $ chmod 000 lsnrctl0
验证结果。
$ ls -l *lsnr* -rwx------ 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl ---------- 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0 -rwx------ 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr ---------- 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0
结论
从本例可得出以下几个结论：
- 更改 oracleO 可执行文件对数据库的操作没有影响。如果曾经遇到导致“oracle”可执行文件损坏的问题，最好的做法是将“oracleO”文件重命名为“oracle”。若如此，请确保将权限重设为 700。对 lsnrctl0 和 tnslsnrctl0 文件也是如此。
- 如果使用 Oracle 软件所有者用户 ID 作为企业管理器操作系统凭证，更改 emtgtctl2 权限将没有任何影响。 如果使用其他用户 ID（例如，不是 orasoft），则必须将 SUID 重设为原来的值，权限必须设为与原来一样。
- 可执行文件 dbnsmp 由 Oracle Enterprise Manager Intelligent Agent 使用，但是仅延续到 Oracle9i 数据库第 2 版。此外，如果您使用 Oracle 软件所有者作为操作系统凭证，更改权限没有任何影响。 如果您使用其他用户 ID，则必须将权限重设为原来的值。
操作计划
- 将 oracleO、tnslsnr0 和 lsnrctl0 的权限更改为 0000。
- 将 tnslsnr 和 lsnrctl 的权限更改为 0700。
- 您在企业管理器中是否使用外部作业？
IF 没有 THEN 将 extjob 的权限更改为 0000
ELSE将 extjob 的权限更改为 0700 并将所有者和组更改为 orasoft 和 oinstall（或任何 Oracle 软件所有者的用户和组）。 END IF -
IF 您运行在 Oracle9i 数据库上 THEN 您是否使用 Oracle Intelligent Agent？ IF 没有 THEN 将 dbsnmp 的所有权更改为 orasoft
将权限更改为 0700ELSE 无需任何更改 END IF
1.4 使用 umask
背景
正如所知，您可以使用 chmod 命令更改 *nix 中的权限。 但是，由于 chmod 仅在现有文件上工作，您如何确保以后创建的文件具有相同的权限？
为了说明这一点，假设您希望目录中的所有文件都具有权限 r--r--r--（或 444）。 通过发出以下命令很容易做到这一点：
$ chmod 444 *
现在在目录上创建一个没有内容的简单文件，查看它的权限。
$ touch a_file.txt $ ls -l a_file.txt -rw-r--r-- 1 orasoft dba 0 Oct 21 13:44 a_file.txt
对于所有者，权限设置为读写，对于组设置为读，对于其他用户设置为读（或者 644），而不是您预期的 444。为什么？
在新创建的文件上设置的确切权限由一个名为 umask 的特殊参数指定。 umask 是一个值集，从所有权限中减去该值集可以得到新文件的权限值。 例如，如果将 umask 设置为 777，从整体权限值 777 中减去该值，得到 000，即新文件没有任何权限。让我们来看一个示例：
$ umask 777 $ touch b_file.txt $ ls -l ?_file.txt -rw-r--r-- 1 oracrmp dba 0 Oct 21 13:44 a_file.txt ---------- 1 oracrmp dba 0 Oct 21 13:53 b_file.txt
请注意，文件 b_file.txt 的权限为 000 或 ---------。 此外，请注意，先前创建的文件 a_file.txt 仍然被设置为原来的权限。 将 umask 设置为 777 得到新文件的权限。
umask 是为 Oracle 将创建的不同文件设置权限的强大有效的方法。
策略
Oracle 软件所有者的整体 umask 为 022，因此文件所有者的权限为读写，所有其他用户的权限为读。 您可以将该内容放到用户的登录配置文件中，以便它随时生效。
Oracle 使用的文件有很多不同类型，数据文件、重做日志文件、跟踪文件等等。数据文件可以预先知道，您可以轻松更改它们的权限，但是跟踪文件是在运行时生成的。 因此，您应该使用 umask 来确保这些跟踪文件没有暴露给任何外部用户，因为这些文件包含可能被黑客利用的各种机密信息。例如，理论上，某人可以通过复制跟踪文件来窃取数据文件，并将其安装在单独的服务器上，调出数据库以窃取其内容。
为目录设置 umask，如下所示：
| 目录 |
说明 |
umask |
| 初始化参数 background_dump_dest 指定的目录 |
某些跟踪文件和数据库警报文件都在此处生成。 权限应为 rw-------（仅 Oracle 软件所有者具有读写权限）。 |
0177 |
| 初始化参数 user_dump_dest 指定的目录 |
跟踪文件在此处生成。 权限应与上面相同。 |
0177 |
| $ORACLE_HOME/rdbms/log |
某些数据库日志文件在此处生成。 权限应与上面相同。 |
0177 |
| $ORACLE_HOME/rdbms/audit |
默认情况下，数据库审计的审计跟踪存储在此处，除非您已经设置了 audit_file_dest 初始化参数。 权限应与上面相同。 即使您有 DB 审计跟踪，某些通用事件（例如 SYSDBA 连接和数据库启动/关闭）始终在此处审计和放置。 |
0177 |
| 初始化参数 audit_file_dest 指定的目录 |
默认情况下，数据库审计的审计跟踪存储在此处，除非您已经设置了 audit_file_dest 初始化参数。 权限应与上面相同。 |
0177 |
结论
以这种方式设置 umask 可以防止某些开发人员访问会话跟踪文件，这些文件在 user_dump_dest 目录中生成并被传递到 tkprof 进行格式化。 因此，您可能希望仅在该目录上放松规则。
操作计划
- 将 background_dump_dest 上的 umask 更改为 0177。
- 将 $ORACLE_HOME/rdbms/log 上的 umask 更改为 0177。
- 将 $ORACLE_HOME/rdbms/audit 上的 umask 更改为 0177。
- 将 audit_file_dest 上的 umask 更改为 0177。
- （可选）将 user_dump_dest 上的 umask 更改为 0177。
1.5 限制 SYSDBA 登录
背景
您可能已经注意到，属于组“dba”成员的任何 *nix 用户都可通过以下命令以 SYSDBA 用户身份登录：
sqlplus / as sysdba
这通常被认为是一件很方便的事，因为您不需要记住或输入用户 SYS 的密码。 但是，这也带来了一个漏洞： 任何可通过 dba 组成员身份登录的用户都可通过 SYS 身份登录数据库。 导致 SYS 的加强密码并不经常使用。 如果您有一个牢固的 SYS 帐户，您可能应该对其以及 dba 组用户进行保护，使得以 SYS 身份登录必须提供 SYS 密码。这种方法不会消除渗透的风险，但是可以使该风险显著降低。
策略
该进程由文件 SQLNET.ORA 中的参数 SQLNET.AUTHENTICATION_SERVICES 控制。如果将该参数设置为 NONE，会禁用 SYSDBA 角色的自动登录。 要禁用 SYSDBA 角色的自动登录，可将以下行放到位于 $ORACLE_HOME/network/admin 目录中的 SQLNET.ORA 文件中。
SQLNET.AUTHENTICATION_SERVICES=(NONE)
从此时起，如果属于组 dba 的 *nix 用户希望使用类似的登录连接：
$ sqlplus / as sysdba
他们将收到：
ERROR: ORA-01031:insufficient privileges
要进行连接，必须提供 SYS 密码：
$ sqlplus /nolog SQL> connect sys/oracle as sysdba
这可以防止仍然不知道 SYS 密码的人访问 dba 帐户。
结论
如上所示，最重要的是使用 SYS 密码。 您可能需要对连接至 SYS 的脚本做一些改动。
如果您曾经丢失过 SYS 密码，不要担心。 您可以对文件 SQLNET.ORA 中的行进行注释，然后按照传统方式进行连接，即 / as sysdba。
操作计划
| IF 您在脚本中使用 SYS 连接 THEN | |
| 将 / as sysdba 更改为 sys/ 将 SQLNET.AUTHENTICATION_SERVICES=(NONE) 置于文件 SQLNET.ORA 中 |
|
| ELSE | |
| 无需任何更改 | |
| END IF | |
1.6 创建监听程序密码
背景
黑客惯用的伎俩之一是在监听程序中插入大量文本，从而导致监听程序终止。 数据库可能仍然运行，但是由于监听程序已经停止，因此无法建立任何新的连接，这实际上是一种“拒绝服务”攻击。
为此，黑客可能尝试更改监听程序的属性。 这里较常用的策略是通过 services 命令列出监听程序处理的各种服务。 注意显示多少信息，这些信息可能已足够黑客获得合法访问：
LSNRCTL> set displaymode verbose
LSNRCTL> services
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=prolin1.proligence.com)(PORT=1521)(IP=FIRST)))
Services Summary...
Service "PROPRD" has 1 instance(s).
Instance "PROPRD1", status READY, has 1 handler(s) for this
service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=/u01/oracle/products/10.1/db1/bin/ora
cle)(ARGV0=oraclePROPRD11)(ARGS='(LOCAL=NO)')(ENVS='_=/u01/oracle/pro
ducts/10.1/db1/bin/racgmain,_USR_ORA_CONNECT_STR=/ as
sysdba,_CAA_CHECK_INTERVAL=600,SHLIB_PATH=/u01/oracle/products/10.1/d
b1/lib32:/u01/oracrs/10gr1crs/lib32:/opt/nmapi/nmapi2/lib/hpux32:,_CA
A_ACTIVE_PLACEMENT=0,PATH=,_USR_ORA_ALERT_NAME=,_USR_ORA_IF=,_CAA_OPT
IONAL_RESOURCES=,_USR_ORA_START_TIMEOUT=0,ORACLE_BASE=/u01/oracle/pro
ducts/10.1/db2,_USR_ORA_DISCONNECT=false,_CAA_SCRIPT_TIMEOUT=600,_CAA
_UPTIME_THRESHOLD=7d,_USR_ORA_STOP_TIMEOUT=0,_CAA_FAILOVER_DELAY=0,_U
SR_ORA_PRECONNECT=none,_USR_ORA_FLAGS=,_CAA_TYPE=application,_USR_ORA
_INST_NOT_SHUTDOWN=,_CAA_REASON=boot,INIT_STATE=3,_USR_ORA_OPEN_MODE=
,_CAA_STATE=:OFFLINE,,_CAA_RESTART_ATTEMPTS=5,_CAA_ACTION_SCRIPT=/u01
/oracle/products/10.1/db1/bin/racgwrap,_CAA_DESCRIPTION=CRS
application for
Instance,_CAA_HOSTING_MEMBERS=prolin1,ORA_RACG_EXEC_ENV=LD_LIBRARY_PA
TH=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nm
api/nmapi2/lib/hpux64:/usr/lib:,_CAA_CLIENT_LOCALE=,_CAA_NAME=ora.PRO
PRD1.PROPRD11.inst,ORA_CRS_HOME=/u01/oracrs/10gr1crs,_CAA_AUTO_START=
1,_CAA_TARGET=:ONLINE,,_USR_ORA_PFILE=,_USR_ORA_OPI=false,_USR_ORA_CH
ECK_TIMEOUT=0,_CAA_PLACEMENT=restricted,_USR_ORA_LANG=,LD_LIBRARY_PAT
H=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nma
pi/nmapi2/lib/hpux64:/usr/lib:,_CAA_REQUIRED_RESOURCES=ora.prolin1.vi
p,_CAA_FAILURE_THRESHOLD=0,ORACLE_HOME=/u01/oracle/products/10.1/db1,
_USR_ORA_SRV=,PWD=/u01/oracrs/10gr1crs/bin,_USR_ORA_VIP=,_USR_ORA_STO
P_MODE=immediate,_CAA_FAILURE_INTERVAL=0,_USR_ORA_NETMASK=,_USR_ORA_D
EBUG=0,ORACLE_SID=PROPRD1,ORA_NET2_DESC=9,12,ORACLE_SPAWNED_PROCESS=1
')(ENV_POLICY=NONE))
黑客的另一个伎俩是关闭监听程序。 新的连接将被拒绝，再一次有效地创建了拒绝服务攻击。
此外，还可以远程管理监听程序。 利用该技术，黑客可以通过攻击其他有漏洞的计算机来远程停止监听程序。
您如何保护自己不受这些威胁侵害？
策略
最好的方法是删除可执行文件 tnslsnr 和 lsnrctl 的所有权限，所有者的权限除外。 （前面的部分已对该方法进行了描述。） 这样，除了 Oracle 软件所有者，没人可以启动或停止监听程序。 可执行文件与以下类似：
-rwx------ 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl -rwx------ 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr
在某些情况下，您可能希望授权启动和停止监听程序。 在这种情况下，您需要打开权限。
$ chmod 0711 lsnrctl
然而，在这种情况下，您应该通过强制使用密码防止未经授权的使用。 当您设置密码时，所有命令（HELP 等某些善意的命令除外）都被禁用。
设置密码的方式在所有版本中都一样，但是实施机制不同：
- 在 Oracle9i 数据库第 2 版和更低版本中，所有用户都需要密码。
- 在 Oracle 数据库 10g 第 1 版和更高版本中，拥有数据库软件的 OS 用户不需要密码。 所有其他用户需要密码。
下面介绍如何设置密码：
$ lsnrctl LSNRCTL> change_password Old password:Not displayed New password:Not displayed Reenter new password:Not displayed Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521)(IP=FIRST))) Password changed for LISTENER The command completed successfully
如果您是首次设置密码，可以在要求提供“旧密码”时按 ENTER 键。 更改之后，将其保存到参数文件中：
LSNRCTL> save_config
该命令将对密码进行加密，并将其放到监听程序参数文件中。 您可以稍后对其进行检查：
#----ADDED BY TNSLSNR 24-OCT-2005 17:02:28--- PASSWORDS_LISTENER_ODSSDB01 = 75CD180DE6C75466 #--------------------------------------------
在决定使用命令时，您需要提供正确的密码。 （在 Oracle 数据库 10g 和更高版本中，拥有该软件的 OS 用户不需要密码。）
LSNRCTL> services Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) TNS-01169: The listener has not recognized the password
要传递正确的密码，请执行以下内容：
LSNRCTL> set password mypassword The command completed successfully LSNRCTL> status Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS of the LISTENER ------------------------ Alias LISTENER ...
如果传递的密码不正确，您将收到以下错误信息
TNS-01169: The listener has not recognized the password.
如果没有传递密码并尝试执行强大的命令，您将收到以下错误信息
TNS-01190: The user is not authorized to execute the requested listener command
要确认密码是否有效，请查看监听程序的 STATUS 显示中的设置。 为此，可发出以下命令：
$ lsnrctl status
版本间的输出不同。 对于 Oracle9i 数据库，下面是部分输出：
STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Solaris: Version 9.2.0.6.0 - Production Start Date 25-OCT-2005 10:26:47 Uptime 0 days 13 hr.53 min. 8 sec Trace Level off Security ON
注意最后一行 (Security ON)，它指示已设置密码。
在 Oracle 数据库 10g 中，该进程稍有不同。 请记住，在该版本中，监听程序设置为了仅 Oracle 软件所有者可执行，无需密码。 如果已经设置了密码，则其他用户可以在提供密码后执行监听程序。 下面是状态显示：
STATUS of the LISTENER ------------------------ Alias LISTENER_ODSPDB02 Version TNSLSNR for HPUX:Version 10.1.0.4.0 - Production Start Date 16-OCT-2005 05:58:35 Uptime 9 days 17 hr.44 min. 41 sec Trace Level off Security ON:Local OS Authentication
注意最后一行 ON: Local OS Authentication，它指示尚未设置密码。 如果设置了密码，该行显示为：
Security ON: Password or Local OS Authentication
注意上面添加的子句 Password，它指示已经设置密码。
结论
在 Oracle 数据库 10g 和更高版本中，使用 OS 身份验证来验证用户，没有必要提供密码来启动或停止监听程序。 在 Oracle9i 和更低版本中，您需要提供密码，因此脚本需要密码。
操作计划
| IF Oracle 数据库 10g 或更高版本 THEN | |
| 删除所有用户的权限，所有者除外 | |
| ELSE | |
| 删除所有用户的权限，所有者除外 设置操作监听程序的密码 |
|
| END IF | |
1.7 保护监听程序
背景
创建一个缓冲区溢出，即通过发送要执行的大型字符串使监听程序崩溃是常用的入侵策略。 另一种常用策略是使用 SET DISPLAYMODE VERBOSE 从 lsnrctl 实用工具查看各种组件。 在这种情况下，黑客可以通过在有漏洞的计算机上运行 lsnrctl 以管理目标服务器上的监听程序来操纵设置。下面就是一个例子：
LSNRCTL> set trc_level support Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521))) LISTENER parameter "trc_level" set to support The command completed successfully LSNRCTL> set trc_directory /tmp Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521))) LISTENER parameter "trc_directory" set to /tmp The command completed successfully
由于跟踪级别为 SUPPORT，因此监听程序会生成大量您可能不希望黑客知道的信息。 此外，因为目录 /tmp 中会写入跟踪文件，所以黑客也很容易查看到这些信息。 甚至不登录服务器也可以了解到所有这些信息。
策略
要保护监听程序，最好的方法是设置密码。 此外，也可以使用其他方法： 限制使用 lsnrctl 实用工具设置各种监听程序参数的能力。在这种情况下，更改参数的唯一方式是在监听程序配置文件中设置参数，然后重新加载。 要设置这些限制，可以在 listener.ora 文件中添加以下行：
ADMIN_RESTRICTIONS_LISTENER = ON
然后，重新启动监听程序。 现在，您将不再能够在 lsnrctl 提示中使用 SET 命令来更改值了。例如：
LSNRCTL> set trc_directory /hacker_dir Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=PROPRD1)) TNS-12508: TNS:listener could not resolve the COMMAND given
注意 TNS-12508。从现在开始，要更改值，必须在 listener.ora 中进行，然后使用重新加载命令。
LSNRCTL> reload
这对本系列讨论的所有 Oracle 版本都适用。
即使使用密码保护监听程序，您仍然应该使用该技术进一步限制黑客操纵监听程序的能力。 在 Oracle 数据库 10g 中尤其应该如此，因为在该软件中，Oracle 软件所有者不需要提供监听程序密码。
结论
结论可以忽略。 总之，很少有用户在线编辑参数；而是先编辑·listener.ora，然后重新加载监听程序。 因此，该更改根本不会影响他们。
但是，请注意，使用远程监听程序控制来管理另一台服务器上的监听程序将不再可能。 相反，您需要登录服务器在 listener.ora 中进行更改，然后重新加载监听程序，总之，这是最好的方法。
操作计划
- 在文件 listener.ora 中，添加参数 ADMIN_RESTRICTIONS_LISTENER = ON。
- 发出 lsnrctl reload，重新加载监听程序。
1.8 调整清除权限
背景
普通用户需要执行其作业必不可少（不多不少）的权限。 但是，这种策略不太现实，您可能需要采用一种中间道路方法： 删除用户不需要的最强大的权限。
例如，CREATE ANY TABLE 就是一个强大的权限，它使用户可通过任意模式而不只是它自己的模式创建表。 用户几乎不需要该权限；您可以放心地收回该权限。 另一方面，QUERY REWRITE 之类允许用户会话重新写入查询以利用基于函数的索引或物化视图的权限则相对无害。
策略
首先，识别您认为无害的所有权限（CREATE TYPE、CREATE SESSION 等等）。 这里，我将 UNLIMITED TABLESPACE 包含在非清除权限内，但是您可能不这样认为。
set pages 50000
break on privilege skip 1
select privilege, grantee, admin_option
from dba_sys_privs
where privilege not in
(
/* list any other privilege here you don't find
"sweeping"
*/
'ALTER SESSION',
'QUERY REWRITE',
'CREATE DIMENSION',
'CREATE INDEXTYPE',
'CREATE LIBRARY',
'CREATE OPERATOR',
'CREATE PROCEDURE',
'CREATE SEQUENCE',
'CREATE SESSION',
'CREATE SNAPSHOT',
'CREATE SYNONYM',
'CREATE TABLE',
'CREATE TRIGGER',
'CREATE TYPE',
'CREATE USER',
'CREATE VIEW',
'UNLIMITED TABLESPACE'
)
and grantee not in
('SYS','SYSTEM','WKSYS','XDB',
'MDSYS','ORDPLUGINS','ODM','DBA')
/* Place all the user names you want to exclude */
order by privilege, grantee
/
下面是一个示例输出的一部分：
PRIVILEGE GRANTEE ADM
--------------------------- ------------------------------ ---
ADMINISTER DATABASE TRIGGER EXFSYS NO
IMP_FULL_DATABASE NO
ADMINISTER RESOURCE MANAGER EXP_FULL_DATABASE NO
IMP_FULL_DATABASE NO
ALTER ANY MATERIALIZED VIEW DWETL NO
REPORTMAN NO
ALTER ANY OUTLINE REPORTMAN NO
ALTER ANY PROCEDURE IMP_FULL_DATABASE NO
QCO NO
ALTER ANY RULE CDC_PUB YES
ALTER ANY RULE SET CDC_PUB YES
ALTER ANY TABLE IMP_FULL_DATABASE NO
CNSMP NO
QCO NO
ALTER ANY TRIGGER IMP_FULL_DATABASE NO
QCO NO
VCHANG NO
ALTER ANY TYPE IMP_FULL_DATABASE NO
ALTER SYSTEM ORADBA NO
QCO NO
ALTER TABLESPACE QCO NO
ALTER USER QCO NO
SYSMAN NO
ANALYZE ANY AFFMAN NO
ARAO NO
CONCASTER NO
CREATE ANY SYNONYM ATHOTANG YES
ARUP YES
IMP_FULL_DATABASE NO
DB_MONITOR YES
QCO YES
RCHUNG YES
SPOT YES
CREATE ANY TABLE IMP_FULL_DATABASE NO
CNSMP NO
QCO NO
SYSMAN NO
DROP ANY TABLE ATHOTANG YES
IMP_FULL_DATABASE NO
CNSMP NO
QCO YES
_ and so on _
注意该输出的一些关键行。 某些清除权限（例如 DROP ANY TABLE）可能不应该授予任何人。 在本例中，让我们来看看哪些用户拥有该权限。
- IMP_FULL_DATABASE 是用于数据库完全导入的角色，通常授给 DBA 或在导入中需要的任何其他用户。 该权限可能是必需的。
- QCO 表示 Quest Central for Oracle，它是管理数据库的常用工具。 该权限可能是必需的。
- 用户 CNSMP 和 ATHOTANG 似乎不需要任何清除权限，除非他们是 DBA。 应该收回该权限。
结论
这是一个您无法立即执行的操作。 收回任何用户的任何权限之前，需要认真分析它的影响。
如果拿不准，最好的操作流程是与持有该用户 ID 的人员进行交流。 例如，ATHOTANG 并不是真的需要删除表，但却被假设成这样。 （不要奇怪，这样的假设是很常见的。）
操作计划
该任务需要一些规划，以便准备下一阶段的所有操作。 在此之前，收集所需的信息。
1.9 更改 DBSNMP 密码
背景
如您所知，Oracle Intelligent Agent 与 Oracle Enterprise Manager 通信，传递有关组件（例如数据库、监听程序以及服务器本身）的信息。 要获得关于数据库的数据，需要使用某个用户 ID 连接数据库。默认情况下，使用的用户 ID 是 BSNMP。
创建数据库时，dbsnmp 的密码也被设置为 dbsnmp。 该用户有一些强大的权限，例如 UNLIMITED TABLESPACE、SELECT ANY DICTIONARY（允许用户从动态性能视图和数据字典视图中选择）和 ANALYZE ANY DICTIONARY（允许分析系统对象）。 很多入侵者使用该用户和密码作为进入数据库的后门入口点。 不用说，这是一个巨大的安全漏洞。
策略
您需要将该用户的密码 dbsnmp。 但是，您不能只是在数据库级别更改该密码，因为该密码还存储在代理配置文件中。 您还需要更新配置文件以使用新密码。 下面是在 Oracle 数据库 10g 中的操作过程。
- 首先，将用户 DBSNMP 的密码更改为别的内容（例如 TopSecret）：
SQL> alter user dbsnmp identified by topsecret;
- 转至 Oracle Agent Home 的安装目录（不是 ORACLE_HOME），例如 /u01/app/oracle/10.1/gridc。
- 转至目录
/sysman/emd ，其中是主机或服务器的名称。 例如，如果服务器的名称为 prolin1，则目录应为 prolin1/sysman/emd。 - 在这里，您会找到一个名为 targets.xml 的文件。复制该文件，为其取一个新名字（例如 targets.xml.old）。
- 打开文件 targets.xml，搜索“dbsnmp”一词；与以下内容类似
注意这一行：
您将在这一行中设置密码的值。 将上述内容替换为：
注意，您将 ENCRYPTED 的值更改为了 FALSE。
如果这是一个 RAC 数据库，该行将在文件中出现两次。 确保在两行中都做了更改。 在文件中搜索“password”一词，找到这两行。
现在，通过发出以下命令停止代理：/u01/app/oracle/10.1/gridc/bin/emctl stop agent重新启动代理：
/u01/app/oracle/10.1/gridc/bin/emctl stop agent重新启动代理后，会加密配置文件中的明文密码。 如果再次在 targets.xml 文件中查看上面的行，将看到类似下面的内容：
注意将明文值转换为加密值的方式。
现在已将代理配置为使用新的密码。
如果使用独立的数据库控制台而非网格控制，则操作过程相似，只是在第 2 步中，您要转至 ORACLE_HOME 而不是 Agent Ho me 所在的目录。结论
此处没有用户结论
操作计划
- 更改用户 DBSNMP 的密码。
- 更新代理文件以反映新密码。