Virtual Wire Pairs – improving network security without extra hardware

Ever found yourself in the unfortunate circumstance of having to support devices on your internal network that tend to pose a higher security risk than you’re comfortable with?   Perhaps an older Windows 2003 or Windows 2008 server, or an outdated kiosk device that is managed by a 3rd party vendor.   Using Virtual Wire Pairs on a Fortigate firewall can drastically reduce the overall attack surface and greatly improve security to and from those specific devices you’re forced to keep around, without the need for additional hardware or software.

The ideal world vs. the real world

As much as we would all like to have networks with fully up-to-date machines that we manage, no legacy devices, and no embedded devices of questionable origin, it seems that we are always put in the position of managing something along those lines. Whether it’s a legacy application running on an out-of-date operating system or a vendor-managed device that you have no control over, there’s always something we can’t secure properly or control access to the way we want to.

Luckily a little-known feature of the Fortigate firewalls called Virtual Wire Pairs allows us to add in security where we would otherwise be unable to without additional hardware purchases in many cases.

The old way vs. the new way

In days past, organizations used to focus primarily on securing the edge of their network from threats via the use of firewalls and other technologies. Those same organizations often left their internal network access uncontrolled and unsecured. Modern-day security strategies focus on protecting your critical assets and infrastructure from both outside threats and inside threats combined.

In recent years, the concept of internal segmentation firewalls (available from Fortigate, Sonicwall, Palo Alto, etc.) using Next Generation Firewall (NGFW) technologies and features sets such as Antivirus, Intrusion Prevention, Deep Packet Inspection, Application Control, etc., have allowed for implementing additional security controls and have gained substantial traction in many IT environments.  Implementing this internal segmentation is generally easiest when done right from the start but often proves to be much more difficult to implement in an already-running production network.

Adding security without cost

Features like Fortigate Virtual Wire Pairs can be implemented without the need to purchase additional hardware and allow you to control access to and from a device based on the physical switch port(s) it’s actually plugged into, similar to how you can use firewall rules to control access between IP addresses. Think of Virtual Wire Pairs as splitting two ports out into their own firewall that we can create specific rules for, independent of any existing configuration. Keep in mind that as a result of being split out in this fashion, traffic is not passed to or from the Virtual Wire Pair ports to any other interfaces on your Fortigate directly. One side must be connected to your internal switching infrastructure, and the other side must be connected to the protected device.

Virtual Wire Pairs (VWP) – implementation guide

For this example, imagine a scenario where we have a server running a legacy ERP system we can’t move to new hardware. The operating system is running Windows Server 2008 and only used for looking up old/archived orders that are not available in the newer (and more current) ERP system. Since Windows Server 2008 is no longer receiving security patches from Microsoft, we want to control access to that legacy ERP system as best we can to mitigate any security risks and vulnerabilities of that outdated operating system.

This diagram shows our intended architecture design:

Since Fortigate Virtual Wire Pairs operate at the port level, we need to have two dedicated ports open on our Fortigate. If your device has an internal switch configured, go to Network -> Interfaces, edit the internal switch, and click on the ‘X’ next to the ports you wish to use in order to remove them from the hardware switch interface. In this case we’re going to use port6 and port7 for our virtual wire pair, so we can remove those two from the hardware switch interface.

Once we have two ports freed up, go to Create New -> Virtual Wire Pair

In the New Virtual Wire Pair menu, assign a name to the virtual wire pair, add the interfaces as members, and if the Virtual Wire Pair is going to be passing VLAN tagged traffic, enable the ‘Wildcard VLAN’ option. If traffic is going to be untagged (the most likely scenario), leave this option disabled.

In your Network -> Interfaces menu, we’ll now see a new section for Virtual Wire Pairs created with our Virtual Wire Pair and the member interfaces. In order to ease configuration, I recommend assigning an Alias to each interface by double-clicking the name and putting in a descriptive value. Your Virtual Wire Pair will have one ‘LAN Side’ interface that connects to your internal switching infrastructure, and one ‘Device Side’ interface that your protected equipment is going to plug into.

As with any rules on the Fortigate we need to define appropriate address objects for our new Virtual Wire Pair. Go to Policy & Objects -> Addresses and define addresses for the sources and destinations you will want to control traffic using. Think about the access rights the protected server or device needs. Are you permitting traffic from your entire LAN IP range, or just select devices? In this example we’re going to permit access to one server (the legacy ERP server) only from one particular device (the only remaining user that accesses the legacy ERP server).

Under Policy & Objects you should see a new set of Virtual Wire Pair policies (including for IPv6, if you’re using it internally). Click on the appropriate section to open the IPv4 or IPv6 Virtual Wire Pair policies, then the Create New button to create a new policy

Creating the Virtual Wire Pair policy on the Fortigate is very similar to creating a normal firewall policy except for the Virtual Wire Pair section. The policy is applied to traffic going from one port to another in addition to our standard rules. In this example we’re going to permit HTTP traffic from one device on the LAN side of our Virtual Wire Pair (port6) to our protected device (port7). Return traffic is permitted by default. Create any rules you need and apply UTM inspection profiles appropriately.

Once created the rule should look fairly similar to any existing access rules you have in place. Keep in mind that Virtual Wire Pair rules by default deny all traffic, so any traffic not explicitly permitted will be dropped!

The last thing to do once all your rules are created in the Fortigate firewall is to physically connect everything. Take the ‘LAN Side’ port of your Virtual Wire Pair (in this case, port6) and connect it to your internal switching infrastructure.

Connect your protected device to the other side of the virtual wire pair (in this case, port7), putting the Fortigate in-line with the traffic and test your access. When configured properly, all network traffic to or from the legacy ERP server should be completely dropped, unless it’s coming from the specified client device and using the HTTP service.

Conclusion

With Virtual Wire Pair policies configured in this scenario, the potential risk of keeping that outdated legacy ERP server on the production network with known exposed/open vulnerabilities from the outdated Windows 2008 Server operating system is substantially reduced and/or completely mitigated.

Fortigate’s Virtual Wire Pair policies can be used for a plethora of other uses and scenarios as well to help better secure your internal network for these specific one-off scenarios and situations.