So, this week we'll dive head first into DNSSEC. I'll address some basic background information about what it is, what it does and what it does not do. It seems to be pretty well misunderstood by many people.
DNSSEC stands for the DNS Security Extensions which the IETF created to help "secure" the DNS query-response process (resolution). In a nutshell, when querying from a DNSSEC-capable resolver, DNSSEC ensures you are getting the correct record from the correct server, or a record of non-existence when the record you are looking for does not exist.
Here are some specifics on what DNSEC can and can not do:
DNSSEC provides:
Data origin authentication
Data integrity verification
Authenticated denial of existence
Cache poisoning protection
DNS hijacking protection
DNSSEC does not:
Provide confidentiality
Prevent Dedicated Denial of Service (DDoS) Protection
Stop IP spoofing
One of the main issues for initiating DNSSEC was to stop DNS cache poisoning where false records are inserted into a DNS server database to divert traffic away from the true intended destination.
Here is a link to a very informative Wikipedia page on DNSSEC:
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
And again, the NIST Secure Domain Name System Deployment Guide is an invaluable resource that includes a very in-depth section on DNSSEC:
http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf
So, that covers some basic DNSSEC background information. Next week, we'll open the hood and start examining how DNSSEC does what it does. Cheers!
Sunday, September 30, 2012
Saturday, September 22, 2012
Securing a DNS Server, Part 3.
This week, we’ll conclude securing an authoritative BIND
server through configuration.
1. It is a definite best practice to keep master and
slave servers isolated from each other. This
means both physically and logically (network-wise). They should be in completely different areas
of a building, or better yet one should be off-site. This so that obviously a disaster will not
wipe out all of your servers. They
should be separated logically by placing them on separate network segments so a
failure of a network segment will not take out both servers.
2. The servers should
run some sort of file integrity checking tool also. Tripwire is a good example of this. This software can notify you that files on
the server have changed.
3. Protect your server by a firewall, don't just leave it outside to fend for itself. Put it in a DMZ with some firewall protection. It can also benefit from ACLs in place on the border routers of your organization.
4. Protect slave servers from false update notifications by using the allow update section in named.conf. Put the master server IP in this section.
That wraps up this week--next week we'll start looking into DNSSEC.
That wraps up this week--next week we'll start looking into DNSSEC.
Saturday, September 15, 2012
Securing a DNS Server, Part2.
This week we'll look into the configuration of a DNS server and some things that can be done to make the server more secure. Again, we are looking at an authoritative BIND server.
1. Hide the version of BIND you are running. The bind version can be found using either dig or nslookup. Bad guys can target their attacks based on the version of BIND you are running. Hiding the version is easily accomplished by editing the configuration file (named.conf). In the options section, there is a version line. Simply edit the text in the quotes to something along the lines of "Not disclosed." or whatever you want.
2. Disable recursion on an authoritative DNS server. This is a best practice and also a good security measure. Authoritative servers answer queries, not perform lookups. With recursion disabled, the server will not build up a cache, thereby preventing a threat for cache poisoning.
3. Limit zone transfers (and associated notifies) to only between primary and secondary servers.
4. Secure zone transfers using shared TSIG (transaction signature) keys. These keys should be changed at least annually.
5. Disable dynamic updates. This will prevent unauthorized adding, changing or deleting of zone data.
For more details on these and more actions, please refer to the NIST Secure DNS Deployment Guide in the 2nd week (3 September) post.
That wraps it up for this week. Next week I plan to finish off securing the server through configuration before we boldly dive into DNSSEC!
This week we'll look into the configuration of a DNS server and some things that can be done to make the server more secure. Again, we are looking at an authoritative BIND server.
1. Hide the version of BIND you are running. The bind version can be found using either dig or nslookup. Bad guys can target their attacks based on the version of BIND you are running. Hiding the version is easily accomplished by editing the configuration file (named.conf). In the options section, there is a version line. Simply edit the text in the quotes to something along the lines of "Not disclosed." or whatever you want.
2. Disable recursion on an authoritative DNS server. This is a best practice and also a good security measure. Authoritative servers answer queries, not perform lookups. With recursion disabled, the server will not build up a cache, thereby preventing a threat for cache poisoning.
3. Limit zone transfers (and associated notifies) to only between primary and secondary servers.
4. Secure zone transfers using shared TSIG (transaction signature) keys. These keys should be changed at least annually.
5. Disable dynamic updates. This will prevent unauthorized adding, changing or deleting of zone data.
For more details on these and more actions, please refer to the NIST Secure DNS Deployment Guide in the 2nd week (3 September) post.
That wraps it up for this week. Next week I plan to finish off securing the server through configuration before we boldly dive into DNSSEC!
Sunday, September 9, 2012
Securing a DNS Server, Part 1
This week I'll go over some methods to secure a BIND DNS server. As I mentioned last week, these methods all pertain to an authoritative DNS server.
These items are all from the Defense Information Systems Agency (DISA), Information Assurance Support Environment (IASE) Domain Name System Security Checklist, Version 4, Release 1.12. which can be downloaded from here:
http://iase.disa.mil/stigs/a-z.html
DISA has a very large collection of security guides to look over--they can be a great help to anyone wanting to secure their IT systems.
Back to DNS security, here are some general common methods DNS administrators use to secure their servers:
1. Do NOT allow the BIND process (named) to run as the root user. For some odd reason, BIND runs as root by default. The reason for this is that if your BIND process is taken over by an intruder then they have root access to your server. I created a "named" user to run BIND on my servers.
Note that the user for BIND should not have a default shell, to prevent someone from logging into that account.
2. Run BIND in a chroot (change root) environment, or jail. This means to place all the files BIND needs to run in an isolated directory and run BIND with the chroot option. This process will make the BIND process "see" the server as existing only in its directory. I had to work with UNIX administrators to get this one done, it can be tricky.
3. File permissions should be restricted to only DNS administrators and the BIND (named) process. This is critical for any keys you have on the system. No files should have permissions allowing anyone beyond the group access to the files in any way. There is a caution to be observed here however, you must be sure that the BIND "user" has access to the files it needs to run.
4. This one is not a DISA item, but it is a good idea to set up your DNS server in a dedicated zone on the physical server PC. This takes the chroot idea a step further by isolating the DNS server to it's own zone.
5. DNS should run on it's own dedicated server. Along with this, all processes not needed for BIND should be disabled.
So, that will wrap it up for this week. I'm sure there are some items I have overlooked. Take a look at the DISA IASE DNS guide if you are interested in learning more. Next week, we'll look deeper into the DNS server configurations and how to secure a server using the configuration files.
This week I'll go over some methods to secure a BIND DNS server. As I mentioned last week, these methods all pertain to an authoritative DNS server.
These items are all from the Defense Information Systems Agency (DISA), Information Assurance Support Environment (IASE) Domain Name System Security Checklist, Version 4, Release 1.12. which can be downloaded from here:
http://iase.disa.mil/stigs/a-z.html
DISA has a very large collection of security guides to look over--they can be a great help to anyone wanting to secure their IT systems.
Back to DNS security, here are some general common methods DNS administrators use to secure their servers:
1. Do NOT allow the BIND process (named) to run as the root user. For some odd reason, BIND runs as root by default. The reason for this is that if your BIND process is taken over by an intruder then they have root access to your server. I created a "named" user to run BIND on my servers.
Note that the user for BIND should not have a default shell, to prevent someone from logging into that account.
2. Run BIND in a chroot (change root) environment, or jail. This means to place all the files BIND needs to run in an isolated directory and run BIND with the chroot option. This process will make the BIND process "see" the server as existing only in its directory. I had to work with UNIX administrators to get this one done, it can be tricky.
3. File permissions should be restricted to only DNS administrators and the BIND (named) process. This is critical for any keys you have on the system. No files should have permissions allowing anyone beyond the group access to the files in any way. There is a caution to be observed here however, you must be sure that the BIND "user" has access to the files it needs to run.
4. This one is not a DISA item, but it is a good idea to set up your DNS server in a dedicated zone on the physical server PC. This takes the chroot idea a step further by isolating the DNS server to it's own zone.
5. DNS should run on it's own dedicated server. Along with this, all processes not needed for BIND should be disabled.
So, that will wrap it up for this week. I'm sure there are some items I have overlooked. Take a look at the DISA IASE DNS guide if you are interested in learning more. Next week, we'll look deeper into the DNS server configurations and how to secure a server using the configuration files.
Monday, September 3, 2012
DNS Security
DNS is a very valuable resource for online communications. Without it, we would be dealing strictly with IP addresses. We would have to operate using host tables to link IPs to URLs. That is how it was done in the early days of the internet. Predictably, that system soon became unmanageable as the number of internet sites grew.
In future postings, I'll cover some of the measures DNS administrators take to secure their DNS servers. Some of the topics I plan to cover will be:
1. Methods to secure the server
2. Securing DNSSEC transactions
3. DNS Security Extensions (DNSSEC) to secure DNS queries/responses
I should mention that my discussion will focus mainly on authoritative DNS servers. These are servers that answer queries from "the outside world" (relative to your domain) looking for sites or services that your domain hosts.
At the possible expense of stealing my own thunder, I'll give credit to a couple of references that are of enormous help to me:
"The National Institute of Standards and Technology (NIST) Secure Domain Name System (DNS) Deployment Guide"
csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf
DNS and Bind, 5th Edition by Cricket Liu and Paul Albitz
In future postings, I'll cover some of the measures DNS administrators take to secure their DNS servers. Some of the topics I plan to cover will be:
1. Methods to secure the server
2. Securing DNSSEC transactions
3. DNS Security Extensions (DNSSEC) to secure DNS queries/responses
I should mention that my discussion will focus mainly on authoritative DNS servers. These are servers that answer queries from "the outside world" (relative to your domain) looking for sites or services that your domain hosts.
At the possible expense of stealing my own thunder, I'll give credit to a couple of references that are of enormous help to me:
"The National Institute of Standards and Technology (NIST) Secure Domain Name System (DNS) Deployment Guide"
csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf
DNS and Bind, 5th Edition by Cricket Liu and Paul Albitz
Subscribe to:
Posts (Atom)