Botbusting

Okay, this week has heated up a great deal for me, so it doesn't look like I'll be able to continue my coding series until Monday. In the meantime, I want to talk a little about combating bots of different sorts. OnionRings knows more about the technical and security stuff than I do, so he may have some stuff to add or correct. Maybe he'll do some stuff about tightening up the backend, but my expertise is on the frontend/touchy feely stuff, so I'll just focus on that.

A CAPTCHA is an image that is (ideally) impossible for a computer to read but easy for a human. It's used to verify that a user is not a bot, rendering brute-force attacks unfeasible. However, even if it is easy for a human, it's also very annoying. For that reason, you need to use them with moderation.

The biggest technical threat is brute-force attacks on account logins. If someone gets the password of the admin account... well, I don't have to tell you the kind of hurt that can result. Combating this can be as simple as implementing brief (15-minute) bans after a certain number of failed login attempts. I don't think it's feasible to use CAPTCHA in this case because it's something that everyone will be presented with, especially if they don't have their browsers set to keep them logged in. I dislike entering more than a couple of them a day, and any unnecessary ones annoy me. However, if you implement temporary IP bans and change your password regularly, it should afford you a reasonable amount of protection. Other options here may be to require CAPTCHA on all attempts after the first one (decided by IP, not cookie), or to create an account that is used only for administration and give lower permissions to your regular account.

You can use CAPTCHA on registration, but I don't like to spend too long filling out registration forms, either. Besides, a human can register, then let a bot loose on the site. It's still not a great solution, although if you have fairly generic registration forms (or use an unmodified script), that may be a concern.

Instead, I suggest requiring CAPTCHA on a user's first few posts/comments/messages. After the first few, no more annoyances. One idea I just came up with and have yet to implement is simply to require CAPTCHA for all users with a 0/0 ratio. If you're using your account, you're likely not a bot.

No matter how careful you are, some will inevitably slip through. As I've mentioned before, proactively promoting moderators means that what does get through can be dealt with reasonably quickly. This is especially nice in the case of porn spam with images attached, which is never nice to be presented with unexpectedly.

If you have any other suggestions, I'd love to hear them.

Leaving a Host

There comes a time when you need to cover your tracks in a hurry. Since you often can't stick a boot CD in a dedicated host to do a DOD hard drive wipe like you should, you can settle for a few other options. It's nice to feel like you haven't left any incriminating footprints behind.

I find that the best tool for the job is secure remove. The command srm will allow you to do a 38-pass deletion wipe that's good enough for most purposes. Note that it's not impossible to recover the data deleted in this method, just beyond the reach of any small to medium sized organization.

Install secure remove:

$ sudo apt-get install secure-delete

Now, you could use this command to bash script a quick exit, but without forking off your processes, a quicker way would be to run each part of your secure removal separately. This works very well if you've got multiple cores or processors. You can use process management tools such as screen or background processes to run multiple srm commands at one time.

The three basic parts of your server you should consider deleting would be the MySQL databases, Apache www folder, and your logs. If you've installed any other software, be sure to check those out as well.

MySQL
sudo srm -rv /var/lib/mysql/

Web root
sudo srm -rv /var/www/

Logs
sudo srm -rv /var/log/*

You'll have to use your judgment on the rest of the system on an individual basis. Don't forget to delete any backups you've made. The last thing you can do is clear out your private files before you exit.

sudo srm -r ~/.*


That's all. SRM uses a lot of processor and takes some time on larger directories and files, so be sure to start your deletes in a relatively parallel fashion if you've got to high-tail it out.

Expect to see the series on "The Tracker Demystified" next week. Hopefully, if I write loud enough, that might happen. ;)

CurlyFries adds: Only stuff that you delete with srm will be securely removed. For this reason, do not drop your MySQL databases prior to hitting /var/lib/mysql with your srm stick. If you do so, MySQL will (insecurely) delete your database files, and running srm afterwards will do you no good.

Oh yeah, and hush up. I'm getting to it.

Linux Part 1: Installing Configuring Sudoers and OpenSSH

Okay, I'm going to start you off with a little advice for beginning Linux users looking to get rolling with a torrent site such as ours. Note that startup sites will most likely look for shared hosting whereas the following advice is aimed at admin's moving from a shared host to a virtual private server (VPS) or a dedicated server (dedi).

In these posts, I'll be customizing the advice for a PHP/MySQL tracker such as ours at TorrentFries. I'll also be running under the assumption that you're running Ubuntu Server Linux, specifically Hardy Heron 8.04. Additionally, these are pretty common instructions you can find at a variety of blogs across the net.

Let's just get some things straight before we get technical. If you're new-ish to Linux, I'd recommend Ubuntu. If you disagree, you don't need to be reading this anyway. Ubuntu isn't the most rock-solid distro available, it's just the easiest to administer (in my realm of experience) and it's stable enough that I've never crashed it on accident. It can also be found with most hosting companies. If not, Debian is the closest to Ubuntu and feels nearly the same.

If you're concerned, check out these survey-based distribution choosers:

• http://www.zegeniestudios.net/ldc/
  
• http://polishlinux.org/choose/quiz/
  

Logging In

You'll find that your hosting company will give you nothing more than an IP address (or a couple if that's the case) and a root login password. This means that you'll be accessing a server via Command Line Interface (CLI) over Secure SHell (SSH).

On Windows, I recommend using PuTTY for terminal access.
On Macs, you have Terminal!

Starting Configuration

Once you're logged in, create an admin group.

groupadd admin

If the admin group already exists, that's fine. Now create the first user with -g being the primary group (often just the username), -G being secondary group (admins), -s is the location to the shell, bash, -p is the password (you can omit this flag if you want), -d being the home directory, and -m creates the directory if it doesn't exist, and finally the username itself.

useradd -Gadmin -s/bin/bash -pPassword -d/home/UserName -m UserName

The password you just set can be tricky, so to be sure...

passwd UserName

You can add any other users in this fashion.
Let's give your new user sudo access first. Sudo lets you run commands as root while not logged in as root. Once, you'll have to use the UNIX text editor 'vim', but in the future, you can use a much easier text editor called 'nano'.

Edit: Ubuntu Intrepid Ibex (8.10) now uses nano for visudo.

visudo

Here's a quick tutorial on vi(m). Only use visudo when editing the sudoers file. Using any other method may cause corruption in the file, so make it a habit to use visudo.
Make sure your sudoers file looks like this in the group section:

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

Now that you have sudo access, try connecting with a new session. You should now see something like

UserName@host$

instead of

root@host#

Let's use our new user from now on.

Configuring OpenSSH

Now, lets lock down SSH. First, copy the config file so we can restore the original settings at any time.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original

Now, let's edit the sshd_config file with nano text editor.

sudo nano /etc/ssh/sshd_config

Look for:
LogLevel INFO

Change to:
LogLevel VERBOSE

This will allow us to get more information about SSH activity. It's handy to see who's logged in and who's tried to log in. Run grep -ir ssh /var/log/* | less to get that good data you're collecting.

Look for:
PermitRootLogin yes

Change to:
PermitRootLogin no

This will prevent hackers from brute forcing the root password, since root login is disabled. They'll still try to enumerate your users, but this is a critical step.

Look for:
LoginGraceTime 120

Change to:
LoginGraceTime 20

Changing the login time will slow down any would-be automated attacks.

If you'd like, you can change the port you connect to on SSH if you feel better being more obscure. Just change the 22 to what you wish:

Port 22

Save and exit the file and restart OpenSSH:

sudo /etc/init.d/ssh restart

You won't notice any changes until you reconnect. When you do, remember that you won't be able to log in as root. If you need root, you will have to use sudo or su. Also, if you changed your port, remember to change it in PuTTY when you reconnect.

For more info on OpenSSH, check this out.

Up next: installing and configuring LAMP.