UPDATE: I wrote this charm and blog post before I saw the unfortunate news that the UbuntuForums.org website had been very recently compromised and user database stolen. Given that such events have sadly become commonplace, the instructions below can actually be used by proactive administrators to identify and disable weak user passwords, expecting that the bad guys are already doing the same.
It's been about 2 years since I've written a Juju charm. And even those that I wrote were not scale-out applications.
I've been back at Canonical for two weeks now, and I've been spending some time bringing myself up to speed on the cloud projects that form the basis for the Cloud Solution products, for which I'm responsible. First, I deployed MAAS, and then brought up a small Ubuntu OpenStack cluster. Finally, I decided to tackle Juju and rather than deploying one of the existing charms, I wanted to write my own.
Installing Juju
Juju was originally written in Python, but has since been ported to Golang over the last 2+ years. My previous experience was exclusively with the Python version of Juju, but all new development is now focused on the Golang version of Juju, also known as juju-core. So at this point, I decided to install juju-core from the 13.04 (raring) archive.
I immediately hit a couple of bugs in the version of juju-core in 13.04 (1.10.0.1-0ubuntu1~ubuntu13.04.1), particularly Bug #1172973. Life is more fun on the edge anyway, so I upgraded to a daily snapshot from the PPA.
Now I'm running juju-core 1.11.2-3~1414~raring1, and it's currently working.
Configuring Juju
Juju can be configured to use a number of different cloud backends as "providers", notably, Amazon EC2, OpenStack, MAAS, and HP Cloud.
For my development, I'm using Canonical's internal deployment of OpenStack, and so I configured my environment accordingly in ~/.juju/environments.yaml:
Using OpenStack (or even AWS for that matter) also requires defining a number of environment variables in an rc-file. Basically, you need to be able to launch instances using euca2ools or ec2-api-tools. That's outside of the scope of this post, and expected as a prerequisite.
The official documentation for configuring your Juju environment can be found here.
Choosing a Charm-able Application
I have previously charmed two small (but useful!) webapps that I've written and continue to maintain -- Pictor and Musica. These are both standalone web applications that allow you to organize, serve, share, and stream your picture archive and music collection. But neither of these "scale out", really. They certainly could, perhaps, use a caching proxy on the front end, and shared storage on the back end. But, as I originally wrote them, they do not. Maybe I'll update that, but I don't know of anyone using either of those charms.
In any case, for this experiment, I wanted to write a charm that would "scale out", with Juju's add-unit command. I wanted to ensure that adding more units to a deployment would result in a bigger and better application.
For these reasons, I chose the program known as John-the-Ripper, or just john. You can trivially install it on any Ubuntu system, with:
John has been used by Linux system administrators for over a decade to test the quality of their user's passwords. A root user can view the hashes that protect user passwords in files like /etc/shadow or even application level password hashes in a database. Effectively, it can be used to "crack" weak passwords. There are almost certainly evil people using programs like john to do malicious things. But as long as the good guys have access to a program like john too, they can ensure that their own passwords are impossible to crack.
John can work in a number of different "modes". It can use a dictionary of words, and simply hash each of those words looking for a match. The john-data package ships a word list in /usr/share/john/password.lst that contains 3,000+ words. You can find much bigger wordlists online as well, such as this one, which contains over 2 million words.
John can also generate "twists" on these words according to some rules (like changing E's to 3's, and so on). And it can also work in a complete brute force mode, generating every possible password from various character sets. This, of course, will take exponentially longer run times, depending on the length of the password.
Fortunately, John can run in parallel, with as many workers as you have at your disposal. You can run multiple processes on the same system, or you can scale it out across many systems. There are many different approaches to parallelizing John, using OpenMP, MPI, and others.
I took a very simple approach, explained in the manpage and configuration file called "External". Basically, in the /etc/john/john.conf configuration file, you tell each node how many total nodes exist, and which particular node they are. Each node uses the same wordlist or sequential generation algorithm, and indexes these. The node modulates the current index by the total number of nodes, and tries the candidate passwords that match their own id. Dead simple :-) I like it.
This does, however, require some way of sharing the inputs, logs, and results across all nodes. Basically, I need a shared filesystem. The Juju charm collection has a number of shared filesystem charms already implemented. I chose to use NFS in my deployment, though I could have just as easily used Ceph, Hadoop, or others.
Writing a Charm
The official documentation on writing charms can be found here. That's certainly a good starting point, and I read all of that before I set out. I also spent considerable time in the #juju IRC channel on irc.freenode.net, talking to Jorge and Marco. Thanks, guys!
The base template of the charm is pretty simple. The convention is to create a charm directory like this, and put it under revision control.
I first needed to create the metadata that will describe my charm to Juju. My charm is named john, which is an application known as "John the Ripper", which can test the quality of your passwords. I list myself as the maintainer. This charm requires a shared filesystem that implements the mount interface, as my charm will call some hooks that make use of that mount interface. Most importantly, this charm may have other peers, which I arbitrarily called workers. They have a dummy interface (not used) called john. Here's the metadata.yaml:
I also have one optional configuration parameter, called target_hashes. This configuration string will include the input data that john will work on, trying to break. This can be one to many different password hashes to crack. If this isn't specified, this charm actually generates some random ones, and then tries to break those. I thought that would be nice, so that it's immediately useful out of the box. Here's config.yaml:
There's a couple of other simple files to create, such as copyright:
README and revision are also required.
And the Magic -- Hooks!
The real magic happens in a set of very specifically named hooks. These are specially named executables, which can be written in any language. For my purposes, shell scripts are more than sufficient.
The Install Hook
The install hook is what is run at installation time on each worker node. I need to install the john and john-data packages, as well as the nfs-common client binaries. I also make use of the mkpasswd utility provided by the whois package. And I will also use the keep-one-running tool provided by the run-one package. Finally, I need to tweak the configuration file, /etc/john/john.conf, on each node, to use all of the CPU, save results every 10 seconds (instead of every 10 minutes), and to use the much bigger wordlist that we're going to fetch. Here's hooks/install:
The Start Hook
The start hook defines how to start this application. Ideally, the john package would provide an init script or upstart job that cleanly daemonizes its workers, but it currently doesn't. But for a poor-man's daemonizer, I love the keep-one-running utility (written by yours truly). I'm going to start two copies of john utility, one that runs in wordlist mode, trying every one of the 2 million words in my wordlist, as well as a second, which tries every combinations of characters in an incremental, brute force mode. These binaries are going to operate entirely in the shared /var/lib/john NFS mount point. Each copy on each worker node will need to have their own session file. Here's hooks/start:
The Stop Hook
The stop hook defines how to stop the application. Here, I'll need to kill the keep-one-running processes which wrap john, since we don't have an upstart job or init script. This is perhaps a little sloppy, but perfectly functional. Here's hooks/stop:
The Workers Relation Changed Hook
This hook defines the actions that need to be taken each time another john worker unit is added to the service. Basically, each worker needs to recount how many total workers there are (using the relation-list command), determine their own id (from $JUJU_UNIT_NAME), update their /etc/john/john.conf (using sed), and then restart their john worker processes. The last part is easy since we're using keep-one-running; we simply need to killall john processes, and keep-one-running will automatically respawn new processes that will read the updated configuration file. This is hooks/workers-relation-changed:
The Configuration Changed Hook
All john worker nodes will operate on a file in the shared filesystem called /var/lib/john/target_hashes. I'd like the administrator who deployed this service to be able to dynamically update that file and signal all of her worker nodes to restart their john processes. Here, I used the config-get juju command, and again restart by simply killing the john processes and letting keep-one-running sort out the restart. This is handled here in hooks/config-changed:
The Shared Filesystem Relation Changed Hook
By far, the most complicated logic is in hooks/shared-fs-relation-changed. There's quite a bit of work we need to here, as soon as we can be assured that this node has successfully mounted its shared filesystem. There's a bit of boilerplate mount work that I borrowed from the owncloud charm. Beyond that, there's a bit of john-specific work. I'm downloading the aforementioned larger wordlist. I install the target hash, if specified in the configuration; otherwise, we just generate 10 random target passwords to try and crack. We also symlink a bunch of john's runtime shared data into the NFS directory. For no good reason, john expects a bunch of stuff to be in the same directory. Of course, this code could really use some cleanup. Here it is again, non-perfect, but functional hooks/shared-fs-relation-changed:
Deploying the Service
If you're still with me, we're ready to deploy this service and try cracking some passwords! We need to bootstrap our environment, and deploy the stock nfs charm. Next, branch my charm's source code, and deploy it. I deployed it here across a whopping 18 units! I currently have a quota of 20 small instances I can run our private OpenStack. Two of those instances are used by the Juju bootstrap node and by the NFS server. So the other 18 will be NFS clients running john processes.
Once everything is up and ready, running and functional, my status looks like this:
Obtaining the Results
And now, let's monitor the results. To do this, I'll ssh to any of the john worker nodes, move over to the shared NFS directory, and use the john -show command in a watch loop.
And the results...
Within a few seconds, this 18-node cluster has cracked all 10 of the randomly chosen passwords from the dictionary. That's only mildly interesting, as my laptop can do the same in a few minutes, if the passwords are already in the wordlist. What's far more interesting is in randomly generating a password and passing that as a new configuration to our running cluster and letting it crack that instead.
Modifying the Configuration Target Hash
Let's generate a random password using apg. We'll then need to hash this and create a string in the form of username:pwhash that john can understand. Finally, we'll pass this to our cluster using Juju's set action.
This was a 6 character password, consisting of 52 random characters (a-z, A-Z), almost certainly not in our dictionary. 526 = 19,770,609,664, or about 19 billion letter combinations we need to test. According to the john -test command, a single one of my instances can test about 12,500 MD5 hashes per second. So with a single instance, this would take a maximum of 526 / 12,500 / 60 / 60 = 439 hours. Or 18 days :-) Well, I happen to have exactly 18 instances, so we should be able to test the entire wordspace in about 24 hours.
So I threw all 18 instances at this very problem and let it run over a weekend. And voila, we got a little lucky, and cracked the password, Uvneow, in 16 hours!
In Conclusion
I don't know if this charm will ever land in the official charm store. That really wasn't the goal of this exercise for me. I simply wanted to bring myself back up to speed on Juju, play with the port to Golang, experiment with OpenStack as a provider for Juju, and most importantly, write a scalable Juju charm.
This particularly application, john, is actually just one of a huge class of MPI-compatible parallelizable applications that could be charmed for Juju. The general design, I think, should be very reusable by you, if you're interested. Between the shared file system and the keep-one-running approach, I bet you could charm any one of a number of scalable applications. While I'm not eligible, perhaps you might consider competing for cash prizes in the Juju Charm Championship.
Happy charming,
:-Dustin