Book Image

Oracle 11g Anti-hacker's Cookbook

By : Adrian Neagu
Book Image

Oracle 11g Anti-hacker's Cookbook

By: Adrian Neagu

Overview of this book

For almost all organizations, data security is a matter of prestige and credibility. The Oracle Database is one of the most rich in features and probably the most used Database in a variety of industries where security is essential. To ensure security of data both in transit and on the disk, Oracle has implemented the security technologies to achieve a reliable and solid system. In Oracle 11g Anti-Hacker's Cookbook, you will learn about the most important solutions that can be used for better database security."Oracle 11g Anti-hacker's Cookbook" covers all the important security measures and includes various tips and tricks to protect your Oracle Database."Oracle 11g Anti-hacker's Cookbook" uses real-world scenarios to show you how to secure the Oracle Database server from different perspectives and against different attack scenarios. Almost every chapter has a possible threads section, which describes the major dangers that can be confronted. The initial chapters cover how to defend the operating system, the network, the data and the users. The defense scenarios are linked and designed to prevent these attacks. The later chapters cover Oracle Vault, Oracle VPD, Oracle Labels, and Oracle Audit. Finally, in the Appendices, the book demonstrates how to perform a security assessment against the operating system and the database, and how to use a DAM tool for monitoring.
Table of Contents (16 chapters)
Oracle 11g Anti-hacker's Cookbook
About the Author
About the Reviewers

Enforcing the use of strong passwords and restricting the use of previous passwords

It is essential to establish an effective security policy for Oracle software owner users. In this recipe we will talk about managing complex password rules that can primarily prevent brute force attacks. Restriction of using previous passwords and too similar passwords is an additional security measure which can be implemented to prevent undesired access into the system.

Password rule checking and restriction of the use of previous passwords is performed by Pluggable Authentication Module, or simply known as PAM, discussed in this recipe. In these days PAM is available and used on all major Linux and Unix distributions. The differences in implementation on these platforms are minimal.

Getting ready

All steps will be performed on the database server host nodeorcl1.

How to do it...

  1. As the user root open /etc/pam.d/system-auth for editing. Modify the line that begins with password requisite, with the following line:

    password    requisite try_first_pass retry=3 minlen=12 lcredit=-2 ucredit=-2 dcredit=-1 ocredit=-1
  2. Save and close the file. At this step you can try to set some weak passwords, such as dictionary-based or very short passwords to verify that the defined rules are enforced.

  3. If the password enforcement rules are working, login as the oracle user and change the password to a strong password, such as of24UT()next(1)=2:

    [oracle@nodeorcl1 ~]$ passwd 
    Changing password for user oracle.
    Changing password for oracle
    (current) UNIX password: 
    New UNIX password: 
    Retype new UNIX password: 
    passwd: all authentication tokens updated successfully.
  4. At this step we will set up the restriction for using previous passwords. First create /etc/security/opasswd file and set its permission to 600. This file will retain the used password history for comparisons:

    [root@nodeorcl1 security]# touch /etc/security/opasswd ; chmod 600 /etc/security/opasswd
  5. Open the /etc/pam.d/system-auth file and modify the line added in step 4 by appending the difok parameter and remember parameter at the end of the line beginning with password sufficient as follows:

    password    requisite try_first_pass retry=3 minlen=12 lcredit=-2 ucredit=-2 dcredit=-1 ocredit=-1 difok=6
    password    sufficient md5 shadow nullok try_first_pass use_authtok remember=10
  6. Login as oracle and change the password. Try to set the password as the same password used before. The PAM module will detect that the password is unchanged as we can see from the following listing:

    [oracle@nodeorcl1 ~]$ passwd
    Changing password for user oracle.
    Changing password for oracle
    (current) UNIX password: 
    New UNIX password: 
    Password unchanged
    New UNIX password
  7. Next, type a password with only two characters, difference. We will get a message that will tell us that the password is too similar to the old one:

    [oracle@nodeorcl1 ~]$ passwd
    Changing password for user oracle.
    Changing password for oracle
    (current) UNIX password: 
    New UNIX password: 
    BAD PASSWORD: is too similar to the old one
    Finally use a strong password (Ty%u60i)R_"Wa?) with more than three different characters as follows:
    [oracle@nodeorcl1 ~]$ passwd
    Changing password for user oracle.
    Changing password for oracle
    (current) UNIX password: 
    New UNIX password: 
    Retype new UNIX password: 
    passwd: all authentication tokens updated successfully.
    [oracle@nodeorcl1 ~]$ 


It is highly recommended to perform security assessments regularly on your system. To check your real password's strength you should try to use a password cracker.

For a list and description of some of the best available password crackers consult

Some recommendations for generating strong passwords:

  • Strong passwords should contain lowercase, uppercase, special characters (such as@,&,},?, and !), high ASCII code characters (such as and ♫), or unicode characters (such as ﭏ, and ﭚ).
  • Divide your password in to more than 2 or 3 groups and use special characters, high ASCII codes, or Unicode characters as delimiters for groups (for example: u6Yi5@My1k!P;m8U where @,!, and ; are delimiters).

  • Use more than 8 characters; 15-20 is a good number to prevent brute-force attacks. A brute force cracker program will need exponentially more time to break a password directly proportional with the password length.

  • Do not use more that 40 percent numbers in your password.

  • Avoid dictionary words.

How it works...

The Linux PAM module checks the password against dictionary words and other constraints using minlen, lcredi, ucredi, dcredit, and ocredit parameters, which are defined as follows:

  • minlen: Minimum length of password. In our case must be 12.

  • lcredit: Minimum number of lower case letters. In our case must be 2.

  • ucredit: Minimum number of upper case letters. In our case must be 2.

  • dcredit: Minimum number of digits. In our case must be 1.

  • ocredit: Minimum number of other characters. In our case must be 1.

To restrict the use of a previous password, the system must save the used passwords to use them for comparison. The file used for storing previous passwords is called opasswd. In case it does not exist, it must be created in the /etc/security directory. The restrict enforcement is performed in stacking mode by combining the remember parameter of the module with the difok parameter of the module. The remember parameter will configure the number of previous passwords that cannot be reused, and difok is used to specify the number of characters that must be different between the old and the new password.

PAM configuration files on Red Hat Linux and variants are located in /etc/pam.d directory. The service shares the same name as the application designed to authenticate; for example the PAM configuration file for the su command is contained in a file with the same name (/etc/pam.d/su).

Next, we will take a look at the PAM configuration file format. To understand this we will use the line corresponding to the password module modified in this recipe:

password    requisite try_first_pass retry=3 minlen=12 lcredit=-2 ucredit=-2 dcredit=-1 ocredit=-1

The first directive is the module type. A brief summary of module types and how PAM enforces the rules is as follows:

Module type



Account modules check that the specified account is a valid authentication target. Here we may have various conditions such as time of the day, account expiration, and that the user has access to the requested service.


These modules verify the user's identity. The identity is verified by checking passwords or other authentication variables, such as a keyring.


These modules are responsible for updating passwords and checking password enforcement rules.


These modules check the actions performed after the users are authenticated at the beginning and end of the session.

The second directive from the PAM configuration files is represented by control flags. These flags tell what to do with the result returned by a module. All PAM modules return a success or failure result when called.

Control flag



If this control flag is used, the result returned by the module must be always successful in order for the authentication process to succeed. If the return value represents a failure, then the user is not notified until the results of all module tests are complete.


This is similar to required, but if the test fails the user is immediately notified and no other module tests are performed.


If this control flag is used and the result fails, it is ignored. If it has a return value of success and it is used with other modules that have the required flag, and these also have a return value of success, then no other results are required and the user is authenticated.


The result of modules flagged with optional is ignored until no other modules reference the interface.

The third directive is the pluggable module. The next parameters represent the arguments passed to the pluggable module.

There is more...

You can bypass PAM rules for password enforcement as root; hence the passwords to comply with the enforcement rules must be changed by each user.

Performing a security assessment on current passwords with the John the Ripper password cracker tool

  1. Download and build John the Ripper from source code as follows:

    [root@nodeorcl1 run]# make clean linux-x86-64
  2. Unshadow /etc/password and /etc/shadow into a separate file, /tmp/passwd.db:

    [root@nodeorcl1 run]# ./unshadow /etc/passwd /etc/shadow > /tmp/passwd.db
  3. Add the file as an argument and perform a simple password cracking session:

    [root@nodeorcl1 run]# ./john /tmp/passwd.db
  4. The weak passwords are found instantaneously:

    Loaded 3 password hashes with 3 different salts (FreeBSD MD5 [32/64 X2])
    testuser         (testuser)
    root1234         (root)
    guesses: 3  time: 0:00:00:00 100% (1)  c/s: 2150  trying: 
    Root999 - root1234
    Use the "--show" option to display all of the cracked passwords reliably
    [root@nodeorcl1 run]#