CS Security Guide: Difference between revisions
Line 8: | Line 8: | ||
==Admin Access== | ==Admin Access== | ||
Admin access can be defined as anyone who has an administration account, sudo access, or access to the root account. | Admin access can be defined as anyone who has an administration account, sudo access, or access to the root account. | ||
#Admin access should be restricted to as few people as necessary. | |||
#Where possible only use an Admin account for the duration of the changes necessary then return to a lower privileged account. | |||
#Admin accounts should lock after a specified period of inactivity (shorter durations is better). | |||
#Accounts with Sudo access are just as dangerous if compromised. | |||
=Passwords= | =Passwords= | ||
==Complexity== | ==Complexity== |
Revision as of 14:36, 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.
- Admin access should be restricted to as few people as necessary.
- Where possible only use an Admin account for the duration of the changes necessary then return to a lower privileged account.
- Admin accounts should lock after a specified period of inactivity (shorter durations is better).
- 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.
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