Transcript 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 Beale
Lead 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.15
Originally, 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.
Interesting Part of the Talk
"
Take the role of an attacker!
– 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.
Interesting Part of the Talk
"
Take the role of an attacker!
– 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
jjbsec.com.
86374 IN
jjbsec.com.
86374 IN
NS
NS
NS
ns2.jjbsec.com.
ns.bastille-linux.org.
ns.jjbsec.com.
;; ADDITIONAL SECTION:
ns.jjbsec.com.
86374 IN
ns2.jjbsec.com.
86374 IN
ns.bastille-linux.org. 86374 IN
A
A
A
192.168.2.2
192.168.2.3
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: 129
Address: 10.0.0.1
Non-authoritative answer:
dumb.target.jay nameserver = dumb.target.jay
dumb.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
<insert text figure 2>
AXFR
; <<>> DiG 9.1.2 <<>> @192.168.2.2 jjbsec.com AXFR
;; global options: printcmd
jjbsec.com.
86400 IN
SOA
ns.jjbsec.com. hostmaster.jjbsec.com. 2002040201 3600 900 604800 3600
jjbsec.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.11
allen.jjbsec.com.
86400 IN
A
192.168.3.6
backup.jjbsec.com.
86400 IN
A
192.168.3.17
bakos.jjbsec.com.
86400 IN
A
192.168.3.3
beale.jjbsec.com.
86400 IN
A
192.168.3.4
billing.jjbsec.com.
604800
IN
NS
ns.billing.jjbsec.com.
ns.billing.jjbsec.com. 86400 IN
A
192.168.128.2
db.jjbsec.com.
86400 IN
A
192.168.5.2
db-dev.jjbsec.com.
86400 IN
A
192.168.4.3
db-storage.jjbsec.com. 86400 IN
A
192.168.5.3
db-storage-dev.jjbsec.com. 86400 IN
A
192.168.4.4
db1.jjbsec.com.
86400 IN
A
192.168.5.4
db2.jjbsec.com.
86400 IN
A
192.168.5.5
db3.jjbsec.com.
86400 IN
A
192.168.5.6
friedman.jjbsec.com.
86400 IN
A
192.168.3.13
Zone Transfer of their Zone 2/2
frontpage.jjbsec.com. 86400 IN
A
192.168.3.15
ftp.jjbsec.com.
86400 IN
A
192.168.2.4
fw1-dev.jjbsec.com.
86400 IN
A
192.168.6.4
imap.jjbsec.com. 86400 IN
CNAME mail.jjbsec.com.
khouri.jjbsec.com.
86400 IN
A
192.168.3.19
mail.jjbsec.com. 86400 IN
A
192.168.2.7
mdk-dev.jjbsec.com.
86400 IN
A
192.168.6.3
ns.jjbsec.com.
86400 IN
A
192.168.2.2
ns2.jjbsec.com.
86400 IN
A
192.168.2.3
ns.bastille-linux.org.
86400 IN
A
10.0.0.3
nt4.jjbsec.com.
86400 IN
A
192.168.3.18
old-www.jjbsec.com.
86400 IN
A
192.168.2.6
pop.jjbsec.com.
86400 IN
CNAME mail.jjbsec.com.
rh-dev.jjbsec.com.
86400 IN
A
192.168.6.2
roesch.jjbsec.com.
86400 IN
A
192.168.3.10
skoudis.jjbsec.com.
86400 IN
A
192.168.3.7
snmp.jjbsec.com. 86400 IN
A
192.168.3.12
snort-eval.jjbsec.com. 86400 IN
A
192.168.3.16
spangler.jjbsec.com.
86400 IN
A
192.168.3.5
spitzner.jjbsec.com.
86400 IN
A
192.168.3.8
stearns.jjbsec.com.
86400 IN
A
192.168.3.2
sundoc.jjbsec.com.
86400 IN
A
192.168.3.9
targets.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.8
www-dev.jjbsec.com.
86400 IN
A
192.168.4.2
jjbsec.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 many
conclusions as possible about their network.
Reactions? 2/2
Think about:
1) services offered on each machine
2) purpose of each machine
3) operating system of each machine
4) 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 reroute 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; };
};
named.conf.restricted_axfr 2/3
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; };
};
named.conf.restricted_axfr 3/3
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/passwd
dns:x:53:53:dns:/var/named:/bin/false
# vipw /etc/shadow
dns:NP:6445::::::
Run as a Non-Root User 2/3
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
Run as a Non-Root User 3/3
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/named
chmod 111 /chroot
chmod 511 /chroot/named
cd /chroot/named
mkdir -p dev var/run/named var/tmp maps/master usr/lib \
/usr/local/etc usr/local/sbin usr/share/lib/zoneinfo/US
chmod -R 111 dev var maps usr
chmod 1711 var/tmp
/usr/ucb/chown -R root.root /chroot
Creating the Chroot Prison 2/6
Copy over binaries:
cp /usr/local/sbin/named{,-xfer} /chroot/named/usr/local/sbin
chmod 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/Eastern
chmod 444 /usr/share/lib/zoneinfo/US/Eastern
Creating the Chroot Prison 3/6
Create devices:
cd /chroot/named/dev
mknod tcp c 11 42
mknod udp c 11 41
mknod conslog c 21 0
mknod log c 21 5
mknod null c 13 2
mknod zero c 13 12
/usr/ucb/chown root.root *
chgrp sys conslog null zero
chmod 666 tcp udp conslog log null zero
Creating the Chroot Prison 4/6
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)
Creating the Chroot Prison 5/6
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/*
Creating the Chroot Prison 6/6
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.conf
chmod 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/bind
make && 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.
Chrooting BIND 9
2/3
We'll be chrooting to /usr/local/bind, so let's create
some subdirectories:
cd /usr/local/bind
mkdir -p usr/local/bind/etc/ usr/local/bind/var/run
mkdir -p var/run var/named
And copy your configuration files:
cp /etc/named.conf etc/
cp /var/named/* var/named/
Chrooting BIND 9
3/3
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:
dnscache
Local site caching-nameserver, but answers no
queries for authoritative zones
Less Privilege? 2/2
tinydns
Authoritative nameserver to answer queries about
our specific machines
axfrdns / axfrget
Responsible 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=200
1/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?
djbdns does much of what we do here very easily:
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?
djbdns does much of what we do here very easily:
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 BIND
PRO: Much better architecture for security
CON: Can you sell your boss on the switch?
PRO: Relatively easy to set up split-horizon DNS
CON: Relatively difficult to configure and use, as
few people have the experience or training
OTOH: 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'
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
BIND 8&9 Logging Categories 2/3
Quoted from DNS and BIND book:
" 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
BIND 8&9 Logging Categories 3/3
Quoted from DNS and BIND book:
" 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; };
};