Sleep Is For The Weak

After having a discussion with another admin in the Indianapolis area, and thinking about who my target audience likely is, I’ve decided to scrap talking about various encrypted tunnels.  Instead I’m going to talk about best practices, and the dos and don’ts of surfing on a public WiFi access point.

Earlier I talked about Email and how not using encryption gives anyone who’s listening access to your username, password, and server address.  Most good mail providers allow for the use of SSL to encrypt communications between your client and the server.  If yours does, you likely only need to check a single check box inside the configuration, and you are golden.  Check with your provider to see if they support encryption, and if they do, ask them to help you configure your client.  If you use gmail, you’re already using encryption as you are automatically forwarded to the https:// site.  I have mail on two or three servers that don’t support the use of encryption.  I set all of these accounts up to forward to a gmail account so that I can easily and securely read my mail from anywhere.

While taking about web based technologies, any financial site worth its salt is going to support, or better still, force you to use the SSL encrypted version of its site.  Look for https:// at the beginning of the URL in your address bar.  Sites like Facebook, Flickr, Meetup, etc., may or may not support the use of SSL.  I recommend trying it.  If the site you want to use does not support SSL and wants you to log in, you might reconsider your visit if you’re on a public network.  The last thing you want is some tool at a coffee shop logging into your Linked-In page spamming all your co-workers about how they need E.D. medicines.

I welcome comments from the community of readers I have, all three or four of you, on other best practices you can use to help protect you while surfing on untrusted networks.

Thanks to: Villoks for the image.

I’d just like to toss a link in the direction of a pretty good resource for hams looking to get involved in the world of Linux.  These guys [Linux In the HAM Shack] run a pretty regular podcast you can download via the iTunes Music Store.  It’s not bad actually.  I’m primarily a BSD user personally, but everything they are talking about applies to most modern Unix like operating systems.

Past topics have included: Rig Control, Digital Modes, Logging Software, and all other forms of computer related ham radio topics.  K5TUX, KB5JBV thank you for the resource.  I look forward to future pod casts.

It’s no secret that Free WiFi connections are everywhere.  It’s easy today if you have a laptop or smart phone to get online virtually everywhere.  It’s convenient, too.  What could be better than being able to get a little work done or checking your e-mail while drinking a redeye at your favorite coffee shop?  However this free access comes at a pretty hefty expense to the security unconscious.  I wouldn’t go so far as to say I’m paranoid, although I’m pretty sure they’re watching me right now……  Ok, seriously I’m not exactly paranoid.  I’ve just been working in this industry long enough to know what is and what is not safe.

I’m going to start with a brief lesson in technology.  When you are at home, connecting your laptop to your personal WiFi connection, chances are you are using, at a bare minimum, WEP, possibly WPA, and if you’re using a new computer on a new access point, WPA2.   These links require you know some code in order to access them and establish encryption between your wireless device and the access point.  This prevents your neighbors from seeing what exactly it is your laptop is accessing on the internet and prevents them from stealing your internet connection to download their pirated warez.  (If you’re not using some form of encryption, go find the manual that came with your router and fix it right now.  This article will be here when you get back.)  So, WEP, WPA, and WPA2 all provide encryption between your device and the router.  Very rarely are your Free WiFi links going to be running any form of encryption though.  This means anyone with a laptop within range of where you are, who would like to, can see everything you’re doing on the net.  If you log into your mail using standard POP or IMAP they can capture your username, password, and mail server information.  This doesn’t require anything terribly special on their end either as you are transmitting it for the world to see.  The other concern you should have is the owner of the Free WiFi.  If I set up an access point in my home and configure its SSID as “Free Public WiFi,” what is to prevent me from using packet capturing techniques on the router itself?  Do you trust the hotel you’re staying in to value your privacy?  How about the guy running the trendy coffee shop?  I sure don’t, and I don’t think you should either.

So what do you do about it?  There are a few ways to mitigate the risks associated with public internet access.  In the next series of articles I will try to present them in more detail.  In brief you can use a VPN, SSH Tunneling, or the Tor Onion Router.  These aren’t the only solutions, however they are all supported on all three major platforms, Windows, OS X, and Linux.

Thanks to: Tim D for the image

In my day job I administer roughly 50 servers.  Most of these are running FreeBSD between versions 6.0-Release and 7.2-Release.  Three or Four of them run CentOS 5.x, and one runs OS X Server.  We have had a single Windows XP virtual Machine on the network since before I started running QuickBooks, and as you might expect it’s one of the most problematic “servers” on our network.

One project we have running in the background is relocating servers from our west coast datacenter to our Indianapolis datacenter.  The first round of machines made the trip a few weeks ago and have been sitting on a shelf waiting for their new tasks.

One of the machines is old enough that we were unlikely to put it in production as a customer server.  This machine, a 2.4ghz NetBurst Xeon with 4gb of ram and two 75gb hard disks, is a perfect candidate for replacing our QuickBooks VM.

In a previous life I was a Windows Administrator.  I’m not proud to say it, but it’s true.  While doing that job I went to a few events hosted by Microsoft.  At one of these events Microsoft gave away Windows Small Business Server 2003 Premium Edition with 10 user CALs.  Since I have no intent of ever running this software at home, I decided to donate it to the office.

SBS 2K3 is a long way away from what we would normally run in the office, but it is an actual server OS that will support more than 1 user accessing it via Remote Desktop at a time.  This coupled with real hardware over a VM leaves us with what I hope will be a much more stable platform for our accounting folks to do their work.

I can’t help but feel a little dirty installing and configuring it though.

Thanks to: Martain Eian for the image

After troubleshooting with our customer and determining there appears to be a problem with the bge driver in FreeBSD 7.0-Release on this specific class of server we decided to upgrade the customer’s server to FreeBSD 7.2-Release.  We scheduled the work for 23:00 one evening during the week, and expected up to an hour or so of downtime.  The process for upgrading FreeBSD versions is well documented and I won’t go into the details here.  Feel free to consult the fine documentation located on the FreeBSD website.

We completed the upgrade at about 01:00 the following morning and confirmed that all the network services came up clean and the hosting environment was in good shape.  We have never been able to reproduce the problems our customer had seen so we sent an e-mail off to him letting him know the upgrade was done, and we would like him to contact the affected people and have them test connectivity to his server.  I received the following couple of messages a few hours into the following day.

Hey, I just got a report from one of the affected people. They’re connecting!!

——

Just heard from 2 others that they can now connect.
A third person reported that she fixed the problem some weeks ago by changing
ISPs.
There are 4 that haven’t reported in yet but I feel confident the issue is
truly resolved.

Well done!

I’m sure we could have figured out exactly what Windows was doing differently than Linux by putting a breakout hub between the laptop and the cable modem at the customer’s end, as well as between the server and router.  Then run something like Wireshark on each end to capture what things look like on each side of the link.  However that sounds like a lot of work, would have required a somewhat more technically savvy person at the customers site, and a trip to the Colo….  All in all upgrading to the latest release version of the OS is something we need to do anyway, and it had the added benefit of solving our problem.

I’m all for suggesting customers use proper operating systems on their computers.  However we all know that’s not going to be a valid response.  73!

Thanks to: krtower for the image

Continuing where we left off with Difficult Diagnosis – Part 1, when our customer attempts to connect to the website tcpdump on the server shows zero traffic incoming from his IP address.  He can ping the server, but cannot access the server with telnet, ssh, http, or ftp.

To eliminate the server’s IP as the problem a new IP address is aliased on the server.  It shows the same result.  We move this newly aliased IP address to another similar server.  Surprisingly it also fails to show any traffic from your customer when he attempts to connect.  We move the IP address again to a third server which has different hardware than the first two.  Now when the customer attempts to access the server he’s successful.  Finally we move the IP address to a fourth server which is the same hardware as the first two, but running FreeBSD 7.1-Release a slight upgrade over FreeBSD 7.0-Release which is on the first two servers.  He is also able to access this server.

This class of machine previously caused similar problems.  We disabled all of the TCP offload engine features suspecting the driver is buggy on FreeBSD.  These features were already disabled on all of the servers we were testing with.  Our working theory is that the driver in FreeBSD 7.1-Release has been improved slightly over the previous version.  We are planning on upgrading our customers server to the newer operating system.  If that fails to solve the problem, our next step is to add a NIC to the server, most likely an Intel Pro1000 (em0) NIC.

How would you have handled this scenario?  What troubleshooting steps would you have taken differently or in addition to steps that were taken?

Thanks to: Qfamily for the image

Here’s a fun scenario for you.  A customer of yours mentions that three customers of his are unable to access any websites hosted on your their server.  These same three customers can access six other websites hosted in the same network rack, on the same block of IP addresses.  Your customer offers to go out to one of the affected users home with their laptop which dual boots Ubuntu 9.04, and Windows Vista.  He arrives to find out that the affected users computers are both in the shop due to a virus.

Your customer fires up his laptop running Ubuntu, pulls up Firefox 3.0.10, types in the URL of one of his websites, and….  Wouldn’t you know it.  The site comes up without a hitch.  On a whim before leaving the users home, after sending a message to the effect of “Apparently it works.” he reboots to Vista, pulls up Firefox 3.0.10, types in the URL of the same website and….  It fails to load giving a generic “Can’t connect to server” type error message.

How do you troubleshoot this with your customer over the phone.  You have root access to the server.  And he’s at the affected users site able to reproduce the problem.  What steps would you take?

Continued……

Thanks to: Cycle60 for the image

In this fifth and final installment I would like to discuss using Varnish to further improve the performance of your website.  Varnish is a state-of-the-art, high-performance HTTP accelerator.  What this actually means when you remove the buzz words and replace them with English is that Varnish is a reverse caching web proxy.  When we think about caching web proxies we usually think of something that sits on a corporate network that caches incoming web content so that sites that see a lot of traffic have most, if not all, of their content stored locally.  A reverse proxy works exactly the same, but not.  When we run dynamic websites like WordPress, Joomla, Plone, or Drupal, each time a page is loaded the PHP script has to pull data from the database, render a static .html page and serve that static page to your browser.  Earlier we talked about a plugin for WordPress called WP-SuperCache which does cache these pre-rendered files and serves them from the file system.  Not all content managers have a plugin like WP-SuperCache.  Also WP-SuperCache still has to check the database to determine if the content it has cached is fresh or if it needs to be updated on every page load.  Finally WP-SuperCache must run on the server that is running WordPress.

A typical dynamic web server will look something like this:

Basic Dynamic Server Configuration

Enter Varnish.  Varnish, like the caching web proxy at your office, is a proxy.  It sits between my nginx web server and your browser.  The difference is, while your proxy at work is configured to cache the content of many websites and serve that cached content to users within your office, Varnish is configured to cache the content of only one website.  Varnish serves that cached content to everyone who attempts to visit the site.

A typical dynamic web server with Varnish will look something like this:

Cache Enabled Basic Server Configuration

Varnish can also be made aware of more than one backend server.  Which means I could have a single internet facing varnish server, and two or more load balanced web servers behind it.

Two options for how this might be configured are laid out here:

A Load Balanced configuration

Scaled, high performance, load balanced configuration

Varnish is also able to add, remove, modify, or otherwise mangle the headers passed from the server to your browser.  You can strip cookies, add content expires, and a whole host of other things.  Things like expires headers can be used to make the client cache content such as images, style sheets, and javascript in their browser on their local machine.  That is the fastest way to serve content as it eliminates the network completely.  Varnish really is a fantastic product for accelerating your dynamic website.

Because my connection at home is nowhere near fast enough to really benchmark my new server, especially with Varnish in place, I decided to run ApacheBench locally.  To give you something to compare against I ran it against my single backend server, as well as against the Varnish front end.

Completed Requests:  17316 vs 50000 a 65.368% improvement

Requests Per Second: 34.63 vs 219.305 a 83.99% improvement

Time Per Request:  28.88 vs 4.39 a 22.63% improvement