PowerDNS:PowerDNS Parental Malware Control

PowerDNS Parental & Malware Control

PowerDNS safeguards your customers with multi-level access control for safe browsing using a combination of rock-solid PowerDNS servers coupled withWeb filters that use categories to define which domains should be blocked for particular clients. In addition to categories, Parental Control supports time windows, white lists and black lists for fine-tuning access control. Features such as configurable NXDOMAIN redirection and an easy-to-use Web Control panel round up the offering. When used with appropriate CPE equipment with support for EDNS-client, Parental Control can decide based on the client’s IP address.

The PowerDNS Parental Control & Malware detection uses a combination of blindingly fast Constant Database (CDB) files, Response Policy Zones (RPZ) and a PostgreSQL database table from which it bases the policy to apply for DNS queries. We offer this to provide subscribers with the peace of mind that all devices on their network (including those they don’t understand or know about) are under control.

For sensitive environments queries to search engines are redirected to safe search.

Thanks to the use of DNS resolution only, unfiltered domain names do not restrict devices in any way: normal DNS resolution proceeds, and applications are blissfully unaware of content protection, contrary to the use of, say, HTTP proxies, which do influence clients’ requirements.

How it works

In very simple terms, a client application issues a DNS query for a particular domain. This query is intercepted by PowerDNS Parental and verified against its datasets. If it passes all controls, the DNS query is resolved and responses are returned to the clients. If access control fails, a unique configurable IP address of a Web filter is returned to the client. The client’s Web browser then connects to the Web filter which does more checks on the URL. If the filter grants access, the Web request is proxied to the origin, otherwise a page which explains why the query was blocked is displayed.

The traditional “one world” view of a recursive name server no longer applies, and neither do the “inside/outside” views as used by other DNS name server implementations; PowerDNS Parental eliminates the need for complex configuration and huge amounts of RAM by providing dynamic lookups using configurable and customizable modules.

Why use it?

Whether in a huge corporate environment or in a family household, filtering of DNS queries should be done for a number of reasons:

• Per-user filtering is a source of tension. (“Why is she allowed, and I’m not?”)
• Per-device filtering is tedious and challenging to configure and verify
• Prevents malware infections
• Detects and warns users
• Allows for long-term storage & logging of queries
• Lawful interception and data retention may be mandatory

In particular, when using the PowerDNS Parental security application, subscribers need not worry about their Internet security. In view of the fact that SOHO and SME are slowly becoming maintainer-less and thus do not have an “administrator” on site, the added level of protection for all devices (also future devices!) becomes important.

The fact that users associate being safe from infections with the service offered by service providers, makes the PowerDNS Parental & Malware Control application useful to have.

System components

The PowerDNS Parental Control & Malware solution consists of the following components which are typically installed on separate machines but which can very easily be run on a single server. This section details the components.

dnsdist

PowerDNS Parental Control fronts its actual DNS servers with dnsdist, which is a highly DNS-, DoS- and abuse-aware loadbalancer. Its goal is to route traffic to the best server, delivering top performance to legitimate users while shunting or blocking abusive traffic. dnsdist is dynamic, in the sense that its configuration can be changed at runtime, and that its statistics can be queried from a console-like interface.

PowerDNS uses dnsdist as a front-end to a Recursor or a cluster of Recursors, so it is the address(es) of the dnsdist instances which you add to the clients’ ‘resolv.conf’ file.

Recursor

The PowerDNS Recursor is a high-end, high-performance resolving name server which powers the DNS resolution of at least a hundred million subscribers. Utilizing multiple processors and supporting the same powerful scripting ability of the Authoritative Server, the Recursor delivers top performance while retaining the flexibility modern DNS deployments require.

PowerDNS Parental Control uses a stock PowerDNS Recursor from the 4.x.x release strain.

Plugins

Plugins or hooks written in the Lua programming language are provided for determining IP address filtering preferences as well as to determine domain name status. They are used by both the HTTPWeb filter and the DNS Recursor. Domain name status basically associates categories to a domain name; these categories are then used by PowerDNS Parental for deciding what to do with the query based on your policy. (Domain status modules are currently available from Zvelo andWebroot.)

Consider the following examples of hook scripts which are located in /opt/parental/:

• decision.lua is used by recursor.lua (and nginx.lua) to determine blockage based on the underlying CDB database files.
• recursor.lua contains the Recursor’s preresolve() function which uses decision to determine whether a site is flagged or not. Interesting to administrators will be that this hook is able to create DNS TXT records which contain the reason for blocking a domain. This can, of course, be disabled if clients should not be able to see why a particular query was blocked.

;; ANSWER SECTION:
www.example.org. 120 IN TXT \
"domain marked via .example.org. in categories (10056, 10092)"

• nginx.lua is used by nginx in theWeb filter. It handles each and every URL given to nginx and passes them through decision.lua to determine whether or not a user may visit the URL or whether it should return a 451 Blocked error page.

Local databases for IP and Domain status

The IP address-based preferences database is a CDB file, which is typically “compiled” at a central location and distributed to satellite name servers (Recursors) and to the Web filter. CDB files can be queried at millions of queries/second and have the additional bonus that they can safely be replaced incrementally at runtime (rsync). With default settings, the CDB files scale to around 9.5 million different customer IDs.

The per-domain status databases are in proprietary formats but are also distributed using rsync.

Web filter

The Web filter server only receives requests that may have to be blocked based on user preferences when the Recursor responds accordingly. It then consults the plugins and serves up a proper “Sorry!” page for HTTP requests that should be blocked.

We use nginx, the industry standard for very high level HTTP proxy service. The Web filter server uses the exact same Lua modules used by PowerDNS Recursor to determine customer/IP address status and domain status, and decides on whether it should forward (i.e. proxy) or block the HTTP request.

Assume a user wants to access the URL example.com/pics. When the Recursor gets a query for example.com it determines that this domain has categories associated with it and returns the address of the Web filter. The user’s Web browser now connects to the Web filter and requests the same URL. TheWeb filter can differentiate between /pics on example.com (nudity, say), and /files on example.com (harmless, say) and either deny (user may not see category “nudity”) or allow the connection.

To determine which connection an HTTPS session is with, we employ sniproxy which again consults the same Lua scripts to determine IP and domain status.

Blocking of HTTPS/TLS content

When a user attempts to visit an HTTPS website, the browser performs a DNS lookup as normal; the DNS name server can’t see whether the DNS query is for a particular type of connection. This means that resolution proceeds as normal. If, however, the user account is set up to block the specified domain name, we return an IP(v6) address for one of the configured transparent proxy servers.

The Web browser will then attempt to setup a TLS protected connection to our HTTP Web filter server. On connecting, we allow the browser to tell us which website it would try to connect with, and it will tell us the the certificate it expects to see used for the negotiation of a session key for encryption. This process is called SNI, or Server Name Indication [1].

Based on the indicated server name, the PowerDNS filtering decision logic determines if the connection should be blocked or not. In case the requested site is supposed to be blocked, there are three options:

1. Immediately drop the TCP/IP connection, leading to a non-scary error for the user and a non-working site
2. Use a self-signed certificate to serve up a page that would tell the user the site is blocked, but only if he ignores the dire warnings about invalid certificates
3. Create a TLS error indication that may be more informative for the user, but still is not very explanatory

Regarding option ‘2’, the subscriber web-browser explicitly wants to verify that it is connecting to the right site. The encryption used for this purpose is solid, and can not be faked. This means that under normal circumstances, it is not possible to inject a ‘Sorry, your visit was blocked’ page for TLS visits without generating dire warnings about traffic being intercepted.

Regarding option ‘3’, we are currently establishing what popular browsers report for various TLS-level errors, and if there is the possibility for browsers to implement a more useful reporting facility to tell users a site is blocked.

As it stands, we recommend and currently #implement option 1.

“Man in the middle” considerations

To enable superior reporting of blocked connections over HTTPS, some corporate/office environments deploy public key certificates of the blocking infrastructure to all desktops. While this can work in highly controlled environments, such “MiTM” certificates lead to large security risks in case of a key compromise. We do not recommend this approach for general internet service providers.

Customer status database

The customer status database is a straightforward PostgreSQL database which for each customer knows about:

• Malware filtering yes/no
• User-visible categories to be filtered
• Configuration of time windows
• Individual whitelists
• Individual blacklists
• (Safe search yes/no)
• (Snooze button status)