CS Security Guide: Difference between revisions
| Line 30: | Line 30: | ||
=Databases, NFS Shares, and Printers= | =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). | 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= | =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). | 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). | ||
Revision as of 12:12, 4 October 2021
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.
- 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
Guidelines
- 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
- Common/Default Passwords - Most password lists include common and default passwords (ie: password, toor, admin, etc) If a device has a documented default password it is most likely included on the lists.
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.
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.
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.
| 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
Linux Security & Hardening Essentials