Managing DNS Security
| Security considerations are of vital importance to DNS administrators because DNS was not originally designed to be a very secure protocol and a number of successful attacks against BIND have been found over the years. The most important defense is to keep abreast of developments in security circles and act on them promptly. DNS is especially vulnerable to attacks known as poisoning and spoofing. Poisoning refers to placing incorrect data into the DNS database, which then spreads to clients and caches across the world, potentially causing hundreds of thousands of people to unwittingly use the bad data. Although DNS poisoning can occur because of carelessness, it has serious implications when performed deliberately. What if someone set up a clone of a common website, redirected users to it by DNS poisoning, and then asked them for their credit card numbers? Spoofing, the practice of forging network packets and making nameservers believe that they are receiving a valid answer to a query, is one of the ways malicious poisoning can be performed. BIND has often been criticized as being very insecure, and although recent versions are greatly improved in this regard, DNS administrators today must take several precautions to ensure that its use is adequately protected from attacks. Of course, it is important to always run the latest recommended version of BIND. Tip One of your strongest defenses against DNS security risks is to keep abreast of developments in security circles and act on them promptly. The BugTraq mailing list, hosted at http://www.securityfocus.com/, and the SANS Institute at http://www.sans.org/ are good places to start. UNIX Security ConsiderationsThe most important step in securing any UNIX system is to configure the environment BIND runs in to use all the security mechanisms available to it through the operating system to its advantage. In short, this means that you should apply general security measures to your computer. Run named with as few privileges as it needs to function. Do not run named as root. Even if an attacker manages to exploit a security hole in BIND, the effects of the break-in can be minimized if named is running as user nobody rather than as root. Of course, named has to be started as root because it needs to bind to port 53, but it can be instructed to switch to a given user and group with the -u and -g command-line options. Starting named with a command such as named -u nobody -g nogroup is highly recommended. Remember, however, that if you run multiple services as nobody, you increase the risks of a compromise. In such a situation, it is best to create separate accounts for each service and use them for nothing else. Fedora runs named as the user named. You can also use the chroot feature of UNIX to isolate named into its own part of the file system. If correctly configured, such a file system "jail" restricts attackersif they manage to break into a part of the file system that contains little of value. It is important to remember that a chroot jail is not a panacea, and it does not eliminate the need for other defensive measures. Caution Programs that use chroot but do not take other precautions as well have been shown to be insecure. BIND does take such additional precautions. See the chroot-BIND HOWTO at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Chroot-BIND-HOWTO.html. For a chroot environment to work properly, you have to set up a directory that contains everything BIND needs to run. It is recommended that you start with a working configuration of BIND, create a directorysay /usr/local/bindand copy over the files it needs into subdirectories under that one. For instance, you have to copy the binaries, some system libraries, the configuration files, and so on. Consult the BIND documentation for details about exactly which files you need. When your chroot environment is set up, you can start named with the -t /usr/local/bind option (combined with the -u and -g options) to instruct it to chroot to the directory you have set up. You might also want to check your logs and keep track of resource usage. named manages a cache of DNS data that can potentially grow very large; it happily hogs CPU and bandwidth also, making your server unusable. This is something that can be exploited by clever attackers, but you can configure BIND to set resource limits. Several such options in the named.conf file are available, including datasize, which limits the maximum size of the data segment and, therefore, the cache. One downside of this approach is that named might be killed by the kernel if it exceeds these limits, meaning that you have to run it in a loop that restarts it if it dies or run it from /etc/inittab. DNS Security ConsiderationsSeveral configuration options exist for named that can make it more resistant to various potential attacks. The most common ones are briefly described next. For more detailed discussions of the syntax and use of these options, refer to the BIND 9 documentation. Tip The Security Level Configuration Tool (system-config-securitylevel) has been updated to make implementation of the firewall simpler. The new on/off choice (rather than levels as used before) allows you to employ a firewall without requiring any special configuration for your DNS server. Defining Access Control ListsSpecifying network and IP addresses multiple times in a configuration file is tedious and error prone. BIND allows you to define access control lists (ACLs), which are named collections of network and IP addresses. You use these collections to ease the task of assigning permissions. Four predefined ACLs exist:
In addition, you can define your own lists in named.conf, containing as many network and IP addresses as you prefer, using the acl command as shown: ---------- acl trusted { 192.0.2.0/29; // Our own network is OK. localhost; // And so is localhost. !192.0.2.33/29; // But not this range. }; ----------Here you see that you can use an exclamation point (!) to negate members in an ACL. After they are defined, you can use these ACLs in allow-query, allow-transfer, allowrecursion, and similar options, as discussed next. Controlling QueriesAs mentioned before, most nameservers perform recursive resolution for any queries they receive unless specifically configured not to do so. (We suppressed this behavior by using dig +norec.) By repeatedly fetching data from a number of unknown and untrusted nameservers, recursion makes your installation vulnerable to DNS poisoning. (In other words, you get deliberately or inadvertently incorrect lists.) You can avoid this problem by explicitly denying recursion. Recursive queries can be disabled by adding a recursion no statement to the options section of named.conf. It might still be desirable to allow recursive queries from some trusted hosts, however, and this can be accomplished by the use of an allow-recursion statement. This excerpt would configure named to disallow recursion for all but the listed hosts: ---------- options { ... recursion no; allow-recursion { 192.0.2.0/29; localnets; // Trust our local networks. localhost; // And ourselves. }; }; ----------You can choose to be still more restrictive and allow only selected hosts to query your nameserver by using the allow-query statement (with syntax similar to allow-recursion, as described previously). Of course, this solution does not work if your server is authoritative for a zone. In that case, you have to explicitly allow-query { all; } in the configuration section of each zone for which you want to serve authoritative data. Controlling Zone TransfersYou also can use queries to enable only known slave servers to perform zone transfers from your server. Not only do zone transfers consume a lot of resources (they require a named-xfer process to be forked each time) and provide an avenue for denial-of-service attacks, but also there have been remote exploits via buffer overflows in named-xfer that allow attackers to gain root privileges on the compromised system. To prevent this, add a section such as the following to all your zone definitions: ---------- zone "example.com" { ... allow-transfer { 192.0.2.96; // Known slave. localhost; // Often required for testing. }; }; ----------Alert named to Potential Problem HostsDespite all this, it might be necessary to single out a few troublesome hosts for special treatment. The server and blackhole statements in named.conf can be used to tell named about known sources of poisoned information or attack attempts. For instance, if the host 203.122.154.1 is repeatedly trying to attack the server, the following addition to the options section of named.conf causes our server to ignore traffic from that address. Of course, you can specify multiple addresses and networks in the black hole list. ---------- options { ... blackhole { 203.122.154.1; };}; ----------For a known source of bad data, you can do something such as the following to cause your nameserver to stop asking the listed server any questions. This is different from adding a host to the black hole list. A server marked as bogus is never sent queries, but it can still ask us questions. A black-holed host is simply ignored altogether. ---------- server bogus.info.example.com { bogus yes;}; ----------The AUS-CERT advisory AL-1999.004, which discusses denial-of-service attacks against DNS servers, also discusses various ways of restricting access to nameservers and is a highly recommended read. A copy is located at ftp://ftp.auscert.org.au/pub/auscert/_advisory/AL-1999.004.dns_dos. Among other things, it recommends the most restrictive configuration possible and the permanent black-holing of some addresses known to be popular sources of spoofed requests and answers. It is a good idea to add the following ACL to the black hole list of all your servers: ---------- /* These are known fake source addresses. */acl "bogon" { 0.0.0.0/8; # Null address 1.0.0.0/8; # IANA reserved, popular fakes 2.0.0.0/8; 192.0.2.0/24; # Test address 224.0.0.0/3; # Multicast addresses /* RFC 1918 addresses may be fake too. Don't list these if you use them internally. */ 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; ----------Using DNS Security ExtensionsDNS Security Extensions (DNSSEC), a set of security extensions to the DNS protocol, provides data integrity and authentication by using cryptographic digital signatures. It provides for the storage of public keys in the DNS and their use for verifying transactions. DNSSEC still isn't widely deployed, but BIND 9 does support it for interserver transactions (zone transfers, NOTIFY, recursive queries, dynamic updates). It is worth configuring the transaction signature (TSIG) if your slaves also run BIND 9. We briefly discuss using TSIG for authenticated zone transfers here. To begin, we use dnssec-keygen, as we did with rndc, to generate a shared secret key. This key is stored on both the master and slave servers. As before, we extract the Key: data from the .private file. The following command creates a 512-bit host key named TRansfer: ---------- $ dnssec-keygen -a hmac-md5 -b 512 -n host transfer ---------- Next we set up matching key statements in named.conf for both the master and slave servers (similar to the contents of the /etc/rndc.key file that we created earlier). Remember not to transfer the secret key from one machine to the other over an insecure channel. Use ssh, sftp (secure FTP), or something similar. Remember also that the shared secrets shouldn't be stored in world-readable files. The statements, identical on both machines, would look something similar to this: ---------- key transfer { algorithm "hmac-md5"; secret "..."; # Key from .private file }; ----------Finally, we set up a server statement on the master to instruct it to use the key we just created when communicating with the slave, and to enable authenticated zone transfers with the appropriate allow-transfer directives: ---------- server 192.0.2.96 { key { transfer; }; }; ----------The BIND 9 ARM contains more information on TSIG configuration and DNSSEC support in BIND. Using Split DNSBIND is often run on firewallsboth to act as a proxy for resolvers inside the network and to serve authoritative data for some zones. In such situations, many people prefer to avoid exposing more details of their private network configuration via DNS than is unavoidable (although there is some debate about whether this is actually useful). Those accessing your system from outside the firewall should only see information they are explicitly allowed access to, whereas internal hosts are allowed access to other data. This kind of setup is called split DNS. Suppose that you have a set of zones you want to expose to the outside world and another set you want to allow hosts on your network to see. You can accomplish that with a configuration such as the following: ---------- acl private { localhost; 192.168.0.0/24; # Define your internal network suitably. }; view private_zones { match { private; }; recursion yes; # Recursive resolution for internal hosts. zone internal.zone { # Zone statements; }; # More internal zones. }; view public_zones { match { any; } recursion no; zone external.zone { # Zone statements; }; # More external zones. }; ----------Further, you might want to configure internal hosts running named to forward all queries to the firewall and never try to resolve queries themselves. The forward only and forwarders options in named.conf do this. (forwarders specifies a list of IP addresses of the nameservers to forward queries to.) The BIND 9 ARM discusses several details of running BIND in a secure split-DNS configuration.
|
EAN: 2147483647
Pages: 362