Fintech scale-up preparing for a client security review
A payments company closes a database port that had been left open for a debugging session months earlier, after a client's security questionnaire asked for evidence of network segmentation.
Firewall & Network Isolation Hosting UK
DevOps services · United Kingdom
Firewall and network isolation for UK teams who want to know, with certainty, exactly what's reachable from the public internet. We set every server to default-deny, open only 80 and 443 publicly, and put everything else behind the private network or VPN. Edge, application and data tiers get segmented from each other, with automated port audits so drift gets caught, not discovered during an incident.
- Default-deny, only 80/443 open publicly
- Edge, application and data tiers segmented
- Scheduled external port audits catch drift
- VPS 1–8 h/month; dedicated 5–10 h/month depending on plan; GPU 10 h/monthIncluded hours
- Frankfurt, in the EUData centre
- L3/L4 DDoS mitigation included at the edgeNetwork protection
- EUR invoicing, 20% UK VAT itemisedBilling
01
What default-deny actually looks like
We configure nftables or UFW on every server alongside the provider-level firewall, with a default-deny inbound policy: only 80 and 443 are open to the world, and every other port — SSH, database, admin panel, internal API — is closed or reachable only over the private network or VPN. Servers are segmented into edge, application and data tiers, so a compromised application server doesn't have a direct line to the database tier.
- Default-deny inbound, with only 80/443 open to the public internet
- nftables or UFW configured alongside the provider-level firewall
- Segmentation by tier: edge, application and data kept apart
- Fail2ban or CrowdSec blocking brute-force attempts automatically
02
Best practices we apply
Firewall configuration drifts quietly — a port opened for a one-off debugging session that never gets closed again is one of the most common findings in the security reviews we run. We apply the same checklist on every deployment and back it with scheduled audits, so drift gets caught automatically instead of six months later. Audit results land in your client panel, with the port and the date it was opened, not a verbal reassurance.
- Default-deny inbound, restricted outbound (egress filtering too)
- Network segmentation by tier, not a single flat address space
- No database, Redis or MongoDB port reachable from a public IP
- Scheduled external port scans, with an alert on any drift
- Logging in place, with geo/ASN rules applied where justified
03
Why egress matters as much as ingress
Most firewall conversations stop at inbound rules, but a compromised server that can freely make outbound connections is how data actually leaves during an incident. We apply egress filtering too — restricting which outbound connections a server is allowed to make — so even a successful compromise has a harder time exfiltrating anything or reaching a command-and-control server. This is one of the checks we run when you book a firewall review through your included hours.
04
How the included hours work
DevOps hours come with the plan: 1–8 hours a month on VPS tiers, 5–10 hours a month on dedicated servers depending on the plan, 10 hours a month on GPU servers. Use them for the initial segmentation and firewall set-up, a port audit after adding new services, or investigating an unexpected open port. Request the work from the client panel under DevOps Services. Hours don't roll over, so most teams handle the initial hardening in one month and rely on scheduled audits afterwards.
How we work
Request the work from the panel
You describe your current server layout and which services are currently reachable from the public internet, and propose a deadline.
We scope the segmentation model
We design the edge, application and data tier split, and confirm which ports genuinely need to stay public versus private.
We apply the rules and audit externally
We configure the firewall rules, then run a port scan from outside your network to confirm nothing unexpected is exposed.
We hand over with a monitoring schedule
You receive the segmentation diagram, the firewall rule set, and the scheduled audit that keeps checking after we've finished.
Use cases
E-commerce platform with a public-facing admin panel
A retailer moves its admin panel behind the private network entirely, after a brute-force attempt on the login page showed up in access logs.
Public-sector supplier needing documented network controls
A contractor bidding for local-authority work needs documented default-deny firewall rules and scheduled port audits to satisfy a procurement security questionnaire.
Technology stack
- nftables
- UFW
- Fail2ban
- CrowdSec
- nmap
- WireGuard
Every subscription includes monthly DevOps, CyberSecurity and Programming hours: 1 h from the cPanel Advanced plan up, 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, and 10 h on GPU servers. Hours are requested from your client panel, don't roll over to the next month, and anything above the quota is accepted and billed separately.
Frequently asked questions
What does default-deny actually mean for our servers?
It means nothing is reachable from the public internet unless it's explicitly allowed — usually only ports 80 and 443. Everything else, including SSH and database ports, is closed to the outside and reachable only over your private network or a VPN connection.
Should our database ever be reachable from a public IP?
No — this is one of the most common and most serious findings we see. A database on a public IP is one leaked credential away from a breach. We put every database behind the private network or VPN, never exposed directly to the internet.
What's network segmentation and why does it matter?
It means splitting servers into tiers — edge, application, data — so a compromised server in one tier doesn't have a direct path to another. If your public-facing web server is breached, segmentation stops that from becoming a direct line to your database.
How often do you audit for firewall drift?
We run scheduled external port scans against your infrastructure, checking what's actually reachable from the outside rather than trusting the configuration on paper. Any unexpected open port raises an alert, so drift — like a port opened temporarily and forgotten — gets caught quickly.
What is egress filtering and do we need it?
Egress filtering restricts which outbound connections a server is allowed to make, not just which inbound connections are accepted. It matters because a compromised server that can freely reach the internet is how data actually leaves during a breach — we apply it alongside inbound rules.
Does the firewall replace our WAF or DDoS protection?
No — they cover different layers. The firewall controls which ports and networks can reach a server at all; L3/L4 DDoS mitigation is included on our network already; a WAF filters application-layer traffic on the ports you do expose, which is a separate CyberSecurity service.
Not sure exactly what's reachable on your servers right now?
Tell us your current set-up and we'll run a port audit and design the segmentation, using the hours already in your plan.