Backup Network Segmentation Against Ransomware: Practical VLAN and Firewall Design

Backup network segmentation is one of the cheapest ways to reduce ransomware blast radius, but it is often designed too late: after the backup repository already lives in the same flat VLAN as users, servers and admin workstations. The result is predictable. If an attacker gets domain credentials or lands on a privileged desktop, the backup platform becomes just another target to encrypt, delete or silently corrupt.

This practical design guide shows a small-office, branch or small data center pattern that separates backup management, backup data and immutable/offline copies. It is intentionally vendor-neutral and fits firewalls, L3 switches or SD-WAN edges. For broader design context, see the Start Here networking topics, Data Center Networking and Resources pages.

X Follow @ipexptobe

Source: original sanitized diagram created for Network freak; inspired by common backup segmentation runbooks, not by a customer topology.

The problem: backups are reachable from the wrong places

Many environments start with a simple backup server and a NAS share. It works until the network grows. User laptops, servers, Wi-Fi clients, monitoring tools and administrators all accumulate routes to the backup repository. Sometimes the repository exports SMB or NFS broadly because it was convenient during deployment. Sometimes backup consoles are reachable from any internal subnet because the firewall rule says “LAN to LAN allow”.

Ransomware operators love that design. They do not need to break backup encryption or exploit a zero-day. They only need a path to the backup console, a service account with excessive privileges, or write access to the repository. Segmentation makes that path narrow, logged and testable.

Design: three backup zones instead of one flat subnet

A practical design uses at least three logical zones:

• Backup management VLAN: backup console, orchestration server and tightly controlled admin access. Admins reach it through a jump host, MFA and named firewall rules.
• Backup data VLAN: media server, deduplication appliance, NAS repository or storage interface used for backup traffic. It should not accept direct user access.
• Immutable or offline target: object storage with retention lock, rotated removable media, a disconnected replication target, or a hardened repository with append-only semantics.

Production servers still need to be backed up, but “can be backed up” is not the same as “can administer or delete backups”. Keep those verbs separate in the network policy.

Source: original sanitized diagram created for Network freak.

Implementation workflow

1. Inventory the real paths first

Before changing ACLs, export the current routing table, firewall rulebase and backup job inventory. Identify the backup console, repository interfaces, hypervisor integration endpoints, object storage endpoints and update URLs. If the repository has multiple NICs, map which one is used for management and which one is used for data movement.

2. Move backup interfaces into dedicated VLANs

Create separate VLANs or VRFs where possible. In a small design this may be VLAN-based segmentation on a firewall. In a data center it may be a separate VRF, tenant or L3-out policy. The goal is not complexity; the goal is a control point where policy can say “users never initiate sessions to backup storage”.

VLAN 20  Users and office clients
VLAN 40  Production servers
VLAN 70  Backup management
VLAN 71  Backup data / repository
VLAN 72  Isolated recovery sandbox

3. Replace broad LAN rules with named pinholes

Use explicit rules with comments and ticket references. Allow backup management to control backup data. Allow backup data movers to reach server agents or hypervisor APIs only on required ports. Deny users, printers, guest Wi-Fi and general office networks to backup management and repository addresses. If the backup platform needs internet access for updates or cloud/object storage, restrict it to vendor update endpoints or object storage destinations instead of “any”.

4. Separate admin identity from daily identity

Network segmentation is much stronger when backup administration does not use the same credentials as email, browsing and day-to-day endpoint work. Use privileged accounts only from the jump host, protect them with MFA, and remove interactive logon where it is not required. If a helpdesk laptop is compromised, it should not become a backup deletion workstation.

5. Add an isolated recovery sandbox

A small recovery VLAN is useful for restore testing and malware-safe investigation. Restores should be tested into this sandbox first, with limited outbound access, before moving recovered data back to production. This also gives auditors and managers a visible proof that backups are recoverable, not just “green” in a dashboard.

Verification and troubleshooting

The most common segmentation mistake is testing only the allow path. You also need to prove the deny path. From a normal user VLAN, test access to backup repository ports such as SMB, NFS, SSH, RDP and HTTPS. Those sessions should fail and should create firewall log entries you can search later.

Source: original sanitized diagram created for Network freak.

Useful checks:

• Client deny test: from a user subnet, TCP tests to backup repository ports must fail.
• Backup job test: scheduled and manual backup jobs must still complete inside the allowed window.
• Restore test: recover one file and one small VM or server object into the isolated recovery VLAN.
• Delete test: verify that normal backup operators cannot shorten retention or delete immutable copies.
• Log review: create alerts for denied access from user VLANs to backup management and repository networks.

Operational runbook

Document the design in one page: VLANs, subnets, firewall objects, allowed flows, backup service accounts, recovery contacts and break-glass steps. Keep a printed or offline copy. During a ransomware incident you may not trust normal collaboration tools, DNS, Active Directory or the production network.

For small environments, a reasonable target is simple: backups complete every night, restores are tested monthly, immutable retention is longer than the expected detection time, and repository administration is impossible from normal user networks. That is a much better security posture than a flat LAN with a large NAS share.

Practical takeaways

• Do not put backup management, backup data and user clients in the same trust zone.
• Write firewall rules as named allowlists, not broad internal-any rules.
• Test denies as carefully as successful backup jobs.
• Use immutable or offline copies so network segmentation is not the only control.
• Keep a recovery sandbox and run regular restore drills.

Backup segmentation is not glamorous, but it is one of the most practical network changes for ransomware resilience. It turns backups from “another reachable server” into a controlled recovery service.

Follow Network freak for more networking notes, diagrams and troubleshooting tips.

X @ipexptobe on X