OP may also benefit from the use of an SSH honeypot. I use kippo (https://code.google.com/p/kippo/) with great success. It tracks all commands run, as well as keeps copies of all downloaded files.
In addition, it limits available commands to a certain predefined subset, allowing the host to prevent damage caused (e.g. a DoS attack in this case) by the system being compromised.
I ran kippo for a while and it seemed that all attackers were trying to upload files over SCP, which kippo does not support. A few attackers resorted to logging in and downloading with wget. However, the vast majority of attacks ended with a failed SCP session.
If you like this kind of stuff, http://www.honeyd.org/ is pretty full featured as well and provides a lot more emulated services (http, ftp, network file shares, smtp). It is also built so it is (relatively) easy to add your own emulated services.
Not to say that kippo isn't good, I didn't look too closely but it seems to be mainly focused on ssh and terminal capture.
Would it have recorded also statistics like the connection activity?
Seeing all the UDP traffic, and being able to trace its origin to the "@udp1 39.115.244.150 800 300" command, received not via shell but via a TCP connection, was pretty cool.
The original article is a bit unclear on this, but the command was not directly received from a TCP connection initiated by the botnet owner.
Rather, his server connected to some IRC server and joined a channel with all his other bot friends. The owner then sent the command to the IRC channel, and it is then broadcasted to all bots by whatever IRC server he is using.
(This is why lots of IaaS providers will forbid you from hosting an IRC server, and sometimes block all IRC traffic (by port anyway) on their networks)
I don't think it measures the inbound/outbound bandwidth - especially over UDP. It's more of an SSH emulator (so to speak) with everything being logged (commands, files, etc.).
In addition, there are quite a few good visualization tools to show the logs made by kippo. You can save them to a db, plot them nicely, etc.
I anonymized the IP addresses in a consistent way before publishing the blog post, so in the very worst case the DoS attack will go towards a completely new host :)
In addition, it limits available commands to a certain predefined subset, allowing the host to prevent damage caused (e.g. a DoS attack in this case) by the system being compromised.