Zero Trust Begins With Internal Segmentation and Inspection

Zero Trust Begins With Internal Segmentation and Inspection

    In this post, I want to highlight a common network topology in K12s where the traditional three tiered or collapsed core designs are used. In that architecture, typically, routing is done either on the core or aggregation switch. Instead, we can take a more security first approach to how traffic is handled internally and out to the internet.

    To begin, I’ll dive into how traffic flows in this typology and provide examples in a lab. Something key to look at in this design is that traffic will be implicitly allowed unless you set up L3 filtering rules. In traditional IP routing when you begin setting up routes and subnets on your core switch, inter-VLAN routing is enabled by default. This is a requirement because that is what allows your internal traffic out to the internet, typically over a transport VLAN to your NAT router or firewall, but the flaw is that it allows all traffic within the core to intercommunicate, including your internal subnets. Later I’ll dive into ACLs and VRFs.

 

The Problem

    In the below example, the core switch contains the SVIs/Layer3 interfaces for the Staff (VLAN10), Student (VLAN20), and ISP Transport (VLAN99). It also has IP routing enabled so that Staff and Student traffic can reach the internet. They typically do have an edge firewall upstream of the core switch, but VLANs are terminated at the core switch for routing before reaching the firewall.

    So, let’s examine how traffic will flow in this scenario. The Staff PC on the left has IP 10.10.10.2, its default gateway lives on the core switch 10.10.10.1. It can reach the ISP router through the default route on the core switch. The same is true for the Student PC (IP 10.10.20.2, default gateway 10.10.20.1). If there is an upstream firewall it can provide routing and traffic inspection to the internet for Northbound traffic.

In the lab:

    Staff can ping student gateway and end device:

    And Student PC can do the same:

 

 

    Now here is the first issue, should the Student and Staff networks be able to communicate with one another? We put them into separate VLANs for a reason, to help separate access to resources, whether that is PII, smart whiteboards, or specific websites staff can access that students should not. So why would we allow their devices to communicate? In the example above, because IP routing is enabled, which is required to provide internet access in this design, inter-VLAN communication is implicitly enabled. This means that both staff and student devices can communicate with one another.

 

    Expand this example to a large production network where there are more than just staff and student devices. IoT/OT, servers, building controls, door access controls, signage, tvs, phones, printers. Should student devices or even GUEST devices be able to run a network scan and see all those different attack vectors? I hope not! In this example that is potentially what is enabled. So how can we fix this problem?

    VRFs/ACLs could be the answer. Separating traffic by creating a rule list on your core switch CLI that prevents subnet X from communicating with subnet Y, and Z, and A, and B, and G, and so on for all your different subnets. This can explode quickly for networks with large numbers of VLANs. It can also be difficult to manage, especially for the poor network engineer that will inherit the spider web of ACLs on your core switch when you move on to a different organization. It’s common to put guest traffic into a separate VRF.

 

 

The Solution

    Migrating internal VLANs and routes to your firewall would provide several benefits including implicit segmentation/control of where traffic flows, how it is inspected, and give you increased visibility. When configuring SVIs and subnets on your firewall, to allow outbound and/or east-west communication between devices you must create a firewall policy, otherwise the traffic will be blocked through the implicit deny rule. This is a complete 180 to the way routing on the core worked, where IP routing, without filters, essentially enables and implicit ACCEPT for all traffic. This also gives you the ability to use advanced reporting and visibility features within the firewall, rather than just the network infrastructure. Giving you greater visibility on where traffic is flowing and how clients are behaving.

     So here is the same example, as before, but with the SVIs on the firewall:

    Now if I want to enable internet access for the clients, I need to create a firewall policy. I can also use IPS/AV/Application Control/Web Filtering on this policy and create different rules on what internet services they can each access.

 

    If I want to enable staff and student devices to communicate between each other, or any subnets to interact with one another, I can create a policy for that. I can also turn on security profiles such as IPS/AV/Application Control/Virtual Patching. This can be useful for preventing internal attacks or the spread of malware. Especially critical for communication to on-prem hosted services like Active Directory servers or file stores. FortiGate can inspect the traffic traversing internally.

    The goal here is that clients can still get out to the internet and access any required internal resources, but only the resources that are explicitly allowed using firewall policies. By layering on inspection, we are leveraging threat intelligence provided through FortiGuard labs to protect internal resources from traffic that would be allowed by the firewall policy. This is especially important if a user’s device becomes compromised, or a bad actor gains unauthorized access to the network or an employee’s device.

 

    Let’s look at how traffic will flow in the topology above. I have two Linux devices connected to the lab switch, one in Staff, one in Student and I do not have a Staff-Student firewall policy.

    Failed ping:

    Now after I enable a staff-student policy:

    Successful ping:

    Taking this a step further, how about two devices within the same VLAN? Traditionally you subdivide the network into VLANs to group like devices at layer two of the OSI model, but what if we want to microsegment the network so that like devices are grouped but still cannot connect to each other? For this example, I will put both Linux devices into the same Staff VLAN:

    Now we see two the second Linux client now with an address from the Staff VLAN at 10.10.10.4:

    And both clients can reach each other:

Microsegmentation with Intra-VLAN Blocking

    As a way of increasing security and further segmenting the network, should two staff devices be able to reach one another directly, without going through inspection? If the answer is they shouldn’t reach each other at all, we can enable block intra-VLAN traffic in the switch settings within FortiGate.

    Within each VLAN you create you can turn on or off this setting:

    Now the clients can’t communicate through the switch:

 

Intra-VLAN Inspection

    But what if we want to enable communication between the clients through FortiGate as a security inspection point? We still want them to not communicate through the switch at layer 2. We can enable this by leaving on block intra-VLAN traffic while also enabling proxy ARP on the FortiGate:

 

    We also need a firewall policy to allow and tell FortiGate to inspect the traffic:

    Finally, we have successful pings and proof that traffic is being proxied through the FortiGate after inspection:

 

Performance Concerns

    What about high performance applications? Would sending traffic all the way to a firewall potentially at the edge of the network create issues? Possibly, depending on the application. There are options for this and it’s not an all or nothing requirement to have all traffic sent through a firewall. You could place a smaller firewall closer to the clients/applications that require low-latency internal communications. You could also keep those subnets terminated on the core and use ACLs/VRFs to separate their traffic. There is no rule saying everything needs to traverse a security checkpoint or where in the network that inspection must occur.

 

 

Resources:

FortiGate Proxy Arp: https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-the-proxy-arp-feature-in-FortiGate/ta-p/247736