Server Hardening Checklists

Red Hat Linux Server Hardening Checklist

The hardening checklists are based on the comprehensive checklists produced by CIS. The VCU Security Team has distilled the CIS lists down to the most critical steps for your systems, with a particular focus on configuration issues that are unique to the computing environment at VCU.

How to use the checklist

Print the checklist and check off each item you complete to ensure that you cover the critical steps for securing your server. The checklist will be used during risk assessments and audits as part of the process to verify that servers are secure.

How to read the checklist

Step - The step number in the procedure. If there is a VCU Note for this step, the note # corresponds to the step #.

Check (√) - This is for administrators to check off when she/he completes this portion.

To Do - Basic instructions on what to do to harden the respective system

CIS - Reference number in the Center for Internet Security Red Hat Linux Benchmark (PDF, Requires VCU eID login.) The CIS document outlines in much greater detail how to complete each step.

UT Note - The VCU Note at the bottom of the page provides additional detail about the step for the university computing environment.

Cat I - For systems that include category I data, required steps are denoted with the ! symbol. All steps are recommended.

Cat II/II - For systems that include category II or III data, all steps are recommended, and some are required (denoted by the !).

Min Std - This column links to the specific requirement for the university in the Minimum Security Standards for Systems document.

Server Information

MAC Address

 

IP Address

 

Machine Name

 

Asset Tag

 

Administrator Name

 

Date

 

Preparation and Installation

Step

To Do

CIS

VCU Note

Cat I

Cat II/II

Min Std

1

 

If machine is a new install, protect it from hostile network traffic, until the operating system is installed and hardened.

 

§

!

 

5.1

2

 

Set a BIOS/firmware password and/or - Configure the device boot order to prevent unauthorized booting from alternate media.

7.8

 

!

 

4.1

Patches, Packages and Initial Lockdown

3

 

Operating system and application services security patches should be installed expediently and in a manner consistent with change management procedures.

1.1

§

!

 

5.2

4

 

Configure SSH
Note: Services used to transfer Category I data shall be encrypted.

1.3

§

!

 

5.6

5

 

Install package sysstat.

1.4

§

!

 

6.1

6

 

Enable and test OS and Applications logging.

n/a

§

!

 

6.1

7

 

Consider installing Bastille Linux.

1.5

§

 

 

 

Minimize xinetd network services

8

 

Disable  any services, application and/or user accounts that are not being utilized

2.1

§

!

 

5.4

9

 

Limit connections to services running on the host to authorized users of the service (utilize firewall technology)

2.2

§

!

 

5.5

Minimize boot services

10

 

Disable GUI login if possible.

3.4

§

!

 

 

Logging

11

 

Configure an NTP server.

5

§

!

 

 

12

 

All administrator or root access must be logged.

5

§

!

 

6.4

Files/Directory Permissions/Access

13

 

Integrity checking of system accounts, group memberships, and their associated privileges should be enabled and tested.

SN.7
6.4

§

!

 

5.9

System Access, Authentication, and Authorization

14

 

Ensure that the configuration files for PAM, /etc/pam.d/* are secure.

7.1
8.2

§

!

!

5.12

15

 

Enable the terminal security file/restrict root logins to system console.

7.7

§

!

!

4.1

Warning Banners

16

 

If services are running - ensure the university warning banner is utilized.

9

§

!

!

5.10

Anti-Virus Considerations

17

 

Install and enable anti-virus software.

 

§

!

!

3.1

18

 

Configure to update signature daily on AV.

 

§

!

!

3.3

Additional Security Notes

19

 

Systems shall provide encrypted storage for Category I data.

 

§

!

!

5.7

20

 

Integrity checking of critical operating system files should be enabled and tested. Third-party tools may also be used to implement this.

 

§

!

!

5.8


1

If other alternatives are unavailable, this can be accomplished by installing a SOHO router/firewall in between the network and the host to be protected.

3

Use up2date with these configuration settings:

1.     Clear option #7 (so the kernel packages are not skipped).

2.     Change option #22 from No to Yes (to enable rollbacks).

3.     Run up2date.

4

If you decide to utilize SSH, the ISO highly recommends the following:

  • Change the port from port 22 to something/anything else. There are scripts online that malicious hackers can use against an SSH server. These scripts always attack port 22 since most people do not change the default port.
  • Do not allow root logins via SSH.
  • If possible, use keys with passphrase instead of just passwords. To create rsa keys, follow these commands:
    • ssh-keygen –t rsa
    • ssh server “mkdir .ssh; chmod 0700 .ssh
    • scp ./ssh/ida_rsa.pub server:.ssh/authorized_keys2

The CIS Solaris Benchmark covers some suggested basic settings to place in the configuration file.

You may also want to visit the SSL Web site.

5

System accounting gathers baseline system data (CPU utilization, disk I/O, etc.) every 10 minutes. The data may be accessed with the sar command, or by reviewing the nightly report files named /var/log/sa/sar*. Once a normal baseline for the system has been established, unauthorized activity (password crackers and other CPU-intensive jobs, and activity outside of normal usage hours) may be detected due to departures from the normal system performance curve.

6

The psacct package contains several utilities for monitoring process activities, including ac, lastcomm, accton, and sa.

  • ac displays statistics about how long users have been logged on.
  • lastcomm displays information about previously executed commands.
  • accton turns process accounting on or off.
  • sa summarizes information about previously executed commands.

7

Bastille Linux is a tool that can help harden any Linux OS. The tool requires perl-tk, so make sure that is installed. Bastille Linux may actually take care of some of the following hardening instructions; nevertheless, the ISO recommends going through the entire document as a checklist and implement all the hardening instructions.  

See Appendix C “Bastille Configuration” in the CIS document for recommended configuration.

8

Disable any xinetd services you do not absolutely require by setting “disable=yes” in /etc/xinetd.d/*. If no xinetd services are required, disable xinetd altogether (sudo service xinetd stop; sudo chkconfig xinetd off)

Configure TCP wrappers for access control.

Edit /etc/hosts.deny to include this entry as the first uncommented line in the file: ALL:ALL

Ensure /etc/hosts.allow is edited appropriately to allow the administrator(s) to connect.

Unless “r” commands (i.e., rsh, rlogin) are required, remove or empty the file /etc/hosts.equiv.

If “r” commands are required, consider replacing them with a secure alternative such as SSH.

Verify that you have disabled any unnecessary startup scripts under /etc, /etc/rc*.d, or /etc/init.d (or startup script directory for your system) and disabled any unneeded services from starting in these scripts.

Unnecessary services can be disabled with sudo chkconfig servicename off.

To check what services are listening use: 

$ lsof | grep ‘*:’ 

OR

$ sudo netstattulp

Much more detailed information regarding services is available in the CIS benchmark documents.

Red Hat has an tool for checking startup service:

ntsysv

For example, the command

ntsysv --level 345

configures runlevels 3, 4, and 5.

9

Red Hat comes with iptables. Below is a list of some iptables resources:

http://firehol.sourceforge.net

http://sourceforge.net/projects/fwbuilder

http://www.simonzone.com/software/guarddog

10

Edit the file /etc/inittab. Look for the line that contains the following:

id:5:initdefault:

replace the “5” with “3”. The line will then read:

id:3:initdefault:

11

 

12

Examples: syslog
Red Hat: http://www.redhat.com/docs/manuals/enterprise/RHEL-AS-2.1-Manual/cluster-manager/s1-software-syslog.html 

13

  • Check in /etc/sudoers to see who has sudo rights
  • Check in /etc/groups to see what groups your users belong to
  • Check in /etc/passwd and/or /etc/shadow for blank passwords
  • Check the strength of users’ passwords with tools such as John the Ripper
  • Seek approval from IT Owner. Consider using a simple dictionary for easily guessed passwords.
  • Develop a procedure to report and remediate easily guessed passwords.

14

Ensure the following are set:

  • auth   required pam_deny.so
  • auth   required pam_warn.so
  • account  required pam_deny.so
  • account  required pam_warn.so
  • password  required pam_deny.so
  • password  required pam_warn.so
  • session  required pam_deny.so
  • session  required pam_warn.so
  • session  required pam_deny.so

Warn will report alerts to syslog.

15

Ensure that the terminal security file (for example, /etc/securetty or /etc/ttys) is configured to deny privileged (root) access. On a Red Hat box, this means that no virtual devices (such as /dev/pty*) appear in this file.

16

The text of the university's official warning banner can be found on the VCU Web site. You may add localized information to the banner as long as the university banner is included.

17

There are few viruses that infect Linux computers; therefore, it is understandable for most Solaris servers to have an exception to this rule. See the Operations Manual for information on the exception process.

You may choose any proven anti-virus product. One option is ClamAV.

19

There are a variety of methods available to accomplish this goal. Two good candidates are PGP (cost) and GNUPG (free).

20

Tripwire is available from Software Distribution & Sales for a nominal charge. The Tripwire management console, which is also available from SDS for a nominal charge, can be very helpful for managing more complex installations.

AIDE is a free tool available from SourceForge.

SamHain is another free tool.