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.
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.
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
| 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 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- RSS Feeds
- New Products
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




16 min 10 sec ago
37 min 20 sec ago
6 hours 51 min ago
12 hours 30 min ago
18 hours 29 min ago
18 hours 52 min ago
19 hours 2 min ago
19 hours 6 min ago
19 hours 36 min ago
22 hours 28 min ago