So this blog post is going to cover some basic security do’s and don’ts.  The end goal will be to have an Ubuntu powered server that is not only decently secure, but also not so secure that it is a pain to work with.  I will be covering many things that should be done as part of basic security, some general best practices, and I will also hit on one thing that I find to be a HUGE annoyance than many many… many… people do, thinking that it will make their server more secure, when in reality it does next to nothing.  I will be targeting an Ubuntu 11.10 server in this article, but everything that I have in here should work on anything 10.04 LTS and up.  I am mainly going to be focusing on securing SSH logins. Read on after the break

1 ) Stop logging into your server as root!

With almost any linux distro out there that is made for a server environment, after the initial setup there will only be one user account for user level logins… root.  For those of you new to the linux world, the root account is the all powerful master account that has permissions to do anything and everything on the server.  If there happens to be something that root isn’t allowed to do, there is a 99% chance that root can just give itself the permissions that it needs to do it.  For those of you coming from a Windows background, you may be thinking that this is like the Windows administrator account… that is not quite right… it is more like the SYSTEM account in windows.

We are going to start with adding a new user account named “someuser”, make sure to use your preferred username instead though

adduser someuser

This will run you through a few prompts asking for things like what password you want that user account to have.  It will also set up that users home folder at /home/someuser.  While specifying a password is optional, I would HIGHLY recommend it.

2 ) Give your new user account administrative permissions (but only if it needs it)

If this user account will be used for administrative privileges, we need to give it access to use the sudo command.  This command will allow the user account to run things as root if it needs to, or even become root for longer term administrative work.

usermod -a -G admin someuser

(note that if you are on something earlier than 11.04 then you will want to use this one instead)

usermod -a -G sudo someuser

This will allow you to run a single command with root privileges as the someuser account like this:

sudo COMMAND

or to become root with the following:

sudo -i

At this point, you should log out of your server since you are logged in as root, and log in through the someuser account that we created using the password that you set earlier.

3 ) Set up SSH public key authentication

This is the first step in disabling password logins to your server.  This first command we will be running on your LOCAL system (I.E. not on the server… but rather on the linux box that you are sitting in front of right now)

ssh-keygen

It will ask you a few questions, the first is where to save the key to, if you don’t have a key setup already, then just press enter to accept the default.  Next it will prompt you for a password to protect the private portion of the key with.  This password is also optional, but also HIGHLY recommended.  Once you have that set up, we need to see what is in the public key portion, that is the part of your key-pair that is safe to share with people.  Assuming that you saved the key to the default location, that would be the following:

cat ~/.ssh/id_rsa.pub

Now we are going to place this public key onto your server.  You will want to replace the part between the quotes with whatever you got from the previous command.

mkdir -p ~/.ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQesAZ03ghoM/Ct89XDoLMN6oyDoe9jRKezfWn38S0fc7hzyBMAt3bxzPU68vR6k//ATQ5bY6U7PnVlJMncIBPsPlIaeHd5kuOa30lBYFpKuorLkAtly4n4N2ae1wxq6Xsw61j0MjI+d9rb80Ud+2EFDhRac++HHiTfiDyaoA+UMxz/EvWxC20VYnvBiLW1DgZg9kLSU5XGew+kk1d/936r2c7sykOaFWBGPi3Ptu6KSDy8YSiH39a0jTrwQSggTVHaRgPYGVd3ljl9gk1HkUtOBGLL7zyQ8CpG797ubXu2juoKEt25UNNhS1FcxoX/i700+pWiVoUqVmvruVPYzOR someuser@somesystem" >> ~/.ssh/authorized_keys

Now when you SSH into the server as the user someuser, you will log into your server using your keypair.  If you set a password on the private key like I recommended, it will prompt you for the password for the private key and then you will be logged in, if you didn’t set a password, you will just be logged straight in.  You will only be able to log in like this from systems that have a private key that is paired with one of the public keys in that authorized_keys file.  Yep, you can have more than one public key in that file, just make sure they are one per line.

3 ) Disable password logins

This next one will disable all logins using passwords, you will only be able to log in using other methods (such as the private key auth that we set up previously).  Make sure that you have that private key auth tested and verified working before you do this step.  Back on the server, edit the file at /etc/ssh/sshd_config and edit it. You will need to use your new sudo powers to edit this file if you are logged in as ‘someuser’. Find the line that looks like this:

#PasswordAuthentication yes

then uncomment it and change it to no, it should look like this whe you are done:

PasswordAuthentication no

4 ) Disable root logins

Again, make double sure that your logins as the someuser account work with your public key auth, and that you can use sudo to run commands because this next tweak will prevent anyone from SSHing into the server as root (although they will still be able to SSH in with their specific user account and then use sudo if you added them to the proper group in step 2).

Edit the file at /etc/ssh/sshd_config and edit it. You will need to use your new sudo powers to edit this file if you are logged in as ‘someuser’. Find the line that looks like this:

PermitRootLogin yes

Change it to no… it should look like…

PermitRootLogin no

5 ) Set up AllowUsers and/or AllowGroups

So now we have specified that root SSH logins are explicitly denied, now we are going to set a list of user accounts which will be the only user accounts that are allowed to SSH in to the server… once more edit the file at /etc/ssh/sshd_config and edit it. You will need to use your new sudo powers to edit this file if you are logged in as ‘someuser’. Then at the end of the file, add a line like this:

AllowUsers someuser anotheruser andanother

Alternatively (or in addition to) you can specify an AllowGroups line so that instead of specifying a list of users, you can specify a list of groups and then members of that group(s) will be allowed to log in over SSH like so:

AllowGroups somegroup anothergroup andanothergroup

Save the sshd_config and then restart SSH to get our new configuration in place:

service ssh restart

Before you log out of this ssh session, open up a new terminal, and once more make sure that you can SSH into the server. If you can, all is good… if you cannot, then you missed something somewhere, go back and review the last few steps and find where you made your mistake.

6 ) OPTIONAL: set up some brute force protection

If you followed ALL of the previous steps (mainly step 3) then this step is purely optional as it won’t give you that much added benefit. But if you did leave password logins enabled, then this step is HIGHLY HIGHLY recommended. We will be installing fail2ban which will basically watch your SSH logs, find IP addresses that fail to log in enough times in a short time period and then block their IP in the systems firewall:

apt-get install fail2ban

That’s it for step 6… really… the defaults for fail2ban are enough for 99% of servers. That said, it is amazingly configurable, how many failed login attempts, within what time period, results in a ban for how long, optionally sending an email off to someone to let them know someone got banned… You can even have it watch things other than just SSH, although SSH is the only thing it watches by default.

For further information on configuring fail2ban, I will refer you to the packages documentation since this is just a general overview article… that and if you are configuring fail2ban with custom jails and email notifications, you likely already know what you are doing when it comes to security.

7 ) Configure your firewall

I am not going to put any real documentation on how to configure your firewall here because what you chose to allow and deny will be heavily dependent on what you are running on your server. But you should configure your firewall to only allow what is needed and deny the rest.

8 ) Keep your software up to date

I have already written a pretty decent article covering this topic, so rather than rewriting it all here, just follow this link .

9 ) BONUS: The really annoying thing that people think makes them more secure and DOES NOT!

Do not even bother with changing what port your SSH server listens on. The only thing it will do is make it slightly more complex for you to SSH into your server. With a single tool, which is available right out of the repositories, I can trivially do a full port scan on your server, find every single open port, and probe them all to see what is listening there. If you move your SSH port from 22 to 8645, I can find it in a relatively small amount of time.

If you aren’t convinced yet, just remember that with the previous steps in place, anyone that stumbles across your server isn’t going to be able to log in over SSH anyway. Brute force attempts at SSH are extremely common, and with the previous steps, they are all but guaranteed to fail, and moving the port isn’t going to stop them anyway. For reference, the server that my personal blog runs on has SSH secured according to the steps listed here, listening on port 22, with no filtering in the firewall for port 22… yep… my port 22 is open to the world… I get at least 10 brute force attempts against it every day… this server has been around for well over a year now and there hasn’t been a single successful attempt.

Rather than moving the SSH port and adding a second or two to what it takes you to SSH into your server… spend those extra seconds fixing the input validation and SQL injections in your websites code… that will net you a better security benefit.