Always Use Sudo

This is part of a series of articles on Red Hat Server Hardening.

Nobody - not even administrators - should ever log in as root unless absolutely necessary. If an administrator needs to run a command with root privileges, they should use sudo.

The sudo tool allows ordinary users to have limited root level administrative access for certain tasks. This allows users to perform specific superuser operations without allowing them full superuser status.

To use sudo to run a command, precede it with the sudo command:
sudo date

The first time a user issues a sudo command during a login session, they will be prompted to enter the administrative password.

The accounts capable of using sudo are specified in the /etc/sudoers file, which is edited with the visudo utility. This file lists users and the commands they can run, along with the password for access (unless the NOPASSWD option is set, then users will not need a password).

A /etc/sudoers entry has the format
     user     host=command

user	The name of the user being granted access
host	A host on the network. For all hosts, use ALL.
command	A list of one or more commands, qualified by options such as whether the password is required. For all commands, use ALL.

So, for example, to give user paul full root-level access to all commands on all hosts:
paul   ALL = ALL

To run as another user, instead of as root, place the alternative user in parentheses before the command. For example, to allow user paul to run as user ringo on the beatle host:
paul   beatle = (ringo) ALL

The command may have an option associated with it. Possible options are:

NOPASSWD / PASSWD	Determines whether or not the user will require a password to run the command.
NOEXEC / EXEC	If sudo has been compiled with noexec support, this determines whether or not an executable will be allowed to run further commands itself.
SETENV / NOSETENV	Determines whether or not users are allowed to override environment variables with the sudo -e command.
LOG_INPUT / NOLOG_INPUT	Determines whether or not the input to the command is written to the log file.
LOG_OUTPUT / NOLOG_OUTPUT	Determines whether or not the output from the command is written to the log file.

By default, relevant logs are written to /var/log/secure.

Therefore, to allow user paul to run the kill command on beatle with a password, but to run the lprm command without a password:
paul   beatle = PASSWD: /usr/bin/kill, NOPASSWD: /usr/bin/lprm

A user can see what commands he or she can run by running: sudo -l

Remove KDE or GNOME From Linux

X Windows desktops like KDE or GNOME are not required on a server, and waste valuable resources. These should therefore be removed:
yum groupremove “X Window System”

This will remove around 100-150 packages from the server.

Doing this will prevent an intruder from starting an X-Windows session on the server by typing startx at the shell prompt.

Installation of X-Windows can also be completely prevented during initial system installation.

Partitioning and Mounting Disks For Security

This is part of a series of articles on Red Hat Server Hardening.

By creating different partitions, data can be separated and grouped. When an unexpected accident occurs, only data on that partition will be damaged, while the data on other partitions will survive.

During the initial installation, mount filesystems with user-writeable directories, such as the following, on separate partitions:

• /usr
• /home
• /var
• /var/tmp
• /tmp

Apache and FTP server root directories should also be mounted on separate partitions.

To limit user access to filesystems, add the mount options from the following table to the filesystems configuration in /etc/fstab . The defaults option is equal to rw,suid,dev,exec,auto,nouser,async.

Option	Description
noexec	Prevents the execution of binaries (although scripts will not be prevented from running).
nosuid	Prevents the setuid bit from having an effect.
nodev	Prevents the use of device files.

Modify the /boot directory to be read only (ro). This reduces the risk of unauthorized modification of critical boot files.

For example, to modify the /etc/fstab entry to limit user access on /dev/sda5 (ftp server root directory):

Find the line that reads:
/dev/sda5  /ftpdata          ext3    defaults 1 2
And change it to:
/dev/sda5  /ftpdata          ext3    defaults,nosuid,nodev,noexec 1 2

Physical Security of Linux Servers

This is part of a series of articles on Red Hat Server Hardening.

The physical security of a Linux Server is the first line of defence against attackers. Who has direct physical access to the server, and should they? Should the server be secured out of hours or while you are away?

BIOS Security

The server's BIOS should be configured to disable booting from CDs/DVDs, floppies, and external devices. If possible, a password should be set to protect these settings.

GRUB Boot Loader Security

The GRUB boot loader should be password protected. The primary reasons for doing this are:

1. Preventing Access to Single User Mode - If attackers can boot the system into single user mode, they are logged in automatically as root without being prompted for the root password.
2. Preventing Access to the GRUB Console - If the machine uses GRUB as its boot loader, an attacker can use the use the GRUB editor interface to change its configuration or to gather information using the cat command.

By generating an MD5 hashed password string and including it in the GRUB configuration file, GRUB can be configured to address these issues.

To do this, first decide on a password, then open a shell prompt, log in as root, and type:
/sbin/grub-md5-crypt
This will ask for a password to be entered. Type the new GRUB password twice. This returns an MD5 hash of the password.

Next, edit the GRUB configuration file /boot/grub/grub.conf.

Open the file and below the timeout line in the general section of the document, add the following line:
password --md5 <password-hash>
Replace <password-hash> with the value returned by /sbin/grub-md5-crypt.

Remove the line that contains the hiddenmenu parameter, and save the changes.

The next time the system boots, the GRUB menu does not allow access to the editor or command interface without first pressing p followed by the GRUB password.

Password Control

This is part of a series of articles on Red Hat Server Hardening.

Once a user account has been created, the user's access to it can be controlled.

Locking User Accounts

The passwd command can be used to lock and unlock a user's account.
passwd -l username

will lock an account, and
passwd -u username

will unlock it.

Lock Any Accounts With No Password Set

Login as root, and enter the following command
awk -F: '($2 == "") {print $1}' /etc/shadow
This will produce a list of all accounts that have no password set.

Note:- Some systems still store the password in the /etc/passwd file (they shouldn't, but they do!). If this is the case, use /etc/passwd instead of /etc/shadow above.

The lock all empty password accounts:
passwd -l <Account Name>

Change Password Expiration Limits

The chage command displays password expiration details along with last password change date.

To view any existing user’s password ageing information such as expiry date and time, use the following command:
chage -l username

To change password ageing of any user, use the following command.
chage -M 60 -m 7 -W 7 <username>

This sets a maximum age of 60 days, a minimum age of 7 days, and allows the user 7 days warning before the password expires.

Options for chage are as follows:

Option	Description
-m	Minimum number of days a user must go before being able to change their password
-M	Maximum number of days a user can go without changing their password
-d	The last day the password was changed
-E	Specific expiration date for a password, date in format YYYY-MM-DD or MM/DD/YYYY
-I	Allowable account inactivity period (in days) after which password will expire
-W	Warning period. The number of days before expiration when the user will be sent a warning message
-l	Display current expiration controls

Prevent Reuse of Old Passwords

Users should be prevented from reusing old passwords. Old passwords are stored in /etc/security/opasswd. This file must be created before switching on password history, otherwise all user password updates will fail because the pam_unix[1] module will constantly be returning errors from the password history code due to the file being missing.

After creating the file, change the permissions to keep it secure:
touch /etc/security/opasswd
chown root:root /etc/security/opasswd
chmod 600 /etc/security/opasswd

Open the /etc/pam.d/system-auth file and add the following line to the auth section:
auth        sufficient    pam_unix.so likeauth nullok

Add the following line to the password section:
password   sufficient    pam_unix.so nullok use_authtok md5 shadow remember=5

This will prevent a user from re-using any of their last 5 passwords.

Force Users to Set Strong Passwords

A number of users use soft or weak passwords and their password might be hacked with a dictionary based or brute-force attacks. The pam_cracklib module, available in the PAM (Pluggable Authentication Modules) module stack, forces users to set strong passwords.

Open the /etc/pam.d/system-auth file and amend or add the entry for pam_cracklib.so:
/lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-2 dcredit=-2 ocredit=-1

This sets the number of times the password may be entered before it fails to 3. The password must be at least 8 characters long, and contain at least 1 lower case character, 2 upper case characters, 1 digit and one other.

[1] qv PAM Overview ↩

Configure or Disable SSH

This is part of a series of articles on Red Hat Server Hardening.

SSH is the usual means of accessing and interacting with a server. Unless the keyboard and monitor are physically connected directly to the server, then access will most likely be via SSH. However, if SSH is not required, then disable it:

/sbin/chkconfig sshd off

The default SSH configuration means that automated cracking scripts and bots trying to break into a server know exactly where to go and what to do. They know the name of the root account, and they know they can SSH onto the server on port 22. The first line of defence is therefore to disable direct root access via SSH, and change the access port.

Changes to SSH are made via the SSH configuration file: /etc/ssh/sshd_config.

Prevent direct root login from SSH

In the config file, find the line that reads:
PermitRootLogin yes

Change yes to no. This prevents users from logging into the server as root via SSH. This adds an extra layer of security. Any hacker trying to get into root will have to get in as a normal user first, then try to access root from there. Warning: Make sure you have a regular user account first before doing this, otherwise you will not be able to access root.

Limit SSH access to a subset of users

If possible, limit SSH access to a subset of users. If there are many user accounts on the server, but only a few need to log into it via SSH, then doing this is a worthwhile exercise.This makes a hacker's job even more difficult because they will have to guess the both the name of an authorised user, and their password.

The AllowUsers parameter is not included in /etc/ssh/sshd_config by default, so it will need to be added:
AllowUsers john paul george ringo

Alternatively, create a group called sshusers and only add the users that need remote access:
groupadd sshusers
usermod -aG sshusers john
usermod -aG sshusers paul
usermod -aG sshusers george
usermod -aG sshusers ringo

Then, add the following line to /etc/ssh/sshd_config:
AllowGroups sshusers
Note:- The AllowUsers and AllowGroups parameters are mutually incompatible, with AllowUsers taking precedent.

Change the default SSH port

Change the default SSH port number of 22 to some other higher level port number.

Note:- The Internet Assigned Numbers Authority (IANA) is responsible for the global coordination of the DNS Root, IP addressing, and other Internet protocol resources. It is good practice to follow their port assignment guidelines. Having said that, port numbers are divided into three ranges: Well Known Ports, Registered Ports, and Dynamic and/or Private Ports. The Well Known Ports are those from 0 through 1023 and SHOULD NOT be used. Registered Ports are those from 1024 through 49151 should also be avoided too. Dynamic and/or Private Ports are those from 49152 through 65535 and can be used.

Choose an appropriate port, also making sure it not currently used on the system, and update the following line in /etc/ssh/sshd_config:
Port <New Port Number>
Make sure, obviously, that anyone who needs to ssh onto the server knows the correct port number. To log in, they will need to add -p <new port number> to the end of the ssh command.

Once all of the necessary changes have been made to /etc/ssh/sshd_config, restart the service so that these changes take effect.
service sshd restart

Set Up SSH Agent Forwarding on a Server

This is part of a series of articles on Red Hat Server Hardening.

SSH is the Secure Shell protocol which can be used for command line access, file transfer and application tunnelling.

Overview

Password free access requires a public/private key pair. The server (sshd) has access to the public key, while only you and your SSH client have access to the private key. To authenticate the client convinces the server that it is in possession of the private key without actually sending it.

Private keys are protected by a pass phrase. This pass phrase is required each time the key is used. To allow repeated access without re-keying of the pass phrase, agent forwarding is used.

The SSH agent allows the pass phrase to be entered once only, e.g. at system start-up or in the originating shell and then caches the keys in memory, eliminating the need for the phrase to be entered for each access. Because the agent is forwarded the pass phrase is available for all sessions that can access the keys in the home directory, including chains of sessions.

Steps

The steps required to set up password free access are:

1. Generate a key pair using OpenSSH
2. Distribute public keys
3. Configure agent forwarding

Generate SSH key pair

ssh-keygen is a program in the OpenSSH package that can be used to create key pairs. RSA is the current SSH key standard; DSA and RSA1 keys can be generated for compatibility with older systems.

Use the full path to ssh-keygen to ensure the correct OpenSSH binary is used, key in a pass phrase when prompted and accept the default file locations. 

> /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/milned/.ssh/id_rsa):
Created directory '/home/milned/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/milned/.ssh/id_rsa.
Your public key has been saved in /home/milned/.ssh/id_rsa.pub.
The key fingerprint is:
77:3f:47:01:92:5f:d0:fe:3e:6a:03:a4:9a:0a:18:26 milned@nyssa

Similarly DSA and RSA1 keys can be generated. Again enter a pass phrase and accept the default file locations as prompted. Using the same pass phrase for all keys will simplify operation of the SSH agent. 

> /usr/bin/ssh-keygen -t dsa
> /usr/bin/ssh-keygen -t rsa1

Distribute SSH Public Keys

The public keys must be distributed to the user's authorized_keys file so that any SSH daemon with access to the user's home directory can use them.

> cd ~/.ssh
> cat *.pub > authorized_keys

Change the permissions on this file so it is not writable by other users.

> chmod go-w authorized_keys

Now check that key authentication is working, by using ssh to connect to the host you are currently logged in to using its hostname. You should be prompted for the pass phrase for one of your keys. If this is the first time you've talked to the machine you will also be asked to accept the host key, which you should do.

> ssh nyssa
The authenticity of host 'nyssa (127.0.0.1)' can't be established.
RSA key fingerprint is 85:4b:2a:53:48:52:9f:61:ed:0a:33:4a:9d:5e:d3:1a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'nyssa' (RSA) to the list of known hosts.
Enter passphrase for key '/home/milned/.ssh/id_rsa':
Last login: Thu Nov 21 17:27:35 2013 from tegan
>

SSH access is now configured to use keys rather than a password to grant access. Access to the key is controlled by a pass phrase. In the next step agent forwarding is set up so that this pass phrase only needs to be entered once.

Configure SSH Agent Forwarding

To check if there is already an agent running use ssh-add.

> /usr/bin/ssh-add -l
Could not open a connection to your authentication agent
If this command reports anything else, then there is an agent running. Otherwise, start an agent using the command:

> exec ssh-agent $SHELL This creates a new shell process as a child of the agent with suitable environment variables set. This agent will live until you exit from this shell, and is only accessible from it.

Running ssh-add should now show the agent is present, but with no identities.
> /usr/bin/ssh-add -l
The agent has no identities The next step is to add the keys using ssh-add. This will prompt you for the pass phrase for one of your keys, and then assuming they all have the same pass phrase, add them all to the agent:

> /usr/bin/ssh-add
Enter passphrase for /home/milned/.ssh/id_rsa:
Identity added: /home/milned/.ssh/id_rsa (/home/milned/.ssh/id_rsa)
Identity added: /home/milned/.ssh/id_dsa (/home/milned/.ssh/id_dsa)
Identity added: /home/milned/.ssh/identity (milned@nyssa) Check the keys are available with ssh-add again, which should now report a list of key signatures.
> /usr/bin/ssh-add -l
1024 90:d1:83:5c:2a:33:9b:c7:ba:85:8e:ef:b7:c0:32:05 milned@nyssa (RSA1)
1024 9f:c0:e4:ed:f1:c4:ec:de:6e:af:4c:91:13:8d:58:45 /home/milned/.ssh/id_rsa (RSA)
1024 ab:a1:89:d7:d5:06:d2:d5:c4:18:e6:bc:65:37:96:dc /home/milned/.ssh/id_dsa (DSA) You should now be able to use ssh to connect to any other machine which is running OpenSSH and has your home directory mounted, and not be prompted for a password. Chaining SSH connections (ssh from a to b and then from b to c) should work via agent forwarding.

Automating SSH Agent Forwarding

Rather than running the above manually, it can be built into the .bashrc file so that it starts automatically when bash is started.

> cd
> cat .bashrc
export PS1="\u@\H \w> "
PATH=$PATH:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
Amend .bashrc as follows:
export PS1="\u@\H \w> "
PATH=$PATH:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
ssh-agent > $HOME/.ssh-agent.sh
ssh_agent="$HOME/.ssh-agent.sh"
if [ -f $ssh_agent ]
then
  source $ssh_agent > /dev/null
fi
ssh-add
alias stat="perl -e'print "%o\n",(stat shift)[2] & 07777' $1"
export EDITOR=vi