Web filters that are based on the HTTP proxy server principle are part of the standard toolkit for protecting corporate networks. The use of such filters, often employing the Squid proxy server and similar tools, leads in practice to serious latency problems on the network because the proxy server analyzes and filters the web traffic and thus becomes a bottleneck. These latency problems grow with the number of users.

However, latency is not the only problem: Proxy servers primarily specialize in filtering HTTP connections. This limitation can be solved with the help of a DNS filter, which can monitor all the traffic, regardless of the protocol used to send or receive data. NxFilter [1] is a freeware DNS filter that can compete with commercial products in terms of functionality and performance. In essence, NxFilter is a forwarding DNS server with a filter function. Because the DNS protocol is used, the data traffic does not have to pass through a special filter – thus eliminating latency problems.

The news gets better: Experience reports indicate that the use of NxFilter has a positive effect on the Internet connection of all the network clients. The reason for the performance gain is the local cache that NxFilter uses and manages for DNS lookups. Assuming a corporate network uses the Internet provider's DNS servers, the DNS queries have to be sent to these servers, and the network clients have to wait for a response. If you operate a local DNS filter, the local DNS server serves the queries. Ideally, the cache provides the responses, which results in a significant reduction of network traffic. Figure 1 illustrates the differences between unfiltered and filtered DNS queries.

Figure 1: Comparison of unfiltered (top) and filtered (bottom) DNS traffic.

NxFilter is available under a freeware license. Companies, public institutions, and private persons can use the tool. Basically, the developers grant their users extensive rights. For example, companies can use NxFilter to generate their own cloud filter service for paid users. The design of the NxFilter user interface can also be customized.

Operation and Advantages

WebProxy and other HTTP filters have enjoyed great popularity for many years – probably because they are comparatively simple to use. They are also popular tools among private users – as are the millions of adblockers based on the same principle. Although DNS filtering is basically faster and even simpler than traditional web proxy filtering, DNS filtering was subject to certain limitations in the past (clearly, no user authentication because the DNS protocol does not have an authentication scheme, which was probably one reason for the low acceptance rate). This shortcoming is considered the main obstacle for the use of a DNS filter in corporate environments. NxFilter cleverly solves this problem by supporting four authentication methods:

• IP-based authentication
• Password-based authentication
• LDAP authentication
• Single sign-on with Active Directory (AD)

These methods result in potential approaches for the use of NxFilter in corporate networks, because it can differentiate between users and apply specific filtering policies.

To control the server, two agents, NxLogon and NxClient, provide convenient web-based applications to block UltraSurf, Tor, Skype, Minecraft, and so on. NxLogon is the AD single-sign-on agent for NxFilter, and NxClient is the remote user filter of the environment.

Much can be said for the use of a DNS filtering mechanism on a corporate network, but in practice, it leads to functional limitations. For example, you cannot enforce a secure search or keyword filtering for URLs because it is done at the DNS level. NxFilter also solves this limitation by implementing its own web proxy filtering through its agents NxLogon and NxClient. Both are local web proxies themselves and can do everything that classic web filters offer, including blocking IP hosts. The big result is that the web proxy agents only act as local web proxies for each individual user, which means no problems with network performance.

The challenge for the system administrator is to create a filtering infrastructure that does not require individual employees to change their work environments. If you use an HTTP proxy server, for example, all your browser settings need to be edited. In principle, you can reduce the setup overhead by operating a transparent proxy server, but even then the devil is in the details. With the transparent proxy setup, however, you will have a problem with HTTPS filtering because it violates the browser restriction for man-in-the-middle attacks. Your browser will not send an HTTPS request to your proxy if you try to redirect traffic transparently. Additionally, the transparent proxy server setup is a challenge, even for experienced admins.

However, the solution is simple: If you use a DNS filter, you hardly have to worry about such problems anymore. You only have to set up your current DHCP server configuration to interact with NxFilter as the DNS server for its clients. Then, your users use NxFilter as a DNS server, and the traffic is filtered in line with your specifications.

Imposed filtering for users is also possible. For example, you can block outgoing ports on UDP and TCP except in the case of NxFilter. In this case, NxFilter acts as the only DNS server that network clients can use. This setup is already transparent and does not cause problems with man-in-the-middle attacks on HTTPS.

A web-proxy-based filter can only examine HTTP or HTTPS traffic. With DNS filtering, you can look at almost any protocol, including HTTP, HTTPS, FTP, and so on, as long as they use DNS. Another point in favor of the DNS filter is that NxFilter can detect malware and botnets with DNS packet checking. This operation is possible because NxFilter works at the DNS level. In times when home office solutions are gaining massively in importance, another feature makes NxFilter even more helpful: Remote filtering allows remote filtering agents to run on macOS and Windows clients.

Putting NxFilter into Operation

NxFilter can be installed on any Java-enabled operating system. The basic requirement is a Java 8 installation or higher. When it comes to resources, the filter is not very demanding. According to the developers, 768MB of RAM and 4GB of free disk space are all it takes; moreover, UDP/53, TCP/80, and TCP/  443 ports are required.

Starting NxFilter is unproblematic on popular operating system platforms. The developers provide installation packages on the NxFilter download site [2]. If you want to install the DNS filter on Windows, you can also work with OpenJDK 1.8 [3] for Windows. The Windows installation only requires you to run a setup program. Alternatively, manual installation is also possible by unpacking the archive and executing the <path>/nxfilter/bin/startup.bat installation script.

DEB and RPM packages and Docker images are available for a Linux-based installation. To install a Debian package, first run wget to load the necessary Java packages and install them with dpkg; then, start the package with the integrated system script:

sudo apt-get install openjdk-8-jre
wget http://pub.nxfilter.org/nxfilter-4.3.6.1.deb
sudo dpkg -i nxfilter-4.3.6.1.deb
sudo systemctl enable nxfilter
sudo systemctl start nxfilter

To view the details of the installation process, run:

tail -f /nxfilter/log/nxfilter.log

If you are working with Ubuntu 18, the systemd-resolved UDP/53 service is used; you need to disable it before installing NxFilter:

sudo service systemd-resolved stop
sudo systemctl disable systemd-resolved.service
sudo rm /etc/resolv.conf
sudo echo 'nameserver 0.0.0.0' > /etc/resolv.conf

NxFilter is also available as an RPM package that takes care of the Java installation and all dependencies:

yum install http://deepwoods.net/repo/deepwoods/deepwoods-release-6-2.noarch.rpm

Next, install NxFilter and two packages: NxCloud for cloud-based DNS filtering and NxRelay, a relaying DNS server for NxCloud:

yum install nxfilter
yum install nxcloud
yum install nxrelay

Docker images for NxFilter take just a few easy steps:

docker run -dt --name nxfilter -v nxfilter-conf:/nxfilter/conf -v nxfilter-log:/nxfilter/log -v nxfilter -db:/nxfilter/db -p 53:53/udp -p 80:80 -p 443:443 -p 19002-19004:19002-19004packetworks/nxfilter-base:latest

After the install, access the NxFilter administrator GUI on http://localhost/admin/ . Initial access is granted with the username/password combination admin /admin . For starting and stopping, various helper scripts are available in the /nxfilter/bin directory, including startup.sh to start and shutdown.sh to stop. On Windows, just replace the .sh file extension with .bat. The bin directory has more scripts for setting up as a service.

Getting Started

After logging in, NxFilter comes up with a clearly structured dashboard that lists trend information and the most frequently blocked domains for existing installations. The graphical view of the request and blocked request trends of the last two hours mean you can see where the filter has intervened.

A visual comparison of these and other graphical evaluations provides an immediate impression of the state of DNS. The Config menu lets you make global system settings. In the Setup submenu, you specify the IP address of the filter, the syslog host, the IP address of the network router, and the admin domain. NxFilter also offers bandwidth control. For this purpose, you need a router that has an appropriate control mechanism. In NxFilter you only need to enter the IP addresses and ports of the router.

In the Admin submenu you will want to change the password for the administrator. In the Alert configuration section you can define reporting time intervals and the email address to which information about blocking and warnings are sent. This operation specifically requires an SMTP server configuration.

Because NxFilter acts as a forwarding DNS server, you have to enter at least one public DNS server on the system in DNS | Setup | DNS Setup . For Response Cache Size , make sure the NxFilter server cache is large enough. According to the developers, NxFilter can store up to 1 million DNS responses. If you use a local DNS server, you can define it in DNS | Setup | Local DNS .