You can make your server more secure in 4 simple steps…

One of the most important things you’ll need to do with your server, once you gain access, is to secure it. It’s an unfortunate fact of life on the internet that it doesn’t take long for a server to be online before persons with nefarious intent are sniffing around them for holes to break-in through.

Step 1

The first thing to do is make sure that you have a secure password for your root and administrator users. Conventional wisdom says use a mix of letters, numbers, and some punctuation characters. Unfortunately, while that is sound advice to a point, it omits a vital element – the password length.  

Many people will use a password of 10 or fewer characters, the majority of remote brute force attacks will focus on the core administrator users and just cycle through common words before moving on to combinations of randomised characters meaning a short password can be cracked in a matter of days if the attacker is happy to let their script run.

Adding additional characters to the length exponentially increases the amount of time this will take, to the point that, once you get into the high teens with an easily memorable lowercase text password, it would take an attacker years to brute force, even if that person knew you’d only used lower case text. Therefore, “4Badgers@Brighton” is essentially as secure as “4HFEo@4&82#fi/P3x” and far more memorable.

Step 2

The next thing you need to do is make new users on your system. These will be the users you use to manage the system. If you are the only person using the server, your name or nickname are as good a username as any. If a group of people is going to be using it, then you probably already have a username convention that you use elsewhere. (Now see the above about secure passwords to give these new users secure passwords.) In windows give the user administrator access, and add the user to the Remote Desktop Users group, or if using Linux, add the user to sudoers. Log-out and then log-in as your newly created user and check that you do have sufficient administrator/root access. If that works, move on to the next step.

Step 3

Remove remote access from the default root/administrator accounts. In Linux this is simply done by editing the /etc/ssh/sshd_config file and setting PermitRootLogin to ‘no’. In windows, this is a more complicated process involving setting the local security policy to block logins by the administrator user group. To do this in Windows 2008 go to

Start > Administrative Tools > Local Security Policy.

Then, in there, navigate to

Security Settings > Local Policies > User Rights Assignment > Allow log on through Remote Desktop Services.

Now remove the Administrators group.

Now you’ll want to log-out and attempt to log-in with your root/administrator user, hopefully this should now fail. If so, you should now have an adequate base to preventing brute forced logins to the server.

Step 4

The next step is to configure your firewall rules for remote access. For the most part, you want to only allow access to remote access services such as RDP and SSH to IPs you know trusted users are going to use. For some users this is entirely impractical and the only option is to leave remote access open to the world. For most, though, access can be closed down. Even if it ends up being to a million of the billions of IPs available, rather than just a half dozen, it’s an improvement.

On the basis that you will probably want access from your home as well as maybe your mobile phone, but you only have a dynamic IP address, you can find out what IPs are assigned to the ISP you are using and enable access for their assigned IPs in your firewall and then block the rest of the world.  Don’t forget to also allow remote access for the support teams at the ISP who host your server, you can always contact the support team and ask what IPs they will connect from.

In addition to this, iptables firewall in Linux can be configured with anti-brute-force rules allowing you to block traffic from an IP after a user definable number of attempts in a user definable time limit.

There you have it, for the sake of a few small tasks the security of your server against common scripted brute force attacks is significantly increased.