Attacking and Securing DNS Servers Jay Beale Lead Developer, Bastille Linux President, JJB Security Consulting (Copyright 2002 - All Rights Reserved)

Attacking and Securing DNS Servers

Jay BealeLead Developer, Bastille Linux

President, JJB Security Consulting

(Copyright 2002 - All Rights Reserved)

Attacking and Securing DNS Servers

Simulating attacks and information probes Implementing security "best practices" for DNS

configuration" Split Horizon Advanced Unix Methods: Chroot the Daemon,

Run as Non-superuser Gung-Ho: djbdns on OpenBSD

What Does DNS Do?

DNS provides a mapping between machine names and IP addresses:

www.mydomain.org -> 192.168.1.15Originally, the Internet just had a large /etc/hosts

file that just listed machine names and IP addresses.

This was replaced by a distributed, fault-tolerant system called "Domain Name Service."

What Does DNS Do?

How Does DNS Work?

Most name servers have some data they're authoritative for, like their domain.

ns1.umd.edu is responsible for:

.umd.edu and 1.2.* Name servers answer queries they have

information for and often hunt for the rest in a recursive query.

Root Servers are the starting point in a recursive query.

Enough Review?

Let's get all the DNS Theory questions out of the way now, so we can get onto the good stuff!

Interesting Part of the Talk

Take the role of an attacker!

DNS gives out a whole lot of useful information

Most syadmins don't think from the attacker's point of view!

Bad habits from when the Internet was a more exclusive neighborhood.

Dual Platform Talk

This talk discusses both Windows and Unix.

We'll have the chance to compare the advantages and disadvantages posed by each platform, beyond the obvious.



DNS is a public database that contains a huge amount of information that an attacker finds useful.

Further:

Most system administrators don't think about their site from an attacker's point of view.

There are many bad habits from when the Internet was a more exclusive neighborhood.



DNS servers have traditionally made good cracking targets!

They're publically available, easy to find, and extremely rewarding to control!

Additionally, on Unix: BIND has had a number of security vulnerabilities BIND runs as root by default

Why All This Introduction?

To secure something, you have to know how it will be attacked

To effectively create an attack, you need to truky understand the target.

"Profiling the Target"# dig @10.0.0.1 jjbsec.com NS

; <<>> DiG 9.1.2 <<>> @10.0.0.1 jjbsec.com NS;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36869;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:;jjbsec.com. IN NS

;; ANSWER SECTION:jjbsec.com. 86374 IN NS ns2.jjbsec.com.jjbsec.com. 86374 IN NS ns.bastille-linux.org.jjbsec.com. 86374 IN NS ns.jjbsec.com.

;; ADDITIONAL SECTION:ns.jjbsec.com. 86374 IN A 192.168.2.2ns2.jjbsec.com. 86374 IN A 192.168.2.3ns.bastille-linux.org. 86374 IN A 10.0.0.3

;; Query time: 1 msec;; SERVER: 10.0.0.1#53(10.0.0.1);; WHEN: Mon Jan 14 15:12:06 2002;; MSG SIZE rcvd: 129Address: 10.0.0.1

Non-authoritative answer:dumb.target.jay nameserver = dumb.target.jaydumb.target.jay nameserver = ns2.dumb.target.jay

Authoritative answers can be found from:dumb.target.jay internet address = 192.168.1.85

Zone Transfer of their Zone 1/2[# dig @192.168.2.2 jjbsec.com AXFR<insert text figure 2>

; <<>> DiG 9.1.2 <<>> @192.168.2.2 jjbsec.com AXFR;; global options: printcmdjjbsec.com. 86400 IN SOA ns.jjbsec.com. hostmaster.jjbsec.com. 2002040201 3600 900 604800 3600jjbsec.com. 86400 IN NS ns.jjbsec.com.jjbsec.com. 86400 IN NS ns2.jjbsec.com.jjbsec.com. 86400 IN NS ns.bastille-linux.org.jjbsec.com. 86400 IN MX 10 mail.jjbsec.com.jjbsec.com. 86400 IN MX 20 ftp.jjbsec.com.jjbsec.com. 86400 IN MX 30 mail.bastille-linux.org.admin-fw.jjbsec.com. 86400 IN A 192.168.3.11allen.jjbsec.com. 86400 IN A 192.168.3.6backup.jjbsec.com. 86400 IN A 192.168.3.17bakos.jjbsec.com. 86400 IN A 192.168.3.3beale.jjbsec.com. 86400 IN A 192.168.3.4billing.jjbsec.com. 604800 IN NS ns.billing.jjbsec.com.ns.billing.jjbsec.com.86400 IN A 192.168.128.2db.jjbsec.com. 86400 IN A 192.168.5.2db-dev.jjbsec.com. 86400 IN A 192.168.4.3db-storage.jjbsec.com.86400 IN A 192.168.5.3db-storage-dev.jjbsec.com. 86400 IN A 192.168.4.4db1.jjbsec.com. 86400 IN A 192.168.5.4db2.jjbsec.com. 86400 IN A 192.168.5.5db3.jjbsec.com. 86400 IN A 192.168.5.6friedman.jjbsec.com. 86400 IN A 192.168.3.13

Zone Transfer of their Zone 2/2frontpage.jjbsec.com. 86400 IN A 192.168.3.15ftp.jjbsec.com. 86400 IN A 192.168.2.4fw1-dev.jjbsec.com. 86400 IN A 192.168.6.4imap.jjbsec.com.86400 IN CNAME mail.jjbsec.com.khouri.jjbsec.com. 86400 IN A 192.168.3.19mail.jjbsec.com.86400 IN A 192.168.2.7mdk-dev.jjbsec.com. 86400 IN A 192.168.6.3ns.jjbsec.com. 86400 IN A 192.168.2.2ns2.jjbsec.com. 86400 IN A 192.168.2.3ns.bastille-linux.org. 86400 IN A 10.0.0.3nt4.jjbsec.com. 86400 IN A 192.168.3.18old-www.jjbsec.com. 86400 IN A 192.168.2.6pop.jjbsec.com. 86400 IN CNAME mail.jjbsec.com.rh-dev.jjbsec.com. 86400 IN A 192.168.6.2roesch.jjbsec.com. 86400 IN A 192.168.3.10skoudis.jjbsec.com. 86400 IN A 192.168.3.7snmp.jjbsec.com.86400 IN A 192.168.3.12snort-eval.jjbsec.com.86400 IN A 192.168.3.16spangler.jjbsec.com. 86400 IN A 192.168.3.5spitzner.jjbsec.com. 86400 IN A 192.168.3.8stearns.jjbsec.com. 86400 IN A 192.168.3.2sundoc.jjbsec.com. 86400 IN A 192.168.3.9targets.jjbsec.com. 604800 IN NS ns.jjbsec.com.training.jjbsec.com. 604800 IN NS ns.jjbsec.com.www.jjbsec.com. 86400 IN A 192.168.2.8www-dev.jjbsec.com. 86400 IN A 192.168.4.2jjbsec.com. 86400 IN SOA ns.jjbsec.com. hostmaster.jjbsec.com. 2002040201 3600 900 604800 3600;; Query time: 63 msec;; SERVER: 192.168.2.2#53(192.168.1.7);; WHEN: Mon Jan 14 15:24:11 2002;; XFR size: 50 records

Reactions?

Two commands and we have a full dump of their zone data!

Let's take the next few minutes and draw as manyconclusions as possible about their network.

Reactions? 2/2

Think about:

1) services offered on each machine2) purpose of each machine3) operating system of each machine4) network layout

Don't be afraid to guess.

Think about it...

Let's really try to draw some conclusions.

When you get back to your own site, try this on your own. Try to determine what a clever attacker would learn about your network from DNS and decide what level of compromise you can agree to.

Defense to Zone Transfers

Should I really let everyone have this much information?

Windows:

Restrict zone transfers to either the NS's for this zone or for a set of known IP's.

Unix- named.conf:Directives:

allow-transfer{}

allow-recursion{}

allow-query { };

Can the attacker still learn the same?

dig @nameserver D.C.B.A.in-addr.arpa PTR

does a reverse lookup on the address A.B.C.D.

We can script this to check every IP address in the class A/B/... network that belongs to this organization!

Defense

Split Brain DNS!

Two set of DNS servers:

Internal

External

Internal DNS

This DNS server has all data about your zone, including a real reverse for every single IP address in the zone.

It is also only reachable by machines inside your site!

External DNS

This DNS server has only data about the systems at your site that need to be addressable by name from outside the site.

These servers are only reachable by the systems outside your site, and by the internal DNS servers.

Forwarding?

The internal DNS servers will forward all requests for names/IPs/zones outside your organization to the external DNS servers.

This significantly reduces the risk to your internal DNS servers, which are more critical in one crucial way...

Cache Poisoning/DNS Spoofing

Whoever takes over your internal DNS servers has an extreme ability to re-route your traffic. They can:

1) take over the entire name<->IP address mapping

2) redirect the mail (MX records)

3) have a much better attack vector for other DNS servers!

Cache Poisoning?

By taking over an authoritative nameserver, an attacker obtains the ability to put data into our nameserver's cache. He accomplish this, if he can get us to ask his nameserver for information!

Remember that DNS is a distributed database.

The steps we're taking here attempt to minimize this possibility.

Attack Vector?

Most of the exploits against any DNS server recently requires that the attacker get the victim DNS server to issue a query against his attacking DNS server.

Defense to this Attack Vector

We can protect against this attack method by telling most of our DNS servers not to do recursion.

Recursive query to a DNS server means that it does multiple queries on your behalf, walking the DNS tree.

Make Sure to Understand Recursion

Recursive query to a DNS server means that it does multiple queries on your behalf, walking the DNS tree.

Normal queries to a DNS server only involve that DNS server either giving you an answer or trying to give you a referral to another DNS server that has more authority.

Deactivating Recursion

Windows DNS servers allow you to deactivate recursion only globally.

Set the registry value NoRecursion to “”true”

Unix DNS servers have much more granular control.

Deactivating Recursion

Windows DNS servers allow you to deactivate recursion only globally.

Set the registry value NoRecursion to “”true”

Unix DNS servers have much more granular control.

named.conf.restricted_axfr 1/3

acl internal { 192.168.1.0/24 ; };

acl secondaries { 192.168.1.3 ; 192.168.2.3 ; };

options {

directory "/var/named/";listen-on {192.168.1.2 ; };allow-recursion { internal ; };allow-query { internal ; };allow-transfer { none; };

};


zone "." {type hint;file "db.cache";

};

// dumb.target.jay maps to the 192.168.1.0/24 network

zone "dumb.target.jay" {

type master;file "db.dumb.target.jay";allow-query { any ; };allow-transfer { secondaries; };

};


zone "1.168.192.in-addr.arpa" {

type master;file "db.192.168.1";allow-query { any; };allow-transfer { secondaries; };

};

zone "0.0.127.in-addr.arpa" {

type master;file "db.127.0.0";allow-query { 127.0.0.1 ; };// Note: no one needs to get zone transfers of this one!

};

Understanding the Settings

If a nameserver doesn't do recursion, a client can only make requests for a record to which the nameserver can answer directly.

Normally, this would imply that it can the nameserver will only then answer for its zone.

Now, if the nameserver is set to “forward” requests, things are different.

Playing the Attacker Some More

Cracking the Unix DNS Server...

* BIND 8.2.0 and 8.2.1 were vulnerable to a Remote Root exploit!

* Huge numbers of exploitable systems, when this exploit was released. Red Hat 6.0, among many others, shipped with one of these versions.

* There have been a number of widespread, similarly lethal vulnerabilities in BIND since then.

Cracking the DNS Server

E'Mind wrote the tutorial on exploitin the NXT buffer overflow.

Get it from google.com, along with the exploit, by searching for:

nxt-howto.txt and t666.c

Got the exploit?

OK, so we've got the exploit and we know how to use it.

But how does an attacker (us) find vulnerable machines?

Well, sometimes he just fires his exploit at every name server he can find. But usually, he seems to look for vulnerable servers automatically:

Finding Vulnerable DNS Servers

Try this command against one of your Unix DNS servers:

dig @your_ns your_ns txt chaos version.bind

Here's the output against my test system:

Grabbing the BIND Version Number

; <<>> DiG 8.2 <<>> @dumb.target.jay dumb.target.jay txt chaos version.bind ; (1 server found);; res options: init recurs defnam dnsrch;; got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; QUERY SECTION:;; version.bind, type = TXT, class = CHAOS

;; ANSWER SECTION: VERSION.BIND. 0S CHAOS TXT "8.2.2"

(truncated)

Security through Obscurity?

Security through Obscurity can be helpful, though it should never be your only defense.

Against Script Kiddies, it can be extremely effective, because of their Modus Operandi.( see http://www.securityportal.com/topnews/tighten20000720.html)

We can obscure the version number through the version directive in the options section of named.conf.

named.conf Revisited

We'll just add one directive to the options block:

options {

directory "/var/named";listen-on {192.168.1.2 ; };allow-recursion { internal ; };allow-query { internal ; };allow-transfer { none; }; version "Go away!";

};

Go Away?

This is a judgment call. The script kiddies generally use scanners that pattern-match. Your goal is to not get matched.

At the same time, you may want to "blend in". Suggestions:

version "9.0.0";version "4.9.7";version "8.3.0";

Other Defenses Against Cracking

Well, suppose a script kiddie gets lucky and tries an attack, even though a scanner didn't pick you out?

Or, worse, suppose a more capable cracker comes after you?

What defenses do you have?

Patch the Server!

As boring as this is, it's wholly necessary!

The BIND DNS server has had a number of security problems. We believe it will have more. You must continually patch/upgrade the server.

Follow the security announcements to know when it is necessary.

Remote Root Vulnerability

Remember how we talked about a "remote root" vulnerability?

You can't remove the "remote" part, but you can remove the "root" part in a very simple way:

Don't run named as root!

The attacker will get access as an ordinary user instead of superuser access!

Run as a Non-Root User 1/3

named -u dns_user -g dns_group

Create a separate user for the DNS server, with shell equal to /bin/false.

# vipw /etc/passwddns:x:53:53:dns:/var/named:/bin/false# vipw /etc/shadowdns:NP:6445::::::


named -u dns_user -g dns_group

Create a separate group for the DNS server, with shell equal to /bin/false.

# echo "dns::53:dns" >> /etc/group


Modify the named init script to use:

named -u dns -g dns

This forces the DNS server to drop privileges after binding to port 53

What Did This Defense Do?

When the attacker uses that sort of exploit, he still gets shell access on the machine. In this case, though, he isn't root!

But wait, he has a great deal of access to walk the filesystem, as much as an ordinary user. He might be able to escalate privilege.

Reference:http://www.securityportal.com/cover/coverstory20000626.html

Additional Defense

He'd escalate privilege by finding a Set-UID program, or other program running as root, and try to exploit it. If there was a vulnerable one on the system that an ordinary user can run, he could get root.

We can stop this by doing a Set-UID audit, but also by cutting off his access to most of the filesystem.

Chroot the named process, and thus the attacker!

Chroot?

Short for "Change Root", where we change the root of the process's filesystem. As an ordinary user, it shouldn't be able to read files outside this root.

This can be difficult, unless you have someone telling you how to do it ahead of time.

Chrooting BIND 8 under Solaris

We have to build a functional subset of the filesystem, with every program, library and data file that named needs.

We'll choose very restrictive permissions, so that if an attacker compromises named and gets user dns access, he won't be able to change much.

(In the "building BIND" appendix, note that the DESTLIB and DESTINC lines that we appended to the Makefile.set file during our build make this slightly less hairy.)

Creating the Chroot Prison 1/6

Set up directories and permissions:

mkdir -p /chroot/namedchmod 111 /chrootchmod 511 /chroot/namedcd /chroot/namedmkdir -p dev var/run/named var/tmp maps/master usr/lib \

/usr/local/etc usr/local/sbin usr/share/lib/zoneinfo/USchmod -R 111 dev var maps usrchmod 1711 var/tmp/usr/ucb/chown -R root.root /chroot


Copy over binaries:

cp /usr/local/sbin/named{,-xfer} /chroot/named/usr/local/sbinchmod 111 /usr/local/sbin/named{,-xfer}/usr/ucb/chown root.root /usr/local/sbin/named{,-xfer}

Copy over Timezone files:

cp /usr/share/lib/zoneinfo/US/Eastern \ /chroot/named/usr/share/lib/zoneinfo/US

/usr/ucb/chown root.root /usr/share/lib/zoneinfo/US/Easternchmod 444 /usr/share/lib/zoneinfo/US/Eastern


Create devices:

cd /chroot/named/devmknod tcp c 11 42mknod udp c 11 41mknod conslog c 21 0mknod log c 21 5mknod null c 13 2mknod zero c 13 12/usr/ucb/chown root.root *chgrp sys conslog null zero chmod 666 tcp udp conslog log null zero


Determine necessary libraries:

# ldd /usr/local/sbin/named{,-xfer} /usr/local/sbin/named: libl.so.1 => /usr/lib/libl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1/usr/local/sbin/named-xfer: libl.so.1 => /usr/lib/libl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 (example on Sol 2.7)


Copy over necessary libraries:

cp /usr/lib/libl.so.1 /usr/lib/libnsl.so.1 /usr/lib/libsocket.so.1 /usr/lib/libc.so.1 /usr/lib/libdl.so.1 /usr/lib/libmp.so.2 \

/chroot/named/usr/lib

Additionally the following is necessary:

cp /usr/lib/ld.so.1 /usr/lib/nss_files.so.1 /chroot/named/usr/lib

And fix the permissions:

/usr/ucb/chown root.root /chroot/named/usr/lib/*chmod 555 /chroot/named/usr/lib/*


Copy in the data files:(Configuration File)

cp /usr/local/etc/named.conf /chroot/named/usr/local/etc/named.conf/usr/ucb/chown root.root /chroot/named/usr/local/etc/named.confchmod 444 /chroot/named/usr/local/etc/named.conf

(Zone Files)

cp /var/run/named/db* /chroot/named/var/run/named//usr/ucb/chown root.root /chroot/named/var/run/named/db*chmod 444 /chroot/named/var/run/named/db*

Running named chroot-ed

Try this:

chroot /chroot/named /usr/local/sbin/named -u dns -g dns

Alternatively:

/chroot/named/usr/local/sbin/named -u dns -g dns -t /chroot/named

Wrapping Up Chroot

Now, go modify your init script to work with the new command line!

To harden the system slightly more, you might go delete or "chmod 000 foo" the named executable.

Chrooting BIND 9 1/3

Suppose you had build BIND 9 as in the appendix:

./configure --prefix=/usr/local/bindmake && make install

Well, to run it chrooted, you simply have to create a few directories -- there are no libraries or include files to copy over.


We'll be chrooting to /usr/local/bind, so let's create some subdirectories:

cd /usr/local/bindmkdir -p usr/local/bind/etc/ usr/local/bind/var/runmkdir -p var/run var/named

And copy your configuration files:

cp /etc/named.conf etc/cp /var/named/* var/named/


Finally, just run the named process with the -t flag!

/usr/local/bind/sbin/named -u dns -g dns -t /usr/local/bind

(This, of course, assumes that you have a dns user and group)

Going Further

Go read the DNS and BIND O'Reilly book, by Paul Albitz and Cricket Liu, or Matt Larson and Cricket Liu's DNS on Windows 2000. While this talk covers best practices and puts you way ahead of the game, there is nothing that compares with a deep understanding of the Basics.

Going Further...Off the Beaten Path

Not for the timid:

djbdns

Daniel Bernstein's DNS server, made to compete with BIND.

Much safer design than BIND -- break out functions into small programs with less privilege.

Less Privilege?

Instead of a central program, we have several smaller ones:

dnscacheLocal site caching-nameserver, but answers no queries for authoritative zones

Less Privilege? 2/2

tinydnsAuthoritative nameserver to answer queries about our specific machines

axfrdns / axfrgetResponsible for serving and getting zone transfers

Setting up djbdns

Kuro5hin.org has an automated setup script in a great article:

http://www.kuro5hin.org/?op=displaystory;sid=2001/4/9/17053/40631

Security?

djbdns does much of what we do here very easily:

1) All servers run by default as a non-root user

2) All servers run chrooted, by default, in their own directories

3) djbdns hasn't had a security hole and promises a $500 prize to the finder of the first one

Security 2/3?


4) walldns -- generates generic forward/reverse information to feed to outside servers, like this:

1.2.3.4 --rev--> 4.3.2.1.in-addr.arpa

4.3.2.1.in-addr-arpa --> 1.2.3.4

Security 3/3?


5) Queries for other people's domains are automatically restricted, since tinydns won't answer them -- this is the internal dnscache's job

6) It's darn easy, by design, to go split horizon with djbdns.

Should You Use It?

PRO: Much better security history than BINDPRO: Much better architecture for securityCON: Can you sell your boss on the switch?

PRO: Relatively easy to set up split-horizon DNSCON: Relatively difficult to configure and use, as few people have the experience or trainingOTOH: http://cr.yp.to/djbdns/ad/easeofuse.html

Even safer on OpenBSD!

Wrap Up

Advantages of Windows over Unix DNS Servers:

* Far, far less”colorful” history of vulnerabilities* That's probably enough!

Advantages of Unix over Windows DNS Servers:

* Greater control over configuration* Greater control over exposure

Speaker Bio

(Fill out your evaluations)

Jay Beale is the Lead Developer of Bastille Linux and the President of JJB Security Consulting and Training. He has written a number of security articles and is currently working on a book on Locking Down Linux and Unix for Addison Wesley. Read more of his articles on:

http://www.jjbsec.com

Appendix I: Building Unix BIND DNS server

Grab source for BIND 8 at:

ftp://ftp.isc.org/isc/bind/src/8.2.4/bind-src.tar.gz

or for BIND 9 at:

ftp://ftp.isc.org/isc/bind9/9.1.3/bind-9.1.3.tar.gz

The Build Process: BIND 8

On Solaris:# tar -xzvf bind-src.tar.gz

# cd src

# vi port/solaris/Makefile.set

Onto configuring build process...

Configuring BIND Makefile.set (Solaris)

Append DESTINC and DESTLIB lines:

'DESTINC=/usr/local/include'

'DESTLIB=/usr/local/lib'

to get the following:

Solaris Makefile.set

'CC=gcc''CDEBUG=-g -O2''DESTBIN=/usr/local/bin''DESTSBIN=/usr/local/sbin''DESTEXEC=/usr/local/sbin''DESTMAN=/usr/local/share/man''DESTHELP=/usr/local/lib''DESTETC=/usr/local/etc''DESTRUN=/usr/local/etc''LDS=:''AR=/usr/ccs/bin/ar cru''LEX=/usr/ccs/bin/lex''YACC=/usr/ccs/bin/yacc -d''SYSLIBS=-ll -lnsl -lsocket''INSTALL=/usr/ucb/install''MANDIR=man''MANROFF=man''CATEXT=$$N''PS=ps -p''RANLIB=/usr/ccs/bin/ranlib''DESTINC=/usr/local/include''DESTLIB=/usr/local/lib'

Compiling BIND (Solaris)

# make depend

# make

# make install

Building BIND 9

# cd bind-9.1.2

# ./configure --prefix=/usr/local/prefix

# make && make install

Installing BIND on Linux

Find the location for your Linux distribution's most recent BIND package.

# rpm -ivh http://path_to_package/bind-8.2.4-x.rpm

Appendix II: Best Practice -Logging

BIND 8&9 add the capability for enhanced logging.

Channel: a method (syslog priority, file, stderr or bit bucket)

for logging data

- Category:a type of data to log, based on hard-coded names in

the BIND 8/9 program

BIND 8&9 Logging Channels 1/2

( For syslog, format is: syslog facility; severity severity; )

channel info_syslog {

syslog daemon;severity info;};

channel some_file {

file "your_file";severity error;};

BIND 8&9 Logging Channels 2/2

channel stderr_fd {

file "<stderr>";severity critical;};

channel null_gone {

null;};

BIND 8&9 Logging Categories 1/3

Quoted from DNS and BIND book:

default - wildcard, maps to ALL cname - CNAME errors config - configuration file errors db - database operations eventlib - system events insist - internal consistency check failures lame-servers - Detection of bad delegation



load - zone loading messages maintenance - Maintenance events (e.g. system queries) ncache - Negative caching events notify - Asynchronous change notifications os - problems with the operating system packet - decodes of packets received and sent panic - problems that cause the shutdown of the server



parser - Parsing of the configuration file. queries - Analogous to BIND 4's query logging response-checks - Malformed responses, unrelated addt'l

information,... security - approved / unapproved requests statistics - periodic reports of activities update - dynamic update events xfer-in / xfer-out - Zone transfers from remote/local

nameserver to local/remote nameserver

Additional Logging

BIND 8&9 have strong default logging, but we can add a security log for certain important categories. Append to named.conf:

logging { channel security { file "/var/adm/bind-security" versions 4 size 10m; print-time yes; };category insist {security;};category os { security; };category panic {security;};category security {security;};category xfer-out { security; };category update {security; };};

Documents

Attacking and Securing DNS Servers Jay Beale Lead Developer, Bastille Linux President, JJB Security Consulting (Copyright 2002 - All Rights Reserved)