AlexJ's Computer Science Journal

VPS Security

I recently decided to migrate this site from an older server to a VPS. I went with IntoVPS because I got some positive feedback from people I know and use their services. Although I am a big user of Ubuntu Server(LTS), I went with a CentOS install. My first Linux interactions were with RedHat based distributions but for the last 8 years I have been almost exclusively using Debian based distributions. So I decided to remember how the Red Hat world looked and changed scenery.

I got the server last week but haven’t had time to do anything with it. I turned it on, ran a ‘uname -a’ to see what I was dealing with and left it alone. When I came back and logged into ssh, the login banner said I had about 20 000 failed ssh login attempts in less than a week. Time to add some security. And, since I am doing that, I thought I should also document some security practices that I think are important for a system.

To start of, simple user and password tips. The install came with a root account to use and a random generated password. Never ever ever EVER use the root account unless you really REALLY have to. So I added my own user, and gave it administrative access via sudo. Of course, it’s important to have a good password. And my opinion is that it’s more important to have a password with a bigger length than a complicated one. I try to have both a decent length and different character types. But having an user with sudo access is useless if the root password is still there. So, next step is to remove the root password.

Be very careful not to lock yourself out when doing this. Verify that you have another way to get access to the root account before removing the password (sudo su access or ssh login via private key). Also, remember that a blank password is not the same as no password. What you want is the latter and you can use:

passwd -d root

Next: SSH. Since this is a VPS, SSH is a vital service (though I am a fan of WebUIs, like gmail, I wouldn’t go for a web interface to administer a server… CLI is all I need). A good practice is to remove the possibility to login as root over ssh. You do that by editing /etc/ssh/sshd_config and adding to it:

PermitRootLogin no

There are some other things you can change in the config, like the timeouts and max failed attempts. Don’t forget to restart the daemon:

service ssh restart

Another idea would be to change the (TCP) port that the sshd is listening on. Why bother? Well, even though you configured a good password against bruteforce, these attacks might still cause you harm. Because even if someone tries a password and fails, they still managed to connect to the SSH process. It opens a TCP connection and consumes CPU and memory to verify the credentials.

So what you can do is stop an attack lower in the TCP stack, at the Transport Layer. You can change from the default port of 22 to another port (for example 8022). Since most bruteforce bots will try only port 22, they will fail because that port is not open on your server. Bad news for the hacker, good news for your server.

Just remember that when you are configuring the ssh daemon, you are probably ON the ssh connection. Be sure you don’t close the connection without having a way of getting back in. And make sure that you understand what changing the port means. 22 is the default port so you don’t have to specify it when trying to connect via ssh. But when you change it, whenever you connect via ssh or scp, you need to manually type in the port (and DON’T FORGET what you set the value to). And also remember that some firewalls may block strange ports so might be on a network that only allows standard connections like 80, 443, 21, 22, 25, 53. Be sure that when you make a decision, you make an informed decision.

Still paranoid about attacks? Good! Another good protection is to install a tool like fail2ban. It detects brute force attacks and tries to block them in your firewall. It takes information from logs, detects malicious activity and adds rules in iptables and hosts.deny. Just install it and watch it do its job.

Now for the extra paranoid section: service versions. Some attacks are based on vulnerabilities found in certain software versions. Keep your software packages up to date because older packages are always more vulnerable. But you can also reduce risks by hiding some public information like the version.

In Apache, for example, the server, by default sends version information. You can edit the configuration file (/etc/apache2/apache2.conf or /etc/httpd/httpd.conf) and add (or set) the following directives:

ServerTokens ProductOnly

ServerSignature Off

And remember that some services need to be accessible from outside (like the httpd) but some don’t. For example, if you need a mysql server that is only required by local services (like Apache) don’t make it accessible to the outside. Bind the process only to loopback ( and/or ::1) and not to IPs of uplink interfaces. Use netstat to check this:

netstat -ntlup




AlphaOmega Captcha Classica  –  Enter Security Code