2000-02-08
|
Conventions (1...) - bibliographical references (a..z) - information about commands "ls -la" - type everything inside the quotes to the shell This document was written using BIND 8 (specifically 8.2.2-p5). It is possible that some of it's recommendations will not work for any version earlier than 8.2.2-p5. It would also be wise to not use any versions of BIND earlier than 8.2.2-p5. The reasoning behind this statement is that BIND has had security issues that result in total compromise of machines that host it, and Denial of Service attacks that prevent the name server from answering queries. At the time of writing there were seven known vulnerabilities in pre 8.2.2 versions of BIND, and a vulnerability in the way DNS is deployed that affects BIND 8.2.2 when you change your nameserver from one ip address to another. (1) Brief HistoryThe first "DNS" system, JEEVES, was written by Paul Mockapetris. In the early eighties, the Berkeley Internet Name Daemon (BIND) was first created at the University of California at Berkeley in response to a government (DARPA) grant. It was maintained for some time at Berkeley and later became software maintained by DEC when Kevin Dunlap, an employee of DEC, worked at Berkeley. Later, Paul Vixie assumed the role of maintainer, and has recently announced that his role in maintaining BIND will cease with version 8, and that version 9 is currently in development.(2, 3, 4)IntroDNS performs a most critical function on internet protocol based networking infrastructure. It is critical because it tells machines what host addresses answer the names that we humans give to our machines. This implies (for better or worse) that we trust the information that the DNS server gives us. The queries it answers result in hostname to numerical IP address mapping, in situations where a compromise has not occurred. Change rooting and having the nameserver run as a user and a group that has limited or no privileges helps us stay closer to that no-compromise ideal. This makes it easier for us to trust the name server's responses. What scenarios become more likely if we chose not to use features such as change rooting and non-privileged execution? Let us consider one, for a moment.Lets say that Foobar, Inc. has defined in their DNS that their webserver answers on 10.0.0.22, and is named www.foobar.com. As a part of doing business, they tell their customers to visit the portion of their webserver that allows their customers to register their information with Foobar as part of a service that Foobar provides. Being security minded, Foobar's information systems personnel have protected this portion of their website with SSL (or TLS) and have purchased a certificate for their webserver. This allows their customers to (if they know how and if they know they should do this) verify the certificate that identifies Foobar's webserver. The customers can then trust that the information that they send to Foobar's webserver is going to Foobar, Inc. because they trust all the components of the process that allow them to engage in this transaction, including the certificate that identifies the Foobar, Inc.'s website. One of Foobar, Inc's competitors, Scratch Monkeys, Inc., hires an industrial espionage professional, Mallory, to steal Foobar's customer data. Mallory learns that FBI's information systems personnel set up this server and the customer service reps at Foobar, Inc. asked their customers to register on this server. Mallory probes Foobar, Inc.'s network and finds their DNS running on a compromisable host. Mallory attacks the host and is able to edit Foobar, Inc.'s DNS files, pointing their customers to a server (192.168.17.3, note: not the same address as FBI's webserver). Mallory sets up this server so that it looks identical to their system, with the exception that the SSL certificate is not the same. However, when Mallory requested the SSL certificate with a CA (certificate authority) whose root certificate is in Foobar, Inc.'s customer's browsers, he was able to convince the CA that he was a legitimate employee of Foobar, Inc. The customer of FBI neglects to do an out of band verification of the certificate with Foobar, Inc. (how many of us really check the verity of certificates anyway ?), and since the CA root is in Foobar, Inc.'s customer's browsers, there are no warnings about the fact that they are connecting to Mallory's server. Foobar, Inc.'s customer's give up their data to Mallory, who, in turn, passes that data to Scratch Monkey's, Inc. Now Scratch Monkey's, Inc. now has all of FBI's customer's information that have registered at Mallory's server, and so they direct market Foobar, Inc.'s customers and decrease FBI's market share. The most obvious way in which this attack could be mitigated is by assuring that the attacker can't penetrate the host serving up DNS, which Foobar, Inc.'s customers trust will tell them the address that has been defined as correct for the customers to transact with for registration. As we can see from this scenario, the price of doing business across the Internet can be quite exorbitant if one isn't vigilant from a security perspective. What is more disturbing is that there are ad infinitum permutations on this scenario that allow the possibility of compromise, if informations systems personnel are not vigilant. To quote, with slight modification: "Network Security is [what] Y2k [was promised to be] without the deadline." (5) ImplementationIn order to protect your host that will be serving up DNS, the bare minimum that should be done is to update the OS to latest patch revisions, remove all network services and software packages that are not necessary for the host to accomplish its tasks, and administrate the host through encrypted tunnels. It is also unwise to have critical services running on hosts that serve less critical or less trusted services. If you dedicate a single host to a single critical service, you're generally assured that the only thing that will get compromised, if that host is compromised, is that service. This statement, however, does not apply if that service is trusted by other network entities. If you haven't at least locked down the host, then you should stop reading this paper, take care of the minimums to lock it down, and then come back to this paper and finish setting up your DNS server.Now that the host OS is ready, lets discuss what we're going to accomplish. We've decided that the requirements we're going place on the DNS server are that it runs as user named, group named and that it will be change rooted to a directory called /opt/chroot. This means that when BIND starts it will see the directory /opt/chroot as /, instead of seeing / (the root of the directory tree on your machine) as /. This is analogous to you logging into your box, and never needing to leave your home directory. In this case, everything, including the shared object libraries, configuration files, and anything else that you need to execute the commands that help you use your machine, live in your home directory or below it. If an attacker happened upon your machine and knew of an attack that was present in BIND that hadn't been fixed by BIND's maintainers, then the most privileges they would have, upon compromising BIND, are the privileges associated with the named user, and they would be stuck in a directory structure that only allowed them to fool with BIND. Since we will set up your name tables to be editable by a user other than the named user, they wouldn't be able to modify the tables, unless they could find a way to get root, from inside the chrooted jail. Since there won't be any setuid binaries of any kind (owned by any user, including root) at all inside the chrooted jail, the likelihood that they would be able to compromise your machine, or your name tables is slim, if not near impossible. One other thing to note is that you will need to allow the var/run and var/log directories to be writable by the named group. want the named.pid file to be written out. It would be wise to place the BIND directory structure on its own partition so that if named is compromised, the worst that can theoretically happen to the partition is that this partition gets filled. The following are assumed for the configuration:
Let's get started!
OutroSetting up a secondary server will be left as an exercise to the reader. The permissions above are set to allow the BIND DNS server to access only the resources it needs inside the change root. In the event of compromise, the cracker would only be able to abuse what the server had permission to use, which equates to "not much". By adapting the steps enumerated above to your environment, you can run BIND in a change-rooted environment, as a non-root user, and with access control on your DNS tree and the zones contained in the tree. This will at minimum make attacks against your BIND server more difficult, and at maximum, help you thwart known attacks against BIND and maintain security and integrity on your BIND DNS server.BioHolt Sorenson is currently employed at Counterpane Internet Security where he chases and herds datagrams and performs system administration on several Unices. Prior to working at CIS, he was employed by Utah Education Network, where he was responsible for security on the WAN that provided commodity and VBNS Internet traffic to higher education, public education, and state agencies in Utah. Comments on this article are appreciated, send them to hso@nosneros.netBibliography:
|
|||||||||
Articles and General Resources in this Section
Subscribe to the FOCUS-Sun Mail List Secure Installation of BIND Secure Installation of Apache with SSL BIND DNS-HOWTO DNS Resources Directory Ask Mr. DNS |