Securing a new Fedora 6 Slice
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. 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
