While every network resource is a potential target for hackers it’s no secret that in on-premise networks some pose a greater security risk than others. Here, we dive into how to provide authentication in a DMZ and why securing a DMZ with multi-factor authentication (MFA) is equal parts an art and science.

A demilitarized zone network (DMZ) is a subnet that hosts public-facing services and is isolated from the rest of the network, adding a layer of security against external attacks. If servers inside the DMZ are compromised, attackers can’t easily use this as a bridgehead to penetrate deeper areas of the network.

In any network, the servers at highest risk are those that by their nature need to be accessible from the public side of the network such as domain name system (DNS), web, and email servers.

That means allowing traffic to reach these servers through the firewall from the outside world, for example HTTPS web traffic on port 443. While public ports are always carefully managed, any access from the public side is a potential risk attackers might exploit.

One way of minimizing the risk is to deploy a DMZ.

However, admins still need to manage DMZ servers and that means accessing them through an internal port. Obviously, as with any privileged access, this needs to be secured using something more resilient than a simple password credential.

The recommended approach is to implement multi-factor authentication (MFA). Because DMZ networks are by their nature isolated, this can be complex to implement. MFA requires dedicated infrastructure of its own as well as integration with the local Active Directory (AD) domain controller outside the DMZ so authentication can happen.

Designed specifically to solve the problem of on-premise MFA and access control, UserLock MFA offers a simple one-server solution to this problem that removes the need for additional infrastructure.

That means that the organization’s MFA controls for the DMZ can be managed using the same console used to configure other session types such as MFA for VPN, RDP and IIS. The DMZ can remain isolated, but authentication can still happen.

One of the simplest techniques for securing a network is to divide it up into smaller networks or subnets. That way, if an attacker compromises a resource in one subnet they are stopped from moving laterally to compromise other resources by a web of firewalls dividing these subnets from each other.

Inevitably, this is more complex to administer — you generally need more or larger firewalls — but worth it for the pay off in terms of security. The idea of a demilitarized zone (DMZ) in networking is really a specialized version of the same idea.

The DMZ is a home for servers that need to be accessible from the public side of the network which makes them more likely to be attacked. But by putting them inside a DMZ subnet, you are separating these high-risk computers from everything else on the network. That means that if a DMZ resource is attacked, any compromise is contained inside the DMZ and can’t spread.

Analogous to the famous DMZ zone that separates North and South Korea, a network DMZ is a buffer that protects the rest of the network from what might be inside the DMZ itself as well as the outside world.

As the above description implies, a basic DMZ needs at least two firewalls for a DMZ to work: one to protect the DMZ from public attack and a second to defend the main network from the DMZ. But the DMZs concept can be applied in more complex ways, a prime example being operational technology (OT) networks.

OT networks are already networks within networks that need to be separated from the outside world as well as the internal IT network. OT networks tend to be viewed as entirely isolated from the outside world to protect them from cyberattacks. In reality, the need for remote management means that OT networks are often configured just like IT networks. Some of their resources need to be publicly accessible, for example SCADA systems, PLCs, and other equipment sensors.

But as with an IT network, this creates more risk of attack and compromise, which is why these types of systems are often placed inside an OT DMZ. It’s even possible for a large OT network to have several DMZs across multiple locations.

If the DMZ idea has a catch it is probably management and security. Obviously, admins have to be able to manage the servers inside the DMZ and that means having access through a firewall port.

Opening a connection would seem to compromise the whole point of using a DMZ to protect the internal network from the possibility of lateral movement. In reality, it usually comes down to the direction of connection — the internal network should be able to connect to the DMZ but connections in the other direction should be strictly controlled.

An admin connection to servers inside the DMZ is extremely sensitive which is why MFA is now a recommended security control. However, implementing this presents admins with a choice.

• The recommended approach is to keep the MFA authentication server outside the DMZ. If the organization already has an on-premise MFA platform or is using an external MFA provider, this is convenient but comes with the possibility of extra latency, which can be an issue for some applications.

• A less orthodox option is to place the authentication server inside the DMZ. This has the advantage that the MFA will be seamless although the MFA server itself is obviously at greater risk. It also requires a connection to a dedicated AD forest connected through a one-way trust to the primary AD domain controller.

• In either case, MFA deployment always requires additional infrastructure, which can add complexity to network management.

The above scenarios reveal another subtlety of DMZs; not all DMZ are the same. Some DMZs are highly controlled and can tolerate the MFA being placed inside the DMZ. Others, in contrast, will prefer the orthodox approach and place the MFA server outside the DMZ.

UserLock makes implementing MFA security and access control simple for admins managing on-premise networks, with DMZs being a special example of this. It is still the case, however, that DMZ security presents admins with difficult trade-offs which often can result in a lower security profile as well as extra complexity.

UserLock, which is a single server solution, minimizes complexity and offers more flexibility in terms of secure management. For example, when placed outside the DMZ, UserLock can secure assets inside the DMZ with MFA using UserLock Anywhere. This works by placing an IIS web service inside the DMZ, which communicates securely with UserLock across the Internet via the Microsoft File and Printers sharing SMB port 445 (separate connections are opened through the firewall for Windows authentication to the domain controller on 389 and 3268).

Through this approach, UserLock bypasses the need to place the authentication process inside the DMZ where it would be an elevated risk.

An energy sector company implemented a DMZ to isolate public servers from its OT network in order to meet regulatory and compliance requirements, including the need to implement MFA for management access from the main IT network to the DMZ.

Most solutions to the IT team looked at added complexity and expense to what is already a complex network setup. With UserLock, the team was able to avoid this, implementing MFA on DMZ access within hours.

UserLock offers multiple MFA methods such as push notifications and token access, but the company opted for TOTP codes via an authenticator app integrated with single sign-on (SSO) as the simplest approach.