Introducing Firewall Groups for Simpler Server Security

Hey everyone! I'm Marc, the CTO at SSD Nodes. Our engineering team just shipped something I'm really excited about: Advanced Firewall Groups.

Look, managing server security shouldn't be rocket science. Too many hosting providers give you bare-bones tools and expect you to figure out nftables on your own. Which is ridiculous.

We built Firewall Groups because our customers told us they wanted better security controls without the headache.

Now, you get enterprise-level network security right from your dashboard. No SSH required.

The Problem We Solved

Here's what was broken: you'd spin up a VPS, and then you had two choices. Leave it wide open to the internet (bad idea), or spend hours learning command-line firewall syntax (also bad).

Even experienced developers waste time on this stuff. You just want to say "allow port 80, block everything else" without memorizing arcane iptables commands. I've watched talented engineers spend entire afternoons fighting with firewall rules that should take five minutes to set up.

The traditional approach is painful. SSH into your server, write nftables rules, hope you didn't lock yourself out, test everything manually. Miss one detail and you either have a security hole or broken connectivity. Make a typo and you're locked out of your own server.

Our team spent months building something better. Point, click, done.

How Firewalls Actually Work

Before I explain our specific implementation, let's talk about what firewalls do at a basic level. This stuff isn't black magic, but the traditional tools make it seem way more complicated than it needs to be.

A firewall sits between your server and the internet. Every packet of network traffic gets checked against a list of rules. If a packet matches a rule that says "allow", it goes through. If it matches a rule that says "block", it gets dropped. If it doesn't match any rules, the firewall follows a default policy.

The key concept is order matters. Firewalls process rules from top to bottom. The first matching rule wins. This is why you typically put specific rules first and general rules last.

For example, if you want to allow SSH access from your office but block SSH from everywhere else, you'd set up:

1. Allow port 22 from your office IP
2. Block port 22 from everywhere else

Swap those rules and nobody can SSH to your server, including you.

Most servers need both inbound and outbound rules. Inbound controls what can connect to your server. Outbound controls what your server can connect to. A web server might accept HTTP connections (inbound) but also needs to make database queries (outbound).

How Our System Works

We kept it simple. With only three concepts:

Groups hold your rules. You make separate groups for traffic coming in (inbound) and traffic going out (outbound). Each group gets a descriptive name like "Web Server Rules" or "Database Access".

Rules decide what happens to traffic. Allow it or drop it based on whatever criteria you set. You can match on IP addresses, port numbers, protocols, or combinations of all three.

Servers get one inbound group and one outbound group max. No conflicts, no confusion. This prevents you from accidentally creating contradictory rules that break connectivity.

The architecture enforces clean separation. You can't assign multiple inbound groups to the same server because that would create ambiguous rule conflicts. Instead, you put all your inbound rules in one group and all your outbound rules in another.

Building Your First Firewall

Let's say you're running a basic web server and you want to accept only HTTP requests for port 80. Here's the whole process:

1. Go to your Firewall Dashboard.

2. Click Create Group and Create a new