Monday, October 20, 2014

You're invited to participate in our DNSSEC Survey

Signing DNS data with DNSSEC enables an organization to authenticate its web addresses and other published DNS information, i.e., to secure its namespace. DNSSEC also protects against DNS cache poisoning attacks when DNSSEC validation is enabled on DNS recursive server resolvers. As such DNSSEC is a critical component of a comprehensive DNS security strategy which should also include use of functional and port access control lists (ACLs), transaction signature keys to sign updates and transfers among servers, detection of DNS anomalies, and possibly domain name filtering or firewalling to restrict communications among malware-infected devices and corresponding command and control centers.

BT Diamond IP is sponsoring a DNSSEC survey to gather input from DNS and network administrators regarding their opinions about the value of DNSSEC, potential obstacles to implementation, and relative priority of deployment. And you are hereby invited to participate! The survey consists of twelve questions plus a thirteenth if you'd like to enter your contact information to be entered for a drawing for a $100 VISA gift card. The survey will remain open through November 3, 2014, after which we will compile the results and publish a free survey report. Make your opinions count, take the survey today!

Friday, October 10, 2014

What Exactly is a DNS Firewall?

When you think of an Internet firewall, you likely think of a gateway device which examines IP packets flowing through it and which selectively blocks or redirects those packets meeting certain criteria. Such criteria may include filtering parameters such as IP addresses or ports such that when an IP packet under inspection matches such parameter settings, the packet is blocked or otherwise handled according to policy settings. A DNS firewall performs similar examination and policy handling functions for DNS queries to prevent unwelcome DNS and subsequent data traffic.

Another common assumption associated with Internet firewalls is that they are deployed on the perimeter of a network with the intention of protecting the network from attacks originating external to the network. DNS firewalls however protect the network against attacks that originate within the network. Why worry about internal attacks if morale is sky high and IP firewalls are seemingly impervious? With the proliferation of smart phones and "bring your own device" (BYOD) initiatives intentionally or unintentionally established, it's quite possible that devices physically leaving the domain of a perfectly firewalled network may elsewhere become infected with malware when operated on less secure networks such at as the coffee house wifi or at home.

Certain forms of malware infiltrate a device as a remote agent or "bot" which, along with several other similarly infected devices, forms a "botnet" where an attacker can command several bots to perform attacks such as distributed denial of service attacks. A bot on an infected device will typically attempt to contact the attacker's command and control (C&C) center to receive its marching orders, and the means of contacting the C&C starts with a DNS lookup. The primary goal of a DNS firewall is to identify such C&C contact attempts, to block such attempts and to identify the infected device.

The leading DNS server reference implementation, BIND from the Internet Systems Consortium (ISC) supports the establishment of DNS firewall policies via its response policy zones (RPZ) feature. RPZ enables a DNS administrator to define policies in standard DNS resource record format to enable filtering of DNS queries. Filtering triggers can be defined based on the queried name (QNAME), resolved IP address (IP address within A or AAAA query response), resolving name server IP (NSIP) as resolved within a response to the A or AAAA query for an NS RRSet, and resolving name server name (NSDNAME) as resolved within an NS RRSet. Thus throughout the resolution process for a particular query, the recursive DNS server can filter at multiple points along the way, then enact the corresponding policy action. Such action can be defined as responding with NXDOMAIN, NODATA, pass through, or inclusion of predefined response data, such as directing the session to a walled garden.

The beauty of this technique is in defining policies as resource records within a zone or zones which enables DNS administrators to create their own policies and/or to subscribe to a provider or providers of malicious domain (filtering) information, which can simply zone transfer such domain information to the corresponding recursive DNS servers. Updates of this zone information of course should be secured via the use of standard BIND ACLs as well as transaction signatures (TSIG) to sign incremental or full zone updates.

BT Diamond IP's IP address management products support configuration of DNS firewall functions via its web user interface for our Sapphire appliances as well as stock ISC BIND servers you may already operate. We also partner with Internet Identity as a provider of bad domain information which can be easily configured with our systems though customers are free to implement their own policies using our systems or use other or additional bad domain providers. Feel free to contact me to learn more.