Stop Trusting Default Configs: A Guide to Survival
Let’s be honest. If you just deployed a fresh CentOS 5 or Debian Lenny box and left it running with the default settings, you are asking for trouble. Automated scanners are hitting port 22 before the kernel has even finished booting. I've seen production servers compromised in less than 24 hours because an admin thought "root/password123" was a temporary placeholder.
Security isn't a product you buy; it's a process you suffer through. In the Nordic hosting market, where reliability is everything, a compromised box doesn't just hurt your uptime—it puts you on the wrong side of the Data Inspectorate (Datatilsynet). Here is how we lock things down at the infrastructure level, and how you should configure your user space.
1. The SSH Fortress: Keys Only, No Root
Password authentication is dead. Brute force attacks are getting smarter, and rainbow tables are getting larger. If you are still typing a password to log into SSH, you are doing it wrong.
First, generate a 2048-bit RSA key pair on your local machine. Once the public key is on the server, edit your daemon config immediately.
Open /etc/ssh/sshd_config and change these lines:
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Disabling DNS lookups (UseDNS no) also speeds up login times significantly—vital when you need to jump in to fix a load spike. Restart SSH and pray you didn't lock yourself out.
2. Iptables: The First Line of Defense
Forget the GUI tools. If you can't read a raw iptables chain, you don't know what traffic is entering your network. A default policy should always be DROP. If you aren't explicitly allowing it, it shouldn't get in.
Here is a battle-tested snippet for a standard web server:
# Flush existing rules
iptables -F
# Default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (keep your SSH session alive!)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH, HTTP, HTTPS
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Save this to /etc/sysconfig/iptables on RHEL/CentOS systems. Without this, your VPS Norway instance is naked on the internet.
3. Ban the Bots with Fail2Ban
Even with keys, your logs will fill up with failed login attempts from compromised boxes in botnets. Install Fail2Ban (currently version 0.8.4 is stable). It parses your logs (/var/log/secure or /var/log/auth.log) and dynamically updates iptables to ban IPs that fail too many times.
Pro Tip: Don't just watch SSH. Configure Fail2Ban to monitor your Apache logs for script kiddies trying to probe for phpMyAdmin or vulnerable WordPress plugins. It saves CPU cycles by dropping them at the firewall level.
4. Physical Isolation and Architecture
Software hardening only goes so far if the underlying host is weak. This is where the choice of virtualization matters. Many budget providers stuff hundreds of containers onto a single host using OpenVZ. If one neighbor gets DDoS'd, you feel it.
At CoolVDS, we lean heavily towards hardware virtualization (Xen/KVM). This provides better isolation. A kernel panic in your neighbor's VM won't take down your database. Plus, for high-performance databases, we are rolling out Solid State Drives (SSD) in our Oslo nodes. The I/O difference between spinning 15k SAS drives and these new Intel SSDs is night and day for random read operations.
5. Updates and Daemons
Run yum update or apt-get upgrade weekly. It sounds basic, but unpatched kernels are the number one vector for local privilege escalation exploits. Also, check what is listening:
netstat -tulpn
If you see services you don't recognize (like Sendmail or RPCbind) listening on public interfaces, kill them. Use chkconfig to ensure they don't start on boot.
The Bottom Line
Security is a trade-off between convenience and paranoia. In 2010, you cannot afford to choose convenience. Whether you are running a small dev box or a high-traffic e-commerce cluster, these steps are mandatory.
If you need a platform that takes this seriously—with low latency connectivity to the Norwegian Internet Exchange (NIX) and hardware that doesn't choke on I/O—give our infrastructure a spin. Don't let a script kiddie ruin your uptime.
Ready to deploy? Spin up a secure CentOS instance on CoolVDS today.