Tuesday, 23 October 2007

Installing Oracle Database 11g on Linux

To install the Oracle software, you must use the Oracle Universal installer.

Step- 1. For this installation, you need either the DVDs or a downloaded version of the DVDs. In this tutorial, you install from the downloaded version. From the directory where the DVD files were unzipped, open a terminal window and enter the following:


Step- 2. The product you want to install is Oracle Database 11g. Make sure the product is selected and click Next.

Step- 3. You will perform a basic installation with a starter database. Enter orcl for the Global Database Name and oracle for Database Password and Confirm Password. Then, click Next.

Step- 4. You need to specify your Inventory directory. The location should be set to /u01/app/oracle/oraInventory. Accept the default Operating System group name, oinstall. Then, click Next.

Step- 5. The installer now verifies that the system meets all the minimum requirements for installing and configuring the chosen product. Please correct any reported errors before continuing. When the check successfully completes, click Next.

Step- 6. Oracle Configuration Manager allows you to associate your configuration information with your Metalink account. You can choose to enable it on this window. Then, click Next.

Step- 7. Review the Summary window to verify what is to be installed. Then, click Install.

Step- 8. The progress window appears.

Step- 9. The Configuration Assistants window appears.

Step- 10. Your database is now being created.

Step- 11. When the database has been created, you can unlock the users you want to use.

Click OK.

Step- 12. You need to execute orainstRoot.sh and root.sh as the root user.

Step- 13. Open a terminal window and enter the following commands. Follow the prompts as instructed.

su -

cd /u01/app/oracle/oraInventory


cd ../product/11.1.0/db_1




Step- 14. Switch back to the Universal Installer and click OK.

Step- 15. Click Exit. Click Yes to confirm exit.

Testing Your Installation

To test that your installation completed successfully, perform the following steps:


Open a browser and enter the following URL:


where <hostname> should be changed to your machine name, IP address, or localhost.

Because Enterprise Manager Database Control is a secure site, you need a certificate. Select the Accept this certificate permanently option, and then click OK.


Enter system as the User Name and oracle as the Password, and then click Login.


The Database Control Home Page appears. Your installation was successful.

Thursday, 18 October 2007

Secure your Linux server using password policy

I think its most important to secure our linux servers.There are many steps to secure our servers. Password security is one of them. I discus here 3 steps of secure our servers by using password. The steps are :

1) Enabling Password Aging
2) Enforcing Stronger Passwords
3) Restricting Use of Previous Passwords

Enabling Password Aging

In general I do not recommend that the system enforces password expiration for system and shared accounts. This could lead to outages if an application's account expires:
# su oracle -c id
You are required to change your password immediately (password aged)
Changing password for test
(current) UNIX password:
Rather a corporate policy should govern password changes for system and shared accounts. But for individual user accounts the system should expire the passwords automatically. The following example shows how password expiration can be setup for individual user accounts.

The following files and parameters in the table are used when a new account is created with the useradd command. These settings are recorded for each user account in the /etc/shadow file. Therefore, make sure to configure the following parameters before you create any user accounts using the useradd command:

/etc/login.defs PASS_MAX_DAYS 60 Maximum number of days a password is valid.
/etc/login.defs PASS_MIN_DAYS 7 Minimum number of days before a user can change the password since the last change.
/etc/login.defs PASS_MIN_LEN n/a This parameter does not work. It is superseded by the PAM module "pam_cracklib". See Enforcing Stronger Passwords for more information.
/etc/login.defs PASS_WARN_AGE 7 Number of days when the password change reminder starts.
/etc/default/useradd INACTIVE 14 Number of days after password expiration that account is disabled.
/etc/default/useradd EXPIRE
Account expiration date in the format YYYY-MM-DD.

Ensure that the above parameters are changed in the /etc/login.defs and /etc/default/useradd files.

When a user account is created using the useradd command, the parameters listed in the above table are recorded in the /etc/shadow file in the following fields:

To create a new user account you can execute the following command:
useradd -c "Test User" -g users test
The -g option specifies the primary group for this account:
# id test
uid=509(test) gid=100(users) groups=100(users)

The settings in /etc/login.defs and /etc/default/useradd are recorded for the test user in the /etc/shadow file as follows:
# grep test /etc/shadow

You can change the password aging any time using the chage command.

To disable password aging for system and shared accounts, you can run the following chage command:
# chage -M 99999 

To get password expiration information:
# chage -l 
For example:
# chage -l test
Minimum: 7
Maximum: 60
Warning: 7
Inactive: 14
Last Change: Jan 11, 2005
Password Expires: Mar 12, 2005
Password Inactive: Mar 26, 2005
Account Expires: Never

Enforcing Stronger Passwords

Practical Considerations

On an audited system it is important to restrict people from using simple passwords that can be cracked too easily. However, if the passwords being enforced are too strong, people will write them down. Strong passwords that are written down are not much safer than weak passwords. Some will argue that strong passwords protect you against e.g. Dictionary Attacks and you can defeat it by locking the accounts after a few failed attempts. However, this is not always an option. As I will show at Locking User Accounts After Too Many Login Failures, locked system accounts could bring down your applications and systems which would be nothing short of a denial of service attack.

Undoubtedly, it is important to practise safe password management. In my opinion, a password should have at least one digit number, one other character, and one upper case letter. But keep in mind not to make it overly complicated.

How to Enforce Stronger Passwords

The pam_cracklib module checks the password against dictionary words and other constraints. Unfortunately, however, the original Linux PAM module pam_cracklib uses a credit mechanism. E.g. if you define password length minlen=10, then you will get 1 credit for e.g. using a single digit number in your password if you defined dredit=1. This means that pam_cracklib will accept a password of the length of minlen-credit. If you don't use a digit number, then the minimum length of the password would be minlen. There was no way to tell the module that a password _must_ include a digit number.

Back in 2000 I wrote a patch for the pam_cracklib module where you can assign negative values to the pam_cracklib parameters lcredit, ucredit, dcredit, and ocredit. Using negative values will disable the credit mechanism. For example, if you define dredit=-1, then the module will only accept a password if it includes at least one digit number and if the password has a length of at least minlen.

Red Hat has finally applied my pam_cracklib patch and you don't have to patch the pam_cracklib module any more. The new pam_cracklib feature works in Red Hat Enterprise Linux 4 and Red Hat Fedora Core 3. This feature is now also included with the Red Hat Enterprise Linux 3 Update 4 and Red Hat Enterprise Linux 2.1 Update 6 release. If the Linux distribution you are using does not use the patched pam_cracklib module yet, you can find the procedure for patching pam_cracklib here.

In the following example I'll assume that you are using the new pam_cracklib module, or that you patched the module if your Linux distribution doesn't include the patched version yet.

The following example shows how to enforce the following password rules:
- Minimum length of password must be 8
- Minimum number of lower case letters must be 1
- Minimum number of upper case letters must be 1
- Minimum number of digits must be 1
- Minimum number of other characters must be 1

Minimum length of password is 8
Minimum number of lower case letters is 1
Minimum number of upper case letters is 1
Minimum number of digits is 1
Minimum number of other characters is 1

To setup these password restrictions, edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib arguments highlighted in blue:
auth        required      /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so

Now verify that the new password restrictions work for new passwords. Simply login to a non-root account and change the password using the passwd command. Note that the above requirements are not enforced if you run the passwd command under root.

NOTE: The /etc/pam.d/system-auth PAM configuration file is auto-generated and contains records which dictate a generic authentication scheme. Keep in mind that authconfig might clobber some changes you made. Since I never run authconfig I usually make changes to this file because it's used by many PAM aware applications. Otherwise I'd have to make changes to many configuration files. Changing system-auth is usually the preferred method. You might even want to disable all execution bits from the /usr/bin/authconfig binary to prevent authconfig from clobbering your changes.

Restricting Use of Previous Passwords

The pam_unix module parameter remember can be used to configure the number of previous passwords that cannot be reused. And the pam_cracklib module parameter difok can be used to specify the number of characters hat must be different between the old and the new password.

In the following example I will show how to tell the system that a password cannot be reused for at least 6 months and that at least 3 characters must be different between the old and new password.

Remember that in the chapter Enabling Password Aging we set PASS_MIN_DAYS to 7, which specifies the minimum number of days allowed between password changes. Hence, if we tell pam_unix to remember 26 passwords, then the previously used passwords cannot be reused for at least 6 months (26*7 days).

Here is an example. Edit the /etc/pam.d/system-auth file and add/change the following pam_cracklib and pam_unix arguments:
auth        required      /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 difok=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow remember=26
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so

If the /etc/security/opasswd doesn't exist, create the file.
# ls -l /etc/security/opasswd
-rw------- 1 root root 0 Dec 8 06:54 /etc/security/opasswd