Locking Down the Fort: A Survival Guide for the Paranoid Sysadmin
Let’s be honest: default installations are dangerous. Whether you just spun up a fresh CentOS 5.3 or a Debian Lenny node, that box is naked. The automated botnets don’t sleep, and they don't care that your startup just launched. I've seen entire clusters compromised because a junior dev left root password login enabled.
If you are serious about hosting in the Nordic market, you need stability. We aren't just talking about uptime; we are talking about integrity. Here is how to harden your Linux VPS before you even think about installing Apache.
1. Burn the Default SSH Config
The first thing an attacker targets is Port 22. Leaving it open to password authentication is suicide. We need to move the port and switch to keys immediately.
Edit your configuration:
vi /etc/ssh/sshd_config
Change these lines. Do not hesitate:
Port 2200 # Move away from default
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Pro Tip: Before you restart SSH with /etc/init.d/sshd restart, open a second terminal session to verify you can login. If you locked yourself out, and you aren't on a CoolVDS instance with out-of-band VNC console access, you are in for a long night.
2. Iptables: The First Line of Defense
Hardware firewalls are great, but you need host-level protection. Most VPS providers give you a wide-open network interface. At CoolVDS, we protect the perimeter, but you should still trust no one.
Here is a restrictive baseline for a web server. Drop everything, then open only what is necessary.
# Flush existing rules
iptables -F
# Default policy: Drop everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (critical for local services like MySQL)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so you don't cut yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your new 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 your rules. On RedHat/CentOS systems: /sbin/service iptables save.
3. Banish Brute Force with Fail2Ban
Even with a custom SSH port, logs get flooded. Fail2Ban (currently version 0.8.4) is mandatory. It scans log files and updates iptables to ban IPs that show malicious signs.
On Debian/Ubuntu:
apt-get install fail2ban
Configure /etc/fail2ban/jail.conf to ban an IP for 3600 seconds after 3 failed attempts. This drastically reduces the noise on your network interface, keeping your CPU cycles free for serving PHP, not rejecting bots.
4. Disable Unused Services
A default install of CentOS often includes services you don't need. Sendmail? Portmap? Cups? If this is a web server, kill them.
chkconfig sendmail off
chkconfig portmap off
chkconfig yum-updatesd off
service sendmail stop
Every open port is a potential vector. Run netstat -tulpn and audit every listening socket. If you don't know what it is, shut it down.
5. The CoolVDS Advantage: Xen vs. OpenVZ
Security isn't just software; it's architecture. Many budget hosts in Europe are overselling resources using OpenVZ containers. The problem? Kernel exploits.
If a hacker crashes the kernel on an OpenVZ node, everyone goes down. At CoolVDS, we use Xen HVM virtualization. Your kernel is your kernel. This provides true isolation. Combined with our 15k RPM SAS RAID-10 arrays (and the new Enterprise SSDs we are rolling out), you get dedicated I/O performance that doesn't fluctuate when a neighbor gets DDoS'd.
Data Integrity and Norwegian Law
For those of us operating out of Oslo, compliance with the Personal Data Act (Personopplysningsloven) is paramount. Hosting your data outside of the EEA creates legal headaches. By keeping your servers physically located in our Oslo facility, you ensure low latency to the NIX (Norwegian Internet Exchange) and strict adherence to Datatilsynet guidelines.
6. Secure Shared Memory
An often overlooked attack vector is shared memory. Mount it with noexec and nosuid to prevent rootkits from executing there.
Edit /etc/fstab:
tmpfs /dev/shm tmpfs defaults,noexec,nosuid 0 0
Remount it:
mount -o remount /dev/shm
Conclusion
Security is a process, not a product. But starting on a robust foundation makes all the difference. Don't build your infrastructure on oversold, insecure containers.
Need a rock-solid environment for your next deployment? Deploy a Xen VPS on CoolVDS today. Experience true isolation, low latency to Oslo, and the stability your business demands.