Thinking About Split Tunneling

Is split tunneling right now that everyone is working from home?

With the massive move to working from home—a trend that probably will not be totally reversed even once things return to “semi-normal” (whatever that eventually looks like), security postures need to be thought and rethought to make certain they are the right thing—like disabling split tunneling for users connected through a VPN. For those who don’t recognize the name of the feature, split-tunneling allows traffic from the VPN endpoint to be split; traffic to local destinations and to the global Internet are not sent through the VPN connection, but rather handled using local resources.

There are two security reasons for disabling split tunneling. First, if the endpoint is infected by malware that captures keystrokes or data off the host, the “only way out” is through the corporate network. If the data exfiltration takes place through the corporate network, it will (hopefully) be captured by internal controls so action can be taken. Second, if the user opens some link or email that contains malware, or might leak company confidential information, internal controls can again come into play and help mitigate any problems.

While these reasons are well-grounded, there are, as always, tradeoffs to consider.

One factor is the use of corporate resources for what would otherwise be local traffic. While it’s tempting to say “you shouldn’t be accessing personal information while on the corporate VPN,” little short of blocking access to a wide array of sites, or the Internet, is going to keep employees from accessing social media, games, news, and other sites while on company time. In fact, it may be counterproductive to strictly limit access to these things; distraction and down time play off one another in ways that are hard to monitor and vary widely between individual users. The amount of traffic pulled through the corporate network when everyone or almost everyone is working from a remote location can be significant—a factor to consider in deciding whether split tunneling is the right solutions for VPN connected users or not.

A second factor is the flip side of the security problem. What if a device on a local user’s network is, in fact, enrolled as a node in a botnet through malware? Not only is the standard traffic now passing through the network, but also any traffic being generated as part of the botnet’s instructions—DDoS traffic destined to interfere with the operations of some other network. While it might be ideal to disallow a host compromised in this way onto the network, it might also not be easy to detect. Either way, allowing this kind of traffic to be pulled through the corporate network is probably not a good idea—it could well cause an internal resource starvation situation, taking the network down for all users.

Regardless of split-tunneling being disabled, there is still the risk of a device being compromised while off the VPN with some sort of malware that probes the network for ‘infectible’ victims and sets up DDoS attacks within the network. If the botnet operator realizes they have access inside the perimeter of a corporate network, they can shut the network down, causing major havoc. Since most DDoS and detection tools are focused on traffic from outside the network, rather than from hosts inside the perimeter, most network operations staff are not well-versed in taking down an DDoS attack or botnet within their own network, and most available services in this realm are focused on Internet-based DDoS attacks, there may be little recourse beyond paying whatever ransom might be demanded in order to gain time to build out proper defenses.

There are no clear answers in split tunneling other than moving more towards a web-application style architecture for all access, and reduce VPN use to the minimal possible, to properly support high numbers of remote users—much like the content providers have already done with the services they provide.