www.bonsaiframework.com
Page tree
Skip to end of metadata
Go to start of metadata

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

Install 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.


  • No labels

4 Comments

  1. Tin Pham

    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.151

    Notice 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

  2. Tin Pham

    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.

    1. Tin Pham

      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

      1. Tin Pham

        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.