Securing DNS and BIND
As of this writing, the most current version is 8.2.2, patch level 5. Due to a particularly nasty buffer-overflow problem that can lead to unauthorized root access of vulnerable systems (the “NXT” bug, described in CERT Advisory #CA-99-14) in all older 8.2 releases, it is essential that anyone using BIND be at least at version 8.2.2P5.
Note that for some time after BIND v.8.1 was initially released in May 1997, many users deliberately continued using BIND v.4 due to its stability (and possibly to postpone having to learn the new configuration-file syntax). In fact, the Internet Software Consortium(ISC) continued to support, and even patch, version 4, releasing BIND v.4.9.7 a full year after 8.1's debut.
However, the ISC no longer recommends that anybody continue using BIND v.4, even v.4.9.7. So it bears repeating: everyone who runs BIND on an Internet server should be running the latest release of version 8.x.
We've established that you need the latest version of BIND. But should you use a pre-compiled binary distribution (such as an RPM), or should you compile it from source? For most users, it's perfectly acceptable to use a binary distribution, provided it comes from a trusted source. Virtually all UNIX variants include BIND with their “stock” installations; just be sure to verify that you indeed have the latest version.
The command to do this with Red Hat Package Manager is rpm -q -v bind8 if the package has already been installed, or rpm -q -v -p ./<path & filename of package> if you have a package file, but it hasn't been installed yet. The rpm package name for BIND is usually “bind8” or “bind”.
If you perform this query and learn you have an old (pre-8.2.2p5 version), most package formats support an “upgrade” feature; simply download a more current package version from the Linux distribution web site, and upgrade it using your package manager. To do this with RPM, the command syntax is rpm -U ./<path & filename of package>, assuming you don't need special install options. If the above doesn't work, you can try rpm -U --force ./<path & filename of package>.
If you can't find a suitable binary distribution, compiling it from source is easy: there is no “configure” script to run, and none of BIND v.8x's Makefiles need be edited. Simply follow the brief instructions in the source's INSTALL file (make; make install is all most people need to do).
It's premature to start named (the main process of BIND) just yet. But how you plan to run named will determine how it should be configured. Now is a good point, therefore, to talk about some startup options that can enhance security.
As with all Internet services, it's a good idea to run named in a “padded cell” in which a prospective cracker will be trapped should he/she exploit, for example, some obscure buffer-overflow vulnerability. Three flags make this cell easy to achieve: -u <username>, -g <group name> and -t <directory for named to chroot to>.
The first causes named to run under the specified user name. The second causes named to run under the specified group name, while the third changes (“chroots”) the root of all paths referenced by named. Note that when running named chrooted, this new root is applied even before named.conf is read. Therefore if, for example, you invoke named with named -u named -g wheel -t /var/named, then it will look for named.conf in /var/named/etc rather than in /etc. That is, the default location of named.conf is always /etc, but if named is chrooted to path /other/path, /etc will be translated as /other/path/etc.
The net effect of these three flags (when used properly) is that named's permissions, environment and even file system are severely limited. Should an unauthorized user somehow hijack named, instead of gaining root permissions (prior to BIND v.8, named ran as root) they'll gain the permissions of an unprivileged account. Furthermore, they'll see even less of the server's file system than an ordinary user can: directories connected to directory-tree nodes higher than the chroot-point won't, from named's perspective, even exist.
Running named in a padded cell is paranoid and elite in itself. But that's just the beginning! BIND 8.x's configuration file, named.conf, with its large number of supported parameters, allows you to control named's behavior with a great deal of granularity.
Consider the example named.conf file as shown in Figure 3.
The hypothetical server whose configuration file is represented here is an external DNS server. Since its role is to provide information to the outside world about coolfroods.org's publicly accessible services, it has been configured without recursion. In fact, it has no “.” zone entry (i.e., no pointer to a hints file), so it knows nothing about and cannot even learn about hosts not described in its local zone files. Transfers of its local zone databases are restricted by IP address to a group of trusted slave servers, and logging has been enabled for a variety of event types.
So how do we do these and even more nifty and paranoid things with named.conf?
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Technical Support Rep
- Senior Perl Developer
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- Weechat, Irssi's Little Brother
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?