A while back I started a series on Network Zoning and like most procrastinating, over-achievers: I got side-tracked (is that a self-induced form of ADD?) ! I have had the pleasure of interacting with a number of folks on the zoning topic, and so I wanted to take a moment to tack on an additional concept that doesn’t always get much attention but is very relevant in your network zoning design.
PERSPECTIVE and the impact of perspective.
Perspective in Network Zoning is a little like determine the perspective of an email without knowing the sender. If you’ve ever sent a witty email to someone who didn’t share your sense of humor, you’ve been impacted by perspective. Please be careful not to confuse perspective with context. Perspective deals with a vantage point, while a context is the surrounding details.
When zoning, the perspective of the actual components, users, and threats dictates a given device’s zoning requirements. Theoretically perspective actually defines the security posture.
Did that hurt? Just a little?
The configuration for each of these devices in this illustration is relative to their location in the network. Their perspective determines their configuration. Obvious right? Please keep in mind, the External Firewall or Internal Firewall could easily be a router with ACL’s
Consider that the External Firewall in this illustration sees untrusted incoming traffic and passes only traffic based on rules for the more-trusted networks.
This “trusted” traffic of the External Firewall is actually UNTRUSTED TRAFFIC for the Internal Firewall! After all this is the UNTRUSTED interface on the Internal Firewall.
The Internal firewall can be configured with the same blocking rules of the External Firewall in addition to new rules that are applicable to protecting the Internal Networks.
The addition or the difference in security configuration for internal or external firewalls will be controlled in-part due to perspective because you could obviously implement the same overall security policy on both firewalls but the expectation for what threats exist where will be based on perspective.
In the same light, your zones will have traffic or usage patterns and requirements relative to their placement in the network. External DNS servers will be configured and protected differently than Internal DNS servers. Network resources talking across zones will work differently than talking inside a zone. Your security practices and configuration will change accordingly. The configuration for a given zone will be driven by perspective – requirements will map out differently based on the perspective of users, threats, and policies.
Perspective will show up within the logs as well. When you review the logs on your devices, you will react differently to external threats to your internal servers logged on the actual internal server versus the External Firewall.
When you build out your network zone, be sure to keep perspective in mind. You may choose to overlap policies as a defense in depth practice, but please take care to define your zoning appropriately.
What’s your perspective?
Drop me a line and let me know!
Traditional network security featured two or three zones, whether they were thought of in terms of zones or not may depend on the organization. Certainly everyone is failure with DMZ; however, modern approaches to network security don’t stop at the perimeter. This is where these new zones come in.
In the early days of network security, the consensus was: place a firewall at the external touch-points of your network with two or more network interfaces. If you ran any public services, locate them inside something called a DMZ or screened-network and restrict access to/from those devices for internal systems.
This should sound familiar, welcome to Network Zoning. The post-modern era of network security takes this DMZ approach and marries it with the principle of trust/privacy, so that the internal network can be carved up into segments providing increased security, compartmentalization, and privacy for users, services, servers, customers, etc.
In the earlier posts I referenced the idea of grouping like-functions of an internal network by vlan and/or IP subnet. This segmenting, grouping, partitioning, or zoning works just like the DMZ approach of traditional network security with the exception that the rules for access will be different and the “firewall” is internal. Here comes the tricky part.
Implementing the segmentation part can get complicated. I recommend vlans and different IP Address ranges as a general architectural practice, but it is possible with modern technology to insert transparent firewalls (let firewalls be firewalls) to facilitate rapid firewalling of network segments without having to implement vlans and IP Addresses.
These zones form boundaries inside the network, if you implement traditional firewalls they represent layer 3 boundaries and if you implement transparent firewalls they represent layer 2 boundaries. The outside boundaries should be thought of as untrusted, DMZ-like boundaries should be untrusted or semi-trusted, and depending on the user community the internal boundaries may be trusted.
These boundaries isolate trusted, untrusted, and semi-trusted devices and services from one-another and form what is referred to as a trust boundary. Trust boundaries can then be used to form privacy boundaries, where decisions are made segment trust implied within these various segments.
Getting back to the zoning concept, one design might feature an external firewall or set of firewalls (if redundancy is preferred) that provide the first barrier between the Internet and Internal users. Assuming the organization provides DNS, Email, Web, or other publicly available services, this firewall will provide an external DMZ as well. This will create one untrusted zone and one semi-trusted zone that will interface with an internal firewall/router acting as a semi-trusted barrier (zone) where the actual trusted zone(s) live.
The firewalls in this diagram can be routers, switch routers, firewalls, or a combination. The key is selecting hardware/software that will support the particular environment and needs of the organization. Firewalls come in all flavors, colors, and sizes these days and many do more than just filtering of packets, including deep packet inspection, IDS/IPS, load balancing, malware scanning, and web content filtering. Most routers on the market today can provide packet filtering / inspection in addition to traditional routing functions with minimal performance implications.
This specific architecture addresses minimal internal and external security from a zoning perspective needed to produce a trust barrier where internal systems should be protected from external (untrusted) systems. If the Internal Servers segment is firewalled from the Corporate LAN segment in this diagram, then four (4) security zones will form a privacy boundary in addition to the trust boundary where servers are isolated from users and outsiders are isolated from insiders.
Further expanding on the Zone concept, I created another diagram to demonstrate the layering that will be accomplished when the zones are implemented.
In effect, the ZONE-NETCORE becomes the underlying fabric that enables the other zones, in this series.
You certainly don’t need to secure your zones in this way and you can definitely just trunk your ZONES back to a firewall or router or a cluster of either, as indicated in this diagram. You can combine this diagram with the other and create clusters of zones, if you choose.
Trust becomes the deciding factor in the approach you take to zoning, followed by comfort with and understanding of the nuances of trunking versus routing. Often times, the idea that multiple zones are traversing the same physical link with only logical (software) separation is enough to drive implementations towards a routed model.
I decided to start a series on Network Zoning after seeing too many “you need to zone your network” articles and best practice guidelines that never give any aide to the reader on HOW to go about this other than segregate your network or firewall off the servers. Before you attempt this, make sure you understand the limitations of your infrastructure and the concepts outlined below.
In this series, a ‘Zone’ will be the LAN segment set aside for a specific function or IP Range. This zone will route or switch to a firewall-like interface which will provide the “networking” part of the puzzle between the various zones. Depending on the ruleset, data from one zone may or may not be transported to another zone.
Make sure you’re familiar with TCP/IP, Networking, VLANs, IP Addresssing, and subnets; you don’t need to be an expert to proceed. The examples, configurations, and how-to will assume you’re working with Cisco equipment. If you need help with other equipment, you’re welcome to drop me a line.
In this example, the zoning will be accomplished by assigning like-resources to a specific VLAN and having these VLANs end on a router/firewall interface whereBasic Network Zoning access decisions can be made in accordance with local Security Policies and Practices.
First thing’s first.
Zoning implies some grouping of computing resources. This grouping could be by location, function, purpose, access type, subnet, etc. Because this is my how-to, I’m going to zone according to functional area and subnet. Take a look at this basic diagram where users, administrators, application servers, and sensitive data servers are zoned off and tie back to a firewall.
Functional zoning is very beneficial once the firewall side comes into play because the access rules and restrictions should be largely similar across the specific zone. All the servers shouldn’t need Y! Instant Messenger access but the Desktop Users might run The Weather Channel on their desktop. Zoning like resources makes management of the firewalling and routing simpler over-time as well, because the zoned areas can be extended without re-inventing the wheel.
Once you know how you want to group the resources, it is important to describe and qualify what is unique and different about each grouping. This ensures that your groups don’t overlap as well as preserves the groupings going forward. Depending on your experience with firewalling and routing, at this point you may want to begin clarifying what each zone can and cannot access, for instance – the Sensitive Data Servers DO NOT surf the web or have access to email.
The example here assumes the subnets of these groups allows for grouping or summarization, this may or may not be the case in your grouping but if you have the options it does simplify things in other areas as well. For my example I have allocated 256 IP Addresses to each of the two server zones along with the administrator zone and I have allocated 1024 IP Addresses for the user zone:
- Zone – APPS = 10.0.0.0/24 (10.0.0.0 – 10.0.0.255) [256 Server IP Addresses]
- Description: Zone dedicated to application servers and services, no end-users and no sensitive customer data
- Examples: Intranet server, Email server, File server
- Zone – SENSITIVE = 10.0.1.0/24 (10.0.1.0 – 10.0.1.255) [256 Server IP Addresses]
- Description: Zone dedicated to servers that contain sensitive customer data (could also be employee data)
- Examples: Oracle database server
- Zone – SYSADMIN = 10.0.2.0/24 (10.0.2.0 – 10.0.2.255) [256 System Administrator IP Addresses]
- Description: Zone dedicated to privileged administrators of systems, applications, or infrastructure, requires extra access to servers, network elements, etc.
- Examples: Network Management Team, Firewall Administrators, Database Administrators, etc.
- Zone – USERS = 10.0.3.0/22 (10.0.3.0 – 10.0.6.255 [1,024 Desktop User IP Addresses
- Description: Zone dedicated to the general user base
- Example: Average Joe user
These examples and zones will not apply to every organization. These are hypotethical and designed to get your imagination flowing. The key ingredient is being able to combine ‘like users’ and ‘like access’. The zone members will be placed into their own VLAN and will not be able to talk to devices outside their VLAN unless a router or firewall allows them to do so. In the example above, this VLAN configuration will allow the use of routed VLAN interfaces and switched VLAN interfaces. The difference between routed and switched interfaces being: switched interfaces only talk to similar switched interfaces (ZONE-USERS talks to ZONE-USERS over switched interface while ZONE-USERS cannot talk to ZONE-APPS without passing through a routed interface).
There is one more zone to introduce, that I have come to rely heavily on, ZONE-NETCORE. If you think about it, you’ve zoned the users, the applications, and the servers. What about the network?
- Zone – NETCORE = 10.255.0.0/24 (10.255.0.0 – 10.255.0.255) [256 Network Core IP Addresses]
- Description: Zone dedicated to network interface on routers to facilitate core communications and isolate zones
- Examples: each router has an interface on this Zone
The ZONE-NETCORE is not required, but it serves to isolate the VLANs from one-another across a core or the network, without this zone each VLAN/ aka Zone must come all the way back to the firewall, as indicated in the basic diagram. This approach creates communities that are aggregated and connected via conduits, as depicted here. Note each zone is self-contained and isolated from other zones before reaching the firewall.
Now we have zones defined and understand basic functionality inside the zones. How are the VLANs setup? What security do we need for each zone and how is that accomplished?