On this page
What firewall configuration involves
A firewall decides which network traffic can reach your server and which cannot. A good one follows a simple principle: deny by default, allow by exception. Only the ports and sources your business actually uses are open, such as HTTPS for visitors and SSH for administrators, and everything else is closed.
Firewalls exist at several layers: on the server itself, at the cloud provider, and in front of your site through services like Cloudflare. Configuration means deciding what each layer does, so they complement rather than contradict each other.
Signs your firewall needs work
- A port scan shows your database, cache or admin tools reachable from the internet.
- The server firewall is disabled because it was blocking something once.
- Docker containers are exposed even though the host firewall seems to block them.
- Your application and database servers talk to each other over open public ports.
- Nobody can say which rules exist on the cloud provider’s firewall versus the server.
What’s included
- An inventory of every listening service and who legitimately needs to reach it.
- Default-deny inbound rules with an explicit allow-list.
- SSH limited to known IP addresses or a VPN where practical.
- Server-to-server traffic restricted to private networks and specific ports.
- Handling of Docker’s own firewall rules so containers are not exposed unexpectedly.
- Cloud firewall or security group rules aligned with the server firewall.
- Optional origin lockdown so web traffic is accepted only from Cloudflare.
- Documentation of every rule and its purpose.
How we avoid lockouts
- Map traffic: listening ports, active connections and what the application calls out to.
- Draft the rule set and review it with you, especially admin access.
- Apply rules with a fallback in place, such as provider console access or a timed rollback.
- Test from outside and between servers: websites, APIs, SSH, database connections and webhooks.
- Scan again to confirm only intended ports are open, then document.
Tools we use
On Ubuntu we typically use UFW, which is a clear front end to the kernel firewall, or nftables and iptables directly for more complex setups. At the provider level we configure security groups and firewalls on AWS, Google Cloud, Azure, DigitalOcean and Hetzner. Cloudflare adds web-layer filtering and rate limiting in front. For many servers, rules are managed with Ansible or Terraform so they stay consistent.
What affects timeline and cost
One server with a simple web stack is quick. It takes longer with multiple servers, private networking, Docker, VPN setup, office IP allow-lists, or legacy services whose traffic has to be discovered before it can be restricted safely.
Where a VPN or bastion host is needed for administrator access, setting it up is a small additional piece of work, but it removes SSH from the public internet entirely, which is one of the most effective protections available for a small team.
An example allow-list
Every firewall we build starts from a written policy that you can read without knowing firewall syntax. For a typical setup with a web server and a separate database server, it might look like this:
| Server | Allowed inbound | From |
|---|---|---|
| Web server | HTTPS (443) and HTTP (80) for redirects | Anywhere, or only Cloudflare if proxied |
| Web server | SSH (22) | Office IP, VPN or bastion host only |
| Database server | Database port | Web server’s private IP only |
| Database server | SSH (22) | VPN or bastion host only |
| Both | Monitoring agent port | Monitoring server only |
Everything not on the list is denied. Outbound traffic is usually left open for updates and integrations, but it can be restricted too where your security requirements call for it.
Keeping the policy in plain language alongside the actual rules means anyone can check whether the firewall still matches the intent. When a new service is added, the policy is updated first and the rules follow, rather than rules being added ad hoc and forgotten.
Common mistakes
- Enabling the firewall before allowing SSH and getting locked out.
- Assuming UFW protects Docker containers when Docker inserts its own rules first.
- Filtering only incoming traffic from the internet while leaving internal traffic wide open.
- Adding rules over time with no comments, until nobody knows which ones are still needed.
Related: Server Security Hardening, Cloudflare Setup and our Cyber Security services. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
Do I need a server firewall if my cloud provider has one?
Using both is sensible. The provider firewall blocks traffic before it reaches the server; the server firewall protects you if the provider rules are ever changed by mistake.
Can you restrict SSH to our office?
Yes, if your office has a stable IP. Otherwise a VPN or bastion host gives similar protection without breaking remote access.
Why is my Docker container reachable even with UFW enabled?
Docker adds its own rules that can bypass UFW. We bind containers to localhost or configure the rules so the host firewall applies.
Will the firewall block webhooks from payment gateways?
Not if planned properly. We identify inbound integrations before enforcing rules and test them afterwards.
What if we lock ourselves out?
We always keep a fallback before applying rules, such as the provider’s web console or a timed automatic rollback. If access is lost, the rules revert or can be fixed from the console.
Talk to us about firewall configuration
UFW or iptables rules that allow exactly what is needed and nothing else.