Welcome to your new VPS or Dedicated Server. Please find below some default network configurations applied to your Server during the deployment process. We have also included some security tips to help you secure access to your Server.
Default network configuration
Your server is configured with at least one public, static IP address or 5, if you have a dedicated server. Please do not attempt to remove or change these IP addresses, as it will result in access to your server being lost. Should this occur, Gridhost will, unfortunately, have to bill you (on an ad hoc basis) for the staff intervention required to resolve.
Your Server is preconfigured to use a provided set of DNS resolvers. These DNS resolvers, or name servers, are only used to resolve your hostname lookups and will not be able to serve as name servers for any of your domains. Please see the IP addresses for these resolvers below:
Your server’s time should already have sensible defaults with the time zone set to GMT+2. However, if you wish to customise it, we have an Internet Time Server (NTP server) available. You can configure your NTP service with the following server details:
In order to ensure we provide you with the best uptime possible for your dedicated or VPS server, we have a monitoring system in place (monitoring ICMP requests to your server). Should you wish to block ICMP but would like us to continue monitoring your server, please add exceptions to the below IP addresses:
Here you will find some tips on keeping your server secure to prevent undesirable events from happening (Examples: loss or exposure of sensitive/ critical data or bandwidth overages.
For your Linux VPS or Dedicated Server, you would want to start with securing your SSH connection to the server and then move on to securing any applications or websites you plan on running. In the Table below you will find a list of the common usernames and passwords used in a generic SSH brute force attack.
What can you do to protect your server?
- Don't allow root login via ssh: require sudo instead.
- Don't allow passwords over ssh: Require private RSA/DSA key authentication
- If allowing passwords over ssh, don’t use obvious or common passwords
- Don't use common usernames.
- Use an allow list, and only allow users that require SSH Access.
- If you make use of a VPN or fixed-IP service, consider only allowing ssh access from those IP addresses via firewall and hosts.allow.
- Use software like fail2ban or SSHguard to catch-and-block brute force attacks.
- Make sure your OS is always up to date with the latest security patches. You can use yum-cron (CentOS) or unattended-upgrades (Ubuntu) for this.
For your application or websites, please consider the below points
- Make sure your application is always up to date, in particular security packages.
- Lock down your application 'admin' pages. Much of the advice above applies to the admin area of your application too.
- Password Protect your admin area, something like htpasswd for web console will protect any underlying application vulnerabilities and create an extra barrier to entry.
- Lock down file permissions. 'Upload folders' are notorious for being entry points for hackers.
|Number of Attempts and the Username||Number of Attempts and the password|
| 365 123456|