Posts Tagged ‘safenet’

NSD and OpenDNSSEC under FreeBSD 10 [Part 5: SafeNet HSM]

Wednesday, May 18th, 2016

This is the fifth part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

This time we’re going to integrate proper hardware HSM support in our setup — a pair of SafeNet Network HSMs (aka Luna SA).

Here is how our updated installation diagram looks like:

2016051701

Before we jump into technical details there are a couple of assumptions:

— I assume that HSMs are already configured and partitioned. HSM installation is outside of scope of this guide since it’s a lengthy and pretty time consuming process which has nothing to do with OpenDNSSEC. It also involves a big chunk of work to be done on the access federation field (different teams accessing different partitions with different PEDs or passwords). SafeNet HSM’s documentation is quite solid though, so make sure this part is completed. In our setup, both HSMs run the latest software 6.2.0-15 and there is one partition created on both units called TEST. TEST partition is activated and we’re going to create High Availability group, add both HSMs to the HA group and allow NS-SIGN to access it;

— As you might have noticed, I decided to leave ZSKs to be handled by SoftHSM. One of the things that you’ll have to keep an eye on with network HSMs is the HDD space. The way it works with SafeNet is that you have an appliance with some fixed amount of disk space (let’s say 2MB). Then you create partitions and allocate space out of total amount for each partition (by default it’s equal distribution). So let’s assume we created five partitions 417274 bytes each. Normally, storing a pair of public/private key consumes very little, but with OpenDNSSEC we’re talking about a number of domains each storing a pair of public/private keys for both KSK and ZSK. It’s very important to understand how far you can go, so you’re not surprised after several years when you discover that you run out of space.

Let’s do some basic math: one domain, with both ZSK (1024) and KSK (2048) stored on HSM, will consume 2768 bytes, so with 417274 bytes partition you should be able to handle ~150 domains. However, during ZSK or KSK rollover, another pair will be temporarily created, and although ZSK/KSK rollover shouldn’t happen at the same time and OpenDNSSEC will purge expired keys after the rollover is completed, you’ll have to consider extra 2768 bytes per domain (for a period of time defined in <Purge> stanza in kasp.xml), which leaves you 75 domains. As you can see this isn’t much. That’s why I decided to keep SoftHSM for ZSKs to save some HSM space (which is not cheap to say the least!).

One of the disadvantages of keeping both storage engines is that you’ll have one more dependency to worry about should you consider to upgrade (for example to SoftHSM2), hence the choice is yours. Another option would be to store private keys in HSM and leave public keys aside (<SkipPublicKey/> option under conf.xml), but I’ve read that it’s very much dependent on the HSM provider and could lead to unexpected results. And one more option would be to use <ShareKeys/> under kasp.xml — that way you can share the same key for multiple domains.

(more…)

How to configure vLAG on a Brocade VDX 6740T-1G switch to work with SafeNet Network HSM

Tuesday, January 26th, 2016

Caution! I deleted my previous post on how to configure vLAG on Brocade VDX 6740T-1G switch to work with SafeNet Network HSM because actually it didn’t work as it should. If you get a cached version somewhere please disregard it.

I have no idea how I managed to get bonding to operate in round-robin mode on SafeNet Network HSM:

  1. [hsm-node-1] lunash:>network interface bonding show
  2.  
  3. ———————————————————–
  4. Ethernet Channel Bonding Driver: v3.4.0-2 (October 7, 2008)
  5.  
  6. Bonding Mode: load balancing (round-robin)

Because once the appliance was rebooted the bonding mode has changed to active-backup and the whole story with LAGs became irrelevant. The primary interface started flapping again and the only way to stabilize connectivity to HSM was to disable the slave interface.

  1. [hsm-node-1] lunash:>network interface bonding show
  2.  
  3. ———————————————————–
  4. Ethernet Channel Bonding Driver: v3.4.0-2 (October 7, 2008)
  5.  
  6. Bonding Mode: fault-tolerance (active-backup)

So, back to the original subject of the post: how do you configure a LAG on Brocade switch to work with SafeNet Network HSM? The answer is — you don’t. In fault-tolerance bonding mode, when one interface is active and another one is backup (read passive), you don’t create any LAGs on the switch. All you have to do is to bring both interfaces to switchport mode access mode and ensure that VLAN and speed settings are identical. Here is how our switch config looks like:

  1. !
  2. interface TenGigabitEthernet 12/0/2
  3.  speed 1000
  4.  description -=HSM-NODE-1:ETH0=-
  5.  switchport
  6.  switchport mode access
  7.  switchport access vlan 12
  8.  spanning-tree shutdown
  9.  no fabric isl enable
  10.  no fabric trunk enable
  11.  no shutdown
  12. !
  13. interface TenGigabitEthernet 13/0/2
  14.  speed 1000
  15.  description -=HSM-NODE-1:ETH1=-
  16.  switchport
  17.  switchport mode access
  18.  switchport access vlan 12
  19.  spanning-tree shutdown
  20.  no fabric isl enable
  21.  no fabric trunk enable
  22.  no shutdown
  23. !

Now, you certainly lose link aggregation and load balancing functionalities, because only one interface will be passing traffic at a time. The slave interface comes into play only if the primary interface is down. We’re still good though when it comes to redundancy — you can disconnect the cable from ETH0 without any impact on connectivity.

On a HSM side, you don’t have many options so you follow the standard procedure: assign the IP address to the bond (network interface bonding config -ip x.x.x.x -netmask y.y.y.y -gateway z.z.z.z) and bring it up (network interface bonding enable).

To check the status:

  1. [hsm-node-1] lunash:>network interface bonding show
  2.  
  3. ———————————————————–
  4. Ethernet Channel Bonding Driver: v3.4.0-2 (October 7, 2008)
  5.  
  6. Bonding Mode: fault-tolerance (active-backup)
  7. Primary Slave: eth0 (primary_reselect failure)
  8. Currently Active Slave: eth1
  9. MII Status: up
  10. MII Polling Interval (ms): 100
  11. Up Delay (ms): 2000
  12. Down Delay (ms): 0
  13.  
  14. Slave Interface: eth0
  15. MII Status: up
  16. Speed: 1000 Mbps
  17. Duplex: full
  18. Link Failure Count: 0
  19. Permanent HW addr: 00:15:c4:n7:13:06
  20.  
  21. Slave Interface: eth1
  22. MII Status: up
  23. Speed: 1000 Mbps
  24. Duplex: full
  25. Link Failure Count: 0
  26. Permanent HW addr: 00:15:c4:n7:6a:34
  27. ———————————————————–
  28. ———————————————————–
  29. Status for eth0:
  30.         Link detected: yes
  31.  
  32. Status for eth1:
  33.         Link detected: yes
  34. ———————————————————–
  35.  
  36. Command Result : 0 (Success)
  1. [hsm-node-1] lunash:>status interface
  2.  
  3. bond0     Link encap:Ethernet  HWaddr 00:15:C4:N7:13:06
  4.           inet addr:192.168.100.42  Bcast:192.168.100.255  Mask:255.255.255.0
  5.           UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
  6.           RX packets:13479 errors:0 dropped:0 overruns:0 frame:0
  7.           TX packets:3183 errors:0 dropped:0 overruns:0 carrier:0
  8.           collisions:0 txqueuelen:0
  9.           RX bytes:1059045 (1.0 MiB)  TX bytes:446623 (436.1 KiB)
  10.  
  11. eth0      Link encap:Ethernet  HWaddr 00:15:C4:N7:13:06
  12.           UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  13.           RX packets:12670 errors:0 dropped:0 overruns:0 frame:0
  14.           TX packets:2082 errors:0 dropped:0 overruns:0 carrier:0
  15.           collisions:0 txqueuelen:1000
  16.           RX bytes:996811 (973.4 KiB)  TX bytes:300205 (293.1 KiB)
  17.           Interrupt:58 Memory:fb4c0000-fb4e0000
  18.  
  19. eth1      Link encap:Ethernet  HWaddr 00:15:C4:N7:6A:34
  20.           UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  21.           RX packets:809 errors:0 dropped:0 overruns:0 frame:0
  22.           TX packets:1101 errors:0 dropped:0 overruns:0 carrier:0
  23.           collisions:0 txqueuelen:1000
  24.           RX bytes:62234 (60.7 KiB)  TX bytes:146418 (142.9 KiB)
  25.           Interrupt:169 Memory:fb6e0000-fb700000
  26.  
  27. Command Result : 0 (Success)