PowerDNS:PowerDNS Parental Malware Control: Difference between revisions

From Open-Xchange
No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
= PowerDNS Parental & Malware Control =
= OX 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.
OX PowerDNS safeguards your customers with multi-level access control for safe browsing using a combination of rock-solid OX 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.


[[Image:Malware_1.png]]
[[Image:Malware_1.png]]


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.
The OX 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''.
For sensitive environments queries to search engines are redirected to ''safe search''.
Line 14: Line 14:
== How it works ==
== 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.
In very simple terms, a client application issues a DNS query for a particular domain. This query is intercepted by OX 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.


[[Image:Malware_2.png]]
[[Image:Malware_2.png]]


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.
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; OX 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? ==
== Why use it? ==
Line 31: Line 31:
* Lawful interception and data retention may be mandatory
* 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.
In particular, when using the OX 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.
The fact that users associate being safe from infections with the service offered by service providers, makes the OX PowerDNS Parental & Malware Control application useful to have.


== System components ==
== Operation ==


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.
As mentioned above, the individual components speak to each other, irrespective of whether they are installed on one or more machines.


[[Image:Malware_3.png]]
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.


=== dnsdist ===
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.
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.
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.


=== Recursor ===
=== Verifying a blocked site ===


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.
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:


PowerDNS Parental Control uses a stock PowerDNS Recursor from the 4.x.x release strain.
$ /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


=== Plugins ===
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


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
$ /opt/parental/manualquery.lua example.org 192.168.1.130
modules are currently available from Zvelo andWebroot.)
time: Wed Jun 8 13:53:03 2016
decision: true
categories: -1
match point: example.org


Consider the following examples of hook scripts which are located in /opt/parental/:
== Dynamic services ==
* 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 ===
OX 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.


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.
These hook scripts can be modified and augmented to encompass any desired functionality, such as
 
* additional logging
The per-domain status databases are in proprietary formats but are also distributed using rsync.
* other data sources for blocking
 
=== 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:
# Immediately drop the TCP/IP connection, leading to a non-scary error for the user and a non-working site
# 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
# 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)
 
[[Image:Malware_4.png]]
 
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 Recursors.
 
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"
}

Latest revision as of 08:58, 2 December 2016

OX PowerDNS Parental & Malware Control

OX PowerDNS safeguards your customers with multi-level access control for safe browsing using a combination of rock-solid OX 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.

Malware 1.png

The OX 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 OX 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.

Malware 2.png

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; OX 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 OX 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 OX PowerDNS Parental & Malware Control application useful to have.

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

OX 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
Retrieved from "https://wiki.open-xchange.com/wiki/index.php?title=PowerDNS:PowerDNS_Parental_Malware_Control&oldid=22757"