Hunter CIS608 Blog Summary


Clearly, the bulk of my postings have been DNS related.  It is what I do and what I am most familiar with since I deal with it daily.  Except for the two-week break from DNS that is.

The entry about IT risk management is another area I am very familiar with, since that is part of my daily job as well.

The Russian network surveillance system was just an interesting article I came across, and thought it might be a nice break from DNS...

I hope this blog may be of some use to someone out there on the 'Net.  The references I have cited along the way are truly the best sources of DNS information I have come across and have provided very valuable reference to me on the job.  This was especially helpful when it came time to tackle DNSSEC--a major undertaking to say the least!

BTW, lessons learned when running DNSSEC, when re-signing your zone don't forget to update the serial number first, and don't forget to restart the server or it will not use the newly re-signed zone!  I've caught myself a couple of times wondering why my dnskey dates hadn't changed after re-signing.

I hope you have enjoyed this blog--it certainly proved to be less painful than I anticipated when I started.  Can't promise it'll keep going...

For future student bloggers, pick a topic you either like or are familiar with--it makes it easier to post weekly updates that way.

Cheers!

New DISA DNS Security Requirements Guide (SRG)

So, now that DoD DNS administrators have become comfortable with using the DNS STIG to manage DNS security on their servers, DISA has put out a new SRG to be used along with the STIG.  Here is a link to the memo that DISA sent out when they posted the new SRG:

http://iase.disa.mil/stigs/net_perimeter/other/u_dns_srg_v1_stig_release_memo.pdf

This was just released on 2 November, so I am still reviewing it to see how it affects how we run our checklists.  What I have gathered so far is that the SRG incorporates security elements from previous network SRGs to ensure that the DNS "big picture" is secure.

It also sounds like the STIG may become automated in the future, which is how many of the other DISA STIGs operate.

Here is a link to the actual SRG, which includes a very informative document, DOMAIN NAME SYSTEM (DNS) SECURITY REQUIREMENTS GUIDE (SRG) OVERVIEW in the zipped file:

http://iase.disa.mil/stigs/net_perimeter/other/u_dns_srg_v1r1.zip

This will certainly have many DoD "DNS oldtimers" pulling their hair out while we figure out how to incorporate the new SRG!

You Think Invasion of Privacy is a Big Issue in the U.S.? Check out what Russia Just Did...

So, apparently the Russian government has contracted and just activated a nation-wide online surveillance system in the country.  The intent is to stop online pedophilia, but it is capable of monitoring the activities of millions of Russians.  Vladimir Putin recently enacted a new law that may allow the system to be used for ferreting out people speaking out against the Russian government as well.  Scary times in Mother Russia...

Imagine what would happen if this took place in the U.S.  There are already many people that feel they are constantly under surveillance with the USA Patriot Act and like measures by the government.  The ACLU and citizens alike would be up in arms immediately if the American government were to try to do this.  Then again, there are those that feel it's already in place in the U.S.

Here is a link to the Infosec Island article by  Pierluigi Paganini:

Russia Deploys a Massive Surveillance Network System

IT Risk Assessment in the Military

I am a civilian employee working for the Air Force.  Part of my job is to perform recurring assessments on the systems I maintain and report the status to our IT Security Office who decides what, if any action to take on findings.  The CISO will then either decide to accept some risks or approve what is done to mitigate them.

As I mentioned in my first post we use Security Technical Implementation Guides (STIGs) provided by the Defense Information Systems Agency (DISA) to perform these evaluations.  Some of the STIGs are automated and others are simply checklists used to check a system for compliance with the STIG guidelines.

These checks are performed before a new system is brought online and recur periodically throughout the life-cycle of the system.  When we complete a review, an IT inspector goes through the checklist and verifies the findings and then a plan is made to mitigate or accept the risks.

As another layer of verification, organizations are inspected by an outside agency that also runs the the STIGs on systems. 

This multi-layer risk management system has proven very effective.

Here is the link to the DISA STIGs that are available to the public:

http://iase.disa.mil/stigs/a-z.html

DNSSEC - Part 4

This week, we'll look at some of the maintenance tasks involved when running DNSSEC.

1.  Periodic zone re-signing-this will most likely be dictated by a parent zone or organization.  The reason for re-signing is that the longer signed records are available to the public, the greater the chance that your private key components could be cracked.

2.  Key rollover-both the KSK and ZSK should be rolled over to new keys periodically.  This is again due to records being available that may lead to the private keys being cracked.  NIST recommends a 60 day (or so) rollover period for the ZSK and yearly for the KSK.  The ZSK is more exposed to the public, hence the shorter rollover period.

There are two methods for key rollover; double-signing and pre-publish.  Double-signing involves creating a new KSK, ZSK or both and signing with both the old and new keys.  Then after waiting at least a full TTL, re-sign the zone using the new key(s).

Pre-publishing is sending the new public key (s) to your parent and signing with the new key(s) after ensuring the parent has your public keys.

3.  Key management-again, the private keys should be kept secure and offline if possible.

4.  Firewall requirements-DNSSEC greatly increases the size of packets that come back in a query response.  See below:

A normal (non-DNSSEC) dig query for www.fbi.gov.  Note the size of the CNAME line.

;; QUESTION SECTION:
 ;www.fbi.gov.   IN A
 
 ;; ANSWER SECTION:
 www.fbi.gov.  300 IN CNAME www.fbi.gov.c.footprint6.net.
 www.fbi.gov.c.footprint6.net. 230 IN A 198.78.202.118

Now, a DNSSEC-enabled gig for the same record.  Again, pay attention to the
CNAME line.

;; QUESTION SECTION:
 ;www.fbi.gov.  IN A
 
 ;; ANSWER SECTION:
 www.fbi.gov.  259 IN CNAME www.fbi.gov.c.footprint6.net.
 www.fbi.gov.  259 IN RRSIG CNAME 7 3 300 20121211184410 (
     20120912184410 58969 fbi.gov.
     wdRHrnOp53u8b4fs1vhV5YdAChNO/dsFQ3dxgyYoWKox
     nbA8Mez4q7hE0lWTM7JFqNBjF+7U2YKYPkPbMZHa1U0I
     2tbU690IYs3HVxONoiq61jPMz9Ox2693ZFNCl3xtuBCG
     +UWzXpwXFUcgTWz9qefx2kA/7CDZnMqnTq/nKSQ= )
 www.fbi.gov.c.footprint6.net. 189 IN A 198.78.202.118

As you can see, the CNAME that came back from the DNSSEC-enabled query was much larger than the non-DNSSEC-enabled answer.  This can be an issue with firewalls that are not configured to allow packets larger than 512 bytes to pass through.

Another potential firewall issue is that DNSSEC requires both UDP and TCP ports 53 to be opened.

That about covers maintenence.  Next week will be a surprise for us both, since I am about done with DNSSEC...

DNSSEC - Part 3

So, now we'll look at how to enable DNSSEC on a BIND authoritative DNS server and specifics on the KSK and ZSK this week.

Here are some steps required to get DNSSEC up and running:

1.  Enable DNSSEC -this requires a simple line dnssec-enable yes; be added into the named.conf file.

2.  Generate the KSK and ZSK public/private keypairs - this requires pre-planning as to what algorithm to use, what the key size will be and the names of the generated keys.  NIST recommends the KSK be 2048-bit and the ZSK be 1024-bit. RSASHA1NSEC3 is a very commonly used algorithm along with the NIST recommended key sizes.  The UNIX command for generating keys is dnssec-keygen.  Details on this command can be found in the NIST Secure DNS Deployment guide or a look at the dnssec-keygen man page.

3.  Plan for and Implement Secure Storage for the Private Keys - dnssec-keygen will create both the public and private keys.  Their names will be K"keyname".+xxx+yyyyy where xxx is a number representing the algorithm and yyyyy is a system generated number for the key.  Additionally, the two generated keys end in .key for the public key and .private for the private key.  So if we create a key, bubba using RSASHA1NSEC3, the two keys will be:

Kbubba.+007+12345.key

Kbubba.+007+12345.private

Remember the 12345 will be a system generated number, but the public and private keys will match.

It is a definite best  practice (and good idea) to keep the private keys stored off line.  Be it removable media of some sort, or a secure storage device they should be protected.

4.  Send KSK Public Key to Parent - this will establish the chain-of trust we discussed last week.

5.  Sign the Zones - this is done using the command dnssec-signzone.  In order to do so, your private keys must be pulled out of storage and put on the system since both the public and private keys are required to sign the zones.  Here also, for more details on the dnssec-signzone command, consult the NIST guide or man pages.

So, that will do it for this week.  Next week, we'll look recurring DNSSEC maintenance tasks required once you are up and running, cheers!   

DNSSEC – Part 2

Last week we took a quick overview of what DNSSEC is and what it does and does not do. As promised, this week we'll take a quick look at how DNSSEC works.

As I stated last week, DNSSEC is intended to secure the DNS query-response process. It ensures you are getting the correct answer (or verified non-existence) from the authenticated DNS server that is truly authoritative for the record requested. There is a caveat here, the querying server must be DNSSEC-enabled in addition to the answering server in order for this process to work properly. The DNSSEC authenticated reply from an authoritative server is known as a signed response.

DNSSEC is able to do so by establishing a chain-of-trust between a DNS server and it's parent servers. For example if the .gov servers hold DNSSEC records for fbi.gov, then there is a chain-of-trust established between the .gov and fbi.gov authoritative DNS servers.  When a zone is DNSSEC signed without a chain of trust, that zone is known as an island of trust since it is operating on its own as far as DNSSEC goes.

DNSSEC performs these authentication and chain-of trust actions by using two different types of asymmetric keys (asymmetric keys are those having two components; a public key and a private key) a Zone Signing Key (ZSK) and a Key Signing Key (KSK).  The ZSK is what is used to sign a zone--specifically the private component of the ZSK.  The KSK performs two functions:  the public key is sent to the parent zone DNS server to establish the chain-of-trust, the private key is used to sign DNSKEY key sets that DNSSEC generates when signing zones.

If you'd like a deeper look just google "DNSSEC", or as always check out the NIST Secure DNS Deployment Guide I have referenced in past posts.

Well, that is probably enough to keep your head spinning until next week when we'll go still deeper into the ZSK, KSK and other DNSSEC operations...

DNSSEC - Part 1

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!

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.

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!

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.

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

First Post

So as it says in my profile, I am new to blogging--that said there won't be any bells and whistles here. One of the roles I fill in my current position is that of a DNS administrator, so many of my posts will most likely be DNS related. This week, I came across a recent DDoS attack that brought AT&T's DNS servers to their knees. Here is a link to an Infoworld article with details of the attack:

AT&T DDoS Attack

In an odd twist of fate, coincidence or whatever I also came across an AT&T white paper on how to keep a DDoS attack from killing your network:

AT&T DDoS Defense


I'll leave that one for now...