Archives

All posts for the month October, 2013

Every stinkin’ time you have to update Java (which is every day it seems, since Java has more (security) holes than most Swiss cheese) it wants to install the stupid Ask Toolbar and take over your default search engine. Here’s a quick Windows registry fix that will apparently disable the installer from even asking you about the toolbar installation.

Another way, without having to download and rename or create a new .REG file, is to copy and paste the following two lines into an elevated CMD prompt:

reg add HKLM\software\javasoft /v "SPONSORS" /t REG_SZ /d "DISABLE" /f

reg add HKLM\SOFTWARE\Wow6432Node\JavaSoft /v "SPONSORS" /t REG_SZ /d "DISABLE" /f

via Superuser: How can I prevent Ask.com Toolbar from being installed every time Java is updated?

Update: Looks like Transmission sends traffic out the loopback (lo) interface, to the loopback interface. Seems kind of weird, but it should be harmless. These rules should permit traffic from the vpnroute gid to pass to the tun0 and lo interfaces, but everything else will be rejected. You can also duplicate the last rule with a LOG target if you want to see what is still being rejected.

sudo iptables -A OUTPUT -m owner --gid-owner vpnroute -o tun0 -j ACCEPT

sudo iptables -A OUTPUT -m owner --gid-owner vpnroute -o lo -j ACCEPT

sudo iptables -A OUTPUT -m owner --gid-owner vpnroute -j REJECT


We recently moved into a new home where we have a shared internet connection with the other occupants of the duplex. I didn’t want to use bittorrent directly, since any nastygrams would end up with the landlord and cause problems, so I signed up for the IPredator VPN service in Sweden. It allows you to make an encrypted and secure connection from your computer to their network, so all of your internet traffic is funneled through the secure connection, making it so that the neighbors, landlord, and internet service provider can’t tell what I’m up to. The VPN was really easy to set up in Ubuntu Linux with the graphical network manager (IPredator provides a visual guide to this process) and the speeds are certainly reasonable.

One downside of this is that if there is a connection hiccup that causes the VPN to drop, the bittorrent software will just fall back to sending data out the regular, unencrypted network interface, potentially exposing your naughty activities to the ISP. I wanted to find a way to effectively say, “only allow bittorrent traffic through the VPN connection” that would step up and protect things if the VPN connection dropped.

On Linux, the standard firewall is called “iptables”, and can do just what we need, in only three commands. But first, a couple of assumptions:

  • I am assuming that you are using the default Ubuntu Linux bittorrent client called “Transmission”, which is executed using the command “transmission-gtk”.
  • When the VPN is connected, it creates a new network interface called “tun0” (“tun” for “tunnel”).

The general plan is to somehow tag the bittorrent traffic so that the iptables firewall can identify the relevant packets, and reject them if they aren’t heading out the secure VPN interface tun0. An easy way is to run your bittorrent program using a different UNIX user or group.

Here, we add a new group called “vpnroute”:

sudo groupadd vpnroute

Then, we add the firewall rule that rejects all traffic from this group that is not heading out tun0:

sudo iptables -A OUTPUT -m owner --gid-owner vpnroute \! -o tun0 -j REJECT

Finally, we start up the bittorrent software with group ownership of vpnroute:

sudo -g vpnroute transmission-gtk

Your torrents should now only run when the VPN is connected. Try it out with some safe torrents, like the Ubuntu ISO files, and make sure that they only download when the VPN is connected, and they should stop right away when you disable the VPN.


If you want to confirm that the firewall rule is actually matching your traffic, you can add a similar rule that does the LOG operation instead of REJECT. You need to ensure that the LOG rule happens first, because after handling the LOG rule the packet keeps going, while a REJECT action won’t let the packet continue down the chain of rules. You can remove the output rule with “sudo iptables -F OUTPUT” (F for Flush), and then:

sudo iptables -A OUTPUT -m owner --gid-owner vpnroute \! -o tun0 -j LOG
sudo iptables -A OUTPUT -m owner --gid-owner vpnroute \! -o tun0 -j REJECT

Then you can check the output of “dmesg” to see when packets are logged (and then rejected) by the firewall.