Design DDoS Protection for Oracle Cloud Infrastructure
While there are many design options from which to select, the common factors for most of the designs is that they must be:
- Aligned to business security standards
- Secured end-to-end
- Follow a defense-in-depth model
- Easy to manage
- Scalable
The primary objective of the OCI DDoS protection service is to provide a secure and scalable solution that meets an organization’s DDoS requirements, while supporting multiple environment tiers, including production, staging, development, quality assurance, and disaster recovery. OCI DDoS protection services also help a company stand up 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), Flexible Load Balancers (FLB), third-party Next Generation Firewalls (NGFWs) with DDoS enabled, and TLS/SSL certificates, along with the associated benefits and considerations for each design.
Evaluate And Choose An Architecture Design Option for DDoS Prevention on OCI
There are various architecture design options you can choose, depending how you'd like your DDoS prevention to scale.
Design Option 1: Web Application Firewalls and Single Network Load Balancer
In this design, TLS certificates are used 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 (e.g., production, QA, and DR) and forwarding HTTP/S traffic to a single NLB, a single FLB and its corresponding back-end sets.
Note:
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. This provides the ability to implement firewall DDoS on a zone based level, or on a global level to focus on layer 3 and layer 4 attacks.The following diagram illustrates this architecture.
single-network-lb-ngfw-architecture.zip
As traffic ingresses through the OCI edge, OCI WAF edge policies perform TLS/SSL termination. The packet is then 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. By default, this is 443/TCP, which can be configured to forward on specific ports.
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 in layer 3 and 4, and is placed in a public subnet. The NLB will typically be configured to preserve the client source-IP address. Traffic ingressing through the OCI WAF will be proxied, using documented OCI WAF CIDRs dedicated to the OCI WAF service. 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 this design leverages 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.
Assuming the NGFW supports decryption and inspection, we can decrypt the traffic to perform IDS/IPS on unencrypted payloads on the NGFW, prior to forwarding the traffic to a given FLB.
Considering the requirements provided and the design option described above, we can conclude the following best practices for this deployment:
- Separate WAF policies for each environment tier (production, development, and QA).
- Use a single network load balancer (NLB).
- Reuse the same backend NGFWs for multiple environment tiers.
- Design a defense-in-depth architecture.
- Secure the environment end-to-end.
- Mitigate and control attacks from on-premises coming into Oracle Cloud.
- Gain layer 3 and layer 4 DDoS protection with organizational control.
- Configure DDoS in the firewall layer with user control to compliment Oracle's offerings.
Design Option 2: Web Application Firewalls and Multiple Network Load Balancers
In this design, the technology, components, and data flow remain the same as our previous design. After traffic ingresses through the OCI edge, it gets processed and inspected by the OCI WAF edge policies for any malicious WAF layer 7 payloads prior to being sent to the NLB, NGFW, and ultimately a private ALB. Similarly, all non-HTTP/S flows will always ingress via the NLB, bypassing the OCI WAF and the NGFWs, and finally the private NLB. This provides the ability to implement firewall DDoS on a zone based level, or on a global level to focus on layer 3 and layer 4 attacks.
The key difference in the Option 2 design is leveraging multiple NLBs on a per environment tier (production, development, and QA) basis to segregate environment traffic. In Option 2, each NLB uses a unique secondary IP address on the NGFW as the backend-set to forward traffic. Traffic 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 (production, development, and QA).
The following diagram illustrates this architecture.
