Securing DNS and BIND
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.
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{}.
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.
“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.
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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
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.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




6 hours 51 min ago
12 hours 37 min ago
12 hours 55 min ago
14 hours 48 min ago
16 hours 41 min ago
23 hours 35 min ago
23 hours 52 min ago
1 day 1 hour ago
1 day 7 hours ago
1 day 12 hours ago