Security
spoofedpacket.net signed (again)
Mar 2nd
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
Dec 17th
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
Dec 13th
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
Mar 24th
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
LDSOFOUND=1;
You can now run the setup script
./setup_chroot.sh
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
Dec 1st
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 (
AwEAAa1qyDcvEEsXZYvzI5TwlJks8pK95OSE
RjMtg0aN/cBfpNeyyYwX1O5zQy1G13qklxYR
CbPHbbeZkxMxfVxc3pUSDOqYtu6IBhhPTv9Z
Gwnjn6CRBdKVrkdMI5ZPJ3uwvMj9yk6a9jjg
tUZZfIRkbURa/Q75AaqB8ihQN7pU5N9Tui0i
V3eoKZrVfc5mUDATnggSw/Pk7blHKn8OWwEJ
b7Q5Uulg4fmHYSxX2sTzt5kgZxWAVbaZ5IWn
XwMJkUN7kM9Lz04exn4JmpeMpfAo3+tyDC1F
LLJVPAk4KmhDKPhiY1y9yeZxLiloYh8KvG4b
W18D465/RQRkoLufF+/6htk=
) ; key id = 15871