A unique TSIG key is not utilized for communication between name servers sharing zone information.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-4495	DNS0720	SV-4495r2_rule	DCNR-1	Medium

Description
If a secret key shared between two servers is not unique, then any breach of the key is not limited to those two servers. In particular, if all servers in a zone share the same key, then there is the possibility that an attack could modify records all of the servers. Recovering from a successful attack is considerably more difficult in this circumstance. Furthermore, the more copies of any one key are in existence, the greater the likelihood that the confidentiality of that key will be lost at some point in time.

Description

If a secret key shared between two servers is not unique, then any breach of the key is not limited to those two servers. In particular, if all servers in a zone share the same key, then there is the possibility that an attack could modify records all of the servers. Recovering from a successful attack is considerably more difficult in this circumstance. Furthermore, the more copies of any one key are in existence, the greater the likelihood that the confidentiality of that key will be lost at some point in time.

STIG	Date
BIND DNS STIG	2015-10-01

Details

Check Text ( C-3373r1_chk )
Two name servers sharing zone information must utilize a unique TSIG key for communication between them or, in cases in which more than four servers support a zone, create a written key management plan that will document how keys are shared and replaced in a manner to reduce residual risk to an acceptable level. If there are no server statements within named.conf, this is a finding. If there are server statements, then check that there is one corresponding to each of the zone partners. If this is not the case, then this is also a finding. If there are server statements for servers other than those supplied, then there may be a finding associated with the incompleteness of the list. On the master name server, this is an example of a configured key statement: key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. { algorithm hmac-md5; include "/etc/dns/keys/tsig-example.key"; }; zone “disa.mil” { type master; file “db.disa.mil”; allow-transfer { key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil.; }; }; On the slave name server, this is an example of a configured key statement: key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. { algorithm hmac-md5; include "/etc/dns/keys/tsig-example.key"; }; server 10.2.2.2 { keys {ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil}; }; zone “disa.mil” { type slave; masters { 10.1.1.1; }; file “db.disa.mil”; }; Check the keys phrase within each of the server statements to ensure uniqueness of keys. If two or more server statements reference the same key, then this is a finding.

Check Text ( C-3373r1_chk )

Two name servers sharing zone information must utilize a unique TSIG key for communication between them or, in cases in which more than four servers support a zone, create a written key management plan that will document how keys are shared and replaced in a manner to reduce residual risk to an acceptable level.

If there are no server statements within named.conf, this is a finding. If there are server statements, then check that there is one corresponding to each of the zone partners. If this is not the case, then this is also a finding.

If there are server statements for servers other than those supplied, then there may be a finding associated with the incompleteness of the list.

On the master name server, this is an example of a configured key statement:

key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. {
algorithm hmac-md5;
include "/etc/dns/keys/tsig-example.key";
};

zone “disa.mil” {
type master;
file “db.disa.mil”;
allow-transfer { key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil.; };
};

On the slave name server, this is an example of a configured key statement:

key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. {
algorithm hmac-md5;
include "/etc/dns/keys/tsig-example.key";
};

server 10.2.2.2 {
keys {ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil};
};

zone “disa.mil” {
type slave;
masters { 10.1.1.1; };
file “db.disa.mil”;
};

Check the keys phrase within each of the server statements to ensure uniqueness of keys. If two or more server statements reference the same key, then this is a finding.

Fix Text (F-4380r1_fix)
The DNS software administrator should modify the named.conf and server statements so that the key shared between any two servers is unique. This may involve the generation of additional keys and the creation of new files dedicated to those keys.