207.3. Securing a DNS server

207.3 Securing a DNS server

Weight: 2

Description: Candidates should be able to configure a DNS server to run as a non-root user and run in a chroot jail. This objective includes secure exchange of data between DNS servers.

Key Knowledge Areas:

  • BIND 9 configuration files

  • Configuring BIND to run in a chroot jail

  • Split configuration of BIND using the forwarders statement

  • Configuring and using transaction signatures (TSIG)

  • Awareness of DNSSEC and basic tools

  • Awareness of DANE and related records

Terms and Utilities:

  • /etc/named.conf

  • /etc/passwd

  • DNSSEC

  • dnssec-keygen

  • dnssec-signzone

When DNS was first implemented, it did not include any security, and soon after being put into use, several vulnerabilities were discovered. As a result, some security solutions was developed in the form of extensions that could be added to existing DNS protocols. This solutions were later tested, modified and approved as a standard by the Internet Engineering Task Force (IETF).

Domain Name Security Extentions (DNSSEC)

The original purpose of DNSSEC was to protect Internet clients from fake DNS data by verifying digital signatures embedded in the data. If the digital signatures in the data match those that are stored in the master DNS servers, then the data is allowed to continue to the client computer making the request.

DNSSEC uses a system of public keys and digital signatures to verify data. These public keys can also be used by security systems that encrypt data as it is sent through the Internet and then decrypt it when it is received by the intended recipient. However, DNSSEC cannot protect the privacy or confidentiality of data because it does not include encryption algorithms. It only carries the keys required to authenticate DNS data as genuine or genuinely not available.

How DNSSEC works?

For explaining how DNSSEC works first we should know about some items. what are RRsets ? ZSK ? RRSIG ? DSKEY?KSK ?

Resource Records sets (RRsets)

The first step towards securing a zone with DNSSEC is to group all the records with the same type into a resource record set (RRset). For example, if you have three AAAA records in your zone on the same label (i.e. label.example.com), they would all be bundled into a single AAAA RRset. Here we omit that as we don't ahve lots of records.

DNSSEC uses two pairs of keys ZSK and KSK.

Zone Signing Keys

Each zone in DNSSEC has a zone-signing key pair (ZSK). the private portion of the key digitally signs each RRset in the zone, while the public portion verifies the signature.

RRSIG

To enable DNSSEC, a zone operator creates digital signatures for each RRset using the private ZSK and stores them in their name server as RRSIG records. This is like saying, “These are my DNS records, they come from my server, and they should look like this.”

When a DNSSEC resolver requests a particular record type (e.g., AAAA), the name server also returns the corresponding RRSIG. The resolver can then pull the DNSKEY record containing the public ZSK from the name server. Together, the RRset, RRSIG, and public ZSK can validate the response.

If we trust the zone-signing key in the DNSKEY record, we can trust all the records in the zone. But, what if the the zone-signing key was compromised? HA HA HA, We need a way to validate the public ZSK. The solution is finding a way to verify the Public ZSK . Lets use KSK!

Key Signing Keys

In addition to a zone-signing key, DNSSEC name servers also have a key-signing key (KSK). The KSK validates the DNSKEY record in exactly the same way as our ZSK secured the rest of our RRsets in the previous section: It signs the public ZSK (which is stored in a DNSKEY record), creating an RRSIG for the DNSKEY.

Just like the public ZSK, the name server publishes the public KSK in another DNSKEY record, which gives us the DNSKEY RRset shown above. Both the public KSK and public ZSK are signed by the private KSK. Resolvers can then use the public KSK to validate the public ZSK.

Validation

Validation for resolvers now looks like this:

  • Request the desired RRset, which also returns the corresponding RRSIG record.

  • Request the DNSKEY records containing the public ZSK and public KSK, which also returns the RRSIG for the DNSKEY RRset.

  • Verify the RRSIG of the requested RRset with the public ZSK.

  • Verify the RRSIG of the DNSKEY RRset with the public KSK.

Implementing DNSSEC

For now we partially demonstrate DNSSEC.To start we need two pairs of keys , first KSK (Key Signing Key ) for DNSKEY record it self and another a of ZSK (Zone Signing Key) to sign the zone and zone validation.

dnssec-keygen

dnssec-keygen generates keys for DNSSEC (Secure DNS), first lets generate KSK keys, that is easy:

Whereas

dnssec-keygen switches

-a

Defines algorithm

-b

keysize

-n

nametype,can be weather ZONE for DNSSEC or HOST for TSIG

-f

Set the specified flag in the flag field of the KEY/DNSKEY record.The only recognized flags are KSK (Key Signing Key) and REVOKE.

dnssec also need a pair of ZSK keys to sign the zone with them:

dnssec-signzone

Obviously dnssec-signzone signs a zone and produces a signed version of the zone.

Lets take a look at inside:

It generates additional required NSEC and RRSIG records :) also. its required to add

in /etc/bind/named.conf.options

include the key files in /etc/bind/named.conf and finally use signed file db.myzone.signed in /etc/bind/named.conf.local .

that is enough for lpic 2 exam.

transaction signatures (TSIG)

Transaction aasignatures (TSIG) is a mechanism used to secure DNS messages and to provide secure server-to-server communication (usually between master and slave server, but it can be extended for dynamic updates as well). TSIG can protect the following type of transactions between two DNS servers:

  • Zone transfer

  • Notify

  • Dynamic updates

  • Recursive query messages etc

TSIG is available for BIND v8.2 and above.

How TSIG works ?

In a simplest way we use tsig to secure zone transfer between Master and slave dns server. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages. TSIG is easy and lightweight for resolvers and named.

Configuring TSIG

Configuring TSIG between Master and Slave DNS servers is no that much hard, We just create a shared key and copy it on both severs, and then configure Zone files to use that shared key.

For generating a shared-key we use dnssec-keygen tool.

As we mentioned dnssec-keygen generates keys for DNSSEC (Secure DNS). It can also generate keys for use with TSIG (Transaction Signatures) or TKEY (Transaction Key).

The name of the key is specified on the command line. For DNSSEC keys, this must match the name of the zone for which the key is being generated.

On master server:

For implementing DNS-SEC use -n ZONE but here for TSIG we have used -n HOST.

As we said TSIG use a shared-key so we just need 1 key. We use Key: b5aPd9u//WDzXeZIfF7vQw== item from Kmykey.+157+08981.private for both servers. Lets create our desired key file :

now we need to include the key file that we have alredy made inside named.conf :

Okey it is time to change zone file configuration and allow zone transfer with with whom has the shared-key. So change

allow-transfer {192.168.10.151;}; to allow-transfer { key "mykey" ; }; like this:

okey lets check it

opps we have forgot tiny miny ; in named.local.tsig .add it and then check again:

Now in Slave side, we should have some problems with zone tarnsfer as we haven't inserted shared-key . To test, increase the serial number of db.myzone file on master :

and see logs on slave:

To solve the problem lets add our shared-key to the Slave Server too:

We defined using the key for zone transfer from the master.

and finally include the key file on named.conf :

and check the zone transfer:

DNS-based Authentication of Named Entities (DANE)

TLS/SSL encryption is currently based on certificates issued by certificate authorities (CAs). Within the last few years, a number of CA providers suffered serious security breaches. Like allowing the issuance of certificates for well-known domains to those who don't own those domains!

Trusting a large number of CAs might be a problem because any breached CA could issue a certificate for any domain name. DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work.

Additionally DANE allows a domain owner to specify which CA is allowed to issue certificates for a particular resource, which solves the problem of any CA being able to issue certificates for any domain.

TLSA Resource Record

The TLSA DNS resource record (RR) is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLSA certificate association". In conjunction with DNSSEC signatures, this will permit better and more secure ways for applications to authenticate certificates. Here's an example for the HTTPS service (port 443, TCP) at www.example.com:

split DNS Server

Split Domain Name System (Split DNS) is an implementation in which separate DNS servers are provided for internal and external networks as a means of security and privacy management. But why we should use split dns servers? Lets see what happens when we use an external dns server for accessing our web server:

Using single external dns having security issues, consume bandwidth, and has dependency to internet connection, while using split DNS servers bring us security and privacy. Split DNS uses two separate DNS servers:

An external DNS contains only small zone files for a domain with information like file transfer protocol (FTP), Web addresses and other server addresses that can be publicly published. An internal DNS server holds DNS records for an internal network.

When internal network users look up host names, the internal DNS answers and externally forwards this information as needed.

External users that lookup hostname from external network are answered by external DNS , which contains data limited to publicly accessible resources.

Also we can configure our Internal DNS server to return external IP address of host name to the guests who are in our internal network ! this prevents internal secrets from being divulged.

split DNS configuration

Implementing split DNS servers is so easy, no matter our internal DNS server is Forwarding requests or it is a Caching only DNS server, its just enough to make a master zone file for desired host name:

Now lets use one of our previous zone db files to configure zone file for mycompany.com hostname:

Now lets query our local DNS server and compare answers with the answers that google DNS returns to us:

as you can see they are different, that is what we expected!

chroot

The term chroot refers to a process of creating a virtualized environment in a Unix operating system, separating it from the main operating system and directory structure.

This process essentially generates a isolated space, with its own root directory, to run software programs. This virtual environment runs separately from the main operating system's root directory. Any software program run in this environment can only access files within its own directory tree. It cannot access files outside of that directory tree. This confined virtual environment is often called a "chroot jail".

A chroot jail is a way to isolate a process and its children from the rest of the system. It should only be used for processes that don't run as root, as root users can break out of the jail very easily.

Configuring BIND to run in a chroot jail

Confguring BIND DNS server to run in chroot jail can be pretty strait forward. But based on distro that we choose, many configurations might be done automatically. Here we use CentOS6 for demonstartion:

In CentOS by default all configuration are placed in /etc/named.conf :

Lets use CentOS bind-chroot package to put every thing in chroot jail:

This package create chroot environment and create required links for BIND daemon :

Lets get in /var/named/chroot and say hello :

bind-chroot package has built every thing.

To do the same thing we have to edit /etc/default/bind9

with -t option, The -t option changes the root directory from which bind operates to be /var/named/chroot :

and then make all required folders under /var/named/chroot directory and copy and link required files.

more info: https://www.cloudflare.com/dns/dnssec/how-dnssec-works/

Previous207.2. Create and maintain DNS zonesNext208.1. Implementing a web server

Last updated