Stop handing your root password to the world
It is 2010. The script kiddies are winning. If you deploy a fresh CentOS 5 or Debian Lenny box and leave it on the default port 22 with password authentication enabled, check your /var/log/secure. You will likely see thousands of failed login attempts from IPs in China, Russia, and Brazil within the first hour.
I recently audited a client's setup in Oslo—a media agency running a high-traffic Joomla site. They complained about sluggish performance. It wasn't the traffic; their server had been recruited into a botnet because of a weak root password. They were spewing spam emails, getting their IP blacklisted, and burning CPU cycles decrypting SSH brute force attempts.
Security is not a plugin you install later. It is architecture. Here is how we lock down production servers at CoolVDS to survive the hostile environment of the public internet while keeping latency low for Nordic users.
1. Kill the Root Login
Logging in as root is a bad habit from the 90s. Stop it. If an attacker cracks your root password, they own the kernel. If they crack a user password, you still have a fighting chance to isolate them.
Create a dedicated user and give them sudo privileges. On a RHEL/CentOS 5 system:
useradd deployer
passwd deployer
usermod -G wheel deployer
visudo
Uncomment the line allowing the wheel group to run commands. Now, lock the front door. Edit /etc/ssh/sshd_config:
PermitRootLogin no
Protocol 2
AllowUsers deployer
2. Keys over Passwords, Always
Passwords can be brute-forced. 2048-bit RSA keys generally cannot (at least not yet). Force public key authentication and disable password logins entirely.
Inside sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes
Pro Tip: If you are managing servers across different Norwegian datacenters, keep your private keys encrypted on your local machine with a passphrase. If your laptop gets stolen at Gardermoen, your servers remain safe.
3. The Firewall: Learn to Love iptables
Many 'managed' panels try to hide the firewall from you. Real sysadmins write iptables rules. We need to drop everything by default and only open what is necessary.
Here is a baseline script for a web server. Save this as /etc/sysconfig/iptables on CentOS:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Allow loopback and established connections
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH (Consider moving this off port 22)
-A INPUT -p tcp --dport 22 -j ACCEPT
# Web traffic
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
# ICMP (Ping) - Useful for monitoring latency to Oslo
-A INPUT -p icmp -j ACCEPT
COMMIT
Reload with service iptables restart. If you lock yourself out, you better have console access. At CoolVDS, we provide out-of-band VNC console access exactly for these "oops" moments, so you don't have to call support at 2 AM.
4. Ban the Bots with Fail2Ban
Even with keys, thousands of connection attempts clog your logs and waste CPU. Fail2Ban is mandatory. It scans logs for repeated failures and updates iptables to ban the offending IP.
Install it from the EPEL repo:
yum install fail2ban
chkconfig fail2ban on
service fail2ban start
Configure /etc/fail2ban/jail.conf to ban an IP for one hour after 3 failed SSH attempts. This simple step reduced the log noise on our reference servers by 98%.
5. Compliance and The "Datatilsynet" Factor
Hosting in Norway isn't just about latency; it's about the Personopplysningsloven (Personal Data Act). If you are storing customer data, you are responsible for access control. Using a shared hosting environment where file permissions are lax is a liability.
This is why we advocate for full virtualization. While OpenVZ containers are cheap, they share a kernel. If there is a kernel exploit, your data leaks to the neighbors. For strict compliance, we use Xen HVM or KVM virtualization at CoolVDS. This provides true hardware isolation, ensuring that your memory segments are yours and yours alone. It satisfies the strict requirements for data processors operating within the EU/EEA.
6. Performance vs. Security?
People think encryption slows things down. In 2010, CPUs like the Intel Xeon 5500 series have become powerful enough that SSH overhead is negligible. What does kill performance is disk I/O when your logs are being flooded.
| Feature | Budget VPS (OpenVZ) | CoolVDS (Xen/KVM) |
|---|---|---|
| Kernel Isolation | Shared (Riskier) | Dedicated (Secure) |
| Swap Usage | Fake/Burst | Real Dedicated Swap |
| Disk System | Standard SATA | RAID-10 SAS (15k RPM) |
We use enterprise-grade 15,000 RPM SAS drives in RAID-10. This ensures that even if you turn on heavy logging for security auditing, your database performance won't tank. Security requires I/O; don't starve it.
Final Thoughts
A secure server is a quiet server. By the time you finish reading this, a bot has probably scanned port 22 on your current machine. Don't wait for the breach.
If you need a sandbox to test these `iptables` rules without risking your production environment, spin up a CoolVDS instance. Our Norwegian datacenter guarantees low latency, and our hardware isolation gives you the peace of mind Datatilsynet demands.