Difference between revisions of "Unmanaged Server Security"

From XMission Wiki
Jump to: navigation, search
(2. SSH Keys)
(2. SSH Keys)
Line 14: Line 14:
 
* SSH keys allow users to SSH to servers with a more secure method rather than having to rely on passwords alone. Passwords can be brute forced, given out, or stolen. SSH keys allow users to store a private key on their local machine, and a public key on their Cloud Server letting them SSH to their Cloud Server without the need for passwords. A SSH key pair consists of a public key and a private key. You can upload your public key on any server, but should keep your private key stored in a protected place preferably with a passphrase.
 
* SSH keys allow users to SSH to servers with a more secure method rather than having to rely on passwords alone. Passwords can be brute forced, given out, or stolen. SSH keys allow users to store a private key on their local machine, and a public key on their Cloud Server letting them SSH to their Cloud Server without the need for passwords. A SSH key pair consists of a public key and a private key. You can upload your public key on any server, but should keep your private key stored in a protected place preferably with a passphrase.
 
* By using SSH keys you can SSH to your server as a user with their SSH key already uploaded to your servers '''authorized_keys''' without a password. If you keep your '''private''' key stored in a secure place, this can immensely help with keeping your server locked down to the outside world.  
 
* By using SSH keys you can SSH to your server as a user with their SSH key already uploaded to your servers '''authorized_keys''' without a password. If you keep your '''private''' key stored in a secure place, this can immensely help with keeping your server locked down to the outside world.  
* Passwords over SSH can easily be broken because users tend to make easy to remember passwords, rather than strong passwords. This makes it easier for bots to brute force your users password.  
+
* Passwords over SSH can easily be brute forced because users tend to make easy to remember passwords, rather than strong passwords. This makes it easier for bots to brute force your users password.  
 
For more information please see [[SSH_Keys| SSH Keys]]
 
For more information please see [[SSH_Keys| SSH Keys]]
  

Revision as of 18:42, 15 November 2016

Recommended Practices

Keeping your server up-to-date is incredibly important in an ever evolving world due to the Internet of Things. XMission strongly recommends a few easy steps to take to ensure that your unmanaged Cloud Server stays up-to-date and secure at all times.

1. Disable Root SSH

  • We recommend creating a group of sudo users that have root abilities, but disabling the ability to ssh to your server using the "root" user.

Example:

ssh root@xxx.xxx.xxx.xxx
  • Instead you should only allow existing users to be able to ssh. Ideally with SSH keys.
ssh dobbs@xxx.xxx.xxx.xxx
  • Why we recommend that you disable root ssh, is because the primary attack against server comes from bots. They will attempt to connect to an IP address as root, since the name "root" is globally the same on almost all devices and servers. Instead, the bots will have to attempt or know your username. This will take many attempts, and can be prevented by using Fail2Ban and iptables.

2. SSH Keys

  • SSH keys allow users to SSH to servers with a more secure method rather than having to rely on passwords alone. Passwords can be brute forced, given out, or stolen. SSH keys allow users to store a private key on their local machine, and a public key on their Cloud Server letting them SSH to their Cloud Server without the need for passwords. A SSH key pair consists of a public key and a private key. You can upload your public key on any server, but should keep your private key stored in a protected place preferably with a passphrase.
  • By using SSH keys you can SSH to your server as a user with their SSH key already uploaded to your servers authorized_keys without a password. If you keep your private key stored in a secure place, this can immensely help with keeping your server locked down to the outside world.
  • Passwords over SSH can easily be brute forced because users tend to make easy to remember passwords, rather than strong passwords. This makes it easier for bots to brute force your users password.

For more information please see SSH Keys

3. Fail2Ban

  • Like the previously mentioned disabling of root ssh, we want to limit the vectors for assailants to brute force usernames and/or passwords. By using a service named "Fail2Ban" we can mitigate their ability to repeatedly guess your servers usernames and passwords. By temporarily blocking the offending IP address from connecting to your server for a designated amount of time, or just flat outright.

4. iptables

  • Simply put, iptables will be your servers firewall. It will allow or block traffic from IP address, ports and protocols.
  • If there is an offending IP address repeatedly attacking your server through a brute force attempt, iptables will block that connection from being established.
  • You can block entire ports outright from being used for traffic in and traffic out. Perhaps to block FTP and require users to use SFTP instead.

5. Automatic Security Updates

  • Lastly we recommend that you keep your Ubuntu Cloud Server up-to-date by using a very simply solution named "AutomaticSecurityUpdates". This will help reduce your exposure to day 1-x vulnerabilities that have since been patched.
  • Ubunutu forums has a great resource on how you can achieve this. We recommend you check it out at: https://help.ubuntu.com/community/AutomaticSecurityUpdates