Permitting remote access to your dedicated server or VPS
Here at Anchor we believe in a security philosophy called defence in depth, which means using multiple overlapping layers of security. This is done to help ensure that no single security breach in a system will result in a compromise.
This means that when you wish to provide access to your server there are a couple of steps involved.
Note that if you have an unmanaged (Monitor) server from Anchor, the framework we describe here won't have been setup, leaving you free to implement things however you wish.
The first access restrictions you may come up against are firewall-based controls. These will typically be in place if a specific service (such as SSH, FTP or remote desktop) is only ever going to be accessed by a mostly-static set of users. These restrictions are set up for a specific IP address (or a block of IP addresses) to prevent unknown hosts from attempting to connect to the service.
This is nowhere near sufficient on its own, but it goes a long way to reducing your exposed "attack surface", shrugging off indiscriminate would-be attackers that make up the vast majority of unauthorised access attempts on servers.
If you have an unmanaged (Monitor) server then you are able to manage the firewall yourself. For Linux servers we recommend the use of Filtergen to manage your iptables ruleset, or you can use iptables directly if you're keen. For Windows servers you'll be using the built-in Windows Firewall.
The next restrictions that we implement are part of PAM (Pluggable Authentication Modules), which comes with most, if not all Linux distributions. We've discussed the mechanisms in greater depth in a separate article if you're interested, but on a managed Anchor server you only need to know about two files for controlling access on a per-user basis:
/etc/security/ssh_users for SSH access
/etc/security/ftp_users for FTP access
We're using what's called the pam_access module, you can read the system's manpages for more details if needed. The format of these files is simple and takes the following format:
To allow access:
To deny access:
The best way to understand this is with an example:
+:testguy:ALL +:testgirl:192.168.0.100 +:test:example-host.com.au -:ALL:ALL
In this example above the respective lines will cause the following behaviour:
Line 1: Permit the user testguy to log in from anywhere
Line 2: Permit the user testgirl to log in from the IP address 192.168.0.100
Line 3: Permit the user test to log in from any IP address that reverse-resolves to example-host.com.au
- Line 4: Denies access to all other users. If you are using PAM-based restrictions you must ensure that this is the very last line in the file.
It is important to note that whilst this can restrict a user from logging on from a specific host, this is configuration is entirely separate from the firewall configuration.
Finally, you need to create an account for the user. It might sound obvious, but some admins let users share accounts! This is bad because it makes it difficult to lock people out when they should no longer have access, and destroys any sense of accountability for actions.
A separate user account means everyone has their own username and password and are have some privacy and security from each other. To create a user account on a Linux host:
Ensure that the username is unique on the machine
id USERNAMEThis should return with error such as "No such user" to indicate that the user doesn't exist, and the username is available.
Add the user account to the server, the USERNAME needs to be substituted with the user you wish to create
For SSH access:
useradd -g users USERNAME
For FTP access:
useradd -g users -s /bin/ftponly USERNAME
Set a password on the account, you should select a strong password that is unlikely to be guessed or brute-forced
To enhance the security of the server even further, SSH keys should be used in preference to standard username and password authentication, though it takes a little more work.