Introduction
Outlined here are the minimal security steps the Bonsai Framework uses in server builds.
Disable Direct Login as Root Through SSH
On a fresh Ubuntu setup from scratch the default values in your /setch/ssh/sshd_config is,
PermitRootLogin prohibit-password
This prevents password and keyboard-interactive authentication using the root account. However, if in a hardened environment we prefer root to not be available at all.
In this example, we are using a canned hosted Ubuntu system where the automated setup has the root account is enabled. This is dangerous because there are attackers out there looking for Unix/Linux boxes and trying to login via ssh using the username root and then a list of common passwords.
I do not like disabling the root account as this might break the hosted Ubuntu setup. For example, Slice's or Rackspace special terminal console login might stop working. In any event, the vector of attack is SSH login. To prevent users from using root, well don't provide the root password and provide sudo privileged accounts as shown in this article.
Connect to SSH as a staff user and edit sshd_config,
sudo nano /etc/ssh/sshd_config
Search for the line "PermitRootLogin yes" and change to "PermitRootLogin no". You can still issue su to go in as root but only after logging in as a user belonging to the admin group.
Last restart the SSH service for the changes to take effect.
sudo service ssh restart
In older versions of Ubuntu (to determine) where Upstart is not available use,
sudo /etc/init.d/ssh restart
Prevent SSH Brute Force Dictionary Attacks
As soon as it is on the Internet people will try to brute force attack your server over ssh. Basically they keep on pounding your system trying different passwords.
Just look in /var/log/auth.log to see some attackes,
cat /var/log/auth.log | grep "Invalid user" Jun 19 18:18:33 myra sshd[29346]: Invalid user oracle from 210.83.86.139 Jun 19 18:18:36 myra sshd[29349]: Invalid user test from 210.83.86.139 Jun 19 18:19:02 myra sshd[29381]: Invalid user kylix from 210.83.86.139 Jun 19 18:19:09 myra sshd[29387]: Invalid user www from 210.83.86.139
Fail2ban makes this kind of attack more difficult. After a chosen number of failed login attempts from the same ip address, fail2ban blocks that ip address for a set period of time. As constantly changing ip addresses is not a trivial task, the attacker may move on to another system.
HOWEVER, you can still be compromised within a few days if you are only using username and password authentication. If your SSH authentication is available on the Internet, you must switch to SSH Key Authentication as soon as possible.
sudo apt-get install fail2ban
The fail2ban installer also starts fail2ban as a service right after installation completes.
Most of the how fail2ban works is in /etc/fail2ban/jail.conf and here are the highlights,
maxretry = 6 # under the ssh section you are allowed 6 retries} bantime = 600 # 600 seconds = 10 minutes ignoreip = 127.0.0.1 # do not block list, and CIDR list
The default settigs of fail2ban are usually good enough but you can also customize fail2ban to suit your needs.
After a day or so on the Internet you should start seeing people getting banned in the logs, /var/log/fail2ban.log. Here is an example of an ip getting banned and then after 10 minutes it unbans,
2009-02-15 10:29:24,108 fail2ban.actions: WARNING \[ssh\] Ban 59.63.25.158 2009-02-15 10:39:24,137 fail2ban.actions: WARNING \[ssh\] Unban 59.63.25.158
Unbanning
To unban a user try these instructions. I am hesitant about playing with the ip tables in any way, so I have not tried myself. I usually just wait the 10 minutes.
According to the developers, Fail2ban version 0.9 will include an unban command through it's own client program.
Switch to SSH Key Authentication
If you system is on the Internet, switching to SSH key authentication this is a must do step.