The internet is not a friendly neighborhood. It's a war zone.

If you spin up a fresh CentOS 5 or Debian Lenny server today and tail your /var/log/secure, you will see it: the relentless stream of brute-force attempts. It doesn't matter if your server is hosted here in Oslo or halfway across the world. The bots don't sleep.

I recently deployed a database node for a client connecting to NIX (Norwegian Internet Exchange). Within 14 minutes of the interface going up—before we even pointed a domain at it—we had 400 failed login attempts from IPs in Eastern Europe and China. If you are running default settings, it is not a question of if you get compromised, but when.

At CoolVDS, we ensure the hardware layer is rock solid with enterprise-grade SAS RAID arrays and redundant power, but once we hand you that root password, the OS is your kingdom. And your responsibility. Here is how to lock it down before you deploy into production.

1. The SSH Lockdown

SSH is the front door. You do not leave the front door open. Open up /etc/ssh/sshd_config and make these changes immediately.

First, disable the root login. You should be logging in as a standard user and elevating to root via su - or sudo. This adds a necessary layer of friction for an attacker.

# /etc/ssh/sshd_config
PermitRootLogin no
Protocol 2
UseDNS no

Pro Tip: Make sure you create your user account and test the login in a second terminal window before you restart SSH. I have seen too many sysadmins lock themselves out of a remote box and have to beg for KVM console access.

Ideally, disable password authentication entirely and stick to RSA keys. Passwords can be brute-forced; a 2048-bit RSA key cannot.

2. Iptables: The Great Wall

Many VPS providers give you a blank slate. That means all ports are open. You need to configure iptables to drop everything by default and only whitelisting what you need.

Forget complex GUI firewalls. Learn the raw commands. They save your life when the GUI breaks.

# Flush existing rules
iptables -F

# Allow loopback (critical for local services)
iptables -A INPUT -i lo -j ACCEPT

# Keep current connections alive
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (If you moved ports, change 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# DROP everything else
iptables -P INPUT DROP
iptables -P FORWARD DROP

Save these rules. On RedHat/CentOS systems:
/sbin/service iptables save

Why CoolVDS? Some budget VPS providers use older OpenVZ kernels that restrict your ability to load specific iptables modules (like connection tracking). CoolVDS uses KVM and Xen virtualization, giving you a full kernel. If you need advanced stateful packet inspection, you can actually run it here.

3. Banish the Brute Force with Fail2Ban

Even with strong passwords, a flood of login attempts eats up CPU cycles and fills your logs. Fail2Ban is mandatory. It scans log files for malicious behavior (too many password failures) and updates your iptables rules to ban the offending IP for a set time.

Install it from the EPEL repo on CentOS or apt on Debian. The default config is usually located in /etc/fail2ban/jail.conf.

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/secure
maxretry = 3
bantime  = 3600

This simple config bans an IP for an hour after 3 failed attempts. It keeps the log noise down and the script kiddies out.

4. Minimal Services, Maximum Speed

Every running service is a potential vulnerability. If you are building a web server, you do not need X11, CUPS (printing), or Sendmail listening on public interfaces.

Run netstat -tulpn to see what is listening. If you don't need it, kill it.

chkconfig sendmail off
chkconfig bluetooth off (Yes, some distros install this by default!)

This is where the "Pragmatic CTO" mindset comes in. Fewer services mean less RAM usage, which is critical on a VPS, but more importantly, it means a smaller attack surface. This is vital for compliance with the Norwegian Personal Data Act (Personopplysningsloven). You cannot claim you are protecting user data if you are running an unpatched FTP server you forgot about.

5. Keep it Local, Keep it Fast

Latency matters. If your customers are in Norway, hosting in the US or Germany adds unnecessary milliseconds. But beyond speed, there is data sovereignty. Under current EU Data Protection Directives (95/46/EC), keeping data within the EEA is crucial, but keeping it physically in Norway satisfies the strictest interpretations of Datatilsynet.

CoolVDS infrastructure is physically located in Oslo data centers. We peer directly with major Norwegian ISPs. When you harden your server here, you aren't just securing ports; you are securing low-latency access for your Nordic user base.

Final Thoughts

Security is not a product; it is a process. Run yum update regularly. Watch your logs. Don't trust defaults.

Ready to deploy a secure stack? Don't settle for oversold hosting. Spin up a CoolVDS instance today—where you get the raw performance of dedicated resources with the flexibility of virtualization.