CS Security Guide: Difference between revisions

From Computer Science Wiki
Jump to navigation Jump to search
No edit summary
Line 12: Line 12:
#Admin accounts should lock after a specified period of inactivity (shorter durations is better).
#Admin accounts should lock after a specified period of inactivity (shorter durations is better).
#Accounts with Sudo access are just as dangerous if compromised.
#Accounts with Sudo access are just as dangerous if compromised.
=Passwords=
=Passwords=
==Complexity==
==Complexity==

Revision as of 15:37, 1 December 2020

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. These are 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.

Firewalls

General

Limit your ssh port access using a counter in combination with a time limit.  Unless a service needs to be public access, leave it blocked at the firewall.  Limit access to a specific IP address range for services that need remote access but should not be globally public.

Centos

IPTables or Firewalld should be used to prevent/limit outside access to ports and services.

Ubuntu

UFW can be used to do the same limitations as above for ubuntu.

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

Keys

Fail2Ban

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.

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.

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

Backups