Preferred Server security recommendations

Recommended Security Best Practices for Preferred Server Configuration

This article outlines critical security recommendations for configuring Preferred Servers to ensure a secure and efficient application of updates in your environment. These guidelines address the use of HTTPS and SMB protocols, proper authentication methods, FQDN (Fully Qualified Domain Name) requirements, and configurations that minimize risks associated with insecure connections.

Key Security Recommendations

1. Avoid Using IP Addresses

   Preferred Servers must be configured to use Fully Qualified Domain Names (FQDNs) instead of raw IP addresses. This ensures compatibility and security across protocols:

   • For HTTPS:

     • Certificates must match the FQDN of the server. Using an IP address for the server URL will invalidate the certificate.

     • An invalid certificate can compromise data integrity, and disabling certificate validation entirely significantly increases risk by allowing man-in-the-middle attacks.

     • Always validate certificates, and if they don't match, block the connection to maintain security.

   • For SMB (UNC Paths):

     • Kerberos authentication, the preferred method, requires the use of an FQDN. Without it, authentication will fall back to NTLM, which is less secure.

2. Prefer Kerberos Authentication

   Kerberos should be the default authentication method wherever possible, as it is more secure than NTLM:

   • Why Kerberos is better:

     • Passwords are never sent to the target server. Instead, Kerberos uses signed tickets validated by a domain controller to grant server access.

     • Tickets are server-specific and cannot be reused to access other machines, reducing the risk of credential misuse.

   • Fallbacks to NTLM:

     • NTLM v1 should never be used as it is highly vulnerable to attacks like hash cracking.

     • NTLM v2 can be used as a fallback but is less secure than Kerberos. Increase password lengths to harden NTLM v2 protections against brute force attacks.

3. SMB Protocol Version and Configuration

   SMB protocol versions and configurations play a significant role in securing file transfers. Follow these guidelines:

   • Disable SMB v1:

     • It is outdated, insecure, and disabled by default on modern systems. Never enable or use SMB v1.

   • Enable SMB Signing (SMB v2):

     • Protects against replay attacks by ensuring that every message is verified.

   • Prefer SMB v3 with Encryption:

     • SMB v3 supports both signing and encryption. Encryption protects data in transit, so even users on the same network cannot view file contents.

4. Write vs. Read Credentials

   Distinguish between write credentials (used by the Sync Agent) and read credentials (used by endpoints) when configuring Preferred Servers:

   • Write Credentials:

     • These are more sensitive as they allow the Sync Agent to upload files to the Preferred Server. Always enforce secure configurations (e.g., Kerberos or SMB v3 with encryption) for write operations.

   • Read Credentials:

     • Used by endpoints to retrieve updates. While secure configurations are preferred, restricting to secure protocols only could result in compatibility issues with older systems. Balance security requirements with operational needs.

5. Default Security Modes

   The following default security settings are recommended for environments to safeguard Preferred Server configurations:

   • Enforce Secure Connections for Write Operations:

     • The Sync Agent should only use secure SMB configurations when writing to the Preferred Server. Reject insecure settings like SMB v1 or NTLM v1.

     • If the admin chooses to allow insecure SMB connections, this will increase risk.

   • Allow Insecure Connections for Read Operations (Optional):

     • For endpoints using read credentials, allow the use of less secure protocols if necessary to support legacy or unpatched systems. However, limit this to specific scenarios and be aware of the risks.

6. Password and Credential Security

   Ensure strong authentication practices:

   • Use complex passwords, preferably longer than 14 characters, to mitigate brute force password cracking for NTLM v2.

   • Avoid basic authentication methods, such as transmitting usernames and passwords in plain text or base64 encoding.

Summary

By following the recommendations above, you can decrease exposure to security risks while maintaining compatibility across your organization. Always prioritize Kerberos authentication, use FQDNs, enforce SMB v3 encryption, and validate certificates carefully to achieve a secure Preferred Server setup.

For further assistance, please contact Ivanti Support.