sudo apt-get install fail2ban

Installing the SSH Server

It is possible that an SSH server was installed when you installed your Ubuntu system, a simple test for this would be to run the following command:

which sshd

This command will tell you where the sshd program is located on the system.  If there is no output from this command, it suggests that you will need to install an ssh server.  If this command provides an output, such as “/usr/sbin/sshd“, it suggests that the ssh server is already installed on your system.  In this case, you could try to connect to your local system using the following command:

ssh localhost

If you can successfully connect, then your ssh server is already installed, otherwise you may be presented with an error message along the lines of “ssh: cannot connect to host localhost port 22: Connection refused“.  This error message may indicate that you need to install the ssh server (though can be caused by other issues).

To install the SSH server, simply run the following command:

sudo apt-get install openssh-server

This command will download, install and start the ssh server for you.  If this has completed successfully, it should now be possible to use the “ssh localhost” command to connect to your system.  You should be presented with a message similar to the one below:

The authenticity of host ‘localhost (127.0.0.1) can’t be established.  ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)?

This simply means that you are connecting to a server that you haven’t connected to before (unsuprisingly as you have only just installed it!).  Typing ‘yes‘ will allow you to finish connecting and will mean that the next time you connect the computer will recognise the server you are connecting to and will not ask you for this confirmation again (unless the fingerprint for the server changes – which would possibly indicate an attack).

Configuring the SSH Server

The ssh server can be configured by editing the configuration file found at “/etc/ssh/ssh_config“.  This file can be edited using your favorite text editor, e.g.

sudo vi /etc/ssh/ssh_config

Information about the effect and nature of each of the different elements in the configuration file can be found using the following command (or via Google):

man sshd_config

If you make changes to the configuration file, it will probably be necessary to restart the SSH server in order for the changes to be effected.  As of Ubuntu 11.04, this can be achieved using the following command:

sudo service ssh restart

However for earlier versions of Ubuntu (and possibly other Linux distributions), you will need to use the following command:

sudo /etc/init.d/ssh restart

 

Securing the SSH Server

Due to the power and flexibility that SSH access gives you on a remote server, as well as its widespread use, it is an obvious target for attack from the big bad world.  This means that attackers have written scripts which will automatically try to login to your server using as many different username/password combinations as possible until they find one that works.  Once they have found a working combination, they will be able to do anything on your server that the user whose username/password combination they have uncovered – this will probably include running the same password-guessing program on your server so that your server will work for the attacker, helping attack other servers (and appearing as though it is you doing it!).  To see these attacks in action, simply take a look at the log files for the ssh server which are stored in “/var/log/auth.log“.  On any standard internet connected server that has been around long enough to be discovered, it will be possible to watch these attacks occuring in in real time (with numerous login attempts occuring every second) using a command such as:

sudo tail -f /var/log/auth.log

It is therefore highly desrable to secure your SSH server as far as possible.  The following are some suggestions that could help secure the server:

1. Use strong passwords – this one really speaks for itself and is a general principle that should be adopted for any passwords.  When attacking your SSH server, an attacker will know the passwords that people commonly use, as well as the mutations that people commonly apply to standard words to create a password.  An attacker (or automated attack script) would therefore try these first and will guess these first.  Using strong passwords will help improve your resilience to these types of attack.
2. Change the SSH Port – the standard port for SSH servers to listen to for incoming connections is port 22.  Attackers are well aware of this and therefore the bulk of the automated scripts that are run will assume that an SSH service is run on port 22 – if it can’t be found on this port, there is a high probability these scripts will give up and move onto easier targets.  Changing the default port number will therefore help reduce your exposure to these scripts.  Clearly this won’t help protect you against a determined attacker who is targetting you, but there is a lot to be said for not being found in the first place.  To change the port, edit the configuration file (as described above) to include the following line (replacing the xxxxx with your chosen port number):  Port xxxxx to connect to your server you will now need to specify your chosen port number.  For example, to connect from the command line, you will need ssh -p xxxxx localhost
3. Disable root login – modern linux systems have moved away from using a ‘root’ (or super-user) account directly, instead allowing specific users to run individual commands with elevated privileges via the ‘sudo‘ command.  When attacking a remote server, however, attackers are aware that there is a high probability of a ‘root‘ user account existing, they may therefore simply guess passwords for this account and so remove one of the unknown variables that they need to guess.  A high proportion (but by no means all) of the brute force guesses will therefore be against the ‘root‘ account.  To disable the ability to login as root via ssh, edit the configuration file (as described above) to include the following line:
   

   PermitRootLogin no

4. Restrict Users that are Allowed to login via SSH – For similar reasons, an attacker will also use other common usernames that exist on a lot of systems.  To see a list of usernames that might be used on your system, you can use the following command: cat /etc/passwd There are far more user accounts than simply the users of the system, none of which will need to connect via SSH.  It is therefore desirable to limit SSH logins to just the users that  you desire.  This can be achieved by editig the configuration file (as described above) to include the following line:  AllowUsers username1 username2 You will need to list all usernames that should be allowed to connect, as no other users will be allowed.
5. Automatically Block Attackers – When attacking your system, it is highly probably that an attacker is going to require multiple attempts in order to correctly guess a username/password combination, particularly if the above steps have been taken.  That being the case, there are programs and scripts which can monitor the number of failed login attempts and automatically add firewall rules to block those addresses that make too many consecutive failed login attempts.  One caveat is that obviously if you configure these to be too agressive, you can end up locking yourself out of your own system as well, although a lot of tools have features to automatically unblock addresses again after a period of time has elapsed (which will serve to massively slow down any brute force attack).  My preferred tool for this is called Fail2Ban – I will cover how to install and set it up in a later post, as it can be used for more than just securing SSH access.
6. Use certificates instead of passwords – <To Be Completed>