Stop Trusting Default Configurations

If you just spun up a new box and left it running on port 22 with root password login enabled, you aren't an admin; you're a victim in waiting. I've watched logs on a fresh IP address provided by NIX (Norwegian Internet Exchange) in Oslo, and it takes less than 15 minutes for the automated scanners to start hammering the auth logs.

Security isn't a product you buy; it's a process you endure. Whether you are running a high-traffic Magento store or a critical mail server, the principles remain the same: reduce the attack surface. At CoolVDS, we provision thousands of instances, but the moment we hand over root, the responsibility shifts to you. Here is how to keep your server from becoming part of a botnet.

1. The SSH Fortress

The first thing to die must be password authentication. Brute force attacks are constant and annoying. By enforcing key-based authentication, you render dictionary attacks useless.

Edit your /etc/ssh/sshd_config. If you are on CentOS 5 or Ubuntu 10.04 LTS, the directives are standard:

Port 4422  # Move it off port 22. It cuts log noise by 90%.
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername

War Story: I once audited a client's server that was 'sluggish.' Turns out, sshd was eating 40% CPU just processing failed login attempts from a botnet in Eastern Europe. We moved the port and banned passwords. Load dropped instantly.

Don't forget to reload the service. Do not use a restart command until you've tested the config, or you might lock yourself out.

2. Iptables: The First Line of Defense

Many admins are scared of raw iptables. They rely on wrappers or, worse, leave the chains open. You need to get comfortable with the kernel's packet filtering. A 'deny all' policy is the only sane default.

Here is a baseline script we use on standard CoolVDS LAMP stack deployments:

# Flush existing rules
iptables -F

# Default policies: Block everything by default
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 your SSH session doesn't die)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (use your custom port from step 1)
iptables -A INPUT -p tcp --dport 4422 -j ACCEPT

# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Pro Tip: If you are managing multiple servers, avoid 'noisy neighbor' issues common with OpenVZ containers. CoolVDS uses Xen hypervisors, which means your iptables connection tracking modules are fully isolated and won't hit the limits of the host node.

3. Fail2Ban: Automated Vigilance

Even with keys and custom ports, you want to ban IPs that show malicious intent. Fail2Ban scans log files (like /var/log/auth.log or /var/log/secure) and updates iptables rules to ban offending IPs for a set time.

On Debian/Ubuntu: apt-get install fail2ban

Configure /etc/fail2ban/jail.local to ban an IP for an hour after 3 failed attempts. It’s simple, crude, and incredibly effective against script kiddies.

4. Compliance & The "Datatilsynet" Factor

If you are hosting data for Norwegian citizens, you are subject to the Personal Data Act (Personopplysningsloven). The Data Inspectorate (Datatilsynet) is becoming increasingly aggressive regarding where data physically sits and how it is secured.

Hosting outside of the EEA (European Economic Area) can introduce legal headaches regarding data export. By keeping your infrastructure on CoolVDS servers located physically in Oslo, you simplify compliance. Latency is just a bonus—ping times from Oslo to our datacenter are often sub-2ms.

5. Minimalist Packages

If you don't need X11, remove it. If you don't need Samba, purge it. Every running service is a potential exploit vector. Run netstat -tulpn to see what is listening. If you see a port you don't recognize, kill the process and uninstall the package.

Final Thoughts

Security is not about being unhackable; it's about making it too expensive (in time and resources) to hack you. These steps—SSH hardening, strict iptables, and legal compliance via local hosting—form the bedrock of a secure architecture.

Don't gamble with your uptime or your customer data. Deploy a hardened, Xen-based instance on CoolVDS today and sleep better tonight.