The Internet is a War Zone. Dress Accordingly.
If you put a Linux server online with default settings today, it will be scanned, probed, and likely brute-forced within 15 minutes. I’m not exaggerating. In a recent deployment for a client in Oslo, I watched the /var/log/secure file on a fresh CentOS 5 install. It lit up like a Christmas tree before I even finished configuring the repo mirrors.
Security isn't a product you buy; it's a process you adhere to. While providers like CoolVDS give you a clean slate with high-performance hardware, the responsibility to lock the door rests with you. Here is the battle-tested configuration we use for production nodes targeting the Norwegian market.
1. SSH: The Front Door Must Be Reinforced
Running SSH on port 22 with root login enabled is professional suicide. Script kiddies run bots that blindly hammer port 22 with dictionary attacks against the 'root' user.
First, create a sudo-user. Then, edit your /etc/ssh/sshd_config. We need to disable root login and enforce key-based authentication. Passwords are a liability.
# /etc/ssh/sshd_config
Port 2200 # Move it. It reduces log noise by 99%.
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Pro Tip: Don't forget to allow the new port in your firewall before you restart sshd, or you'll lock yourself out. I've seen senior admins make that drive to the datacenter at 3 AM. It’s not fun.
2. iptables: The Great Wall
Many sysadmins are scared of iptables because the syntax looks arcane. Learn it. It is the single most powerful tool in your arsenal. Unlike simple wrappers, raw iptables rules give you granular control over every packet.
Here is a baseline policy. We drop everything by default and only open what is necessary. This script assumes a web server setup.
# Flush existing rules
iptables -F
# Default policies: DROP everything incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (localhost)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so you don't cut your own SSH session)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your custom port), HTTP, and HTTPS
iptables -A INPUT -p tcp --dport 2200 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Save rules
/sbin/service iptables save
3. Virtualization Matters: KVM vs. The Rest
Hardening the OS is useless if the virtualization layer leaks. In the budget hosting market, OpenVZ is rampant. It shares the host kernel across all containers. If a kernel exploit drops for that version, every container on that node is potentially compromised.
This is why serious infrastructure relies on KVM (Kernel-based Virtual Machine). KVM provides hardware virtualization. Your kernel is your kernel. It’s isolated.
| Feature | OpenVZ / Virtuozzo | KVM (CoolVDS Standard) |
|---|---|---|
| Kernel | Shared with Host | Dedicated / Isolated |
| Performance | Fast, but 'noisy neighbors' can steal CPU | Guaranteed Resources & Stability |
| Security | Vulnerable to Kernel exploits | High Isolation |
At CoolVDS, we strictly use KVM. When you are handling sensitive data subject to the Norwegian Personal Data Act (Personopplysningsloven), that isolation layer is not just a feature; it's a necessity.
4. Fail2Ban: The Bouncer
Even with a custom SSH port, determined attackers might find you. Fail2Ban is a python script that parses your log files (like /var/log/secure or /var/log/httpd/error_log) and updates your iptables rules to ban IP addresses that show malicious signs.
Install it from the EPEL repo on CentOS or standard repos on Debian 6.
yum install fail2ban
# Configure /etc/fail2ban/jail.conf
[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=2200, protocol=tcp]
logpath = /var/log/secure
maxretry = 3
5. The Physical Layer: Latency and Law
Security isn't just about hackers; it's about legal sovereignty. If you are serving Norwegian customers, your data belongs in Norway. Hosting in the US or even Germany introduces latency and complicates compliance with Datatilsynet guidelines.
By hosting locally in Oslo, you reduce latency to the NIX (Norwegian Internet Exchange) to under 5ms. Speed is a security feature—slow sites get abandoned, and slow admin interfaces lead to mistakes.
Furthermore, standard HDDs are becoming the bottleneck for log analysis and database locking during attacks. We are seeing a massive shift toward SSD storage. While expensive, the IOPS capability of SSDs means your server won't choke when writing massive error logs during a DDoS attempt. CoolVDS has deployed SSD arrays specifically to mitigate this I/O wait time.
Final Thoughts
A hardened server is a quiet server. By disabling the defaults, enforcing strict firewalls, and choosing the right virtualization technology, you sleep better at night. Don't wait for the breach to teach you these lessons.
Need a sandbox to test your iptables scripts? Deploy a KVM instance on CoolVDS today. Local Norwegian peering, pure SSD performance, and zero compromise on isolation.