#making an in-server backup in folder blawg.bak

cp -r blawg blawg.bak

#backup the database

mysqldump -u user -ppassword database-name > blawg-backup.sql

# upgrade the wordpress files

wget http://wordpress.org/latest.tar.gz

tar xzvpf latest.tar.gz

cp -r wordpress/* blawg/

Then I visited http/blawgupdate.php (which I’ve renamed, suckas.) And that was it, really! Many thanks to the WordPress developers for such an easy upgrade.

——-

A visitor sent me an email a few days ago, correcting my hack post for SSH tunneling of HTTP. Jim was his name, and he said that he wasn’t 100 % sure, but that he believed SSH only used the keys for authentication purposes, and that smaller session keys were created on the fly after authentication was successful. Therefore he believed the strength of the encryption wouldn’t be an order of magnitude better than SSL, as I claimed at the end of my post.

I am afraid Jim is correct. The session key size varies from one implementation of SSH to another, but they all support 168-bit triple-DES. This is the default for most OpenSSH installs on Linux and BSD these days. So while 168-bit triple-DES is believed to be better than SSL’s 128-bit RSA, it’s not an order of magnitude improvement.
Thanks Jim, for the correction.

Technorati Tags:
hacks, ssh, tunneling, upgrades, wordpress

Over the past few months, some friends and cow-orkers have come to my site, and invariably I get the “Where are the hacks?!? When you gave me the link, I was excited and assumed the site had all your hacks and tricks?!? What happened?!?” You see, my fellow cow-orkers specially, know me as a man of many technical talents. I can turn any normal workday into a techfest show-and-tell, just by emptying my pockets or laptop bag, or discussing my latest interests.

So without much further ado …

Hack #1 – SSH tunneling for ultra-secure web app administration

I’m a fairly paranoid person. OK, I take that back: I’m a really paranoid person when it comes to my online life, but only fairly paranoid in my real life. And just to set the record straight, simply because I am paranoid and admit it freely, doesn’t mean someone out there isn’t really out to get me! They just haven’t gotten me yet.

I’ve been around the tech block a few decades, and have had Commodore C64 and Amiga demo scene BBSs defaced, and later, a Sega Dreamcast demo scene website and a Yahoo! webmail account taken over, by a prankster who proceeded to send crap to various Dreamcast scene mailing lists I frequented, pretending to be me. With these experiences came lessons that I apply as much as I can. Because of them, I’ve been without security related problems for the last six years.

That’s six years with no virus attacks, no remote IRC bots, no trojans or backdoors installed, no rootkits on my personal computers or servers. Being paranoid pays dividends in serenity. I can sleep at night knowing I’m not sending out spam or aiding in DDOS attacks. Can you say the same, with certainty?

The problem

One of the things I don’t like about the stock WordPress install, is that the administration pages are not secured with SSL. There are various write-ups on how to modify the code to accomplish this, but applying them makes it more complicated to upgrade WordPress. And I want my WordPress upgrade to be as painless as possible, or I’ll just put it off.

One of the reasons I put off upgrading from WordPress 2.0 to 2.0.1, 2.0.2, and finally 2.0.3, is that I had modified my WordPress install with one of these SSL hacks. I could feel the paranoia mount up as I thought “My username and password may be SSL secured, but there are known security holes in WordPress 2.0. I’ll better upgrade ASAP!” So after RailsDay, since I didn’t have any work, I upgraded to WP 2.0.3 and didn’t apply the SSL hack.

You see, I have a secure way of logging in to the admin pages, and still keep the WordPress upgrade as simple as possible. (By the way, this trick works for proxying all web access to a server, it’s not just for WordPress administration.)

Introducing SSH tunneling

SSH is called Secure SHell, and many people just think of it that way. But it does more than that, with secure remote file copying and secure FTP tranfering of files as built-in features. Under the hood of the secure terminal access and file transfers, lies a packet tunneling framework with great flexibility.

With SSH tunneling, it is possible to connect to one computer at one port, and forward the TCP request to any other computer at the same or any other port. This only works for TCP connections, though. UDP-heavy protocols such as BitTorrent peering and seeding can’t travel through “regular” SSH tunnels.

(There’s one kind of SSH tunnel, the SSH SOCKS proxy, that does allow UDP packets through, but only in one direction. So it’s not as effective for P2P tunneling anyhow. We’ll discuss SSH SOCKS proxying and its uses some other time.)

So how do you tunnel to a web host with SSH?

First, using a plain text editor (not Wordpad, Windows people; use Notepad) open your hosts file on your local host (not on the web server.) In Unix the file lives in:

/etc/hosts

In Windows, it lives in: ** usually **

C:/Windows/system32/drivers/etc/hosts

In Windows, the operating system isn’t always installed on drive C and not always in a folder called Windows. But ninety-nine thousand times out of a hundred thousand, it will probably be like this. So don’t sweat it, specially if you bought your Windows PC already set up. And if it wasn’t already set up, you probably already know where you installed your Windows.

The hosts file wil contain a line like this:

127.0.0.1		localhost

While preserving the rest of the contents of the file, change that line to read like this (substitute serverName as appropriate for the web host you want to tunnel to):

127.0.0.1		localhost serverName

Second, install SSH on your local host. If you’re on Windows, this can be Putty or the SSH client for Cygwin. (There are plenty of writeups about both open source Windows products, so use Google search for further help with that.) Most Linux distributions come with at least the SSH client installed. Mac OS X and Solaris come with both SSH client and server software installed.

Third, you need an SSH login account on your web server. Not all shared hosting accounts give shell access, so it may be that you can’t use my little trick. Virtual private hosts and dedicated servers definitely have SSH if they’re Unix-based. If you host your weblog on Windows, you have other problems besides no remote secure shell access. It’s called gullibility. Again, look it up on Google.

Now comes the good part. Once you have installed an SSH client, and have SSH access to your remote server and a shell account, you have to forward port 80 from your local host to the web server, with this command (substitute serverIP and accountName as appropriate; namely, you need the IP address of your web host, or a different domain name that resolves to the same IP as your web host):

ssh -L 80:serverIP:80 -N accountName@serverIP

If you’re using Putty, the command is:

plink -L 80:serverIP:80 -N accountName@serverIP

Make sure your Putty installation is on the command-line PATH. If you don’t know what that is, what are you doing reading this far?!?

Now, when you browse to http://serverName (not serverIP), SSH will tunnel from your local host to the web server, and your connection will be encrypted just a tad better than industrial-strength SSL. Most SSH implementations let you choose from a variety of protocols and session key sizes, such as Blowfish and 256-bit session keys. That’s double the encryption power of the 128-bit RSA encryption in SSL. Ultra-secure, baby! (Thanks to Jim for the clarification.)

And there you have it, PJTrix.com’s Hack #1.

(Soon, I’m putting up a Wiki to collect these. So consider this text as my second draft of this hack. Any comments, improvements, criticisms, are welcome in the comments. Thanks for reading this far!)

Technorati Tags:
open source, hacks, ssh, tunneling