The College of Engineering and Information Assurance (IA) recommend that you begin the process of hardening university servers, workstations, or databases by running the Center for Internet Security’s Configuration Assessment Tool—CIS-CAT. The tool will scan your system, compare it to an established benchmark, and then generate a report to help you harden your system. See CIS-CAT for U-M Systems for information about the UM-specific version of the tool. If you are permitted to access or maintain sensitive institutional data using a server that you manage, please meet the minimum expectations below.

Note that while the general instructions apply to most Unix/Linux systems, these specific configuration instructions are current for Red Hat Enterprise Linux 7. We hope to address those RHEL 6 settings that need to be updated (and/or those settings that CIS-CAT calls out that are ‘falsing’ or incorrect). By all means use the Editor of your choice, references to ‘nano’ are simply a suggestion here.

Configuration and Management

  • Set a system use or logon notification that references SPG 601.07.

To set a banner to appear on every attempted ssh connection before a login attempt:

  1. Open a terminal window and enter the command:
  2. sudo nano /etc/issue.net
  3. Add a sample message. This, for example, would be a good notification text for a server maintained by the university:
    • *******************************************************************************
    • * This is a University of Michigan Network.
    • * You must be authorized to use these resources. Unauthorized or criminal use
    • * is prohibited. By your use of these resources, you agree to abide by
    • * “Responsible Use of Information Resources (SPG 601.07),”in addition to all
    • * relevant state and federal laws.
    • * http://spg.umich.edu/policy/601.07
    • **************************************************************************************
  4. Edit the ssh configurations with the command:
  5. sudo nano /etc/ssh/sshd_config
  6. Look for the word “Banner” in the file, uncomment the line and make it “Banner /etc/issue.net”
  7. Exit nano with ctrl+x and press y to save. Your message will appear on all attempted logins.
    • Set your screensaver to activate after a period of inactivity and require your password to unlock it.

To configure the screen saver in RHEL 7:

1. Create “/etc/dconf/db/local.d/00-screensaver” with the following content:

[org/gnome/desktop/session]

idle-delay=uint32 180

[org/gnome/desktop/screensaver]

lock-enabled=true

lock-delay=uint32 300

# Set both values to the desired number of seconds

2. To prevent users from changing these settings, create “/etc/dconf/db/local.db/locks/screensaver” with the content:

/org/gnome/desktop/session/idle-delay

/org/gnome/desktop/screensaver/lock-delay

3. Update the dconf database with the command: dconf update

  • Install and use anti-virus software.

While not required, it is recommended that you use anti-virus software on your systems. Anti-virus is especially important if Windows or Mac clients upload/download files using a web application, email, and/or file services running on your server. Below are steps for using ClamAV, an available open-source anti-virus option. See the Viruses page for more guidance.

Install ClamAV open source antivirus

  1. Open a terminal window.
  2. To download ClamAV on an RHEL server, first enable the EPEL Repository. The way this is done depends on RHEL version and architecture. (For the appropriate command for your version and architecture, see Tecmint’s How to Enable EPEL Repository for RHEL/CentOS 7.x/6.x/5.x.) For example, to activate the EPEL Repository on RHEL 6 with a 64 bit architecture, use this command:
  3. sudo rpm -ivh epel-release-6-8.noarch.rpm
  4. Install ClamAV using this command:
  5. sudo yum install clamav clamav-db

Run a basic scan with ClamAV

  • Issue these commands to run a basic scan:
  • sudo freshclam
  • sudo clamscan -r –bell -i /

Configure daily scans with ClamAV

  1. Open the Daily Clam Options file using this command:
  2. sudo nano /etc/cron.daily/manual_clamscan
  3. Add the following lines to the file:
  4. #!/bin/bash
  5. SCAN_DIR=”/home”
  6. LOG_FILE=”/var/log/clamav/manual_clamscan.log”
  7. /usr/bin/clamscan -i -r $SCAN_DIR >> $LOG_FILE
  8. Exit nano with ctrl+x and press y to save.
  • Configure your host to synchronize time as a Network Time Protocol client.

It is a good idea to do this because many Internet services rely on the computer’s clock being accurate. Also, accurate time/date stamps in logged activity aids any forensics analysis and system troubleshooting.

Chrony is the default NTP daemon in RHEL 7.

1. Install the “chrony” package if absent

2. Configure “/etc/chrony.conf” to point at the University’s ntp servers by adding these lines:

server ntp1.itd.umich.edu

server ntp2.itd.umich.edu

server ntp3.itd.umich.edu

3. Enable and start the chrony daemon: sudo systemctl enable –now chronyd

  • Update the services and applications within 30 days of an official security patch release by a vendor.

Set up weekly auto updates:

  1. Install the “yum-cron” package
  2. Configure “/etc/yum/yum-cron.conf”
    1. Set up “update_cmd”
      1. “update_cmd = default” – Pull down all updates, equivalent of ‘yum upgrade’
      2. “update_cmd = security” – Only pull down packages marked as security updates in the yum metadata. Equivalent of ‘yum –security update’
      3. “update_cmd = security-severity:Critical – Only pull down critical security patches. Equivalent of ‘yum –sec-severity=Critical upgrade’
    2. Set up any email settings. Any package updates will be emailed to the defined recipients.
  3. Enable the ‘yum-cron’ service by running:
  4. $ sudo systemctl enable yum-cron.service
  • Back up your data.

The university offers the MiBackup service for server backups. The Sensitive Data Guide entry for MiBackup provides detail about which types of data can or cannot be backed up using the MiBackup service.

Backup Recommendations

  • Determine a backup schedule that works for you based on how frequently the data stored on the system changes.
  • The most recent full backup of the system should be stored off-site in case of disaster.
  • Run one full backup of the system once a week, and differential backups on every other day. Schedule the backups for times when the system is not in use to ensure that all files are captured and performance issues are avoided.
  • Test system restores using the backups on a regular basis.
  • Assign a Static or reserve a DHCP IP address and register a DNS name for your server.

Using ITS DNS is recommended. In addition, set up reverse DNS for the server and each service hosted on the server. Include email contact information in the DNS record. You can access Proteus through Bluecat to add this information.

  • Avoid running local versions of services such as DHCP, NTP, and DNS that ITS provides centrally.

The local versions of these services may create vulnerabilities for exploit or attack.

  • Request an SSL server certificate and enable its use by the web server.

You can order an SSL server certificate from UMWeb. Do not use default certificates in production.

  • Disable any unused or unnecessary features of the server or the service/application.

If they cannot be turned off, use a firewall to restrict access to services that can be installed/enabled by primary services—like DNS or NTP to U-M campus IP space.

  • Locate servers in an ITS-maintained data center.

ITS provides data center services and can house your servers using a service such as MiDatabase or MiServer.

If you are unable to use an ITS-maintained data center, follow these expectations:

  1. Secure physical server access. Keep your server in a physically locked space. Do not keep your server in a publicly accessible location.
  2. Maintain constant power. For the safety of the server equipment and the data stored on it, use an uninterruptible power source to supply power to the server.
  • Dispose of safely and securely.

Before decommissioning the server hardware, securely erase the data from the system. See Prepare Devices for Disposal.

Access and Accounts

  • Require a password for access to the machine and single user boot.

Follow these guidelines for a strong password. Unauthenticated access should not be permitted, whether by unauthenticated web servers, anonymous ftp servers, or open network shares which allow access to the server’s file system.

Require Password Authentication

  1. Open a terminal window and copy the system authentication folder into working directory with this command:
  2. sudo cp /etc/pam.d/system-auth /etc/pam.d/system-auth.ORI
  3. Edit the file by issuing this command:
  4. sudo nano /etc/pam.d/system-auth
  5. From the line that reads:
  6. auth sufficient /lib/security/pam_unix.so likeauth nullok
  7. remove ” nullok” so that the line reads as follows:
  8. auth sufficient /lib/security/pam_unix.so likeauth
  9. Exit nano with ctrl+x and press y to save.
  • Change default or vendor-supplied passwords to secure and unique passwords.

Require first-time users to change their default password.

  • When you provide a user with access to a machine, it is important that they set their own account password rather than sticking with the default. Set this requirement for each user.
    • Open a terminal window and issue the following command:
    • sudo chage -d 0 {username} This only applies to local accounts.
  • Disable or remove guest and default accounts.

Best practice is to not allow guest, default or shared accounts access to the machine. Verify that there are no suspicious accounts in the /etc/passwd file.

  • Disable root login / su – and implement sudo.

Implementation of sudo will allow privileged access as required and will log all such activity and link specific actions to specific individuals. It also avoids shared root accounts, which can make it more difficult to securely deprovision access for an individual or contain security incidents involving compromised credentials.

Note: Many Linux distributions already implement the no root login feature and force the use of sudo. If the distribution you are using does not already support sudo, install the sudo package and configure it appropriately (ensure “su -” does not switch user to root. Consider bash, vi, and other apps that can shell out to root).

Prevent Remote Root Logins via the SSH Protocol

  1. Open a terminal window and edit the SSH daemon’s configuration file (/etc/ssh/sshd_config) using this command:
  2. sudo nano /etc/ssh/sshd_config
  3. Find the line that reads:
  4. PermitRootLogin yes
  5. and change it to this:
  6. PermitRootLogin no
  7. Exit nano with ctrl+x and press y to save.
  8. Stop and restart the SSH Daemon using these commands:
  9. service sshd stop
  10. service sshd start
  • Restrict server and application access whenever possible.
  1. Restrict access to the application through groups or sudo. Create an account exclusively for the daemon with specific, limited rights.
  2. Avoid using administrative or root level accounts to run the daemon or services.
  3. Accounts that access or administer the server should have the minimum permissions necessary to conduct the appropriate functions. (I.e., specify who may, and who may not run cron jobs)
  • Require centralized authentication.

Avoid using local accounts for authentication into any service or application hosted on your server or the server daemon itself. Instead, use directory-based accounts, such as U-M Kerberos accounts. Do not allow authentication with shared accounts.

  • Implement account lifecycle management procedures to remove access of employees and collaborators that no longer require access to the server or applications.
  • Remove ctrl-alt-del option to restart server.

To disable the default behavior of ctrl-alt-del rebooting the machine on a non-GUI system: systemctl mask ctrl-alt-del.target

To disable ctrl-alt-del for all users using a graphical interface:

1. Create “/etc/dconf/db/local.d/00-disable-CAD” with the following content:

[org/gnome/settings-daemon/plugins/media-keys]

logout=”

2. Update the dconf database with: dconf update

Starting with RHEL 7.4 there’s also the CtrlAltDelBurstAction to define system behavior upon

multiple successive Ctrl-Alt-Delete presses.

To disable any response edit the CtrlAltDelBurstAction line in “/etc/systemd/system.conf” to say:

CtrlAltDelBurstAction=none

  • Force session timeouts.

Regularly disconnect sessions idle more than two hours using a scheduled task or other methods.

The autologout file below will implement a 120-minute idle timeout for the default /bin/bash shell. Note that TMOUT can be set to 300 to implement a 5-minute idle timeout and so on.

  1. Open a terminal window.
  2. Create a file called /etc/profile.d/autologout.sh by issuing this command:
  3. sudo touch /etc/profile.d/autologout.sh
  4. Edit the file using this command:
  5. sudo nano /etc/profile.d/autologout.sh
  6. Append the following:
  7. TMOUT=7200
  8. readonly TMOUT
  9. export TMOUT
  10. Exit nano with ctrl+x and press y to save
  11. Set permissions with this command:
  12. sudo chmod +x /etc/profile.d/autologout.sh

The autologout file below will implement a 120-minute idle timeout for the C shell.

  1. Open a terminal window.
  2. Create a file called /etc/profile.d/autologout.csh by issuing this command:
  3. sudo touch /etc/profile.d/autologout.csh
  4. Edit the file using this command:
  5. sudo nano /etc/profile.d/autologout.csh
  6. Append the following:
  7. # Log out after 2 hours, as recomended by
  8. # https://safecomputing.umich.edu/hardening
  9. set -r autologout=120
  10. Exit nano with ctrl+x and press y to save
  11. Set permissions with this command:
  12. sudo chmod +x /etc/profile.d/autologout.csh

If you need to leave your session open, you can run “screen” or “top,” to prevent the session from being idle and logging you out. This should be done only when necessary to prevent autologout from interfering with your work.

  • Enable two-factor authentication, especially if the system will be storing sensitive data.

To implement two-factor authentication using Duo, see instructions:

https://documentation.its.umich.edu/2fa/duo-unix-ssh-installation-directions

Monitoring

  • Configure the logging for unique services, and syslog for the server system itself.

If using remote logging, then ensure the data is encrypted in transit.

Configure Service Audit Log

  1. If you have not done so, install the syslog package with this command:
  2. sudo yum -y install rsyslog
  3. Edit syslog configurations with this command:
  4. sudo nano /etc/rsyslog.conf
  5. To enable listening on the UDP and TCP ports, remove the comment symbol # before each $ModLoad statement and each ServerRun statement to get this:
  6. $ModLoad Input
  7. $UDPServerRun 514
  8. ……
  9. $ModLoad imtcp
  10. $InputTCPServerRun 514
  11. Exit nano with ctrl+x and press y to save.
  12. Restart the syslog service to make the changes take effect with this command:
  13. sudo service rsyslog restart
  14. Configure the machine to send logs to a central server by opening syslog configurations with this command:
  15. sudo nano /etc/rsyslog.conf
  16. At the end of the file, append the following line to point the client message log to the server:
  17. *.info;mail.none;authpriv.none;cron.none @192.168.0.105
  18. Exit nano with ctrl+x and press y to save.

Note that you can either mention hostname or ip address. All message logs will be sent to a central server as well as copied locally.

  • Log authentications for services or applications housed on the server using a centralized logging system. Enable login auditing of failed and successful login attempts.
  • Enable Enforcing SELinux, or Permissive SELinux if restrictions prevent use of enforcing mode.
  • Increase audit log size to accommodate the increased activity occurring on a server.

Configure logs to start a new log file each day, and retain at least the last 30 days of log files.

  • Configure notifications to alert the system owner or administrator when the system stops or restarts.
  • Monitor file system modifications for unauthorized changes using a binary file integrity check service such as tripwire or aide.
  • Detect and monitor brute force attempts by using a service such as Fail2ban to monitor your logs for failed remote attempts and prevent brute force password attacks.

Monitor Using Fail2ban

  1. Open a terminal window.
  2. If you have not already installed Fail2ban, install it with this command:
  3. sudo yum install fail2ban
  4. Copy the configuration file for editing
  5. cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
  6. Modify the configuration file using this command:
  7. sudo nano /etc/fail2ban/jail.local
  8. The defaults should be sufficient for most servers, but you can adjust features such as ban time, attempts before ban, and which addresses are always blocked. Detailed instructions for how to do so are included in /etc/fail2ban/jail.conf.
  9. Exit nano with ctrl+x and press y to save.
  • Report security incidents.

If your server or associated devices are compromised, stolen, or otherwise accessed in an unauthorized manner, report it as a security incident.

Connections

  • Enable your local firewall, if it is not on by default.

Firewalld is the default firewall in RHEL 7. Ensure it is installed via “yum install firewalld” before ensuring it is enabled with “systemctl enable –now firewalld”.

A list of U-M subnets can be found at UMnet.

  • Disable unused optional network connections such as Wi-Fi or Bluetooth.

Disable Wireless

  1. Open a terminal window.
  2. Use the following command to list all interfaces using a wireless connection:
  3. ifconfig -a
  4. Go through the list and disable each one that is unused. Modify /etc/sysconfig/network-scripts/ifcfg-$DEVICENAME (where $DEVICENAME is the device to disable) to permanently disable wireless on a device. You may need to disable mutliple devices, depending on your particular system.

Disable Bluetooth

To disable the bluetooth kernel modules from being loaded automatically:

echo “install bnep /bin/true” >> /etc/modprobe.d/disable-bluetooth.conf ​echo “install bluetooth /bin/true” >> /etc/modprobe.d/disable-bluetooth.conf ​echo “install btusb /bin/true” >> /etc/modprobe.d/disable-bluetooth.conf

You can then/also disable the bluetooth service with: systemctl disable bluetooth.service

Other services you might want to disable:

  • cupsd or lpd (if not running a printer)
  • xinetd
  • Connect securely to the server.

Do not use insecure or clear text protocols to authenticate to the server. If insecure methods must be used, restrict server access to specific IP addresses or the U-M campus network using iptables. Use an SSH tunnel or another encryption method to protect the data in transit.

Cleartext Services/Protocols to Avoid

Avoid using these cleartext services/protocols to connect to your Linux server:

  • FTP
  • Telnet
  • etc.

Should you have a business case for using one of these services/protocols, you should restrict access to specific networks and IP addresses.

Copy Files Between Systems Securely

  • To securely copy files between systems it is highly recommended that you use the scp command. This command is used in the form:
  • scp [email protected]:foobar.txt /some/local/directory
  • Where scp [email protected]:foobar.txt /some/local/directory is your destination, foobar.txt is the file you are trying to send, and /some/local/directory is the destination directory in the destination account.
  • Limit network access to the service to LAN or U-M campus networks only, by using the local or a gateway-style firewall. Run a port scan of the system to confirm that ports are properly protected.
  • Require VPN connections.

Configure the firewall (iptables) to allow access from the U-M virtual private network (VPN) and appropriate campus networks.

Configure Firewall to Allow VPN Access

  1. Open a terminal window.
  2. First flush old rules with this command:
  3. iptables -F
  4. Block everything except the rules you’re about to make with the following three commands:
  5. iptables -P INPUT DROP
  6. iptables -P FORWARD DROP
  7. iptables -P OUTPUT DROP
  8. Allow loopback access using these two commands:
  9. iptables -A INPUT -i lo -j ACCEPT
  10. iptables -A OUTPUT -o lo -j ACCEPT
  11. Accept the U-M VPN with this command:
  12. iptables -A INPUT -s 141.213.168.0/21 -j ACCEPT
  13. Finally, make sure that all incoming and outgoing traffic is using the VPN with these commands:
  14. iptables -A INPUT -j ACCEPT -p udp s Y.Y.Y.Y –sport 1194
  15. iptables -A OUTPUT -j ACCEPT -p udp d Y.Y.Y.Y –dport 1194
  16. Save your iptables rules to the file that is loaded by the iptables service:
  17. iptables-save > /etc/sysconfig/iptables
  18. Start iptables with this command:
  19. service iptables start

Additional information about U-M subnets can be found at UMnet.

  • Restrict access to remote access management cards (such as IPMI interfaces used by system administrators for out-of-band management) to U-M campus networks and require use of the U-M VPN for off-campus access.

Other Things to Consider

  • Monitor File System Details with Tripwire or AIDE
  • If using Network File System (NFS), use NFS version 4 or later and restrict direct NFS mounts to specific campus IPs.
  • NFS mount is ‘squashed root’ by default, ensure that it is set to that. nfs mount root_squash
  • Whether RHEL or some other flavor of Unix, monitor and limit user resources and processes where appropriate (to help prevent fork bombs, for example).
  • Enable full disk encryption.

You can encrypt the hard drive, partitions on the hard drive, or files and file directories. Hard drive encryption can be set up during the installation of the operating system.

  • Partition hard drive.

Isolate sensitive data on separate hard drive partition/s. Isolate boot and critical OS files on separate partitions, and ensure the boot partition is set to read-only to reduce the risk of unauthorized modifications to boot files (root write access only).

  • Restrict boot source in BIOS.

Configure BIOS to disable boot from CD/DVD, external devices (USB), or from a floppy drive if the physical security of the server could be compromised, and set a BIOS password to further restrict access to the system.

  • Add bootloader (GRUB 2) password
    1. Run the grub2-setpassword command as root:
    2. ~]# grub2-setpassword
    3. Enter and confirm the password:
    4. Enter password:
    5. Confirm password:

Following this procedure creates a /boot/grub2/user.cfg file that contains the hash of the password. The user for this password, root, is defined in the /boot/grub2/grub.cfg file. With this change, modifying a boot entry during booting requires you to specify the rootuser name and your password.

  • Regularly scan the server for vulnerabilities.

IIA offers free monthly vulnerability scans.

  • Check the Sensitive Data Guide to confirm that your server is eligible to access or maintain the type(s) of sensitive data it is storing or processing.

Checking the Sensitive Data Guide is especially important if your server is a virtual machine.

If you are accessing or maintaining Credit Card or Payment Card Information (PCI) or Protected Health Information (PHI) on your server, you should consult with IIA to determine if your server is approved.

  • Centrally manage anti-virus and update utilities.

This is especially important if the server network is large or distributed. Send anti-virus logs to a centralized logging system such as splunk.

  • Use appropriate settings or controls to ensure that sensitive data accessed or maintained by your server cannot be cached to client systems connecting to your server.

Additional Resources

Thanks to Jonathan Billings and Dakota Lambert for their help with this Guide – and for prompting an update and review.