5 Minutes to Root: Why Your Default Linux Install is a Ticking Time Bomb

Let’s be honest. If you plug a fresh RHEL 5 or Debian Lenny server into the public internet today without a firewall, you are essentially donating your bandwidth to a Russian botnet. I watched the logs on a honeypot node just last week: it took exactly 14 minutes for the first automated SSH brute-force script to knock on the door.

In the Nordic hosting market, we pride ourselves on stability. But hardware redundancy means nothing if your software layer is Swiss cheese. Whether you are hosting a high-traffic Magento store or a critical Subversion repository, security is not a feature—it is the baseline.

Here is the exact hardening protocol we apply to high-value infrastructure, the same methodology we recommend for every CoolVDS instance deployed in our Oslo facility.

1. Burn the Default SSH Config

The default sshd_config is designed for compatibility, not security. Running SSH on port 22 with root login enabled is professional negligence.

Open /etc/ssh/sshd_config and change these lines immediately:

Port 2200  # Move away from the default port 22 scan range
Protocol 2 # Never use Protocol 1, it is insecure
PermitRootLogin no # Create a sudo user instead
UseDNS no # Speeds up login by disabling reverse DNS lookups

After saving, do not forget to restart the service. On CentOS/RHEL:

service sshd restart

Pro Tip: Never rely on passwords alone. Generate a 2048-bit RSA key pair (ssh-keygen -t rsa -b 2048) and enforce key-based authentication. Passwords can be guessed; private keys cannot.

2. The Firewall: iptables is Your Best Friend

Many admins are afraid of iptables because the syntax is unforgiving. Get over it. A hardware firewall at the datacenter edge is great for stopping DDoS attacks, but you need host-level filtering to stop lateral movement.

Here is a "deny-all-by-default" policy script. This allows only SSH (on our new port), Web, and Loopback traffic:

# Flush existing rules
iptables -F

# Set default chain policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Accept on localhost
iptables -A INPUT -i lo -j ACCEPT

# Accept established connections (keep your shell alive!)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (Port 2200), HTTP (80), HTTPS (443)
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

# Log dropped packets (optional, watch disk space)
iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

On RedHat systems, save this with service iptables save so it survives a reboot.

3. Banish Unnecessary Services

Does your web server really need xinetd, cups (printing), or portmap running? Every open port is an attack vector. Run netstat -tulpn to see what is listening.

If you see services you don't recognize, kill them. On a lean CoolVDS Xen VPS, we provide a minimal template, but if you installed from a standard ISO, you likely have bloatware.

chkconfig sendmail off
chkconfig bluetooth off
chkconfig cups off

4. Brute Force Protection with Fail2Ban

Even on a non-standard port, bots will eventually find your SSH daemon. You need an automated bouncer. Fail2Ban scans log files (like /var/log/secure) and bans IPs that show malicious signs—too many password failures, seeking exploits, etc.

Install it via EPEL repo on CentOS or apt on Debian. Configure jail.conf to ban an IP for 3600 seconds after 3 failed attempts. It keeps your logs clean and your CPU usage low.

The CoolVDS Advantage: Isolation Matters

Software hardening is useless if the virtualization platform is weak. Many budget hosts use OpenVZ, where a kernel exploit in one container can potentially compromise the host node.

At CoolVDS, we strictly use Xen virtualization. This offers true hardware virtualization and memory isolation. If a neighbor gets hit, your instance remains secure. Combined with our 15k RPM SAS RAID-10 storage, you get the reliability of dedicated hardware with the flexibility of a VPS.

Compliance in Norway (Personopplysningsloven)

For our Norwegian clients, physical location matters. The Datatilsynet (Data Inspectorate) is becoming increasingly strict about where personal data resides. By hosting in Oslo, you ensure compliance with the Personal Data Act of 2000 and the EU Data Protection Directive.

Don't risk legal headaches to save a few kroner hosting in a US jurisdiction. Keep your data under Norwegian law.

Final Thoughts

Security is not a "set and forget" task. It is a discipline. Run yum update regularly, read your logs, and never underestimate the persistence of script kiddies.

Need a rock-solid foundation for your next project? Deploy a Xen VPS on CoolVDS today. We handle the hardware; you control the code.