Oracle 审计参数AUDIT_SYSLOG_LEVEL介绍

文档中描述的审计参数AUDIT_SYSLOG_LEVEL比较模糊,仅有几处提及,且其实际功能要较文档描述的更强大。

数据库中由SYS用户或其他管理员用户所作的操作均可以被审计且记录到由root用户拥有的系统级日志中。这样就可以避免有人使用Oracle的OS账户修改普通审计日志删除相关操作信息。启用(AUDIT_TRAIL=OS)在Oracle审计目录中记录日志或启用 (AUDIT_TRAIL=DB)在数据库中记录审计信息都是不妥当的,显然DBA总是可以修改它们。通过UNIX系统级的日志组件来进行审计对防止黑客侵入和“内鬼“捣乱都很有效。

结合UNIX中的SYSLOG组件记录审计信息是Oracle 10g的一个新特性。该组件包括一个守护进程(daemon)名叫syslogd(你可以通过man syslogd查询其相关手册),该进程用以接受由应用程序调用syslog的C函数库所发送的日志信息。Syslogd服务(service)的配置文件一般是/etc/syslog.conf,日志信息一般被记录在/var/log或/var/adm视乎不同的UNIX发行版本。日志文件名由相关组件名,重要性和级别组成。在/etc/syslog.conf每条记录为特定的组件与重要性指定文件名。在该配置文件中加入记录:user.notice  /var/log/oracle_dbms,并使syslogd进程重启,接下来修改Oracle 参数 AUDIT_SYSLOG_LEVEL=user.notice,则相关的审计记录将出现在文件/var/log/oracle_dbms中。

在UNIX系统上,以SYSDBA或SYSOPER权限进行的CONNECT,STARTUP与SHUTDOWN操作均会被无条件地记录到$ORACLE_HOME/rdbms/audit或AUDIT_FILE_DEST指定的目录中,并使用扩展名为.aud。 Oracle 9i以后版本中通过设置AUDIT_SYS_OPERATIONS=TURE可以记录不限于CONNECT,STARTUP,SHUTDOWN的以SYSDBA或SYSOPER进行的操作。

windows Oracle audit

windows Oracle audit

当AUDIT_SYSLOG_LEVEL参数与AUDIT_SYS_OPERATIONS参数被结合使用时,任何以SYS运行的SQL和PL/SQL均使用syslog组件被审计记录。 由于syslog所使用的文件是root用户拥有的,一般dba是不能获得root账号的,故dba无法修改相关文件。当然,这也预示当主机被侵入时,只要不是使用root账户,其相关的操作仍被记录。

在Windows平台上,AUDIT_SYSLOG_LEVEL参数和AUDIT_FILE_DEST参数没有作用,因为Windows使用事务记录服务(事务管理器)作为系统级审计。如同UNIX一样,CONNECT,STARTUP,SHUTDOWN 操作是无条件记录的。当设置AUDIT_SYS_OPERATIONS=TURE时,SYSDBA或SYSOPER的其他操作也被记录到事务管理器中,你可以通过 START > CONTROL PANEL > Administrative Tools > Event Viewer找到事务管理器。其中日志分类为应用程序(APPlication)来源(SOURCE)为oracle.ORACLE_SID形式。

以下为Oracle Database reference 10g Release 2手册中关于AUDIT_SYSLOG_LEVEL的解释

AUDIT_SYSLOG_LEVEL enables OS audit logs to be written to the system via the syslog utility, if the AUDIT_TRAIL parameter is set to OS. The value of facility can be any of following : USER,LOCAL-LOCAL7,SYSLOG,DAEMON,KERN,MAIL,AUTH,LRP,NEW,UUCP or CRON. The value of level can be any of following : NOTICE,INFO,DEBUG,WARNING,ERR,CIRT,ALERT,EMERG.

在Solaris10和 Red Hat Linux系统上的测试说明文档的解释是不准确的:

1.  AUDIT_SYSLOG_LEVEL 独立于AUDIT_TRAIL, 当设置了AUDIT_SYSLOG_LEVEL而AUDIT_TRAIL为默认值 NONE时, CONNECT,STARTUP,与SHUTDOWN信息始终由SYSLOG记录。

2.  同时设置AUDIT_SYSLOG_LEVEL与AUDIT_SYS_OPERATIONS=TURE 会将SYSDBA 或SYSOPER权限执行的任何操作通过SYSLOG记录,即便AUDIT_TRAIL=NONE

3.  仅特定的组件与级别组合可正常使用。 不适用的组合会引起”ORA-32028:Syslog facility or level not recognized” 错误,可能导致数据库无法启动。

转载请注明源地址: www.askmaclean.com

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Comments

  1. admin says:

    Applies to:
    Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 11.1.0.7
    Information in this document applies to any platform.
    Oracle Server Enterprise Edition – Version: 10.2.0.1 to 11.1.0.7
    Goal
    The present note provides an example about how to set the AUDIT_SYSLOG _LEVEL Parameter.
    Solution

    1) AUDIT_SYSLOG_LEVEL parameter. When the AUDIT_TRAIL parameter is set to OS, writes SYS and standard operating system audit records to the system audit log using the syslog utility.

    To enable syslog auditing, you assign a value of OS to the AUDIT_TRAIL initialization parameter, as described in “Setting the AUDIT_TRAIL Initialization Parameter”. You must also manually add the AUDIT_SYSLOG_LEVEL parameter to the database’s initialization parameter file, init.ora. You assign to the AUDIT_SYSLOG_LEVEL parameter a facility and priority in the format AUDIT_SYSLOG_LEVEL=facility.priority. The facility argument describes the part of the operating system that is logging the message while the priority argument defines the severity of the message. The syslog daemon compares the value assigned to the facility argument of the AUDIT_SYSLOG_LEVEL parameter with the syslog.conf file in order to determine where to log information. For example, the following statement identifies the facility as local1 with a priority level of warning:

    AUDIT_SYSLOG_LEVEL=local1.warning

    Setting the AUDIT_SYSLOG_LEVEL initialization parameter to the default value
    (NONE) will result in DBAs gaining access to the OS audit records.

    2) To enable syslog auditing, follow these steps:

    2.1) Assign a value of OS to the AUDIT_TRAIL initialization parameter:

    For example:

    SQL> ALTER SYSTEM SET AUDIT_TRAIL=OS SCOPE=SPFILE;

    2.2) Also set the AUDIT_SYSLOG_LEVEL parameter :

    SQL> ALTER SYSTEM SET AUDIT_SYSLOG_LEVEL=”local1.warning” SCOPE=SPFILE;

    Set the AUDIT_SYSLOG_LEVEL parameter to specify a facility and priority in the format AUDIT_SYSLOG_LEVEL=facility.priority.

    facility: Describes the part of the operating system that is logging the message. Accepted values are user, local0–local7, syslog, daemon, kern, mail, auth, lpr, news, uucp, and cron.

    The local0–local7 values are predefined tags that enable you to sort the syslog message into categories. These categories can be log files or other destinations that the syslog utility can access. To find more information about these types of tags, refer to the syslog utility MAN page.

    priority: Defines the severity of the message. Accepted values are notice, info, debug, warning, err, crit, alert, and emerg.

    The syslog daemon compares the value assigned to the facility argument of the AUDIT_SYSLOG_LEVEL parameter with the syslog.conf file to determine where to log the information.

    For example, the following statement identifies the facility as local1 with a priority level of warning:

    AUDIT_SYSLOG_LEVEL=local1.warning

    See Oracle Database Reference for more information about AUDIT_SYSLOG_LEVEL.

    2.3) Add the audit file destination to the syslog configuration file /etc/syslog.conf.

    For example, assuming you had set the AUDIT_SYSLOG_LEVEL to local1.warning, enter the following:

    local1.warning /var/log/audit.log

    This setting logs all warning messages to the /var/log/audit.log file.

    Also pre-create the file as follows (as root):

    # touch /var/log/audit.log

    2.4) Restart the syslog logger:

    $/etc/rc.d/init.d/syslog restart

    Now, all audit records will be captured in the file /var/log/audit.log through the syslog daemon.

    After this, when the user selects from a table TEST and the operation gets audited, the following informations will be added to the audit.log file:

    Sep 28 11:37:24 oracle Oracle Audit[23714]: SESSIONID: “24523”
    ENTRYID: “57” STATEMENT: “8” USERID: “SCOTT” USERHOST: “ro-rac3”
    TERMINAL: “pts/2” ACTION: “103” RETURNCODE: “0” OBJ$CREATOR: “SCOTT” OBJ$NAME:
    “TEST” SES$ACTIONS: “———S——”
    SES$TID: “154816” OS$USERID: “oracle”

    2.5) Restart the database instance:

    CONNECT SYS / AS SYSOPER
    Enter password: password
    Connected.
    SQL> SHUTDOWN;
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL> STARTUP;
    ORACLE instance started.

    Comments

    The changes made as a result of the fix to unpublished bug 4085593 (included in the patches referenced from Note 731908.1) cause the following behaviour:

    When AUDIT_TRAIL=XML (or XML,EXTENDED) and AUDIT_SYSLOG_LEVEL is set, mandatory and SYS audit records are written to SYSLOG files and regular audit records are written to XML format ted OS files.

    If the logfile becomes too large and Oracle cannot write to it anymore the following actions need to be taken:

    1. stop database(s),
    2. login as root
    3. Stop syslogd
    4. clean or archive audit data
    5. restart syslogd
    6 start database

    To avoid this situation it is possible to configure the logrotate facility. This allows automatic removal and rotation of the log files. Compression can be activated by editing the logrotate.conf file and adding the compress option. For more informations see the manual for logrotate.

  2. admin says:

    Applies to:
    Oracle Server – Enterprise Edition – Version: 10.2.0.3 to 11.1.0.7 – Release: 10.2 to 11.1
    Oracle Audit Vault – Version: 10.2.3 to 10.2.3]
    Information in this document applies to any platform.
    Purpose
    This document briefly introduces the new DBMS_AUDIT_MGMT package that is used by Audit Vault to manage and purge audit data. It is intended to provide references to the relevant patches and documentation.
    Scope and Application
    The requirement for the introduction of this package came from Audit Vault. It is currently not supported to use the DBMS_AUDIT_MGMT package outside of Audit Vault. Its features include the purge of audit records and can be used to move the audit tables AUD$ and FGA_LOG$ to another tablespace. It can also be used to purge OS audit files including XML files.The Audit Trail Cleanup functionality will be available with patchset 11.1.0.7, this means 11.1.0.7 databases do not need additional patches to become a source of an Audit Vault. The package is documented in the Audit Vault 10.2.3 Admin Guide. Oracle will not be supporting the DBMS_AUDIT_MGMT in versions 9.2.0.x or 10.1.0.x

    New Feature DBMS_AUDIT_MGMT To Manage And Purge Audit Information
    References to Patches

    The DBMS_AUDIT_MGMT package will become available in Oracle 11.2, and in patchset 11.1.0.7 but has also been made available as a separately installable patch for other versions, here are the references:

    RDBMS version 11.1.0.6 :

    There is no backport that supplies DBMS_AUDIT_MGMT on 11.1.0.6. Please upgrade to the 11.1.0.7 patchset in order to use this functionality.

    RDBMS version 10.2.0.3 :

    Patch 6989148 MLR ON TOP OF 10.2.0.3 FOR AUDIT TRAIL CLEAN-UP

    Other merge patches that include this fix available on some platforms:

    Patch 7460180 MERGE LABEL REQUEST ON TOP OF 10.2.0.3 FOR BUGS 6041317 6989148
    Patch 7428689 MERGE LABEL REQUEST ON TOP OF 10.2.0.3 FOR BUGS 6989148 7129285
    Patch 7557322 MERGE LABEL REQUEST ON TOP OF 10.2.0.3 FOR BUGS 7460180 6115797 5679561 5711129
    Patch 9100457 MERGE REQUEST ON TOP OF 10.2.0.3.0 FOR BUGS 7311381 7428689 8567112 5548510

    RDBMS version 10.2.0.4 :

    Patch 6996030 MLR ON TOP OF 10.2.0.4 FOR AUDIT TRAIL CLEAN-UP

    Other merge patches that include this fix available on some platforms:

    Patch 7506476 MERGE LABEL REQUEST ON TOP OF 10.2.0.4 FOR BUGS 5679561 6996030
    Patch 7685199 MERGE LABEL REQUEST ON TOP OF 10.2.0.4 FOR BUGS 5679561 6996030 7581770
    Patch 7714556 MERGE LABEL REQUEST ON TOP OF 10.2.0.4 FOR BUGS 7006588 6996030
    Patch 8198020 MERGE LABEL REQUEST ON TOP OF 10.2.0.4 FOR BUGS 6133008 7685199
    Patch 8295186 MERGE LABEL REQUEST ON TOP OF 10.2.0.4 FOR BUGS 7652915 7685199
    Patch 8648568 MERGE LABEL REQUEST ON TOP OF 10.2.0.4 FOR BUGS 6805009 7685199
    Patch 8605144 MERGE LABEL REQUEST ON TOP OF 10.2.0.4 FOR BUGS 7592082 7685199
    Patch 9433518 MERGE REQUEST ON TOP OF 10.2.0.4.0 FOR BUGS 8605144 8254572
    Patch 9577923 MERGE REQUEST ON TOP OF 10.2.0.4.0 FOR BUGS 8295186 8365964
    Patch 9711694 MERGE REQUEST ON TOP OF 10.2.0.4.0 FOR BUGS 8605144 7023214
    Patch 9729279 MERGE REQUEST ON TOP OF 10.2.0.4.0 FOR BUGS 8605144 9545854
    Patch 9761176 MERGE REQUEST ON TOP OF 10.2.0.4.0 FOR BUGS 9070891 9442339

    RDBMS version 10.2.0.4.2:

    Patch 9064839 MERGE LABEL REQUEST ON TOP OF 10.2.0.4.2 FOR AUDIT TRAIL CLEAN-UP

    RDBMS version 10.2.0.4.3:

    Patch 9628655 MERGE REQUEST ON TOP OF 10.2.0.4.3 FOR BUGS 9466949 6991606

    RDBMS version 10.2.0.4.4:

    Patch 9650152 MERGE REQUEST ON TOP OF 10.2.0.4.4 FOR BUGS 9589005 6805009 6991606

    On Windows this fix is included in the Windows bundles since 10.2.0.4 bundle 23. Please refer to note 161549.1 for advise on the latest bundle. Note that on Windows the auditing behavior doesn’t change unless Audit Trail Cleanup is initialized with DBMS_AUDIT_MGMT.INIT_CLEANUP.

    Please see the associated READMEs for patch instructions, besides the introduction of DBMS_AUDIT_MGMT these patches also fix a number of related audit problems and are therefore recommended to apply when your database will become an Audit Vault source. Of the collection of changes to auditing as referenced from note 6023472.8 a notable change is that there will be no longer any updates to AUD$ .

    Exceptions Introduced by the new DBMS_AUDIT_MGMT package.

    The new package DBMS_AUDIT_MGMT introduces a new range of ORA errors that may be raised as exceptions, these are referenced in note 602050.1 . For the backported version of dbms_audit_mgmt available with the patches listed above for technical reasons development did not include any updated message files so this means if any of the new exceptions is raised you will see the error being displayed as follows:

    BEGIN DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY (12,21,true); END;

    *
    ERROR en l�nea 1:
    ORA-46257: Message 46257 not found; product=RDBMS; facility=ORA
    ; arguments: [CLEAN_UP_INTERVAL]
    ORA-06512: en “SYS.DBMS_AUDIT_MGMT”, l�nea 41
    ORA-06512: en “SYS.DBMS_AUDIT_MGMT”, l�nea 1569
    ORA-06512: en l�nea 1

    This is expected behaviour and you will have to lookup the error in note 602050.1, you can substitute ‘%s’ with the arguments that are passed, so in this example the error means:

    “Property CLEAN_UP_INTERVAL cannot be cleared”

  3. admin says:

    Applies to:
    Oracle Server – Enterprise Edition – Version: 10.2.0.4 to 11.1.0.7
    Information in this document applies to any platform.
    Goal

    When using the syslog daemon to isolate the audit output from the owner of the Oracle software, it is not possible to make the difference between the various audit files when coming from more than one database because, unfortunately, the audit files don’t include neither the database id nor the database name.

    This problem is addressed has been addressed in an Enhancement Request and, starting with 11.2, the database id will be introduced into the audit log of syslog.
    Solution

    This problem has been investigated in Enhancement Request:

    BUG:6755639 – ADD DATABASE IDENTIFIER TO AUDIT TRAIL WHEN WRITING TO SYSLOG

    and is now backportable on the currently supported releases (10.2.0.4 and 11.1.0.7 at the time when the note was written). The backport is especially recommended when the number of databases installed on a server is larger than 8, because the below workaround is very useful for maximum 8 databases/server, given the limitation of 8 services the syslog daemon can serve.

    Alternatively, the following workaround can be used:

    First of all, using the syslog daemon to capture and store the audit output should be set in the database using the audit_trail and audit_syslog_level parameter, as follows:
    *.AUDIT_TRAIL=OS
    *.AUDIT_SYSLOG_LEVEL=’facility.priority’

    It is in more detail documented in:
    Note 553225.1 How To Set the AUDIT_SYSLOG _LEVEL Parameter?
    Secondly, the facility.priority is specified in the syslog.conf file, the file which configures the syslog daemon. The outputs are:
    facility.priority .

    An example for this would be:
    init.ora settings:
    *.AUDIT_TRAIL=OS
    *.AUDIT_SYSLOG_LEVEL=level1.info

    syslog.conf settings:
    local1.info /var/log//oracle_audit.log

    Given the above, it is easy to separate the outputs of different databases in different directories or in different files and hence be able to make the distinction which is which. The first database would have the AUDIT_SYSLOG_LEVEL=loca1.info, the second to local2.info and so on, with 7 such allowed facilities, while in the syslog.conf file the various facilities to point to various locations, eg:
    local1.info /var/log//oracle_audit.log
    local2.info /var/log//oracle_audit.log

    In this way, one can know what is the output from one database and what is the output from another database.

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569