After you create a new Cloud Server, we recommend that you perform the following tasks to enhance security of the server: 

1. Log into Your Server
2. Change the Root Password
3. Add an Admin User
4. Setup Public and Private Keys
5. Modify the SSH Configuration
6. Set Up a Private Firewall Using iptables in Ubuntu or Set Up a Private Firewall Using iptables in RedHat

Note: Small modifications to the commands below may be necesssary if you're using a different distribution. If necessary, refer to your operating system documentation.

Log into Your Server

As soon as you have your server's IP address and password, log in using the following SSH command:

ssh root@123.45.67.890

Note: If you're logging into a rebuilt server, you may see a message that the "remote host identification has changed". When you rebuild a Cloud Server, the remote host key changes, which makes your computer think there is something suspicious or unusual going on. To avoid this issue, simply remove the older entry for the server IP. On your local computer, edit the SSH known_hosts file and remove any entries that point to your Cloud Server IP address using the following command:

nano ~/.ssh/known_hosts

If your local computer running an operating system other than Linux or OS X, the location of the known_hosts file will differ. Refer to your OS documention to learn the location of this file.

Change the Root Password

After logging into your server, change the root password and assign the admin user Super User privileges. To change the root password, issue the following command:

passwd

Add an Admin User

1. To add an admin user, issue the following command and replace with "demo" the user name of your choice:

adduser demo

Note: After this initial step, you should not log in as root user to perform daily operations on your server. However, you'll need Super User (sudo) privileges to complete these administrative tasks.

2. To assign the admin user sudo privileges, issue the following command, which invokes the nano editor by default on Ubuntu:

visudo

3. At the end of the file add your administravie user name (in place of our example "demo" user below) and the following text string:

demo   ALL=(ALL) ALL

4.  When you are finished adding this line, exit, confirm, and save the file, using these commands:

Press the key combination Ctrl-X to exit.

Press y to confirm the changes.

Press the Enter key to save the file as /etc/sudoers.tmp.

Note: You may find that while working in the nano editor, the backspace/delete key works backwards, deleting characters in front of the cursor rather than behind it. This can be resolved by editing the /etc/nanorc file (with nano, for example) and either uncommenting or adding the line:

set rebinddelete

 The new behavior takes effect after the file has been saved and nano has been opened again.

Set Up Public and Private Keys (SSH keygen)

One effective way of securing SSH access to your Cloud Server is to use a public/private key. This means that a public key is placed on the server and the private key is on your local workstation. This makes it impossible for someone to log in using just a password - they must have the private key. This consists of 3 basic steps: create the key on your local workstation, copy the public key to the Cloud Server, and set the correct permissions for the key. 

The following instructions assume you use Linux or OS X. For Windows instructions, see Key generation using Putty for Windows.

Step 1. Create the Public and Private Keys

• Create a folder to hold your keys on your LOCAL workstation:

mkdir ~/.ssh

• To create the ssh keys, on your local workstation enter:

ssh-keygen -t rsa 

If you do not want a passphrase then just press enter when prompted.

The id_rsa and id_rsa.pub are created in the .ssh directory. The rsa.pub file holds the public key. You'll place this file on you server.

The id_rsa file is your private key. Never show, give away, or keep this file on a public computer.

Step 2. Copy the Public Key

You can use the scp command to place the public key your server. 

1. While still on your local computer enter this command, substituting your admin user for "demo" below:

scp ~/.ssh/id_rsa.pub demo@123.45.67.890:/home/demo/

2. When prompted, enter the admin user password.
3. Change the IP address to your server and the location to your admin user's home directory (remember the admin user in this example is called demo).

Step 3. Modify SSH Permissions

1. Create a directory on the admin user's home folder on your server called .ssh and move the pub key into it, as shown in the following examples:

mkdir /home/demo/.ssh
 mv /home/demo/id_rsa.pub /home/demo/.ssh/authorized_keys

2. Set the correct permissions on the key using the following commands, changing the "demo" user and group to your admin user and group:

chown -R demo:demo /home/demo/.ssh
 chmod 700 /home/demo/.ssh
 chmod 600 /home/demo/.ssh/authorized_keys 

Congratulations! You have now successfully created the key on your local computer, copied the public key to your Cloud Server, and set the correct permissions for the key. 

Modify the SSH Configuration

Keeping the SSH service on the default port of 22 makes it an easy target. We recommend changing the default SSH configuration to make it more secure. 

1. Issue the following command:

nano /etc/ssh/sshd_config 

2. Modify, check, and add the following values: 

Port 22                           <--- change to a port of your choosing
 Protocol 2
 PermitRootLogin no
 PasswordAuthentication no
 UseDNS no
 AllowUsers demo

3. Change the default port of 22 to one of your choosing, turn off root logins, and define which users can log in.

Note: The port number can be any integer between 1025 and 65536 (inclusive). Be sure to note the new port number and remember to avoid port conflicts if you later configure additional listening processes.

PasswordAuthentication has been turned off as we setup the public/private key earlier. If you intend to access your server from different computers, you may want to leave PasswordAuthentication set to yes. Only use the private key if the local computer is secure (i.e. don't put the private key on a work computer).

Note that these settings are not enabled yet. First you should create a simple firewall using iptables before restarting ssh using the new port.

NOTE: Do not restart ssh yet.

Set Up a Private Firewall Using iptables in Ubuntu

The utility called iptables is the default firewall for Linux systems. It works by refusing connections to ports or services that you specify. 

As part of this procedure, you'll open three ports: ssh, http, and https. 

You'll then create two files:

• /etc/iptables.test.rules

• /etc/iptables.up.rules

The first is a set of temporary test rules and the second is the permanent set of rules iptables will use.

Note that you need to root user permissions to complete procedure. If you're not currently logged in as root, use the sudo command in front of the following commands.

1. Issue the following command to see what's currently running:

iptables -L

You'll see something similar to this:

Chain INPUT (policy ACCEPT)
 target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
 target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
 target     prot opt source               destination

This means the server is are accepting anything from anyone on any port.

Some people think that this is not dangerous if there are no services running on the server, and it doesn't matter that all ports are open. We disagree. If connections to unused (and popular) ports are blocked or dropped, then the vast majority of malicious intruders will move on to another machine where ports are accepting connections. It only takes a few minutes to set up a firewall - so we highly recommend that you do so to protect your server.

2. To build the firewall, create the file /etc/iptables.test.rules and add some rules. If you have worked through these steps previously, this file may not be empty:

nano /etc/iptables.test.rules 

Change and add ports as necessary.

3. Issue the following command to apply the rules to our server:

iptables-restore < /etc/iptables.test.rules

4. Issue the following command to note any differences:

iptables -L

If there is no change in the output, repeat the previous steps and try again.

Check the rules and see exactly what is being accepted, rejected and dropped. When you're satisfied with the rules, save them permanently by issuing the following command:

iptables-save > /etc/iptables.up.rules

Note: If the server is rebooted before this step, the changes are lost and the server reverts to the previous settings.

5. Add a small script that the system will run when your network interfaces are started. Create the file by running:

nano /etc/network/if-pre-up.d/iptables

Add the following lines to the new file:

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules

Save your changes, and then make the new script executable:

chmod +x /etc/network/if-pre-up.d/iptables

That should ensure that whenever your network interfaces are brought up (usually just at boot time), the firewall will be too.

iptables in Red Hat

If you are using a Red Hat distribution, iptables works a little differently.  Using the commands below, you can change your iptables ruleset directly from the command line.

HTTP - Port 80

Use the following command to open port 80 for HTTP (web) traffic in your iptables firewall:

# sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport http -j ACCEPT

HTTPS/SSL - Port 443

Use the following command to open port 443 for Secure HTTP traffic:

# sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport https -j ACCEPT

SSH - Port 22

Though port 22 is open by default to allow you to SSH to your server after it is built, this command shows you how you would open port 22:

# sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport ssh -j ACCEPT

FTP - Port 21

FTP is a common service for file transfer, but it is largely obsolete due to the fact that it is not a secure protocol and we strongly recommend using a secure file transfer protocol like sftp.  If you absolutely have to use FTP, use these commands to open the default port of 21.

# sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport ftp -j ACCEPT
 # sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport ftp-data -j ACCEPT

MySQL - Port 3306

If you need to make a remote connection to your MySQL database from another server, you will need to open port 3306 in iptables.

# sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport mysql -j ACCEPT

Saving Your Rules

Use the following command to save all the rules you’ve created.  If not saved before your server is rebooted, the iptables ruleset will revert to the default ruleset blocking all traffic except on port 22!

# sudo /sbin/service iptables save

Restarting iptables

Your changes to iptables will not take effect until you save your rules, and then restart the iptables service.  Remember, if you restart iptables before saving your rules, iptables will revert to the default ruleset!

# sudo /sbin/service iptables restart

Restarting ssh

Now we'll restart the ssh service.  Make sure you stay logged in while you restart ssh and test it with a new connection.  That way if something goes wrong you can troubleshoot it more easily.

On most distributions the service is "sshd", and you restart it with the command:

# sudo service sshd restart

On Ubuntu and some other distributions it's called "ssh", and is restarted with a similar command:

# sudo service ssh restart

If you have trouble making a new connection after restarting ssh, check the symptoms to see what may be wrong.  If the connection times out, there may be a problem with the iptables config.  If you get a warning about a private key, your key may not be installed on the server properly (check for extra linebreaks or characters that were missed in a copy and paste operation).  If you've been rebuilding the server then you may need to remove the host key from your known hosts file before you can make a connection.

If you're locked out...

The incorrect configuration of SSH, sudo and/or iptables could cause you to be locked out of your system.  If this occurs, please log into the The Rackspace Cloud Control Panel and use the Web Console or Rescue Mode to repair the configurations.

These are the basics of connecting to a Linux Cloud Server and setting up security.  See Windows Cloud Server to be perform these steps on a Windows server.