1.3 Minimal Ubuntu Linux Security Checklist
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-passwordThis 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_configSearch 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 restartIn older versions of Ubuntu (to determine) where Upstart is not available use,
sudo /etc/init.d/ssh restartInstall Fail2ban
Install fail2ban to prevent brute force attacks.
Switch to SSH Key Authentication
If you system is on the Internet, switching to SSH key authentication this is a must do step.
Comments
I have removed denyhosts as a recommendation. It appears to have the problem of denying users in the iptables and never letting them come in again. I have seen this with my own servers and my work servers at 2Keys.
Besides denyhosts seems to duplicate the functionality of fail2ban but with less flexibility focusing only on ssh attacks.
Just found out that according to Duncan this is actually expected behaviour. May put DenyHosts back in after some more reading. Some flags that would be wise to turn on,
RESET_ON_SUCCESS to on. That way a successful login will reset the number of allowed login attempts, http://denyhosts.sourceforge.net/faq.html#2_21
Also need instructions how to unban someone, it may just be a matter of editing /etc/hosts.deny
The steps to unblocking a user from DenyHosts seems to be a bith lengthy. My initial impression is would cause quite a bit of problems for newbies.
If this is to be recommended for the uninitiated it needs more documentation and should be used in conjunction with key based authentication.
Recently I noticed attacks like this which are not being banned by fail2ban by looking into the /var/log/auth.log
Jun 13 16:50:18 krypton sshd[18636]: reverse mapping checking getaddrinfo for 68-168-212-106.ip.static.interserver.net [68.168.212.106] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:50:19 krypton sshd[18641]: reverse mapping checking getaddrinfo for 68-168-212-106.ip.static.interserver.net [68.168.212.106] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:50:20 krypton sshd[18643]: reverse mapping checking getaddrinfo for 68-168-212-106.ip.static.interserver.net [68.168.212.106] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:55:23 krypton sshd[18689]: reverse mapping checking getaddrinfo for del-static-151-71-7-210.direct.net.in [210.7.71.151] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:55:25 krypton sshd[18692]: reverse mapping checking getaddrinfo for del-static-151-71-7-210.direct.net.in [210.7.71.151] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:55:28 krypton sshd[18694]: reverse mapping checking getaddrinfo for del-static-151-71-7-210.direct.net.in [210.7.71.151] failed - POSSIBLE BREAK-IN ATTEMPT! .... IT KEEPS ON GOING .... Jun 13 16:58:36 krypton sshd[18884]: reverse mapping checking getaddrinfo for del-static-151-71-7-210.direct.net.in [210.7.71.151] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:58:38 krypton sshd[18886]: reverse mapping checking getaddrinfo for del-static-151-71-7-210.direct.net.in [210.7.71.151] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:58:40 krypton sshd[18888]: reverse mapping checking getaddrinfo for del-static-151-71-7-210.direct.net.in [210.7.71.151] failed - POSSIBLE BREAK-IN ATTEMPT! Jun 13 16:58:40 krypton sshd[18888]: Invalid user r00t from 210.7.71.151Notice the timeframes. Neither fail2ban or denyhosts seem to take effect. I do not see this IP address in my fail2ban logs. Yet I still see other attacks with the same error like this being banned after 6 tries by fail2ban.
This thread seems to indicate that it is a date format issue in the SSH logs most likely to me using the Canadian Locale.
http://www.howtoforge.com/forums/archive/index.php/t-32279.html