Data Center Security
Data center security is always a significant concern in data center networks. ACI security addresses security concerns with several application-centric infrastructure security options. You may have heard of the allowlist policy model. This is the ACI security starting point, meaning only something can communicate if policy allows it. This might prompt you to think that a data center firewall is involved. Still, although the ACI allowlist model does change the paradigm and improves how you apply security, it is only analogous to access control lists within a switch or router. So, we need additional protection. So, there is still a need for additional protocol inspection and monitoring, which data center firewalls and intrusion prevention systems (IPSs) do very well and can be easily integrated into your ACI network. Here we can introduce Cisco Firepower Threat Defence (FTD) to improve security with Cisco ACI.
Cisco ACI is one of many data center topologies that needs to be secured and does not consist of a data center firewall. It has a zero-trust model. However, more is required; the policy must say what can happen. Firstly, we must create a policy; you have Endpoint groups (EPG) and a contract. These would be the initial security measures. Think of a contract as the policy statement and an Endpoint group as a container or holder for applications of the same security level.
Then on top of that, you can add a service graph to insert your security function. Now we are heading into the second stage of security. What we like about this is the ease of use. If your application is removed, all the dots, such as the contract, EPG, service graph, and firewall rules, get released. Cisco calls this security embedded in the application and allows automatic remediation, a tremendous advantage for security functionality insertion.
For pre-information, you may find the following posts helpful:
ACI Security |
|
- A key point: Back to basic with Cisco ACI
The ACI, an application-centric infrastructure SDN solution, consists of a spine-leaf fabric with a spine that connects the leaf, and the leaf switches combine the workloads and the security services. All of this is managed by the controller. So to create policy, we need groups, and here we have EPG. In an EPG, all applications can talk by default.
Data center security: EPG communication
Devices within an Endpoint group can communicate, provided they have IP reachability which the Bridge Domain or VRF construct can supply. Communication between Endpoint groups is, by default, not permitted. The defaults can be changed, for example, with intra-EPG isolation. Now the endpoint in a single Endpoint group cannot communicate. They need a contract like a stateless reflective access list for external communication. There is no full handshake inspection. So the ACI contract construct is not a complete data center firewall and needs to provide stateful inspection firewall features.
Data center security: Cisco ACI ESG
We also have ESG, which is different from that of an EPG. EPG is mandatory and is the way you attach workloads to the fabric. Then we have the ESG, which is an abstraction layer, and now we are connected to a VRF, not a bridge domain, so we have more flexibility. As of ACI 5.0, Endpoint Security Groups (ESGs) are Cisco ACI’s new network security component. Although the endpoint groups (EPGs) have been providing network security in Cisco ACI, EPGs have to be associated with a single bridge domain (BD) and used to define security zones within a BD.
This is because the EPGs define both forwarding and security segmentation at the same time. The direct relationship between the BD and an EPG limits the possibility of an EPG spanning more than one BD. This limitation of EPGs is resolved by using the new ESG constructs.
As we discussed in ACI security, devices are grouped into Endpoint groups. This grouping allows the creation of policy enforcement of various types, including access control. Once we have our EPGs defined, we need to create policies to determine how they communicate with each other. For example, a contract typically refers to one or more ‘filters’ to describe specific protocols & ports allowed between EPGs. We also have ESGs that provide additional security flexibility. Let’s dig a little into the world of contracts in ACI and how these relate to old access control of the past.
Starting ACI Security
ACI Contract
In network terminology, contracts are a mechanism to create access lists between two groups of devices. This function was initially developed in the network via network devices using access lists and then eventually managed by firewalls of various types depending on the need for deeper packet inspection. As the data center evolved, access-list complexity increased.
Adding devices to the network that required new access-list modification could become increasingly more complex. While contracts satisfy the security requirements handled by access control lists (ACLs) in conventional network settings, they are a more flexible, manageable, and comprehensive ACI security solution. Contracts control traffic flow within the ACI fabric between EPGs and configured between EPGs or between EPGs and L3out. Contracts are assigned a scope of Global, Tenant, VRF, or Application Profile, which limits the accessibility of the contract.
- A key point: Issues with ACL with traditional data center security
With traditional data center security design, we have traditional access control lists (ACLs) with several limitations the ACI fabric security model addresses and overcomes. First, the conventional ACL is very tightly coupled with the network topology. They are typically configured per router or switch ingress and egress interface and are customized to that interface and the expected traffic flow through those interfaces.
Due to this customization, they often cannot be reused across interfaces, much less across routers or switches. In addition, traditional ACLs can be very complicated because they contain lists of specific IP addresses, subnets, and protocols that are allowed and many that are not authorized. This complexity means they are challenging to maintain and often grow as administrators are reluctant to remove any ACL rules for fear of creating a problem.
The ACI fabric security model addresses these ACL issues. Cisco ACI administrators use contract, filter, and label managed objects to specify how groups of endpoints are allowed to communicate.
ACI Security: Topology independence
The critical point is that these managed objects are not tied to the network’s topology because they are not applied to a specific interface. Instead, they are rules that the network must enforce irrespective of where these endpoints are connected. So, security follows the workloads allowing topology independence. Furthermore, this topology independence means these managed objects can easily be deployed and reused throughout the data center, not just as specific demarcation points.
The ACI fabric security model uses the endpoint grouping construct directly, so allowing groups of servers to communicate with one another is simple. With a single rule in a contract, we can allow an arbitrary number of sources to communicate with an equally arbitrary number of destinations.
Data center security: ACI Micro-segmentation
We know that perimeter security is insufficient these days: lateral movement can allow bad actors to move within large segments to compromise more assets once breached. And traditional segmentation based on large zones gives bad actors a large surface to play with. Keep in mind that identity attacks are hard to detect. How can you tell if a bad actor moves laterally through the network with compromised credentials or if an IT administrator is carrying out day-to-day activities?
Micro-segmentation can improve the security posture inside the data center. Now, we can perform segmentation to minimize segment size and provide lesser exposure for lateral movement due to a reduction in the attack surface.
Microsegmentation with Cisco ACI adds the ability to group endpoints in existing application EPGs into new microsegment (uSeg) EPGs and configure the network or VM-based attributes for those uSeg EPGs. This enables you to filter with those attributes and apply more dynamic policies. We can use a variety of attributes to classify endpoints in a specific kind of EPG called µEPG Network-based attributes: IP/MAC VM-based attributes: Guest OS, VM name, ID, vnic, DVS, Datacenter.
Example: Microsegmentation for Endpoint Quarantine
Let us look at a use case. You might have separate EPGs for web and database servers, each containing both Windows and Linux VMs. Suppose a virus affecting only Windows threatens your network, not the Linux environment. In that case, you can isolate Windows VMs across all EPGs by creating a new EPG called, for example, “Windows-Quarantine” and applying the VM-based operating systems attribute to filter out all Windows-based endpoints.
This quarantined EPG could have more restrictive communication policies, such as limiting allowed protocols or preventing communication with other EPGs by not having any contract. A microsegment EPG can have a contract or not have a contract.
Improving ACI Security
Cisco ACI includes many tools to implement and enhance security and segmentation from day 0. We already mentioned tenant objects like EPGs, and then for policy, we have contracts permitting traffic between them. We also have micro-segmentation with Cisco ACI. Even though the ACI fabric can deploy zoning rules with filters and act as a distributed data center firewall, the result is comparable to a stateless set of access lists ACLs. As a result, they can provide coarse security for traffic flowing through the fabric.
However, for better security, we can introduce deep traffic inspection capabilities like application firewalls, intrusion detection (prevention) systems (IDS/IPS), or load balancers, often securing the application workloads.
ACI service graph
ACI’s service graph and policy-based redirect (PBR) objects bring advanced traffic steering capabilities to universally utilize any Layer 4 – Layer 7 security device connected in the fabric, even without needing it to be a default gateway for endpoints or part of a complicated VRF sandwich design and VLAN network stitching. So now it has become much easier to implement a Layer 4 – Layer 7 inspection.
And you won’t be limited to a single L4-L7 appliance only; ACI can chain many of them together or even load balancing between multiple active nodes, all according to your needs. The critical point here is to utilize it universally. The security functions can be in their POD connected to a leaf switch or pair of leaf switches dedicated to security appliances and not located at strategic network points.
Cisco FTD
With these features, we can now have additional security from Cisco FTD. FTD is a hardware form. If you don’t want physical, it can be virtual in the public and private cloud platforms. As you know, ACI can be extended to AWS, and you can use the same data center firewall. FTD, which stands for Firepower threat defense, comes from a converged solution. We have a converged NGFW/NGIPS on a new Firepower and ASA5500-x platforms. But now we have a single management point with the Firewall Management Center (FMC). So we take two images and bring them together.
Data Center Firewall: Cisco Security Firewall
For a data center firewall, we can use the Cisco secure firewall. The architecture of the Cisco secure firewall is modular. A high-end single chassis comprises multiple blade servers, also known as security modules. In addition, the threat defense software runs on a supervisor. The data center firewall is a highly flexible security solution. There are multiple ways to enable scalability and ensure resiliency in a Secure Firewall deployment, such as using clustering, multi-instance, high availability, and more.
Data center firewall: Routed mode
The Cisco secure firewall has different modes of operation. Firstly, it can be deployed in routed mode. In this mode, every interface will have an IP address. Such a design enables you to deploy a Secure Firewall threat defense as a default gateway for your network so that the end users can use the threat defense to communicate with a different subnet or connect to the Internet. In routed mode, a threat defense acts like a Layer 3 hop. Each interface on a threat defense can be connected to a different subnet, and the threat defense can serve as the default gateway. In addition, the threat defense can route traffic between subnets, like a Layer 3 router.
Data center firewall: Transparent Mode
We can also have a transparent mode. You can also deploy a threat defense transparently to stay invisible to your network hosts. So with transparent mode, we have no IP addresses on the interfaces, and we need a change of VLAN between interfaces. In transparent mode, a threat defense bridges the inside and outside interfaces into a single Layer 2 network and remains transparent to the hosts.
When a threat defense is transparent, the management center does not allow you to assign an IPv4 address to a directly connected interface. As a result, the hosts cannot communicate with any connected interfaces on the threat defense. Unlike with routed mode, you cannot configure the connected interfaces as the default gateway for the hosts.
Data center firewall: FDT Multi-instance DC use case
The higher Cisco secure firewall models also offer multi-instance capability powered by the Docker container technology. It enables you to create and run multiple application instances using a small subset of the total hardware resources of a chassis. In addition, you can independently manage the threat defense application instances as separate threats defense devices. So we are slicing the physical into multiple physicals to allocate each instance to CPU, memory, and disk. So we physically cut the hardware in multi or FTD. So this use case helps have a separate firewall for different traffic flows in the data center.
Let’s say for compliance. It would help to have a separate firewall for north-to-south traffic and another for east-west traffic. You can also use VRF light instead of multi-instance, giving you more scalability as you can only have a certain number of multi-instance FTD. So we can use these two features together. So if you have a physical device, you can slide it, and in the management domain, we can have different management domains.
- A key point: Knowledge Check: Inserting data center security
Data center security with Service Insertion
In ACI, service devices can also be connected in traditional Layer 2 Transparent/Bridge mode or Layer 3 Routed mode by a front-end and back-end endpoint group (EPG), commonly known as a sandwich design in ACI. This type of service integration is called service insertion or service chaining.
Data center security with Service Graph
The concept of a service graph differs from the concept of service insertion. Instead, the service graph specifies that the path from one EPG (the source) to another EPG (the destination) must pass through certain functions by using a contract and internal and external EPGs, also known as “shadow EPGs,” to communicate to service nodes.
Cisco designed the service graph technology to automate the deployment of L4–L7 services in the network. Cisco ACI does not provide the service device separately from a physical device. Still, it can configure it as part of the same logical construct that creates tenants, bridge domains, EPGs, etc. When deploying an L4–L7 service graph, you can choose the following deployment methods:
- Transparent mode: Deploy the L4–L7 device in Transparent mode when the L4–L7 device is bridging the two bridge domains. In Cisco ACI, this mode is called Go-Through mode.
- Routed mode: Deploy the L4–L7 device in Routed mode when the L4–L7 device is routing between the two bridge domains. In Cisco ACI, this mode is called the Go-To mode.
- One-Arm mode: Deploy the L4–L7 device when a load balancer is on a dedicated bridge domain with a single interface.
- Two-Arm mode: Deploy the L4–L7 device in Two-Arm mode when a load balancer is located on a dedicated bridge domain with two interfaces.
- Policy-based redirect (PBR): Deploy the L4–L7 device on a separate bridge domain from the clients or the servers, and redirect traffic to it based on protocol and port number.
With policy-based redirect (PBR), the Cisco ACI fabric can redirect traffic between security zones to L4-L7 devices, such as a firewall, intrusion-prevention system (IPS), or load balancer, without the need for the L4-L7 device to be the default gateway for the servers or the need to perform traditional networking configuration such as virtual routing and forwarding (VRF) sandwiching or VLAN stitching. PBR simplifies configuration because the VRF sandwich configuration is not required to insert a Layer 3 firewall between security zones. The traffic is instead redirected to the node based on the PBR policy.
Data Center Firewall: Secure Firewall Insertion and PBR
Let’s say you have a single application design. We have EPG that groups applications. These EPGs are tied to the bridge domain, and each bridge domain has a different subnet. This could be a simple 3-tier application with each tier in its own EPG. The fabric performs the routing. Now we need to introduce additional security and have a firewall inserted. So we must have FTD between each EPG, representing the application tiers.
So, what happens is that you create a service graph on top of the contract that will influence the routing decisions. In this case, the ACI relies on PBR to redirect traffic defined in the contract to the security service. So when traffic hits the leaf switch, the firewall will be waiting in a different bridge domain and subnet.
The fabric will create whatever is needed to forward the traffic to the firewall, get inspected, and go back to the destinationIf you remove it, the firewall; the ACI will return to regular ACI routing. More and less instantaneously. So PBR is not routing; it is switching. Here we can pre-empt the switching decisions and forward traffic to the firewall. Because traffic goes to the leaf switch where the PBR rules are enforced, traffic will be sent to the security service defined in the service graph.
We can also use this for microsegment, even if you have all workloads in the same EPG. So we can leverage PBR to redirect traffic within an EPG/ESG. For example, attaching a service graph to redirect traffic to the FTD for traffic inside an EPG is possible.
Closing Highlights of ACI Security
Application-centric policy model: ACI security provides an abstraction using endpoint groups (EPGs) and contracts to more easily define policies using the language of applications rather than network topology. This overcomes a lot of the problems we have with standard access lists.
The ACI security allowlist policy approach supports a zero-trust model by denying traffic between EPGs unless a policy explicitly allows traffic between the EPGs. Make sure you have applications of the same security level in each EPG.
Unified Layer 4 through 7 security policy management: Cisco ACI automates and centrally manages Layer 4 through 7 security policies in the context of an application using a unified application–centric policy model that works across physical and virtual boundaries as well as third-party devices.
Policy-based segmentation: Cisco ACI enables detailed and flexible segmentation of physical and virtual endpoints based on group policies, thereby reducing the scope of compliance and mitigating security risks.
Integrated Layer 4 security for east-west traffic: The Cisco ACI fabric includes a built-in distributed Layer 4 stateless firewall to secure east-west traffic between application components and across tenants in the data center.
- Rise in Ransomware Attacks - March 31, 2023
- Network Connectivity - March 30, 2023
- Carriers Based on Open Ethernet with SONiC - March 28, 2023