Note:

Secure Your Applications using OCI Network Firewall and OCI WAF Regional with Let’s Encrypt Certificates

Introduction

In a landscape shaped by widespread digital transformation, safeguarding your applications is no longer optional - it is a critical priority. As organizations transition their workloads to Oracle Cloud Infrastructure (OCI), implementing a strong defense against cyber threats is essential. OCI offers a wide range of tools to strengthen your applications, and in this tutorial, we will walk you through how to protect your digital assets using OCI Network Firewall and OCI Web Application Firewall (WAF) regional/local.

Template

Why is this tutorial essential?

As your applications communicate with the outside world, they face the ever-present challenge of cyber security threats. This tutorial helps you to build a multi-layered defense, safeguarding your applications against both known and emerging threats by leveraging the power of OCI Network Firewall and OCI WAF regional. We will explore important concepts, including Multi-Domain support and the generation or renewal of X.509 certificates using standard tools. Additionally, we will delve into the use of the widely recognized and free service Let’s Encrypt. Through this, you will gain a comprehensive understanding of essential practices for securing your applications.

Who is this tutorial for?

This tutorial is designed for cloud architects, security professionals, and developers seeking a comprehensive understanding of OCI security features. Whether you are a seasoned cloud practitioner or just starting your journey into cloud security, this tutorial will equip you with the skills to build a robust defense around your applications.

What is OCI Network Firewall

Oracle Cloud Infrastructure Network Firewall represents a cutting-edge managed firewall service that is built using Palo Alto Networks. It is a Next-Generation Firewall Technology (NGFW). It offers machine learning-powered firewall capabilities to protect your OCI workloads and is easy to consume on OCI. As an OCI native firewall-as-a-service offering, OCI Network Firewall enables you to take advantage of the firewall features without the need to configure and manage additional security infrastructure. The OCI Network Firewall instance is highly scalable with built-in high availability and can be created in a virtual cloud network (VCN) and subnet of your choice.

The OCI Network Firewall service provides deep insights into the flow of data entering your cloud environments, addressing both incoming and inter-subnet or inter-VCN communication. In essence, it offers visibility into North-South network traffic and East-West network traffic. For more information, see OCI Network Firewall.

What is OCI Web Application Firewall Regional/Local

OCI Web Application Firewall (WAF) is a cloud-based security service that helps protect web applications from common security threats and attacks such as SQL injection, cross-site scripting (XSS), and Distributed Denial of Service (DDoS). The OCI WAF regional is the latest version of WAF that is typically deployed at a regional level, integrated with OCI Load Balancer to provide a flexible, scalable defense mechanism.. For more Information, see OCI Web Application Firewall.

Architecture

Architecture

This proposed architecture will include total protection for tenancy workloads by using the following components.

Data Flow Diagram

The network data flow can be easily seen in the following network diagram, incoming requests in green dot lines, responses in red dot lines.

Architecture

This diagram adheres to best practices for deploying the OCI Network Firewall for North-South traffic. In the initial stage, incoming traffic (depicted in green and operating at Layer 7) is directed through the Internet Gateway. Internet Gateway has an associated routing table to divert all the traffic targeting the load balancer subnet (192.168.6.0/24) toward the NGFW private IP. This will make sure the incoming traffic will traverse the NGFW for inspection.

Following the network flow, the traffic proceeds to the OCI Network Firewall or Next-Generation Firewall (NGFW) from the internet gateway. It is noteworthy that the OCI Network Firewall seamlessly receives the traffic without terminating the TLS/SSL connection. The OCI Network Firewall applies decryption profiles to decrypt the TLS traffic, allowing for deep packet inspection. For more information, see Using OCI Network Firewall for SSL decryption.

Once the OCI Network Firewall thoroughly inspects the traffic, it progresses to the OCI Load Balancer, which first terminates the TLS/SSL connection. The attached WAF then performs deep packet inspection on the decrypted traffic to ensure it is clean before forwarding it to the backend servers. The load balancer then executes load balancing routing and initiates a secondary connection to the selected backend server.

For return traffic from backend servers, the backend servers initially respond to the OCI Load Balancer (illustrated in Red and operating at Layer 7). Upon reaching the load balancer, the attached WAF first inspects the returned traffic to ensure it meets security standards. After the WAF inspection, the load balancer routes the traffic back to a private IP where the OCI Network Firewall performs additional security checks on the response. Once inspected by the firewall, the traffic is routed to the internet gateway based on the routing table associated with the NGFW subnet. From IGW, the returned traffic will flow to the original client over the internet.

Objectives

The primary goal of this tutorial is to empower users to fortify their cloud workloads by effectively setting up OCI WAF regional in conjunction with OCI Network Firewall. By incorporating signed X.509 certificates from Let’s Encrypt for the OCI Load balancer front end, users can ensure a secure and validated connection. The tutorial further guides users in implementing OCI Network Firewall best practices for North-South traffic, deploying an application OCI Load Balancer. Notably, this configuration strategically designates the OCI Load Balancer as the sole component using a non-self-signed certificate - Let’s Encrypt certificate, while other elements employing Transport Layer Security (TLS) utilize hassle-free self-signed certificates, that are easier to manage.

Prerequisites

Task 1: Deploy OCI Web Application Firewall Local

The first component we are going to deploy is WAF local.

  1. Log in to the OCI Console and click Web Application Firewall.

    WAF Menu 1

  2. In Policies, click Create WAF Policy and enter the following information. Click Next.

    WAF Menu 1

  3. In Access Control policy, select Enable access control if access control is needed. For more information, see Access Controls for Web Application Firewall Policies.

    WAF Menu 1

  4. In Rate limiting policy, select Enable to configure rate limiting rules if rate limiting is needed. For more information, see Rate Limiting for Web Application Firewall.

    WAF Menu 1

  5. In Protections, select Enable to configure protection rules if configure protection is needed. For more information, see Protections for Web Application Firewall.

    WAF Menu 1

  6. In Select enforcement point, the purpose of this menu is to attach the newly created WAF policies to an existing load balancer. If no load balancer has been created or is available at this time, you can skip this step and attach the policies when creating the load balancer.

    WAF Menu 1

Task 2: Signing Server Certificate with Let’s Encrypt

In this tutorial, we will be utilizing a free public CA service called Let’s Encrypt to sign our server certificate. Therefore, the chain certificate will appear as follows:

1.-End-user Certificate - Issued to: *.example.com; Issued By: Let’s Encrypt R3
2.-Intermediate Certificate 1 - Issued to: Let’s Encrypt R3 (RSA 2048, O = Let's Encrypt, CN = R3); Issued By: Signed by ISRG Root X1:ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
3.-Root certificate - Issued by and to: ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1) , Selfsigned

In PEM format:

-----BEGIN CERTIFICATE-----
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yNDAxMTUxNjAyMTNaFw0yNDA0MTQxNjAyMTJaMBgxFjAUBgNVBAMM
DSouZnd0ZXN0LnNpdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
3NkuEB3r0m/cIWjYBvXEg8QAcib3QjkGO2YwDRu9IwjyxTYTqiWp0F8ZYh2hM1zP
...xxxx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
oIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5Dt....XXXX
-----BEGIN CERTIFICATE-----
oOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUsWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOd....xxx
-----END CERTIFICATE-----

So, before using Let’s Encrypt we need to install certain software that will help us to create our Let’s Encrypt certificate or sign one CSR to be signed. For more information, see Let’s Encrypt.

For signing, we are going to use certbot from Let’s Encrypt. For more information about set up instructions, see Set up Instructions. To install it on Oracle Linux, see Let’s Encrypt - Free Certificates on Oracle Linux (CertBot).

Once you have installed certbot, you can easily create a signed x.509 certificate by executing the following command.

sudo certbot certonly --manual --preferred-challenges=dns --email YOUR EMAIL ADDRESS --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.example.com --key-type rsa

Since we are utilizing a wildcard domain (_.example.com), certbot requires a verification challenge to confirm ownership of _.example.com. We choose DNS challenge by using –preferred-challenges=dns option. During the execution of certbot, we will get a message about the DNS challenge as shown in the following image.

Certbot DNS challenge

Since we are using an OCI DNS service, we just create a txt record in the example.com zone.

OCI DNS TXT challenge

Now, certbot should finish the process, allowing you to obtain the end user certificate, complete with the full CA chain, and its corresponding private key. We will be using this end user certificate (with its complete chain) for the load balancer https listener later on in this tutorial.

Task 3: Configure OCI Load Balancer

After completing the setup for OCI WAF local, our next objective is deploying the OCI Load Balancer in Layer 4 to 7, also known as the OCI Flexible Load Balancer, to serve as the public-facing service with a WAF local attached to it.

  1. Open the OCI Console, click Networking and Load balancer.

    Load Balancer 1

  2. Click Create Load Balancer and enter the following information and click Next.

    • Load balancer name: Enter the name of the load balancer.

    • Choose visibility type: Select Public load balancer.

    • Bandwidth: Select load balancer shape and other configuration details.

    • Choose networking: Select a VCN with at least two public subnets; one for OCI Load Balancer and other for OCI Network Firewall.

      Load Balancer Main menu

    • Show advanced options: Check Use a web application firewall policy to protect against layer 7 attacks and choose the previously created local WAF.

      Load Balancer Main menu/Advanced option

  3. Skip the Choose backends section, since we will be adding backend servers later once the load balancer is created and click Next.

  4. In Configure Listener, enter the following information and click Next.

    Load Balancer Listener menu

    We will configure the incoming requests load balancer listeners, essentially the main entry point for the load balancer where we receive all connections from the outside world. We will need to set up HTTPS for secure HTTP on the default port 443, which inevitably necessitates the use of X.509 certificates (SSL certificates). By using HTTPS we will make sure all the connections will be securely encrypted.

    In a typical scenario where the public load balancer serves as the primary entry point for end users on the internet, it is imperative to upload SSL certificates signed by a reputable public Certificate Authority (CA), such as Digicert, Global Sign, Let’s Encrypt, and others. Furthermore, these certificates exposed to the internet need to be renewed near their expiration dates to ensure that customers do not encounter unnecessary messages such as Your connection is not private!! ERR_CERT_DATE_INVALID.

    That being said, you will need to upload both the public and private details of the Let’s Encrypt certificate you created. Ensure that both components are correctly uploaded to facilitate secure connections. Make sure you upload the fullchain certificate (that includes intermediate and/or root CAs) in the public part.

  5. The Manage logging is an optional configuration and not in scope for this tutorial. Click Submit.

  6. After a while your load balancer will be created. Now, we need to configure the backend servers. Since SSL will be used for the backend servers, we need to first create at least one certificate into the load balancer’s certificate section that will be used to set up the SSL connection toward backend servers. As described above, this certificate bundle can be created manually with third party tools or you can use the OCI Certificates manage service. For this tutorial, we will be using the XCA tool.

    Go to Networking, Load balancers, Load balancer, Load balancer details and Certificates.

  7. In the Certificate section, select Certificate resource as Load Balancer manage certificate and click Add Certificate.

    Load Balancer Certificate source

    Add the public CA root or intermediate CA certificate that you used to sign the backend server’s SSL certificates. As a reminder, we have been utilizing self-signed certificates with any common name and SAN, and without an expiration date. You do not need to install any server certificates here, as the load balancer will solely utilize the root CA for backend server certificate validation.

    Load Balancer Adding certificate

  8. To create the backend servers, select Backend sets and click Create backend set.

    Load Balancer Backend Set 1

  9. In Create backend set, enter the following information.

    • Backend Set Name: Enter the backend set name.
    • Select SSL.
    • Select Load Balancer manage certificate.
    • Add the certificate you created in step 7. If you want to make sure load balancer checks the received SSL certificate signature, click Verify peer certificate.
    • Health checks:
      • Protocol: Select HTTP.
      • Port: Select 443 port.
      • Intervals and Timeout: Keep default interval and timeout (10000 and 3000 msec).
      • For the health response from health check select 200.
      • URL path (URI): Add any resource from URL that exists on the webserver. For example: index.html, mainpage.html and so on.

    Load Balancer Backend Set 1

Task 4: Configure OCI Network Firewall

After OCI Load Balancer is set up, our objective is to configure an OCI Network Firewall to safeguard North-South traffic. The firewall will be positioned between the newly configured load balancer and the internet gateway. To proceed with setting up the OCI Network Firewall, see Use OCI Network Firewall for SSL forward proxy and inbound inspection using Decryption rule and complete the following.

Task 5: Configure OCI Routing

The OCI Network Firewall has been deployed, we need to make sure the North-South traffic traverses it in both directions. The first thing to do is to create a dedicated routing table for the internet gateway associated to the VCN where the OCI Network Firewall is.

  1. Create the routing table into the VCN and add an entry of Target Type as private IP, Destination as CIDR block, introducing the load balancer subnet CIDR block, for this tutorial 192.168.6.0/24 and Target as the private IP assigned to the OCI Network Firewall deployed in Task 6.

    Internet GW Route table

  2. Associate the routing table to internet gateway, click three dots and Associate Route table and then select the routing table.

    Internet GW Route table

  3. Once this routing table is associated with the internet gateway, all traffic directed towards the public load balancer 192.168.6.0/24 will initially be redirected to the private IP 192.168.5.78, where the OCI Network Firewall resides.

    From OCI Network Firewall private IP 192.168.5.78, after packet inspection from OCI Network Firewall, the packet will keep its journey toward OCI Load Balancer. From there, they are directed to their final destination among the selected backend servers, determined by the load balancer’s routing configuration.

    Now, it is essential to ensure that packets returning to internet users follow the same path in reverse order, traversing the OCI Network Firewall for inspection of responses as well. We need to create a routing table for the load balancer public subnet in order to route the responses from backend servers through OCI Network Firewall private IP 192.168.5.78, as shown in the following image.

    load balancer Route table

From the OCI Network Firewall subnet, we need to make sure the responses are routed towards internet gateway, by adding a 0.0.0.0/0 route to the internet gateway.

Network Firewall Route table

After reaching the internet gateway, the packages are routed back to their source. As a test, navigate to https://www.test.com.

Internet GW Route table

Acknowledgments

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.