UDP Tunneling to avoid hotspot or firewall restrictions

February 24th, 2010

UDP tunneling is an attack that is often overlooked when manufacturers design wireless hotspot and other firewall/proxy based devices.

When you try and resolve a domain name, you make a request to a name server on UDP port 53. The way that a lot of wireless hotspot, firewalls and proxies work, is that your DNS request is allowed out, you get the IP for the machine you’re looking for, and then your request to the IP is redirected to the wireless hotspot login page, or through a web proxy server.

The problem is, that all port 53 UDP traffic is allowed out to anywhere, without any kind of authentication. You can therefore install OpenVPN on a remote server which by default listens in on UDP port 1194. You can change this with one configuration option to 53, and then edit your client config to connect to the server on port 53 instead. Often, other TCP/UDP ports might be allowed out, and ICMP is also sometimes a possibility. It is possible to easily tunnel your data out over TCP, UDP or ICMP as a worst case.

This type of attack worked on 5 out of 6 different wireless hotspot systems to gain access without authentication.

The one that it didn’t work on, captured all outbound 53 UDP requests, and silently redirected them to it’s own local DNS server. This is simple enough to do, so I’m not sure why more manufacturers haven’t done the same. Using iptables:

${IPTABLES} -t nat -A PREROUTING -i eth0 -p udp -m udp –dport 53 -j REDIRECT –to-port 53

These are the same type of rules used to configure transparent proxying for Squid.

Full NAT, DNAT and SNAT aka 1:1 NAT, 1 to 1 NAT

February 10th, 2010

Full NAT, DNAT and SNAT aka 1:1 NAT, 1 to 1 NAT – this is used when you want to map a dedicated external IP on an external interface to another IP on a separate interface with everything routed between them.

EXTERNAL_IP=”87.117.XXX.XXX”
EXTERNAL_IF=”eth1″
INTERNAL_IP=”192.168.1.105″
INTERNAL_IF=”eth0″

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -i ${EXTERNAL_IF} -d ${EXTERNAL_IP} -j DNAT –to-destination ${INTERNAL_IP}
iptables -t nat -A POSTROUTING -o ${EXTERNAL_IF} -s ${INTERNAL_IP} -j SNAT –to-source ${EXTERNAL_IP}
route add -host ${EXTERNAL_IP} ${INTERNAL_IF}
arp -Ds ${EXTERNAL_IP} ${INTERNAL_IF}

netfilter/iptables split access with multiple ISPs

February 10th, 2010

Quite a while back, I posted article http://www.adampalmer.me/iodigitalsec/extending-tc-and-iproute2-linux-routing-split-access-multiple-uplinks-multiple-isps-iptables-masquerading/

The article focuses on using the standard iproute2 tool to allow the box to attempt to balance traffic over multiple uplinks with multiple default routes. While relatively easy to set up, it has a few problems:

  1. Routes are cached, meaning that once the balancer has decided on a route to a certain IP for the first time, it will continue to use this route for a while.
  2. There is no real control over which packets end up over which route, other than some basic metrics such as source IP and destination IP.
  3. Certain long established TCP connections such as MSN or IRC die after the route cache expires and the packets begin being routed over the other connection. Logically, there should be a fix for this or theres a bug in my script, either way I gave up digging after a while, and just forced connections to given IPs over the same route each time.

I’ve recently decided to give this a go in netfilter purely. My environment is a router with a number of LAN devices, with eth0 being the LAN interface (192.168.1.0/24), while eth1 and eth2 are separate ISP links with public IPs.
Read the rest of this entry »

Linux LUKS Crypt HOWTO

February 5th, 2010

Linux kernels now support encrypted filesystems. Setting one up should take 5 minutes, or 3 hours if you’re like me and can’t read.

Firstly, install the right tools: apt-get install cryptsetup

Make a new partition, and initialize it with: cryptsetup luksFormat /dev/sda3 mycrypto

Where /dev/sda3 is your newly created partition and ‘mycrypto’ is your name for the container.

You will be prompted to type YES in uppercase to confirm your understanding that your partition is about to be wiped. If, like me, you type ‘yes’ in lowercase, it will fail with “Command Failed.”. You’ll then spend hours checking for loaded kernel modules, log files, and trawling google for more information. The answer is to type ‘YES’ in uppercase as you’re told 🙂

Enter a passphrase, and you’re ready to go.

Next, ‘open’ the container. cryptsetup luksOpen /dev/sdb3 enter the passphrase, and you should at this point end up with a /dev/mapper/mycrypto

Format with your desired partition mkfs.ext3 /dev/mapper/mycrypto

Then, you can mount /dev/mapper/mycrypto as you would any other block device: mount /dev/mapper/mycrypto /mnt/my_mount_point

To close the container:
umount /dev/mapper/mycrypto
cryptsetup luksClose mycrypto

Easy 🙂