Secure Your Linux/Unix Server

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 these instructions generally apply to most Unix/Linux systems, the specific instructions shown are current for Red Hat Enterprise Linux 7. You can use the command-line text editor of your choice; examples using 'nano' are shown below.


Start with CIS-CAT

Information Assurance (IA) recommends 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 a preset benchmark, and then generate a report to help guide further hardening efforts. See CIS-CAT for U-M Systems for information about the UM-specific version of the tool.

Check the Sensitive Data Guide and Minimum Information Security Requirements

Use 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. If you are accessing or maintaining data classified as Restricted or High on your server, you should consult with IA by contacting the ITS Service Center

Use the Minimum Information Security Requirements for Systems, Applications, and Data to see a summary of requirements spelled out in U-M's Information Security policy (SPG 601.27) and the U-M IT security standards.

Configuration and Management

Enable full disk encryption.

Full disk encryption is recommended for all U-M servers, and is required for some. For systems storing sensitive data, refer to Encryption (DS-15) for requirements for encrypting U-M data. Encryption can be used on entire drives, partitions a drive, or directories and files, and can be enabled during operating system installation and configuration.

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:
    sudo nano /etc/
  2. 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.

  3. Edit the ssh configurations with the command:
    sudo nano /etc/ssh/sshd_config
  4. Search for Banner in the file and uncomment the line it appears in.
  5. Add a new line:
    Banner /etc/
  6. Exit nano using 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 the file /etc/dconf/db/local.d/00-screensaver with the following content:​
    idle-delay=uint32 180

    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:
  3. Update the dconf database with the command: dconf update

Install and use antivirus software.

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 Endpoint Protection page for more guidance. 

Install ClamAV open source antivirus

  1. Open a terminal window.
  2. Download ClamAV. You may need to enable the EPEL Repository to download it. 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:
    sudo rpm -ivh epel-release-6-8.noarch.rpm
  3. Install ClamAV using this command:
    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:
    sudo nano /etc/cron.daily/manual_clamscan
  2. Add the following lines to the file:
    /usr/bin/clamscan -i -r $SCAN_DIR >> $LOG_FILE
  3. Exit nano with ctrl+x and press y to save.

Configure your host to synchronize time as a Network Time Protocol client."

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:
3. Enable and start the chrony daemon with the command:
   sudo systemctl enable --now chronyd

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

To set up auto updates:

  1. Install the yum-cron package
  2. Configure /etc/yum/yum-cron.conf
  3. Set up update_cmd using the following commands:
    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'
  4. Set up email settings. Any package updates will be emailed to the defined recipients.
  5. Enable the yum-cron service by running:
    $ 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. Contact the U-M Hostmaster if you need assistance.

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:

  • Secure physical server access. Keep your server in a physically locked space. Do not keep your server in a publicly accessible location.
  • 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.

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 a working directory with this command:
    sudo cp /etc/pam.d/system-auth /etc/pam.d/system-auth.ORI
  2. Edit the file by issuing this command:
    sudo nano /etc/pam.d/system-auth
  3. Find the line that reads:
    auth sufficient /lib/security/ likeauth nullok
    remove nullok so that the line reads as follows:
    auth sufficient /lib/security/ likeauth
  4. Exit nano with ctrl+x and press y to save.

Change default or vendor-supplied passwords to secure and unique passwords.

Always change passwords to ones of your own choosing. IA recommends use of a password manager to help create and track secure 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 command 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:
    sudo nano /etc/ssh/sshd_config
  2. Find the line that reads:
    PermitRootLogin yes
    and change it to this:
    PermitRootLogin no
  3. Exit nano with ctrl+x and press y to save.
  4. Stop and restart the SSH Daemon using these commands:
    service sshd stop
    service sshd start

Restrict server and application access whenever possible.

  • Restrict access to the application through groups or sudo. Create an account exclusively for the daemon with specific, limited rights.
  • Avoid using administrative or root level accounts to run the daemon or services.
  • 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.

Promptly 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

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 the command:
    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:

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/ by issuing this command:
    sudo touch /etc/profile.d/
  3. Edit the file using this command:
    sudo nano /etc/profile.d/
  4. Append the following:
    readonly TMOUT
    export TMOUT
  5. Exit nano with ctrl+x and press y to save.
  6. Set permissions with this command:
    sudo chmod +x /etc/profile.d/

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:
    sudo touch /etc/profile.d/autologout.csh
  3. Edit the file using this command:
    sudo nano /etc/profile.d/autologout.csh
  4. Append the following:
    # Log out after 2 hours, as recomended by
    set -r autologout=120
  5. Exit nano with ctrl+x and press y to save.
  6. Set permissions with this command:
    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: Duo Unix SSH Installation Directions


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.

To Configure Service Audit Log

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

Remeber to 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.

Alerts should go to a group (multiple persons) if possible.

Monitor file system modifications for unauthorized changes.

Use a binary file integrity check service such as Tripwire or Aide.

Monitor and detect brute force attempts

Use a service such as Fail2ban to monitor your logs for failed remote access attempts and to 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:
    sudo yum install fail2ban
  3. Copy the configuration file for editing using this command:
    cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
  4. Modify the configuration file using this command:
    sudo nano /etc/fail2ban/jail.local
    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.
  5. 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.


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

Firewalld is the default firewall in RHEL 7. If it is not installed, install with the command:
yum install firewalld
Ensure it is enabled with the command:
systemctl enable --now firewalld

    A list of U-M subnets can be found at UMnet to assist configuring the firewall to access U-M resources.

    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:
      ifconfig -a
    3. 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, and you should restrict access to specific networks and IP addresses when using them.

    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 /some/local/directory
      Where scp /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 services to your LAN or U-M campus networks only 

    Use the local or network gateway firewall to limit connections from unknown and unwanted locations. 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:
      iptables -F
    3. Block everything except the rules you're about to make with the following three commands:
      iptables -P INPUT DROP
      iptables -P FORWARD DROP
      iptables -P OUTPUT DROP
    4. Allow loopback access using these two commands:
      iptables -A INPUT -i lo -j ACCEPT
      iptables -A OUTPUT -o lo -j ACCEPT
    5. Accept the U-M VPN with this command:
      iptables -A INPUT -s -j ACCEPT
    6. Finally, make sure that all incoming and outgoing traffic is using the VPN with these commands:
      iptables -A INPUT -j ACCEPT -p udp s Y.Y.Y.Y --sport 1194
      iptables -A OUTPUT -j ACCEPT -p udp d Y.Y.Y.Y --dport 1194
    7. Save your iptables rules to the file that is loaded by the iptables service:
      iptables-save > /etc/sysconfig/iptables
    8. Start iptables with this command:
      service iptables start

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

    Restrict access to remote access management cards

    Limit access to devices such as IPMI interfaces used by system administrators for out-of-band management. Limit access to U-M campus networks and require use of the U-M VPN for off-campus access.

    Other Things to Consider

    Restrict direct NFS mounts to specific campus IPs.

    If using Network File System (NFS), use NFS version 4 or later, and limit direct mounts to campus. NFS mount is 'squashed root' by default, ensure that it is set to that. nfs mount root_squash .

    Limit user resources and processes where appropriate.

    Whether RHEL or some other flavor of Unix, monitor and limit user resources and process. This helps to prevent fork bombs, for example.

    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:
        Enter password:
        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.

    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.

    Dispose of old equipment safely and securely.

    Before decommissioning the server hardware, securely erase the data from the system. See Erase or Destroy U-M Devices.

    Additional Resources

    Last Updated: 
    Wednesday, April 14, 2021