Database Reference
In-Depth Information
Make sure that on the receiving server (
lab1-3.sr.ema.ase.net)
the
syslog.conf
file
is set up to receive syslog to a syslog channel (such as
local4.info)
and then store that
syslog to a local file, in this case
oracle.log.
In this example
syslog.conf
would look like
the following when opened in
vi
:
4.
vi /etc/syslog.conf
local4.info /var/log/oracle.log
5.
Run the following command to read this syslog from the centralized syslog server:
tail -f /var/log/oracle.log | grep 'unique_string345'
If there is a problem, check to see that the sender can
nmap
the receiving server to “see” the
syslog daemon. For example:
6.
# nmap -sU -p 514 ael.svr.ase.net
After the OS configuration has been shown to be successfully sending syslog from the local database server OS to
the remote centralized syslog server, you can configure the Oracle database to send its audit trail to syslog. Here is the
process to follow:
1.
Choose an available syslog channel that fits in with your organizational syslog usage. You'll
be configuring Oracle to use that channel to send its audit trail. For this example, we've
chosen
local4.info
as our channel.
Log in to the DB as
SYS
. Issue the following commands to set up syslog to the OS:
2.
alter system set audit_syslog_level='local4.info' scope=spfile;
alter system set audit_sys_operations=true SCOPE=SPFILE;
alter system set audit_trail='OS';
shutdown immediate;
startup;
3.
Verify that the commands have worked as intended. Do that by executing:
sho parameter audit;
To see the individual DBIDs in each log entry for versions prior to 10.2.0.5, you need to
install patch 6755639 (use the same patchid for Linux and Solaris). All versions above
10.2.0.4 come with the DBID improvement included.
The above takes only a short amount of time to do. Because the logs are sent by Oracle using UDP, the syslog
server cannot have any negative effect on the DB server - they are not connected, as they are not using TCP. So from a
change-control perspective, the preceding change is a low-risk one. In fact, sending the logs remotely lowers the risk
of filling up a local disk, so centralized syslogging already makes your server more safe and secure by simply turning it
on, and of course it is free of charge.
