Security has become paramount in today’s dynamic IT environment. In previous blog posts, I introduced various network flow patterns of Palo Alto integration with AWS GWLB. Coming from years of experience in on-prem hardware Palo Alto firewall deployments, I have to make quite a bit of adjustments. In this blog, I share how I approach zone-based security, micro-segmentation and dynamic cloud workloads with GWLB and Palo.
Introduction
In public cloud computing, Security Group (SG), or its equivalent form in other vendors, is widely used to protect workloads. It is perceived as a basic stateful firewall where 5-tuple of protocol, IP addresses, ports are specified. If L3/L4 firewall meets your security requirements, Security Group is a great choice. As it sits much closer to workloads, Security Group can serve as the main component of micro-segmentation design. However, there are increasing demands to inspect, control and monitor traffic based on identity, application characteristics, locations and etc. To support these L7 firewall features, vendor products like Palo Alto can be leveraged.
When these vendor solutions are deployed on-prem, zone-based security model is widely used. The network is partitioned into different zones, which typically include external, DMZ, intranet, and other zones for classified workloads/data. Each security zone is attached to firewall devices on a separated physical or logical interface. In a zone-based model, firewalls play two major roles. First, they participate in network L3 routing decisions among security zones. Dynamic routing protocols or static routes are configured on firewalls. Second, security policies are enforced to inspect traffic crossing security zone boundaries.
In early firewall cloud deployment patterns, the zone-based approach is common. Virtual firewall appliances are created with multiple NICs to mimic hardware chassis. The firewall NIC IP addresses are defined as next hop in Cloud Route Table. Due to the lacking of L2/L3 network protocols supported on public clouds, it is very challenging to achieve firewall HA and scalability.
AWS GWLB and Palo Alto Integration
GWLB is a new integration pattern from AWS for third-party network and security appliances. In a previous blog, I explained GWLB using the concept of bump-in-the-wire. GWLB helps decouple firewall’s network routing role from its security services. Most of the network routing configurations are shifted to the underlay native cloud side. Network topology changes, either due to user’s own requirements or from introductions of new AWS network features, are transparent to firewalls.
The “bump’ in GWLB also offers the flexibility to direct traffic into firewalls at random AWS network locations. The ingress pattern is a good example of this idea. Internet ingress raffic is brought to firewalls through local GWLBE. Only local VPC subnet Route Tables need adjustments. There is no need to re-wire virtual firewall appliances.
What’s the catch?
The bump-in-the-wire concept implies firewalls run in transparent mode. It’s similar to virtual wire in Palo’s terminology. Firewalls behind GWLB can be considered as L2 devices. Traffic enters and leaves firewalls on the same interface that supports GENEVE encapsulations. I am so used to thinking about firewall rules from the perspects of source zone and destination zone. This is the first adjustment to make when planning GWLB deployment.
Design Zone-Based Policies using Resource Metadata (Tags)
In GWLB, the zone associated with firewall appliance interface does not offer much value in policy enforcements. While IP addresses and subnets can still be used to construct firewall rules, they do not provide context information of applications or networks. It is not a scalable solution in security policies management and audit.
In a public cloud environments, resource metadata and tags are widely used for many purposes. Is there chance to use AWS tags in the place of IP? Well, Palo Alto’s Dynamic Address Group (DAG) is an option. When defining DAGs, AWS tags are used as filters. When the mapping of these tags to IP addresses/subnets are established, Panorama propagates IP information to firewall for traffic inspection.
In zone-based model, workloads and subnets are typically described as belonging to a certain security zone. I would simply rephrase it as resources tagged with said security zone name. Effectively, the relationship between resources and physical security zone is digitized into logical zone based on tags. Instead of spending time on partition physical network to fit zones, now the focus is changed to create resoource tag hierarchy that establishes virtual security zones. The digitization of security zone is a powerful concept. Zones can be created at a fine-grain level. It offers another building block for micro-segmentation design.
Implementation I: Palo Alto AWS Plugin
Palo Alto offers DAG plugins tailored for major cloud providers. They all work in similar fashions. The AWS plugin queries AWS accounts and retrieves resource tag <-> IP mappings at certain intervals. If an entry is changed, Panorama updates firewalls for that particular mapping record. Note here Panorama only publish a mapping to firewalls if it is referenced in security policies. This is to minimize firewall loads.
Figure 1 illustrates an application migrated from on-prem to AWS. It consists of web and database tiers. In the on-prem environment, the corresponding servers sit in web and db security zones. Each security zone is attached to different interfaces on firewalls. With GWLB, traffic between the source (App) and destination (DB) goes through the same eth1 interface on the firewall appliance.
In this example, the subnet used for web EC2 instances is tagged with the zone name of “web”. A DAG of web_net_DAG is created that filters on zone and type tags. Similar DAG is created for “db” subnet as well. Then security policy is created that blocks traffic between the two virtual zones.
Next, DAGs are created for web and DB components of the application. A second security policy is constructed to allow communication between the two tiers. If there are other applications deployed on the same web subnet, they are not able to query DB of App1. Some level of micro-segmentation is achieved.
With DAG, no IP address or subnet is directly referenced in security policy. In cloud computing, workloads tend to scale up/down or be re-deployed constantly. DAG and AWS plugin provides a good answer to handle the dynamic nature of Cloud.
Implementation II: Palo Alto DAG APIs
With the polling model, AWS plugin is limited to predefined query intervals. The minimum value might come short in meeting your convergence requirements. The recent versions of this plugin add support of ALB, NLB, and VPC endpoints, on top of EC2 instances. However, you might have AWS resources to inspect not seen on the list. If you have development resources, I would highly recommend exploring DAG APIs to complement AWS plugin. Depending on your exact use cases, these API calls can be triggered by events (ie Cloudtrial) or invoked periodically. Figure 2 illustrates the use of AWS Lambda.
Takeaways
In this blog, I shared my designs of using resource metadata to support zone-based security and micro-segmentation with GWLB. The transformation from physical zones to tag-based logical zones is the key. My focus is not to debate micro-segmentation replacing zone-based approach. I believe the digitization of security zones provides flexibility moving along the spectrum between zone-based and micro-segmentation designs.
Tag-based security boundary also streamlines CI/CD pipelines. The need to submit separated firewall request is greatly reduced. Git becomes the central place for development, infoSec and other teams to request, review, approve, deploy and audit security policies.
