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