Two-Faced Servers
The same conversation happened twice yesterday. Different companies, different industries, same words coming out of two different engineers' mouths.
"We separate those levels with a dual-homed system." Or, on the second call, with a more pointed delivery: "That server kind of straddles the levels."
Over countless audits and site visits, some version of that sentence emerged many times, and it always means the same thing: somewhere in that architecture sits one or more computers with more than one network card, connected to two networks at once.
To hear folks talk about it, you'd think they were describing a clever bit of engineering. And twenty years ago, in some ways, they might be correct. However, we don’t live in the land of once-upon-a-time anymore. The threats come fast and the risks are too real. Put aside the ugly baby, let’s discuss what that design actually does in today’s environment.
It isn’t cutting risk. It’s quadrupling it. Let me explain how.
Meet Janus
The Romans had a god of doorways: Janus, with two faces and one head, looking in opposite directions at the same time. He's the god of transitions, of thresholds, of the moment you step from one place into another. It's where we get the word "January," the doorway between one year and the next. And don’t even get me started on Julius and Augustus stealing days from February and spoiling a nice, neat 31, 30 month pattern.
A dual-homed computer is a little like that. It isn’t Janus. It’s a kludge. It’s a two-headed cybersecurity abomination. We tell ourselves that one face turns toward Network 1 and the other turns toward Network 2. We pretend it stands at the threshold between two levels of your Purdue model. We assume it decides with care which traffic it allows to pass.
In other ways, the similarities stand all too clear. Janus was a mythical god. Your dual-homed Pentium II Dell Dimension running Windows NT 4.0 has mythical cybersecurity.
And they’re probably 3com PCI cards locked to 10 megabit half-duplex, because they can’t autonegotiate consistently to Cisco switches, but that’s another issue.
Why It's There
To treat the folks who built these things fairly, I am not accusing anyone of carelessness. Twenty years ago, many OEMs intentionally designed systems this way to create a break between security levels. It stemmed from good intentions. Do not let your traffic route directly across all networks from the top corporate side, through the controls networks, and down into the physical devices. Instead, the software on that box receives data on one interface, processes it (validates it, transforms it, logs it), and then sends it back out the other interface as a deliberate, application-layer action. Not a route. A decision.
On paper, this forms an understandable and legitimate way to enforce a type of segmentation. But only on paper. Much like every DMZ diagram shows two firewall icons, when really only one physical device exists, with different interfaces. Or how, in the electrical sector, we always see a dashed red line that denotes an Electronic Security Perimeter, but that floating line really bears little resemblance to physical realities (it isn’t a line, it’s an interface).
In practice, we all know that if we traced every cable in that server room, at least one patches around that dual-homed box. Someone had to get something done and they forgot to undo it later. It’s a problem, not a guess. I have written enough audit violations to know.
The Truth
Here's the thing about Janus, though. He's still one head.
That dual-homed computer isn't two separate, independently secured devices doing careful, deliberate work at a boundary. It's one, usually obsolete, Windows operating system, with one set of vulnerabilities, one patch cadence, one local admin password somebody wrote on a sticky note in 2011, and it happens to have a live network cable running into both of your worlds.
If that box gets compromised (through the interface facing the business network, say, which is usually the one with more exposure), the attacker doesn't just have a foothold in Network 1. They have a foothold on a machine that can also see and touch Network 2. You didn't build a break in the road. You built a wide bridge and told everyone it was a wall.
That's not a doubling of your risk exposure. Depending on what that box talks to on each side, it can look a lot more like quadrupling it: two attack surfaces available from two different vectors, all feeding into one single point of failure that has legitimate access to both of your networks.
What We Do About It
You cannot rip that box out. Half the time, the software running on it is tied to a process that keeps the lights on, and "just remove it" is the kind of advice that gets you uninvited from the next planning meeting.
What we do instead is put a BlastShield Gateway in parallel with the dual-homed system; not replacing it on day one, just standing next to it. We build out real policy: who talks to what, when, and under what authentication. Over time, as we prove that the Gateway is handling the legitimate traffic that originally justified the dual-home, the dual-homed box's job gets smaller and smaller. Eventually (and this depends entirely on what the software will tolerate), you reach the point where the second NIC isn't doing anything anymore, and you can finally let it go.
You don't get Janus's job done by adding a second head. You get there by putting an actual guard at the doorway.
The Verdict
A dual-homed system was a reasonable idea in an era with fewer options. But a single unpatched Windows box standing at the boundary between two networks isn't a security control; it's a hallway with a nice rug over the hole in the floor. If you've got one of these in your architecture, you're not alone, and you're not the one who built it wrong. But it's worth a second look before someone else finds it first.
FAQs
What is a dual-homed server?
A dual-homed server is a computer with two or more network interfaces connected to separate networks at the same time. In OT environments, these systems are often used to exchange data between different security zones or Purdue Model levels without directly routing traffic between them.
Why are dual-homed servers a cybersecurity risk?
A dual-homed server creates a shared point of access between two networks. If an attacker compromises the operating system through either network interface, they may gain access to a system that can communicate with both environments. Instead of functioning as a true security boundary, the server can become a bridge between networks.
Do dual-homed servers provide network segmentation?
They can provide a limited form of application-layer separation when properly configured, but they are not equivalent to modern network segmentation. Both network interfaces ultimately terminate on the same operating system, creating a single point of failure with access to multiple network zones.
Why were dual-homed systems commonly used in OT networks?
Many OEMs and industrial environments adopted dual-homed systems years ago as a practical way to move data between different security levels without directly routing traffic between networks. The application on the server would receive, process, validate, or transform data before sending it through the second interface.
Can a compromised dual-homed server enable lateral movement?
Yes. If an attacker compromises a dual-homed system through one network, the attacker is now operating on a machine that also has legitimate connectivity to another network. That connectivity can increase the opportunity for reconnaissance, unauthorized access, and lateral movement across security zones.
Do organizations need to immediately remove dual-homed servers?
Not necessarily. Many dual-homed systems support critical industrial processes and cannot simply be removed without operational consequences. A safer approach is to introduce modern segmentation alongside the existing system and gradually reduce the server's role as legitimate traffic is migrated.
How can BlastShield reduce the risk of dual-homed systems?
A BlastShield Gateway can be deployed alongside the existing dual-homed system to enforce explicit policies governing which users, devices, and systems are allowed to communicate. As legitimate traffic is moved through the Gateway, dependence on the dual-homed server can be reduced until the second network interface may no longer be necessary.
How to Reduce the Security Risk of a Dual-Homed Server
Step 1: Identify dual-homed systems
Locate servers, workstations, or industrial computers with multiple active network interfaces connected to different network zones or Purdue Model levels.
Step 2: Map both network connections
Document what each network interface connects to, which systems communicate through the server, and what applications or industrial processes depend on those connections.
Step 3: Verify the actual traffic path
Do not rely only on network diagrams. Trace the real network connections and confirm that no temporary cables, bypasses, or undocumented routes allow traffic around the intended security boundary.
Step 4: Determine which communications are legitimate
Identify exactly which systems need to communicate across the boundary, what applications require that communication, and when those connections should be permitted.
Step 5: Deploy a BlastShield Gateway in parallel
Place a BlastShield Gateway alongside the dual-homed system rather than immediately replacing it. This allows the existing industrial process to continue operating while a more explicit security architecture is introduced.
Step 6: Create granular access policies
Define policies specifying who or what may communicate with each protected system, when access is permitted, and what authentication requirements must be satisfied.
Step 7: Move legitimate traffic to the Gateway
Gradually transition approved communications away from the dual-homed server and through the BlastShield Gateway. Validate each change before reducing the server's existing connectivity.
Step 8: Reduce the dual-homed server's role
As more legitimate communication moves through the Gateway, decrease the amount of traffic and access that depends on the dual-homed system.
Step 9: Remove the unnecessary second network connection
When the applications and operational processes no longer require the second network interface, disable or remove it. The former dual-homed system can then operate without acting as a bridge between security zones.
Step 10: Maintain explicit segmentation policies
Continue reviewing access policies and network dependencies so communication between OT security zones remains deliberate, authenticated, and controlled rather than dependent on a single multi-homed operating system.
-min.avif)
Russian hacktivists compromised a Polish hydropower plant through exposed ports. BlastWave cloaks OT networks, eliminating reconnaissance, exposed endpoints, credentials, and lateral movement entirely.
Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.
Less than 8% of OT and ICS Companies Have Robust AI Deployment, According to new Nozomi Networks and BlastWave-Sponsored Takepoint Research
.svg)
.svg)
