This post provides concrete, step-by-step guidance to harden SSH and RDP in order to meet Compliance Framework objectives for AC.L2-3.1.15 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2—focusing on limiting and securing remote access paths, implementing strong authentication/encryption, and ensuring logging/monitoring so Controlled Unclassified Information (CUI) remains protected in small-business environments.
Why AC.L2-3.1.15 matters for remote access
Control AC.L2-3.1.15 in the Compliance Framework emphasizes controlling and protecting remote access methods so adversaries cannot use external access to reach systems that process or store CUI. For small businesses this means treating SSH and RDP as high-risk gateways: misconfigured remote services are a primary vector for credential compromise, lateral movement, ransomware, and CUI exfiltration. Implementations mapped to this control must both reduce the attack surface (limit who/what can connect) and increase assurance (strong cryptography, MFA, logging).
SSH hardening — practical configuration checklist
Configuration and service hardening
On Linux/OpenSSH servers, update /etc/ssh/sshd_config with restrictive, explicit settings and restart sshd. Key recommended values you can copy into your config: PermitRootLogin no; PasswordAuthentication no; ChallengeResponseAuthentication no; PubkeyAuthentication yes; AuthorizedKeysFile .ssh/authorized_keys; UsePAM yes; AllowUsers alice bob@203.0.113.0/24; X11Forwarding no; AllowTcpForwarding no (unless required); LoginGraceTime 30s; MaxAuthTries 3; ClientAliveInterval 300; ClientAliveCountMax 2. Also set strong KEX/Cipher/MACs such as KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256; Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com; MACs hmac-sha2-512,hmac-sha2-256. For FIPS environments, enable FIPS-compliant algorithms and compile OpenSSH with FIPS support where required by your Compliance Framework.
SSH hardening — access controls and network design
Bastions, jump boxes and firewall restrictions
Do not expose SSH on every host. Use a hardened bastion/jump host in a DMZ or cloud-facing management subnet. Require public-key authentication to the bastion only, then require jump users to connect from the bastion to internal hosts (using forced commands, restricted keys or an administrative jump user). Enforce IP-restrictions at the network perimeter with firewalls/security groups (allow only corporate office IPs, approved VPN subnets, or an identity-aware proxy). Implement Just-in-Time (JIT) access or ephemeral firewall rules to open SSH ports only when needed. For automated containment, integrate fail2ban or similar to ban hosts after repeated failures and consider port-knocking or single-packet authorization for very high-risk systems.
RDP hardening — practical configuration checklist
Windows settings and Group Policy
For Windows Remote Desktop, enforce Network Level Authentication (NLA) via Group Policy: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > "Require user authentication for remote connections by using Network Level Authentication" = Enabled. Set "Set client connection encryption level" to High and require TLS 1.2 (or newer). Disable RDP redirection of drives and clipboard unless strictly needed (Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection). Apply account lockout policies and enforce strong password/lockout via: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
RDP hardening — gateway, MFA and network segmentation
Use RD Gateway or VPN + MFA
Never expose port 3389 directly to the internet. Require an RD Gateway or a VPN with strong authentication. Integrate MFA (Duo, Azure MFA, Okta MFA) with the RD Gateway or with your identity provider. If running in Azure, use Conditional Access to require compliant devices and MFA before allowing RDP sessions. Place RDP hosts on segmented VLANs and restrict inbound RDP with firewall rules that only permit connections from the gateway/jump host IPs. Consider Remote Credential Guard, Restricted Admin mode, or delegating ephemeral local admin credentials to avoid credential theft (e.g., Microsoft's LAPS for local admin password rotation).
Logging, monitoring and detection (required for compliance)
Enable comprehensive logging: for SSH, centralize /var/log/auth.log or /var/log/secure into a SIEM; for Windows, forward Windows Event Logs (Security/EVD/TerminalServices) to your logging platform. Configure retention consistent with Compliance Framework requirements, and ensure alerts for suspicious events: multiple failed logins, successful logins from unusual geolocations, concurrent sessions outside business hours, and use of privileged accounts. Implement session recording or at minimum session metadata collection for high-value systems. Maintain audit trails for privileged access requests and approvals (e.g., ticket ID tied to JIT open ports).
Small-business real-world examples and implementation scenarios
Example 1 — Small engineering firm: place a single Linux bastion host in a cloud VPC that requires key-based SSH to the bastion and uses SSH agent forwarding only to allow connections to CAD servers on an internal subnet. MFA is enforced via Duo on the bastion and firewall rules (security groups) restrict access to known office and contractor VPN IP ranges. Example 2 — MSP supporting a manufacturer: use RD Gateway with Duo MFA + Conditional Access, require technicians to connect from managed jump hosts, log all RDP sessions, and rotate local admin passwords with LAPS. Both examples show the Compliance Framework pattern: limit exposure, require strong auth/MFA, log everything, and restrict lateral movement.
Compliance tips, common pitfalls and risk of noncompliance
Key tips: (1) Document baseline configurations (sshd_config, GPOs) and change-control for exceptions; (2) Automate hardening via configuration management (Ansible, Puppet, SCCM) and test in staging; (3) Use vulnerability scanning and regular patching to remove RDP/SSH exploit risk; (4) Map each technical control back to AC.L2-3.1.15 in your System Security Plan and evidence repository (screenshots of configs, firewall rules, MFA logs, SIEM alerts). Risks of not implementing these measures include credential theft, ransomware, unauthorized access to CUI, contract loss, and audit findings that can trigger corrective action plans or termination of DoD contracts.
Summary: To meet Compliance Framework AC.L2-3.1.15 you must reduce remote-access attack surface, enforce strong authentication and encryption, centralize logging and monitoring, and document everything. Practical actions include hardening sshd_config, using a bastion host, enforcing key-based SSH and MFA, deploying an RD Gateway with NLA and MFA, restricting connections with firewalls, and capturing logs into a SIEM—measures that are feasible for small businesses and essential to protect CUI and satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requirements.
