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.
You need only a few items for the project: a USPS Priority Mail envelope, a needle and thread (from the repair kit in your trusty possibles pouch, no doubt), a bit of cord, a cordlock, and a sharp object. You could make the needed cuts with a knife, but scissors are a bit easier. I use the pair on my Leatherman Juice S2, which has replaced the Charge ALX as my daily carry.
The envelope can be new or used. Any post office will have new envelopes available in the lobby, free for the taking. Still, I would feel a little guilty about taking a brand new envelope just for this purpose. There’s plenty enough used envelopes floating around, and it seems a waste to steal a brand new one. I lucked out in that recently someone sent me a package in a box, but, within the box, used the pictured envelope to organize the goods. So the envelope is used, but brand new.
This project also warrants a disclaimer: Priority Mail envelopes, whether new or used, are property of the United States Postal Service. They are intended solely for the use of the postal system and, contrary to logic, just because somebody paid to mail you a package in one doesn’t make it yours (or theirs). So repurposing the envelope in this way is probably a federal offense. Law abiding citizens should immediately navigate away from this page and return to their cells. The rest of us can move on.
The first step in the process is to cut a little square in one corner of the open end of the envelope. No need to measure. Just eyeball whatever looks good. The height of the square will determine the size of the channel which we will sew and then pass the cord through (this one happened to be about 1.5mm).
If you are using a brand new envelope, you’ll want to cut the top bit with the sticky stuff off, so that both sides of the envelope are the same height. On a used envelope, you might have to do some trimming to achieve the same thing, depending on how you opened the envelope.
After the square is cut, fold down the rim of the envelope all the way around, using the height of the square to determine how much is folded. If you want, you can cut a slit in the other corner of the envelope to help fold it down. I did this on the first stuff sack. For this one, I chose not to. There’s a slight bit of bunching in that corner as a result, but it’s fine.
Now that you have the top flap folded down all along the top of the envelope, sew it shut. This creates a channel which we may then thread a bit of cord through, using it to cinch the sack shut.
I start my stitching on the inside of the envelope, poke the needle through, and pull all the thread through except for a tag of about 3”. Then I poke the needle back through in another hole, pull all the thread through back to the inside, and use the tag end of the thread to tie a square knot, thus securing my first stitch.
With the sewing done, now would be a good time for the camera battery to die. Curse a little, perhaps shed a tear, then decide that your audience is intelligent enough to struggle through the next steps without pictures.
For this stuff sack, I used ALSE survival vest cord, also known as accessory cord or Type I paracord. This stuff has a breaking strength of 100 lbs, is 1/16 of an inch in diameter, and tips the scale at 1oz per 50 feet. Pick it up at Supply Captain. You could use any cord you happen to have, including the standard (Type III) 550 paracord, but I don’t think the cord on this little stuff sack needs to have a breaking strength of 550lbs and Type III paracord is much, much heaver than Type I. We’re trying to go lightweight here.
Threading the cord through the channel can require a little perseverance. I usually tie a knot in one end, stick it in, and then use the knot to push the cord along with my fingers from the outside. If need be, you can shove a skinny stick or something in there to help it along.
When the cord comes out the other side, all that’s left is to cut it to length, slide the cordlock over both ends, tie some sort of knot so that the cordlock can’t be inadvertently slide off the cord, and you’re done!
The resulting stuff sack is durable, lightweight, and free (or close to it, depending on what materials you have in your craft box). Though you’re obviously not going to get a water-tight seal by cinching the sack closed, the Tyvek material itself is waterproof and will suffice to keep your gear organized and dry in any pack. If water crossings and momentary submersion is a concern, use a trash bag as a liner in your pack and you will be very well off for almost no cost in weight or money.
Lighter, stronger, more waterproof, and better constructed stuff sacks can of course be purchased, but for an exponentially higher price. I have nice stuff sacks for my sleeping bag and spare clothes, so, for the time being, this Tyvek stuff sack is used for my food.
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:
(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.
1
$ 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:
1
$ 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.
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:
This is a good time to protect SSH by installing DenyHosts, which I discuss here:
1
$ sudo aptitude install denyhosts
Ubuntu’s default text editor is nano, which I abhor. Real men use vim. Ubuntu comes with a slimmed down version of vim, but you’ll probably want the full version:
1
$ sudo aptitude install vim
To change the global default editor variable, execute the following and select the editor of your choice:
1
$ sudo update-alternatives --config editor
This is also a perfect time to install GNU Screen.
# Print a pretty line at the bottom of the screen
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{Y}%Y-%m-%d %{W}%c %{g}]'# Nobody likes startup messages
startup_message off
# Turn visual bell on and set the message to display for only a fraction of a second
vbell on
vbellwait .3
# Set default shell title to blank
shelltitle ''# Gimme my scrollback!
defscrollback 5000# Change command character to backtick
escape ``# Stop programs (like vim) from leaving their contents# in the window after they exit
altscreen on
# Default screens
screen -t shell 0
I prefer to have my bash profile setup to connect me to Screen as soon as I login. If there are no running sessions, it will create one. If there is a current session, it will disconnect the session from wherever it is connected and connect it to my login. When I disconnect from screen, it automatically logs me out. To achieve this, I add the following to ~/.bashrc:
12345
# If possible, reattach to an existing session and detach that session# elsewhere. If not possible, create a new session.if[ -z "$STY"];thenexec screen -dR
fi
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.
Now, check your email as user by running mail. See the message? Good.
Open /etc/postfix/main.cf to make sure that Postfix knows what domains it’s receiving mail for. To do this, edit the mydestination variable to include all the proper domains. For me, the name of my server looks like server.mydomain.com. I want Postfix to accept mail for that domain, but not for mydomain.com (since that’s being handled by Google Apps), so mine looks like:
Right. Now let’s send another test. Notice this time we’re using full domain names, instead of localhost:
1 2 3 4 5 6 7 8 910
$ telnet server.mydomain.com 25
ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: domains!
woot... I think this works.
.
quit
Working? Good.
Let’s test from the outside. The first step is to open up the correct ports in the firewall. Assuming you have iptables configured in the way the Slicehost article suggests, open up your /etc/iptables.test.rules and add the following:
# Allow mail server connections
-A INPUT -p tcp -m state --state NEW --dport 25 -j ACCEPT
And now, from your local computer, let’s test it out.
1 2 3 4 5 6 7 8 910
$ telnet server.mydomain.com 25
ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: remote connection test
Hello, you.
.
quit
Now check your mail on the mail server as before. Once again, everything should be working.
Now we need to setup a virtual domain. Remember, I don’t want any virtual users. I only want aliases at a virtual domain to forward to my primary email address. That makes this relatively simple. (Be very, very happy. You should have seen this guide before, when I was still hosting virtual domains with virtual users!) Open up /etc/postfix/main.cf and add the following:
Create the /etc/postfix/virtual file referenced above and add the aliases:
alias@myvirtualdomain.comuser@mydomain.com
Turn it into a database:
12
$ cd /etc/postfix
$ sudo postmap virtual
Restart Postfix:
1
$ sudo /etc/init.d/postfix restart
Attempt to send an email to the new alias at the virtual domain:
123456789
$ telnet server.mydomain.com 25
ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: alias@myvirtualdomain.com
data
Subject: virtual domain test
I hope this works!
.
quit
The message should now be in your primary email inbox!
As long as we’re setting up forwards, let’s forward system account mail to somewhere where it’ll actually get read. To do so, create a ~/.forward file with the following contents:
user@mydomain.com
Let’s also create a /root/.forward, so that roots mail gets forwarded to my local account (where it is then forwarded to my primary email). Root’s forward would simply read:
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.
First, we need to install the web server. Nginx is now in Ubuntu’s repositories:
Next up, we’ll need to install MySQL and PHP, and get them working with Nginx.
Slicehost has a guide for installing MySQL and Ruby on Rails, which also includes suggestions on optimizing MySQL. I follow the MySQL part of the guide, stopping at “Ruby on Rails install”.
To get PHP as FastCGI working with Nginx, we first have to spawn the fcgi process. There are a few different ways to do that. Personally, I use the spawn-fcgi app from lighttpd. To use it, we’ll compile and make lighttpd, but not install it. We’re only after one binary.
Lighttpd has a few extra requirements, so let’s install those:
1
$ sudo aptitude install libpcre3-dev libbz2-dev
Now, download the source and compile lighttpd. Then copy the spawn-fcgi binary to /usr/bin/:
123456
$ wget http://www.lighttpd.net/download/lighttpd-1.4.19.tar.gz
$ tar xvzf lighttpd-1.4.19.tar.gz
$ cd lighttpd-1.4.19
$ ./configure
$ make
$ sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi
Then, create a script to launch spawn-fci (I call it /usr/bin/php5-fastcgi):
The script tells spawn-fcgi to launch a fastcgi process, listening on 127.0.01:9000, owned by the web user, with only 2 child processes. You may want more child processes, but I’ve found 2 to be optimal.
Give the script permissions:
1
$ sudo chmod +x /usr/bin/php5-fastcgi
I then link the script filename to a version-neutral, err, version:
Alright, now that PHP is running how we want it to, let’s tell Nginx to talk to it. To do that, add the following to your vhost server block in /etc/nginx/sites-available/mydomain.com, making sure to change the SCRIPT_FILENAME variable to match your directory structure:
Let’s create a file named test.php in your domain’s public root to see if everything is working. Inside, do something like printing phpinfo.
Go to http://mydomain.com/test.php. See it? Good. If you get “no input file specified” or somesuch, you broke something.
If you create an index.php, and delete any index.html or index.htm you might have, you’ll notice Nginx throws a 403 Forbidden error. To fix that, find the line in your vhost config (/etc/nginx/sites-available/mydomain.com) under the location / block that reads index index.html; and change it to index index.php index.html;. Then restart Nginx.
There is one bug in the second guide. In the first server module listening on port 443, which forwards www.domain1.com to domain1.com, the rewrite rule specifies the http protocol. So, in effect, what that rule does is forward you from a secure domain to unsecure: https://www.domain1.com to http://domain1.com. We want it to forward to a secure domain. Simply change the rewrite rule like thus:
Nothing further is needed, unless you want fancy rewrites. In that case, we’ll have to make a change to your Nginx vhost config at /etc/nginx/sites-available/mydomain.com. Add the following to your server block under location / {:
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:
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.)