All posts by Zanzibar McFate

Stupid Problems Deserve Stupid Solutions

I recently got handed a pretty decent Vista-era Lenovo laptop, which on inspection, turned out to have no hard disk in it. I invested $30 in a 250GB SATA disk, and decided I’d have a go at setting up Kali Linux just to check it out.

I’m very impressed. It’s well-put-together and well-documented, there’s a good IRC channel on freenode, and it’s got most of what I want in a development workstation.

I did run into one little problem setting some things up, though. Apparently, prior version 1.0.8, lsb_release reported a codename of “n/a”, which causes the nodesetup.sh script to barf. That was reported as fixed, but it seems to have regressed in the latest version, 1.0.9a.

After fooling around with a couple of candidates to fix the problem — and does anyone know the right way to fix this…? Ugly details below — I broke down and just hacked the setup script.

The core problem is that lsb_release -c -s is returning “n/a”, and causing the script to decide that this isn’t a distro it knows how to support. Here’s the (stupid) fix.

First, pull down the setup script from the NodeJS site and save it to a file so we can patch it:

curl -sL https://deb.nodesource.com/setup > nodesetup.sh

Next, open nodesetup.sh in an editor and look for the following section:

check_alt "Linux Mint" "rebecca" "Ubuntu" "trusty"
check_alt "Linux Mint" "qiana" "Ubuntu" "trusty"
check_alt "Linux Mint" "maya" "Ubuntu" "precise"
check_alt "elementaryOS" "luna" "Ubuntu" "precise"
check_alt "elementaryOS" "freya" "Ubuntu" "trusty"

Edit it to all a line to the end as follows:

check_alt "Linux Mint" "rebecca" "Ubuntu" "trusty"
check_alt "Linux Mint" "qiana" "Ubuntu" "trusty"
check_alt "Linux Mint" "maya" "Ubuntu" "precise"
check_alt "elementaryOS" "luna" "Ubuntu" "precise"
check_alt "elementaryOS" "freya" "Ubuntu" "trusty"
check_alt "Kali" "n/a" "Debian" "wheezy"

Now, pass the script to bash as intended. This will set up the repos correctly to get node.js and its dependencies as though you were running on a stock Debian “wheezy” system.

cat nodesetup.sh | bash -

It should complete without a problem. Now, you can install nodejs and npm:

apt-get install nodejs

Gory Details

I’m unclear on where the code name reported by lsb_release gets set up. A couple of candidates which didn’t work: attempting various edits to /etc/os-release didn’t help nor did modifications /etc/dpkg/origins/default which is an aliased for /etc/dpkg/origins/kali. Anyway, it worked, nodes and npm are in and check out.

Building a Customized PirateBox, Part 1: Build a PirateBox

I wanted to have something fun and portable that I could use to promote the software literacy effort I’m spinning up here, and I thought it would be great to make a PirateBox that I could “re-brand” and use to share files and a microsite about what I’m doing and why it’s important.

The PirateBox project has spawned a number of customized versions, like LibraryBox, BibleBox, and others. I’m calling the one I’ve put together “nanonet”, and you can see a version of the web site it runs here.

What You’ll Need

  • A TP-Link TL-MR3040
  • A small USB drive — you only need the room for the base PirateBox install, under twenty megabytes, plus whatever space you’ll need for the web site you want to serve plus any files you want to share.
  • A Debian 7 “Wheezy”-like system with an Ethernet port that you can dedicate to this for a little while

I did my build on Linux Mint 17, but this will probably work on any Linux command line.

Considerations

A “vanilla” PirateBox offers a chat window, a forum board, and the ability to upload and download files, in addition to its single-page HTML site. For my application, I wasn’t really interested in having people upload to the device, I just wanted to make material available for people to download.

The only “administrative” access to the PirateBox is via the Ethernet port, so there aren’t really any security issues to worry about on a device like this.

Overview

The TL-MR3040 is, in today’s terms, a tiny device, although in the mid-to-late ’90s, it would have been more or less the equal of a reasonably powerful PC. Its biggest limitation is internal storage: it’s got 16MB of RAM, and only 4MB of flash memory to play around with.

That’s going to limit what we’ll be able to put on the device, and aside from what’s needed to make PirateBox itself run, we’re going to limit ourselves to an index page, the stuff needed to support it (e.g. minified jQuery, etc.) Every thing else can go onto the USB drive, in a “Shared” directory.

We’re going to take things in the following order:

  1. Reflash the TL-MR3040 with the PirateBox version of OpenWrt 12.09 “Attitude Adjustment”.
  2. Do the first-time OpenWrt set-up.
  3. Install PirateBox v1.0

That much is going to be a lengthy posting in and of itself. In part 2, we’ll

  1. Extract an image of the on-board PirateBox web site from the install — this is the only portion where I actually used Linux, everything else was done on OS X
  2. Throw away the index page, and replace it with one of our own
  3. Implement the rest of the web site in the shared directory on the USB drive
  4. Customize things like the SSID of the WiFi network, the favicon, etc., to reflect the new “branding”

Installing OpenWrt “Attitude Adjustment” (PirateBox Edition)

Check which version of the MR3040 you’ve got, there are two different firmware versions, and you can brick your device if you try to reflash it with the wrong one.

To do this, take off the back — you’ll need to do this to install the battery anyway — and look at the barcoded label stuck on the label underneath where the battery goes. This photo shows the label on a v2.2 device, as indicated. For this one, we’d want v2 firmware. Do not guess at this. Be sure to check.

IMG_1145

For a version 2 device, you will want http://stable.openwrt.piratebox.de/auto/openwrt-ar71xx-generic-tl-mr3040-v2-squashfs-factory.bin

For a version 1 device, you will want http://stable.openwrt.piratebox.de/auto/openwrt-ar71xx-generic-tl-mr3040-v1-squashfs-factory.bin

In either case, get a copy of http://stable.openwrt.piratebox.de/auto/install_piratebox.zip, and expand it. Put the resulting folder, called install, onto your FAT-formatted USB drive. Do not insert the USB drive into the MR3040 at this time.

Again, be sure you’ve gotten the correct bin file for your device!

Start by installing the battery and plugging the MR3040 into a powered USB port via its own mini-USB port to charge it up. Both of mine have arrived with flat batteries. This will take an hour or two.

Configure the Ethernet port on your system. The MR3040’s factory configuration uses the link-local IP address 192.168.0.1 on its Ethernet port, so we want our system to have an address on the same network that won’t collide. 192.168.0.2 is fine.

To set it up on OS X, choose “System Preferences” from the Apple menu, then double-click on “Network”.

In the Network control panel, select your Ethernet port in the sidebar and then choose “Using DHCP with manual address” from the pop-up menu. Enter “192.168.0.2” in the box below the pop-up and click “Apply”.

System PreferencesScreenSnapz004

Connect the MR3040 to your computer’s Ethernet port — they include a short cable in the box — slide the 3-way switch on the side to “3G/4G”, and turn it on. It takes a little while to boot, but you can check to see when it’s up with the command

ping 192.168.0.1

at a Terminal command line. When you start getting responses to the ping, open up a browser window and enter the URL http://192.168.0.1

The browser will ask you for a user name and password. For a new TL-MR3040, these are admin and admin. This will get you to the Administration app for the TP-Link software.

Click on “System Tools” in the sidebar menu, then on “Firmware Upgrade” when the accordion menu opens. That will get you to this screen. Note that the factory firmware version for the device is shown here. In this case, it’s v1, more than likely, yours will be v2.

Be very sure that the version of the firmware that you’ve gotten from the PirateBox site is the same as the version shown here. You can brick your device if you mix them up, and you’re a lot better off bricking your device after you’ve successfully installed OpenWrt than you are before, for reasons we’ll discuss another time.

tl-mr3040-upgrade-firmware-2

Click the “Select” (or “Parcourir”) button to the right, and choose the bin file you downloaded earlier.

A scroll bar will appear indicating the progress of the firmware update. DO NOT INTERRUPT POWER ON THE DEVICE WHILE THIS IS GOING ON. While you’re waiting, go back to your Ethernet preferences panel and change the address you’re using from 192.168.0.2 to 192.168.1.2, since when a new device comes up on OpenWrt, it uses the default address 192.168.1.1.

Bring up a terminal window, and start pinging that address with the command

ping 192.168.1.1

When you start getting a response to your pings — and it can take a while, maybe ten or fifteen minutes — we can proceed to the next step. (If you’re not getting ping responses after twenty minutes, the most likely problem is that you haven’t reconfigured your own system’s Ethernet port correctly.)

First Login to OpenWrt

Initially, OpenWrt only allows telnet access, has a single user, root, who has no password set, so the very first thing we want to do is telnet in and set that password.

telnet 192.168.1.1

When prompted to log in, enter root and hit return. You should see this:

PB-openwrt-telnet

Once you see this screen, you’re talking to ash, the OpenWrt command shell. Change the root password:

passwd

You’ll be prompted to enter your new root password twice. Choose something you won’t forget! Assigning a password to root will “activate” OpenWrt, and once we’ve closed the telnet connection, we’ll only be able to access the system via SSH from that point on, so you’ll need to use the command

ssh root@192.168.1.1

When you’re prompted, enter your password, and you should be back at the OpenWrt command prompt shown above.

We’re now ready to complete our PirateBox installation. Get out of the telnet (or ssh) connection by typing

exit

and power off the MR3040.

Install PirateBox

Finally, we’re ready to install PirateBox v1.0 onto our newly-configured TL-MR3040. This part is easy.

With the power still off, insert your prepared USB drive — FAT-formatted, with the install folder you unpacked from the file install_piratebox.zip you downloaded earlier — into the USB port of the MR3040.

Turn the power on. Go do something else for fifteen minutes or so.

What you’ll observe, if you watch it, it a lot of blinking and flashing, occasionally interrupted by short periods when only the power light is lit — that indicates that the MR3040 is rebooting, which is does three or four times before the installation is completed.

After about the third reboot, if you scan your local Wifi networks, you’ll see the network “Piratebox — Share Freely!” appear. You can connect to that network, but it may go away if the install hasn’t actually completed yet.

Once you’ve been able to get onto the Wifi network that the MR3040 is creating, open a new browser page, and navigate to any address you haven’t browsed recently — caching can confuse things — or just go to http://piratebox.lan, the name the Piratebox uses to refer to itself. You should see this.

piratebox-lan

Congratulations! You’ve just created a PirateBox, a tiny self-contained web server based on a tiny version of Linux.

Explore and have fun — you can upload and download files, put up messages on a forum, or leave brief notes on the home page. It turns out that, when you’re out with a crowd, a PirateBox can be an easier way to share around things like photos rather than having to email them.

In part two, we’ll dig a little deeper into the internals of PirateBox and show how you can put pretty much any sort of a web site onto one.

If you follow this tutorial, please let me know how things worked out for you in the comments. If you run into snags, I’ll do what I can to help out.

Easy Build for OpenWrt On Ubuntu/Debian

I just got a TP-Link TL-MR3040 a few days ago, and successfully set it up as a PirateBox, which involved refreshing the firmware with OpenWrt rather than a stock image. This is actually a pretty cool little device for the $35, it’ll run Linux, and with OpenWrt, not only can it function as a router, it can act as a tiny server running off a file system attached via USB.

I’ve tried this build on multiple platforms, and documented some of that in a previous version of this posting. While I’ve successfully gotten the core of OpenWrt to build on OS X, and a number of things to build on CentOS, I’ve only gotten consistent and reliable results overall on Debian-like systems, so that’s what I’m going to be sticking to here.

In particular, I’ve had nothing but trouble trying to build an OpenWrt image for a Raspberry Pi anywhere other than on Debian or a Debian derivative. I have verified working builds for both the TL-MR3040 and the Raspberry Pi on Mint 17.

The instructions for building a firmware image on the OpenWrt wiki are a version or more out of date — they’re for building Attitude Adjustment, rather than Barrier Breaker.

The procedure for building top-of-trunk for OpenWrt developers is better documented than the Attitude Adjustment build seems to have been, but still a little bit scattered.

Additionally, the guide for setting up a build environment on OS X relies on MacPorts, and I prefer Homebrew, is similarly outdated, and there are a wrinkle or two along the way, so I figured I should document what I’ve done. I’m not recommending, at this point, that you try building this stuff directly on OS X. Use a VM running Debian or Mint instead, that’s my recommendation.

Set Up the Prerequisites

On Ubuntu 14.04 LTS “Trusty Tahr”/Debian 7.7.0/Mint 17

sudo apt-get install subversion build-essential libncurses5-dev zlib1g-dev gawk git ccache gettext libssl-dev xsltproc zip

On OS X 10.10 “Yosemite”

On OS X, we’ll want to specifically set up a case-sensitive file system to work on. We can create a .dmg file that we can use for our development with the following commands. Twenty gig is plenty of space.

hdiutil create -size 20g -fs "Case-sensitive HFS+" -volname OpenWrt OpenWrt.dmg
hdiutil attach OpenWrt.dmg

Getting the build environment set up right here is a little more ornate. If you don’t have Homebrew (and you should), you’ll need to get that installed first. You’ll also need to install Xcode and the Xcode Command Line Tools.

brew update
brew upgrade
brew install coreutils e2fsprogs ossp-uuid asciidoc binutils fastjar gtk+ gnu-getopt gnu-tar intltool openssl subversion rsync sdcc gawk wget findutils

When brew installs the gnu toolset, it doesn’t automatically link it into your path, and the build wants to use gnu-compatible tools. However, brew does create an auxiliary directory of gnu-compatible aliases at /usr/local/opt/coreutils/libexec/gnubin, and for the purposes of the build, we can set our path to preference those tools temporarily.

ln -s /usr/local/Cellar/gnu-getopt/1.1.5/bin/getopt /usr/local/opt/coreutils/libexec/gnubin/getopt
ln -s /usr/local/bin/gtar /usr/local/opt/coreutils/libexec/gnubin/tar
export PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH

Get the Sources

Get the Barrier Breaker sources from the upstream repo to build the current stable release:

git clone git://git.openwrt.org/14.07/openwrt.git

Or pull down the latest OpenWrt “Chaos Calmer” sources to build the “bleeding edge” top-of-trunk version:

git clone git://git.openwrt.org/openwrt.git

Prepare For the Build

Connect to the source directory, and update and install all the feeds. These represents the build schemes for all of the optional components that you can add to your OpenWrt system.

cd ~/openwrt
./scripts/feeds update -a
./scripts/feeds install -a

Configure the build.

make prereq

This sets up prerequisites for the build and then takes you into menuconfig, a screen-driven configuration utility based on the one used to set up builds for the Linux kernel.

For starts, you simply want to pick an appropriate “Target system” and “Target profile”. For the TP-Link TL-MR3040, the target system is “Atheros AR7xxx/9xxx”, subtarget “generic”. For a Raspberry Pi, the target system is “BRCOM947xx/953xx”, the only profile is “Raspberry Pi”.

build5

For an initial build, I’d suggest simply picking the correct target and leaving it at that. You can start adding other options once you’ve verified that you can produce a working build and have an idea how much free space you’ve got to play with on the system. You want to start out minimal, the MR3040 only has 4MB (!) of available flash memory.

When you’re done here, select “Exit”, and save your configuration file as .config when prompted to do so.

Build that sucker!

All it takes is a make at this point. I like to use make V=s because I like to watch it do its thing.

make

Results will be in the bin/ folder, in a subfolder corresponding to the architecture you’ve built for — in my case “ar71xx”.

Using OS X to Image an SD Card with Debian for BeagleBone Black

The latest revision of the BeagleBone Black is shipping with a 4GB eMMC, and it’s now possible to get it pre-imaged with Debian Wheezy, a more broadly useful production-isn environment than Angstrom. If you have a rev. B BeagleBone Black, you might want to run Debian on yours as well.

BeagleBoard.org only provides instructions for using a Windows machine to set up an SD card with the Debian Wheezy image, so I wanted to document a parallel set of directions and utilities for OS X users.

Get the Compressed “Wheezy” Image

wget https://rcn-ee.net/deb/microsd/wheezy/bone-debian-7.6-console-armhf-2014-08-13-2gb.img.xz

Check the MD5 hash, just to make sure that we’ve gotten the correct image. On OS X, the md5 command works similarly to md5sum on other systems.

$ md5 bone-debian-7.6-console-armhf-2014-08-13-2gb.img.xz
MD5 (bone-debian-7.6-console-armhf-2014-08-13-2gb.img.xz) = f925d35517b3938e67d9108f6abd3c4b

Uncompress the Image

Images for the BeagleBone Black (and other small devices) tend to come in 7zip format, and there’s no built-in support for unpacking 7zip files in OS X. However, Dag Ågren, the author of the Mac utility the UnArchiver, has made some free command line tools available which will handle 7zip files.

Install unar wherever it’s convenient to in your $PATH (Homebrew users will probably want to move it to /usr/local/bin). Unpack the image file with the command

unar bone-debian-7.6-console-armhf-2014-08-13-2gb.img.xz

Install the Image On an SD Card

Without the SD card inserted in your Mac, run the command

df -h

You’ll get a list of the disk volumes mounted on your system. Now, insert the SD card, and run the df -h command a second time. Note the device identifier for the SD card, which should now appear at the end of the list, showing an identifier that wasn’t previously present (you can also check the volume names, at the end of each output line.) In my case, it’s /dev/disk5s1.

The "df -h" command

Start by unmounting the SD card so that it can be completely rewritten.

sudo diskutil unmount /dev/disk5s1

We have to write to the raw disk, which has a slightly different identifier. In this example, since our SD card was /dev/disk5s1, the corresponding raw disk is /dev/rdisk5; if your SD card showed up at /dev/disk3s1, you’d use /dev/rdisk3, and so on.

Issue the dd command to write the image to the SD card. Be very certain you’re using the correct raw disk identifier here, or you’re liable to overwrite something you didn’t want to!

sudo dd bs=1m if=bone-debian-7.6-console-armhf-2014-08-13-2gb.img of=/dev/rdisk5

This command will take several minutes to run, be patient. When it completes, it will output something like the following:

1700+0 records in
1700+0 records out
1782579200 bytes transferred in 366.464955 secs (4864256 bytes/sec)

Now, eject the SD card, and you’re ready to reboot your BeagleBone into Debian Wheezy.

sudo diskutil eject /dev/rdisk5

With the BeagleBone connected to a monitor and a keyboard, but not connected to power, insert the SD card. While holding down the “BOOT” button, connect the board to power, and continue to hold the “BOOT” button down until you see the USR LEDs light up. You should be able to log in using the user name “debian” and password “temppwd”.

The Micro Python pyboard Arrived!

The version 1.0 pyboard that I ordered from the Micro Python project arrived in the mail today. It’s amazingly small.

IMG_1115-0.JPG

The board supports a REPL shell, accessible via the same USB cable that provides power, and has a number of LEDs, timers, a user-assignable switch, and an accelerometer framework. I’ll be putting together a review pretty shortly, but there are a million things going on, suddenly.

Stay tuned.

The Most Recent Batch of Inept Hackers

WordPress is very popular. Very easy to install. Very easy to install incorrectly if you’re not entirely clear on how things operate on your hosting, and in my experience, even a lot of ISPs seem to not be entirely clear on that.

This is just a screenful’s worth of the security scan — I’m using the free WordFence plugin on that site, which is one of the better free ones out there — from one of the WordPress sites I run. Pretty typical.

If you’re not running some sort of live traffic and file system scanner on your WordPress site, you’re probably asking for trouble. If your administrative account has a name like “admin”, “Administrator”, or “«PASTE SOME PORTION OF YOUR SITE’S DOMAIN NAME HERE»”, or if you expose your admin account name in other ways (like via an “?author=” page, or by using your admin account as an author), you’re walking down dark alleys with twenty-dollar bills hanging out of your pockets.

If you’re using an account name like that and an easily-guessed (or duplicated) password, you’re probably already in trouble.

I’m going to have more to say on this when I get it all organized…

Set Up Your WordPress Site to Use Password-Free SFTP For Better Security

This turns out to be a pretty easy trick to do. In order to accomplish this, you will need:

  1. to be able to ssh (or, heaven forbid, telnet) into a command line on your server and operate as root or a “sudoer”;
  2. to be able to edit the wp-config.php file for your WordPress installation;
  3. to be able to stop and restart your web server.

Assumptions: You’re running CentOS or something like it. If you’re running Debian, or something like it, you’ll need to use apt-get instead of yum, and your directory layout will be different.

Enabling SSH for PHP

We’re going to set up WordPress to enable uploads via SFTP; for that, we’ll first need to build and install the ssh2 extension to PHP. At your server’s command line, execute the following to load all of the infrastructure you’ll need:

$ yum install php-devel php-pear gcc gcc-c++ make automake autoconf pcre-devel re2c libssh2 libssh2-devel

Next, have pecl install the ssh2 extension.

$ pecl install ssh2-0.12

Turn on ssh2 by creating an ini file for PHP:

$ echo "extension = ssh2.so" > /etc/php.d/ssh2.ini

Restart your web server:

$ service httpd restart

At this point, the SSH2 PHP extension should be installed and activated; you can use

$ php -i | grep ssh2

to verify this.

Setting Up WordPress for SFTP

First thing to do is to generate a key pair. YOU MUST BE LOGGED IN AS THE USER WHO WOULD BE DOING THE UPLOADING TO WORDPRESS. At the command line, execute

$ keygen-ssh

When prompted to enter a file name, we’ll call the key pair “~/wp_rsa”, so as not to accidentally overwrite any other keys we have around. Once your key pair has been generated, execute the following commands in that user’s home directory:

$ cat wp_rsa.pub >> .ssh/authorized_keys
$ mv wp_rsa* .ssh/

For reasons that aren’t immediately clear to me, WordPress required both the public and private key to be available to it. Set the access protections appropriately:

$ chmod 755 .ssh/
$ chmod 644 .ssh/*

Next, edit wp-config.php, and add the following lines to the end, making the appropriate substitutions for your own site «where indicated»:

define('FTP_HOST', 'localhost');
define('FTP_USER', '«your user name goes here»');
define('FTP_PUBKEY', '«full path to user's home directory»/.ssh/wp_rsa.pub');
define('FTP_PRIKEY', '«full path to user's home directory»/.ssh/wp_rsa');

Finally, set the protections and ownership on the wp-content directory to allow Apache to create things in there (assumption — I have ownership of my wp-content directory set to «site owner»:apache; you may need to adjust this to suit your specific situation:

$ chmod 775 «full path to WordPress directory»/wp-content

You should be good to go.

[This posting is an adapted excerpt from the upcoming book “McFate’s Indispensible and Comprehensive Guide to Building Bullet-Proof Servers”]

The Correct Way to Lock Out an IP Address From Your Server

I’ve been getting something like a one-person DoS attack overnight, it seems — a single IP address hitting port 80 hundreds of times a minute, generating endless 404s, and chewing up noticeable bandwidth — so I had to add a rule to my iptables to block the IP address at fault. Here’s how to do it:

First, list your current iptable rules, with line numbers, for easy reference:

$ sudo iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
3    REJECT     all  --  0.0.0.0/0            127.0.0.0/8         reject-with icmp-port-unreachable 
4    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:587 

etc...

Add a new rule to block the offending IP address (“xxx.yyy.zzz.www”).

$ sudo iptables -I INPUT 1 -s xxx.yyy.zzz.www -j DROP

This will insert the new rule at position 1, just prior to the rule that accepts TCP incoming traffic on port 22 for SSH and passes it to fail2ban.

Save the updated table and restart the service.

$ sudo service iptables save
$ sudo service iptables restart
$ sudo iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    DROP       all  --  200.85.152.75        0.0.0.0/0           
2    fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
4    REJECT     all  --  0.0.0.0/0            127.0.0.0/8         reject-with icmp-port-unreachable 
5    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:587 

etc...

Some suggestions for doing this that turn up on Google have used the “-A” (Add) flag rather than the “-I” (Insert) flag. This will not work in most cases, it would add the new rule to the end of the INPUT chain, after the rule that accepts (for instance) HTTP packets. If the banned IP address were attempting to access port 80, if would be ACCEPTed by that rule before it could get DROPped by the new rule.

The position of the rule is important: if it follows a rule which would accept the traffic otherwise, the new rule will have no effect. Placing it before the rules for general public traffic ensures that the annoyance in question can’t consume resources by trying to do things like load non-existent web pages. In fact, by checking first, the IP address is effectively firewalled from the server.

LEARN YOU SOME GIT! A git Resource List

If you’re working on code, whether you’re doing it on your own or collaboratively, you really want to be using a version control/source code management system, and the one most widely used these days is Linus Torvalds’ program git.

Git can be a little difficult to get your head around, but luckily, there are a lot of excellent (and free!) resources available to get you up to speed.

First, there’s TryGit, a collaboration between Github and Code School. TryGit walks you through fifteen guided experiments that will introduce you to the basics of git.

When you’ve worked through that, Code School’s “Git Real” course is available for free, no sign-up or credit card needed.

Another great resource is Git Immersion, from EdgeCase, a web-based guided tutorial that you can download to your own desktop.

Atlassian also provides an extensive set of git tutorials.

Finally, the text of the entire book “Pro Git”, written by Scott Chacon and published by Apress, is available online for free.

There’s no good reason not to use git, and lots of excellent reasons to do so. Do yourself a favor, save yourself some headaches, and check it out.

(SEE WHAT I DID THERE?)

“Shell Shock” Exploit — Probably Not a Worry For OS X Users

We’ve been hearing a lot about a very serious exploit in a universally-deployed piece of software, the “Shell Shock” bug in the bash shell. I got an alert late yesterday evening, and immediately upgraded the software on my publicly-facing servers.

There’s been some discussion of whether or not it’s an issue for OS X, and some debate over whether it’s a significant exposure on that platform. I didn’t think it was, but I haven’t seen an update for OS X Server to patch it, for example.

My own version of bash is managed through Homebrew, so rather than the stock 3.2, I’m running a newly patched and up-to-date v4.3.25(1). However, I got curious, so I decided to check the stock OS X version of bash for this exploit, and here’s what I found:

TerminalScreenSnapz002

So, the (rather antiquated) OS X version of bash, which has a “modified” date of May 10, has already been patched to disallow this hack, or so it would appear.

UPDATE: Apple’s given a statement on iMore that OS X users should not be at risk from the “Shell Shock” exploit unless they have “advanced UNIX services configured”. I’m not sure which specific “advanced UNIX services” they’re referring to — at a guess, “Web Sharing”, which I don’t do, seems a likely suspect — but that may be the explanation for the commenters reporting vulnerability and me not seeing it on my system (either in /bin/bash or in /bin/sh)…

The vast majority of OS X users are not at risk to recently reported bash vulnerabilities,” an Apple spokesperson told iMore. “Bash, a UNIX command shell and language included in OS X, has a weakness that could allow unauthorized users to remotely gain control of vulnerable systems. With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.”

UPDATE, 2014-10-01: Apple has put out a patch for OS X systems.