CS Security Guide

Introduction

This document was created with the purpose of assisting new administrators in maintaining secure research systems within the department. It represents the views of the technical staff at the time of publication, and should be viewed as a starting point for security and not a comprehensive document. 

Scope

The scope of this document is limited to only the most basic of security recommendations. These are intended to be quick wins that will stop the largest portion of passive threats to our networks. This includes the things that the Security Office is scanning for. As such you will not find suggestions or instructions on how to secure a specific service (Such as Apache, MySQL or anything similar). If you want more information on those topics there are pages of documentation that can assist you. 

Responsibility

It is the responsibility of any user granted Root (or Administrator) Access, to ensure that the System in question is as secure as possible from outside threats.  (Policy 7010)

Admin Access

Admin access can be defined as anyone who has an administration account, sudo access, or access to the root account. 

1. Admin access should be restricted to as few people as necessary.
2. Where possible only use an Admin account for the duration of the changes necessary then return to a lower privileged account.
3. Admin accounts should lock after a specified period of inactivity (shorter durations is better).
4. Accounts with Sudo access are just as dangerous if compromised.

Passwords

Complexity

Secure passwords feature a number of special characters, numbers, and a mix of upper and lowercase letters (8+ Characters), or are of significant length (16+ Characters). Even following these complexity rules can result in a password that is insecure. For instance take a “four seasons” password (Example: Winter2020! ) This password is 11 characters long, features mixed-case, numbers and a special character, and yet exists in common password lists. 

Sharing

Do not share passwords for your personal account or an admin account. It is also recommended not creating a shared account. 

Reuse

Do not reuse passwords, especially for accounts with Admin Privileges. This means do not use the same password for more than one account. And it also means do not change back to the password at a later time.

Checking for Compromise

A variety of password managers will review your list of passwords periodically against a list of compromised passwords to ensure that your password doesn't appear in a dictionary that attackers are using. You can also check at a variety of websites the standard being HaveIBeenPwned

Firewalls

It is recommended that you use a firewall to secure any open ports on your Server/Virtual Machine. The baseline recommendation for this is to restrict access to only the campus networks. Since there are a number of options available and different options for each operating system instructions on how to set up a firewall goes beyond the scope of this document. Please refer to the Howto::Firewall page listed below for more information.

Howto::Firewall

Databases, NFS Shares, and Printers

These services almost never need public internet access and should be among the first ports you restrict access to with your firewalls or Access Control Lists (Printers). 

SSH

Based on recent attack history, SSH brute forcing tends to be one of most common infiltration methods we have been seeing. Often times in relation to insecure password generation (see above).

Keys

The IT Security Office currently recommends the use of SSH keys requiring a password as the preferred method of securing root access and providing multifactor authentication for remote access.

4help - SSH Key Guide

Fail2Ban

There are guides on using fail2ban to dynamically block an IP that is making repeated failed login attempts through SSH. This would limit the effectiveness of password spray attacks and brute forcing.

Unneeded Public Services

Common sense goes a long way here, if you installed a service which people can connect to from outside of campus and are no longer using it, disable the service. The smaller attack surface you present to the outside world the less options you give an attacker. 

Patching

Patching is important for securing applications and operating systems. This is extremely important for systems that have public facing services. If there is a security patch for one of your services, there is a pretty good chance that it has been found to be vulnerable and could potentially be used to exploit your system.

Operating System End of Life

This topic is similar to patching but more serious. As OS developers strive to improve their OS it becomes essential to drop support for older versions to focus on the newer versions. When this happens an OS stops receiving important updates and security patches. Any new vulnerabilities found in the system going forward are not serviced and the system becomes less secure as time goes on.  Please use a current operating system.  If your operating system is no longer supported or the provider is no longer providing security patches for your OS, you need to upgrade or reinstall.

We have a page established for Operating system End of Life Dates which can be found here Operating System End of Life.

Exposed Files

Lately ITSO has been scanning systems with open ports for specific files. Each time one is found they alert us and open a security ticket. These files either give an attacker information about the environment or in more serious cases can occasionally contain passwords.  Below is a list of these files and their services.

Caption: Exposed Files Table

Exposed File	Service	Suggested Remediation
.env	Python & Django	Remove or Restrict Access
.git	github	Restrict Access to the folder containing this file in Apache
.htaccess	Apache & nginx	Restrict Access to this file in your configuration

Backups

One of the most common attacks in the Education sector right now is Ransomware. The best defense against having to pay to decrypt your data is having an up to date offsite backup. That said it is important to think about your backup strategy long before the need to restore arises.

Currently our recommendation is Nightly backups for 7 days and weekly snapshots for a month, then monthly snapshots.

Hardening Scripts

Here are a couple of example scripts to help get you started.
- (Ansible)
- (Bash)

Training

Below are some links for training.

Linux Training

LinkedIn Learning [1]

MacOS

Apple Support [2]

Windows 10

LinkedIn Learning [3]