Note:

• This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
• It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.

Protect your Oracle Cloud Infrastructure Internal Network using a DNS Firewall

Introduction

Having control of what your Virtual Machine (VM) instances are doing is essential so that you can control their behavior. In most cases, Domain Name System (DNS) queries are forgotten and not controlled or monitored, leaving the way open for a compromised machine to connect to command and control (C2) servers and download malicious software, for example. Being able control and block these outbound queries to C2 servers and other types of malicious servers, adds an extra layer of security to your network, and you might avoid your VM and network from being further compromised.

Objectives

• Use Oracle Cloud Infrastructure (OCI) private DNS service to protect your internal OCI network against malicious outbound DNS queries by configuring a DNS firewall and adding logging to have better control and visibility of your instances’ DNS queries.

Prerequisites

• Access to an OCI tenancy.

• Basic understanding of DNS.

• A Virtual Cloud Network (VCN).

  Configuration: By default every VCN is created with its own DNS resolver, and if you pay attention to the configuration on Linux machines, they come configured in the /etc/resolv.conf file with the following content (example for Oracle Linux 9):

  [opc@linu-lab ~]$ cat /etc/resolv.conf
  ...
  nameserver 169.254.169.254
  

  The Automatic Private IP Addressing (APIPA) address 169.254.169.254 is used in OCI network for several services, amongst them the DNS resolver.

• An account on any DNS firewall provider (optional).

Task 1: Locate the DNS Resolver on OCI Console

Make sure you already have a VCN created and click the VCN name. In the Virtual Cloud Network Details page, click DNS Resolver.

Task 2: Configure a Forwarding Endpoint

1. Under Resources, click Endpoints and Create Endpoint.

2. In the Create endpoint page, enter the following information and click Create Endpoint.

   • Name: Enter a name.
   • Subnet: Select the subnet where you want your forwarder endpoint.
   • Endpoint type: Select Forwarding.

   

   It should take a couple of minutes and when finished, you will have your DNS forwarder created. This will allow us to configure a redirect of queries where we want to, in our case to a DNS firewall.

   The DNS resolver follows an order on how the queries of the instances are resolved:

   First, it will check all attached private views, then the resolver rules and last it uses Oracle’s own public Internet resolvers to resolve hostnames. For more information, see Configuration and Resolution.

   In the next step, we want to divert all queries that are not local (do not exist in any private view) and send them to a DNS firewall service, or some other DNS server managed by your company to control the queries.

   You can opt by choosing a free service, like OpenDNS, Quad9, ControlD, and many others, or choose a paid service with much more control and features, like Cisco Umbrella, ControlD, NextDNS, InfoBlox and many more.

   Note: We have no connection with the DNS providers mentioned in Task 3. They are used as an example due to the simplicity, ease of use and configuration. There are many other vendors providing similar services, find the one that best suits your requirements.

Task 3: Create a Resolver Rule

• Use a Free DNS Firewall Service

  Remember that the resolver will evaluate the rules by their order and will stop at the first match. Make sure that if you have other rules for internal domains our rule is last, so we can redirect all other queries to our DNS firewall.

  In this tutorial, we use Quad9 service, this is a free service that is very simple to use with basically no configuration. Other free services like ControlD allow you to configure several categories of queries to be blocked.

  1. Under Resources, click Rules and Manage Rules.

  2. In the Manage rules page, enter the following information.

     • Rule Condition: Select None, this will create a Match all client, meaning that all queries not resolved on the private views or by the previous rules will be diverted to the resolver forwarder and will not be resolved by OCI Internet public resolver.

     • Source Point: Select forwarder endpoint created in Task 2.

     • Destination IP Address: We use Quad9 DNS servers 9.9.9.9.

     

  3. Click Save changes and wait a few minutes for the resolver to be updated.

     

     All your instance queries are sent to the Quad9 DNS Firewall service and blocked if some instance tries to connect to a malicious IP.

  Or

• Use a Paid DNS Firewall Service

  If you need more control, features and logging, then maybe the free service is not the solution for your case. Paid services offer much more control and features than free services and might allow you to detect instances that are making suspicious queries to hostnames that they should not.

  In this tutorial, we will use NextDNS, and there are a few extra steps that are needed to make it work.

  First you need an account, NextDNS offers a free tier with up to 300K queries per month, which should be more than enough to test the service. After you have the account, log in and create a new profile for your VCN.

  1. Click New and enter a name.

     

  2. Click Settings and select the region where the logs will be saved, you can choose between USA, Europe or Switzerland.

  3. Click Security and select how to filter and block malicious IPs, by using AI, by using feeds and many more options.

  4. Click Privacy and add the list of known malicious IPs, trackers, ad servers and more.

  5. You can also create deny and allow lists in the DenyList and AllowList.

     Best part for this service is the logging and analytics capabilities. This allowed us to find a browser extension on laptop doing dozens of thousands of queries to a very weird hostname, which resulted in the removal of the extension.

  6. Now, click Setup and we can see that there are different endpoints, IPv4, IPv6, DoT (DNS over TLS) and DOH (DNS over HTTP).

     

  7. In this tutorial, we will use IPv4, and we have specific IPs for their resolvers, we just need to link our IP address, so that NextDNS knows where the queries are coming from, so that they can log them against your profile.

     For that we need to login into one of the instances with access to the Internet (through NAT) and run the following command to link the IP to the profile.

     [opc@linux-lab ~]$ curl https://link-ip.nextdns.io/d34ff7/fd11c0xxxxx67cab
     158.101.204.149[opc@linux-lab ~]$
     

     Click Show Advanced Options, Linked IP and get the correct link for your profile.

     The script will return the IP of the OCI NAT Gateway, that is used by the OCI DNS resolver to make all queries.

     

     We just need to make one last change in the resolver rule to point to the IPv4 IP of NextDNS resolver.

  8. In the VCN resolver page, click Rules and delete the rule we added previously and create a new one pointing to the IP 45.90.28.43.

     

     After the OCI DNS resolver gets updated with this change, all internal instances making DNS queries on this VCN will use the NextDNS firewall service.

     Create a Deny List

     Let us create a deny List and check if it works. Go to the NextDNS console, select the profile created and click DenyList. Add the domain malicious.site and click Enter.

     

     In the internal instance, try to resolve the IP of this domain.

     [opc@linux-lab ~]$ dig +short A malicious.site
     0.0.0.0
     

     As expected the query is not resolved to any IP and 0.0.0.0 is returned, on top of this the query has been logged.

     

     The Analytics tab starts to show information regarding all the queries made against this profile. From now on, all queries made by internal instances inside your VCN will use the resolver rule to forward queries to the DNS firewall.

Notes:

• All these providers have anycast networks and highly resilient and scalable architectures, that should sustain the failure of servers, but if you want to increase the resilience of your own architecture you should implement a Network Load Balancer in OCI that will be used as the forwarder on the resolver rule and use the several IPs given by the DNS providers as the Network Load Balancer backends. In case one of the IPs of the DNS provider goes down, which would be very unusual, the Network Load Balancer switches traffic to the other IP.

• Remember that the security list of the subnet where the private DNS endpoint forwarder is deployed must allow connections on port User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) port 53, to be able to receive DNS queries.

• This subnet needs to have Internet connectivity through a NAT gateway. Make sure that both security lists and routing tables are properly configured to allow this.

Related Links

• Oracle Cloud Infrastructure DNS

• Private DNS

• Quad9

• NextDNS

Acknowledgments

• Author - Carlos Jorge Santos (OCI Cloud Engineer - Networking Domain Specialist)

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.

---

Title and Copyright Information

Protect your Oracle Cloud Infrastructure Internal Network using a DNS Firewall

G15311-01

September 2024

Copyright ©2024,

Oracle and/or its affiliates.