SSH Tunnel for Web Browsing Freedom and More

Ever been using the Internet somewhere where there's a firewall or web filter in place keeping you from browsing your favorite sites?  If you have a secure shell (ssh) server setup at home (or at a hosting site) you can easily use it to proxy all of your web browsing activity, bypassing most types of obstacles that would likely be in your way.

For the purposes of this post, let's assume that you're running an out-of-the-box installation of OpenSSH server on a linux system, with the configuration files located in the /etc/ssh directory.  The most useful parameter in the /etc/ssh/sshd_config file is the "Port" setting.  By default, it's set to 22, which is the standard port for ssh.  In most situations where your web browsing traffic is being filtered, port 22 is likely being blocked as well, so that doesn't help us too much.  You can change the line to

• Port 443

in order to have the ssh server listen on a port that is likely not being blocked at all.  443 is normally used for SSL-encrypted web traffic, a.k.a. https.  Most web filters will take one look at that and say, "Nevermind, sorry for the disruption, nothing to see here, move right along."  There are a couple of other basic parameters that you should be mindful of from a security standpoint including:

• Protocol 2
• This is to ensure that your ssh server only uses the latest, more secure protocol, as backwards compatibility with protocol 1 introduces vulnerabilities into the system
• PermitRootLogin no
• This is to ensure that nobody can login remotely as root directly.  An attacker would need to first gain access to a lower privileged account, and then attempt to escalate from there.

Once you've got the sshd_config file all set, save it, and restart the sshd service.  Then you should be ready to login remotely using any ssh client.  For our example here, we'll use a popular one called PuTTY.  Once you've downloaded, and optionally installed, PuTTY, fire it up, and when the Configuration window comes up, enter in the hostname/IP address of your ssh server, with the port that you selected in your sshd_config file:

Then, on the left-hand side, under Category, navigate to Connection --> SSH --> Tunnels.  Enter in a Source port for the tunnel (I've chosen 1080 because the tunnel is really creating a SOCKS proxy, which uses 1080 by default), select the radio button for Dynamic instead of Local, and click the Add button next to the Source port field.  It should now look something like this:

At this point you can go back to Category --> Session, and save the session so that you won't need to configure it all again, or you can just click the Open button in the lower-right corner to start up your ssh session.  Once you've got your session up and running, you'll need to configure your browser of choice to take advantage of the tunnel you've just created.

In IE9, navigate to Internet Options --> Connections --> LAN Settings --> Proxy server,  Check the box for "Use a proxy server for your LAN," and click the Advanced button.  In the Proxy settings window that comes up, for the "Socks:" entry, enter in 127.0.0.1 for the address and 1080 for the port.  Click on the OK button when you're done.

In Firefox 5, navigate to Options --> Advanced --> Network --> Settings...  Select Manual proxy configuration, and for the "SOCKS Host:" entry, enter in 127.0.0.1 and 1080 for the Port.  Select the radio button for SOCKS v5 instead of v4.  Click on the OK button when you're done.

In Chrome 12, navigate to Options --> Under the Hood --> Network --> Change proxy settings...  This will bring up the same window as for IE9 above, so just configure the Proxy server as mentioned previously.

You should now be all set!  Any web browsing that you attempt to do now will be redirected through your encrypted ssh tunnel, and go out to the Internet from the network that your ssh server resides on, rather than the current network that you're connected to locally.  Filters schmilters!

This technique has an infinite number of uses for getting you where you need to go.  You can tunnel things like Microsoft Remote Desktop/Terminal Services, port 3389, Instant Messaging, VNC/Apple Remote Desktop, port 5900, etc.  Best of all, it's all encrypted, and potentially performs better than a direct connection, as you can even turn on compression for the SSH connection.

To perform simple port forwarding for these types of services, you'll need to add another tunnel into your PuTTY session configuration.  This time, select the radio button for Local instead of Dynamic.  You'll also need to enter in a specific destination host and port to forward the traffic to on the other side of the tunnel.  For example, say you want to connect to a Windows system that has an IP address of 192.168.1.2 on the remote network, using Remote Desktop, you would set up the tunnel in PuTTY like so:

Then, once your ssh session is up, in your Remote Desktop Connection client window, simply connect to 127.0.0.1:3389 to utilize the tunnel to get to the remote host:

You may run into issues if you're trying to do this from a Windows system that is itself also accessible via Remote Desktop, meaning port 3389 on localhost is already taken.  In that case, just change the source port to something else like 3391 in the port forwarding configuration, and connect to 127.0.0.1:3391 from your RDP client, easy as that.

And of course, for those of you that are like me and prefer to use the command-line for things like this, a simple ssh one-liner using something like cygwin:

• ssh -p443 -D1080 -L3391:192.168.1.2:3389 username@your-ssh-server

does the exact same thing as all that GUI PuTTY configuration.

Happy tunneling!

Install Ubuntu 11.04 / 11.10 / 12.04 / 12.10 on an Asus Eee PC 701 4G

Ever since I got my iPad last summer, my grand-daddy of all netbooks, the Asus Eee PC 701 4G, has become somewhat... neglected.  These days it serves as a test bed for various flavors of linux and their respective updates.  I've run the default Xandros, XP Pro (full installation, compressed), Fedora, Ubuntu, and Joli OS (Jolicloud).  Even with XP Pro, all updates, I never had an issue installing any OS within the confines of the tiny 4GB SSD that is soldered on the board of this device.

Leave it to a bug in the latest version of Ubuntu (11.04) to ruin that perfect record.  An issue that I ran into, and subsequently found information about at Ubuntu in Launchpad, is that the Ubiquity installer imposes an arbitrary minimum hard disk size when the actual final installed size of the OS is far below that limit.  Observe.

After creating a bootable USB key with the Universal USB Installer from Pendrive Linux, boot from the key, and at the Installer boot menu, choose Select Run Ubuntu from this USB to boot into a live session of the OS:

Double-click on the icon to Install Ubuntu 11.04.  At the Welcome window, Select your language, and use Alt-Left Click anywhere in the window to drag it up to click the Forward button, since the massive 800x480 resolution of the Eee PC isn't QUITE able to fit it all on-screen.

On the Preparing to install Ubuntu window, you'll see the specifications that you'll need "For best results" including:

• has at least 4.4 GB available drive space
• is plugged in to a power source
• is connected to the Internet

This time, when you Alt-Left Click-and-Drag the window up, you'll find that the Forward button is greyed out.  So really instead of being suggestions for best results, these are actually requirements to even continue with the installer!  Finks.

Click the Quit button to return to the Ubuntu desktop.  Hit Alt+F2 and type:

• gksu gedit /usr/lib/ubiquity/plugins/ubi-prepare.py

Then on line 310 of that file, change the "fudge factor" from

• min_disk_size = size * 2

to

• min_disk_size = size * 1.4

Update: For Ubuntu 11.10, the same bug rears its ugly head, but instead of line 310, it's now on line 250.
Update 2: For Ubuntu 12.04, the file is now /usr/lib/ubiquity/ubiquity/misc.py, line 796.
Update 3: For Ubuntu 12.10, the file is still /usr/lib/ubiquity/ubiquity/misc.py.


Click the Save button, exit the editor, and then double-click on the icon to Install Ubuntu 11.04 again.  Proceed through all the same windows, and this time you should find that the Forward button is no longer greyed out.  Hey, would you look at that!

Feel free to check the boxes to "Download updates while installing" and "Install this third-party software," and click the Forward button.  Once you finally get to the point where you get the Installation Complete message, click on the Restart Now button, go ahead and restart.  Once you login for the first time, run the Update Manager for any additional updates that didn't get picked up during the course of the installation.  When you open up a Terminal window, and run:

• df -h
• cat /proc/cpuinfo 

you will notice a few things.  First, the final installed size of the OS is actually only around 2.7 GB instead of the 4.4 GB that the installer was requiring .  Second, even though the processor in this netbook is a Celeron M 900, it is downclocked to 630 MHz.  This is fairly common, also happened by default with XP.  In both cases, additional utilities are required to get that back up to 900 or higher for better performance, but poorer battery life obviously.

Not that I'm playing favorites or anything, but for comparison purposes, a Fedora 15 installation on the same hardware comes out to a final installed size of 2.5 GB, and a clockspeed of the full 900 MHz, out of the box.

Anyway, hope that helps if there's any of you out there that are like me, a closet hoarder of technology, always looking to repurpose older tech, rather than dispose of or recycle it.  You can have my gadgets... if you can pry them from my cold dead fingers!

Forcing a Screen Resolution in Fedora 15

I love linux.  I really do.  It's gotten better and better over the years with functionality, hardware detection, and user friendliness.  Where it still falls flat on its face however is when something doesn't work as expected, most times it requires digging into some obscure configuration file somewhere to put in a custom fix, and Google becomes your best friend.  That and the fact that it's getting all GUI and bloated like Windows.  Ugh. ;-P

Anyway, I just wiped out my Fedora 12 linux server in order to install Fedora 15, primarily due to lack of updates for 12, but also just to play with the new GNOME 3.0, GNOME Shell, and service management tools.  I usually have it running headless, but every once in a while, do need to do something GUI based.  That's when I plug it into the nearest monitor, my trusty 4-year old 47" Vizio GV47LF.  This TV is fully 1080p (1920x1080@60Hz), but for whatever reason, it gives out incorrect EDID information over its VGA connection.  Its claimed maximum resolution is only 1360x768@60Hz.  This issue affected any operating system that I've had plugged in via VGA in the past, requiring custom fixes like using SwitchResX in Mac OS X (10.5.8) or PowerStrip in Windows.

With Fedora, I never bothered searching for a fix, as I usually connected to it via ssh and just didn't care enough to bother with it.  Had some time over the weekend to poke around and put together a pretty decent fix that should work well for most of you in a situation like mine where your monitor just isn't playing ball nicely.

First, after logging in, open up a Terminal and type:

xrandr -q

This should return to you a list of resolutions and refresh rates that the system is being told by your monitor that it supports.  In addition, you'll find the name of the output that the system has assigned to your monitor at the start of the second line.  The man pages refer to it as VGA, for example, but for my particular situation it was VGA1.

Next, you'll need to put together a modeline for your particular situation to outline the true display capabilities that your monitor supports.  In my case it was:

"1920x1080" 148.350 1920 2008 2056 2200 1080 1084 1089 1125 +hsync +vsync

Finally, what you'll need to do is go and edit "/etc/gdm/Init/Default".  This is a startup script that gets referenced whenever X is starting or restarting.  You may want to make a backup copy of the file first, you know, just in case.  You will need root access to modify this file.  Anyway, you'll want to add in three (3) lines right before the "exit 0" at the end of the file:

xrandr --newmode [your modeline here]

xrandr --addmode [your output here] 

xrandr --output [your output here] --mode [your new mode here]

In my example:

xrandr --newmode "1920x1080" 148.350 1920 2008 2056 2200 1080 1084 1089 1125 +hsync +vsync

xrandr --addmode VGA1 1920x1080

xrandr --output VGA1 --mode 1920x1080

Once those edits are added, save the file, and logout.  You should find that the changes take place immediately, and your login screen is now running at the full resolution that your monitor actually supported all along!

Hope that helps!

Something's Not Quite Right...

Ok, so I've blogged about my fake attwifi hotspot using DD-WRT.  I've blogged about setting up a laptop in between that hotspot and the Internet for packet sniffing with Wireshark.  And I've mentioned doing other more interesting things like setting up the Upside-Down-Ternet.  I decided to put my money where my mouth is and build it out myself, potentially for demonstration purposes at our next security awareness presentation at the company I work for.  How many people in an audience of about 50 do you think I can get to auto-connect to my access point, just by virtue of them having their devices in their pockets?  We're about to find out in a couple of weeks.

After reading the main page for the Upside-Down-Ternet, I realized it was slightly more complicated than just running a script.  Turns out I needed to setup a squid proxy, a web server (likely apache), and some image manipulation tools on my laptop in order to automatically intercept Internet requests for linked images coming from my "victims", pull down those images myself for flipping, and rewrite the links to point to the flipped images on my own web server before delivering the web page to the client.  There is a pretty decent write-up about how to do this in a step-by-step fashion, but there are couple of differences/mistakes in certain sections:

• Setting up the proxy - Good
• Setting up the webserver - Instead of:
• sudo chown www-data:www-data /var/www/images
• it should be:
• sudo chown proxy:proxy /var/www/images
• Otherwise you'll end up with all sorts of permissions errors when squid tries to start manipulating and writing image files.
• Image Script - Good
• Networking Setup - Unnecessary, we're going to be taking care of this through our DD-WRT configuration
• Cleaning Up - Unnecessary, you won't be running it for very long. *ahem*

Also, instead of doing all that sudo-ing, I prefer to just "sudo su" once to get a root shell, but maybe that's just me. Anyway, once you've got that all set up, you can go ahead and test it out locally on the laptop first. Open up Firefox and navigate to Edit --> Preferences --> Advanced --> Network --> Settings... --> Manual proxy configuration. Enter 127.0.0.1 Port 3128 for the HTTP Proxy, and check the box to "Use this proxy server for all protocols."

Click OK to accept everything, then try going to your favorite sites to see the effects! Here's a couple of screenshots showing the updated sites that the original creator used:

If you can't get it to connect properly, or it just seems to be hanging, try kicking the services like so:

• service squid restart
• service apache2 restart

and that should work. Now, remember that whole proof-of-concept from the last blog entry? Well, once the router is setup to get Internet access through the laptop, you need to configure it so that anybody that connects to the router, goes through your new proxy. How do we do that? You'll need to use another device to manage the router for this, or you can temporarily connect the wireless interface of your laptop to the router instead of your real Internet connection to create a bit of a circular mess. :) Just remember to disconnect from attwifi and back to your true Internet connection on the laptop before calling it a day. In my case I used my iPad connected to attwifi to perform these steps.

• In the DD-WRT interface, navigate to Services --> Hotspot --> HTTP Redirect.
• Click the radio button to Enable this functionality, then for the HTTP Destination IP, enter in the IP address of the router's assigned gateway, which is also the IP adddress of the laptop's Ethernet interface. You can find that out easily by doing "ifconfig" on the laptop and looking for the IP address assigned to the "eth0" interface.
• For the HTTP Destination Port, enter 3128.
• For the HTTP Source Network, enter the CIDR address without the /24 or whatever your subnet mask might be.
• Click Save and then Apply Settings at the bottom of the page and wait for the router to come back up.

At this point, everything should be good to go! Try it out from any mobile device connected to your router, and voila:

Mogrify has a TON of image manipulation options, so play around and see which one you like the most. In the meantime, I think at this point you probably all want me to come up with a new line of topics to blog about already. Don't worry, have a bunch in draft, coming soon.

Cheers.

Proof-of-Concept Evil Hotspot

So I recently built-out a new computer for the family common area, allowing me to repurpose that laptop for other nefarious tasks.  Ok, not really nefarious, i just wanted to have a decent test bed for trying out some of the latest versions of various flavors of Linux operating systems.  So the first one I'm trying is the newest Ubuntu, version 11.04.  One of the interesting capabilities that's been built into this OS for a couple of years now is Internet Connection Sharing whereby I can actually plug a device into the Ethernet port on my laptop and allow that device to piggy-back off of my laptop's existing Internet connection.  So of course I had to play around with it to see what I could do...

Enabling this functionality is actually extremely easy to do, and is well documented here.  Couple of screenshots to get the point across:

This functionality is extremely convenient in that it even pushes out a DHCP address to the connecting device.  So that's all well and good, but what can we DO with it?

Well, in my first blog post, I talked about how easy it was to spoof a legitimate hot spot's SSID, attwifi in my example, and some of the risks associated with connecting to those.  In my second post, I talked about Wireshark, and how easy it was to sniff traffic passing across the network to which you're connected.  Put 'em together and what have you got?  A method by which you can capture and view network traffic from mobile devices automatically connecting to you, trying to get Internet access.

Here's the setup: Internet connection --> Ubuntu laptop-Ethernet port --> WAN port-Asus WL-330GE Router-"Evil" attwifi network.

After you've configured Ubuntu to share out its Internet connection via the Ethernet port, and either rebooted or restarted the networking, your choice, you should find that the Internet-facing interface has reconnected back up, and the Ethernet interface will be ready to have a private address assigned to it, as per RFC 1918, once you plug in the router.  In my case, it was a 10.x.x.x address.

Now, plug in the wireless router's WAN port to the laptop's Ethernet port, and power up the router.  If it's configured to grab an IP address automatically via DHCP, it should also now have an IP address in the same subnet as the Ethernet interface of the laptop.  The wireless side of the router will now be broadcasting the new "evil" SSID, attwifi in my case.

Connect a "victim" device to the attwifi network, and you should find that you can get Internet access routed through the router --> laptop --> real Internet connection.  Now, run Wireshark on the Ubuntu laptop to capture clear-text traffic like http web traffic, smtp email traffic, telnet or ftp traffic, etc. sourced from your unwitting "victim" device.

One of the gotchas of running Wireshark on Ubuntu is that it will likely complain that there are no network interfaces to start capturing from.  This is because Wireshark needs root access to place those network interfaces into what's called "promiscuous mode," listening to all network traffic, not just that which is only intended for the system itself.  You can either "su" to root, or just "sudo wireshark" in order to get the necessary privileges to get Wireshark the access that it needs, and start capturing on the Ethernet interface of the laptop.  Done deal.

You also have the ability to do things like create a replica of a legitimate hot spot's captive portal to put up once someone connects to your "evil" one.  Then, you can capture a victim's hot spot credentials as well, in addition to their traffic once they've connected to you instead.  How easy is it?  Walk into a Starbucks, connect to their AT&T WiFi network, open up a browser, and when you get to their captive portal, from the File menu, just Save/Save Page As to pull down a copy of the site with all images and source code for your enjoyment.  Modify it to your liking, run it on your own webserver on the laptop, and you can even point to various Hotspot Services from the DD-WRT router firmware.

You can also have some more fun by creating a proxy on your laptop and causing some browsing mayhem doing something like serving up the Upside-Down-Ternet.  Watching the extremely confused looks on your victims' faces might actually be even more fun than just capturing their traffic and logon credentials, etc. :)

So the moral of the story hasn't changed, but let me summarize:

• Disable mobile device wireless when not in use.
• Be absolutely certain of what wireless networks you're connecting to and their legitimacy.
• Use encrypted protocols whenever possible.
• Don't do anything of a sensitive nature, like online banking or file transfers, when out and about using free, likely unsecured, wireless hotspots.

Like those Allstate commercials say, "Be better protected from mayhem like me.  Dollar for dollar, nobody protects you from mayhem like [gobitech]." :)