fluidBlog

Within hours of a new slice’s creation, /var/log/secure will start recording brute force attack attempts to gain access to your slice unless you take steps to secure your slice. If you doubt it, login to your slice and execute lastb.

This post is a compilation of useful steps I found in the articles I’ve cited in the References. I’ve combined and adapted them for my situation which is a local server running Fedora 6 setting up a newly built remote Fedora 6 slice from Slicehost. If you have a different setup, your mileage may vary.

Lets start from the creation of a new Fedora 6 slice. You’ve received your new root login password, and Slicehost has helpfully suggested that you change it immediately after logging in. dull-thing Login from local as root

[user@localhost ~]$ /usr/bin/sudo ssh your.slice.ip.address

Change the root password to a strong password

[root@remote ~]$ /usr/bin/passwd

Next, before we disable root login via ssh, we need to create a new user id that we can use to login to the slice. If you are not going to turn off password authentication, then pick a name that you have not used publicly. Remember, we are trying to defend against a brute force attack. Therefore, don’t give the attacker an entry by using a user id that can be guessed. Its easy to guess root and that is one reason why we will be disabling root login via ssh.

[root@remote ~] /usr/sbin/useradd user_id

Change the user’s passwd

[root@remote ~] /usr/bin/passwd user_id

Your new slice doesn’t have sudo installed. Before we yum install anything, we’ll first update the system.

[root@remote ~] /usr/bin/yum -y update

Next, install sudo

[root@remote ~]$ /usr/bin/yum -y install sudo

Give the new user sudo privelage. Edit /etc/sudoers and find the line that says

root ALL=(ALL) ALL

Duplicate this line and change root to user_id.

[root@remote ~]$ /usr/sbin/visudo

Before continuing, start a new terminal on local (don’t exit your current session in case you need it) and test that you can login via your new user id, and that the new user can execute su and sudo successfully. If the user id on the remote system is different from the user id on your local system, you can use the -l switch to specify the user to login as on the remote machine.

[user@localhost ~]$ ssh -l remote_user_id the.slice.ip.address

It would be also be a good idea to make sure you can reach your slice via the console from SliceManager.

Next we are going to disable root login via ssh because a lot of attacks will start with trying to login as root. To disable root login via ssh, edit the file /etc/ssh/sshd_config and set PermitRootLogin to no.

[root@remote ssh]$ /bin/vi sshd_config

Note: Commented lines are defaults. A good practice is to duplicate the default line, uncomment the duplicate line, and edit.

#PermitRootLogin yes
 PermitRootLogin no

Restart sshd

[root@remote ssh]$  /sbin/service sshd restart

Test that you can no longer login as root.

[user@localhost ~]$ sudo ssh the.slice.ip.address

You should get the response

Permission denied, please try again.

If you don’t want your logs filled and your slice’s resources wasted by processing brute force attacks, then there are some additional things that can be done.

First we are going to set things up so that eventually we can disable password authentication for ssh and use public key cryptography.

Generate a key on your local system

[user@localhost ~]$ /usr/bin/ssh-keygen -t rsa -f ~/.ssh/id_rsa

Create .ssh directory on remote system and copy the public key you just created to the .ssh directory.

Create the directory .ssh on remote.

[user@localhost ~]$ /usr/bin/ssh user@domain
> 'mkdir ~/.ssh;chmod 700 ~/.ssh'

Note: The “>” on the second line of the command above is the system prompt when you continue the command on a new line with a backslash. Don’t type “>” before “mkdir”.

Note: The following directories on remote must be writable only by user or they will be ignored.

drwxr-xr-x  ...  /home/user
drwxr-xr-x  ...  /home/user/.ssh
-rw-r--r--  ...  /home/user/.ssh/authorized_keys

Copy your public key to the remote server. Since this is a new slice you won’t have scp installed unless you have already executed yum install openssh-clients, so we’re going to copy like a wizard using file redirection.

[user@localhost ~]$ /usr/bin/ssh user@domain cat <
> ~/.ssh/id_rsa.pub ">" ~/.ssh/authorized_keys

Note: The “>” on the second line of the command above is the system prompt … I know I need to find a better way to display these commands!

Ensure that the file authorized_keys is writable only by user

[user@localhost ~]$ /usr/bin/ssh user@domain 'chmod 600
> ~/.ssh/authorized_keys'

If ssh agent is not running on local system

[user@localhost ~]$ /usr/bin/ssh-agent $SHELL

Add key to memory on local system

[user@localhost ~]$ /usr/bin/ssh-add

Test that you can login to your slice without being prompted for a password or passphrase.

[user@localhost ~]$ ssh the.slice.ip.address
Last login: Sat Apr 14 14:35:25 2007 from ...
[user@remote ~]$

Now that we have created a user to login to the slice and set up our public key, we can turn off password authentication and passphrashe authentication, and disable the older less secure protocol 1. Edit the file /etc/ssh/sshd_config

[user@remote ~]$ /usr/bin/sudo /bin/vi /etc/ssh/sshd_config

#PasswordAuthentication yes
PasswordAutheentication no

#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

#Protocol 2,1
Protocol 2

Also if you installed openssh-clients, edit the file /etc/ssh/ssh_config and restrict it to Protocol 2 as well. sshd_config is for the daemon and ssh_config, the client. Both are restricted to Protocol 2 to ensure that a man-in-the-middle attack cannot cause both client and server to degrade to the less secure Protocol 1.

Restart sshd

[root@remote ssh]$  /sbin/service sshd restart

Again, open a new terminal and test that you can login.

Next we want to change the port that ssh listens to. This will cut down on a lot of log entries, but it doesn’t make the system more secure. Again edit /etc/ssh/sshd_config

#Port 22
Port 2222

Pick something more original than 2222. Preferably pick an unassigned port above 1000, check this list.

You might also consider changing MaxAuthTries, MaxStartups, and LoginGraceTime, see Securing SSH

Don’t forget to restart sshd after any changes.

[root@remote ssh]$  /sbin/service sshd restart

Login and test the port change

[user@local ~]$ ssh -p 2222 the.slice.ip.address

Next we want to install denyhosts and start it running

[user@remote ~]$ /usr/bin/sudo /usr/bin/yum -y install denyhosts
[user@remote ~]$ /usr/bin/sudo /sbin/chkconfig denyhosts on
[user@remote ~]$ /usr/bin/sudo /etc/init.d/denyhosts start

The default denyhosts configuration meets most needs but if you want to edit the configuration, the file is /etc/denyhosts.conf. See the documentation at DenyHosts

Next we want to setup a firewall

[user@remote ~]$ /usr/bin/sudo /usr/bin/yum -y install iptables

Edit /etc/sysconfig/iptables and paste in the following configuration from CentOS: Network Security & Django which worked for me, thanks djangojoe. Make sure to open the port that you have SSH listening on.

# By default drop all incoming and forwarded traffic
# Allow all outgoing traffic

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Allow returning packets
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow incoming traffic on ports 80 and 443 for web server
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow local traffic
-A INPUT -i lo -j ACCEPT

# Allow ping
-A INPUT -p icmp --icmp-type ping -j ACCEPT

# Allow incoming SSH
-A INPUT -p tcp --dport 2222 -j ACCEPT

COMMIT

Change permission on /etc/sysconfig/iptables to make it writable only by root

[user@remote ~]$ /usr/bin/sudo chmod 600 /etc/sysconfig/iptables

Restart the firewall

[user@remote ~]$ /usre/bin/sudo /sbin/service iptables restart

Ok, we’re done and a bit more secure. Many thanks to the authors of the following references.

References

• Securing SSH
• CentOS: Network Security & Django
• Port Numbers
• Getting Started with SSH
• DenyHosts