Application Access Control: It All Starts with DNS

Most IP communication starts with a DNS query to translate the server name contained in a URL or any application solution into an IP address. Whether it uses TCP or UDP (or any other communication protocol), and whether it uses IP version 4 or 6, the session will be established after the DNS resolution. DNS is at the intent of any application exchange, it can perform value-added actions like securing the communication, filtering predefined destination sites, optimizing the destination or controlling network access to an application.

Improving Application Access Control at network level

Application access control is generally associated with user authentication. Providing credentials to access the application is the default solution and accepted for most applications. Sometimes it can be simplified through single sign-on functionality for enhancing user experience and security with stronger password usage and MFA (multi factor authentication).

But we could also consider enforcing the control for user access to the application infrastructure (e.g. hosting server) at the network level. Why provide the prompt to the credentials form if the user (or its device) is already known as not being authorized to use the application? If we have a way to discriminate between authorized users and non-authorized ones, even at a vast level, we can think about applying filtering at the network level, for which making use of the DNS would bring significant value. DNS occurs prior to the connection establishment, allowing filtering as soon as possible. This can help in supporting a security approach such as Zero Trust where no user or device is trusted even if it is located on the sanctuary side of the organization’s network.

DNS as the ignitor for Application Access Control

During the resolution process, the DNS has the technical ability to provide a different answer to the client. Some consider this untruthful, but this is a real feature named RPZ (Response Policy Zone). RPZ can be used to protect the user from a malicious or unwanted destination (e.g. child abuse site, malware command and control), and is mainly based on reputation filtering and threat intelligence feeds. But the DNS filtering feature can also be utilized to protect the infrastructure or the application from specific network sources or known devices. For example, does a printer really need to access the backup network? Does an IoT device need to access the accounting application? For sure, changing the DNS answer during the resolution process can be just considered as passive security since a session could be established using the IP address directly, but it can reduce the number of devices accessing specific applications or network destinations during normal operation.

Going further with DNS Client Query Filtering

EfficientIP proposes an innovative solution to perform advanced DNS filtering based on the client or device asking for IP address resolution and the destination to reach. Known as DNS Client Query Filtering (CQF), this process is able to apply various DNS policies to specific groups of clients. For example, it can apply “allow list” (whitelist) filtering to untrusted devices like IoT, with communication enabled only towards known and validated destination domains. It can also apply very restrictive filtering based on categories of web sites to standard users in the organization and more open internet access to trusted people who are managing the IT security policies, for example.

In order to continue offering the fastest DNS resolution service, the solution is based on efficient and scalable list management and a very powerful solution for data spread and replication from the administration point towards the DNS engines. Every list inclusion or deletion is performed in real time and immediately applied to all DNS requests from every client.

CQF allows linking of intelligent authentication systems such as captive portals or NAC (Network Access Control) with the distributed DNS filtering engine in order to provide application access control in addition to network access control. CQF also allows you to delegate the control to an external system which, through the open API of the SOLIDserver, will update the lists (client or filtering) based on its own appreciation of the security situation. If a device requires to be in the official organization inventory to get specific access, the inventory solution just needs to keep the appropriate information updated in the list. When an authenticated user has an established session on a device to get access to a specific set of corporate applications, we can use the Identity Manager repository to automatically maintain the list of authorized IP addresses that can perform such DNS requests.

Since everything starts at the DNS level, it’s evident that DNS is the first line of defense and control in your Zero Trust security strategy. And with DNS CQF, the limits are pushed even higher.