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...