Security on a Classic mode server

The security of your Gandi Cloud VPS server is your responsibility.

This page is intended to describe various ways in which you can access your newly-created Classic mode server and its default listening services, as well as to provide some advice for implementing a few basic security measures.

A newly-created server

SSH access is enabled by default for the user and password you configured when creating the server. This user can obtain root permissions by running the command:

su -

Because the user's password is the same as the root password by default, it would be prudent to change them using the passwd command.

Best practices

SSH: Key-based authentication

Instead of using a password when connecting via SSH, you can create a public/private key pair that will allow you to connect from your local machine without being prompted for a password. The advantage of this approach is that you do not need to remember a password to connect, and the key exchange is quite secure, as long as the key pair remains secure. The disadvantage is that every computer that connects in this way will need the key pair installed.

To create the keys, run the following command on your local machine:

  ssh-keygen -t rsa -b 2048 

Then, copy the public key to your remote server (where your_server_ip is the IP address of your VPS):

 scp .ssh/id_rsa.pub user@your_server_ip:~/.ssh/authorized_keys 

If the ~/.ssh/ directory doesn't already exist on the VPS, you'll need to create it before uploading the public key.

Now, when you connect via SSH (ssh username@your_server_ip) you will no longer be asked to provide your password.

For more information on pubkey auth, see Connecting to your Classic mode server via SSH.

SSH: The Gandi key

An SSH key is included on Classic mode servers to allow access to our hosting team if authorization is provided and if the urgency or complexity of the problem precludes resolution by all other means.

If desired, you can deactivate it in the file /etc/default/gandi.

SSH: Listening on another port, or port-knocking

This technique allows you to reduce the effectiveness of brute-force attacks by setting SSH to listen for connection attempts only after you've activated it by “knocking” on another port first.

More information available at Wikipedia.

Security tools (Firewall, IDS...)

You should close any open ports that you are not using on public interfaces. Several tools based on iptables (Netfilter/Linux firewall rules) can be used to do this, and so increase the security of your server, as well as inform you of fraudulent connection attempts. Note that iptables can be managed directly from the command line.

  • Firewalls: Shorewall, Ufw, Arno-iptables-firewall, Dtc…
  • Systems to reduce the effectiveness of brute-force attacks: fail2ban…

None of these programs take IPv4 and IPv6 into account on the same interface. To secure IPv6, an IPv6-specific firewall is in order (Shorwall6, for example).

On Unix/BSD systems, Packet Filter (PF) is the standard firewall.

You must accept icmp echo (ping) requests in order for the IPv6 protocol to function on your virtual private server.

Alerts/reporting tools

  • Logwatch/logcheck: Daily report delivered by email - parsing of server logs
  • Rkhunter/Chkrootkit: System rootkit checker
  • Ninja/Tiger: Reporting system (watches permissions and changes to system files)
  • Debsecan: Reporting on known failures of packages installed on the server

Activation of SELinux on CentOS (6.0 and higher)

You can use SELinux to inhibit the unauthorized installation and reconfiguration of software on your server, and enhance the enforcement of access control policies. This is an important step in hardening your systems.

The activation of SELinux on CentOS 6.x has been tested by our teams on the 2.6.32 and 3.2 kernels.

You must first activate SELinux in the advanced disk configuration, accessible from the Kernel section of the disk's management page in your Gandi account.

Under the “Boot line options selection” heading, make the following selections:

  • “Enable SELinux at boot time”: Checked
  • “Security framework”: selinux

Click “Change” to save the disk configuration. Note that the server has to be rebooted for the changes to take effect.

You can verify if it worked by executing this command on your server as root:

 # cat /proc/cmdline
  console=hvc0 nosep loglevel=8 selinux=1 security=selinux ro root=/dev/xvda1
 

Next, add the following lines in the file /etc/fstab:

  none    /selinux    selinuxfs    defaults    0  0

Finally, install the following packages:

  • libselinux
  • selinux-policy
  • selinux-policy-<type> (where <type> is minimum, targeted…)

SELinux should now be active.

If you reboot your server, you will need to take additional steps.

It will be necessary to use semodule to manage SELinux policy modules on the server, for example:

  # packages="execmem.pp.bz2 unconfined.pp.bz2 unconfineduser.pp.bz2"
  # semodule -n -r oracle-port -b base.pp.bz2 -i $packages -s \
       targeted 2>&1 | grep -v "oracle-port"

The list of available packages can be found in the file /usr/share/selinux/<type>/*.pp.bz2.

You can also load additional policies with the load_policy command.

If necessary, you can make fixes with fixfiles. You can verify the status of SELinux with the sestatus command.

You can get more information in selinux-policy-<type> package scripts, readable with the command rpm -q -scripts, for example: rpm -q –scriptps selinux-policy-minimum.

Last modified: 05/27/2015 at 12:36 by Alexandre L. (Gandi)