Assume You Are Already Under Attack
Let’s be honest: the moment your new server IP is announced on the BGP routing tables, the scanners start. It doesn’t matter if you are hosting a small blog for a bakery in Bergen or a high-traffic e-commerce platform in Oslo; automated bots do not discriminate. They are looking for default passwords, open ports, and unpatched versions of Apache.
I have seen seasoned systems administrators lose weeks of work because they left SSH on port 22 with password authentication enabled. In the Nordic hosting market, where we pride ourselves on reliability and stability, leaving a server wide open is not just negligence; it is professional suicide.
This guide isn't theoretical. These are the exact steps I take within the first 10 minutes of spinning up any new instance. Whether you are running CentOS 5.5 or the new Ubuntu 10.04 LTS, the principles remain the same: reduce the attack surface, verify every user, and trust no one.
1. The First Line of Defense: SSH Lockdown
The majority of brute-force attacks target SSH. If you are still logging in as root with a password, stop reading and fix it now. Password authentication is a relic of the past.
Step A: RSA Keys Only
Generate a 2048-bit RSA key pair on your local machine. Do not rely on simple passwords that can be cracked by a rainbow table in minutes.
ssh-keygen -t rsa -b 2048
Step B: Configure sshd_config
Edit /etc/ssh/sshd_config. We need to disable root login and enforce key-based authentication. This prevents an attacker from even attempting to guess the root password.
# /etc/ssh/sshd_config
Port 2202 <-- Security by obscurity, but it reduces log noise
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
After saving, reload the service with /etc/init.d/ssh reload. Warning: Keep your current session open while you test the new connection in a second terminal window. If you messed up, you don't want to lock yourself out.
2. iptables: The Great Wall
Many VPS providers give you a server with all ports open. This is convenient for them, but dangerous for you. We need to implement a default-drop policy. If traffic isn't explicitly allowed, it dies.
Here is a standard battle-hardened configuration for a web server:
# Flush existing rules
iptables -F
# Set default policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (critical for local services like MySQL connecting to localhost)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so the server can reply to you)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your custom port)
iptables -A INPUT -p tcp --dport 2202 -j ACCEPT
# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Remember to save these rules so they persist after a reboot. On RedHat/CentOS systems, use /etc/init.d/iptables save.
3. Automated Defense with Fail2Ban
Even with SSH on a custom port, determined bots will find you. Fail2Ban is an essential piece of software that scans log files (like /var/log/secure) for malicious patterns—too many failed password attempts, for example—and updates iptables to ban the offending IP address for a set period.
Install it via EPEL (CentOS) or Apt (Debian/Ubuntu). The default configuration is usually sufficient, but I prefer to increase the bantime to 3600 seconds. If someone tries to break into my server, they can sit in the corner for an hour.
4. The "Noisy Neighbor" Problem and Hardware Choices
Security isn't just about software; it's about isolation. In the budget hosting world, many providers use OpenVZ virtualization. While efficient, OpenVZ shares the kernel with all other tenants. If a kernel exploit is discovered, every container on that node is vulnerable. Furthermore, if a neighbor gets DDoS'd, your performance tanks.
This is where architecture matters. At CoolVDS, we prioritize full virtualization technologies like Xen and KVM. This ensures that your memory and CPU are strictly allocated to you. It also means you can run your own custom kernel if you need specific security patches that the host hasn't applied yet.
Pro Tip: When choosing a VPS in Norway, ask about the storage backend. We are seeing a massive shift in 2010 toward RAID-10 SAS and early enterprise SSD adoption. High I/O wait times can look like a DDoS attack when it's actually just a neighbor running a massive backup. CoolVDS isolates I/O specifically to prevent this.
5. Data Privacy and Norwegian Law
Hosting physically in Norway isn't just about low latency (though pinging NIX in Oslo at 2ms is fantastic); it's about compliance. With the Personopplysningsloven (Personal Data Act) and the vigilant eyes of Datatilsynet (The Data Inspectorate), you need to know exactly where your data sits.
US-based hosts are subject to the Patriot Act. By hosting on CoolVDS infrastructure located in Oslo, you add a layer of legal hardening to your technical hardening. Your data stays within the EEA jurisdiction, simplifying compliance with the Data Protection Directive (95/46/EC).
6. Disable Unnecessary Services
Do you need Sendmail running if you aren't sending email? Do you need RPCbind? Use netstat -tulpn to see what is listening.
chkconfig sendmail off
chkconfig rpcbind off
service sendmail stop
Every open service is a potential entry point. If you don't use it, kill it. Lean systems are secure systems.
Final Thoughts
Hardening a server is not a "set it and forget it" task. It is a discipline. You must read the logs, apply security updates via yum or apt-get weekly, and verify your backups.
However, the foundation matters. You can configure the tightest iptables in the world, but if your host oversells resources or runs on unstable hardware, your uptime is doomed regardless. Don't fight the infrastructure.
Ready to deploy on a platform that takes security as seriously as you do? Deploy a secure KVM instance on CoolVDS today and experience the stability of true resource isolation.