Redhat Enterprise Linux 4 OS Hardening

Guidelines

Physical Security
Physical security should be of the utmost concern. Linux production servers should be in
locked datacenters where only people with passed security checks have access.
But physical security is out of scope for this checklist.

Verifying Security Action Items

It is strongly recommended to have scripts available which will verify many of the security
action that have been implemented.

Retiring Linux Servers with Sensitive Data

To retire servers with sensitive data, it is important to ensure that data cannot be recovered
from the hard disks. To ensure that all traces of data are removed, the DiskSanitizer tool can be
used. This tool can be operated from a floppy disk and it removes data according with the U.S.
Department of Defense (DoD) standards. DiskSanitizer is available at
http://freshmeat.net/projects/disksanitizer.

Backups
It is very important to take some Backups offsite for cases like disasters.
For legal reasons, some firms and organizations must be careful about backing up too much
information and holding it too long.

Disk Partitions
Servers should have separate partitions for at least /, /boot, /usr, /var, /tmp, and /home. You
don't want that e.g. logging and temporary space under /var and /tmp fill up the root partition.
Third party applications should be on separate filesystems as well, e.g. under /opt.

FTP, telnet, and rlogin (rsh)

FTP, telnet, and rlogin (rsh) are vulnerable to eavesdropping, which is one of the reasons why
SSH/SCP/SFTP should be used instead. It is highly recommended not to run these services.
Password Security – Reset Default Passwords
Passwords are the primary method Red Hat Enterprise Linux uses to verify a user's identity.
This is why password security is enormously important for protection of the user, the
workstation, and the network.

Consider the following:

BIOS and Boot Loader Security — Can an unauthorized user physically access the machine
and boot into single user or rescue mode without a password?
Password Security — How secure are the user account passwords on the machine?
Administrative Controls — Who has an account on the system and how much administrative
control do they have?
Available Network Services — What services are listening for requests from the network and
should they be running at all?
Security Enhanced Communication Tools — Which tools should be used to communicate
between workstations and which should be avoided?

The following checklist was developed using content from the Redhat Enterprise Linux 4
Security Configuration Guide found here:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/

The reader is encouraged to visit this site to learn more about hardening the Redhat Enterprise
Linux 4 installation.

Password Checklist
Step 1. Reset Default Passwords
Creating Strong Passwords:
• Do Not Use Only Words
• Do Not Use Recognizable Words
• Do Not Use Words in Foreign Languages
• Do Not Use Personal Information
• Do Not Invert Recognizable Words
• Do Not Write Down Your Password
• Do Not Use the Same Password For All Machines

Default Passwords Changed on the Following Devices / Areas

Default Device Type : Location Changed by
Changed
 Note: To protect the network from intrusion it is a good idea for system
administrators to verify that the passwords used within an organization are
strong ones. When users are asked to create or change passwords, they can use
the command line application passwd, which is Pluggable Authentication
Manager (PAM) aware and therefore checks to see if the password is easy to
crack or too short in length via the pam_cracklib.so PAM module. Since PAM is
customizable, it is possible to add further password integrity checkers, such as
pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to
write a new module. For a list of available PAM modules, refer to
http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information
about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM)
in the Red Hat Enterprise Linux Reference Guide.

Step 2. Reset Password Ageing

The -M option of the change command specifies the maximum number of days
the password is valid. So, for instance, to set a user's password to expire in 90
days, type the following command:
change -M 90 <username>
In the above command, replace <username> with the name of the user.
.
Step 3. Check for and Install the most resent security patch updates.
Contact a representative from Motorola security services if you have any
questions in this area.

DHCP and DNS Internal Servers

Item OS / Hardware Platform Comments
 Step 4. Check Permissions on files in /etc directory
Create additional user accounts -> “Admin, Operator and Guest”
Issue the useradd command to create a locked user account:
useradd <Admin>
Unlock the account by issuing the passwd command to assign a password and
set password aging guidelines:
passwd <username>

Command line options for useradd are detailed below:

Option Description
-c <comment> can be replaced with any string. This option is generally used
'<comment>' to specify the full name of a user.
-d<home-dir> Home directory to be used instead of default /home/<username>/
-e<date> Date for the account to be disabled in the format YYYY-MM-DD
-f<days> Number of days after the password expires until the account is disabled. If
0 is specified, the account is disabled immediately after the password
expires. If -1 is specified, the account is not be disabled after the password
expires.
-g<group- Group name or group number for the user's default group. The group must
name> exist prior to being specified here.
-G<group- List of additional (other than default) group names or group numbers,
list> separated by commas, of which the user is a member. The groups must
exist prior to being specified here.
-m Create the home directory if it does not exist.
-M Do not create the home directory.
-n Do not create a user private group for the user.
-r Create a system account with a UID less than 500 and without a home
directory
-p<password> The password encrypted with crypt
-s User's login shell, which defaults to /bin/bash
-u<uid> User ID for the user, which must be unique and greater than 499

Passwords created for the accounts must comply with the password
requirements detailed in the Error! Reference source not found. above.

Repeat Step 4 to create usernames Operator and Guest”

There should only be 4 Users configured on the server at this time.
Root
Admin
Operator
Guest

Step 5. Add non root users to Wheel Group

Upon typing the su command, the user is prompted for the root password and,
after authentication, is given a root shell prompt.
Once logged in via the su command, the user is the root user and has absolute
administrative access to the system. In addition, once a user has become root, it
is possible for them to use the su command to change to any other user on the
system without being prompted for a password.
 One of the simplest ways to do this is to add users to the special administrative
group called wheel. To do this, type the following command as root:
usermod -G wheel <Admin>

Only the Admin user shall be permitted to use the ‘su’ command to obtain root
privileges.

Next, open the PAM configuration file for su (/etc/pam.d/su) in a text editor and
remove the comment # from the following line:

auth required /lib/security/$ISA/pam_wheel.so

use_uid

Doing this permits only members of the administrative group wheel to use the
program.
Note: The root user is part of the wheel group by default.
 Step 6. Limit Root Access – sudo Command
The admin user should be granted permissions to perform basic commands to
restart the DHCP and DNS server processes by adding the following entries to
the /etc/sudoers file:
admin ALL= /usr/sbin/rndc /usr/sbin/dhcpd
This command permits them to restart the services without having to log in as
the root user.

Step 7. Disabling Root SSH Logins

To prevent root logins via the SSH protocol, edit the SSH daemon's
configuration file (/etc/ssh/sshd_config). Change the line that reads:
# PermitRootLogin yes
to read as follows:
PermitRootLogin no

Step 8. Review and List Insecure Services

Examples of inherently insecure services includes the following:
o rlogin
o rsh
o telnet
o vsftpd
All remote login and shell programs (rlogin, rsh, and telnet) should be avoided
in favor of SSH. FTP is not as inherently dangerous to the security of the system
as remote shells, but FTP servers must be carefully configured and monitored to
avoid problems.

Insecure Services present

Service Name Comments

Step 9. Disabling Runlevel Services
One of the most important tasks is to remove any network services from the
system startup process that are not needed.

On Red Hat systems you can list all services which are started at bootup using
the following command:

chkconfig –list |grep on

You will notice that there are quite a lot of services enabled on your system. But
many runlevel services (Stand-Alone Services) are not network related services
like kudzu which is responsible for detecting and configuring new and/or
changed hardware on your system. This service is only run during the boot
process. Ensure not to disable runlevel services that are needed by the system to
run smoothly.

The following list of services are the only services that should be permitted to
be executed on the system. This list does not include services that are installed
as part of the applications hosted on the DNS/DHCP server platform.

gpm needed if you want to use the mouse at the console

kudzu important for detecting new hardware
syslog important for syslog services
netfs needed only if there are NFS shares that should be
mounted at boot time
network important for starting network interfaces (e.g. eth0, eth1,
bonding,...)
random used for the system entropy pool
atd needed if the at(1) service is used instead of cron
iptables needed if Netfilter (iptables) Firewall is being used
irqbalance important for distributing interrupts across all CPUs
autofs needed if automounter is used - production applications
should not be dependent on automounter
sshd important for logins via SSH
portmap needed if e.g. NFS is being used
nfslock needed if NFS shares are mounted
nfs needed if server runs the NFS server
mdmonitor needed only if software RAID is being used
crond important for running cron jobs
xinetd needed if xinetd services are being used, see /etc/xinetd.d/
for list of services
software updates etc.
sysstat needed to reset system statistics logs
audit needed only if Linux Audit Subsystem (LAuS) should
run for collecting system call audit records
psacct needed only if kernel process accounting information is
needed
smartd important for monitoring disk problems if hard disks
support SMART technology
netdump important if kernel oops data and memory dumps should be sent
to a Netdump server for server crashes

The start/stop scripts of all runlevel services can be found in the /etc/init.d
directory. For example, if you don't know what the atd service does, go to
/etc/init.d and open the file atd. And in the script look for lines that start
programs. In the atd script the "daemon /usr/sbin/atd" line starts the binary atd.
Now having the name of the program that is started by this service, you can
check the online pages of atd by running man atd. This will help you to find out
more about a system service. Disable all unused services starting with the ones
listed above in red it they are active.

To permanently disable e.g. the runlevel service nfs, run:

chkconfig nfs off

To immediately disable the runlevel service nfs, run:

/etc/init.d/nfs stop
 Step 10. Secure SSH
Many network services like telnet, rlogin, and rsh are vulnerable to
eavesdropping which is one of several reasons why SSH should be used instead.
Red Hat's default configuration for SSH meets the security requirements for
many environments. However, there are a few parameters in
/etc/ssh/sshd_config that you may want to change on RHEL and other Linux
systems.

The chapter Restricting System Access from Servers and Networks shows how
direct logins can be disabled for shared and system accounts including root. But
it's prudent to disable direct root logins at the SSH level as well.

PermitRootLogin no

Also ensure to have privilege separation enabled where the daemon is split into
two parts. With privilege separation a small part of the code runs as root and the
rest of the code runs in a chroot jail environment. Note that on older RHEL
systems this feature can break some functionality, for example see Preventing
Accidental Denial of Service.

UsePrivilegeSeparation yes

Since SSH protocol version 1 is not as secure you may want to limit the protocol
to version 2 only:

Protocol 2

Ensure the StrictModes directive is enabled which checks file permissions and
ownerships of some
important files in the user's home directory like ~/.ssh, ~/.ssh/authorized_keys
etc. If any checks fail,
the user won't be able to login.

StrictModes yes

Ensure that all host-based authentications are disabled. These methods should be
avoided as primary authentication.

IgnoreRhosts yes
HostbasedAuthentication no
RhostsRSAAuthentication no

Make sure sftp is enabled:

#Subsystem sftp /usr/lib/misc/sftp-

server
 After changing any directives make sure to restart the sshd daemon:

/etc/init.d/sshd restart

Step 11. Remove Unnecessary Software Packages (RPMs)

(This Step is not complete at this time 12.17.07 )
(Must Verify via Fresh RedHat Install to obtain an accurate list)

For example, you should not have Apache or Samba installed on your system if
you don't use them. Also, it is a good practice not to have development packages,
desktop software packages (e.g. X Server) etc. installed on
production servers. Other packages like FTP and Telnet daemons should not be
installed as well unless there is a justified business reason for it
(SSH/SCP/SFTP should be used instead).

One of the first action items should be to create a Linux image that only
contains RPMs needed by the applications, and needed for maintenance and
troubleshooting purposes. A good approach is to start with a minimum list of
RPMs and then add packages as needed. It may be time-consuming but worth
the efforts.

To get a list of all installed RPMs you can use the following command:

rpm -qa

If you want to know more about a particular RPM, run:

rpm -qi <package_name>

To check for and report potential conflicts and dependencies for deleting a RPM,
run:

rpm -e --test <package_name>

Step 12. Single User Mode Password for root

Add the following line to the /etc/inittab file to ensure that a root password is
required for Single User Mode logons:

~~:S:wait:/sbin/sulogin

Step 13. Restirct Direct Login Access for System and Shared Accounts

For SSH Logins add the pam_access module to /etc/pam.d/sshd as follows:

auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_access.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth

For Console Logins add the pam_access module to /etc/pam.d/login as follows:

auth required pam_securetty.so
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_access.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_selinux.so close
session required pam_stack.so service=system-auth
session optional pam_console.so
session required pam_selinux.so multiple open

For Graphical Gnome Logins add the pam_access module to /etc/pam.d/gdm as

follows:

auth required pam_env.so

auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_access.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so

Now add the following line to the /etc/security/access.conf configuration file:

-:ALL EXCEPT users :ALL

The /etc/security/access.conf configuration file is read by the pam_access

module. This entry specifies that no users are accepted except users that are in
the "users" group. Since the pam_access module has been configured for
"Authorization" (account) in the above PAM configuration files, it denies direct
logins for all accounts except the ones that are in the "users" group.

In RHEL4 pam_access is already configured for crond:

# grep pam_access /etc/pam.d/*
/etc/pam.d/crond:account required pam_access.so
accessfile=/etc/security/access-cron.conf

To ensure that all users on the system can still run cron jobs you can add the
following argument to pam_access in /etc/pam.d/crond:
 account required pam_access.so
accessfile=/etc/security/access-cron.conf

This ensures that the /etc/security/access.conf configuration file is not invoked

by crond. Since
pam_cracklib does not grant permissions if the configuration file does not exist,
execute the following command to create an empty file:

# touch /etc/security/access-cron.conf

Now verify that cron jobs can be launched by any user on the system.

NOTE:

The above example will only work if there exists no "users" account in the
/etc/passwd file on the system, which is usually the case. Otherwise you have to
either delete the "users" account or you have to designate or create another
group name.
Server Security
Step 1. Activate Kernel Tunable Security Parameter
The following list shows tunable kernel parameters you can use to secure your
Linux server against attacks. To activate the configured kernel parameters
immediately at runtime, use:

# sysctl -p

Step 2. Enable TCP SYN Cookie Protection

A "SYN Attack" is a denial of service attack that consumes all the resources on
a machine. Any server that is connected to a network is potentially subject to
this attack.

To enable TCP SYN Cookie Protection, edit the /etc/sysctl.conf file and add the
following line:

net.ipv4.tcp_syncookies = 1

Step 3. Disable IP Source Routing

Source Routing is used to specify a path or route through the network from
source to destination. This feature can be used by network people for diagnosing
problems. However, if an intruder was able to send a source routed packet into
the network, then he could intercept the replies and your server might not know
that it's not communicating with a trusted server.

To enable Source Route Verification, edit the /etc/sysctl.conf file and add the
following line:

net.ipv4.conf.all.accept_source_route = 0

Step 4. Disable ICMP Redirect Acceptance

ICMP redirects are used by routers to tell the server that there is a better path to
other networks than the one chosen by the server. However, an intruder could
potentially use ICMP redirect packets to alter the hosts's routing table by
causing traffic to use a path you didn't intend.

To disable ICMP Redirect Acceptance, edit the /etc/sysctl.conf file and add the
following line:

net.ipv4.conf.all.accept_redirects = 0

Step 5. Enable IP Spoofing Protection

 IP spoofing is a technique where an intruder sends out packets which claim to
be from another host by manipulating the source address. IP spoofing is very
often used for denial of service attacks. To enable IP Spoofing Protection, turn
on Source Address Verification. Edit the /etc/sysctl.conf file and add the
following line:

net.ipv4.conf.all.rp_filter = 1

Step 6. Enable Ignoring Broadcast Requests

If you want or need Linux to ignore broadcast requests, edit the /etc/sysctl.conf
file and add the
following line:

net.ipv4.icmp_echo_ignore_broadcasts = 1

Step 7. Enable Bad Error Message Protection

To alert you about bad error messages in the network, edit the /etc/sysctl.conf
file and add the
following line:

net.ipv4.icmp_ignore_bogus_error_responses = 1

Step 8. Enable Logging of Spoofed Packets, Source Routed Packets and redirected
Packets

To turn on logging for Spoofed Packets, Source Routed Packets, and Redirect
Packets, edit the
/etc/sysctl.conf file and add the following line:

net.ipv4.conf.all.log_martians = 1

Step 9. Checking File Permissions and Ownership

The umask (user file-creation mode mask) command is a shell built-in command
which determines the default file permissions for newly created files. This can
be overwritten by system calls but many programs and utilities make use of
umask.

By default, Red Hat sets umask to 022 or 002 which is fine. If the name of the
user account and the group account is the same and the UID is 100 or larger,
then umask is set to 002, otherwise it's set to 022, see /etc/bashrc for bash shells.

$ id uid=509(test) gid=510(test)
groups=100(users),510(test)
context=user_u:system_r:unconfined_t
$ umask
 0002
$

# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:system_r:unconfined_t
# umask
0022
#

Here is an example how umask works:

$ umask 000
$ touch file1
$ ls -l file1
-rw-rw-rw- 1 oracle oinstall 0 Dec 26 19:24 file1
$ umask 002
$ touch file2
$ ls -l file2
-rw-rw-r-- 1 oracle oinstall 0 Dec 26 19:24 file2
$ umask 022
$ touch file3
$ ls -l file3
-rw-r--r-- 1 oracle oinstall 0 Dec 26 19:25 file3
$

For the bash shell you can find the setting of umask in /etc/bashrc. The
/etc/bashrc file is for system-
wide aliases and functions and is invoked by ~/.bashrc.

Step 10. Locate World-Writeable Files

World-writable files are a security risk since it allows anyone to modify them.
Additionally, world-writable directories allow anyone to add or delete files.

To locate world-writable files and directories, you can use the following
command:
find / -path /proc -prune -o -perm -2 ! -type l
-ls

The "! -type l" parameter skips all symbolic links since symbolic links are
always world-writable.

However, this is not a problem as long as the target of the link is not world-
writable, which is checked by the above find command.

World-Writable directories with sticky bit such as the /tmp directory do not
allow anyone except the owner of a file to delete or modify it in this directory.
The sticky bit makes files stick to the user who created it and it prevents other
 users from deleting and renaming the files. Therefore, depending on the purpose
of the directory world-writable directories with sticky are usually not an issue.
An example is the /tmp directory:

$ ls -ld /tmp
drwxrwxrwt 18 root root 16384 Dec 23 22:20 /tmp

The "t" mode, which denotes the sticky bit, allows files to be deleted and
renamed only if the user is the owner of this file or the owner of the directory.

Step 11. Identify Unowned Files

Files not owned by any user or group might not necessarily be a security
problem in itself. However, unowned files could pose a security problem in the
future. For example, if a new user is created and the new users happens to get
the same UID as the unowned files have, then this new user will automatically
become the owner of these files.

Find all setuid and setgid programs on your system, and keep track of what they
are, so you are aware of any changes which could indicate a potential intruder.
Use the following command to find all setuid and setgid programs on your
system:

user@myhost# find / -type f -perm +6000 -ls

You can discriminately remove the setuid or setgid permissions on a suspicious

program with chmod(1), then change it back if you absolutely feel it is
necessary.

World-writable files, particularly system files, can be a security hole if a cracker

gains access to your system and modifies them. Additionally, world-writable
directories are dangerous, since they allow a cracker to add or delete files as he
wishes. To locate all world-writable files on your system, use the following
command:

user@myhost# find / -perm -2 ! -type l -ls

and be sure you know why those files are writable. In the normal course of
operation, several files will be writable, including some from /dev.
Unowned files may also be an indication an intruder has accessed your system.
You can locate files on your system that do not have an owner, or belong to a
group with the command:

root@myhost# find / -nouser -o -nogroup

 Step 12.
Create a Connection Banner File
This example implements a banner for vsftpd. To begin, create a banner file. It
can be anywhere on the system, but it must bear same name as the daemon. For
this example, the file is called /etc/banners/vsftpd.
The contents of the file look like this:
220-Hello, %c 220-All activity on ftp.example.com is
logged. 220-Act up and you will be banned.

The %c token supplies a variety of client information, such as the username and
hostname, or the username and IP address to make the connection even more
intimidating. The Red Hat Enterprise Linux Reference Guide has a list of other
tokens available for TCP wrappers.
For this banner to be presented to incoming connections, add the following line
to the /etc/hosts.allow file:
vsftpd : ALL : banners /etc/banners/
Step 13. Enable TCP Wrapper Logging
To do this, place the following line in /etc/hosts.deny:
in.telnetd : ALL : severity emerg
This uses the default authpriv logging facility, but elevates the priority from the
default value of info to emerg, which posts log messages directly to the console.