By Tobias McCurry
Although remote access into corporate networks isn’t new, such widespread, continuous use of remote access is. Organizations very early on identified capacity issues, but some legacy security risks in remote access solutions may be exacerbated by the extensive use of remote access under a widespread work from home scenario. Accordingly, it may be time to tighten, or at least review, the security on remote access mechanisms now that they are used more extensively. Below are three security settings in particular that deserve review and assessment to ensure enterprise security policies extend to remote workplace situations.
Host Level Restrictions
Organizations may want to re-examine, for example, key design and configuration settings for their virtual private networks, including the host-level restrictions that are enforced by the VPN. These settings may no longer be appropriate to the new widespread work from home use case. Because VPNs connect the client to the network, it is essential that only company-owned and secured computers are permitted to access the network. Network access controls (using certificates) can be used to authenticate the VPN client to ensure that it is a computer that is authorized to connect. VPNs can also use other attributes (such as the domain to which the client belongs, etc.) to achieve that same purpose. These controls to prevent connecting unknown, unauthorized computers from the network are more important than ever. VPNs often also provide additional features that enforce a policy on systems in order to ensure that they are properly patched and utilize up-to-date malware protection. These features weren’t used much in the past because identifying the client computer as company-owned was a sufficient indicator that the system was up-to-date. As discussed earlier, in today’s environment, such assumptions may no longer be valid. If remote laptops need to connect to the VPN to obtain updates, then it is possible that some could be very much out of date and therefore insecure. VPNs can be configured to assign out-of-date, insecure clients to a IP pool that only has access to infrastructure services to update the system. The VPN can restrict broader access to the network resources only to those clients that are sufficiently current in their security protections as to be trusted. VPN products, sometimes in conjunction with other products, have a great deal of flexibility in enforcing rules for access. The greatly expanded use of VPNs gives sufficient reason to reconsider whether these controls are appropriate to the new context.
Split Tunneling
Another particular configuration that deserves a fresh look is the VPN configuration that restricts or allows split-tunneling. When VPNs were used less extensively, some organizations may have decided to accept the risk of remote laptops connecting to their network with concurrent untrusted connections. With widespread use of VPNs, the risk profile has changed so it probably no longer makes sense to accept this risk. In fact, organizations may want to revisit split-tunneling settings that allow access to systems on the local network. Such exceptions to split-tunneling restrictions are often permitted for ease-of-use reasons, such as allowing users to access network-connected printers at home. With so many employees working from home, it makes sense to reassess whether these accommodations continue to be appropriate.
SSH
Organizations may also allow their more technical savvy users to connect remotely via SSH to a bastion host that serves as a jump server for accessing other systems in the network. In the past, such access may have been used occasionally to support systems after hours and on weekends. Now, IT support personnel may be connected over SSH all day, every business day. More widespread use again can increase risk. One often-ignored risk relates to session multiplexing. SSH multiplexing can be a convenient feature, but this capability provides a way for a remote adversary on a compromised laptop to bypass authentication controls and leverage an existing SSH connection to access the jump server in the corporate environment. If multiplexing is supported, an adversary can simply initiate a new SSH session to piggyback off of the initial SSH session, potentially hours after that initial session has been closed, to obtain access into the corporate network. Although the likelihood may be low that an adversary could own a corporate laptop, the impact of SSH multiplexing could be catastrophic. By default, SSH servers support multiplexing. Organizations should consider disabling multiplexing on the SSH server by setting MaxSessions 1 within /etc/sshd/sshd_config. If multiplexing is required, organizations should at least reconfigure SSH clients to set ControlPersist no to disallow new SSH sessions to be started after the initial session closes. However, organizations should be aware that users can override system-wide SSH client settings with user-specific configurations or command-line options.
SecureIT experts partner with organizations to improve security architecture and controls to achieve compliance. Our advisors provide practical advice that save you time and money. If you are in the process of implementing security or compliance requirements and wondering if you’re heading down the best path, please contact us. SecureIT would love the opportunity to learn more and show you how we can help.