这一部分涉及：
· 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 列
d. select program

e. from v$session

f. 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
---------- 1 orasoft oinstall 248823320 Sep 15 13:27 oracleO

./bin/oradism
用于动态隐私共享内存。 可以在您的平台上使用。 并不是在所有情况下都出现。 如果出现，保持原样。

./bin/emtgtctl2
用于 Enterprise Manager Agent。 无需使用 SUID 设置它。 原因和“oracle”可执行文件一样。 删除权限。

$ chmod 0700 emtgtctl2

./bin/nmb

来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/178357/viewspace-910006/ ，如需转载，请注明出处，否则将追究法律责任。