Segmentation is one of the most used buzzwords right now in the world of networking. Reasons might be the rise of network attacks even on small to medium sized enterprises at the moment. Or simply to achieve certifications like ISO 27001.
Recently a lot of my customer experienced situations with malware like encryption trojans, or even with not so dangerous, malware like crypto currency mining software on their server. Neither you want to have in the network.
In this Post i want to briefly discuss what i like to share with my customer. What are the basic of segmentation with Cisco DNA Center. I will not cover how you should group your devices or which protocols should be allowed and which not. This is a whole new topic and highly individual.
In my opinion a next generation firewall is needed to get the most out of a proper segmentation.
So we know we want segmentation with the help of Cisco SDA, but how to start?
One thing what is a little bit confusing, especially at the beginning, is the difference between macro- and micro segmentation.
For the sake of easiness, i usually start with the question:
which traffic you want to be redirected through a Firewall for IDS/IPS, antivirus scanning and so on, and which traffic is OK to be controlled on a Group/Port basis, gaining advantages in terms of performance?
Because with SDA you have a build-in packet filter firewall, the sizing of the central firewall can be reduced by quite a lot. Let's start with the micro segmentation.
So this part is straight forward. You divide your devices into groups and control the traffic between the groups based on ports. For example only allow HTTP/HTTPS from production to sales.
And yes, you can control the traffic within a group! This is very common in production areas, where the machines are controlled and monitored remotely. A scenario could be to put all machines into a group and deny all traffic between them but allow traffic to a specific server. To control traffic to a destination outside the fabric, please refer to my article:
Use DNA Center Policy Matrix for traffic to Data center.
There is another very important consideration you have to take attention to.
Implicit deny or implicit permit?
The default behavior, if traffic is not covered in the policy matrix, is permit!
So how to start? It is a lot easier to start with an implicit permit. But be honest to yourself, when is the perfect moment to turn the switch from permit to deny? probably never. There is simply too much applications that could stop working and the troubleshooting will be time intensive.
So i suggest to start with fewer groups but with the default behavior turned to deny right at the beginning.
When you want to have an IDS/IPS, Virus Scanner and so on in between, things get a little more complicated. But not too much.
In earlier days it was pretty common to put the gateway of an IP network with high security risks on the firewall. The switching infrastructure was used as a transparent transport medium and the Vlans were stretched from the endpoints to the firewall.
I´ve seen a good amount of SDA implementations where the customer migrated this scenario 1:1. Creating a layer 2 VN leaving the fabric with a Layer 2 handoff to the firewall.
Besides that you should not use a Layer 2 handoff other than the migration process or very few specific scenarios, this has another big disadvantage, most customers aren't aware of.
A Layer 2 VN needs flooding turned on to work. But the SDA can only enforce the policies on unicast traffic. Therefore Broadcast and Multicast Traffic will reach the endpoints even you denied communication between the groups!
A better way to isolate certain IP Pools is to use Virtual Networks and leave the gateways inside the fabric. The most customers feel not very comfortable to have all devices in the same infrastructure. But even all devices are in the same fabric and all SGTs are found in the same policy matrix, traffic flow between Virtual Networks is not possible. It is like an imaginary wall between them. As long as the IP Pools/Gateways are in the same VN, the routing does its job and deliver the packets from point A to point B. Are the IP Pools/Gateways located in different VNs, no routing entries can be found and the default behavior will transport the traffic according to the default route out of the fabric.
In the most scenarios certain traffic should be allowed to flow between two VNs. This is the time a next generation Firewall comes into play.
Because every Virtual Network has its own unique exit, the firewall needs a routed transfer network for each. Most of the time this is done with multiple Vlan tags on a single logical link. The Firewall is now responsible to route and control the traffic between the VNs. The informations, which networks are located behind the different sub links, has to be stored in the Firewalls routing table. Either through dynamic routing between the Border Nodes and the Firewall or, more preferably, static routing on the Firewall.
Is a client in Virtual Network 1 sending traffic destined for a client in Virtual Network 2, the routing in VN 1 is pointing out of the fabric to the firewall, because the destination address is not known within the VN.
The Firewall must decide based on the configured rules, if the packet will be forwarded or not. If the traffic is permitted and the next gen scanning did not find any suspicious, the traffic will be forwarded out of the other subinterface according the routing table back into the SDA Fabric. Entering Virtual Network 2.
With a SGT aware Firewall it is possible to design rules based on the SGT tags. There are a few SGT aware Firewalls of different vendors on the market.
Please be aware, that the SGT information is not transported inline per default. SGT Inline tagging or SXP is needed. Please refer to my article: "Use DNA Center Policy Matrix for traffic to Data center" for this.
Another very common misconception is, where the enforcement point of the SDA Fabric is located. The answer:
Only the egress Edge Node will enforce the policy matrix!
In a scenario where the traffic is blocked in the DNA Center matrix but allowed on the firewall, the packet will travel the whole way to the egress network device just to be dropped there.
There is an interesting concept called PAP. It stands for Packet filter - Application Layer Gateway - Packet filter. Basically this means, that between two security areas there have to be three enforcement points. Two of them are Layer 4 based filters and one with next gen features. The two Ps should be maintained by another group of engineers that the A.
To achieve this you can implement the enforcement point on the Border Node or, of if you have, the Fusion Device. I covered this in my article "Use DNA Center Policy Matrix for traffic to Data center"
Lets re-imagine the scenario above -> DNA Matrix deny, Firewall permit. In the concept of putting the enforcement point inline, the packet will never reach the firewall and would not waste as much resources and bandwidth as before.
I hope this gives you an idea about the concept with segmenting using the Cisco DNA Center and an easier start. Let me know in the comments below if you need more informations or want to get another topic covered on this site.
Comments