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 Recursor's, 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 and Webroot.)

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 pre resolve() 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 (Recursor's) 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)

The content of the status database is periodically merged into a CDB database file to enable fast lookups, and the file is given to the Syncer for distribution to the Recursor.

Note that this database is keyed on a customer ID and not IP address!

Customer status API

This is a small Python script which provides access to the customer status database via a simple JSON based API. This can either be used to underpin a service provider’s own customer preferences portal, or it can be used by our own white labelWeb control panel.

{
"DisableTimeEnd": "00:00",
"DisableTimeStart": "00:00",
"WeekDays": "DISABLE_NEVER",
"WhiteList": [
"www.powerdns.com"
],
"BlackList": [
"evil.com",
"wikipedia.org"
],
"Categories": {
"PDNS_CHAT": true,
"PDNS_SECURITY": true,
"PDNS_CHILDSAFE": true
},
"clientid": "cust42"
}

White label customer preferences website

This is a fully optional customer preferences control panel that uses our API to change customer settings. The page is a ‘single page Javascript’ application with no external dependencies. By default it follows a ‘username=IP address’ model, and allows each IP address to change its own settings without authentication. The preferences page basically populates the underlying PostgreSQL database with a user’s preferences which include categories to block, time windows, and blocked / whitelisted domains. It is from this database, that the preferences CDB file is created.

Before a real deployment, this website must be integrated with a sign-on solution and needs to learn the customer ID from that solution.

Syncer

The Syncer rapidly distributes IP-based preferences based on customer preferences found in the database, and a current IP/User identity mapping.

The DNS nameserver and HTTPWeb filter functionalities think in terms of IP addresses, which are not the same as customer identities. Additionally, the customer preferences database can by design not deliver DoS-proof query rates.

For this reason, the syncer does the following continuously:

• Flatten the SQL based customer preference database to a CDB
• Using the current IP/Customer ID mapping data
• Distribute the generated CDB file to the configured servers (DNS servers,Web filters)

Out of the box no user/IP mapping is configured and user identity and IP address are considered identical.

Logging and reporting

The PowerDNS Parental & Malware Control components make copious use of logging for administrators to track and reproduce where a particular decision was taken and why it was taken. These logs can be streamlined into an existing log management infrastructure (e.g. Splunk, Graylog, or Logstash) for reporting, monitoring, alerting, and long-term log storage archival.

Installation

The individual components of the PowerDNS Parental & Malware Control system can be installed on dedicated machines, but the components can all be installed together on a single server.

We make Ansible playbooks and roles available with which to do this. For example, installing all components on a single machine can be accomplished with an invocation of

ansible-playbook -i hosts/hosts playbooks/allinone/allinone.yml

Periodic tasks

The installation process also sets up cron tasks which take care of maintenance. In particular the following jobs are scheduled to run:

• Creation of clientblocks.cdb, which is the database containing manually added per/customer blocked sites.
• Synchronizing of the category databases.

• The Syncer synchronizes the clientblocks CDB from its master.

Operation

As mentioned above, the individual components speak to each other, irrespective of whether they are installed on one or more machines.

The basic premise is a client (for example a Web browser) which has the IP address(es) of one or more dnsdist processes configured as resolvers in its /etc/resolv.conf. The client DNS request is received by dnsdist which hands it over to the Recursor for doing the hard work of looking up the desired query.

The Recursor utilizes the Lua hook scripts to query the CDB database in order to determine whether the desired domain name has been blocked, and if so, why. In the case of blockage, the Recursor returns to dnsdist a configured address of the Web filter, whereupon the Web browser will open a connection to this filter to be informed that the domain has been blocked for a particular reason.

If the Recursor deems that the domain was not blocked, it performs recursion (over the Internet) to resolve the query, whereupon it returns, via dnsdist, this response to the requesting client.

Verifying a blocked site

In order to verify that the Recursor and the Web filter are correctly blocking a particular site, you can use the manual query utility, passing it the domain name and the client’s IP address:

$ /opt/parental/manualquery.lua example.org 192.168.1.207
time: Wed Jun 8 13:49:40 2016
decision: false
categories:
match point: example.org

The decision specifies whether the decision to block is true or false. For example, using the IP address of a different client, i.e. one which has explicitly blocked the site, the output would be

$ /opt/parental/manualquery.lua example.org 192.168.1.130
time: Wed Jun 8 13:53:03 2016
decision: true
categories: -1
match point: example.org

Dynamic services

PowerDNS uses scriptable back-ends with hooks written in the Lua programming language to intercept queries and provide customer-definable responses based on policy decisions.

These hook scripts can be modified and augmented to encompass any desired functionality, such as

• additional logging
• other data sources for blocking