GNU/Linux is a fantastically secure Operating System (given many of the alternatives). However, like any security measure, it is only as strong as the humans operating and administering it. What use is the world’s strongest lock on your front door if you leave a window open? Alternatively, what good is locking the door if the lock can be thwarted by sliding a credit card through it?
One of the many responsibilities of being a System Administrator with A Small Orange’s Operations team is to keep up with security issues. Because of this, I go to a lot of security conferences (“hacker cons“)- where exploits new, old, and clandestine are revealed to like-minded individuals. Many (most, if not all) of these individuals are not there to gain information on how to break into systems, but rather are security professionals interested in learning what attacks are in the wild in order to protect themselves against them (even FBI and other law enforcement agents attend these conventions to learn and share their knowledge!). You also learn some neat things in hacking “real life”- for instance, thanks to friends at TOOOL I know how to pick locks. It’s SUPER handy for when you lock your keys inside your car or house (and, admittedly, it happens to me a lot). Many of the people presenting are “pentesters“. It’s assumed and expected that any and all knowledge you gain from these conventions is to be used for good and not evil. For an analogy, if you know how cars work you can either fix them for people or you can sabotage them. Sabotaging people’s cars is generally frowned upon by mechanics and engineers.
Now with that aside, let’s talk about what this article sets out to do and what it does not set out to do.
This article aims to:
- Equip you with some basic theory in securing your server
- Set you up with a more secure SSH connection
- Shows you how to install new software and keep your software upgraded
- Provides you with ways of furthering your own knowledge (i.e. “Teach someone to fish”)
- Give you several specific suggestions to help you along this goal
What this article does NOT set out to do:
- Give you expertise that can only be gained through experience
- Teach nor encourage you to attack machines, your own or others
- Guarantee you will not be attacked and/or guarantee a prevention of compromise
Got it? Great! Let’s move on to the juicy details.
Passwords are a series of (hopefully) random characters that make up a complex sequence. Passphrases are a combination of words that make up that sequence. It is generally considered that long passphrases are more secure than passwords, but that is still being debated. It’s safe to assume that for most attacks (both bruteforce and dictionary attacks), however, a passphrase of seven words or longer that doesn’t resemble normal speech patterns is sufficient.
Generally, A Small Orange will never need your password/passphrase. There may be fringe cases where we request it (notably if it regards a particular web application e.g. WordPress) to troubleshoot, but for 95%+ cases we won’t need it. Be sure to follow this advice when using your passwords/passphrases, and this article has a lot of information on how to choose strong passwords (I personally use pwgen- typically with the command
pwgen -sy 26 1 – to create randomized strong passwords).
Hey, remember when I told y’all about how you can use SSH to connect to your server’s terminal? Well, now we’re going to focus on how to lock down SSH even more. Using a strong password is good, but not even giving an attacker the chance to bruteforce or dictionary attack your password is even better!
SSH supports public key authorization, or “pubkey auth” (Ubuntu article). This means that if you lock SSH down to only authorized keys, you can disable password logins- thus effectively thwarting both bruteforce AND dictionary attacks. A Small Orange staff has keys installed by default on new servers so we can gain access to your servers without needing to reboot them- typically, if you need to reset your root password or the like. Ubuntu has specific details on setting this up server-side, starting with how to edit and apply SSH settings.
First, we need to get pubkey authentication working.
Linux/Mac OS X
- Open a terminal session on your workstation- i.e. local computer (see the article I wrote on using SSH for details)
ssh-keygen -t rsa -b 4096#Note: you can just hit enter for each of the questions asked to accept the defaults. It is recommended that you set a password for your key.
cat ~/.ssh/id_rsa.pub#Note: be sure that you cat id_rsa.pub and not id_rsa. The .pub file is your public key, which can be safely redistributed. The file without the .pub at the end is your private key, and that should never leave your computer or be seen by others.
- Copy the above output (not including the command) to your clipboard. It should look something like:
- Now on your server, run
mkdir -p /root/.ssh ; chmod 700 /root/.ssh
- On your local computer, you can try running
ssh-copy-id -i ~/.ssh/id_rsa root@YOUR-SERVER-IPbut this may fail (I can’t recall offhand if Mac OS X has ssh-copy-id). If it fails, follow the instructions below. If it succeeds, you can skip them.
- Again on your server, paste the above in a file at /root/.ssh/authorized_keys. Note that the key should all be on one line. For now, you can use scp to skip pasting if you don’t know how to edit files from the command-line; I’ll cover some basics in a later article. To transfer the file via scp:
- (On your local machine)
scp ~/.ssh/id_rsa.pub root@YOUR-SERVER-IP:/root/mykey
- (On your server)
cat /root/mykey >> /root/.ssh/authorized_keys ; chmod 600 /root/.ssh/authorized_keys ; rm /root/mykey
- (On your local machine)
Again, Windows requires some different steps made possible via the PuTTY suite. See my original SSH article for installation instructions; make sure you install the installer.exe version as this will include all tools we need.
- Open up PuTTYgen. Go to the Key menu at the top and make sure “SSH-2 RSA Key” is selected and at the bottom, “Number of bits in a generated key” is set to 4096. Once these are set, Key > Generate Key Pair
- Now for the fun part. Move the mouse around in the grey area per the instructions. You’ll need to do this for a fair bit in order to generate some random data to be used for the keys. It’s best to make the mouse movements erratic (no drawing of shapes, etc.). You’ll see the progress bar grow. When enough random data has been collected, it will generate the keys.
- Now you can set the key comment (not required) and the key passphrase (recommended but not required). Once that is done, click on the “Save public key” AND “Save private key” buttons- we’ll want them both, so remember where you save them to. While you’re at it, open up Notepad and copy the public key displayed at the top. Paste this into Notepad.
- Now open PuTTY. Go to Connection > SSH > Auth and where it says “Private key file for authentication“, browse to the .ppk file for the private key you just generated.
- Almost done! Now, ssh into your server using PuTTY and enter the command mkdir -p /root/.ssh ; chmod 700 /root/.ssh ; touch /root/.ssh/authorized_keys ; chmod 600 /root/.ssh/authorized_keys ; nano -w /root/.ssh/authorized_keys
- You’ll get a fairly basic text editor inside your PuTTY connection. Copy the public key you copied to Notepad, and back in PuTTY do a Shift+Ins (that is, hold down the Shift key and hit the Insert key). You should see your public key paste into the document. Be sure that it is all on one line (you can use the left and right cursor keys to move forwards and backwards through the line; the -w switch for nano turns off wordwrap, which is what we want in order to make sure the entire key is on one line).
- Once the key’s in nano and it’s all on one line, hit Ctrl-X and when it asks if you want to save changes, hit “y” and then hit the Enter key.
And you’re done! Now, close your connection (type
exit to exit the server shell if you’re logged in) and attempt to SSH in again. It should ask you for your key password, if you set one. If not, it shouldn’t ask for a password at all. Have no fear, this is expected and normal behaviour- it means the server authenticated your server based on the key you’re using and thus didn’t need you to put your server’s root password in.
Now, what was the point of all that? Technically, we’re only half finished.
Stay tuned for the conclusion tomorrow!
Existing Customers get 50% off 1st hosting invoice
w/ Coupon OJ2013
Good for all new hosting plans & upgrades.