MCSS Compliance Notes: RHEL5
The Ohio State University requires all devices connecting to university network resources to be compliant with the Minimum Computer Security Standard (MCSS) document, which can be found at:
http://buckeyesecure.osu.edu/Policy/MCSS
The MCSS consists of four components:
1. The device must be guarded by an up-to-date and active firewall set to protect it from unauthorized network traffic.
2. Current operating system and application software with current security patches must be installed.
3. The device must be protected against malicious or undesired software such as viruses, spyware, or adware.
4. Access to the device must require appropriate authentication controls such as account identifiers and robust passwords.
There are other important aspects of the MCSS policy, so it is important to read. The CSE computing staff officially supports the Red Hat Enterprise Linux distribution. These notes can be used with RHEL5 Desktop and RHEL5 Server systems to become MCSS complaint, provided that:
· All the commands execute correctly on any specific installation of RHEL5.
· All of the steps in this document are followed exactly.
Any deviations from these steps or changes to how the software installed works needs to be discussed with CSE staff members before a device can be certified as MCSS compliant. Any attempts to circumvent MCSS compliance checks will result in disconnection from the CSE network until the device in question can be brought back into compliance.
Initial Setup
All the commands prefixed with “sudo” in this document assume that an entry like the following was added to /etc/sudoers using “visudo”:
<username> ALL=(ALL) ALL
Substitute “<username>” with the normal user account name used when interacting with the system, otherwise run the commands as root without “sudo” instead.
The first step is to make sure the device is properly registered with the CSE Red Hat Network proxy server. There are three possibilities with current registration on a RHEL5 system installed from the CSE provided media:
· The system is installed, but not registered.
· The system is installed and registered, but the CSE SSL proxy certificate on the registered machine is out of date.
o This is not likely with RHEL5 systems since that was when we updated the certificate.
· The system is installed and the registration is current and working.
In the first case, the system was installed but never registered for updates for whatever reason. Some systems might have been registered and worked in the past, but the CSE staff had to update the CSE proxy server SSL key when RHEL5 was released, and the system is now out of date because it has an old SSL certificate. Some systems might be registered and are working fine. Registration status can be tested by trying to run the following command:
sudo yum check-update
This command normally displays the available updates. If the command prints out the following, along with some other output:
This system is not registered with RHN.
RHN support will be disabled.
the system has not been registered. If the command complains about an SSL certificate and possible system time synchronization issues, then the system was registered, but the SSL certificate is out of date. If the command properly lists available updates (which could be an empty list), no action is required to register the system. For the first two cases, where the system is not currently registered or has an SSL certificate error, download the current activation setup files:
http://www.cse.ohio-state.edu/~rowland/mcss/activation-rhel5.tar.gz
and setup the system with the following commands:
tar -vxzf activation-rhel5.tar.gz
cd activation-rhel5
sudo ./install.sh
The install.sh script will fix the system configuration and make sure the proper SSL certificate is installed. It is safe to run this on a RHEL5 system regardless of its current state, even if it is already configured properly. The install.sh script prints out further instructions on how to complete the registration process, which include:
· Contacting CSE computing staff to acquire the proper activation key.
· Activating the system with the activation key.
Activating the system is only necessary if it has not already been activated. Testing with “yum check-update” as suggested can test the setup. If there are any questions about Red Hat Network CSE proxy server registration, please ask CSE computing staff for assistance.
Once the system has been registered and activated, run the following command:
sudo yum update
This will update the system software before moving to the MCSS specific configuration steps. Answer yes to any prompts if required (there should be at least one concerning actually downloading the updates and probably a second about an initial Red Hat GPG key import). If yum complains that it cannot download a required file, wait a few minutes and run the command again. If the update process indicates a reboot is required, reboot the device. Even if not prompted, if there are a lot of updates, it is advisable to reboot regardless. Another alternative is to use the update notification icon at the top right of the screen, which shows up as a brown box as shown below:
Sometimes software updates can cause currently running applications to behave strangely. Firefox and Thunderbird experience this quite frequently when updated. This can be solved by restarting the applications or logging out and logging in again.
Firewall
RHEL5 systems come with a firewall already installed. The firewall settings can be checked from the System --> Administration --> Security Level and Firewall Gnome menu as shown below:
The MCSS policy requires that CSE computing staff are able to check device compliance at any time, therefore opening the SSH port is required. We also need to be able to ping the machine (which is enabled by default). The settings above are the minimum required:
· The firewall is enabled.
· SSH is listed as a trusted service.
It is acceptable to open up more ports or port ranges if required for research work, but the firewall should be operated in the default manner where it blocks incoming connections except for exceptions. It is possible there will be other requirements that might need different configurations. If needed, these should be discussed with CSE computing staff to make sure the settings meet the MCSS firewall requirement.
Current OS/Software
RHEL5 systems that are registered with the CSE Red Hat Network proxy server will run the update notification icon by default. Additional settings will be maintained on the Red Hat Network proxy server to automatically install security updates for most systems unless there is a specific reason not to do so. This will be handled by CSE computing staff. If prompted to install updates by the update notification icon, or by the MCSS check script results failing, update the system as soon as possible. This includes any kernel updates.
Anti-Malware
Install the three ClamAV RPMs found in either of the following two URIs:
32 bit systems (“uname -m” does not show x86_64):
http://www.cse.ohio-state.edu/~rowland/mcss/clamav/rhel-5/i386/
64 bit systems (“uname -m” shows x86_64):
http://www.cse.ohio-state.edu/~rowland/mcss/clamav/rhel-5/x86_64/
Download all three RPMs and install them with the following command:
sudo rpm -ivh *.rpm
The command above assumes there are no other RPMs in the same directory. If there are, simply specify all three full filenames on the RPM command line. These RPMs might require other RPMs that are not on the device. If there is an error with the installation, contact CSE computing staff for help or attempt to install the needed packages with:
sudo yum install <package needed>
Once ClamAV is installed, delete the test files that come with the clamav RPM package manually:
sudo rm -r /usr/share/doc/clamav-0.92/test
In the future it might be necessary to use a CSE created
package to keep the anti-malware software up-to-date. For now, the 3rd
party supported anti-malware software will be utilized to meet MCSS compliance.
Authentication Controls
This should be fine by default, but do not do any of the following:
· Create an account with no password.
· Create an account with a weak password:
o Username: guest / Password: guest
o See “man passwd” for more information.
· Configure the graphical login screen to automatically login any account.
· Use the root account as a regular login account, instead make a normal user account for general use (this is the default anyway).
Install MCSS Software
The CSE computing staff are required to make MCSS compliance automated and auditable. These additional steps are necessary to meet these additional requirements, therefore these steps are required. Any changes or problems must be discussed with CSE computing staff before proceeding with MCSS certification. The first step is to download the rhel5-mcss-1.1.tar.gz package containing the necessary programs and configuration files:
http://www.cse.ohio-state.edu/~rowland/mcss/rhel5-mcss-1.1.tar.gz
Save this file to your normal user account’s home directory. If your home directory is mounted over NFS or a networked filesystem, do these steps in /tmp instead because root can’t normally access files over NFS or a networked filesystem mount, and that will cause problems. Once downloaded, extract the contents and move into the source directory with the following commands:
tar -vxzf rhel5-mcss-1.1.tar.gz
cd rhel5-mcss-1.1
Once in the rhel5-mcss-1.1 directory, run the installation script:
sudo ./install.sh
If the machine is a server that does not usually have a single user logged into it, run the following installation command instead:
sudo ./install.sh -s
The “-s” argument is only for servers. Do not use the server install argument on a desktop system.
The MCSS installation script does the following:
· Creates /root/mcss installation directory structure.
· Installs MCSS software.
· Sets up log rotation for /var/log/mcss.log and /var/log/anti-malware.log.
· Updates the PAM configuration to meet the MCSS appropriate authentication controls requirement.
· Schedules the anti-malware command to run at 4:30am every day.
· Schedules the mcss check command to run every 6 hours.
The anti-malware script runs the ClamAV software every day at 4:30am. The anti-malware configuration simply detects malware. It doesn’t modify, move, or copy suspected malware files. It is possible to get a false positive. It is also possible to put the paths to files and directories in the /root/mcss/malware-exclude file. Files and directories listed in that file will not be scanned, and there are notes in that file that explain this in more detail. If there is a false positive, put the full path to the file in /root/mcss/malware-exclude. Don’t simply put blanket directory exclusions for the parent directory unless there is a specific reason to do so. One example of when a full directory exclusion is appropriate is the case were a directory contains tar archives generated for some reason where it is absolutely known those aren’t malware. If unsure, please ask in advance. In addition, there are some default exclusions that should remain in the file. It is important to check this file for the last two sections concerning the /home directory and any other network filesystem mounts.
It is important that network filesystem mounts are excluded from scanning as this will generate unnecessary network traffic. If /home is mounted over NFS, its entry should be uncommented. Additionally, any other network filesystem mounts should be added at the bottom of the /root/mcss/malware-exclude file using the full path to the mount point with no trailing slash. See the comments in the /root/mcss/malware-exclude file for more details. Do not forget this step!
In the case of malware detection or an MCSS compliance check failure, a warning message is walled to all users and added to /etc/bashrc so that it will be seen on login. In addition, if an MCSS compliance failure is not fixed within seven days, after seven days the system will schedule a halt every time the MCSS compliance check fails. Once the problem is fixed and the MCSS compliance check passes again, the warning message will be removed and the system will remove the halt countdown. The server install option disables the notification and halt countdown, but these systems will be monitored more closely to ensure MCSS compliance.
After the installation, run the mcss check script interactively to make sure that it works and sees the previous configuration steps as making the system MCSS compliant:
sudo ./mcss -i
MCSS Check: Sun Jan 13 23:04:05 EST 2008
Firewall: pass
Software: pass
Malware: pass
Authentication: pass
If the above command shows anything other than the above output (except for the date being different), there is either a problem with MCSS compliance or the software needs some bug fix. In that case, run the uninstallation script:
sudo /root/mcss/uninstall.sh
and contact CSE computing staff so that the problem can be investigated. If the installation was successful and there were no error messages or failures when testing as noted above, the source files for the MCSS software can be removed. Do not remove the installed files in /root/mcss.
CSE Staff Account
All research machines are required to have a CSE staff account with full sudo access. Once all of the steps in this document have been followed, contact the CSE computing staff by sending a help request to help@cse.ohio-state.edu indicating that you need to have your RHEL5 system certified for MCSS compliance. Someone will come to your machine and verify everything is working, setup a CSE computing staff access account with full sudo access, and certify the system as MCSS compliant.