Wednesday, July 6, 2011

a network layer proxy

i've been wanting to get this going for a long time. i'm often on untrusted networks, and it would be nice to use a secure tunnel to get onto the internet. luckily there is this cool program called redsocks that will interface with iptables to transparently use a socks proxy. this page was an excellent guide to setting things up.

first, we setup a chain to setup our routing policy. we will put all the policy in a chain called REDSOCKS:
sudo iptables -t nat -N REDSOCKS
sudo iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345

the bulk of the rules (the ones with RETURN) are to not change the routing of connections to private addresses. the last rule is key; it will cause all other connections to get routed through redsocks. specifically, it will cause the kernel to forward connections to the port 12345 which redsocks will be listening on. redsocks then uses SOCKS to route the connection through ssh and out to the internet. (for the curious, i was, you figure out the original target of the socket using a sockopt.)

note that in this case the server we are sshing to is 127.0.0.1, which we cannot route through redsocks. (otherwise we have a chicken and egg situation.) if we are connecting to routable addresses, we need to add an entry to iptables. if X.X.X.X is the machine that we are sshing to, the table setup would be as follows:

sudo iptables -t nat -N REDSOCKS
sudo iptables -t nat -A REDSOCKS -d X.X.X.X/32 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345
one other thing to note is that the link above says to use the DNAT target rather than REDIRECT. for this part of the project both worked, but i couldn't get DNAT working for connections routed through my laptop from the router. we will get to how to setup this routing in the next post.

ok, now the REDSOCKS chain is setup, but nothing will happen since it is just a chain floating out there in iptables. we've got to connect it to a chain that is actively involved in packet processing. the chain we are looking for is the OUTPUT chain. this chain is used in the initial stages of local packet routing.
sudo iptables -t nat -A OUTPUT -p tcp -j REDSOCKS
the iptables has an excellent explanation of the iptable chains and how/why they are used.

with that last rule the kernel will start routing connections to port 12345. we need to start something listening on that port. that something is redsocks. you'll need to download it and compile it.

before we start up redsocks, we need to point it at a configuration file.

base {
        log_info = on;
        log = stderr;
        daemon = off;
        redirector = iptables;
}
redsocks {
        local_ip = 127.0.0.1;
        local_port = 12345;
        // `ip' and `port' are IP and tcp-port of proxy-server
        ip = 127.0.0.1;
        port = 1080;
        type = socks5;
}

nothing really tricky here. the local_port is the port that the kernel will use to forward connections to redsocks. ip and port are the ip address and port of the socks server. once you have created the config file, i called it redsocks.conf, start redsocks with:
redsocks -c ./redsocks.conf
of course make sure your socks server is up. from the previous post i was forwarding an ssh port to local port 2222, so i started up socks with:
ssh -p 2222 -D 1080 127.0.0.1
the -D 1080 flag tells ssh to service SOCKS clients on port 1080. so there you go. transparent tunneling over the internet. pretty cool huh? of course we have to do a bit more if we want to route connections through the machine.

Tuesday, July 5, 2011

fun with ssh



for the 4th of july weekend we headed to los cabos, mexico for a family reunion. we stay at this really nice resort, barcelo, and they have these really cool plasmas on the wall. we start playing with them: they have games and a web browser and come with a keyboard. you can facebook on it! pretty cool.

i notice that it's running google chrome and then my son finds gnu chess. definitely running linux, so 30 seconds after turning on the tv we have a shell. (you just have to push alt-f2 and startup bash :)


now, what can you do with a shell? more specifically, since we don't want to mess up anything or use exploits, what can you do from user space?

well we don't actually know the guest (huesped in spanish) password, so we are further limited. but there are a couple of things i noticed:
  1. the wifi network, which you have to pay $20 a day for, is accessible from the network (ethernet) that the room is hooked up to. the wifi network is one of those that give you an ip address, but doesn't route you to the internet until you pay.
  2. there is some sketchy proxying going on. i'm sure they aren't doing anything malicious, but i'm a bit paranoid about these things.
  3. it has ssh.
  4. we brought our wifi router from home. (ok, i kind of knew that before we walked into the room :)
one other thing to consider is that we have a bunch of wifi devices: 3 itouches, 2 computers, and 2 phones. so, i do the project i've been wanting to do for a long time! transparent socks proxying at the network layer. because there are other devices involved i'm throwing in ip masquerading on top.

if i wasn't worried about observation number 2, i could have just started up a simple socks proxy on the tv. instead i use a remote vps (basically a web service shell acount)  i have from jaguarpc.

getting internet access


before i start, let me just point out this was a research project. i actually got legitimate wifi access after i got this working. you should too. $20 is kind of a rip off, but not a total one. (it does seem to go against the notion of an "all inclusive" resort though...)

first, setup my laptop to connect to the wifi network. whenever i try to connect anywhere i get the prompt for the login or payment for internet service. we'll fix that in just a second.

the easiest option to get internet access would be to ssh from the tv to my external ssh account using:
ssh -g -D 1080 myserver.me
but that would open up access through my server to everyone. of course, i'm just being paranoid since why would anyone look for an open socks proxy on the tv in our room?

since I am paranoid i do something better:
ssd -R 2222:myserver.me:22 laptop-address
the laptop-address is the address of the wifi interface of my laptop. once i ssh into my laptop, i can now use
ssh -D 1080 -p 2222 myserver.me
to connect myserver.me from my laptop. since i'm using the -D option, i also have a fully functional local socks proxy going. so, i change the proxy of my web browser of my laptop to 127.0.0.1:1080 and voila (or andale since we are in mexico) i'm on the internet from my laptop.

ok, so this is a start. it's such a pain to setup socks settings, and i want to allow the rest of my devices to connect through, so of course i didn't stop there.