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.

Protocol

Okay, this is going to be a quick post because OnionRings and I both have a ton of work to do and Ketchup seems to be maintaining our collective laziness quota.

I'm planning to offer a detailed examination of what exactly goes into the technical end of a BitTorrent tracker by offering explanations as I write my own, but that's well beyond my time allotment for the evening. Instead, I'll write a simple summary of the protocol.

The peer-to-peer aspect is not important for our purposes. Unless you're planning on writing a client, which is well outside the scope of this site, you don't even need to think about it. I know I don't. I really haven't taken the time to study it in much detail, aside from understanding what's going on in general terms.

Happily, the peer-to-tracker protocol is very simple to understand. The tracker is inherently passive, never initiating connections itself. Instead, clients connect to the tracker via HTTP. They provide the infohash (unique identifier) for the torrent they're trying to download, their current port, and a bunch of other information indicating the state of the client. The tracker responds with a simple list of IP addresses that are also downloading the same file. It's up to the client to initiate connections with the provided peers. Since the protocol is peer-to-peer, any client can initiate the connection, assuming that the other computer is properly configured to accept incoming connections.

That's all a tracker has to do: log the IP addresses that connect, and respond with a list of suggestions for possible peers. The process is fast, light on resources, and very easy to code. You can develop a tracker just like any website, using just about any language you want: PHP, ASP, Ruby, whatever. The biggest trackers run on C or other such languages, since it's fast and lightweight beyond the dreams of PHP. However, for your purposes, web languages are all you need.

That said, I'll pick up on the subject later on when I actually find the time to get going on development. Like I say, things have been nuts of late.

Linux Part 2: Installing LAMP

I'm going to resume from Linux Part 1: Installing Configuring Sudoers and OpenSSH with part 2: Installing LAMP. In the world of Ubuntu, virtually no one installs LAMP from a command line on Ubuntu Server. Ubuntu provides the option to automatically install LAMP during OS setup, so most of the time, it's done that way. Purchasing a dedicated server often doesn't give you that option, however. Yes, many tutorials cover installing LAMP, and they are just as good, but note that they're installing on Ubuntu Desktop, sometimes assuming you have a GUI. Thankfully, installing LAMP on Ubuntu from the command-line isn't hard at all.

Let's start by running the best command ever, apt-get. This will get all the packages we need.

sudo apt-get install apache2 php5 php5-mysql libapache2-mod-php5 mysql-server libapache2-mod-auth-mysql

Alternatively, you can try

sudo tasksel install lamp-server

Apt will download the packages and install. Then, you'll see this as MySQL is being configured:



You'll have to confirm your password, and then you're done. Restart Apache.

sudo /etc/init.d/apache2 restart

Let's make sure everything went okay. Browse to your IP address. You should see an "It Works!" page. This means Apache is running. Let's check PHP. Run

sudo nano /var/www/test.php

Write out this single line to the file:

<?php phpinfo(); ?>

Browse to your addresss/test.php and you should see lots of information about the current state of PHP.

Securing MySQL

That installation was so easy, we'll do a little security cleanup too.

Log into MySQL:

mysql -uroot -p

Your prompt will change to mysql>

Create a user you'll be using to administrate the databases. By default, MySQL is secure in the fact that it will only allow root to login locally. That's excellent until you realize that MySQL can be a pain to administer locally. I don't mind too much, but some people like to install PHPMyAdmin. This can open you up to potential remote access attacks on the root user's password. Therefore, if you're going to install PMA, we'll get rid of the root user to make it more difficult to enumerate users. Let's start by creating a MySQL account, Zeus.

mysql> GRANT ALL PRIVILEGES ON *.* TO 'zeus'@'localhost'
-> IDENTIFIED BY 'yourpassword' WITH GRANT OPTION;

You should consider also adding the privileges to this user @ 127.0.0.1
mysql> GRANT ALL PRIVILEGES ON *.* TO 'zeus'@'127.0.0.1'
-> IDENTIFIED BY 'yourpassword' WITH GRANT OPTION;

At this point, you should create a user that will be the one accessing the database. Using your "God" user to access MySQL from your web application is bad karma and invites security risks. Google 'create mysql user' for the syntax on creating a user with less privileges.

Feel free to be creative with your names...
Flush the privileges and exit.

mysql> FLUSH PRIVILEGES;
mysql> quit

DO NOT ATTEMPT TO FORGET THIS PASSWORD! It's a pain to restore a MySQL root password, and even more of a pain when the root user doesn't exist, (some say impossible) so take it from me-- remember your privileged user's password for cripes' sake.

Login and delete the root and anonymous user once zeus was created.

mysql -uzeus -p

mysql> DELETE FROM mysql.user WHERE User = ' ';
mysql> DELETE FROM mysql.user WHERE User = 'root';
mysql> FLUSH PRIVILEGES;

Check out your work:

mysql> SELECT User, Host FROM mysql.user;

Don't drop the debian-sys-maint account.

Apache and MySQL Control

Here's how you can restart Apache and MySQL without rebooting your server if you have changed a configuration file.

sudo /etc/init.d/apache2 restart
sudo /etc/init.d/mysql restart

Replace 'restart' with 'stop' or 'start' if needed.

Thanks for reading again, next we'll show you a bit about the different administrative tools available for Linux.

Retrospective 6: Early Linux Experiences

As I mentioned on Friday, I was completely hopeless with Linux when TorrentFries moved to its first dedicated server. Happily, I quickly discovered the most magical feature of Ubuntu: apt-get. With it, it's possible to download and install applications with a simple command, such as apt-get install htop. (By the way, htop is something well worth checking out. For those that don't know, top is a command that allows you to monitor the processes and load on a server. htop takes that a step further and allows more advanced process manipulation and general feedback.)

What I did know was what needed doing, specifically, setting up a LAMP (Linux/Apache/MySQL/PHP) server and somehow getting everything to work properly. For working this out, the Ubuntu documentation (both official and unofficial) was invaluable. I've found the unofficial docs to be more comprehensive since they do a better job of covering command-line and server material, while the official stuff seems more focused on the desktop GUI. Obviously, since the server version doesn't have a GUI, that's not especially useful.

Thanks to the magic of Ubuntu, a LAMP server needs only one command to install. Obviously, there's a bit of fiddly configuration that follows, but it's still a walk in the park compared to the downloading and compiling some OSes would have you doing. The masochists that prefer that sort of thing are welcome to it, and it's certainly true that the customization available during compile makes for a faster and more effective install... but I can still have my server online hours before you, and that's a matter of days if we're using beginner timeframes here.

The bottom line is that Ubuntu is a good choice for an introduction to Linux server administration. It's be messy at first, but Google is a great place to find tutorials that can walk you through just about anything. Once OnionRings came onto the scene, he was able to help me out with a lot of the more complicated stuff, although it took even him days to figure out how to set up a proper mail server. Trust me, Google Apps is the way to go for email.

Since Linux still isn't my strong point, I'm not going to go into any more detail here, but some of OnionRings' eventual posts should be a little more helpful in that regard.