Stop Trusting Default Configs: A Sysadmin's Guide to Firewalling

Let’s be honest. If you deployed a server today and left Port 22 wide open to the world, your /var/log/secure is already bleeding gigabytes of failed login attempts. The internet of 2010 isn't a playground; it's a war zone of automated botnets scanning for weak root passwords and unpatched Apache exploits.

I’ve seen too many competent developers deploy a brilliant application only to have their server crawl to a halt because a Chinese botnet decided to brute-force their SSH daemon. Latency spikes. I/O wait hits 40%. The client calls screaming.

Today, we aren't just "setting up a firewall." We are architecting a perimeter defense using iptables and Fail2Ban. And we're doing it the right way, optimized for the low-latency infrastructure we run here at CoolVDS.

The Philosophy: Default DROP

Most default Linux installations (looking at you, CentOS 5) come with a polite firewall policy. It accepts traffic unless told otherwise. This is backward. In security, if you aren't explicitly invited, you don't get in.

We need to switch our INPUT chain policy to DROP. This makes your server invisible to random port scans. If they ping you, you don't answer. You are a black hole.

But before you type this, ensure your current SSH session is allowed, or you’ll be locking yourself out and submitting a ticket to our support team to get console access.

# Flush existing rules
iptables -F

# Allow loopback (critical for local services like MySQL)
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

# Allow SSH (Change 22 to your custom port if you're smart)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

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

# Set default policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP

Rate Limiting: Killing the Brute Force

Even with a firewall, an open port is an invitation. If you run a high-traffic site targeting users in Oslo or broader Europe, you can't just IP-whitelist your office. You need the world to connect, but you need to punish abuse.

This is where the recent module in iptables shines. It tracks IP addresses hitting your network interface. Here is a snippet I use on every CoolVDS instance I provision. It limits new SSH connections to 3 per minute per IP.

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

If a bot tries to hammer your login, the kernel silently drops their packets after the third attempt. No CPU wasted on encryption handshakes. Clean. Efficient.

The "CoolVDS" Factor: Kernel Control

Here is the dirty secret of the hosting market right now. Many budget VPS providers use oversold OpenVZ containers. They share a single kernel. Often, they disable critical iptables modules like xt_recent or connection tracking to save resources on the host node.

Pro Tip: If modprobe ip_conntrack fails on your VPS, migrate immediately. You cannot secure a server without stateful inspection.

At CoolVDS, we prioritize KVM and Xen virtualization. You get your own kernel. You get raw access to netfilter. If you want to load custom security modules or tweak your TCP stack for 1ms latency to the NIX (Norwegian Internet Exchange), you can. We don't artificially limit your security posture to save RAM.

Automating Defense with Fail2Ban

Iptables handles the network layer, but what about application logic? If someone is trying SQL injection on your web forms, iptables won't know.

Install Fail2Ban. It parses your log files (syslog, auth.log, apache/error_log) and dynamically updates firewall rules to ban offending IPs. It works perfectly with the Norwegian Data Protection Authority (Datatilsynet) compliance, as it logs the intrusion attempts for audit trails.

Quick config for /etc/fail2ban/jail.conf:

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 3600

This bans an attacker for one hour after 3 failed password attempts. It turns your server into a moving target.

Compliance and Storage

For our clients operating in Norway, remember the Personal Data Act (Personopplysningsloven). You are responsible for the security of the data you host. A firewall isn't optional; it's a requirement for due diligence. However, logging all this traffic generates massive I/O.

This is why the underlying storage matters. On standard SATA drives, heavy logging can cause "iowait," slowing down your database. CoolVDS utilizes enterprise-grade RAID-10 SAS storage (and we are testing high-performance SSDs in our labs). This ensures that writing 10GB of firewall logs doesn't choke your MySQL queries.

Final Thoughts

Security is a process, not a product. But having a hosting platform that doesn't fight you makes that process a lot smoother. Don't settle for stripped-down containers that leave you vulnerable.

Need a sandbox to test these rules? Spin up a KVM instance on CoolVDS today. We offer full root access and the raw performance you need to handle the traffic, attacks and all.