URL and FQDN firewall filtering or URL/FQDN filtering seems to be a simple and direct method to block or permit the access to resources hosted on Internet or Clouds. The notation “URL/FQDN” is giving the impression that, somehow, the two functions works almost in the same way. Are these two features really work in the same way?

The OCI NFW offers support for defining URL and FQDN lists that can be used in security policies to enforce the desired level of filtering. The scope of the current blog is to clarify the differences between the two, URL filtering and FQDN filtering, thus, we will not use the term URL/FQDN filtering but URL vs FQDN filtering.

During OCI NFW design and implementation projects, I received many questions about URL and FQDN difference both, conceptual and for implementation part. I realized that sometimes, the two features are just treated just like the one working and function in the same way. In the next sections we will explore each function, what it means and how the firewall is using the data to perform the filtering function. At the end we will have the final conclusion if the two features are quite the same or not.

FQDN (Fully Qualified Domain Name)

The Fully Qualified Domain Name represents the specific address of a website or server mapped to an IP address. 

The FQDN structure is the following:

  • the Top Level Domain or TLD
  • the Second-Level Domain or SLD
  • the Subdomain (if exists)
  • the Hostname  

Let’s pick an example to see how the FQDN looks in real life for a web server (it will include all of the above parts): ateam.blog.oci.com where .com is the TLD, oci is the SLD, blog is the subdomain and ateam is the hostname.

The DNS holds configuration for FQDNs together with the associated IP addresses. We will see later that this is a very important part when we will use the FQDN filtering feature.

The FQDN filtering feature is very useful when we are dealing with dynamic hosts that changes the IP address frequently. 

URL (Uniform Resource Locator)

The URL represents the specific address of website or server plus access to different resources hosted on the server.

The URL structure is the following:

  • Scheme – the protocol that the web browser needs to use in order to access the resource
  • Authority – includes the domain and optionally the port used
  • Path to resource – it represents the path to a resource hosted on the web server
  • Parameters (if exists) – specific to each web server
  • Anchor – a specific section on the target resource 

An example will be very helpful to visualize the above URL components: https://www.ateam.blog.oci.com:443/news?id=100#topic_security-features where https is the Scheme, www.ateam.blog.oci.com:443 is the Authority, news is the Path to resource, ?id=100 is the Parameter and #topic_security-features is the Anchor. 

We can observe that ateam.blog.oci.com is the FQDN described above. We can consider the FQDN is just a section from the URL with the URL being more complex.

Having said that, it is clear now that the firewalls will use the FQDNs and URLs filtering in a different way and for different purposes.   

OCI NFW URL Filtering

The URL lists should be created to allow or deny traffic to a group of URLs. We can create up to 1,000 URL lists in a policy. Each list can contain a maximum of 1,000 URLs. The total maximum number of URLs allowed in a policy is 25,000. 

We can apply custom URL filtering to both clear text HTTP and encrypted HTTPS web traffic, enabling policy enforcement across the following scenarios:

  • Clear text HTTP transactions: the URL filtering policy inspects the HTTP host and URL path headers in the client’s request to enforce its rules – there is no need for SSL inspection
  • Encrypted HTTPS transactions: the policy examines the server name indication (SNI) field in the TLS client hello handshake to determine the URL – it needs SSL inspection

For the second use case, in order for the OCI NFW to read the encrypted information we need to create a Decryption rule for SSL Inbound Inspection (Internet to a VCN resource) or SSL Forward Proxy (VCN resource to Internet, On-premises or another OCI server).

URL filtering reads the information at Layer 7, at the application level and then it enforces the security rule defined. 

OCI NFW FQDN Filtering

OCI NFW FQDN filtering is not enabled by default after the firewall is deployed. The FQDN filtering feature relies on defining FQDN Address List. By default the Address List can be configured only with IPv4 and IPv6 types of addresses but not FQDN. The FQDN Address Lists needs first to be enabled by creating a Service Request. 

We have some important information to note in regards to FQDN filtering:

  1. The FQDN must be publicly resolvable, private FQDNs are not supported. FQDN filtering relies on DNS to get the IPv4 or IPv6 destination IP address and enforce the security rule defined. Thus, FQDN filtering is a L3 type of filtering, very different than URL filtering. 
  2. An FQDN should not have more than 32 resolvable IP addresses (the case when the FQDN changes the IP address frequently)

We cleared up the differences between URL vs FQDN filtering and how these two features are handled by the OCI NFW. Implementing one or another will offer a great feature that can secure our network.