I have many conversations with customers regarding the various traffic flows and security patterns we can achieve using OCI cloud native features co-mingled with third party Next Generation Firewalls (NGFW) cloud appliances. While there are many design options to select, the common factors for most of the designs typically have the following requirements (not in any specific order):
- Design must be aligned with the business security standards
- Design must scalable
- Design must be secure end-to-end
- Design must follow a defense-in-depth model
- Design must be easy to manage from an operational perspective
The primary objective of this blog is to provide a secure and scalable solution that meets the customers requirements of supporting multiple environment tiers (e.g. Prod, Stage, Dev, QA, etc.) and the need to have a highly available and scalable architecture with a defense-in-depth security model leveraging OCI cloud-native components such as Web Application Firewalls (WAF), Network Load Balancers (NLB), Application Load Balancers (ALB), third party Next Generation Firewalls (NGFWs), and TLS/SSL certificates, along with the associated benefits and considerations for each design.
A brief overview of the various technologies we will leverage for the design:
Web Application Firewalls (WAF)– Oracle Cloud Infrastructure Web Application Firewall (WAF) is a regional-based and edge enforcement service that is attached to an enforcement point, such as a load balancer or a web application domain name. WAF protects applications from malicious and unwanted internet traffic. WAF can protect any internet facing endpoint, providing consistent rule enforcement across a customer’s applications.
There are two types of OCI WAF solutions: WAF Edge Policy and WAF Firewall Policy. The WAF Edge Policy is used for enforcing policies at the edge whereas a WAF Firewall Policy is associated to ALBs. In this blog, we will leverage WAF Edge to enforce WAF policies prior to entering the customer’s VCN.
Network Load Balancer (NLB) – The Oracle Cloud Infrastructure Flexible Network Load Balancing service (Network Load Balancer) provides automated traffic distribution from one entry point to multiple backend servers in your virtual cloud network (VCN). It operates at the connection level and load balances incoming client connections to healthy backend servers based on Layer 3/Layer 4 (IP protocol) data. The service offers a load balancer with your choice of a regional public or private IP address that is elastically scalable and scales up or down based on client traffic with no bandwidth configuration requirement.
Flexible Load Balancer (FLB)– The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from one entry point to multiple servers reachable from your virtual cloud network (VCN). The service offers a load balancer with your choice of a public or private IP address, and provisioned bandwidth.
Next Generation Firewalls (NGFW)– A next-generation firewall is the latest generation of firewall technology, leveraging traditional firewall services coupled with advanced layer 7 filtering, threat detection/prevention, deep packet inspection, and intrusion detection/prevention features.
TLS/SSL Certificate – A TLS/SSL certificate is a digital certificate that authenticates a website’s identity and enables an encrypted connection.
There are two main types of certificates: standard certificates and wildcard certificates. A standard single domain SSL certificate secures one domain name. A. wildcard SSL certificate secures your domain and an unlimited number of first-level subdomains. In general, wildcard certificates are considered less secure since the compromise of the certificate will lead to a larger set of resources impacted whereas a standard single domain certificate is more secure because if there is a compromise, only the resources using the certificate are impacted.
Design Option 1: Web Application Firewalls + Single Network Load Balancer + Next Generation Firewall (active/active)
In this design, we leverage the use of TLS certificates on the WAF, NGFW, the private FLBs and the back-end servers for HTTP/S flows. The HTTP/S flow will always ingress from the OCI WAF edge and gradually work its way through an NLB, followed by NGFWs, and finally the private FLB. This approach requires multiple WAF policies for each environment tier (Prod, Dev, etc.) forwarding HTTP/S traffic to a single NLB, and a single FLB with its corresponding back-end sets.
For all non-HTTP/S flows, the flow will always ingress via the NLB, bypassing the OCI WAF, by the NGFWs, and finally the private NLB.
As traffic ingresses through the OCI edge, OCI WAF edge policies perform TLS/SSL termination where the packet is decrypted so that it can be inspected for any malicious WAF layer 7 payloads prior to sending the traffic towards Origin on a specific port, which by default is 443/tcp. This can be configured to forward on specific ports. In our case, the Origin of the OCI WAF is configured to forward traffic to a single NLB which then forwards the traffic towards third-party NGFW compute instances for a given TCP port. For example, in the diagram above, the green and blue traffic flows from OCI WAF edge is sent to Origin (the NLB Listener IP address) on specific ports, 4443/tcp and 4444/tcp respectively. In turn, the NLB is configured to forward the traffic to the backend-sets (the NGFWs) on the same TCP ports.
The NLB operates at layer 4 and is placed in a public subnet. The NLB will typically be configured to preserve the client source-IP address. It’s noteworthy to mention that traffic ingressing via the OCI WAF will be proxied using documented OCI WAF CIDRs dedicated for the OCI WAF solution. Since the traffic is proxied from a list of documented OCI WAF CIDRs, we can add an additional layer of security by leveraging security lists and/or NSGs to limit the connectivity to a list of valid and trusted OCI WAF CIDRs. This also implies the NLB subnet flow logs and the third-party NGFW traffic logs will only see the IP addresses from the OCI WAF CIDR ranges as the source-IP.
Since the design is leveraging active/active firewalls using an NLB, the third-party firewall must perform source-nat prior to forwarding the traffic to the private FLB to maintain a symmetrical path for the return traffic. The NGFW will also need to perform destination-nat since the destination is a private FLB.
Additionally, we can decrypt the traffic to perform IDS/IPS on unencrypted payloads on the NGFW prior to forwarding the traffic to a given FLB, assuming the NGFW supports decryption and inspection.
Considering the requirements provided and the design option described above, we can conclude the following benefits and considerations for this solution:
Benefits
- Separate WAF policies per environment tier (Prod, Dev, etc.)
- Ease of management using a single NLB
- Same backend NGFWs for multiple environment tiers
- Defense in depth model
- Secure end-to-end
Considerations
- Certificate rotations require [proper planning and team synergy
- Using non-standard ports to support HTTP/S flows
- Cannot scale past 50 listeners per NLB
- Considering this is a single NLB design, we will not be able to scale past 50 listeners
- NLB listener port numbers cannot be re-used on a per environment basis
- Applications and/or services in different environment tiers (Prod, Dev, etc.) may require same listener port
To scale past some of the considerations mentioned above, we can scale the NLBs per environment tier. This will allow us to exceed overall 50 listeners the design is limited to by the use of a single NLB and will also allow the separation of environment tier (Prod, Dev, etc.) flows on a per NLB basis. Let’s look at the second design option listed below.
Design Option 2: Web Application Firewalls + Multiple Network Load Balancers + Next Generation Firewall (active/active)
In this design, the technology, components being used, and the data flow remain the same as our previous design: traffic ingresses through the OCI edge, gets processed and inspected by the OCI WAF edge policies for any malicious WAF layer 7 payloads prior to sending the traffic towards the NLB, NGFW, and ultimately a private ALB. Likewise, all non-HTTP/S flows will always ingress via the NLB, bypassing the OCI WAF, by the NGFWs, and finally the private NLB.
However, the primary difference in this design is leveraging multiple NLBs on a per environment tier (Prod, Dev, etc.) basis to segregate environment traffic. Each NLB will use a unique secondary IP address on the NGFW as the backend-set to forward traffic towards, and ultimately makes its way to the designated FLB for the given application or service. This design also introduces the ability to scale past the 50 listeners limitation using a single NLB. This design will also allow the re-use of NLB listener ports to standardize the traffic flows for each environment tiers (Prod, Dev, etc.).
Considering the requirements provided and the design option described above, we can conclude the following benefits and considerations for this solution:
Benefits
- Separate WAF policies per environment tier (Prod, Dev, etc.)
- Separate NLBs per environment tier (Prod, Dev, etc.)
- Same backend NGFWs for multiple environment tiers
- Defense in depth model
- Secure end-to-end
- NLB listener port numbers can be re-used on a per environment basis
- Applications and/or services in different environment tiers (Prod, Dev, etc.) may require same listener port
Considerations
- Certificate rotations require proper planning and team synergy
- Using non-standard ports to support HTTP/S flows
- More NLBs to support and may need to increase OCI service limits
The designs discussed in this blog are two of the more common ways to adopt a secure and scalable architecture leveraging OCI WAF, NLBs, NGFWs, and private ALBs and/or NLBs. There are other methods to achieve the design requirements using the same technologies that may be more suitable for your business and security needs. Please contact your dedicated Oracle team to determine the most appropriate solution to meet your requirements.
References:
OCI Network Load Balancer Documentation