Managed Firewall & Network Isolation in Romania

What we close and what stays open

We start with an inventory: what listens on each server today, and why. We almost always find services exposed out of habit rather than need: a database port opened for a client who left, an admin panel reachable from any country, a management port forgotten after a migration. Only 80 and 443 stay public. Everything else moves to the private interface or behind the VPN, and we confirm the result from outside.

• An inventory of listening ports on every server
• Only 80 and 443 stay public; SSH moves behind the VPN or a bastion
• PostgreSQL, MySQL, Redis and MongoDB bound to the private address
• Filtered outbound traffic, so a compromised server cannot reach just any destination

Best practices we apply on the firewall

Firewall rules decay over time, as teams add temporary exceptions that quietly become permanent after a debugging session. So we work from a fixed list and repeated checks from the outside, not from a one-off configuration. The list stays in your documentation, together with the result of the first scan, so you have a clear reference against which the following months are compared.

• Default deny inbound, and outbound limited to the destinations that are needed
• Segmentation by tier: edge, application, data, with no direct crossing
• No database, Redis or MongoDB on a public IP, in any environment
• Automated port audits from outside, with an alert on any drift
• Logging, progressive blocking of attempts and country or network rules where justified

Segmentation by tier, not office VLANs

Material about segmentation usually talks about home networks or office VLANs. On servers the split is different: an edge tier that receives internet traffic, an application tier that must never be called directly from outside, and a data tier that accepts connections only from the application. Every crossing between tiers is an explicit rule, not a side effect of the machines sharing a subnet.

• Edge: reverse proxy and TLS termination, the only tier exposed publicly
• Application: reachable only from the edge, on internal ports
• Data: accepts connections only from the application and from administration over the VPN

DDoS, automatic blocking and included hours

L3/L4 DDoS protection is included at the network level, so volumetric attacks do not reach your server. For abuse at application level we add progressive blocking with Fail2ban or CrowdSec and request limits. Hardening and port audits come out of your monthly hours: 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, 10 h on GPU servers, requested from the client panel. Anything above the quota is billed separately.

How we work

1. Request it in the panel

   Open a request under DevOps Services, tell us which servers you have and what must remain reachable from the internet, then propose a deadline.

2. We scope the work

   We inventory the ports, scan from outside, show you what is exposed for no reason and agree the order in which things get closed.

3. We build it without breaking production

   We apply the rules tier by tier with a way back, move services to private addresses, then rescan and compare the results.

4. Handover with documentation

   You receive the rules we applied, the map of the tiers, the report from the outside scan and the procedure for opening an exception.

Use cases

Technology stack

• nftables
• UFW
• Fail2ban
• CrowdSec
• nmap
• WireGuard
• Suricata
• Prometheus

Frequently asked questions

• How do I secure a Linux VPS?

  In this order: automatic security updates, SSH with keys and taken off the internet, default deny in the firewall, services bound to the private address, progressive blocking of attempts and monitoring. Then check from outside what still answers, because the port list on the server does not tell the whole story.

• How do I find open ports on my server?

  Locally, ss or lsof shows what listens, but the real picture comes from a scan from outside with nmap, from another network. The difference between the two lists is exactly what the firewall filters, or fails to filter. We scan at every audit and leave you the report.

• What is network segmentation, and why does it matter?

  It is splitting the infrastructure into zones that talk only through explicit rules. It matters because it limits the damage: an attacker who compromises the public component does not automatically reach the database, but stops at the first crossing between tiers.

• Should a database or Redis ever sit on a public IP?

  Not in any ordinary scenario. The application reaches them on the private address and administrators go through the VPN. A Redis or MongoDB instance without a password on a public IP is found by automated scanners within hours and used straight away.

• Does Docker bypass my UFW rules?

  It can. Docker adds its own rules ahead of UFW when you publish a port, so a container may be reachable even though UFW looks closed. We write Docker-aware rules in nftables and verify with an outside scan, instead of trusting the UFW status alone.

• CrowdSec or Fail2ban?

  Fail2ban is simple and reacts to patterns in your own logs. CrowdSec adds shared reputation lists from many servers and a more modern engine. We choose by setup: Fail2ban alone can be enough for SSH, while CrowdSec earns its place where web traffic is heavy.