Many organisations today face a challenge in securing enterprise networks that were designed prior to internal segmentation and security becoming a primary concern. It is very difficult to retrofit security into a network design, especially when you want to avoid changing server configurations, minimize downtime and impact, maintain performance within existing network segments, and progressively phase in security rules. In this blog post, we’ll discuss an approach we have developed and used for both new network deployments, as well as, retrofits.

THE PROBLEM

Retrofitting security into a network design while avoiding server configuration changes, downtime and performance issues.

OUR APPROACH

We have successfully used solutions based on this type of design in large managed VPN environments, as well as, corporate networks with multiple facilities.

The Scenario

In this simplified example, we’ll address an organisation that has two server networks (10.1.1.0/24 and 10.1.2.0/24) that need to communicate with each other at line rate. Users are in a network segment in 10.1.3.0/24. After a recent audit, a lack of internal segmentation has been raised as a concern, the administrative interfaces of the servers are exposed to all users and include many difficult to patch applications.

The Process

Introducing a Next Generation Firewall with IPS capabilities will address these legitimate concerns, however, there are a wide variety of servers, applications and appliances in the two server networks, their interaction with the user network isn’t fully understood. Some of them are licensed based on their IP address and the server administrators are not eager to change the network design or configuration.

In order to separate the users from the servers, we are going to create a new VRF routing table on the core switch. VRF is a technology that allows a network device to maintain multiple distinct routing tables on the same switch or router. Devices in different VRFs can’t communicate with each other. We will place the two server networks inside a new VRF called servers. The gateway IP addresses will remain on the switch and there will be no impact on the speed of communications between servers in different subnets. We will leave the users in the global routing table in this example.

We also create two new /30 networks that are going to be used to connect the two network segments to a next generation firewall. The firewall can be either physical or virtual. We typically run OSPF on the firewalls and core switch in order to exchange routing information between the devices. While there isn’t much of a need in this simple example we use this for redundancy in most of our designs. The firewall continues to terminate the Internet connection as it did before the change.

With these changes made, traffic from users to the servers will now pass through the firewall. We would typically start in monitoring mode with a set of rules permitting all traffic so we can start to analyse the traffic between the users and servers, progressively we build out rules for desirable traffic until we are able to remove the permit all rules.

IN SUMMARY

This is an extremely powerful technique to help address network segmentation needs as it minimizes changes and maintains performance. All of the groundwork can be done in advance so the firewall can be fully deployed, then during a brief maintenance window, you change the VRF on the interfaces and change the traffic flow to pass through the firewall.

Building out from these techniques we have:

Used multiple firewall devices with different route costs for high availability

We have extended from these principles to build out redundancy with multiple firewalls at different sites.

We have extended segments between different WAN sites so that server traffic between two data centres will flow within the VRF between the two sites.

In a large managed VPN environment with centralised services and internet access for content filtering, we have traffic landing on VPN routers inside a VRF, from their traffic flows through a central firewall to access either central resources or the internet.

Some of these resources are actually remote services accessed via another VPN, rather than deploy additional hardware for this VPN we have placed these tunnels in another VRF, traffic arrives on the VPN router, passes through the central firewall / IPS for inspection and filtering before returning to the same VPN router to reach the remote service.

Have you faced this problem? Have you tried a different approach? Reach out and let us know, we would like to hear from you. Perhaps you are now facing this problem and need help working through your network architecture; we are here to help. Reach out and let’s discuss.