Your new slice
These two articles will take you from a ‘barebones’ CentOS 5.4 Slice to a secured and up-to-date Slice ready for your server software (or whatever you use the Slice for). Not only that, you will have a better understanding of what is going on and, more importantly, why it’s going on.
This first part will walk you through setting up a new user and securing login access to your slice.
First login
As soon as you have your IP address and password for your Slice, login via SSH:
ssh root@123.45.67.890
If you are on a Windows machine you may need to install an SSH client like Putty in order to make the connection.
If you rebuilt your Slice, you may get a message informing you that the ‘remote host identification has changed’.
When you log into a Slice via SSH, one of the security features is matching the remote host with known keys. When you rebuild a Slice, the remote host key changes. As such, your computer thinks there is something dodgy going on.
All you need to do is remove the older entry for the Slice IP:
On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your Slice IP address.
nano ~/.ssh/known_hosts
If you are not using Linux or a Mac on your LOCAL computer, the location of the known_hosts file will differ. Please refer to your own OS for details of where this file is kept.
User administration
Now we’re logged in to the VPS, immediately change your root password:
passwd
Apart from this initial setup, you should never log in as the root user. It’s safer and more secure to create a new administrative user and use the ’sudo’ command from that user. Having to use sudo to run superuser commands can help prevent some potentially system-breaking accidents, and it also means that any root-level commands run through sudo will be logged to ‘/var/log/secure’ if later review is needed.
To make managing administrative access to your slice easier let’s designate a group, ‘wheel’, that will contain users with sudo privileges.
Issue the ‘visudo’ command to edit the sudo configuration:
/usr/sbin/visudo
The visudo command runs a default editor, and will check the configuration for any syntax errors before saving it.
The rest of this tutorial will refer you to ‘nano’ for editing text files, which is a bit nicer about being easy to use and having an on-screen tip telling you how to bring up a helpfile. For security reasons, however, visudo on CentOS will only use ‘vi’.
If you’re new to Linux, or have never used the ‘vi’ editor before, then you’ve come to the hardest part of this tutorial. While vi is a powerful editor once you’ve learned it, ‘user friendly’ is definitely not on its list of features. You’ll want to hit a search engine and look for something along the lines of ‘vi quickstart’ to find a reference, since an introduction to vi would be too much to fit into this article. Just know that if things get too weird, hit escape a couple times and type ‘:q!’ to get out of vi without saving. Then you can start over.
Once you’ve run visudo, near the bottom of the file you will find this entry:
## Allows people in group wheel to run all commands
# %wheel ALL=(ALL) ALL
Simply uncomment the second line (remove the ‘#’) so it looks like this:
## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
Make sure to only uncomment that line, not the one with the ‘NOPASSWD’ option that follows. It sounds more convenient, but in practice the password requirement for using sudo isn’t so bad (and provides more protection).
Save and exit the file, and sudo is all set. Members of the ‘wheel’ group will now have full sudo privileges.
Add a new user
Time to create a new administrative user (I’ve used the name demo here but any name will do).
/usr/sbin/adduser demo
You will need to specifically set the password for your new user:
passwd demo
Since you’ll want to use this user instead of ‘root’ to manage your system, it will need to be able to use the sudo command. We’ve already granted that permission to the ‘wheel’ group, so we just need to add the new user to ‘wheel’:
/usr/sbin/usermod -a -G wheel demo
SSH keygen
One effective way of securing SSH access to your slice is to require users to use a public/private key pair. This means that a ‘public’ key is placed on the server and a matched ‘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.
The first step is to create a folder to hold your keys. On your LOCAL workstation:
mkdir ~/.ssh
That’s assuming you use Linux or a Mac and the folder does not exist. For Windows users we have a separate article on key generation using Puttygen.
To create the ssh keys, on your LOCAL workstation enter:
ssh-keygen -t rsa
If you do not want your key to require a passphrase when used then just press enter when prompted.
That created two files in the .ssh directory: id_rsa and id_rsa.pub. The pub file holds the public key. This is the file that is placed on the Slice.
The other file is your private key. Never share this file with someone else or store it on a public computer.
SSH copy
Now we need to get the public key file onto the Slice.
We’ll use the ’scp’ command for this as it is an easy and secure means of transferring files.
Still on your LOCAL workstation enter this command, substituting your new username and the IP address of your slice:
mkdir ~demo/.ssh
mv ~demo/id_rsa.pub ~demo/.ssh/authorized_keys
If you haven’t run into it before, that squiggly character is the ’tilde’, and it’s usually in the upper-left of your keyboard. In the Linux shell it can be used as a reference to a user’s home directory. Using ‘~’ by itself refers to the current user’s home directory, while using it like we did above, ‘~demo’, refers to the home directory of user ‘demo’. It’s a handy shortcut to know.
Now we can set the correct permissions on the key:
chown -R demo:demo ~demo/.ssh
chmod 700 ~demo/.ssh
chmod 600 ~demo/.ssh/authorized_keys
Again, replace the ‘demo’ user and group above with the name of the user you created.
Additional users
If you need to add more users to your system, now or after you finish this initial setup, you can just run through the steps above again for each user.
If the user doesn’t need to have administrative privileges, skip the part where you add the user to the ‘wheel’ group.
If the user will be accessed from the same workstation as your administrative user, you can re-use the same public SSH key for the new user.
SSH config
Next we’ll change the default SSH configuration to make it more secure:
nano /etc/ssh/sshd_config
You can use this ssh configuration as an example.
The main things to change (or check) are:
Port 30000 <— change to a port of your choosing Protocol 2 PermitRootLogin no PasswordAuthentication no X11Forwarding no UsePAM no UseDNS no AllowUsers demo
NOTE: The port number can readily be any integer between 1025 and 65536 (inclusive), but should be noted for reference later when any additional listening processes are setup, as it will be important to avoid conflicts.
If you need to allow remote logins for more than one user, add the additional users to the ‘AllowUsers’ setting separated by spaces.
The labels are fairly self explanatory, but the main security changes to make are to move ssh from the default port of 22 to one of your choosing (we use 30000 in the example), turn off remote root logins, and define which users can log in remotely.
PasswordAuthentication has been turned off because we setup the public/private key earlier. Do note that if you intend to access your slice from different computers you may want leave PasswordAuthentication set to ‘yes’. Only use the private key on a secure workstation.
Note that we haven’t enabled the new settings — we will restart SSH in a moment, but first we need to create a simple firewall using iptables.
iptables
Right, now we have the basics of logging in and securing SSH done.
Next thing is to set up our iptables (firewall) so we have a more secure installation. It’s possible to skip this step, or to disable iptables entirely, but we recommend that if you follow the Slicehost tutorials, you set up iptables with our default rules. It’s a good hindrance to would-be intruders.
The default rules
Let’s have a look at the default iptables rules:
/sbin/iptables -L
Remember that if you come back to this part of the tutorial as a non-root user later, you’ll need to put a ’sudo’ in front of the iptables command to make it work.
The default setup will output something similar to this:
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all – anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all – anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all – anywhere anywhere
ACCEPT icmp – anywhere anywhere icmp any
ACCEPT esp – anywhere anywhere
ACCEPT ah – anywhere anywhere
ACCEPT udp – anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp – anywhere anywhere udp dpt:ipp
ACCEPT tcp – anywhere anywhere tcp dpt:ipp
ACCEPT all – anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp – anywhere anywhere state NEW tcp dpt:ssh
REJECT all – anywhere anywhere reject-with icmp-host-prohibited
There’s too much there to go into much detail in this article, but the basics to pay attention to when you skim those firewall rules are ‘ACCEPT’, ‘REJECT’, ‘INPUT’, and ‘OUTPUT’. Fortunately those are reasonably understandable in context. Rules can refer to incoming traffic (‘INPUT’) or outgoing traffic (‘OUTPUT’), and they can describe whether to ‘ACCEPT’ or ‘REJECT’ the described connections. The rest of it determines the sort of traffic being controlled, like what port or packet type it’s looking for.
Roll your own
Of course, now that we’ve looked over the default iptables rules and tried to understand them a little, we’re going to throw them out to make room for new ones. Flush the iptables rules by running the command:
/sbin/iptables -F
If you check the rules again, you’ll see that all the ‘ACCEPT’ and ‘REJECT’ stuff is gone. We can now set up our own rules that allow local connections and keep established connections (which is how the root SSH connection on port 22 will still work when we apply the SSH port changes and apply the new iptables rules).
We’ll also open port 80 and port 443 (the normal HTTP and HTTPS ports) and, of course, allow connections to our custom SSH port. Then we’ll allow pings to the Slice and, effectively, reject all other attempts to connect to a port.
To make it easier to keep track of the rules you want iptables to use and to change them later, let’s create a file to store them:
nano /etc/iptables.up.rules
Now check out our example iptables rules file. Copy and paste those rules into your new file, and edit the rules however you see fit. The comments should help you decide what to change. In particular, make sure you change the line opening port 30000 to whatever you chose as your custom ssh port.
The lines opening ports for a web server should provide a good template for opening ports for other services you may add to your slice later.
If you want more complex firewall rules (restricting outbound traffic as well as inbound, for example), you might do well to research iptables more after you’re done with this basic setup.
Once you’re happy with your iptables rules, save the file.
Implement your rules
To tell iptables to use your new rules, run the command:
/sbin/iptables-restore < /etc/iptables.up.rules
That will read in the custom rules from the file you just created. You can confirm that it worked by checking the rules again:
/sbin/iptables -L
See the difference between the first time we entered that command and now? Again, have a look at each line of the output and see where it marries up with the rules we entered earlier.
Although the rules are up and running, they are only active for the current session. If the Slice were to be rebooted they would be lost.
As such, let’s ensure they are restored on a Slice reboot:
/sbin/service iptables save
The output confirms the rules were added to the correct file:
Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
Feel free to have a look at that file and note the familiar syntax.
Editing iptables later
You can repeat these steps if you decide you’ve made a mistake, or if you want to change any rules later. Just edit the rules file you created, flush the current rules from memory, restore the edited rules, and save the new rules to the system’s configuration.
The commands you’d use (without all the commentary) are:
nano /etc/iptables.up.rules
/sbin/iptables -F
/sbin/iptables-restore < /etc/iptables.up.rules /sbin/service iptables save
Good work. Onward!
Reload sshd
Now we have our basic firewall humming along and we’ve set the ssh configuration. Time to test it. Reload ssh so it uses the new ports and configurations:
/etc/init.d/sshd reload
Don’t logout as root yet…
Logging in with the new user
On your LOCAL computer, open a new terminal and log in using the administrative user (in this case, demo) to the port number you configured in the sshd_config file (for our example, 30000):
ssh -p 30000 demo@123.45.67.890
The reason we use a new terminal is that if you can’t login you will still have the working root connection to try and fix any errors.
Slicehost also has an excellent ajax console so if it all goes horribly wrong, you can log into your slice from the Slicehost management area.
You should be greeted with a plain terminal prompt like this:
[demo@yourvpsname ~]$
Success!
Tidak ada komentar:
Posting Komentar