Vic/notes/dns
From Summerseas
Contents |
[edit]
Using Transaction Signature Keys.(TSIG)
- Transaction Signature Keys can provide an added measure of security for DNS servers receiving zone transfers from the primary DNS server or dynamic zone updates from a DHCP server. It is possible and in fact fairly typical for DNS servers to use an IP address as the only means to specify who's allowed to transfer zones or update zones. The problem with this approach is that IP addresses can be faked which could allow an unauthorized person to alter DNS records.
- The TSIG key is shared between a pair of servers and provides an additional layer of security. To generate the key simply use the dnssec-keygen program provided with current BIND distributions.
- Example:
# dnssec-keygen -a hmac-md5 -b 128 -n HOST dns1-dns2 Kdns1-dns2.+157+46748 # cat Kdns1-dns2.+157+46748.private Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: MXO0pi5xjF102xeXhPj+qw==
- The key MXO0pi5xjF102xeXhPj+qw== may be used on both servers to control transfers. To tell the primary DNS server to use the TSIG key to control zone transfers from a secondary DNS server add appropriate lines to the named.conf file.
Example:
#
# Primary server - 192.168.36.1
# Secondary server - 192.168.36.2
#
# (named.conf on the primary.)
options {
directory "/";
allow-transfer { key dns1-dns2; };
};
key dns1-dns2{
algorithm "hmac-md5";
secret
"MXO0pi5xjF102xeXhPj+qw==";
};
server 192.168.36.2 {
keys { dns1-dns2; };
};
#
#
#
# (named.conf on the secondary)
key dns1-dns2{
algorithm "hmac-md5";
secret
"MXO0pi5xjF102xeXhPj+qw==";
};
server 192.168.36.1 {
keys { dns1-dns2; };
};
- After the servers reload their config the new key will be required for zone transfers from 192.168.36.1 to 192.168.36.2.
- For additional information and for the latest distribution of BIND, visit www.isc.org
[edit]
Logging
- It is often desirable to customize DNS logging to collect and organize statitistics and usage information. You may want to know about attempts to update or transfer zones whether the attempt is successful or not. You may also want to know where queries are coming from and what information is being queried. If you see an excessive number of queries from a particular host you may need to investigate and in severe cases you may need to block access from that host until the problem is resolved.
- Here is a sample logging statement that might be used in named.conf. Consult the administrator's reference at www.isc.org for additional details.
- Example:
logging {
channel my_syslog {
syslog daemon;
severity info;
print-time yes;
print-category yes;
};
channel my_file {
file "logs/dns.logs" versions 3 size 25m;
severity info;
print-time yes;
print-category yes;
};
channel my_queries {
file "logs/queries.logs" versions 3 size 25m;
severity info;
print-time yes;
print-category yes;
};
channel my_xfers {
file "logs/xfers.logs" versions 3 size 25m;
severity info;
print-time yes;
print-category yes;
};
channel my_security {
file "logs/security.logs" versions 3 size 25m;
severity info;
print-time yes;
print-category yes;
};
category default { my_syslog; my_file; };
category queries { my_queries;};
category xfer-in { my_xfers; };
category xfer-out { my_xfers; };
category lame-servers { my_file; };
category config { my_file; };
category security { my_security; };
};
[edit]
Securing DNS
- DNS servers have been a favorite target for internet vandals for quite some time. Consider the fact that if I could compromise the DNS server that you are using, I could fool you into thinking that my computer is any other computer. I could build a web-site just like your bank's and maybe collect account numbers and pins. If I compromise your company's DNS server I could affect business severely. It is important to make your DNS server as secure as possible.
- The following steps will help secure your DNS server:
- Avoid running the named daemon as root.
- Run the named daemon in a chrooted environment, sometimes called a chroot jail.
- Promptly apply security patches.
- Log DNS activity and review the logs.
- Use transaction signature keys to control transfers and updates.
- Fortunately, with the newer versions of DNS these steps are easier to accomplish than with earlier versions. The named daemon can be started with command line parameters that will effect the chroot jail and run the daemon as the desired user. The following command will run the daemon as user "named" locked into /var/named. "/usr/sbin/named -u named -t /var/named". An added measure of protection would be to make /var/named a filesystem. That way if the named daemon is exploited the damage will be contained to /var/named and will not affect the OS or health of the server other than the named process.
- The following steps are required to chroot named:
- Create named user and chroot jail.
- Make directories within the jail for etc, zones, logs
- Copy named.conf to ~named/etc
- Edit ~named/etc/named.conf making entries reflect that ~named is "/"
- Copy zone data to ~named/zones.
- Set perms such that named can read everything and write logs and updates.
- The daemon will log using UTC time unless you copy timezone information to the jail and that will vary depending on platform. For Solaris, copy the appropriate file from /usr/share/lib/zoneinfo to the same path within the chroot jail along with /etc/TIMEZONE to ~named/etc.
- Finally, modify the named startup script to specify the chroot jail and named user as described earlier.
- NOTE - Consult the administrator's reference at www.isc.org for additional details.
[edit]
DNS Hints File Updates
- A DNS server needs a list of root name servers in order to locate authorative name servers and answer queries. The root name servers do not often change but is is good practice to update the file from time to time. The command "dig . ns > db.cache" will produce an updated file. The following example shows correct syntax in named.conf for loading the file.
Example named.conf
zone "." {
type hint;
file "master/db.cache";
};
Example db.cache
; <<>> DiG 9.2.1 <<>> . ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54331
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 485721 IN NS F.ROOT-SERVERS.NET.
. 485721 IN NS G.ROOT-SERVERS.NET.
. 485721 IN NS H.ROOT-SERVERS.NET.
. 485721 IN NS I.ROOT-SERVERS.NET.
. 485721 IN NS J.ROOT-SERVERS.NET.
. 485721 IN NS K.ROOT-SERVERS.NET.
. 485721 IN NS L.ROOT-SERVERS.NET.
. 485721 IN NS M.ROOT-SERVERS.NET.
. 485721 IN NS A.ROOT-SERVERS.NET.
. 485721 IN NS B.ROOT-SERVERS.NET.
. 485721 IN NS C.ROOT-SERVERS.NET.
. 485721 IN NS D.ROOT-SERVERS.NET.
. 485721 IN NS E.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
J.ROOT-SERVERS.NET. 572121 IN A 192.58.128.30
;; Query time: 40 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Aug 20 05:44:55 2004
;; MSG SIZE rcvd: 244
- Consult the administrator's reference at www.isc.org for additional details.
[edit]
Handling Spam
- Some estimates suggest that up to 80% of all mail flowing throughout the internet is spam. This has become a significant problem for users and a troubling problem for mail server administrators. One approach is to dynamically look at email content and try and determine from the content whether the email is legitimate mail or spam. This approach will identify spam emails but invariably will sometimes mistake legitimate email for spam. This side effect tends to annoy users of the mail system even more than the spam did in the first place.
- Another approach is to use spam and open relay databases maintained on the internet to reject mail from black listed mail servers. These databases are maintained by organizations like www.spamhaus.org and www.ordb.org. They are actually DNS servers populated with "A" records of known spammers and mail servers functioning as open relays.
- What is an open relay? A mail server that will accept email from anyone and deliver it to users at domains that the mail server isn't intended to serve is an open relay. Open relays are used extensively by spammers.
- Most mail servers can be configured to check these lists when receiving mail from the internet. If the IP address of the smtpd client is in any of the databases specified then the client is rejected.
- Here is an example of how to configure Postfix to consult a couple of these databases:
- From the postfix main.cf file:
- maps_rbl_domains = relays.ordb.org, sbl-xbl.spamhaus.org
- smtpd_client_restrictions = permit_mynetworks, reject_maps_rbl,check_relay_domains
