Perils of Remote Access

I thought since I've shared quite a bit of technical information in my past few posts that it was time for an admin's parable. I wrote a little about the perils of remote access servers earlier, but I didn't really go into detail about how 'normal' activities should be rethought in the environment of sole access being remote. Remote administration can be a wisening experience, unless you have some out-of-band administration tool (such as a DRAC card). With may hosts, you may only have the option to do a hard reboot or a reimaging (often at a fee).

In one case, CurlyFries was looking to add a static IP to the server to move critical services off the primary IP and domain. Most services, such as SSH, can listen on any address and can be restricted to certain addresses. It's handily secure to only have ports 80, 443, and 5222 open on a heavy-trafficked IP address.

It's fairly straightforward to add a static IP to a system. I would never dream of being timid about making such a change. At least not nearly as timid as when making a critical Apache or MySQL configuration change. Nonetheless, I managed to screw up with a typo in the /etc/network/interfaces file and got a serious error when restarting the networking. Thankfully, I hadn't lost terminal access, so I went back to look for the problem.

When I thought that I found it and fixed the problem, I restarted networking again. No joy. I was well aware of the implications of having a bad network interfaces file: no network interface access. So, I restored the backup configuration and restarted the service. At that point, my terminal died and I was then unable to establish any SSH connections to the server. The web server was down. Confounded, I cursed Debian for being so ridiculous and hoped that the configuration had taken effect. Within the hour, we had our TorrentFries rebooted, and to my relief the original configuration was working.

Had the networking stopped working when I tried to load the invalid configuration instead of when I loaded the original working configuration, we would have been toast. Not only would we have been forced to do a complete reinstall, but we would have lost quite a bit of data in the process due to not moving the rather infrequent non-automated backups off site regularly. *cough*

We barely escaped a disaster that would have spelled the second time in my capacity as an admin to need an OS reinstall on the remote server. The only time we've had to reinstall was when a certain curly type of administrator dropped the MySQL privileged users and my consequent mucking with things resulted in an inoperable system. The lesson to take away is threefold:

1. Backup offsite before making any changes that could effect the operation of the site.
2. Be mindful of what senarios could leave you with no server access. These generally include but are not limited to network configuration, SSH configuration, firewall configuration, and boot loader configurations.
3. Don't close an open terminal session unless you're sure you can get back in. After I make some changes, I open a second SSH session to ensure access before exiting out of my working session.

I hope you found that at least mildly entertaining enough for you to remember when it's your server you'll be losing access to. There's nothing quite as disappointing as the realization of failures easily avoided.

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.