Dave Winarsky's Blog

SSH Tunneling (on Windows) with OpenSSH and Putty through an HTTP proxy

2006-11-27T01:15:00Z

I became interested, a little while ago, in how to tunnel encrypted traffic through an http proxy and firewall with only the standard open ports (80, 443). There are a number of reasons to do this, basically anyone sniffing or logging will not be able to tell the difference between the tunnelling and regular https traffic. It will appear as one https session to a destination address. I'll leave it up to all of you to figure out the useful scenarios. In any case, I wasn't able to find any documentation that explained how to do this simply, so here we go:

In this example, I'll use two machines workComp - a winxp computer sitting behind the standard corporate firewall with only proxied http and https access, and homeComp - a winxp computer sitting behind a router/gateway running NAT and a simple blocking firewall (e.g. linksys).

Step 1: Download and install OpenSSH

On homeComp download OpenSSH for windows from: http://sourceforge.net/project/showfiles.php?group_id=103886&package_id=111688/ Follow the instructions and install it. Once its installed configure it according to the documentation- be sure to use a strong password/username because it will be visible to the internet (although disguised in a way, as I explain in a bit.) Once you're sure that it is working correctly (test it using ssh localhost, and you can get to a shell) it is time to configure it for the tunneling.

Step 2: Configuring OpenSSH

On homeComp edit the file c:\program files\openssh\etc\sshd_config. Note the file name is sshd_config and NOT ssh_config. So in the sshd_config file, you want to make 2 important changes:

1. Uncomment the port line and change it to 443. This is very important if the http proxy that workComp is behind is doing anything at all to detect tunneling. Basically, this disguises the connection so the proxy thinks its a regular https connection. I've found that these things implement some of the worst security I have ever seen - check out http://www.bluecoat.com/downloads/support/BCS_tb_tunnelling_applications.pdf if you want to have a laugh, they control tunneling by verifying the user agent header and port on the destination.

2. Uncomment the line with AllowTcpForwarding, and set it to yes. This will allow the forwarding to take place.

Step 3: Configure port forwarding on the router (on homeComp net)

1. You now have to configure port forwarding on your router so you'll be able to access homeComp from the internet. Go to your port forwarding setup on the router and set to forward all 443 TCP traffic to the nat'd IP of homeComp (ex. 192.168.100.1).

You're now finished configuring homeComp - next are the steps for workComp.

Step 1: Download Putty

1. You can get putty from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html - install it.

Step 2: Configure Putty for use with the proxy

1. Under the session tab enter the external IP of homeComp - this will be the router's ip - you can get this from going to status or something of the like on your router. This should not be a 192.168 address. Enter the port as 443 (this is going to fool the proxy). Next set the protocol to SSH.

2. Now go down under Connections and pick your proxy type (I used http, but you may want to pick something else if you are behind a socks proxy). Enter in its hostname and port. If you don't know what this is check the proxy settings for your web browser, this should give you all the information you need. It'll probably be 8080..

3. Under the SSH tab set the protocol for version 2 and move AES encryption up to the top with 3DES below.

4. Now under the SSH tab, click on Tunnels - this part gets a bit confusing. Source port is the port on workComp you want to forward over the tunnel and destination should be localhost:port. This is because when homeComp gets the forwarded packets, it will forward it to localhost:port - which will be homeComp:port - exactly what we need. This is also interesting, because we could set it up to forward to a 3rd machine, I'll leave that one up to someone else with some good ideas. When your done, click add and you should have something like “L5900 localhost:5900” - I set up this forward so I can use VNC from workComp to connect to homeComp.

5. Remember to save your session, up on the main session tab, as it is quite annoying have to type all these settings in every time you start up putty.

Step 3: Connect!

1. If you've done everything correctly here and you can get out on workComp, just fire up putty and click connect. You should be able to connect to your homeComp and get a shell up. But there is one final task, start up the tunnel for whatever app you configured in forwarded ports.

2. Open the app which you configured your tunnel for (in Step 2.4 - on the workComp) and connect to localhost on specific port. For tightVNC connect to localhost:5900, if we wanted to tunnel out http, we would configure our browser to use localhost:8080 and set up the similiar rule in putty. Putty will grab the request, encrypt and tunnel it over https. Ding. You’re done.

Somehow I think this ended up much more confusing than I meant - let me know how I can clarify this more, or of any confusing parts and I'll fix it up.

Dave

DSniffing Wifi with Atheros

2005-01-18T16:58:00Z

This past weekend, I blew out my linux install to check out Redhat's Fedora Core 3 and for the 3rd time went though getting dsniff 2.3 installed with the WiFi patch. Everytime I've done this, I've forgotten how and had to re-learn it. Here are the steps.

Setup your system

1. Install Redhat Fedora Core 3 with 'All' packages (feel free to try with less, but I've got the drive space and wanted to deal with as little dependencies as possible).
2. Get the latest MadWifi drivers out of CVS:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/madwifi co madwifi
3. Compile and reboot
4. Make sure your wifi card is working.

Install DSniff

4. Download and compile/install Libnet-1.02a:
     http://www.packetfactory.net/libnet/dist/deprecated/libnet-1.0.2a.tar.gz
5. Get libnids 1.18 out of sourceforge:
     http://sourceforge.net/project/showfiles.php?group_id=92215&package_id=97542&release_id=191323
6. Download the patch to allow for wireless dsniffing in rfmon mode:
     http://airsnort.shmoo.com/libnids-1.18-snax-prism-modified.diff
7. Patch it, then compile/install:
     patch -p0 src/libnids.c ~/wifi/libnids*.diff
8. Make and install dsniff:
     http://www.monkey.org/~dugsong/dsniff/dsniff-2.3.tar.gz

DSniff

9. Put your card into RFMON (monitor) mode:
iwconfig ath0 mode monitor

Couple of points/questions:
     -It is possible to get it compiled with newer versions of libnet (prepare for a huge headache).
     -I have not found a newer patch for libnids 1.18 - let me know if there is a better way..
     -I've found dsniffing wifi with the '-c' option helps when you are far from the base station (you may only receive half the trans because of signal power).
     -Has anyone figured out how to set the sensitivity? I've tried, but I can never see any change - ex: iwconfig ath0 sens -80, etc.

Lycos screensaver fights SPAM

2004-12-02T20:53:00Z

I can't even remember the last time I downloaded a screensaver, but I'm definitely going to check this one out. Lycos has apparently created a screensaver, developing on distributed computing ideas such as the seti@home project, and applied it to a more practical problem - spam.

Slashdot reports on it here: http://it.slashdot.org/it/04/11/26/2129238.shtml?tid=111

Lycos claims that the screensaver is not a real ddos because it doesn't take the site off-line entirely - one would assume this is to dodge legal repercussions I'll be waiting for the full ddos version... meanwhile sleeping well knowing that my PC is happily contributing to the fight against spam.

Major ASP.NET Vulnerability

2004-10-08T17:44:00Z

So, this new amazing vulnerability has been making it's rounds this week and Microsoft has released some official information about it (http://www.microsoft.com/security/incident/aspnet.mspx).

Just a few thoughts on this-

1. I think this exploit wins the prize for being the cheesiest I have seen in a long time, I mean, it doesn't really take a technical genious to switch a '/' to a '\'..

2. Building on the last thought - what on earth were the msoft developers thinking???? Come on guys, could you help us out a little bit here?

3. And finally, I was going to write something here about how long this one has probably been known by all the Asshats out there, but I don't even want to think about it.

Its Friday and I'm going for beer - have fun installing urlscan/aspnet modules this weekend :)

Little bit of info on ViewState

2004-06-17T16:26:00Z

A good article on ViewState that I found through weblogs on MSDN-
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp11222001.asp

Especially the section on the ViewState vs. SessionState.. Session state is protected because it remains on the server's side, however viewstate bounces back to the client. Encryption (its only base64 encoded by default, which is essentially clear text) and tamper proofing definitely has a performance hit so the inclination is going to be turn it off.

Who'd ever think to tamper with the viewstate? ;-)

http://www.pluralsight.com/tools.aspx