SecureDBA

Securing Oracle Enterprise Linux - Part 6 - Minimize Network Services

This is the sixth in a series of posts that describe how to secure Oracle Enterprise Linux. These posts are based on the Center for Internet Security Secure Base Line for Red Hat Enterprise Linux 5 but have been verified against Oracle Enterprise Linux (OEL) 5.5. You can download OEL here.

In Part 1 we reviewed a secure partitioning strategy, in Part 2 we performed a  minimal install, in Part 3 we performed some mandatory housekeeping before starting the hardening process, in Part 4 we secured ssh and in Part 5 we enabled system accounting. In this post we minimize network services.

A Word of Caution

The actions outlined in these posts have been performed on a clean install of OEL 5.5 exactly as documented in these posts. If you are contemplating taking these actions on an existing server, please take appropriate precautions such as:

• Backing up the server
• Reviewing the content of all scripts before running them
• Testing the actions on a non-production server

The hardening steps in these posts were performed in the order posted. Performing these steps in a different order my result in unpredictable behavior. Also, all these scripts MUST be run as root, not as sudo.

Disable Standard Services

If any of the following services are configured in /etc/xinetd.d, then the script below will disable them using chkconfig. For services that do not exist, the script prints an OK message:

• amanda
• chargen
• chargen-udp
• cups
• cups-lpd
• daytime
• daytime-udp
• echo
• echo-udp
• eklogin
• ekrb5-telnet
• finger
• gssftp
• imap
• imaps
• ipop2
• ipop3
• klogin
• krb5-telnet
• kshell
• ktalk
• ntalk
• rexec
• rlogin
• rsh
• rsync
• talk
• tcpmux-server
• telnet
• tftp
• time-dgram
• time-stream
• uucp

Administrators that determine some of these services are needed can either modify the script or re-enable them after the script completes.

If you installed OEL according to these posts then the following services will be disabled:

• eklogin
• ekrb5-telnet
• gssftp
• klogin
• krb5-telnet
• kshell
• rsync

You can download the script here: cis_script2_xinetd.sh (1.0K)

Implement TCP Wrappers

TCP Wrappers are implemented by configuring the /etc/hosts.allow and /etc/hosts.deny files. TCP Wrappers rules work by first checking hosts.allow and then checking hosts.deny and stopping on the first match. If hosts.deny is configured before host.allow then the server will block all traffic from network hosts.

Configure /etc/hosts.allow

The following script will loop through the output of ifconfig and create a single hosts.allow entry which will allow all services from all local networks.

For example, on a simple configuration with a single IP address in the 192.168.1.0 / 255.255.255.0 range  (plus a local loopback), the script adds the following entry to hosts.allow:

ALL: localhost, 192.168.1

The script assumes IPv4 and a subnet mask of 255.255.255.0. IPv6 configurations are beyond the scope of this post. See the CIS documentation referenced at the top of this post for additional information. If the server is configured for other subnet masks, the hosts.allow file will need to be manually modified after running this script.

Download cis_script3_hosts.allow.sh (0.4K)

 

Configure /etc/hosts.deny

Warning: Do not proceed with this section until you have configured hosts.allow as above.

The following script will insert a single line in /etc/hosts.deny as follows:

ALL: ALL

Download cis_script4_hosts.deny.sh (0.3K)

 

Enable These Services Only If Mission Critical

The services described in this section all have security risks and/or flaws. Enable them only if they are mission critical and there are not other alternatives available.

telnet

Enable by running the following:

chkconfig telnet on

 

ftp

Enable by running the following:

chkconfig --levels 35 vsftpd on

 

rlogin/rsh/rcp

Enable by running the following:

chkconfig login on

chkconfig rlogin on

chkconfig rsh on

chkconfig shell on

 

tftp

tftp is not installed by default, so first install the tftp package.

Next run the following script which uses chkconfig to turn on tfpt, then sets the permissions on /tftpboot or creates it with the proper permissions if it does not exist.

Download cis_script5_tftp.sh (0.2K)

Securing Oracle Enterprise Linux - Part 5 - Enable System Accounting

This is the fifth in a series of posts that describe how to secure Oracle Enterprise Linux. These posts are based on the Center for Internet Security Secure Base Line for Red Hat Enterprise Linux 5 but have been verified against Oracle Enterprise Linux (OEL) 5.5. You can download OEL here.

In Part 1 we reviewed a secure partitioning strategy, in Part 2 we performed a  minimal install, in Part 3 we performed some mandatory housekeeping before starting the hardening process and in Part 4 we secured ssh. In this post we enable system accounting.

A Word of Caution

The actions outlined in these posts have been performed on a clean install of OEL 5.5 exactly as documented in these posts. If you are contemplating taking these actions on an existing server, please take appropriate precautions such as:

• Backing up the server
• Reviewing the content of all scripts before running them
• Testing the actions on a non-production server

The hardening steps in these posts were performed in the order posted. Performing these steps in a different order my result in unpredictable behavior. Also, all these scripts MUST be run as root, not as sudo.

Enable System Accounting

The system accounting function is enabled by the sysstat package. If you have performed a clean install of OEL as outlined in this series of posts than this package is already installed. Otherwise, install it if it does not exist.

System accounting provides for the regular collection of performance data and enables such commands as sar and iostat to report on this data.

Regular review of performance data provides a monitoring security control because it may be used to identify suspicious activity.

Securing Oracle Enterprise Linux - Part 4 - Hardening ssh

This is the fourth in a series of posts that describe how to secure Oracle Enterprise Linux. These posts are based on the Center for Internet Security Secure Base Line for Red Hat Enterprise Linux 5 but have been verified against Oracle Enterprise Linux (OEL) 5.5. You can download OEL here.

In Part 1 we reviewed a secure partitioning strategy, in Part 2 we performed a  minimal install and in Part 3 we performed some mandatory housekeeping before starting the hardening process. In this post we will begin the hardening process by securing ssh.

 

A Word of Caution

The actions outlined in these posts have been performed on a clean install of OEL 5.5 exactly as documented in these posts. If you are contemplating taking these actions on an existing server, please take appropriate precautions such as:

 

• Backing up the server
• Reviewing the content of all scripts before running them
• Testing the actions on a non-production server

The hardening steps in these posts were performed in the order posted. Performing these steps in a different order my result in unpredictable behavior. Also, all these scripts MUST be run as root, not as sudo.

 

Create Non-root User(s)

Part of hardening ssh will be disabling remote login as root. Therefore, it is critical that you have at least one non-root user on the server (especially if you are hardening from a remote ssh session, or you will be locked out of the server and will need to directly access the server console to login.

Users should always log into the server using their own account and then use either sudo or su to execute administrative functions. The preferred method is sudo.

 

Setting Up Basic sudo for Administrators

First of all the sudo package must be installed. If you have installed the OS according to these posts then it will already be installed.

sudo is configured using the /etc/sudoers file; however, it cannot be directly edited using your favorite editor. You must use the visudo command to edit the file. visudo uses the VISUAL environment variable to set the appropriate editor. If vi is your editor of choice, then run:

export VISUAL="vi"

You will probably want to put this line in .bash_profile of root.

Once this is completed you can simply enter"

visudo

and it will open up /etc/sudoers in the editor specified by the VISUAL environment variable.

Once opened, you will likely see an lines such as the following:

 

## Allow root to run any commands anywhere

root    ALL=(ALL)       ALL

 

You should also find a lines like:

 

## Allows people in group wheel to run all commands

# %wheel        ALL=(ALL)       ALL

 

Uncomment the line that starts with %wheel and save the file.

Now all users in the wheel group will be able to run all commands. Please note that this is a very simple implementation meant for administrator access only.

The next step will be to create a user or users in the wheel group for all administrators as follows:

useradd <username>

passwd <username>

usermod -G wheel <username>

These users can log into the server as themselves. If they need to run privileged commands they can simply enter:

sudo <command>

and they will be prompted to reenter their password.

Alternatively, the users, assuming they know the root password, can enter:

su

and then the password for root.

 

Securing SSH

The following script secures ssh by:

1. Ensuring the ssh client configuration in /etc/ssh/ssh_config enforces Protocol 2 and Port 22 and by setting permissions of the config file to 0644
2. Ensuring the ssh server configuration in /etc/ssh/sshd_config enforces Protocol 2, Port 22, VERBOSE logging, turning off RSA and host based authentication, requires passwords and a banner page and setting permissions of the config file to 0600

Warning: The second to the last line in this script changes permissions of the temp files it writes out to 0400 by referencing $tmpcis/*. If $tmpcis is not properly set, it will change permissions on the wrong files/directories recursively. Worse case would be not having $tmpcis set in which case your server will become unusable. You might want to remove this line and set the permissions manually to be safe.

You can download the shell script that makes these changes here: cis_script1_ssh.sh (2.6K).

Note: The default (and non-secure) warning banner was enabled by this step. We'll address modifying the banner in a future post.

The changes made here for the ssh server will not take effect until sshd is bounced. This is accomplished by running:

/etc/init.d/sshd stop

/etc/init.d/sshd start