Rob Gallagher
Heartbeat and IPv6
May 11th
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.
Backporting debian packages
May 6th
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.
Shatner vs Shatner vs Shatner vs Shatner…
May 1st
Quite possibly the greatest work of fiction ever, about the greatest man ever: Shatnerquake!.
It’s the first ShatnerCon with William Shatner as the guest of honor! But after a failed terrorist attack by Campbellians, a crazy terrorist cult that worships Bruce Campbell, all of the characters ever played by William Shatner are suddenly sucked into our world. Their mission: hunt down and destroy the real William Shatner.
First steps towards DNSSEC
Apr 3rd
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.
