Database Reference
In-Depth Information
Another file that should be considered for advanced state checking is the dsec.bsq:
/home/oracle/app/oracle2/product/12.1.0/dbhome_1/rdbms/admin/dsec.bsq
The .bsq files are called by Oracle to set up the database itself. If these were tampered with, e.g., hidden DBA
account added, then this tampering would affect all subsequent databases created from that Oracle software. The
dsec.bsq file also ends the debate as to whether PUBLIC is a role or a user group, as follows:
root@orlin $ cat /home/oracle/app/oracle2/product/12.1.0/dbhome_1/rdbms/admin/dsec.bsq | grep
'create role public'
create role public enable editions for synonym
The above further exemplifies that safeguarding Oracle DB security is largely the job of root Unix. Therefore, the
segregation between Oracle Unix and root Unix is the foundation for Oracle database security. Thus, it is important to
verify that segregation is watertight.
A relevant example of simple security is remembering to check whether the front door has been left open. It is
surprisingly common for a recently audited DB and application to be vulnerable to this simple check below, often
because the auditor only had DB and ERP skills but was not a *nix technician.
SQL> SELECT UTL_INADDR.get_host_address from dual;
GET_HOST_ADDRESS
--------------------------------------------------
192.168.1.3
[oracle@linuxbox:~] $ssh oracle@192.168.1.3
oracle@192.168.1.33's password: [oracle]
Last login: Sat May 18 21:35:32 2013 from 192.168.1.10
A change of “oracle” *nix password will be required here. A related issue is the lack of profiles on pwfile-managed
users like SYS, which can be solved by forcibly setting the SYS password to a complex value using double quotes to
include special characters such as those below
alter user sys identified by "%^@$*()_+~`-=[{}\|;:,<.>";
Achieving password complexity is a solvable problem. A more intransigent problem is that of maintaining
password uniqueness. Users quite often do not know what makes a password secure. Essentially it is the
unpredictability of the password. Recommendations have been made in the past to check users' password security by
inputting them into Internet web sites that will check the passwords' security for you (SANS Guide v2, page 45), but
most users are not that naive, thankfully. However, the question remains: How do we guarantee that all the passwords
are not the same? We can't see them all, so how do we verify them? This is one reason why password reversing
has a genuine security function. We have shown how to decrypt the DBlink password, and it is easy enough for an
authorized security administrator to use that plaintext password to try to log on as other users on the database to
check that their passwords are indeed different from each other.
Controlling Database Link Permissions
A method of creating database link connections that can then be granted to users is by creating a view in front of the
link. This enables more fine-grained permissions than just private or public. In this example, two roles are created that
can either edit or read through the DBlink.
 
Search WWH ::




Custom Search