A Rabbit's Guide to Installing & Securing CentOS 7 Servers
This guide is designed for anyone who is running a Linux based server, however, examples in the guide are generally tailored to CentOS 7. This guide is not comprehensive, however, it will hopefully be enough so that you aren't low hanging fruit. We are in no way responsible for your security, and by using this guide, you agree not to hold us liable for your security.
Table of Contents
Choosing a Server Location
Choosing the right home for your server is an important consideration, and different locations have divergent risks and benefits.
Benefits of Home Servers
- Physical control over access to the server. This is an important security consideration.
- Price - you don't have to pay a monthly fee, although you may have an upfront cost for hardware.
- Freedom to install whatever operating system you want.
Drawbacks of Home Servers
- Dynamic IP address. It is challenging for the outside world to connect to a server, if the server's address is always changing. This limitation can be overcome by using a remote VPN server or a remote gateway that forwards traffic to your home server. Also, the dynamic IP address you were just assigned could have belonged to anyone, and thus could be a target for malicious activity. Some ISPs allocate static IP addresses, often for an additional fee.
- Slower connection, particularly upstream.
Benefits of Professional Hosting Companies
- Professional hosting companies provide users with high speed connections and static IP addresses.
- Increased uptime and server availability.
Drawbacks of Professional Hosting Companies
- Some hosting companies limit what operating systems a user can install, and some may limit users from using whole disk encryption.
- Users don't know who has access to their server.
- Virtual private servers (VPS) can dynamically allocate resources. The memory your server was just using could be assigned to a different person, which could result in a memory leak.
Secure passwords are important, however, few users take the time to use strong passwords that are stored in an encrypted file or drive. Tools such as the Only Key by Crypto Trust can be useful for password management. To generate a secure password in linux, you can use apg (Automatic Password Generator) by typing the following command into a terminal prompt:
apg -s -m 30 -n 1 -M CLN
In the above code snippet:
- "apg" calls the program.
- The "-s" option prompts the user for keyboard input, which is used as a seed to generate the password.
- The "-m 30" tells the program that the password must be a minimum of 30 characters long. You can change this number to suit your needs. Secure passwords should be a minimum of 14 characters long.
- The "-n 1" specifies that we only want one password to be generated.
- "-M CLN" indicates that the password must include capital letters (C), lowercase letters (L), and numbers (N).
Whole disk encryption is an important security measure, as it protects your data that is at rest (i.e., not moving through a network) from being accessed or modified. Enable disk encryption when you are installing the operating system. Note that disk encryption will not protect your server from someone modifying the processes that are responsible for booting your server.
- On the "Installation Destination" screen, check the "Encrypt my data" box.
- Click "Done".
- Enter and verify your password when prompted. Remember your password, as you won't be able to start your computer or access your data without it.
- Every time your computer boots, you will need to access a serial console, usually in your hosting provider's dashboard, so that you can type your password. ssh will not work until you have unlocked your disks.
Note: After installing the operating system, you will likely need to eject the installation disk (iso) image so you can boot from the new install. The steps for this vary by hosting provider.
On *nix systems, the root user has complete access to every file or process on a given system. Anyone with root access has complete control of the system. Sometimes root access is needed to change files or settings, or even to browse some directories. Instead of logging in as the 'root' user, consider disabling the root account entirely, as the 'sudo' command can be used to complete a task as though you were root. For example, if you need to restart the ssh process you could use:
sudo systemctl restart sshd
This will allow you to execute the systemctl command as though you were a root user. If you are engaging in several tasks that require root access, simply enter:
This will allow you to execute commands as though you were root, without prefacing them with sudo. For example, if you had entered "sudo -i", you could run:
systemctl restart sshd
And the command would be run as though you were root, even though you didn't preface it with "sudo".
In this guide, I preface commands that must be run as an administrator with "sudo". If you used "sudo -i", than omit the word "sudo" when running these commands.
Don't forget to update your server regularly by running:
sudo yum upgrade
You may need to restart your server to fully apply updates. Always restart after updating the Linux kernel.
Installing some additional software can make your life much easier. I prefer to use nano for my text editor, rsync through ssh to transfer files, and tmux to manage terminal windows. I also typically install the epel-release repository, which provides access to additional software packages. The examples in this guide use nano, however, you are free to use whatever text editor you prefer (e.g., nano, vi, etc.).
You can install them by running:
sudo yum install rsync wget tmux curl epel-release
I like to use htop to monitor performance. htop is included in the epel-release repository. After you have installed "epel-release":
sudo yum upgrade sudo yum install htop
I prefer vim to nano, and I customize vim using the "~/.vim" file. A sample vim configuration file is available in my git. If you want to use my configuration file, run:
wget -O ~/.vimrc https://raw.githubusercontent.com/crypticrabbit/server_configs/master/.vimrc
wget -O ~/.tmux.conf https://raw.githubusercontent.com/crypticrabbit/server_configs/master/.tmux.conf
This command will fetch my .vimrc file from my git and will automatically save it to the home directory associated with the user that you logged in as. You can use "~/" as a shortcut for the full "/home/username/" file path to your home directory.
- wget is a software package that fetches files using HTTP.
- "-O ~/.vimrc" tells wget to save the file in your home directory (~/) as ".vimrc".
- "https://raw.githubusercontent.com..." is the URL where my .vimrc file is hosted.
You can download a template with some default rules for IP tables here:
wget -O ~/iptables.sh https://raw.githubusercontent.com/crypticrabbit/server_configs/master/iptables.sh
After downloading the iptables, make sure to change variables to match your server. If you don't know your server's IP addresses and interface names, run:
Once you know your interface names and IP addresses, edit the variables at the top of the iptables.sh file:
When you are ready, initialize your IPtables rules:
sudo bash ~/iptables.sh
If you don't see any error messages, your rules were successfully initialized. You could build on the basic rules in the iptables.sh template by adding advanced features, such as port knocking and logging.
If you are installing rippled on a computer that you have physical access too (for example, a desktop computer in your living room), they you probably won't use SSH to interact with the computer, since you can just plug in a monitor, keyboard, and mouse.
SSH (Secure SHell) is an application for interacting with a remote computer. By default, ssh listens for TCP packets sent to port 22. The most secure way to access ssh is using public/private ssh key pairs. Keys are saved in a user's ".ssh" directory. To generate a new keypair:
ssh-keygen -t rsa -b 4096 -C "email@example.com"
This will generate two 4096 bit RSA keys. The key that ends in ".pub" is public, and can be shared with anyone. Do not share your private key with anyone. Also, ensure you backup your keys to a secure location, like an encrypted USB drive. You will need to copy your public key file to "~/.ssh/authorized_keys" on your server, so that ssh can verify your identity when you login using your private key.
Sending Your Public Key To A Server
If you need to transfer your public key from your personal computer to your server, you can use:
rsync -vz -e ssh ~/.ssh/id_rsa.pub firstname.lastname@example.org:/home/username/.ssh/authorized_keys
This command will overwrite the "authorized_keys" file on your server.
- rsync is a program for copying files from one computer to another.
- "-vz" tells rsync to use verbose ("v") mode, which outputs additional text/warnings and to also use compression ("z").
- "-e ssh" tells rsync that you want to use ssh to connect to the remote server. Without ssh, rsync sends data to the server unencrypted, which means anyone could intercept it.
- "~/.ssh/id_rsa.pub" is the path to your public ssh key on your local computer. You may need to change this.
- "username@server...:/home/username/.ssh/" is the path to your "authorized_keys" file on the remote server. Change "username" to your username on the remote machine, and change "ip.add.ress" to the remoter server's ip address. Change "username" in the "/home/username/.ssh/..." file address to your username on the remote server.
Logging in Using Your Public Key
Login to your remote server using your ssh key:
ssh -i ~/.ssh/id_rsa username@serveraddress
Replace "id_rsa" with your private key file, change "username" to your username on the server you are trying to access, and change "serveraddress" to the server's IP address.
If you are using linux on your local computer (e.g., laptop), you can use ssh-add to store the password that is used to decrypt your private ssh key:
Change "~/.ssh/id_rsa" to point to your private ssh key. When prompted, you will have to enter the password to decrypt your key.
If you are asked for a password, something went wrong. Check that your "~/.ssh/authorized_keys" file is in the home directory associated with your username, and that you have set appropriate ownership and file permissions. If you continue to have issues, you may need to check the SELinux policy associated with the file. If you suspect a problem with ownership, permissions, or SELinux, you can run these commands:
chown -R username:username /home/username/.ssh
chmod 700 /home/username/.ssh && chmod 644 /home/username/.ssh/authorized_keys
restorecon -R /home/username/.ssh
Make sure to replace "username" in the above commands with your username.
- chown is used to change the ownership of a file. The -R option is used to change ownership recursively, so that it is changed for all of the files inside the ".ssh" directory.
- chmod is used to change permissions. The "700" tells chmod that the owner of the "~/.ssh" directory (your username) should be able to read, write,and execute (display the contents of) the ".ssh" directory, while members of your user's group and the public should not be able to read, write, or execute the directory or file. The "&&" in the command tells the server to only execute the second command if the first completes successfully. "644" in the second command sets the "authorized_keys" file's permissions so that it can be read and written to by the owner (your username) and read by your username's group as well as the public.
- restorecon is used to reset the SELinux security context of a given file or directory. Again, the -R option is used, so that it restores the context for both the ".ssh" directory as well as the files contained in the directory.
Strengthening SSH Security
You can strengthen the default ssh security by using a text editor to modify the configuration file:
sudo nano /etc/ssh/sshd_config
Ensure the following parameters are set in your configuration file:PasswordAuthentication no
- "PasswordAuthentication no" prohibits users from using passwords to login to ssh. Users should use ssh keys rather than passwords.
- "PermitRootLogin no" bars anyone from logging in through ssh as the root user. Use "sudo -i" instead of logging in as root.
- "AllowUsers rabbit" specifies the usernames who are allowed to login to the server. Change "rabbit" to your username.
- "Protocol 2" specifies that the second version of the ssh protocol should be used. Version 1 is not secure. Only use version 2.
- "ListenAddress" tells ssh which ip address(es) to listen on. I run VPNs on all of my servers, and I prefer ssh to only listen for connections coming through my VPN. You can specify multiple IPv4 and IPv6 addresses.
- "IgnoreRhosts yes" ignores insecure rhosts files.
- "ChallengeResponseAuthentication no" and "GSSAPIAutentication no" disables challenge response and GSSAPI authentication.
- Secure servers do not have a graphic user interface (GUI) installed, so you can set "X11Forwarding no", since there is no display to forward.
After you modify the ssh configuration file, restart the sshd service, so your changes take effect:
sudo systemctl restart sshd
Copying Files To & From Servers
Only use rsync through SSH
rsync -vzd -e ssh ~/file.to.copy email@example.com:/home/username/
- Add info on --delete
- Add info on file/ownership permissions
Additional Software = Larger Attack Vector
- Don't run anything on your rippled nodes that isn't necessary.
- Consider using a minimal or headless (no GUI) operating system install.