DNS Filtering and Authentication Policies

Let us start with the fundamentals, assuming you have never configured a firewall in your life. The internet works because of a system called the Domain Name System (DNS). Think of DNS as the phonebook of the internet. When you type a website address like 'www.example.com' into your browser, your computer does not know where that website lives. It asks a DNS server: 'What is the IP address for www.example.com?' The DNS server replies with a number, such as 192.0.2.1. Your computer then uses that number to connect to the website. Without DNS, you would have to memorise long strings of numbers for every site you visit.

DNS filtering is a security feature that sits in the middle of this conversation. When your computer asks the DNS server for an address, the FortiGate firewall (or a dedicated DNS filter service) checks the requested domain name against a database of known malicious or categorised sites. This database is maintained by FortiGuard, Fortinet's threat intelligence service. If the domain is on a blocklist — for example, a known phishing site that tries to steal your passwords, or a domain that distributes ransomware — the firewall intercepts the DNS request and returns a block page instead of the real IP address. Your browser never connects to the dangerous server.

DNS filtering can also block entire categories of websites. For example, an organisation might block all gambling, adult content, or social media sites during work hours. The filtering decision is based on the domain name alone, which makes it very fast and efficient. It works even if the website's IP address changes, because the domain name stays the same. This is a key advantage over traditional IP-based blocking.

Now, let us move to authentication policies. A network without authentication is like a building with no locks on the doors. Anyone who can physically reach the network cable or connect to the Wi-Fi can access everything. Authentication policies solve this by requiring a user or device to prove its identity before it can use the network. The FortiGate firewall supports several authentication methods, including local password databases, LDAP (Lightweight Directory Access Protocol, which connects to a central user directory like Microsoft Entra ID), RADIUS (Remote Authentication Dial-In User Service, often used for Wi-Fi and VPN access), and single sign-on (SSO) systems.

When a user tries to access a resource, the firewall checks if the user is already authenticated. If not, it presents a captive portal — a login page that the user must complete with credentials. Once authenticated, the firewall creates a 'user identity' entry that links the user's IP address to their username and group memberships. This identity is then used by firewall policies to permit or deny traffic based on who the user is, not just where they are connecting from. For example, a policy might allow the finance team's members to reach the accounting server, but block everyone else.

Device identity works similarly but focuses on the device itself rather than the person. The firewall can check a device's operating system, hostname, MAC address, or a certificate installed on the device. This is especially important for allowing only company-issued laptops onto the corporate network while blocking personal devices. Fortinet calls this feature 'device identification' and it can be integrated with FortiClient, an endpoint security agent installed on user machines.

Why do these two technologies exist together? Because they solve different problems. DNS filtering is proactive: it prevents users from even attempting to reach dangerous destinations. Authentication policies are reactive to access: they control what an authenticated user is allowed to do once they are inside the network. A typical FortiGate security policy will combine both: first, DNS filtering blocks the request if the domain is malicious, and second, if the domain is safe, the policy checks the user's authentication status and applies the appropriate rules.

An IT professional working for a mid-sized company of 500 employees is tasked with implementing a security solution on a FortiGate firewall. The company has recently experienced a ransomware attack that started when an employee clicked a link in a phishing email that led to a malicious download site. The IT professional's goal is to prevent this from happening again and to restrict access to sensitive financial systems.

Step one: the IT professional enables DNS filtering on the FortiGate. They log into the firewall's web interface and navigate to the DNS filter profile settings. They select the FortiGuard category-based filter and choose to block several categories: 'Malicious Websites', 'Phishing', 'Spam URLs', and 'Recently Registered Domains'. The last category is particularly important because attackers often register fresh domains that have no reputation yet. By blocking domains registered in the last 30 days, the IT professional stops many emerging threats.

Step two: they configure the DNS filter to redirect blocked requests to a custom block page that tells the user the site is categorised as malicious. They also enable logging so that every blocked attempt is recorded. The logs allow the IT professional to see which users are clicking suspicious links and to provide additional training if needed.

Step three: the IT professional turns to authentication policies. The company uses Microsoft Entra ID for user accounts. The IT professional configures the FortiGate to authenticate users against Microsoft Entra ID using LDAP. They create a user group called 'Finance_Users' and a separate group called 'HR_Users'. They then create firewall policies that specifically allow only members of the Finance_Users group to access the IP address of the accounting server. Any user not in that group gets a 'deny' message.

Step four: they enable device identification by installing FortiClient on every company laptop. FortiClient sends a fingerprint of the device (including its hostname, OS version, and installed certificates) to the FortiGate. The IT professional creates a policy that says: only devices with a valid Fortinet certificate and a hostname matching the company naming convention can access the internal file server. Any personal device or unrecognised laptop is automatically quarantined to a guest network with internet-only access.

Step five: the IT professional tests the setup. They connect a test laptop that is not enrolled with FortiClient and try to access the file server. The firewall blocks the connection because the device identity does not match. They then connect a company laptop, log in with a finance user's credentials, and attempt to browse to a known malicious test domain. The DNS filter intercepts the request and shows the block page. The test laptop is also unable to access the accounting server because the user is not in the Finance_Users group. The IT professional has now successfully implemented a layered defence that blocks malicious domains at the DNS level and enforces user and device identity checks at the policy level.