The Internet is Not Your Friend
I watched a junior sysadmin lose a production MySQL database last week. It wasn't a complex zero-day exploit or a disgruntled employee. It was a dictionary attack on port 22. He used a weak password for the root user. Gone. In minutes.
If you are deploying a server in 2009 without locking it down, you are essentially hanging a "Free Hardware" sign on your IP address. Botnets don't care that you're a small startup in Oslo. They scan, they brute-force, they conquer.
This isn't theoretical. At CoolVDS, we see thousands of unauthorized login attempts hitting our perimeter firewalls every hour. Here is how we secure our infrastructure, and how you should secure your slice.
1. SSH: The Front Door
The default sshd_config shipped with CentOS 5 and Debian Lenny is designed for compatibility, not security. Change it immediately.
Open /etc/ssh/sshd_config and make these non-negotiable changes:
# Use a non-standard port to stop script-kiddie noise
Port 2222
# Never allow root to log in directly
PermitRootLogin no
# Protocol 1 is broken. Use Protocol 2 only.
Protocol 2
# Passwords are for amateurs. Use Keys.
PasswordAuthentication no
UsePAM no
Pro Tip: Before you restart SSH with /etc/init.d/ssh restart, open a second terminal session to verify you can still log in. If you lock yourself out, you'll be submitting a ticket to the datacenter floor for a manual console reset. Don't be that guy.
2. The Firewall: Respect iptables
GUI firewalls are for desktops. On a server, we use iptables. It operates at the kernel level and it is fast. The logic is simple: Drop everything, then open only what is necessary.
Here is a baseline script to flush existing rules and set a sane policy:
# Flush old rules
iptables -F
# Set default policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (localhost)
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
# Open your new SSH port (2222)
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
# Web traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPTSave this. On RedHat/CentOS systems, use service iptables save. On Debian systems, you might need to use iptables-save and restore it via rc.local or pre-up scripts in /etc/network/interfaces.
3. Automate Defense with Fail2Ban
Even on a custom port, persistent attackers will hammer your server. You cannot watch /var/log/auth.log 24/7. Let software do it.
Fail2Ban parses your logs for failed login attempts and dynamically updates your iptables rules to ban the offending IP address. It is available in the EPEL repository for CentOS and standard repos for Debian.
Install it, and configure jail.conf to ban an IP for one hour (3600 seconds) after 3 failed attempts. This drastically reduces the load on your CPU caused by processing failed crypto handshakes.
4. The Architecture Factor: Why Isolation Matters
Software hardening is useless if your neighbor brings down the physical node. In the budget hosting market, providers often oversell resources using OpenVZ containers. If one user gets DDoS'd, the whole node suffers.
This is where architecture counts. At CoolVDS, we prioritize Xen HVM virtualization. This provides true hardware isolation. Your kernel is your kernel. If a neighbor spikes their CPU or gets flooded, your memory and I/O remain dedicated to you.
Furthermore, hosting in Norway offers distinct advantages regarding data integrity. With the strict enforcement of the Personopplysningsloven (Personal Data Act) and the oversight of Datatilsynet, your data remains legally distinct from US-based jurisdictions. Physical proximity to the NIX (Norwegian Internet Exchange) in Oslo ensures your latency stays in the low single digits for Nordic users.
5. Disable Unused Services
Do you need sendmail running if you aren't sending email? Do you need rpcbind? Every open socket is a potential vulnerability.
Run netstat -tulpn to see what is listening. If you don't know what it is, shut it down using chkconfig (CentOS) or update-rc.d (Debian).
Conclusion
Security is not a product; it is a process. These steps will filter out 99% of automated attacks targeting your infrastructure. But remember, a secure server on an unstable network is just a secure brick.
If you need a foundation that respects strict resource isolation and offers high-performance SAS RAID-10 storage for heavy I/O workloads, we are ready for you.
Secure your stack today. Deploy a Xen-based instance on CoolVDS and sleep better tonight.