Security Best Practices for Internet-Exposed Endpoints

The following article describes best practices and recommendations for reducing the security risk of internet-exposed endpoints. Following these recommendations can help you build a foundation on which to construct security practices for your endpoints.

In This Article

• Stay Up to Date
• Configuration
• Network Availability
• Authentication and Accounts
• Sources and Further Reading

Stay Up to Date

Many software providers offer mailing lists, RSS feeds, or other notifications for when new versions become available. Subscribing to these notifications can help you keep your software up to date while reducing the workload needed to constantly search for updates.

Keep all services, especially external-facing services, up to date. To accomplish this, you should review vulnerabilities on a regular basis to quickly identify and prioritize patches against vulnerabilities that pose the greatest risk.

Many applications and services have the option for automatic updates. The potential for issues originating from automatic updating should be weighed based on how a system is used and the criticality of the system’s availability. Where this is not possible, a structured patch management program should be in place to validate updates prior to deployment.

Recommendations

1. Subscribe to software update notifications from vendors.
2. Implement a patch and vulnerability management program.
3. Turn on auto-update wherever possible.

Configuration

Default to secure versions of protocols, such as SFTP instead of FTP and HTTPS instead of HTTP. This prevents a variety of attacks, including man-in-the-middle attacks. Disable the ability to downgrade to an insecure version of a protocol to prevent downgrade attacks. For example, disable SSH v1 and TLS 1.0.

Note: In order for Alert Logic to monitor and alert on SSL/TLS traffic, the certificate and key must be uploaded to the Alert Logic console and the cipher suite may not include any Diffie-Hellman-based ciphers. Alternatively, the encryption may be terminated prior to reaching the Alert Logic appliance.

It is good practice to log out idle users and close idle sessions. This limits exposure to session hijacking, which can be especially threatening if a user’s physical device becomes compromised. Common idle timeout ranges are 2-5 minutes for high-value targets and 15-30 minutes for lower-value targets.

Recommendations

1. Default to more secure versions of protocols.
2. Configure services to disconnect idle users.

Network Availability

Reduce your attack surface by limiting network access, including accessible addresses, ports, and services, to those required to run the business. A reduction in attack surface reduces the resources required to monitor the attack surface as a whole, allowing for focus on the threats that are most dangerous.

Recommendations

1. Only enable public-facing services on systems where they are absolutely necessary. For example, if hosting a website, only the ports serving the site – ports 80, 443, 8080, etc. – need to be open to the Internet.
2. Allow traffic only to/from trusted addresses and networks.
3. Allow access only to/from users who have already authenticated and connected securely, such as via VPN or RD gateway.
4. Deny connections by default and allow by exception. The default behavior of a system should be to deny access, allowing access only from trusted systems rather than allowing all access and denying known bad actors.

Authentication and Accounts

Enforce least privileged access for accounts, especially for automated processes. Do not give an account more access than it needs. Ideally, you should prefer keys and certificates over passwords. Additionally, you should require that the keys and certificates have a passphrase.

Note: In many cases (such as SSH), this must be enforced by internal policy rather than by system configuration.

For user sessions, implement multi-factor authentication (MFA). Keep in mind that requiring knowledge-based factors such as security questions in addition to a password does not constitute MFA, as both factors are knowledge-based. The secondary factor should be something possession-based (“something you have,” such as a smart card or security token) or biometric-based (“something you are,” such as a fingerprint or face scan).

Note: SMS-based MFA is vulnerable to attacks such as phone cloning or social engineering attacks against the cell provider.

Set expiration dates on keys and certificates. While password expiration is no longer recommended, key expiration is. Rotating keys does not require that users learn a new key and can be largely automated, requiring little or even no input from users.

Recommendations

1. Periodically review access, removing or reducing access where appropriate.
2. Disable login as the admin or root user and escalate privilege (e.g. with sudo) once connected, if necessary.
3. Trust relationships should not cross release environments. For example, the SSH keys for the testing environment should not work for the production environment. This prevents a compromise in one environment from spreading to another.
4. Implement brute-force protections such as Fail2Ban.

Sources and Further Reading

• NISTIR 7966 - Security of Interactive and Automated Access Management Using Secure Shell (SSH)
• NIST SP 800-131A Rev 2 - Transitioning the Use of Cryptographic Algorithms and Key Lengths
• NIST SP 800-46 Rev 2 - Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• NIST SP 800-171 Rev 1 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
• NIST SP 800-41 Rev 1 – Guidelines on Firewalls and Firewall Policy
• OWASP Session Management Cheat Sheet