Database Reference
In-Depth Information
And an updated local syslog setting that deliberately omitted the new Oracle syslog entry from the local collection
would look like this:
*.info;
local4.none
/localpath/pre-existing_OS_syslog_minus_orasyslog.log
Note that the Oracle syslog on
local4
has been omitted from the
*.info
setting,(which was basically a
“catchall,”) by using the
local4.
none
qualifier to omit the Oracle syslog. This can save production databases from
filling their local disks. In low-volume, high-security circumstances, keeping a local copy of the syslog can be seen as
an additional security feature, in that the two can be compared if there is the possibility that either has been tampered
with. The previous example gives you the choice of keeping syslog local or not.
The ability to omit syslog in this way is not very well known even among SAs, but is very useful for avoiding a
full local disk. Disk filling is the main risk of turning on auditing. The other primary risk is performance degradation,
which in my experience is not that great for OS audit trails, such as syslog. This experience is verified by Oracle's own
performance statistics for native audit, which show that logging through the OS is approximately five times more
performant than logging to the database. The following URL takes you to a website that documents those performance
statistics in more detail:
Alerting to Syslog Content
The following is an example of an Oracle syslog alert using a bash script, which you can call from
cron
as normal:
#!/bin/bash
find /export/oracle_syslog/oracle.log.1 | xargs egrep 'delete |update |insert ' >
/tmp/email_message.txt
SUBJECT="Syslog alert for DML"
# Email To ?
EMAIL="paul.m.wright@ase.com"
# Email text/message
EMAILMESSAGE="/tmp/email_message.txt"
echo "This email contains SQL alerts for insert, updates and deletes" >> $EMAILMESSAGE
# send an email using /bin/mail
/bin/mail -s "$SUBJECT" "$EMAIL" < $EMAILMESSAGE
#/usr/bin/rm /tmp/email_message.txt
Native Intrusion Prevention
Alerting to syslog content can be useful, but most organizations do not want to employ permanent individuals purely
to watch for emails telling them that they have just been hacked. Why? Because it costs money and by that time
it is too late
—the damage has already been done! What is needed is a way to optionally and
safely
interject when
security incidents are occurring. This is where intrusion prevention comes in, also known as “IPS,” where the S is for
system(s). IPS have generally been third-party solutions added onto the OS of a DB server or onto the network where
the databases reside. However, over time the general trend is for security systems to become embedded into the host
system that they were designed to protect. In that vein, we will now write a simple PoC of a native IPS that will block
incoming database links using the inbuilt Oracle tools. By default there is no way to configure Oracle to do this using
the standard commands, so please regard this as a custom improvement.
