Note:

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

Introduction

In a landscape dominated by pervasive digital transformation, ensuring the security of your applications is not just a consideration, it stands as an uncompromising priority. As organizations migrate their workloads to Oracle Cloud Infrastructure (OCI), a robust defense strategy against cyber threats becomes indispensable. OCI provides a comprehensive suite of tools to fortify your applications, and in this tutorial, we will guide you through the process of securing your digital assets using OCI Network Firewall and OCI Web Application Firewall (WAF) edge.

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 edge. 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 Oracle Cloud Infrastructure 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 Edge

OCI WAF edge is a cloud-based Web Application Firewall service. It protects web applications from online threats such as SQL injection and DDoS attacks by filtering malicious traffic at the network edge, enhancing security. 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 OCI WAF edge Layer 7 firewall. The OCI WAF edge performs the termination and response for TLS/SSL connections, subsequently initiating a secondary TLS/SSL connection towards OCI, acting as a back-to-back user agent.

Following the network flow, the traffic proceeds to the OCI internet gateway from OCI WAF edge. Within the internet gateway, a routing table has been configured to redirect traffic towards a private IP address where the OCI Network Firewall is located. 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. The balancer takes on the responsibility of terminating and responding to the TLS/SSL connection. It executes load balancing routing and subsequently initiates a secondary connection towards the selected backend server.

For the 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 balancers, a routing table within the load balancer subnet redirects the traffic back to a private IP where the OCI Network Firewall is located. This enables the OCI Network Firewall to inspect the responses comprehensively. After the OCI Network Firewall completes the inspection, it then progresses back to the internet gateway based on the routing table commands associated with the Next-Generation Firewall (NGFW) subnet.

Subsequently, the returning traffic reaches the OCI WAF edge for the final inspection of responses. Once the OCI WAF edge completes the inspection, it securely delivers the traffic back to the user on the internet.

Objectives

The primary goal of this tutorial is to empower users to fortify their cloud workloads by effectively setting up OCI WAF edge in conjunction with OCI Network Firewall. By incorporating signed X.509 certificates from Let’s Encrypt for the OCI WAF edge 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 WAF edge 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.

Additionally, we will demonstrate the usage of multiple sub-domains in OCI WAF edge and OCI Network Firewall, set up OCI WAF edge to accept wild card domains and use wild card domains in X.509 certificates.

Prerequisites

Task 1: Deploy OCI Web Application Firewall (WAF) Edge

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

  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.

    WAF Create Policy

    In order to create a OCI WAF edge, click Use legacy workflow here if you need to secure your non-OCI web applications. By default, a local WAF policy is created that is useful to be attached to load balancers. The focus of this tutorial is around OCI WAF edge (known as legacy workflow WAF) that is an external element to OCI that will allow to protect OCI and non-OCI origins (public IP servers). Notice that OCI WAF edge is a different product compared with OCI WAF local policy with features such as Bot Management (Captcha challenge, JavaScript Challenge, Human Interaction challenge and so on) and Caching Rules (similar to CDN caching mechanism).

  3. In Create Edge policy, enter the required information.

    Create Edge policy

    At this point, two crucial concepts require clarification.

    • Domains: The WAF edge Domain denotes the internet domain accessible to the public for accessing your web service (for example: www.myexamplewebshop.com). This domain serves as the primary point of connection for all users, including those using mobile devices and laptops. This domain only supports the default http 80 https 443 TCP ports.

      In the Domains, you can add the Primary domain of your website (for example: www.example.com) and keep adding more Additional domains (app1.example.com, customer1.example.com and so on). In case you want to add a wild card domain, you will need to use OCI CLI to add it manually. The fastest way to access OCI CLI is via OCI Developers tools, Cloud Shell, where you will have access to a web browser-based terminal from the OCI Console, with a pre-configured Linux shell with the latest version of the OCI CLI and a number of useful tools. For more information, see OCI Command Line Interface (CLI) and OCI Cloud Shell

      In order to add a wild card domain as additional domain, open OCI Cloud Shell and execute.

      oci waas waas-policy update --additional-domains '["*.yourmaindomain.xxx"]' --waas-policy-id your-WAF-policy-ID

( You can get your policy ID from OCI Web Console->Web application firewall->Policies->Policy details -> Policy Information Tab -> OCID )

      By using wild card domains, your WAF policy will be able to receive http(s) requests including any subdomain, such as \*.example.com. For example: myapp1.example.com, mycustomer2.example.com and so on.

    • WAF origin: we have the WAF edge Origin. The origin(s) refers to the actual web server(s) situated behind the WAF. In WAF terminology, origin signifies the ultimate destination servers being safeguarded. These origins should exclusively communicate with the WAF edge servers responsible for their protection. Ensuring this protection is upheld by the origin servers is imperative, typically achieved in OCI through security lists or Network Security Groups (NSG) that exclusively permit access from designated OCI WAF edge source IPs. For more information, see Securing Your WAF. Typically, you will enter the public IP addresses or FQDNs of your actual webservers or origins here. However, in this tutorial, we will utilize the flexible load balancer’s public IP address. If a load balancer has already been created, you can use its public IP address as the WAF origin. If not, you can initially add any IP address and update it later once you have created the public load balancer.

      You will be able to create different origin groups with multiple origins per group and do load balancing among them (IP_Hash, Round_robin, Sticky_Cookie) , including periodic health checks. For more information, see Origin Management. In addition, under advanced origin options, you will be able to change the default http 80 https 443 TCP ports (only for origins, not for domains).

  4. Click Create Edge Policy. It will take approximately 2 mins and we will see Creating. After that, we will get ACTIVE, so we can continue setting up OCI WAF.

Task 2: Configure DNS for OCI WAF Edge

Now, we have a basic configuration of OCI WAF edge up and running. In order to make sure primary and additional domains (including wild card) are redirected toward OCI WAF edge servers, we need to configure the DNS server hosting the domain with the corresponding CNAME shown in the console.

DNS CNAME

In this tutorial, we are using OCI public DNS server, adding CNAME for the proposed value, as shown in the following image.

OCI DNS configuration

Once configured and published, any attempt to connect to \*.example.com, will be redirected toward OCI WAF edge servers for Layer 7 inspection at www-example-com.o.waas.oci.oraclecloud.net. Once the inspection is done, OCI WAF edge will load balance toward the configured origins with clean traffic after WAF inspection.

Task 3: Enable HTTPS Support for OCI WAF Edge

In this task, we will enable HTTPS support on our OCI WAF edge. Nowadays, nearly all web services require secure HTTP or HTTPS implementation, relying on SSL/TLS connections. It is crucial to have a solid grasp of TLS/SSL concepts, including X.509 management, to effectively enable HTTPS support not only on OCI WAF edge but also on upcoming software components discussed in this tutorial.

  1. Go to the OCI Console and under Edge policy, click Settings.

    Edge Policy Settings

  2. To enable HTTPS, click Enable HTTPS support.

    HTTPS enabling

Here, you need to upload the server certificate with its private key. This certificate will represent the Primary Domain and Aditional Domains, you choose during the creation of the OCI WAF edge, therefore it is crucial that the common name and subject alternative name (SAN) fields of the certificate include these domains. For more information, see What is the SSL Certificate Subject Alternative Name?.

If you are using a self-signed certificate, which is not signed by a public CA, then select Self-Signed Certificate. When you upload a certificate signed by a public CA, it is important to ensure that you upload the entire chain certificate. A chain certificate consists of a list of certificates, typically starting with an end-entity certificate, your server certificate and its public key, followed by one or more CA certificates (intermediates), and optionally concluding with a root CA certificate (self-signed).

Task 4: 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. You can then upload these to the OCI WAF HTTPS menu in Task 3.

Once you upload the just signed certificates in Task 3, you will see a You have 1 unpublished change message. Click Publish All, this can take around 20-30 mins approximately.

At this point, your OCI WAF edge is configured to receive HTTPS traffic. Later on, when OCI Load Balancer is created, you will need to get the load balancer public IP and set it in the OCI WAF edge origin.

WAF Edge Origin Public IP

Task 5: Configure OCI Load Balancer

After completing the setup for OCI WAF edge, 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 origin for OCI WAF edge. It is important to note that the OCI Load Balancer offers the capability to enable and attach an internal or regional OCI WAF, providing WAF features. However, it is worth mentioning that this OCI WAF regional is a distinct product with its own unique set of features. This tutorial specifically focuses on OCI WAF edge implementation.

  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, remember OCI WAF edge only protects public IP origins.
    • 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.

    As described in Architecture, ensure that the load balancer only accepts traffic from OCI WAF edge servers range, see CIDR Ranges.

    You can achieve this by applying firewall rules in the Network Security Group (NSG), click Use network security groups to control traffic and utilize a NSG or by configuring the load balancer subnet security list.

    Load Balancer Main menu

  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.

    In this tutorial, we are using OCI WAF edge as the main entry point for users accessing the web services on the internet. The public load balancers, which are where our services originate, will be positioned behind OCI WAF edge, meaning they will only receive traffic from OCI WAF edge nodes. Because of this setup, there is no need to upload an SSL certificate from a public CA to the load balancer. Instead, we can easily install a self-signed SSL certificate with either no expiration date or a very long one, making management simpler.

    It is important to note that OCI WAF edge will not inspect the details of the SSL certificates received from the load balancer, such as the common name or subject alternative name, nor will it inspect the certificate signature. Nevertheless, it will still establish a secure and encrypted connection between OCI WAF edge and the OCI Load Balancer’s target origin.

    We have created a self-signed certificate using any external tool such as openssl or XCA. Alternatively, you can use Oracle Certificates Managed service which is integrated with OCI Load Balancer. In this tutorial, we have used XCA to create the self-signed certificate and uploaded it manually into OCI Load Balancer, along with its private key. The self-signed certificate uploaded uses any common name or SAN and have a 50 years expiration time. OCI WAF will not inspect that info.

  5. The Manage logging is an optional configuration and not in the 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 6: 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 7: 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, the OCI WAF edge, for final inspection of responses, before being directed towards internet users.

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.