On this page
What firewall setup covers
A firewall decides which traffic is allowed to reach your systems and which is refused. There are two broad kinds, and most businesses benefit from both. A network firewall works at the level of ports and addresses: it can make sure your database is reachable only from your application server, and SSH only from known locations. A web application firewall (WAF) looks inside web requests and can block common attack patterns, abusive bots and floods of login attempts before they reach your application.
Our firewall setup service designs, tests and documents both layers, based on what your services actually need rather than a generic template.
Who needs it, and the warning signs
Anyone running their own servers should have a host firewall at minimum. A WAF becomes especially useful for public sites with login pages or forms, such as an e-commerce store, a patient portal for a clinic, a real estate listing site with agent logins, or a SaaS application exposed to the whole internet.
- Database or cache ports are reachable from the internet.
- Logs show constant login attempts against your admin pages or SSH.
- Nobody knows what the existing firewall rules do, or whether there are any.
- A compromised server would be free to connect anywhere on the internet.
What’s included
- Traffic inventory — which services need to be reached, by whom, and on which ports.
- Host firewall rules on each server, using tools such as ufw, nftables or iptables, with a default-deny inbound policy.
- Cloud firewall or security group rules where your provider supports them.
- Egress restrictions, limiting outbound connections so a compromised service has less freedom to cause damage or send data out.
- WAF configuration, for example through Cloudflare, including managed rule sets, rate limiting on login and form endpoints, and bot controls.
- Brute-force protection with fail2ban or similar, working alongside the firewall.
- Documentation explaining the purpose of each rule, so future changes are safe.
How we deliver it
- Confirm scope and authorisation for the servers, networks and domains involved.
- Observe current traffic and listening services to build an accurate picture of what’s legitimate.
- Design rules and review them with you, particularly anything affecting partners, payment providers or remote staff.
- Test in monitoring mode where the tool supports it, logging what would be blocked without blocking it.
- Enforce once the logs show legitimate traffic is unaffected, keeping a safe way back in.
- Document and hand over, including how to add or change a rule.
Why outbound rules matter too
Most firewalls are set up to control what comes in and allow anything to go out. That is convenient, but it means a compromised application can freely download further malicious tools, send spam, or copy data to an outside server. Egress rules limit outbound connections to the destinations a service genuinely needs — for example, your payment gateway, your email provider, package update mirrors and the APIs you integrate with.
Egress filtering needs care, because blocking a legitimate destination can break a feature in ways that are hard to spot. That is why we observe real outbound traffic first, and document each allowed destination so that adding a new integration later is a deliberate, recorded change rather than a mystery outage.
What affects timeline and cost
- The number of servers, networks and public domains in scope.
- How many external parties need access — payment webhooks, partner APIs, offices, remote staff.
- Whether a WAF is already in place or needs to be introduced, including any DNS changes.
- How long a monitoring period is needed before enforcement to be confident nothing legitimate is blocked.
Common mistakes
- Enabling a firewall over SSH without first allowing SSH, and locking everyone out.
- Rules that allow everything because a quick fix for one problem was never tightened again.
- Firewalling the server but leaving the origin IP open, so attackers bypass the WAF entirely.
- Blocking a payment provider’s webhook addresses, so orders stop updating without any obvious error.
- Undocumented rules that nobody dares to change.
Frequently asked questions
Do we need both a network firewall and a WAF?
For most public web applications, yes. The network firewall limits which ports and systems are reachable at all; the WAF filters the web traffic that has to be allowed through.
Can a firewall stop DDoS attacks?
A server firewall alone can’t absorb a large flood of traffic. A CDN or WAF service in front of your site can help with many attacks, and we configure those where appropriate, but no setup can promise to withstand every attack.
Will the firewall block legitimate customers?
That’s the risk we test for. Rules are run in monitoring mode first where possible, and tuned before they’re enforced.
We already use Cloudflare. What else is needed?
Cloudflare can provide the WAF layer, but the server behind it still needs its own firewall, and ideally should accept web traffic only from Cloudflare so attackers can’t bypass it by going straight to your server’s address.
Who maintains the rules afterwards?
Your team can, using the documentation we provide, or we can maintain them as part of an ongoing support arrangement.
Talk to us about firewall setup
Network and application-level rules matched to how your systems are genuinely used.