安全保护项目.docx

第 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 a20col account_status format a20col username format a15select o.username, o.password, d.account_statusfrom dba_users d, osp_accounts owhere o.hash_value = d.password/USERNAME PASSWORD ACCOUNT_STATUS- - -CTXSYS CHANGE_ON_INSTALL OPENOLAPSYS MANAGER OPENDIP DIP EXPIRED & LOCKEDDMSYS DMSYS OPENEXFSYS EXFSYS EXPIRED & LOCKEDSYSTEM ORACLE OPENWMSYS WMSYS EXPIRED & LOCKEDXDB CHANGE_ON_INSTALL EXPIRED & LOCKEDOUTLN OUTLN OPENSCOTT TIGER OPENSYS 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 lockedWarning: 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 sqlplusoracle 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 spidfrom v$session s, v$process pwhere s.sid = (select sid from v$mystat where rownum select spid 2 from v$session s, v$process p 3 where s.sid = (select sid from v$mystat where rownum connect sys/Password_of_SYSdba102 as sysdba是的，该方法使用了 SYS 密码；但是无论如何，与 / as sysdba 相比，该方法要好些。 但是，一种更好的方法是为各个 DBA 创建 Oracle 用户 ID： connect ANANDA/Password_of_ANANDAdba102 as sysdba黑客惯用的伎俩是使用任意帐户登录服务器，然后尝试强行进入数据库。 （典型的“松散门户”是用户“nobody”。） 即使黑客没有进入数据库，他也可以通过 oracle 可执行文件的缓冲区溢出创建拒绝服务攻击。 如果删除了执行该文件的功能，那么该攻击的效果将受到严格限制。 同时，正如所见，您没有删除合法用户的任何功能。 总之，大多数用户使用监听程序连接到数据库，而且并不会受到太大影响。 操作计划准备查看系统上是否有任何用户构建了 bequeath 连接。 为此，您可以执行以下操作： a. 通过询问 b. 在服务器上搜索进程，查看是否有象 SQL*Plus 一样明显的内容 c. 查看 V$SESSION 的 MACHINE 列 d. select programe. from v$sessionf. where machine = ;如果出现一些这样的内容，您可以通过打开审计（在后续阶段将学习该功能）并捕获来自该服务器的所有程序来识别运行的确切程序。 操作IF 没有程序连接到服务器，THEN更改 oracle 可执行文件的权限chmod 0700 $ORACLE_HOME/oracleELSIF 某些程序从服务器进行连接将连接从 UserID/Password 更改为 UserID/PasswordConnect_StringEND IFIF 您频繁从 shell 脚本作为 sqlplus / as sysdba 进行连接 THEN 将其更改为使用 DBAUser/PasswordConnect_StringEND IF1.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/nmbOracle 10g 网格控制代理用其来收集目标服务器上的统计信息。 保持原样。 ./bin/nmoOracle 10g 网格控制代理用其来收集目标服务器上的统计信息。 保持原样。 ./bin/extjob这是 EXTJOB（外部作业，可用来从企业管理器内部执行基于 OS 的程序）的可执行文件。 您应当给予注意。 您是否经常使用外部作业？ 如果不是，那么您甚至不应该保留该可执行文件。 在这种情况下，您可以将其保留在目录中，但要更改权限和所有权关系。 所有者可以是 Oracle 软件所有者（本例为 orasoft），权限应该为 rwx-。$ chown orasoft:oinstall extjob$ chmod 0700 extjob可能还会存在另一个程序 extjobO，它是同一程序的先前编译。 该程序的权限也要改。 $ chown orasoft:oinstall extjobO$ chmod 0000 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 也是一样。 策略既然您了解了每个可执行文件的作用，让我们来看看您如何能够保护数据库基础架构。 大部分策略已经在前面部分的背景信息中进行了讨论。 因此，实际上，您的策略措施是： 1. 删除不需要的文件（例如 lsnrctl0）的所有权限。 2. 限制仅 Oracle 软件具有可执行文件的权限。 3. 如果 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，则必须将权限重设为原来的值。 操作计划 1. 将 oracleO、tnslsnr0 和 lsnrctl0 的权限更改为 0000。 2. 将 tnslsnr 和 lsnrctl 的权限更改为 0700。 3. 您在企业管理器中是否使用外部作业？ IF 没有 THEN 将 extjob 的权限更改为 0000ELSE将 extjob 的权限更改为 0700 并将所有者和组更改为 orasoft 和 oinstall（或任何 Oracle 软件所有者的用户和组）。END IF4. IF 您运行在 Oracle9i 数据库上 THEN您是否使用 Oracle Intelligent Agent？IF 没有 THEN将 dbsnmp 的所有权更改为 orasoft将权限更改为 0700 ELSE无需任何更改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 /nologSQL connect sys/oracle as sysdba这可以防止仍然不知道 SYS 密码的人访问 dba 帐户。 结论如上所示，最重要的是使用 SYS 密码。 您可能需要对连接至 SYS 的脚本做一些改动。 如果您曾经丢失过 SYS 密码，不要担心。 您可以对文件 SQLNET.ORA 中的行进行注释，然后按照传统方式进行连接，即 / as sysdba。操作计划 IF 您在脚本中使用 SYS 连接 THEN将 / as sysdba 更改为 sys/ as sysdba 将 SQLNET.AUTHENTICATION_SERVICES=(NONE) 置于文件 SQLNET.ORA 中ELSE无需任何更改END IF 1.6 创建监听程序密码 背景 黑客惯用的伎俩之一是在监听程序中插入大量文本，从而导致监听程序终止。 数据库可能仍然运行，但是由于监听程序已经停止，因此无法建立任何新的连接，这实际上是一种“拒绝服务”攻击。 为此，黑客可能尝试更改监听程序的属性。 这里较常用的策略是通过 services 命令列出监听程序处理的各种服务。 注意显示多少信息，这些信息可能已足够黑客获得合法访问： LSNRCTL set displaymode verboseLSNRCTL servicesConnecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1521)(IP=FIRST)Services Summary.Service PROPRD has 1 instance(s). Instance PROPRD1, status READY, has 1 handler(s) for thi