Backup network segmentation is one of the cheapest controls that can stop a ransomware incident from becoming a total rebuild. Many small and mid-size environments protect production servers with decent backup software, but then place the backup console, proxies and repository in the same routing domain as users, printers, Wi-Fi clients or general server management. When an attacker gets an admin token or moves laterally, the backup platform becomes just another target.
This article shows a practical, vendor-neutral design for separating backup traffic with VLANs, VRFs and firewall rules. It fits SMB, home lab, branch and small data-center networks, and it complements the Start Here networking topics, Data Center Networking and Resources pages.
The problem: backups are often reachable from the blast radius
Ransomware defense is not only about having a second copy. The important question is: can the same compromise path that encrypted production also erase, corrupt or lock the backups? Common weak patterns include:
- Backup repository in the same VLAN as production servers.
- SMB/NFS/iSCSI exposed broadly because it was easier during deployment.
- Backup console reachable from user VPN, office Wi-Fi or shared admin workstations.
- Firewall rules written as “temporary any/any” exceptions that stayed forever.
- No independent recovery path when Active Directory, DNS or the core firewall is down.
The goal is not to make backups magically immune. The realistic goal is to reduce paths, create logging choke points and keep at least one recovery path available when normal administration is not trusted.
Design: split backup control, repository and recovery access
Use separate VLANs or VRFs
A simple design uses at least three zones: production/server networks, backup control/proxy networks and repository networks. Larger environments can place the backup platform in its own VRF and leak only the exact routes required through a firewall. Smaller networks can still get most of the value with dedicated VLANs and a stateful firewall interface per zone.
Do not treat the repository as a normal file server. It should accept writes and reads only from backup components that need it. User endpoints should not talk to it directly. Domain-wide interactive logon should be avoided where possible; use local break-glass accounts, MFA-protected admin paths and immutability features on the storage platform.
Keep management separate from data movement
Backup data movement can require high bandwidth, while administrative control needs only a narrow path. Separate the two mentally and in policy. The backup server may orchestrate jobs, a proxy may read from hypervisors, and a repository may store restore points. Those flows deserve different rules, different logs and sometimes different QoS treatment.
Implementation workflow
1. Inventory backup flows before writing rules
Start with a table: source zone, destination zone, protocol, port, backup window and owner. Capture real traffic during one successful backup and one successful restore. This prevents the common mistake of allowing only backup writes while forgetting restore, catalog, metadata, hypervisor API or DNS/NTP dependencies.
# Example discovery checklist, vendor-neutral
backup-proxy -> repository TCP required-storage-ports
backup-server -> hypervisors TCP management/API ports
backup-server -> DNS/NTP/SMTP narrow infrastructure services
admin-jump -> backup-console HTTPS/SSH/RDP as required
users -> repository DENY + LOG
users -> backup-console DENY + LOG
2. Put a firewall or L3 policy point between zones
Layer-2 VLAN separation alone is not segmentation if the core switch routes everything freely. Put an explicit L3 policy point between production, backup and repository zones. In a small network that can be a firewall-on-a-stick, an internal segmentation firewall or switch ACLs as a minimum. In a data center, it may be a VRF-aware firewall, fabric contract or route-leaking policy.
3. Make denies useful
Default-deny rules are useful only if someone sees the interesting events. Log denied connections from user, Wi-Fi and general server VLANs to backup networks. Create an alert for new denies during a ransomware drill or real backup window. A few denied SMB or RDP attempts toward a repository can be an early warning that lateral movement has reached a sensitive boundary.
4. Preserve a recovery path
Keep a small out-of-band or recovery management path that does not depend entirely on the compromised production domain. This may be a console server, management switch, dedicated jump host, hardware MFA token and offline credential procedure. The same principle applies in larger AI or data-center environments: recovery networks should not share every failure mode with the production fabric. For related operational ideas, see the AI Infrastructure hub and BGP Table Watch page.
Example small-environment BOM
You do not need exotic hardware to start. A practical first phase can be modest:
- Managed 1/2.5/10GbE switch with VLANs and ACL support: about 250–900 EUR / 270–980 USD.
- Small firewall appliance or virtual firewall host with at least three routed interfaces: about 300–1,200 EUR / 325–1,300 USD.
- Dedicated backup repository NAS/server with immutable snapshots or hardened Linux storage: about 800–3,000 EUR / 870–3,260 USD before disks.
- Optional console/OOB device for recovery access: about 150–700 EUR / 165–760 USD.
The important part is not the brand. It is the policy: users do not reach repositories, repositories do not initiate broad connections back to production, and administrators enter through a controlled jump path.
Verification and troubleshooting
Test restore, not only backup
A design that allows nightly backups but blocks urgent restore is broken. Test file restore, VM restore and bare-metal or clean-room restore where relevant. Record how DNS, credentials and routing behave when production identity services are unavailable.
Watch counters and logs
During a backup window, firewall counters should rise on expected allow rules. Unexpected denies may reveal missing dependencies or misclassified traffic. Outside the window, new attempts from user VLANs toward the backup network should be treated as suspicious until proven harmless.
Run a safe attack drill
From a test client in a normal user VLAN, verify that SMB, SSH, RDP, HTTPS admin pages and storage APIs toward the repository are blocked. From a server VLAN, verify that only documented backup agent/proxy flows work. From the admin jump host, verify that access requires the intended credentials and MFA path.
Practical takeaways
- Backup segmentation is a routing and policy problem, not only a backup-software setting.
- Separate production, backup control, repository and recovery management zones.
- Use explicit allow rules for backup flows and log denied lateral movement attempts.
- Test restore paths regularly, including identity/DNS failure assumptions.
- Start small: even a few VLANs and firewall rules are better than a flat network where ransomware can see the repository.
Post a Comment