Introduction

Outlined here are the minimal security steps the Bonsa Bonsai Framework uses in server builds.

Allow staff Group to sudo

Use account names associated with a user. For this example, I will be designating adminstrative users under the staff group. To see the list of groups available to you use the command, cat /etc/group.

The staff group by default does not normally have sudo access. To grant sudo access to the staff group,

sudo visudo

visudo launches your default editor to a special file. Add the following to the bottom of the file,

# Members of the staff group may gain root privileges
%staff ALL=(ALL) ALL

Create Catch-All serveradmin user

The purpose of serveradmin is the catch-all place to setup things like scripts. It may also, depending on requirements for your organization be used to manually setup software like application servers.

Also, the serveradmin account is limited in that it can not use sudo. If an attacker compromises the application, sudo is still out of reach.

Add the user and assign a password to that user,

sudo addgroup --gid 3000 serveradmin
sudo useradd -d /home/serveradmin -m -g serveradmin -u 3000 -c "Admin catch-all" -s /bin/bash serveradmin
sudo passwd serveradmin

Create Staff Users

...

Disable Direct Login as Root Through SSH

On a fresh Ubuntu setup from scratch the default values in your /setch/ssh/sshd_config is,

sudoPermitRootLogin useradd -d /home/bhitch -m -g staff -u 2000 -c "Support Bryan Hitch" -s /bin/bash bhitch
sudo useradd -d /home/jcassaday -m -g staff -u 2001 -c "Support John Cassaday" -s /bin/bash jcassaday
sudo useradd -d /home/wellis -m -g staff -u 2002 -c "Support Warren Ellis" -s /bin/bash wellis

Notice the -u which set's the user's GUIDs. We found it essential to standardize on the GUID of the accounts across all our systems consistently. Not doing so causes problems when it comes to cloning systems or moving programs across different environments. As a practice, we use the following GUID's ranges,

• Staff 2000-2499
• Guest Staff Users 2500-2999
• Custom services 3000 - 3999

Additionally, we use the following group GUID ranges,

• Custom services 3000 - 3999
• I further broke up my custom services with Web Groups for website management - 3100-3199

Next, we add to the Staff users the following groups,

• adm - so staff can view logs in apps setup without having to use the sudo command

Here is the command,

sudo usermod -a -G adm bhitch
sudo usermod -a -G adm jcassaday
sudo usermod -a -G adm wellis

Do not forget to set a passwords for the new accounts,

sudo passwd bhitch
Enter new Unix password:
Reenter new Unix password:
passwd: password updated successfully
sudo passwd jcassaday
sudo passwd wellis

Disable Direct Login as Root Through SSH

...

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.

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.

...

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 not worthwhile. 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 will move on to another system.

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.

More

This is basic Ubuntu Security. There is more.

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.