Unit 4

BIND and DNS Security
Objectives

Upon completion of this unit, you should be able to:
  • DNS Review
  • Configuration and use of TSIG
  • Restrictions of zone transfers and queries
  • "Split namesspaces" and views
  • Configuration of a chroot() name server
  • Logging: categories and channels
Vulnerabilities

  • Use of your DNS information to launch other attacks
  • Spoofing of legitimate host information by a third party
  • Compromise of named daemon
Resolutions

  • Use TSIG keys with access control
  • Restrict zone transfers, recursive queries, or all queries
  • Run BIND in a chroot() jail
  • Configure logging
Types of Name Servers

  • Master and slave name servers provide authoritative information about a zone
    • Must answer iterative queries from servers; may answer recursive queries for clients
    • Slaves get updated database from master through zone transfers
  • Caching-only name servers are not authoritative for any zone
    • Answer recursive queries for clients
Service Profile: BIND

  • Type: System V-launched daemon
  • Packages:bind, bind-utils, bind-chroot
  • Daemons:named
  • Script: named
  • Ports: 53/udp, 53/tcp
  • Configuration:/etc/named.conf, /var/named/*
  • Related: caching-nameserver, openssl
DNS Security

  • DNS is a critical piece of infrastructure
    • Almost every site must run a nameserver
  • Information stored in DNS is required by many network services
    • Spoofed DNS responses can lead to subversion of hostname-based security
    • An attack on DNS may be the first stage of an attack on something else
Attacks on DNS

  • Host enumeration
    • Determine existing hosts, possible targets
  • Cache poisoning (name spoofing)
    • Bogus information fed to server cache through packet interception, client flooding, or control of a legitimate name server
  • Attacking the parent zone
    • Cause NS delegation to be changed to hijack control of your zone
Address Match Lists and acl

  • Address match lists for access control
    • A semicolon-terminated list of items
    • IP address, network prefix, cryptographic key, or named address match list
  • acl names an address match list
    • acl "mylist" { 127/8; 192.168.0/24; };
    • Four defaults acl's
TSIG: Transaction Signatures

  • Authenticates DNS messages by signing them with a shared symmetric key
    • Secure access control mechanism
    • Guarantees message not altered in transit
  • Requires clocks to be synchronized between communicating machines
Installing TSIG Keys

  • Generate a key with dnssec-keygen
  • Use key directive to install and name the key on both machines
    • The name must be the same both places
  • Only named on the two servers should know the key!
    • Configure key in a file with secure permissions and use include
Using TSIG Security

  • Key to authenticate communication with server is declared in keys statement in a server block
  • On server, access is controlled by using the named key in an appropriate directive's address match list
  • Response from server is also signed with TSIG key
Limitations of TSIG

  • Symmetric key management can be difficult and does not scale
  • Only provides next-hop security, not end-to-end security
  • Does not provide data confidentiality
  • Currently, cannot use to secure communication between stub resolver (workstation) and name server
Restricting Zone Transfers

  • Zone transfers should be strictly limited
    • Master server should only allow slaves
    • Slaves should not allow zone transfers
  • allow-transfer
    • Takes an address match list
    • Most secure to restrict by key, not IP
    • Can restrict globally or for a zone
Restricting Recursive Queries

  • You should not allow recursive queries on authoritative name servers
    • Use separate caching name servers for client DNS lookups
    • Helps prevent cache poisoning and other types of name service attacks
  • recursion no;
Single Server Topology

Split Server Topology

Blocking All Queries

  • Useful for internal-only name servers
    • Internal recursive server for client lookups
    • Private DNS server for "split namespace"
  • allow-query
    • Similar to allow-transfer
    • Usually cannot block by key due to lack of client support; block by IP instead
Bogus Servers and Blackholes

  • Some name servers respond with bad information
    • May be misconfigured or deliberately hostile
    • Use bogus in an appropriate server directive to prevent queries to a bad server
  • Systems on the blackhole list will not be responded to or queried
    • If rejected by allow-query, server transmits refusal message
Views

  • Name server normally provides one view of the DNS namespace
  • Different hosts can be shown different views of a zone by the server
    • Most hosts see public DNS information
    • Some hosts see private DNS information; those hosts may be behind a firewall
    • A "split namespace"
Defining Views

  • view directive defines a view
  • match-clients defines which clients see which view
    • Order is important; first match applies
  • Most things can be declared in a view
    • ACLs can be used but not defined in a view
    • If even one view is defined, all zones must be defined inside a view
view Example

version.bind

  • BIND leaks version information through built-in CH TXT resource records
    • version.bind (BIND 8.2 and later)
    • authors.bind (BIND 9.1.0 and later)
  • host -c chaos -t txt version.bind nameserver
  • Best way to block is to use a custom view to suppress all CH records
bind-chroot Package

  • Installs a chroot environment under /var/named/chroot
  • Moves existing config files into the chroot environment, replacing the original files with symlinks
  • Updates /etc/sysconfig/named with a named option:
       ROOTDIR=/var/named/chroot
  • Tips
    • Inspect /etc/sysconfig/named after installing bind-chroot
    • Run ps -ef | grep named after starting named to verify startup options
Monitoring with logging

  • BIND has a very flexible and configurable logging system
  • channel defines where log information should go
    • Can use custom channel or use one of four predefined channels
  • category defines what should be logged
    • Many different categories exist
channel

  • channel defines target for logs
    • Can syslog to any facility or use a file
  • Need to specify a severity as well
    • Similar to syslog severity; default is info
  • Additional options for verbose output
  • Four channels predefined
category

  • category statement associates a category with a channel for logging
  • Fifteen categories to choose from
    • default, general, client, config, dispatch, dnssec, lame-servers, network, notify, queries, resolver, security, update, xfer-in, xfer-out
    • default has a category statement predefined
logging Example

logging {
    channel locallog { syslog local4; severity info; };
    category default { locallog; };
};
Dynamic Update Security

  • Dynamic updates are dangerous
    • Authorized hosts can delete all zone data
  • Best: TSIG and update-policy
    • Windows 2000 uses GSS-TSIG, not yet supported by BIND
  • IP-based security and allow-update
  • Separate zone for dynamic hosts (i.e., *.dyn.example.com)
Setting up DDNS

  • Use dnssec-keygen to create keys
  • Add this key to BIND and DHCP configuration file
  • Make sure DHCP sends name, otherwise BIND will not update DNS
End of Unit 4

  • Questions and Answers
  • Summary
    • TSIG key configuration and use
    • Restriction of zone transfers and queries
    • Split namespaces and view
    • Running named in a chroot() jail
    • Logging with categories and channels