You have about 4 minutes before the scanners find you.
I ran a test last week. I spun up a fresh CentOS 6.0 install on a public IP. I didn't touch it. I just tailed /var/log/secure. It took exactly 230 seconds for the first brute-force attempt to hit port 22.
The internet is not a friendly place. It is a constant stream of automated scripts looking for default passwords, open ports, and unpatched exploits. If you are deploying production infrastructure—whether it's for a client in Oslo or a personal project—security isn't a "feature." It's oxygen.
This isn't a theoretical computer science lecture. This is the checklist I use for every single node I deploy. If you skip these, you don't have a server; you have a victim.
1. The Keys to the Kingdom (SSH)
Passwords are dead. If you are still logging into your root account with a password, you are asking for a breach. Dictionary attacks are getting faster every year.
Step 1: Generate a 2048-bit RSA key pair on your local machine.
ssh-keygen -t rsa -b 2048
Step 2: Push it to your server.
Step 3: Edit /etc/ssh/sshd_config. This is non-negotiable.
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusernameWe disable UseDNS to stop the SSH daemon from trying to resolve the client's hostname, which kills latency on login. We disable root login because if they guess your user's password, they still need sudo access. It adds a layer.
Pro Tip: Many admins move SSH to a high port like 2222. While this reduces log noise from dumb bots, it is security through obscurity. A determined scanner will find the open port. Rely on keys, not hiding spots.
2. The Firewall: Learn to Love iptables
There is no GUI for this on a serious server. You need to be comfortable with iptables. By default, most provider templates come with everything open. That is reckless.
We want a "Default DROP" policy. If traffic isn't explicitly allowed, it dies.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (critical for local services)
iptables -A INPUT -i lo -j ACCEPT
# Keep established connections alive
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (obviously)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Web traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Don't forget to save. On RedHat/CentOS systems:
service iptables save
Why KVM Matters: At CoolVDS, we use KVM virtualization. Why? Because with kernel-shared technologies like OpenVZ, your iptables modules are often restricted by the host node configuration. KVM gives you your own kernel. You can load whatever modules you need for advanced packet filtering. Don't let a cheap host dictate your security policy.
3. Ban the Noise with Fail2Ban
Even with keys, your logs will be flooded with failed attempts. This consumes disk I/O and CPU cycles. Install Fail2Ban. It parses your logs and updates iptables rules dynamically to ban offending IPs.
On Debian/Ubuntu:
apt-get install fail2ban
Configure /etc/fail2ban/jail.local. Set the bantime to something painful. I prefer 3600 seconds (one hour). If they hammer you, put them in timeout.
4. Updates and Patches
Linux is secure, but software has bugs. The exploit window between a vulnerability being published and a patch being applied is shrinking.
If you are on Debian, apt-get update && apt-get upgrade needs to be part of your weekly routine. If you are running mission-critical workloads, look into unattended-upgrades for security patches, but be careful—automatic updates can sometimes break config files.
5. The Norwegian Advantage (Legal Hardening)
Security isn't just about packets; it's about jurisdiction. If you are hosting data for European customers, you need to be aware of the Data Protection Directive (95/46/EC) and Norway's Personopplysningsloven.
Hosting in the US exposes your data to the Patriot Act. Hosting in Norway keeps your data under Norwegian law. It’s a layer of legal hardening that your CTO will appreciate. Furthermore, latency matters. If your users are in Oslo or Northern Europe, routing traffic through Frankfurt or London adds unnecessary milliseconds. Physics always wins.
Conclusion
A default server installation is a prototype, not a production environment. Hardening takes fifteen minutes, but recovering from a rootkit takes days.
If you need a rig that gives you full control over the kernel for advanced firewalling and high-performance I/O for your databases, stop messing around with oversold shared containers. Spin up a KVM instance on CoolVDS. The network is stable, the storage is fast, and we stay out of your way.