Friday, January 17, 2014

How to secure AXFR transfers using encryption via SSH

Zone transfers and the transmission of the zone database information, is a security matter that should not be taken lightly.


We go to great lengths of building a named.conf cfg,  and securing who can  execute a AXFR,  but we rarely  do anything to secure the contents of the AXFR from any MiTM.



"Security is only as strong  as  our weakest link" ;  & truly applies here!


Take this gTLD nameserver  { 128.16.5.32 } &  for the int  gTLD zone. It's was found to be  open to the world for AXFR ( zone transfers )  DEC 16 2013





This allows for any individual to harvest potential targets. Maybe not so much or a risk to a gTLD NS,  since it lists authoritive NS for various domains with in that gTLD, but how about that enterprise business that doesn't want to show it's hands, & expose information to the world as to what hosts/node is in it's zone database.  It also open up your NS up for abuse & other security risk.

note:  A simple email was sent to the contact listed in the SOA, making them aware of their exposure .





So back to our  environment , to secure  our AXFR from peering eyes, we can encrypt the  zone-transfer via  a simple ssh-tunnel between SALVES and MASTER. This will provide a simple means for  securing  the actual zone resource-records, during the AXFR operation. Depending on your security policy and posture , you can  mandate various cipher for the execution of this  tunnel.
( e.g  3des AES BLOWFISH etc..... )


To do this tunnel, we will need to make some changes to our  configuration files on the DNS name-servers.

note: There's no changes required from within  any zone-database files


1:

1st we need to set the slaves to use a loopback addressed interface on our  master server. This address will be present in our ssh tunnel. You should validate that the listener is operative on the loopback address at the master ;

( using lsof )



( conducting a AXFR on the master,  using our 127net interface )





2:

A ssh-key must be shared between the  master and slaves for automation of the logins. We want to avoid having to manually insert any passwords. This key should be secured between the master and all slave(s). And installed in our authorized keys file.




3:

On the slave, you will need to instruct it to use a SSH tunnel for connection to the master NS. I'm using a static defined ssh_config  file on my knot_slave  that assist with the SSH tunnel setup

( e.g contents of a  basic file  )


cat /etc/knot/ssh_config  master


User root       
HostName master
CheckHostIP no   
StrictHostKeyChecking no
Compression  yes
ConnectionAttempts  4
LocalForward 53 127.0.0.1:53
IdentityFile /root/.ssh/id_rsa
Port 2022

note: This file relies on a share key between the slave and master for hands-off automated  logins, also these hosts sits within the dangerous internet, so sshd is running at the masters & on port 2022 and is also  protected via a firewall. This would provide us  protection from any script kiddies that are probing  port 22/tcp and trying to brute-force/dictionary attack our  accounts.

You have host of means to secure the ssh access using any of the following;  iptables, firewalls, sshd,etc.....   I highly recommend that you pick one method and secure it.


4: So on the masters& slave DNS NS you will have something of the following in our NS configuration files. These entries are from a knot name-server btw.

( a sanitized version of my  knotd-master & slave conf file for this blog  )




# cat master.conf
system { storage "/etc/knot";
}
interfaces { my_interface { address 127.0.0.1@53; } second_int { address 1.1.1.254@53; }
}
log { syslog { any notice, warning, error; }
}


#keys {  key0.blog.hyperfeed.net  hmac-md5 "Kyn1C/2NwR79F7wiAhPaJxWuCHWSzfzR95C9pgwAtp3N5hmLZAogusNmlyWFMN6Bdm/Chz9tczDKDW3Mrnn3uQ==";  }



remotes { 

slave1 { address <public_address_ofslave>@53; }
loopback { address 127.0.0.1@53; }

 }

zones { dnssec-enable on; dnssec-keydir "/etc/knot/key/blog.hyperfeed.net";  blog.hyperfeed.net { file "blog.hyperfeed.net"; xfr-out slave1,loopback; notify-out slave1; } }



log {
  stdout { any info, notice; }
  stderr { any debug, warning, error; }
  syslog {}
  file "/tmp/knotd.log" { any all; }
}



and


system { storage "/etc/knot";
}
interfaces { eth_int { address <x.x.x.x>@53; }
}
log { syslog { any notice, warning, error; }
}

#
remotes { master { address 127.0.0.1@53; } }
#
#
#

zones { blog.hyperfeed.net { file "blog.hyperfeed.net"; xfr-in master; notify-in master; } }

log {
  stdout { any info, notice; }
  stderr { any debug, warning, error; }
  syslog {}
  file "/tmp/knotd.log" { any all; }
}


And finally, you will need to test the AXFR manually  from the  slave & monitor the logs on the master. Do this after  you have established the ssh tunnel.


AXFR request conducted from the my slave;



knotd.log on master showing a AXFR and via the  client at our 127net address;





Okay so this is how you secure a AXFR zone database transfer  & with simple encryption. The same principles would be applied for bind named or anything other DNS server package that you run.

The final activity that you would need to build is a check script that validates the ssh tunnel is establish and if not, than  restart the  ssh -F  for the tunnel.

note: Their used to be a opensource ssh check package but my investigations shows it hasn't been maintain nor  would it work in this case.

( example   a basic  shell script on the slaves )


#!/bin/bash
#   
###########################################################################
#
#  ########     CHECK SCRIPT  EXECUTED VIA CRONTAB  EVERY  min */1 ##########
#                                              kfelix <at> socpuppets  <dot>   com                                          #
##########################################################################
#
DATE=`date +%T_%D`
#
#  this variable would be set to your  master dns-server ip_address or VIP if behind a VIP
#
MASTER=1.1.1.1
#
#
#
CHK=`lsof –nP   -i | grep $MASTER:2022 | awk ' { print $2 }' `
#
#
#
if [[ -n "$CHK" ]] ;
   then 
     echo “ We have a tunnel no action required” ;
    
   else

     echo “ OMG the tunnel is not up, I will restart now & send a notice to my OPS team  “

       ssh -f -N -F /etc/knot/ssh_config $MASTER  ;
   
       mail –s “ SSH TUNNEL $HOSTNAME  RESTABLISHED  $DATE”  noc@mydomain.com
   fi

   
In conclusion,  you could also craft  site2site vpn between the DNS-servers. This would require more added resources such as firewall and might not be as  easy to implement.

Other solutions that I have used, have based on  deployment of OpenSwan  Ipsec vpns,  running on top of the  DNS name-severs directly. Once again this might not be as easy to implement, and depending on the based OS Open/StrongSwan might not be supported.

Since most big public facing name-servers are using UNIX/LINUX,  and ssh fits in quite easily. The tunneling of our  AXFR &  thru these ssh tunnels are effective and easy to deploy.

One other thing that should be pointed out, The NOTIFY from the master ( if enabled ) could be encrypted over the tunnel or not. The NOTIFY doesn't  proposed as much risk outside of telling the salve that the zone information has changed  for zone xyz and the SOA serial#.


  • It's your call on how much of a risk that proposed during a AXFR and if the requirement for securing the notifies. 


  • Also TSIG is useless in this process, since TSIG does NOT hide or encrypt any part of the data.


  • I hope this post become handy for any one hosting  multiple zones like in a TLD or ISP environment.


  •  DNS is a protocol that I've been working with for at least  17+ years and security has never been fully implemented in this internet application
Another ideal that I entertain many many years ago, and deployed with bind; "  was a script that took the  NOTIFY from the master, and conducted a remote ssh cmd execution to build the tunnel and then refresh the zone in question via rndc ".  I found that it worked , but it was quite messy.

It would be nice if  the folks at ISC or knot would provide hooks into the current name-servers for the trigger or script execution upon receipt of a  NOTIFYs.  This would allow you to easy run thru a series of  tasks  and executions, based on the NOTIFY.

YMMV I hope this shed one ideal of securing AXFR zone-datebase  information & specially for slaves that are situation external and require transfers thru the untrusted INTERNET




Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(  @   @ )=
          o
       /     \

No comments:

Post a Comment