Network Design Scenario #2: DMZ Design

In this scenario we will cover Network Demilitarized Zones.

Introduction

The “Design Scenario” is a series where I plan to show case different network or security designs. Generally I will list a few requirements, go over the designs and discuss the pros and cons. I will try to steer away from specific configurations as the goal is always to try and be vendor neutral. However there will be some scenarios where I will go over implementations, so in some cases I will provide specific configuration. I hope this provides you with an alternate way to look at a network engineering or defense challenge and also feel free to share your thoughts or your own designs !

Network segmentation is key for network defense. From Vlans on switches, security zones on firewalls and VRFs on routers, segmentation is prevalent throughout networks and likely seen in yours. The idea is to have an area where users from an untrusted domain like the internet or a 3rd party entity can have access to services that the company might provide, such as a website or multimedia – without compromising the security of the internal trusted network.

For example, sticking with the web server, if there was a web server hosted inside the internal network and it was compromised by an attacker, then all of the other internal resources and users are at risk if the attacker pivots; however in the case of the divided demilitarized zone, only the limited resources within that area are at risk – nothing on the internal network (unless someone leaves the door open with a misconfiguration!). Firewalls are central in the application of this type of flow protection.

I’ve seen some posts on Reddit asking about DMZ design so I formulated this design scenario in response to those questions. We will look at a DMZ for a small business with just 1 firewall, a medium sized business with a zone-based firewall, and then a larger network that utilizes hardware segmentation. Although compartments and DMZs are widely used in data centers due to multi-tenancy and in ISP networks due to customer separation, we will cover only the enterprise today.

Basic requirements:

Segment external (untrusted) from the DMZ and internal (trusted) areas.
Overall goal is to allow access to shared services within the DMZ with a flow from external to DMZ and internal to DMZ.
1 Firewall, and 1 server for small business, utilizing interface security levels.
2 firewalls, 1 VPN appliance, and 2 servers for the medium business, utilizing zone-based security protection.
4 firewalls for the large business, focus on separation vs. firewall configuration.
Large business must incorporate multiple locations.

DMZ design challenges:

Routing complexity – how do you route in and out?
Firewall complexity – balancing simple and complex while optimizing security
Visibility – how can you maintain visibility outside the network?

Note: As always you need to ensure your firewall security policy only allows the necessary traffic, ports/protocols etc.

Network Design #1: Small Business DMZ

The first topology is for a common SMB setup of 1 firewall and 1 server. The security levels refers to the old Cisco ASA firewall or a common firewalls like pfSense style of configuration. Although Cisco has changed in the recent years (in the latest configuration guide I noticed they use the zone nomenclature more) it’s still a common setup you will likely see in the small business space.

The diagram highlights the simple traffic paths: outside can access the DMZ server but not the internal hosts, and if hosts need to access the DMZ they can. Moreover, the default interface level policy will not allow the untrusted network to source traffic towards the trusted network.

However at a basic level if the DMZ server is compromised the attacker will not be able to access the internal resources. Devices are directly connected at the interface level to the firewall with it acting as the default gateway.

You could use security level 0 for the outside and adjust via policy or access control lists (ACL), but I listed the outside interface as the same level as the DMZ as not all platforms have the ability to divide via security levels. Therefore having the outside and DMZ at the same security level I think covers that.

One thing I want to call out in this section because I think it applies most is a common thing you’re likely aware of – the massive use of “port forwarding”. This is where a user will essentially allow a inbound connection via port forwarding to an internal host on a certain port. Please use DMZ compartments, client/client-less VPNs, or IPSEC tunnels wherever possible. NAT is not absolute protection against intrusion. There’s a reason there are so many IoT botnets and that is part of the problem.

Relevant ASA configuration guide

pfSense setting up a DMZ

Network Design #2: Medium Business – Zone-Based DMZ

The second topology is more in-line with the Next-Generation firewalls like Palo Alto or Fortinet. You can see now we are a bit larger with a firewall cluster (2 devices) and more services hosted in the DMZ. Due to the requirements we have a separate zone all together for the VPN Appliance.

Virtual Lans (Vlan) are widely used to keep traffic in their own lanes and they do a good job of that. Really the only attack against them are double tagging or hopping attacks which require knowledge of the local network’s Vlan numbers and the native untagged vlan, therefore we can put a certain level confidence in Vlan segmentation. This is for layer 2 broadcast and pivoting protection.

The design here has tagged trunk interfaces moving down to distribution switches with the firewalls acting as the default gateways for each vlan; therefore when traffic travels from zone to zone (inter-vlan) we have the ability to apply firewall policy and also maintain visibility. Although this would require some decent horsepower on the firewalls if there is a lot of inter-vlan traffic, it provides some growth potential because as new services and servers are added we can simply create a new Vlan on the switch and Vlan interface or sub-interface on the firewall to expand. This covers two of our challenges of routing and maintaining visibility.

The thought process of having the VPN in its own logical zone is because if it is indeed a VPN appliance we can apply a certain level of protection with the edge firewalls for traffic destined to it. Also if there were other zones like in the very first picture of the post, we can apply more granular zone policies to what VPN users have access to. Lastly, since the appliance or VPN firewall has direct access into the internal trusted network, we can have some defense in-depth with two firewalls for remote access users (Perhaps advantageous for a BYOD environment).

Palo Alto Zones

Fortinet Zone Config Guide

Network Design #3: Large Business with Hardware Segmentation

If you recall the requirements for topology 3: maximum of 4 firewalls, must have multiple locations, and to focus more on hardware segmentation. So initially there are a few things to dissect.

First we can see the goal of the organization is to provide content available on the internet, therefore there are multiple locations to provide content geographically which generally will serve local clients better.

Secondly we can see the company has elected to invest in their ISP’s distributed denial of service (DDoS) mitigation product which acts as a proxy or traffic inspection agent for the enterprise (more on this later) .

One of the companies must-haves was the ability to manage and transfer content between locations independently from the customer traffic. So a private cloud with a different set of firewalls was implemented. It should be mentioned that this could also be done with virtual firewalls to minimize hardware costs along with VRFs on the edge routers as well for network 1 and 2 , but that is probably only needed if there were multiple sets of routers. VRFs are a method similar to Vlans but for layer 3.

We could say the DMZ here is created more as a different network – blending in so to speak – with hardware and connections being the primary focus here. But that’s not to say this network couldn’t be an overlay one (beyond the scope of this post). Load-balancers are shown because typically a large content provider would be using them with multiple servers.

One situation that might arise with a network like this is needing good routing throughput near the servers. If you recall we used the firewall as the default gateway in scenario 1 and 2, however we could almost assume that inter-vlan routing would be done via the core switches at the location. So in order to maintain one of our challenges visibility, the use of an Intrusion Detection System (IDS) appliance would probably be the recommended way to maintain clarity internally post-firewall. Either by using cable taps, span ports, or inline with flows etc.

I mentioned BGP in the diagram notes as this protocol would be a good choice at the edge and within the private transport cloud. The customer here would also be peering with their ISP to better control ingress traffic and [in this scenario] to utilize the DDoS mitigation product. BGP provides granular routing policy that could be applied in addition to the fact BGP would scale better as more locations are added to the network. Plus if a technology like EVPN/Vxlan was needed to extend layer 2 between locations BGP would be there to help pave the way. OSPF would probably be the IGP within locations. Remember routing was one of our design challenges and in a highly distributed/segmented network the challenge only grows.

DMZs outside the enterprise

To conclude this section I’d like to dive a little more into the ISP cloud in the large business diagram. If you think about the way a service like this might perform it represents core DMZ principles:

Divide two or more areas or zones of a network.
Allow only certain types of traffic between areas of the network.

So as we look above the traffic in this example would be redirected from the internet via DNS into the ISP’s mitigation cloud. Then the service would inspect and observe traffic to block or allow certain flows before they travel to the customer network and access the content it provides. This service could even host the companies content like Akamai.

To continue, there’s some malicious traffic that is flagged by the ISP and dropped before it leaves to the customer network which thereby provides an added layer of security. This DMZ concept goes more along the lines of a border DMZ where neither of the two parties (in this case source and destination) control the area. I will cover this more in a future post of The Art of Cyber War.

In Design scenario #2 we covered three designs which showcased different options when creating a network demilitarized zone. The central focus was the firewall which we can use to portion off a network fairly well. There are also virtual options like Vlans which provide layer 2 protection. Furthermore, as services become more available on the internet, products like mitigation services mentioned above can be implemented to provide a “border-style” DMZ. Thank you and I hope this helps you.