spoofedpacket.net signed (again)

For real this time :)

My previous attempts at signing spoofedpacket.net fell into disrepair and the zone expired soon afterwards, since I was doing everything manually. However, the whole lot is automatically managed by OpenDNSSEC now, apart from the KSK rollover of course. But there are some clever things you can do to fix that, with the DelegationSignerSubmitCommand.

So here’s the current trust anchor for spoofedpacket.net in DNSKEY format, and in
DS format.

Unfortunately, joker (my registrar) don’t appear to be accepting DS records at this point. So neither of the above are in the wider DNS even though .net is now signed. However, I did register mechazawa.net with godaddy, who are currently accepting DS records through their somewhat clunky interface.

Stub/local zones and DNSSEC in Unbound

I have a couple of local DNS zones on my home network that are served from a BIND running on the same machine as my Unbound resolver. It listens on a different address, so Unbound, being the default resolver for the network, is configured to forward all requests for that particular zone to BIND.

This has worked fine, until I enabled the signed root in Unbound. Suddenly, the entire local zone was being treated as bogus, since, obviously, it appears nowhere in the root. This was manifested as SERVFAIL responses and general badness on the network – including my NAS losing it’s DHCP address whilst I was watching an episode of Full Metal Alchemist: Brotherhood….not good.

After scanning down through the sample unbound.conf, a simple solution presented itself:

 domain-insecure: "localdomain"

This tells unbound to put up with the fact that a particular domain may be bogus/insecure, and life goes on. It could be argued that it’s not a good idea to let some domains be treated differently than others when it comes to DNSSEC, but I think it’s good that the developers of Unbound had the presence of mind to include a solution to this particular corner-case.

exim vulnerability

Here’s something I haven’t seen in a while, a remotely exploitable root hole.

Debian and Ubuntu ship exim as their default MTA, so there could potentially be a lot of vulnerable machines out there.

The fixes are detailed here. Both Debian and Ubuntu have since released updated packages that fix (one part of) the vulnerability, so it would be a good idea to do a quick “aptitude dist-upgrade” if you run either of these OSes.

Setting up scponly

In the past, if I wanted to create a restricted account for a user, to upload files via scp/sftp for example, I normally setup rbash with a defined set of commands. However, it’s possible to break out of an rbash environment quite easily.

Recently, whilst setting up an account for one of the Eirtakon guys to modify their drupal install, I decided to give scponly a whirl. This is a restricted shell that, as the name implies, only allows access to scp and sftp. It also provides a chroot mode (scponlyc) to lock users into a specified directory hierarchy, which I configured for this particular user.

Installation on Debian is simple:

 aptitude install scponly

To enable the chrooted version of scponly, do:

dpkg-reconfigure -plow scponly

Unzip the chroot setup script and make it executable

cd /usr/share/doc/scponly/setup_chroot
gunzip setup_chroot.sh.gz
chmod 755 setup_chroot.sh

If you are on a 64 bit system, scponly is basically broken out of the box. You need to do a couple of things to make it work, the first is to apply this diff to setup_chroot.sh, it adds /lib/ld-2.7.so to the LDSO_LIST variable.

--- setup_chroot.sh     2010-03-24 18:53:15.000000000 +0000
+++ setup_chroot.sh.busted      2010-03-24 18:52:24.000000000 +0000
@@ -79,7 +79,7 @@
 #      we also need to add some form of ld.so, here are some good guesses.
-LDSO_LIST="/lib/ld-2.7.so /lib/ld.so /libexec/ld-elf.so /libexec/ld-elf.so.1 /usr/libexec/ld.so /lib/ld-linux.so.2 /usr/libexec/ld-elf.so.1"
+LDSO_LIST="/lib/ld.so /libexec/ld-elf.so /libexec/ld-elf.so.1 /usr/libexec/ld.so /lib/ld-linux.so.2 /usr/libexec/ld-elf.so.1"
 for lib in $LDSO_LIST; do
        if [ -f $lib ]; then

You can now run the setup script


This creates a chrooted user and sets up the necessary environment.

Now set up /dev/null:

 cd ~scponlyuser
 mkdir dev
 cp -a /dev/null dev/

For a 64 bit system, you need to copy across a few more supporting libraries into the chroot:

 cd ~scponlyuser
 cp -p /lib/libncurses.so.5 lib/
 cp -p /lib/libncurses.so.5 lib/
 cp -p /lib/libdl.so.2 lib/
 cp -p /lib/libc.so.6 lib/
 mkdir lib64
 cp -p /lib64/ld-linux-x86-64.so.2 lib64/

To restrict the user to only the path I want them to see, I set their home directory to /home/scponlyuser//drupal. The // has the effect of dropping them into that particular directory once they get chroot’ed, which is /drupal in the chroot environment.

I also wanted to let them have access to /var/www/eirtakon.com/drupal, but without symlinks or other nonsense. This can be done with the bind option in mount:

 mount -o bind /var/www/eirtakon.com/drupal /home/scponlyuser/drupal

To test it out

 sftp scponlyuser@longcat.spoofedpacket.net

spoofedpacket.net signed

I recently signed spoofedpacket.net, here’s the DS sets:

  spoofedpacket.net.      IN DS 15871 5 1 6D6B3C370091ECF38D81B2D91B54C7B2EB6D47E6
  spoofedpacket.net.      IN DS 15871 5 2 41D36F7DEC5827F650E772DE1DA33A219B3B994757DDF763830EBC12 E2DCEC80

And the keysets:

  spoofedpacket.net       604800  IN DNSKEY 257 3 5 (
                                        ) ; key id = 15871