The Default Install is a Liability
Let’s be honest: a fresh installation of CentOS 5.5 or Ubuntu 10.04 LTS is not ready for the public internet. It is a soft target. I have seen perfectly good servers compromised in less than 15 minutes after the network interface went up. Script kiddies and automated botnets don't care about your business logic; they care about your open port 22.
If you are managing infrastructure for a Norwegian enterprise, the stakes are even higher. We aren't just talking about uptime; we are talking about compliance with the Personopplysningsloven (Personal Data Act) and the scrutiny of Datatilsynet. You cannot afford a breach.
This guide isn't theoretical. It’s the baseline configuration we expect on any serious deployment, whether you are running a dedicated rig or a high-performance slice on CoolVDS.
1. Secure the Door: SSH Hardening
The first thing an attacker targets is SSH. If you are still logging in as root with a password, you have already failed. Brute-force attacks are constant, and a strong password is just a delay tactic, not a solution.
Switch to Key-Based Authentication
Passwords can be guessed; 2048-bit RSA keys cannot. Generate your key pair locally and push it to the server. Once you verify you can log in without a password, kill the password authentication method entirely.
Edit your /etc/ssh/sshd_config:
Port 4422
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers adminuserPro Tip: Moving SSH off port 22 (to something like 4422) is not "security," it is "obscurity." However, it keeps your logs clean from thousands of automated Chinese and Russian bot attempts, which saves CPU cycles and disk I/O. Just do it.
After saving, restart the service: service ssh restart (or service sshd restart on CentOS).
2. The Firewall: Learning to Love iptables
Many sysadmins are afraid of iptables because the syntax is unforgiving. If you type the wrong command, you lock yourself out. That is why we access our CoolVDS instances via KVM VNC console for these changes, just in case.
You need a "Default Deny" policy. Traffic should be explicitly allowed; everything else must drop. Here is a battle-tested configuration for a standard web server:
# Flush existing rules
iptables -F
# Allow loopback (critical for local services like MySQL)
iptables -A INPUT -i lo -j ALLOW
# Allow established connections (so you don't cut yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your custom port)
iptables -A INPUT -p tcp --dport 4422 -j ACCEPT
# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Drop everything else
iptables -P INPUT DROP
iptables -P FORWARD DROPSave these rules. On Red Hat/CentOS systems, run service iptables save. On Debian systems, use iptables-save > /etc/iptables.rules and load it in your network interface config.
3. The Watchdog: Fail2Ban
Even with a firewall, your open ports are vulnerable to application-level abuse. Fail2Ban is mandatory software in 2011. It scans log files (like /var/log/secure or /var/log/apache2/error.log) and bans IPs that show malicious signs—too many password failures, seeking exploits, etc.
Install it via EPEL (CentOS) or Apt (Ubuntu/Debian). Configure /etc/fail2ban/jail.local to ban repeat offenders for at least an hour. This keeps the noise down and prevents brute-force scripts from hammering your application login forms.
4. The Norwegian Context: Data Sovereignty and Latency
Why do we stress hardening so much? Because in Norway, data responsibility is codified. Under the Personal Data Act of 2000, you are responsible for securing user data. If you host sensitive data on a budget US host, and that host is compromised (or subject to the Patriot Act), you are in a legal gray area.
Hosting locally isn't just about law; it's about physics. Hosting in Oslo means your latency to Norwegian users is 2-5ms. Hosting in Frankfurt or Amsterdam pushes that to 20-30ms. For high-frequency trading or database-heavy applications, that difference is noticeable.
At CoolVDS, we utilize enterprise-grade RAID10 SAS storage and true hardware virtualization (KVM). Unlike OpenVZ "containers" used by budget providers where a neighbor's DDoS attack kills your performance, our isolation ensures that your security hardening efforts aren't wasted by a noisy neighbor.
Conclusion
Security is not a product; it is a process. You harden the OS today, but you must patch it tomorrow. Run yum update regularly. Watch your logs.
If you need a platform that respects these principles—raw performance, strict isolation, and low latency to the Nordic market—you know where to look. Deploy a secure baseline on a CoolVDS instance and stop worrying about your infrastructure.