*ahem* BitTorrent uses the Kademila DHT for distributed tracking, and it works really, really well so far. I haven't used a centralized tracker for a year or so now. There's also peer exchange (PEX). The trackers aren't the weak points of BitTorrent, and haven't been for years. The weak point is in .torrent distribution, with commenting/forum, seed/leach counts, search, etc. Magnet links partially resolve this by moving the .torrent files out to the DHT as well.

$ cat /dev/urandom > tmp
error: out of disk space
$ rm tmp

That kind of statement is probably the most effective way to get a teenager to read anything. If you had said "please read my journals" he wouldn't have even looked at them, but now ...

I see what you did there.

To quote Chris Rock, "That ain't a payment, that's a jack!"

As long as the private flag DRM isn't set, which prevents you from turning it on.

In my small amount of experience observing these types of ssh attacks, and even letting them into high-interaction honeypots to see what they do, there are four simple things that can be done to really cut down on the danger. Applying the first item, and any subset of the last three should be pretty good.

One, turn off root log in. Then they have to guess both a user name and a password. This would stop every single attack I have ever seen in my logs, since none of them have guessed a correct user account, let alone a correct password. It tries names like root, admin, apache, samba, so if you have these make sure they can't log in with ssh.

Two, use a decent password. A lot of people will tell you to take the inconvenient route of disabling password logins, saying they are dangerous. However, guessing over ssh is extremely slow, compared to a brute force attempt on a local machine. This means they really only get a chance to guess the most obvious passwords. If you trust all the passwords on the system to have decent strength, which is the case if, say, you are the only person logging into the machine, then you don't need to disable password logins.

Three, in case they did somehow figure out the name of an account that can log in, run DenyHosts. This will stop non-distributed attacks in their tracks, as they only get a few guesses.

Four, move the ssh port to something other than the default 22. I moved mine to 443 (https), since it's accessible from highly firewalled networks behind which I may be trapped, and people are already used to seeing encrypted traffic on that port. Ever since I did this, I haven't seen a single login attempt on my server other than myself. This means my server also wastes less time rejecting remote logins.

The ssh brute force bots I've seen are very stupid. I'm not really sure what the bot operators are doing. In my ssh honeypot where I have the root password set to "password", most bots won't ever guess it after thousands of attempts. Of the ones that do eventually guess the right password, most log out right away, then go right back to guessing root passwords again! Maybe trying to detect if it's a honeypot? Then there are ones that do log in and stop guessing, but they immediately log out and don't ever return (that is, no one has ever shown up and logged in without making guesses). Security researchers? Maybe marked my honeypot down for some future abuse? Maybe detected that it was a honeypot? I'm not sure what's going on with that.

There have been a few mistakes made, but nothing terribly important. The ones I know of can possibly be attributed to character confusion. For example, there was that TNG episode where they find Scotty trapped in a transporter buffer after an accident. When they free him he believes that Kirk has brought the Enterprise to come rescue him. However, Scotty had already witnessed what was believed to be Kirk's death in Star Trek: Generations, so Scotty should believe Kirk to be dead at that time.

But nowhere near as inconsistent as the bible, with its multiple, incompatible creation myths. :-)