Server Security

[justchil]

I miss having that feature with a VDS. Unfortunately you only have Windows FW on a dedi.

[jared2014]

I have used Nfoservers for hosting a few times and have many friends who use it and they have no issues with direct attacks to your machine or its security but you may have to worry about people attacking the server using RCon by using password guessing and other attacks that may bypass the servers defences (Not Nfoservers Security)

[stickz]

Alot of game-servers (source-engine in particular) have rcon exploits. You should always either disable or firewall it. Leaving this port open to the general public is a huge vulnerability, even if you have an insanely strong password like "ThisPort(27015)is110%Private!". And speaking of passwords, that is how you create a password which takes over a million years to brute force (on an industrial scale) and is easy to remember.

[mgd84]

Here are the things I normally do to initially lock things down.

Linux:
--------
1. When first logging in, go ahead and create a new user for yourself.
- "useradd -m USER" or "adduser USER"
2. Next, edit the /etc/ssh/sshd_config and disable root login. Then restart ssh to take affect.
3. And as always, close any ports you don't need via iptables.
This will prevent 90% of the issues as most of the brute force attempts are script kiddies looking for common users such as root, admin, sysadmin, etc... If you need to access root, simply "su" into it via the user you created. You can also add the user you created to the sudoers file.

Windows:
-----------
1. Change the default RDP port from 3389 to anything else.
2. And as always, close any ports you don't need open to the public.

[slait]

Also adding to mgd84's reply.

For Linux based systems, it is a great security practice to use SSH public / private key authentication, disable root login like mgd84 mentioned, and disable SSH password authentication. Authentication will only happen if the public key (hosted on the VPS) challenge-response is properly decrypted using the private key (the user has).
So basically with pub/priv key ssh auth, instead of the user sending their password to the server for authentication, the server sends an encrypted random value to the user, and the user decrypts the encrypted message from the server using the private key, and then sends a response back to the server. If the initial message (the challenge) sent from the VPS -> User matches (the response) from the User -> VPS, only then is an SSH tunnel built and access is granted.

For resources on why use SSH key authentication instead of password auth, you can check these out:

• StackExchange first answer (My response is more a less a summary of theirs):https://security.stackexchange.com/ques ... a-password

• Debian-Administration:
  https://debian-administration.org/artic ... f_password

Some more guides on setting up SSH Key Authentication

• Linux-Audit (Has some nice visuals):
  https://linux-audit.com/using-ssh-keys- ... passwords/

• Digital Ocean:
  https://www.digitalocean.com/community/ ... ecommended

Cheers!

[slait]

Also, I forgot to mention if you're super serious about security there are 2 - Factor Authentication methods available for Windows Server RDP and Linux servers.

I recommend looking at https://duo.com/.
It's free for up to 10 users before you have to select pricing options. Their documentation is well written and very accessible. The whole process is literally a few clicks for Windows servers and a few copy and paste commands for Linux. I've recently implemented duo at my work for our mission-critical servers and the usability and ease of use are just awesome.
There are other options like azure mfa, but I've tinkered around with it and it can be complicated setting up.

[Edge100x]

Re: SSH keys, when it comes to instructions, please consider posting the instructions directly instead of (or in addition) to linking to third-party sites. Having the instructions in-line means that even if the linked site goes down, deletes the content, or changes its link structure, those searching here for the information can still find answers.

SSH key generation is relatively painless. If you'd like to access a Linux server from a Windows client using a key in PuTTY, you can do it with these steps:

1. Download puttygen.exe from the PuTTY website, and run it.
2. Under "Parameters", select the "ed25519" option.
3. Click the "Generate" button and follow the instructions to generate some randomness.
4. At the top, it will show you a public key that you can paste into the authorized_keys file. Select the entire contents of this field with your mouse, then right-click and click Copy.
5. Open an SSH connection to the Linux server (host) that you wish to log into in the future and make sure that the logged-in user is the same one that you wish to use in the future.
6. Open the ~/.ssh/authorized_keys file in your favorite text editor. For instance, nano ~/.ssh/authorized_keys.
7. Paste the key from step # 4 as a new line at the end of the ~/.ssh/authorized_keys file. If the file doesn't exist, create it. If the folder doesn't exist, create it.
8. Save the changed ~/.ssh/authorized_keys file.
9. Back in puttygen.exe, click "Save private key" and enter the name "ed25519.ppk" (or your desired name). Click "Save public key" and enter a different name, such as "ed25519-public.key". puttygen.exe may ask if you are sure that you wish to save without a passphrase; click "Yes" (unless you'd rather go back and set one).
10. Close puttygen.exe.
11. Open your normal PuTTY client.
12. In the left-hand "Category:" tree, expand the "SSH" option under "Connection". Then, click "Auth".
13. Under the "Private key file for authentication:" field, click "Browse..." and select the private key that you saved earlier.
14. In the left-hand "Category:" tree, click "Session".
15. Enter your username and the hostname of the server into the "Host Name" box. For instance, "user@your.server.ip".
16. Enter a name for your new connection in the blank field under "Saved Sessions" and click "Save".

Now, whenever you open PuTTY, you can simply double-click the entry in the list for the name that you chose in the last step, and your client will log in for you.

Here's how to generate a key that you can use to access a Linux server from a Linux client:

1. Open an SSH connection on the Linux system that will be the client, and make sure that the logged-in user is the same one that you wish to use in the future.
2. Enter this command:

   Code: Select all

   ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

   When it asks for a passphrase, you can choose to enter one or leave it blank. Using a passphrase is more secure, but it adds a manual entry step during the connection phase.
3. Show the contents of the file that you just created:

   Code: Select all

   cat ~/.ssh/id_ed25519.pub

4. Open an SSH connection to the Linux server (host) that you wish to log into in the future and make sure that the logged-in user is the same one that you wish to have log in.
5. Open the ~/.ssh/authorized_keys file in your favorite text editor.
6. Copy the key from step # 3 and paste it in as a new line at the end of the ~/.ssh/authorized_keys file.
7. Save the changed ~/.ssh/authorized_keys file.

After you do this, you can log in from the client to the second server with a single line, such as "ssh user@your.server.ip" -- you won't be asked for a password (unless you chose a passphrase). This is particularly useful for automation.

After you set up your clients and server to use SSH keys, it's best to change your password on the server to something even more complex than it was before. Since the password will only be used very rarely, you don't need it to be easy to type or remember!

To take security a step further, you can make it so that your Linux server only accepts remote SSH logins that use generated keys. If you do this, you won't be able to log in with a password, but you can still log in through the VNC console on a VDS. We recommend this, but only after you've made sure that your SSH key setup is working properly.

1. Open an SSH session to your Linux server.
2. In your favorite text editor, open the /etc/ssh/sshd_config file.
3. Look for a line that starts with "#PasswordAuthentication" or "PasswordAuthentication". Change it to be this:

   Code: Select all

   PasswordAuthentication no

4. Look for a line that starts with "#ChallengeResponseAuthentication" or "ChallengeResponseAuthentication". Change it to be this:

   Code: Select all

   ChallengeResponseAuthentication no

5. Save the file.
6. Reboot your VDS, or restart/reload the OpenSSH server (each distribution has a different way of doing this; on Gentoo, for instance, the command is /etc/init.d/sshd reload).

[slait]

Re: SSH keys, when it comes to instructions, please consider posting the instructions directly instead ...

Will do, thanks.

To take security a step further, you can make it so that your Linux server only accepts remote SSH logins that use generated keys. If you do this, you won't be able to log in with a password, but you can still log in through the VNC console on a VDS. We recommend this, but only after you've made sure that your SSH key setup is working properly.

1. Open an SSH session to your Linux server.
2. In your favorite text editor, open the /etc/ssh/sshd_config file.
3. Look for a line that starts with "#ChallengeResponseAuthentication" or "ChallengeResponseAuthentication". Change it to be this (usually you will just need to remove the # at the beginning):

   Code: Select all

   ChallengeResponseAuthentication no

4. Save the file.
5. Reboot your VDS, or restart/reload the OpenSSH server (each distribution has a different way of doing this; on Gentoo, for instance, the command is /etc/init.d/sshd reload).

To add to this in the same /etc/ssh/sshd_config file:

1. Ensure that "PubkeyAuthentication" is uncommented and set to yes, i.e "PubkeyAuthentication yes"
2. Change PasswordAuthentication from yes to no. Ie "PasswordAuthentication no". If this specific setting is set to no, this is what will disable password access via SSH and only allow users to connect if they have a proper public/private key setup.
3. Save the file and for Ubuntu 16.04, in terminal window, do

   Code: Select all

   $ sudo systemctl reload ssdh

[Edge100x]

PubkeyAuthentication should be set to yes on all distributions by default, so I just assumed that one. If a user has changed it, they should know . The other two do need to be adjusted from the defaults.