Securing DNS and BIND

Decreasing the vulnerability of your DNS server is largely a matter of staying current and private.
Useful named.conf Parameters: acl{} Sections

Although strictly optional, Access Control Lists (acls) provide a handy means of labeling groups of IP addresses and networks. And since we're paranoid, we definitely want to restrict certain actions and data by IP address.

An acl may be declared anywhere within named.conf, but since this file is parsed from top to bottom, each acl must be declared before its first instance in a parameter. Thus, it makes sense to put acl definitions at the top of named.conf.

The format for these is simple:

acl acl_name { IPaddr1;
IPaddr2; ...etc. };

Note that the IP address list can contain either complete IP addresses in the form x.x.x.x or network addresses in the form x.x.x/24, x.x/16, etc. Now, each time named.conf is read, the parser will substitute all instances of the acl's name (that occur after its definition) with its corresponding IP address list.

Global Options: The options{} Section

The next thing to add is a list of global options. Some of the parameters that are valid for this section can also be used in zone sections; be aware that if a given parameter appears both in options{} and in a zone section, the zone version will supercede the global setting as it applies to that zone. In other words, the zone-section values of such parameters are treated as exceptions to the corresponding global values.

Listing 2 shows some useful parameters that can be used in options{}.

Listing 2. options {} Listing

Logging

In addition to global options, we definitely want to set some logging rules. By default, named doesn't log much more than a few startup messages (such as errors and zones loaded), which are sent to the syslog d<\#230>mon (which in turn writes them to /var/log/messages or some other file). To log security events, zone transfers, etc., you need to add a logging{} section to named.conf.

The logging{} section consists of two parts: one or more channel{} definitions (each of which defines a place to send log information) followed by one or more category{} sections (wherein each event type you wish to track is assigned one or more channels). Channels usually point to either files or the local syslog d<\#230>mon, and categories are actually pre-defined; that is, you choose from a set of pre-defined categories, specifying in each case what is to be done with event messages from that category.

Channel definitions take the following format: channel channel-name {{filename syslog syslog-type|null]; print-time [yes | no]; print-category[yes | no];};

Note that filename by default is put in named's working directory, but a full path may be given (that is assumed to be relative to the chrooted directory, if applicable).

Category specifications are much simpler:

category category-name {channel-list ; };

Note that as with IP address lists, the channel list is semicolon-delimited and must contain channels defined in a prior channel{} statement. See the BIND Operator's Guide (BOG) for the full list of supported categories; suffice it to say that xfer-out, security, load, os, insist, panic and maintenance are usually of interest to the security-conscious DNS administrator.

A Note on Caching-Only Name Servers

“Caching-only” name servers, which are not authoritative for any zones (i.e., are neither master, slave, nor even stub for anything), are inherently simpler and therefore easier to secure than other kinds of DNS servers. Little of what follows will apply when setting up a caching-only server.

zone{} Sections

The last type of named.conf section we'll examine here is the zone{} section. Like options{}, there are many additional parameters besides those described below; see the BOG for more information.

The three parameters most useful in improving zone-by-zone security are:

allow-update { IP/acl-list ; };
allow-query IP/acl-ist ; };
allow-transfer IP/acl-list ; };

allow-update lists hosts that may submit Dynamic DNS updates for the zone; allow-query specifies which hosts may even submit simple DNS queries; and allow-transfer restricts who may download entire zone files. Note that all three of these parameters may be used in either/both zone{} sections and/or the options{} section, with zone-specific settings overriding global settings.

______________________

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions