The default install is not your friend.
I spent last Saturday night cleaning up a compromised web server for a client in Oslo. It wasn't a sophisticated APT (Advanced Persistent Threat); it was a simple brute-force attack on port 22. They had a weak root password and no firewall rules. The result? A rootkit installed in /usr/bin and their IP blacklisted by Spamhaus. The server was a zombie.
If you are deploying a server today, whether it's for a high-traffic Magento store or a dev environment, you cannot assume "security through obscurity." Bots scan the entire IPv4 range constantly. If you have a public IP, you are a target.
Here is how we lock things down. This isn't theoretical; this is the exact checklist I use when provisioning bare metal or virtual instances.
1. SSH: The Front Door
The first thing an attacker targets is SSH. By default, most providers give you root access on port 22. That is asking for trouble.
First, create a dedicated user. Do not log in as root.
useradd -m deployer
passwd deployer
usermod -aG wheel deployer # CentOS
# or
usermod -aG sudo deployer # Ubuntu/DebianNext, edit your daemon config. I've seen too many sysadmins leave Protocol 1 enabled. Don't be that person.
Pro Tip: Before you restart the SSH service, open a second terminal session and keep it active. If you mess up the config, you won't lock yourself out.
Edit /etc/ssh/sshd_config:
Port 2222 # Security by obscurity, but it reduces log noise
PermitRootLogin no
Protocol 2
PasswordAuthentication no # Use SSH Keys only!Force the use of RSA keys. Passwords are dead in 2011. If you aren't using ssh-keygen -t rsa -b 4096, you aren't secure.
2. The Firewall: Learn to Love iptables
I hear people complaining that iptables is complex. It is. It is also the most powerful tool you have in the kernel. Forget GUI wrappers; learn the syntax.
A basic ruleset for a web server should look like this. Note the default policy is DROP. We only allow what we need.
# Flush existing rules
iptables -F
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
# Keep established connections alive
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on our new port), HTTP, HTTPS
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
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 DROPOn CentOS 6, remember to save it: service iptables save.
3. Fail2Ban: The Bouncer
Even with a custom SSH port, bots will find you. Fail2Ban scans log files (like /var/log/secure) and updates iptables to ban IPs that show malicious signs.
Install it via EPEL (Extra Packages for Enterprise Linux):
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
yum install fail2banConfigure /etc/fail2ban/jail.local to ban an IP for an hour after 3 failed attempts. This drastically reduces the load on your CPU caused by auth processes.
4. Data Sovereignty and The "Patriot Act" Problem
This isn't a config change, but it's a security decision. If you are hosting data for Norwegian citizens, you need to be aware of where that data physically sits. With the US Patriot Act allowing American agencies to subpoena data on US servers (even if the server is in Europe but owned by a US company), data location matters more than ever.
The Norwegian Data Protection Authority (Datatilsynet) is strict. By hosting on CoolVDS, your data stays in our Oslo datacenter. We are a Norwegian entity. Your data falls under Norwegian jurisdiction and the EU Data Protection Directive (95/46/EC), not US law. This is crucial for compliance projects.
5. Performance as a Security Feature
A slow server is vulnerable to DoS (Denial of Service) attacks because it takes fewer requests to topple it. You need I/O throughput to handle log writing during an attack without choking the CPU.
We are currently rolling out storage tiers utilizing the new NVMe 1.0 specifications and high-performance PCIe flash storage. While traditional SAS drives struggle at 150 IOPS, our high-performance setups push thousands of IOPS. This means your database doesn't lock up when traffic spikes—malicious or otherwise.
Summary: Trust No One
Security is a process, not a product. Keep your kernel updated (yum update is your friend), monitor your logs, and choose a host that understands the infrastructure stack from the metal up.
If you need a rock-solid foundation for your next deployment, don't gamble with oversold budget hosts. Deploy a secure, low-latency instance on CoolVDS today. We handle the hardware; you handle the code.