In this article, we take a look at network architecture and some ideas and guidelines on how to segment your server networks into different zones to increase security, control, and visibility.
Introduction
While general network segmentation is a best practice to structure up your network (using Virtual Routing and Forwarding instances, also known as “VRFs”) for all parts of your network, this article will go through some examples and concepts specifically on how to segment your server networks.
In firewall terms, a zone usually represents either a VRF (for client devices, printers etc.) or a server zone, where servers are connected to the network.
“Network segmentation is FREE security”
Server Network Segmentation commonly means creating several VLANs and IP networks that are dedicated for use for servers only. Connecting each of these VLANs to a separate logical interface of your firewall immediately creates a point of control and visibility, for traffic that needs to pass from one server to another, or to and from client devices that connect to the servers. For the rest of this article, we are going to refer to these different segments as different server zones.
In the events of a security breach or compromise, you will forever thank yourself for segmenting your server into different networks, greatly limiting the severity of the attack if you have configured a good security policy and rules in your firewalls.
In my opinion, a proper network architecture/design is way more important than buying the latest shiny security box out there.
The Problem
Unfortunately, most network diagrams in educational material look something like the image below.
In this topology, there are only three different zones present: Inside, Outside, and DMZ. Depending on the size of your network and your security policy this kind of design might work just fine most of the time, but it does raise some questions about security.
Historically, client devices in the Inside zone were considered “secure” and would never cause harm to other resources or other client devices residing in the same Inside zone as them.
As you can see, the Inside zone is both a client zone and a server zone, meaning the clients usually have full access to all the servers in this zone, since client traffic doesn’t have to go through the firewall to reach the internal servers.
But nowadays, a compromised “trusted” device client is one of the biggest risks in cybersecurity. With most people using laptops that the employee carries with them every day and might even use at home, where security measures might be limited, the risks of carrying viruses, malware, or ransomware back to the office have most likely grown in the last few years.
Therefore, being on the Inside of the firewall shouldn’t automatically grant you access to every other internal resource. Every server zone should be evaluated and thoroughly locked down regardless of what function that specific server zone is serving. Only permit traffic that is needed and block the rest to improve security and minimize risks.
Most servers these days need to talk to other servers due to integration, data sharing, etc., so it can be a bumpy ride to move a server to a different IP network, especially if some server talking is done IP-to-IP, where you are not able to use DNS to your advantage by simply changing the IP address to which a DNS name is mapped to.
Moving currently active production servers from one IP network to another is usually tough work, and the Server administrators might hate you for bringing up the idea, but it’s for their own good!
The following segmenting models are to be viewed as examples of how you can segment server networks in different ways.
A combination of these models is probably what you are looking for, as no model cover ALL of the possible use cases that exist out there. As you will notice, some of these models can appear very similar to each other, depending on the kind on business/company you are working with.
Segmenting servers based on Security/Confidentiality Level
There are different ways to classify the importance of your servers, and it is not too uncommon that this is done based on information security requirements, decided by the IT Security group or similar, at the company.
For example, the HR servers could belong to the highest security level due to containing lots of sensitive information and being business-critical, compared to something like an internal test server for creating service desk tickets, which isn’t nearly as important.
However, some things to consider before segmenting your servers based on this model.
Firstly, consider what happens if a server is “upgraded” to a higher security level, all of a sudden? How feasible is it to move the server to another/new zone, without causing too many changes to be made on other parts of your network/servers as a result? Should you even move it in the first place, or make configuration changes on the current zone to somewhat match the security settings of one of the already higher security zones? This could cause all kinds of headaches and make your server network architecture hard to understand and maintain in the long run.
Secondly, the mindset that certain servers are not “important enough” to hide or protect from other parts of the network is dangerous, as neglected servers running less than up-to-date versions of operating systems or software can be a gold mine for attackers. While some servers or systems are probably considered more critical to the operations of your business, they should all be evaluated and secure network measures should be put in place regardless of this. The layers of protection residing on a server itself depend on the operating system and its software, and there is no rule that important server software has “better” security than other server software.
Always assume that all servers need all network protection they can get.
Segmenting servers based on Function / Service
Since servers usually have specific purposes and relations to other types of servers, consider segmenting your server networks based on this. It might be hard to make a different server zone for every different type of service (or function) that your servers offer, but you can probably stretch the use case for some servers to make them fit into certain zones.
Some examples of these types of servers zones could be:
Active Directory servers
Internal DNS / DHCP servers
Jumpgate servers (RDP/RDS jump servers)
Database / Database Hotel servers
Payment / PCI-DSS servers
General internal servers
General external servers (for consultant specific projects)
IT monitoring servers
Surveillance / CCTV servers
VoIP / Video Conferencing / UC servers
Network Management / Configuration servers
Backup / File servers (FTP/SCP etc.)
Public servers (see more on DMZ segmenting further down)
One server zone for all servers belonging to the same function. For example, a multi-server system could consists of an application server, a database server, and a dedicated RDP Jumpgate for those servers. You could make one dedicated zone for all these servers.
Segmenting servers based on Instance
Deploying new servers in bigger organizations is commonly done in different phases, like the ones below.
Testing / Development Servers
Quality Assurance (QA) Servers
Production (PROD) Servers
However, having three different versions of each potential server zone could end up an administrative burden pretty quickly, so there could be a need to perhaps group together a lot of different servers in the Testing/Development and Quality Assurance zones, but keeping different servers more split up when it comes to their Production equivalents.
Segmenting publicly accessible servers in DMZ
If you are hosting some kind of public resources for others on the internet to access and use, these servers are most likely placed in some kind of DMZ in your firewall.
Depending on your type of business or company, segmenting your DMZ could be a real challenge if you have a lot of publicly available services. Assuming a somewhat common network type, you could segment your DMZ servers into the following zones:
Servers hosting typical web services via HTTP (TCP 80/443)
Servers hosting odd web services via TCP 8443/8080 or other non-standard ports.
Servers hosting specific non-web applications (could be any port, really)
Servers hosting DNS services (external DNS server)
Servers hosting Mail services
If you are hosting services that others on the internet can access, make sure to only make public the absolute minimum. For example, some websites or public systems can consist of multiple servers with integrations to servers like databases, application servers, image servers, and more, that need to be accessed by the website server, but not directly by end-users on the internet. Consider putting this kind of servers/resources on a different server zone, that is not publicly available, if possible.
Segmenting servers based on Internet connectivity
Many servers that offer services only for use by internal employees can be sectioned off and locked down to not have any internet access at all.
In terms of Internet connectivity requirements, I would say there are three scenarios:
Server needs no internet access at all.
Server needs internet access (only outbound via NAT, or more likely, PAT).
Server needs internet access (inbound, in DMZ) to offer public services on the internet.
If you decide to cut off internet access for certain servers that probably won’t need it, what things do you need to consider? What if a server needs Windows updates? Depending on your network size, perform updates manually (pretty rough to say the least) or set up an intermediate server (like WSUS) to download updates and then push them to the Windows servers.
Segmenting based on Department responsibility
This model is probably one of the most straightforward ones, which is to simply segment the servers into different zones depending on which department is responsible for said servers.
Information Technology (IT) servers
Human Resources (HR) servers
Sales servers
Engineering servers
Healthcare servers
Fieldworker servers
Student servers
Just to be clear, this doesn’t mean, for example, that an employee in the Engineering department cannot access a server in the Sales server zone if the firewall permits that kind of access, this is just a way to somewhat easily segment your servers into different segments, as most systems (hopefully) has kind of formal ownership within the company.
Some departments might require multiple server zones to better structure the network design.
Segmenting every server into their own server zone
If you are really looking to lock down your network and achieve a detailed understanding, control, and visibility of all traffic being sent to and from all of your servers, you could put every one of your servers into a different one. If your network is not too large and not too advanced, this solution is really solid.
Segmenting servers running legacy software
No matter which of the segmenting model(s) above you aim for, make sure to put servers running legacy software in a zone of their own. This is especially important if your legacy servers are accessible from the internet.
Unfortunately, there are older Windows/Linux distributions that cannot be updated or are considered legacy nowadays but are still in production nonetheless because they offer a service that is still needed today.
Segmenting servers behind different firewalls
If you want to go one step further from just using multiple zones and VLANs to separate your servers, you can also connect your servers to completely different firewalls, to achieve segmentation.
These different firewalls can be virtual instances (like Contexts in the ASA world or Virtual Systems in Check Point and Palo Alto terms) or different physical boxes, depending on your requirements and budget.
For example, you could have different virtual instances of firewalls for the different segmentation models described above and/or have different physical firewall hardware for servers accessible internally and servers accessible from the internet.
More physical boxes generally mean a higher total cost of ownership as you'll need both extra boxes and licenses/subscriptions connected to them, but in return, you get the opportunity to create a very structured server network design. Having more boxes could also mean more things to configure and maintain, but in some cases, this can be to your advantage, as performing maintenance on one physical firewall shouldn't affect traffic passing through the other firewall(s), unless it's traffic destined to that particular physical firewall.
Watch out for what you put behind the firewall
There are some instances where you should think twice before putting some type of resources in a zone behind a firewall.
OS Update Servers
Consider the case of an OS update server or a re-imaging server, which need to push a massive amount of data. If possible, put these types of servers directly into the zone/VRF (routing instance) where the client devices connecting to it will reside, to not put unnecessary traffic load on your firewall.
Multiple devices downloading updates or being re-imaged/re-installed at once can require loads of data to be moved very quickly, causing other server traffic not to be able to pass through the firewall correctly. Depending on your type of client management solution, you might be able to place the actual updating service (that clients download the updates from) on one server, while the actual management component resides on a different server in server zones behind the firewall, where it is protected.
WIRELESS LAN CONTROLLERS (WLC)
If you are tunneling all of your wireless traffic back to your central Wireless LAN Controllers (WLC), be careful to not hide the internal Access Point (AP) interface (often the same as the Management Interface) of Wireless LAN Controllers behind a firewall, as this could cause traffic to hit the firewall twice, once as CAPWAP traffic and probably once as the actual user traffic that was contained within the CAPWAP packets needs to pass through the firewall go get where it needs to be.
Different types of clients (employees, contractors, guests) should of course be put into different VRFs/VLANs, but make sure the communication path from AP to WLC is straightforward (routed), unless you are only using FlexConnect/locally switched APs, in that case, it can be okay to have the WLC behind the firewall.
There are probably many other similar cases like the two above that you need to take into account when designing your server networks, but these were the examples I could come up with on the spot.
Final notes
If you have made it this far in the article, you can see that there are many different ways to segment your server networks. No model will fit every use case, but I hope this article might have given you some tips and ideas on how to deal with server segmentation.
Server segmentation naturally means pushing more traffic through your firewalls - watch out for big jumps in the daily traffic flows. Pay extra attention to how your server backups are handled, from where and to do the big backups files need to be transferred, and how will it affect you?
Watch out for servers with multiple network interfaces, make sure you know what you are doing if you need to implement this. You could quickly lose control of which traffic is passing through your network and your servers, and the risk of backdoor access between two separate servers zones is also a thing to consider.