DNSSEC recursive servers by socpuppets, made easy as 1 2 3 4 5

1st let look at what DNSSEC offers

DNSSEC advantages

1: The owner of the signed zone information, can build confidence in his end-users, that no part of the response or data was compromised

2: A small performance penalty, but  a major security enhancements for the dns systems in whole

3:  The local clients are protected from a hijacked response 
( poisoned responses )

DNSSEC dis-advantages

1: The signing of zone data can be complex,  and intimidating for the 1^st time user

2: It's easy to "DoS"  your domain  if you have problems or make a mistaken ( been their.... done that :(   )

3: Not all systems within  the DNS levels  uses DNSSEC 
( resolvers, tld, ccTLD, etc…..  trust-points    ......aka trust-anchors... )

4: Firewalls might restrict or block large UDP response 
( lack of EDNS0 support  or improper configure local systems   )

5: A firewall might not be open for dns 53/tcp 
( the old habit of restricting  tcp/53 only for AXFR and  TSIG  between authoritives pairs .... bad practices & improper configured local systems ! )

6: our trust-anchors maintenance,  could be easily overlooked and doesn’t scale very well when hiearchrial levels of trusts are not chained 
( island of trust-points boundaries exists  )

7: DNSSEC is greatly mis-understood by the general population, and poorly implemented 

8: Not all DNSSEC servers understands all alogrithims 
( NSEC3 issues )

9: Changing to a new registrar & dnssevers,  could be problematic if you depend on DNSSEC

10: Older DNS servers did not fair well with response over 4K bytes

11: IPS/DDoS mitigation gear might mistakenly block large UDP response and/or udp fragments which is commonly seen in 1400+ bytes response sizes

( they assume it's part of an attack.... a lot of false positives  )

12: DNSSEC is not very well adapted on all corners of planet earth due to all of the above and lack of experience by domain administrators 
( the issues of  island of trust boundaries again  )

                              

13: Most larger ISP are ignorant of DNSSEC,  and of  the value it offers, so the large massives of end-users have no protection afforded by DNSSEC 

The two following slides shows  what a DNSSEC trust-point boundary and how the chain is broken per-se

In each of the above examples, we have a non contiguous  hierarchical  systems  & with regards to the DNSSEC protocol from the root to the subzone level ( see the red ovals... these  break the chain )

We can remediate some oft this via trust-anchors to some degree,  but that doesn't scale very well.  ( your only as strong as your weakest link )

fwiw: All "dot" root-servers are DNSSEC enabled for well  over 2+ years now  reference :  http://www.root-dnssec.org/

Okay now let's look at a bind9 recursive name-servers,  and with us adding the ability for DNSSEC for  a local resolver ;

1:

Ensure you should have the the correct system time.  A stratum 3 time-source or  better imho.

I never trust  the ntpd daemon  alone , and prefer using the ntpadate tool or a regular interval. We typically  executed ntpdate on a regular interval &  against a stratum  external time reference. 

e.g 

( update to 2 fictious ntp sources  via a cron job  every @  59mins on the clock)

59 * * * * /usr/sbin/ntpdate -b  1.1.1.1  2.2.2.2  > /dev/null 2>&1

With ntpdate and the <-b> option,  you will always step the time  vrs the slower skew time updates. A interval of 5mins seems to be sufficient on systems that don't managed ntpd and the correct time properly. Every hour would be my extreme interval imho

2: 

Install the trust anchor from a known secured site using a HTTPs enable website 

e.g

https://www.iana.org/dnssec

Do not use dig, unless you  compare the output to a known good  sources

e.g ( very bad without any validation )

dig +short +noall +answer . dnskey  | grep -E -v '^($|;)'

3:

 Modify the named.conf file with the following;

include "/etc/bind/bind.keys";

and touch the following file in your bind directory;


touch /etc/bind/managed-keys.bind

4: 

Enable validation within your named conf options ;

        dnssec-enable yes;
        dnssec-validation yes;
        managed-keys-directory "/etc/bind";

5: 

(optional) 

enable the logging channel for dnssec in your named.conf

logging {
  channel logdnssec {
    severity info;
    syslog local7;
    print-time yes;
    print-severity yes;
    print-category yes;
    
  };

category  dnssec  { logdnssec; };

};

After you have made the above configurations changes, you must restart or reconfig the named process;

rndc reconfig

rndc reload

or

pkill -HUP named

Cool means for testing DNSSEC

1: Using the unix dig command & with the dnssec option;

e.g

dig +dnssec isc.org @8.8.4.4 dnskey

and


dig +dnssec +multiline -t ns com. @127.0.0.1 | more

2: if your lazy, you can use the versignlabs link below for external testing on authoritive DNS servers:)

http://dnssec-­‐debugger.verisignlabs.com      

3: Theses site also has some good checks & tools

http://www.dnssec-tools.org/download/#gotoDNSSEC-Check

http://viewdns.info/



And here's some misc information that might come in handy

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   O )=

          o

       /     \

ASA failover using a port-channel

For the cisco ASA,  you can achieve a better  redundant failover link configuration  in a  single or multi context mode by using a port-channel.

By aggregating 2 links together, you  provide redundancy and  helps ensure the  failover link is always up and not disturb

In this post, we will look at the basic configuration;

1: Here's the ports that was used on a ASA5558

Notice we are using LACP active mode.


2: The ASA will create the virtual port-channel automatically so you have nothing todo here ;

3rd: We create the  failover cfg for both the primary and secondary units;

note: the secondary unit has the same above cfg but with the wording "failover lan unit secondary"


Finally we validate the cfg and port-channel status and lacp

And the failover state;

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   $   $  )=

          o

       /     \

Passwords and more passwords

In this blog, I want to speak  briefly about passwords,  but not my usual with regards to strength, but with vaulting the passwords for later recovery.


Take this recent case. I had a domain up for renewal,  but the mail admin  contact was disabled. I 've been trying over the last 3 weeks, in attempts to recover the password.


Guess what ?  I had the wrong account information

So sitting here drinking my San Miguel beer got me wondering.

How many electronic accounts do I really  have ?


2x credit card acounts
5x bank/saving accounts PIN/act#,etc....
3x IRA accounts
A few  email accounts ( about 6x non job related , and 3x job relate  btw one of those I can't recall that password :(  )
2x  googlevoice  numbers
2x voice-mail systems passcodes
numerous router/switch/ips/firewalls ( so many that I can even recall of these )
1x alarm code
4x access code
1x itunes store
1x androd store
5x vpn accounts
3x dns-registrar counts


and the list goes on and on .....etc...

I accounted over 64 unique accounts/password/pins  in my electronic daily madness. I'm sure I missed a few btw, that I completely  forgot about & just like with with my domain registrar .

Not all are the same,  nor uses the same "Password criteria". And not all have the same password recovery criteria or methods.

Take this for example, a new bank account that I just open, has a password criteria that matches  any of the following;

note: you have to laugh at 1st line ( see arrow ) & with  the min of 4  characters and specially when the bank brags about taking security seriously :)



So with so many rules, acounts, names,etc........ just how do we manage our username/password details?

• Do we deploy a kee-pass type of approach , & the one master-key that give us access to all of the keys on the key-rings?

• How about  the nuclear submariners missile launch control method ( the two keys approach) ?

• Help & aids from a Biometrics solution ?

• A electronic safe-deposit box?

• Do we burying or information outback under a brick,  or like a squirrel buring a nut? 

                                       

                                        ( will we even remeber where we buried it at ? )

In our modern day and electronic ages, we have so many functions in our everyday life that revolves around a login/password.And this is not going to  get easy?

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \