It’s been a while…

It’s been a while since I updated this. Not through a lack of wanting to, more a combination of things - lack of time, lack of anything worth writing, hating the old blog theme…

So I’ve replaced the theme!

Maybe that’ll help.

It probably won’t.

Limiting the effectiveness of DNS Amplification

I recently had the misfortune of having a server I am responsible for used as a target for DNS Amplification, and thought I’d share how I countered this. (Whilst this was effective for me, your mileage may vary, but if this actually helps someone then it’s worth posting about.)

This particular server was the main recursor for the site that it was located at (And this was correctly limited not to allow open recursion), but was also authoritative for a small selection of domains. (Yes I know mixing recursors and resolvers is bad.)

The problem only came about when I needed to relocate the server to another site. In order to ensure continuity of service whilst the nameserver IP change propagated, I added some port-forwards at the old site that redirected DNS traffic to the new site. This however meant that all DNS traffic going towards the server came from an IP that was trusted for recursion. Oops.

After adding the port-forwards, but before updating the nameservers, I got distracted and ended up forgetting about this little hack, until the other day when I suddenly noticed that both sites were suffering due to large numbers of packets. (It’s worth noting, that in this case both sites were actually on standard ADSL connections, so not a whole lot of upload bandwidth available here!)

After using tcpdump it became apparent quite quickly what was going on, and it reminded me that I hadn’t actually made the nameserver change yet. This left me in a situation where the server was being abused, but I wasn’t in a position to just remove the port forward without causing a loss of service.

I was however able to add a selection of iptables rules to the firewall at the first site (that was doing the forwarding) in order to limit the effectiveness of the attack, which should be self explanatory (along with the comments):

# Create a chain to store block rules in
iptables -N BADDNS

# Match all "IN ANY" DNS Queries, and run them past the BADDNS chain.
iptables -A INPUT -p udp --dport 53 -m string --hex-string "|00 00 ff 00 01|" --to 255 --algo bm -m comment --comment "IN ANY?" -j BADDNS
iptables -A FORWARD -p udp --dport 53 -m string --hex-string "|00 00 ff 00 01|" --to 255 --algo bm -m comment --comment "IN ANY?" -j BADDNS

# Block domains that are being used for DNS Amplification...
iptables -A BADDNS -m string --hex-string "|04 72 69 70 65 03 6e 65 74 00|" --algo bm -j DROP --to 255 -m comment --comment ""
iptables -A BADDNS -m string --hex-string "|03 69 73 63 03 6f 72 67 00|" --algo bm -j DROP --to 255 -m comment --comment ""
iptables -A BADDNS -m string --hex-string "|04 73 65 6d 61 02 63 7a 00|" --algo bm -j DROP --to 255 -m comment --comment ""
iptables -A BADDNS -m string --hex-string "|09 68 69 7a 62 75 6c 6c 61 68 02 6d 65 00|" --algo bm -j DROP --to 255 -m comment --comment ""

# Rate limit the rest.
iptables -A BADDNS -m recent --set --name DNSQF --rsource
iptables -A BADDNS -m recent --update --seconds 10 --hitcount 5 --name DNSQF --rsource -j DROP

This flat-out blocks the DNS queries that were being used for domains that I am not authoritative for, but I didn’t want to entirely block all “IN ANY” queries, so rate limits the rest of them. This was pretty effective at stopping the ongoing abuse.

It only works of course if the same set of IPs are repeatedly being targeted (remember, these are generally spoofed IPs that are actually the real target). Once the same target is spoofed enough times, it gets blocked and no more DNS packets will be sent to it, thus limiting the effectiveness of the attack (how much it limits it, depends on how much packets would otherwise have been aimed at the unsuspecting target).

Here is my iptables output as of right now, considering the counters were cleared Friday morning:

root@rakku:~ # iptables -vnx --list BADDNS
Chain BADDNS (2 references)
    pkts      bytes target     prot opt in     out     source               destination
  458939 29831035 DROP       all  --  *      *             STRING match "|0472697065036e657400|" ALGO name bm TO 255 /* */
 2215367 141783488 DROP       all  --  *      *             STRING match "|0473656d6102637a00|" ALGO name bm TO 255 /* */
       0        0 DROP       all  --  *      *             STRING match "|0968697a62756c6c6168026d6500|" ALGO name bm TO 255 /* */
       1     2248 DROP       all  --  *      *             STRING match "|03697363036f726700|" ALGO name bm TO 255 /* */
    5571   385042            all  --  *      *             recent: SET name: DNSQF side: source
    5542   374343 DROP       all  --  *      *             recent: UPDATE seconds: 10 hit_count: 5 name: DNSQF side: source
root@rakku:~ #

Interestingly, the usual amplification target,, wasn’t really used this time.

As soon as the nameserver IP updated (seems the attackers were using DNS to find what server to attack), the packets started arriving directly at the new site and thus no longer matched the recursion-allowed subnets and the attack stopped being effective (and then eventually stopped altogether once I removed the port-forward which stopped the first site responding recursively also)

In my case I applied this where I was doing the forwarding, as the attack was only actually a problem if the query ended up at that site and to limit the outbound packets being forwarded, however this would work just fine if implemented directly on the server ultimately being attacked.

Website Reshuffle

Over the past few weekends I’ve been (slowly) working on moving my websites around a bit so that things are all in once place, and in the case of this blog, no longer hosted on my home ADSL connection.

At the moment all non-existent pages on, and will now redirect to the equivalent link on, over time I will work on moving all public content from these sites over to here (There isn’t much, they’ve mostly been used as dumping grounds!)

After this will be primarily for private things and and will simply redirect here. Eventually I may look to transition this blog over to one of the raw domains (probably Ultimately I’m trying to do this without breaking any links that may exist to files/etc on these domains.

So if stuff breaks over the next few weeks, that’s why. Feel free to leave a comment if you notice anything or something goes missing.

GMail – apply labels to email from group members – Redux

A while ago I posted a python script that allowed automatically adding labels to GMail messages based on contact groups.

Unfortunately, a side effect of this script was that Google occasionally would lock an account out for “suspicious activity”, and for this reason I stopped using the script.

However recently I looked at Google Apps Scripts to see if this would allow me to recreate this using Google-Approved APIs, and the good news is, yes it does.

The following script implements the same behaviour as the old python script. It checks every thread from the past 2 dates (so today, and yesterday) and then for each message in the thread gets the list of groups the sender is in (if the sender is a contact, and in any groups) and then checks to see if there are labels that match the same name, if so it applies them to the message.

To get this running, create a new project on the Google Apps script page, then paste the code in.

Modify scheduledProcessInbox and processInboxAll to include a label prefix if desired (eg contacts/) and then enable the desired schedule (click on the clock icon in the toolbar). Once this has been scheduled you can run an initial pass over the inbox using processInboxAll() - however this is limited to the last 500 threads.

The code can now be found here on github

Any questions/comments/bugs please leave them here or on github.

Microsoft Lync on Linux

Post thumbnail

Update: This post still gets a lot of search traffic hits, but is now over a year old, and I no longer have a need to use Lync, so haven’t needed to keep this working.

I believe that the Ubuntu repos now contain new enough versions of SIPE that the deb mentioned here shouldn’t be needed any more, but that the rest of the instructions should still be valid.

Update 2: I need to use LYNC again. Pidgin from the default Ubuntu repos does indeed now appear to work just fine with a custom user agent. In addition, I’ve also had some success with “WYNC” which works pretty well but has a few minor issues of it’s own.

Recently at work we have started using Lync internally. Whilst this is great for the Windows and Mac users among us, not so much for those of us running on Linux.

However, it turns out that it is possible to get basic Lync support working quite easily. I can see people, talk to people, people can talk to me – I can send files to people, but people can’t send file to me. I’ve not tried any video/voice stuff but I suspect it doesn’t work.

It’s done using “sipe” – basically an open source implementation of the Extended SIP/SIMPLE protocol Lync uses for chat.

The basic steps on Ubuntu are:

  • Install the latest pidgin from pidgin devs ppa apt-get install pidgin pidgin-sipe
  • Download sipe
  • Compile it
  • Connect to lync.

The compiling step is required because we use Office365 for Lync which needs the latest version of SIPE for which a deb does not yet appear to exist. However, I have uploaded my compiled deb which can be found below.

Instructions for Ubuntu (using a pre-compiled deb I’ve uploaded):

sudo apt-add-repository ppa:pidgin-developers/ppa
sudo apt-get update
sudo apt-get install pidgin
sudo dpkg -i pidgin-sipe_1.13.1-2_i386.deb

Once this is done you can then open pidgin, and add an “Office Communicator” account, using the following settings:

First tab (Basic)
Login: email address
Username: email address
Password: password

Second tab (Advanced)
Server/port: blank
Connection Type: Auto
User Agent: UCCAPI/4.0.7577.314 OC/4.0.7577.314
Auth Scheme: TLS-DSK

Un-tick /Use single sign on/, leave everything below it blank

Ignore the other 2 tabs

Done. Connect, see buddies :)

Amusingly, at home, I’ve actually had more success on Linux than windows! On my windows machine, opening LyncSetup.exe seems to just do nothing at all, the process appears to be running, but no setup window appears.

Issues encountered:

  • The version of pidgin-sipe currently in Ubuntu repos is too old to work with Office 365 (needs 1.13.0, hence compiling myself)
  • Version of pidgin in ubuntu was old, I installed a new version to be sure
  • A colleague of mine seems to have had no success with these steps - pidgin seems to crash immediately after trying to connect

The pidgin-sipe deb above also builds the required “telepathy” binaries – so I’m going to have a go at getting it working with KDE’s native messaging client rather than pidgin, but for now for IM at least, pidgin is quite usable. (As I no longer need to use Lync, I never did get round to trying this)

Update iptables on Endian Community Firewall (EFW) 2.4.0

Compiling ip6tables on Endian Community Firewall (EFW) 2.4.0

Unfortunately the version of ip6tables available at the time of fedora core 3 doesn’t support the ‘state’ or ‘comment’ modules for use with firewall rules. So in order to get these, I decided to compile iptables for Endian.

To do this, we’ll need a build environment on the Endian box, we’ll also install wget.

cd /root
rpm -Uvh --nodeps
wget -O EFW-COMMUNITY-2.4-devel-srpms.tar.gz
tar -xvf EFW-COMMUNITY-2.4-devel-srpms.tar.gz
cd EFW-COMMUNITY-2.4-201006071652/RPMS/
rpm -Uvh gcc-* binutils-* cpp-* glibc-extras-* glibc-*headers-* glibc-devel-* libgomp-* libstdc++-devel-* make-* rpm-build-* patch-*

Now, we can compile iptables.

So firstly, lets download and install the sources we will need:

mkdir -p /usr/src/endian/{SOURCES,BUILD,RPMS}
wget -O /usr/src/endian/SOURCES/iptables-1.4.12-IMQ-test4.diff
rpm --nomd5 -i iptables-1.4.12-2.fc16.src.rpm

And modify the spec file to make it compile on Endian:

egrep -vi "(SOURCE[12]|ip6?tables-config|ip6?tables.init|ip6?tables.service)" /usr/src/endian/SPECS/iptables.spec > /usr/src/endian/SPECS/iptables.spec.temp
mv /usr/src/endian/SPECS/iptables.spec.temp /usr/src/endian/SPECS/iptables.spec
sed -i 's#CFLAGS=#export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | sed s/-mtune=generic//`\nCFLAGS=#g' /usr/src/endian/SPECS/iptables.spec
sed -i 's#rm -f include/linux/types.h##g' /usr/src/endian/SPECS/iptables.spec
sed -ri 's#^(Patch5:.*)$#\1\nPatch502: iptables-1.4.12-IMQ-test4.diff#g' /usr/src/endian/SPECS/iptables.spec
sed -ri 's#^(%patch5.*)$#\1\n%patch502 -p1#g' /usr/src/endian/SPECS/iptables.spec
rpmbuild --nodeps -bb /usr/src/endian/SPECS/iptables.spec

And then install it:

rpm --nodeps -Uvh /usr/src/endian/RPMS/i386/iptables-

now iptables and ip6tables will be version, and ip6tables will have the extra missing modules.

If anyone wants a copy of the generated RPM just leave a message here and I’ll get them uploaded somewhere.

IPv6 with Endian Community Firewall (EFW) 2.4.0

First post in over a year! Oops.

For a while now, my home ADSL provider (EntaNET) has provided me with an IPv6 allocation, but I’ve never really used it (Its been on my to-do list for some time) primarily due to the fact that it is unsupported by Endian which I use for my home router/firewall.

However the other day after being asked about IPv6 at my day job, I decided I wanted to get this working, and decided to document it here in case it can assist anyone else in future. (I also finally got round to completing the Hurricane Electric IPv6 Certification up to sage level)

There’s a few things worth noting before we continue here.

  1. I use a Draytek Vigor 120 for my adsl modem - this is a PPPoA to PPPoE bridge. This means that my Endian box uses PPPoE to get its Internet connection, and directly receives an IPv4 address via the PPP session. There is no “PPP Half-Bridge” tricks here (such as where Modem does authentication, then DHCPs the address to Endian).
  2. Due to Endian lacking support for IPv6 you will need to use SSH to configure this, and any Endian upgrades will probably reverse a fair chunk of it. (Also, some reconfigurations may also undo things) - so with this in mind the rest of this guide assumes you are familiar with SSH and have successfully logged in as root to the Endian box (SSH can be enabled under the “System” section and “SSH Access”).
  3. Due to previous requirements, my Endian server is not “pure” in that I have additional packages installed that made this easier. Notably, a complete build environment. This won’t be needed here.
  4. This was all done without writing it down, so this documentation is based on my recollection and attempts at replicating various parts on a VirtualBox VM (which can’t do PPPoE…). If I’ve missed anything, please let me know in the comments.
  5. This was done with EFW 2.4.0 and may not work in the latest 2.5.1 version.
  6. I have only had this running for a few days, so there may be some unforeseen issues with this.

With this in mind, we continue to the actual important stuff!

The way EntaNET do IPv6, with a default setup you will get an IP Address allocated over PPP that is in a /64, but you also get a /56 which is routed to you. We will use a /64 from the /56 as the address for the LAN.

For the purposes of this, we are going to assume the following:

  • 2001:DB8:4D51:AA00::/56 - /56 range allocated to us by the ISP
  • 2001:DB8:4D51:AAFF::/64 - /64 range we are going to use internally.
  • 2001:DB8:4D51:FFFF::/64 - /64 range advertised across the PPP session.

The first thing to do, is to have Endian actually ask for IPv6 from the upstream provider at PPP time. This is easy:

echo "+ipv6" >> /etc/ppp/peers/defaults/pppd-pppoe

Assuming that the ADSL provider and modem both support IPv6, and you have been assigned an allocation you will see an IPv6 address attached to ppp0 once your session is active. This is from the PPP /64 and is not part of your /56 allocation.

So now we know that IPv6 works we can disconnect the PPP session.

Now, we actually want to be able to do something with our allocation, so we will want to announce it to our network.

For this, we will need radvd which will send the required RA Packets out to the network. As Endian 2.4.0 is built on Fedora Core 3, we can use the existing package for this, these can currently be found here

Unfortunately, Endian doesn’t quite provide a complete environment, so we will need to force the install to ignore dependencies (specifically, chkconfig and /sbin/service are missing).

rpm --nodeps -Uvh

We can now configure this to announce our prefix by editing /etc/radvd.conf to something like this:

interface br0
        AdvSendAdvert on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
        AdvHomeAgentFlag off;
        prefix 2001:DB8:4D51:AAFF::/64
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;

To trick radvd into starting, we also need to create a dummy file that exists in real RedHat-esque distros that Endian doesn’t provide:

echo "NETWORKING_IPV6=yes" >> /etc/sysconfig/network

We also need to enable IPv6 forwarding:

sysctl net.ipv6.conf.all.forwarding=1

and we should now be able to start radvd:

/etc/init.d/radvd start

Now, if we bring the ppp connection back up, you’ll notice that the ppp0 interface no longer gets allocated a routable IPv6 address from the PPP /64. This is because with ipv6 forwarding turned on, this host is now acting as an ipv6 router, and ipv6 routers ignore RA packets.

This isn’t a problem.

At this point, your LAN boxes will have IPv6 addresses, but the LAN boxes won’t be able to communicate with the internet yet.

To fix this, we need to tell the Endian box how to route traffic, specifically to both our LAN, and the default route:

route --inet6 add 2001:DB8:4D51:AAFF::/64 dev br0
route --inet6 add default dev ppp0

With this however, the Endian box won’t have IPv6 connectivity, if this is something that is required, we can do something like this instead:

ip -6 addr add 2001:DB8:4D51:AAFF::/64 dev br0
route --inet6 add default dev ppp0

But remember, that any time Endian makes any changes to the network configuration, this will be lost.

Endian’s version of iputils is missing ping6 and traceroute6, but we can install these as follows:

cd /
curl > iputils.rpm
rpm2cpio iputils.rpm | cpio -ivd '*6'
rm iputils.rpm

This will give you ping6 etc to allow you to verify everything so far.

The next thing to do then is firewalling, this is done with ip6tables, which again Endian doesn’t have, however we can install ip6tables using the iptables-ipv6 package available in the RPM repo above)

rpm -Uvh

Now you’ll be able to create firewall rules for your IPv6 connectivity. Its worth noting though that this version of ip6tables doesn’t support some modules (comment and state that I’ve seen so far). If you want these modules, then you’ll need to compile a newer version of iptables. (I’ve got a follow up post with a guide for this.)

To support this, I wrote a set of scripts for parsing “formatted-english” rules files into iptables rules, so lets install that and configure some rules.

cd /root
wget -O
mv ShaneMcC-Firewall-Rules-* fwrules
cp fwrules/example.rules fwrules/rules.rules
chmod a+x fwrules/

Looking at fwrules/rules.rules should give you a good guide on how the rules work, and you can edit these to your needs.

Once you are happy, the rules can be installed by running:


The last thing then is to make this all work automatically.

In theory we should be able to just drop some files into the subfolders of /etc/uplinksdaemon, or into ifup.d or ifdown.d folders inside mkdir /var/efw/uplinks/main/ but neither of these approaches works. So instead we will make a minor modification to /usr/lib/uplinks/generic/ and then have a script of our own do it.

Firstly, the minor change and an empty file:

sed -ri 's#^(.*log_done "Notify uplinks.*)$#\1\n    /sbin/ "$@" >/dev/null 2>&1#' /usr/lib/uplinks/generic/
touch /sbin/
chmod a+x /sbin/

Now we can put the following into /sbin/




if [ "${STATUS}" = "" ]; then
        exit 0;


if [ "${UPLINK}" = "main" ]; then
        if [ "${STATUS}" = "OK" ]; then
                sysctl net.ipv6.conf.all.forwarding=1
                /etc/init.d/radvd start
                route --inet6 add ${OURPREFIX} dev br0 2>&1
                route --inet6 add default dev ppp0
        elif [ "${STATUS}" = "FAILED" ]; then
                route --inet6 del default dev ppp0

                ip6tables -F
                ip6tables -X
                ip6tables -P INPUT ACCEPT
                ip6tables -P OUTPUT ACCEPT
                ip6tables -P FORWARD ACCEPT

Now when the state of the main uplink changes, the relevant ipv6-related commands will be run to ensure that connectivity remains.

And that’s it, you should now have native IPv6 connectivity combined with Endian. Feel free to leave any comments you have regarding this.

A tale of two monitors

So, a while back (just under 3 years ago) I obtained 2 of Hyundai’s W240D monitors. These monitors had (I believe) PVA panels and worked fine for most of their life so far.

A while back they both developed a problem, as evident in the video below:

So, as they were still under warranty I contacted Hyundai/RepairTech and arranged for these to be repaired. Hyundai sent the parts to RepairTech, who collected the units, repaired them and sent them back.

And this was the result:

So quite obviously they have come back with different panels from each other - but also different panels than I sent them in with.

One of them now has a TN panel, and one of them now has a panel that flickers when being videoed.

I sent the TN panel back (as it was clearly no where near what I sent in) and after a while it came back - still with a TN panel, but without a working stand. I sent it back again, and after eventually getting Hyundai involved I now have it back with a PVA panel.

The problem I find now, is that the second one (the one I had considered to be fine after the initial repair) is clearly not using the same panel technology, after searching and discovering the service menu, it became obvious why.

As you can see one of them has an RTC control, for TN or IPS panels, as its not a TN panel we can assume that is is an IPS panel.

So now I have 2 monitors, which previously were able to show images identically, that now show everything (subtly) differently - which isn’t what I wanted. (I bought 2 at the same time from the same place in order to get them the same)

I’ve invested in a colour calibrator to try and bring them closer together, but I know I won’t be able to get them the same. The PVA monitor also has no ability to change the colour values on the monitor itself when using DVI and not in service mode (Video).

For most people, there wouldn’t be any problem with this - not everyone cares about panel technology, or that 2 monitors side by side are the same (not everyone even has 2 of the same model side-by-side anyway), but now I find myself with a dilemma, that needs to be resolved quickly. (The warranty period on the IPS monitor runs out on 2nd December)

  • I could just accept it and move on and let it annoy me. (How often do I have both monitors showing things that are similar enough for the differences to be obvious?)

  • I could contact RepairTech again and request that they swap out the one with an IPS Panel for one with a PVA Panel (Is it really acceptable during a repair to fundamentally change the product? And do I really want the whole hassle of dealing with RepairTech again?)

  • I could sell both of the monitors and buy 2 new different identical monitors (This of course means finding acceptable replacements which is a chore in itself)

Choices, Choices, Choices.

I think I’m going to contact RepairTech to try and get this sorted properly, I had PVA panels, I should have PVA panels, even if it means dealing with RepairTech again. I can then look at the option of replacing the 2 monitors in the future when they have to be replaced, rather than doing it just for the sake of getting them to be the same.

Greasemonkey script for forums

If you’ve ever visited the forums you’ll know that any links in the post get enclosed by a call to “javascript:openExternal(“)” in the href rather than doing it properly in onClick. Amongst other things, this breaks the ability to middle click to open links in new tabs.

This finally annoyed me enough today and as a result, I now use the following greasemonkey script:

// ==UserScript==
// @name           Stupid HP.COM Links
// @namespace
// @include        **
// ==/UserScript==

var a = document.getElementsByTagName("A");
for (var i = 0; i < a.length; i++){
        var href = a[i].href;
        href = href.replace(/javascript:openExternal\('([^']+)'\)/i, '$1');

        a[i].href = href;

This will make the links no longer have the call to openExternal around them, and thus make them middle-click friendly.