（RHCA）Red Hat Enterprise Linux RHS333: Red Hat Enterprise Security: Network Services

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