Stop Handing Root Access to Script Kiddies
Let’s be honest. The moment your new VPS spins up and the IP hits the BGP tables, the bots are already knocking. I tail my auth logs and see brute force attempts from IP addresses I can't even pronounce within seconds of a server going live. If you are running a default CentOS 5 or Debian Lenny install without hardening it, you aren't an admin; you're a victim waiting to happen.
At CoolVDS, we keep the network clean and the latency to NIX (Norwegian Internet Exchange) low, but we don't touch your user space. That's your domain. And if you leave it wide open, no amount of RAID-10 redundancy will save your data from being wiped.
Here is the exact hardening protocol I use for every production node we deploy.
1. Burn the Root Password
Using a password for SSH is negligent. Using the root account for SSH is suicide. Dictionary attacks are getting faster every year.
First, create a wheel-group user:
# useradd -m cooladmin
# passwd cooladmin
# usermod -aG wheel cooladmin
Next, generate RSA keys on your local machine. Don't use DSA; stick to RSA 2048-bit for now.
$ ssh-keygen -t rsa -b 2048
Push the public key to your server and lock down /etc/ssh/sshd_config. You need to change these lines immediately:
PermitRootLogin no
PasswordAuthentication no
AllowUsers cooladmin
Port 4422
Pro Tip: Moving SSH off port 22 is security through obscurity, but it drops your log noise by 99%. It keeps the logs clean so you can see the real threats. Just remember to allow the new port in iptables before you restart sshd, or you'll lock yourself out. I've done it. It's a long walk to the console access.
2. The Firewall is Not Optional (Iptables)
We don't have fancy GUI firewalls on bare metal Linux. We have iptables. It’s raw, it’s confusing, and it works. By default, most distributions accept everything. You want a default policy of DROP.
Here is a basic script I use to initialize a web server. It allows HTTP, established connections, and our custom SSH port.
# Flush existing rules
iptables -F
# Allow loopback (critical for local services)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH (Custom Port)
iptables -A INPUT -p tcp --dport 4422 -j ACCEPT
# 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 DROP
Save this. On CentOS, use service iptables save. On Debian, you'll want to dump it to a file and load it on interface up in /etc/network/interfaces.
3. Fail2Ban: Automated Defense
Even with keys, you don't want a bot hammering your SSH port wasting CPU cycles. Install Fail2Ban. It parses logs and updates iptables dynamically to ban IPs that fail authentication too many times.
In /etc/fail2ban/jail.conf, set the ban time to something painful. I prefer 3600 seconds. If they want to guess passwords, make them wait an hour between batches.
4. Compliance and The "Datatilsynet" Factor
If you are hosting data for Norwegian clients, you are bound by Personopplysningsloven. Security isn't just about uptime; it's about legal liability. Storing customer data on an unpatched server is a violation of the requirement for "satisfactory information security."
We see developers putting databases on public IPs for convenience. Don't. Bind MySQL to 127.0.0.1 in my.cnf. If you need remote access, tunnel it through SSH. It’s safer and actually faster due to compression.
5. Minimal Services, Maximum Speed
Every running service is a potential exploit vector. Do you need sendmail? Do you need rpcbind? If this is a web node, probably not.
Run netstat -tulpn to see what is listening. Kill what you don't need. This also frees up RAM. On a CoolVDS slice, our Xen virtualization guarantees your RAM is yours, but there's no point wasting it on a printer daemon for a headless server.
Why Infrastructure Matters
You can harden the OS, but you can't harden the hardware if you don't own it. We use enterprise-grade RAID-10 SAS arrays because we know that disk I/O is usually the bottleneck for database locking. We host in Oslo to ensure your data stays within Norwegian jurisdiction, satisfying local privacy laws.
Security is a stack. We secure the datacenter and the hypervisor. You secure the socket.
Ready to deploy? Don't settle for oversold hardware. Spin up a secure, high-performance VPS instance on CoolVDS today and experience the stability of true dedicated resources.