spoofedpacket

I’ve been playing around with heartbeat quite a bit recently. It’s quite a mature piece of software with some cool features, however the documentation is bit unstructured and lacking in some areas, especially where IPv6 support is concerned. Heartbeat *supports* IPv6 address takeover through the IPv6addr resource but it’s not exactly clear on how you go about setting it up.

Anyway, after reading through some forum posts, here is a sample haresources file that will give you IPv4 and IPv6 address failover. We are using eth1 as our primary network interface:

my.failover.address 193.1.219.93
my.failover.address IPv6addr::2001:770:18:2:0:0:c101:db5d/64/eth1

The important thing is to specify the IPv6 address fully, ie: pad it out with 0’s, no :: shortcuts!

With v6 support recently added to IPVS, it should now be possible to do full IPv6 failover and load balancing.

rob IPv6

Sometimes, you need a newer version of a package than is available in your debian/ubuntu install.

There’s a number of ways to do it, for example using tools such as Prevu, but here is the step by step process.

We are going to backport the latest version of Unbound from Ubuntu Jaunty (1.2.1 at the time of writing) to an Ubuntu Hardy system. As a prerequisite, we need the build-essential package installed as we are going to compile some software, we also need the fakeroot package in order to build debian packages:

aptitude install build-essential fakeroot

Firstly, we need to enable the Jaunty source repositories in our /etc/apt/sources.list file, and comment out the Hardy source repositories (any of the other lines beginning with deb-src). You should run aptitude update after this step:

deb-src http://ie.archive.ubuntu.com/ubuntu jaunty restricted main multiverse universe

The next step is to gather what we need to compile Unbound, the build dependencies:

apt-get build-dep unbound

Now, we retrieve the “debianised” source code for unbound:

apt-get source unbound

Then cd into the unbound source directory (it should be something like unbound-1.2.1) and run the following command:

dpkg-buildpackage -rfakeroot -b -uc -us

This will compile unbound and build the debian package in one go. The resultant package is deposited in the parent directory. You can install it by doing:

dpkg -i ../unbound_1.2.1-0ubuntu1_i386.deb

If all goes well you should be able to install this package on other i386 Ubuntu Hardy systems as needed.

rob Ubuntu

Quite possibly the greatest work of fiction ever, about the greatest man ever: Shatnerquake!.

rob Books, Friday, Funny

I recently began deploying DNSSEC within HEAnet. Things are at an early stage, but I’m hoping to have some signed zones up and running in the next few months.

For testing, I wanted to find a practical application of DNSSEC, rather than simply stating “now our zones are secure against attack A, B and C”.

RFC4255 provides exactly this, with automatic verification and trusting of SSH host keys through a combination of the SSHFP record type and DNSSEC validation. This removes the need to maintain a known_hosts file on each client, key fingerprints can simply be distributed through DNS.

I started by generating our zone signing key (ZSK) and key signing key (KSK) for the secure zone, login.heanet.ie. These are 1024bit RSASHA1 keypairs.

 mkdir /etc/bind/keys
 cd !$
 dnssec-keygen -r /dev/random -a RSASHA1 \
  -b 1024 -n ZONE login.heanet.ie
 dnssec-keygen -r /dev/random -f KSK \
  -a RSASHA1 -b 1024 -n ZONE login.heanet.ie

Then, I imported the trust anchor (KSK public part) for the zone into the DNS resolver. We are using Unbound but BIND etc. configuration is somewhat similar.

cp Klogin.heanet.ie.+005+61342.key /etc/unbound/anchors/login.heanet.ie.anchor
...
vi /etc/unbound/unbound.conf
...
#
# login.heanet.ie test signed zone - robertg@heanet.ie 20090309
#
trust-anchor-file: "/etc/unbound/anchors/login.heanet.ie.anchor"
...

To prepare the zone for signing, I published the ZSK and KSK public keys at the apex of the zone, ie: after NS records but before any other records are defined.

@                       IN      NS      ns.heanet.ie.

; DNSSEC public keys
$INCLUDE                /etc/bind/keys/Klogin.heanet.ie.+005+01530.key  ;ZSK
$INCLUDE                /etc/bind/keys/Klogin.heanet.ie.+005+61342.key  ;KSK

; hosts
charlene                IN      A       193.1.219.75
charlene                IN      AAAA    2001:770:18:2::193.1.219.75
charlene                IN      SSHFP   1 1 d343493a92fdd26281dddc26e90440e5504c3b1a
charlene                IN      SSHFP   2 1 4fad90afa04a6b62371091662f88685822b07ebb

Now, to actually sign the zone! I signed the RRsets in the zone with dnssec-signzone and the ZSK and KSK keypairs we generated earlier. This produces a signed version of the zonefile, of the form zonefile.signed. The KSK (61342) is used to sign the keys we entered at the apex of the zone earlier, and the ZSK (01530) is used to sign all the other records in the zone.

dnssec-signzone -r /dev/random -o login.heanet.ie \
-k /etc/bind/keys/Klogin.heanet.ie.+005+61342.key \
login.heanet.ie /etc/bind/keys/Klogin.heanet.ie.+005+01530.key

Then, I loaded the .signed file into the authoritative nameserver.

zone "login.heanet.ie" {
        type master;
        file "pz/forward/login.heanet.ie.signed";
};

After doing this, it’s a good idea to check for any errors in name server log.

As a first test, I made a DNSSEC query to the resolvers. It should follow the chain of trust and securely resolve the query. The “ad” - authenticated data - flag in the flags: section of the dig output confirms that the zone data is signed and has been verified as authentic. The +dnssec option sets the DO (DNSSEC OK) bit on the query and the +multiline option is simply used for readability purposes.

dig @resolver0.heanet.ie charlene.login.heanet.ie +dnssec +multiline

; <<>> DiG 9.5.0-P2 <<>> @resolver0.heanet.ie charlene.login.heanet.ie +dnssec +multiline
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42200
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;charlene.login.heanet.ie. IN A

;; ANSWER SECTION:
charlene.login.heanet.ie. 3600 IN A 193.1.219.75
charlene.login.heanet.ie. 3600 IN RRSIG	A 5 4 3600 20090429144034 (
				20090330144034 1530 login.heanet.ie.
				dw8qCGcHEBA8kSfv3CTr7sTM7FEJvoGyY8tz9bEgIsNK
				adSgG3eUfHIQ5nMFVYvg7/MEXLfhUyXmByNjPuuMhfi0
				mvX4GV0z+MqIRfVBb6bH8kPBlAjdXisny4e8rhrheRwu
				P8FyONy88cyy5OqTattjzz8bBtMevZo4wN/KfQs= )

;; AUTHORITY SECTION:
login.heanet.ie.	3600 IN	NS ns.heanet.ie.
login.heanet.ie.	3600 IN	RRSIG NS 5 3 3600 20090429144034 (
				20090330144034 1530 login.heanet.ie.
				C7C54YAIMVqp9UJfrrM56dRd2U8OB+zkxHV2G2YN0QsR
				7XFZHVcBEjw/9l8r1E6yiRIyAx2P3XGWT/tAvYvssAG8
				p143UAn29Gqnibf5mGzhRQFGN/huCdmFSIL7yK2jinhA
				rw/ZgOrVkBnWiGYNRe4BWtIhkHbcVYZ6roWXlo8= )

;; Query time: 2 msec
;; SERVER: 2001:770:f8::c101:ba02#53(2001:770:f8::c101:ba02)
;; WHEN: Wed Apr  1 17:07:12 2009
;; MSG SIZE  rcvd: 436

Now to test the signed SSHFP records. On the client, I added the following to resolv.conf.

options edns0

Also, I edited ~/.ssh/config and added this line in the Host section

VerifyHostKeyDNS yes

When ssh’ing to a the machine with signed SSHFP records, the user should not be prompted to accept the host key, even if it is “unknown”.

ssh -v heanet@charlene.login.heanet.ie
OpenSSH_5.1, OpenSSL 0.9.7j 04 May 2006
...
debug1: found 2 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_rsa_verify: signature correct
...

Presto! No known_hosts file. Profit! etc.. No need to maintain host keys across multiple clients, simply distribute your SSH fingerprints through DNS.

$ ls -al /home/rob/.ssh/
total 16
drwx------  2 rob  users  512 Mar 31 14:35 .
drwxr-xr-x  3 rob  users  512 Mar 31 14:15 ..
-rw-------  1 rob  users  613 Mar 31 17:23 authorized_keys
-rw-r--r--  1 rob  users  120 Mar 31 14:35 config

Of course there are a number of issues. I haven’t gone through the required key rollover and resigning processes, however these are reasonably straightforward and can be automated with freely available tools.

rob DNS, Networking, Security

With the addition of a leap second on December 31st, 2008 went on for a bit longer. This was interesting for me as we operate a pair of stratum-1 time servers, ntp1.heanet.ie (MSF-synched) and ntp2.heanet.ie (GPS-synched), both of which are in the ie.pool.ntp.org rotation. ntp2.heanet.ie maintained accuracy throughout, however ntp1.heanet.ie drifted by 1 second for a short while. This is to be expected however, as the MSF signal does not pre-announce the leap second.

Before Christmas, I began monitoring traffic to and from both servers in anticipation of some funky patterns in or around new years. We did get a surge of traffic, just not in the way I was expecting…

On new years eve, ntp2.heanet.ie suddenly became extremely popular - receiving 1.34Mbit/s of traffic at it’s peak. ntp1.heanet was slightly less in demand, spiking at 721.06Kbit/s. Both boxes reached their highest traffic levels since we put them into service at the end of November. However, from the graph it appeared that the traffic spike arrived several hours before midnight.

Drilling down, the largest amount of traffic was seen by ntp2.heanet.ie in or around 18:00 on the 31st with further spikes at 20:00, 21:30 and just before midnight. The only conclusion I can come to is that a large amount of people were frantically synching their clocks before heading out to the pub

Further reading: Dave Malone collected quite a bit of information the last time a leap second appeared.

rob NTP