Why Is Your Network’s Front Door Still Unlocked?

Updated January 2024

Putting aside the current macro issues we face, we’d like to instead discuss and explore a very relevant security issue — a fundamental flaw in networking approaches, which is unfortunately widely prevalent and continually exploited: open network ports in security products.

The Issue: TCP/IP

This issue has been highlighted recently by yet another well-publicized and critical security weakness in a widely deployed remote access product, which can be exploited by any unauthenticated remote adversary. We’re not here to shame vendors, as all complex software has vulnerabilities which can potentially be exploited. Our point is that the remote access entry points into many businesses' networks are based on the fundamentally open nature of the TCP/IP protocol. And this is a major shortcoming that must be changed.

TCP/IP was designed more than 40 years ago, with a goal of easily connecting remote networked systems. By design, it advertises open, running services to any system that can reach it across the network, inviting them to connect. It has worked extraordinarily well over the decades, but our security world has changed in ways that would be unrecognizable to the original designers.

In today’s environment, this open nature means that our network services are visible to every adversary on the internet — including literal armies in hostile nation-states — inviting them to connect, consume server resources, and exploit these systems. While organizations have largely moved their private servers off the internet, they have not done so for their remote access entry points — hence the ongoing series of exploits in these “front doors.” Hastily implemented WFH options deployed over recent months have likely increased the attack surface, exacerbating risk for enterprises.

A Better Approach

As a security professional, you’re familiar with the Zero Trust security principle of least privilege, and likely apply this practice throughout application and network environments. This practice needs to also be employed at the packet level, where even a ping or TCP handshake is in fact a privilege and must be treated as such. What this means is that — at a network level — we need a way to distinguish authorized and unauthorized users prior to TCP connection. That is, to permit authorized users from establishing a connection while blocking unauthorized users.

On this surface this may appear technically impossible, as it seems to be enforcing user-level classification and authorization at a network layer. Fortunately, as is often the case, math comes to our rescue! Specifically, by using single packet authorization (SPA), which uses a basic cryptographic hash technique using a shared secret, authorized users’ devices can generate a time-based hash that’s included in the initial network packet, prior to a network connection being established. 

Because authorized users have the shared secret, their systems can generate a valid hash, and will be permitted to establish a TCP connection. Unauthorized users, without the secret, will be unable to generate a matching hash, and can be rejected at the network level, prior to connection. The elegance of this technique is that validating the hash is very computationally lightweight, so the server can easily identify and reject unauthorized attempts at scale, while still servicing authorized users. This is particularly useful to prevent DDoS attacks, which you can learn more about in this Whitepaper.

This one change in how security products secure themselves, as the “front door” into our networks, will make a significant improvement in organizations’ security and resiliency. We recommend that organizations look at the open security specification, the software-defined perimeter, which has single packet authorization as a core part of its architecture. As strongly vocal advocates of this approach, we implemented SPA within Appgate SDP, our universal Zero Trust Network Access (ZTNA) solution that many enterprise and government customers have embraced to secure their resources.

The ZTNA software-defined perimeter use of SPA was designed to eliminate the ability of unauthorized users to even connect to the security infrastructure, let alone exploit it. We believe that it’s frankly irresponsible that many security and remote access vendors still leave the network “front door” open despite the availability of this open and well-proven network cloaking technique. We live in a world that’s too dynamic, too interconnected, and too dangerous not to do this.

We believe that enterprises should challenge their security vendors with some hard questions: Why do you have open ports? Why are you exposing my enterprise’s entry points to our adversaries? And enterprises should challenge themselves to take a serious look at adopting the software-defined perimeter. With it, they can, at long last, hide the front door from their adversaries.

For more Zero Trust Network Access resources, visit our resource center.