All UC Berkeley IT Resources and all devices connected to the UC Berkeley network or cloud services must comply with the Minimum Security Standard for Networked Devices (MSSND). The Implementation Requirements below are provided as guidance to assist with achieving the Remote Access Services Requirement.
MSSND Remote Access Services Requirement
Remote access to systems:
Remote desktop, interactive shell, or terminal-level access that allows broad access from the public Internet to a system is not allowed and must be restricted. Indirect access using a gateway or proxy service approved for campus use by the CISO is allowed. Remote access using a configuration approved though documented Unit policy that meets the configuration requirements below is also allowed.
Remote access to the UC Berkeley network:
Only remote access services, such as proxy servers and VPN gateways, whose configuration and use have been approved by the CISO, or through documented Unit policy, are allowed to provide broad access to the UC Berkeley network from the public Internet. These remote access services must meet the configuration requirements below.
Configuration requirements:
All approved remote access to individual systems or the UC Berkeley network must be configured according to the Remote Access Services Guideline.
Scope clarification:
This requirement does not apply to:
- sessions where access is restricted to a limited number of trusted hosts
- sessions where access is from one campus host to another
Background and Description of Risk
Services that provide remote access to systems (e.g., desktop, shell) or to the UC Berkeley network from the public Internet are high-value targets for attackers. When these services are open to the Internet, attackers may be able to compromise credentials, the system, or put other systems at risk by:
- Exploiting vulnerabilities in the remote access service itself (e.g., BlueKeep vulnerability) or its underlying protocols
- “Pivoting” to attack additional systems and applications on the UC Berkeley network and other connected networks
- Compromising CalNet credentials and other user accounts through (not limited to):
- Credential stuffing: Testing username/password pairs obtained from the breach of another site (made possible by users re-using passwords)
- Password spraying: Testing a single weak password against a large number of different accounts
- Brute-force attacks: Testing multiple passwords from a dictionary or other source against a single account
- Exploiting Service Providers’ infrastructure and software (e.g., vendor-managed remote access services and products)
- Creating Denial of Service (DoS) conditions such as locking out legitimate user accounts after many failed logins
Therefore, it is very important that remote access services are protected from attackers on the public Internet.
Implementation Requirements
1. Use Campus-Approved Remote Access Services
-or-
2. Use Unit-Approved Remote Access Services That Meet The Following Guidelines
Quick links: | A. Unit Approval | B. General Guidelines for All Implementations | C. Microsoft RDP Guidelines | D. SSH Guidelines |
A. Unit Approval
Units may approve remote access configurations through documented policy that meets the implementation requirements in this Guideline. A Unit's policy must, at a minimum, document:
- The Unit's decision to allow remote access configurations that meet the MSSND Remote Access Services Guideline
- Any additional requirements the Unit may have
B. General Guidelines for All Implementations
These guidelines apply to all remote desktop, interactive shell, and terminal-level access services. Examples include: Microsoft Remote Desktop Protocol (RDP), SSH, Apple Remote Desktop, VNC. They also apply to services such as remote administration of virtual machines, remote KVM, and console servers.
i. Restrict Network Access Using a Firewall:
- Inbound connections to remote access service ports should be denied by default whenever possible
- Reduce the attack surface. Only authorized hosts and/or networks should be explicitly permitted to connect to remote access services
- Remote access services should not be opened to the public Internet without a business need to do so
ii. Multi-Factor Authentication (MFA):
- Remote access services that are open to the Internet must use MFA (described below).
- MFA must be sufficiently strong. Examples of acceptable forms of MFA (or the equivalent) include:
- Two-Factor Authentication such as Duo 2FA -- e.g., mobile app, hardware token such as YubiKey
- One-Time Password implementations such as Google Authenticator, Twilio Authy, or FreeOTP
- Note: Time-Based One-Time Passwords (TOTP) are preferred over HMAC-Based One-Time Passwords (HTOP)
- FIDO standard smart cards or hardware tokens
- SSH public/private keypair with a password set (password encryption) - passwords must meet campus passphrase requirements
- Additional MFA guidance for Microsoft RDP and SSH is below
iii. Logging:
- Remote access service logs must log both successful and failed login attempts
- Logs must identify the source IP address for connection attempts
- Logs must be retained a minimum of 90 days. However, one year or more is recommended.
- Systems handling P3 or P4 data must adhere to all applicable MSSEI logging requirements, including sending relevant logs to the campus Log Correlation Program.
C. Microsoft RDP Guidelines
- Individual remote access services such as RDP can be accessible from the campus VPN, Campus RD gateway, or approved Unit gateway, but should otherwise be restricted using a network or host-based firewall.
- If you do not utilize an approved Campus or Unit RD gateway, enforcing a MFA and logging configuration as described above is required for opening an individual RDP system up to the Internet.
- Detailed recommendations for securing Remote Desktop
D. SSH Guidelines
i. Restrict Access:
- Restrict access to SSH servers from the Internet as much as possible using firewalls or other network-based access controls.
ii. User Accounts (providing shell access):
- SSH servers may be open to the Internet if the above Multi-Factor Authentication (MFA) and logging requirements are being met.
- Escalation of privileges on the SSH server should require a unique password, separate from the password used to protect an SSH key.
iii. Service Accounts:
- Service accounts used to automate tasks (e.g. SCP, SFTP, remote commands) are exempt from requiring MFA provided the accounts:
- Do not permit interactive login sessions
- The SSH configuration limits what commands the service accounts are permitted to execute on the remote system
- Where possible, restrict usage of service accounts to the fewest network sources possible
- Service accounts must use SSH keys and not password-based authentication
iv. SSH Key Management Guidelines
- Visit our SSH Key Management page for detailed instructions.
v. Additional guidance for securing SSH
- The Information Security Office (ISO) has received requests for specific copy-paste configuration directives that SSH users could use to ensure they comply with this Standard. Because there are multiple ways this Standard can be met, and compliance is Unit-specific, there is not a single set of configurations that are recommended for all implementations. Instead, work with your unit's IT support or Unit Information Security Lead (UISL) to determine the correct SSH settings for your environment, application, and risk profile.
- As outlined in Section 2 above, Units may approve remote access configurations internally through documented policy that meets the implementation requirements in this Guideline. One example is IRIS' SSH Server Configuration information for EECS.
Scope Clarification
Examples of situations where this requirement applies:
- A workstation or server with remote desktop services (such as RDP or VNC) open to the Internet
- A VPN service
- A departmental SSH server that allows connections from the public Internet
Examples of situations where this requirement does not apply:
- Remote access is restricted to a limited number of trusted hosts
- Remote access is restricted to one off-campus IP address or a small range of off-campus IP addresses
- Access is from one campus host to another
- The installation of routers, switches, and other network devices that extend the internal network without providing external access
- Attended connections that are initiated from the campus network (e.g. outbound remote desktop, video conference screen sharing, etc.) [1]
- Remote support sessions that are initiated by the person requesting the support [1]
- Remote access only from Airbears/eduroam (these are campus networks)
[1] NOTE: Third-party services used to facilitate remote access must follow applicable Procurement data security policies and procedures.