Ransomware Network Security Guide

1. Why network design matters

Ransomware becomes significantly more damaging when a compromised workstation can communicate freely with large numbers of internal systems. Attackers can use stolen credentials and legitimate administrative protocols to discover hosts, access shares, move between systems and reach infrastructure that should never be exposed to ordinary users.

Network security therefore has two jobs: reduce the paths an attacker can use and make abnormal paths visible when they are attempted.

2. Model the network as trust zones

Start with security boundaries rather than VLAN numbers. A VLAN is useful for organising traffic, but it is not itself a security boundary if routing allows unrestricted communication between it and every other VLAN.

3. East-west traffic: the main ransomware network problem

North-south security controls protect the boundary between the organisation and the Internet. Ransomware frequently becomes an internal problem after the initial compromise, so east-west traffic between internal systems deserves equal attention.

How lateral movement uses the network

• A compromised workstation discovers other hosts.
• Stolen credentials are used against servers.
• SMB is used to access shares or administrative resources.
• RDP or other management protocols are used to reach additional systems.
• An attacker searches for management interfaces, identity systems and backup infrastructure.

Required controls

• Default-deny or tightly constrained inter-zone policy where operationally practical.
• Explicit source-to-destination rules for required applications.
• Host firewalls as an additional layer for critical systems.
• Separate management and backup paths from ordinary user traffic.
• Logging of important permitted and denied inter-zone traffic.

Engineering test: From a normal user workstation, map which internal subnets and TCP services are reachable. Compare that result with the documented business requirements. Anything reachable without a business reason is a candidate for restriction.

4. Segmentation that actually contains ransomware

Effective segmentation is more than creating VLANs. The control must prevent or restrict communication between trust zones.

Common weak design

Users, servers and management interfaces are placed in separate VLANs, but the core router permits any-to-any communication between them. The diagram looks segmented while the attacker sees a largely flat network.

Stronger design

Users can reach only required application services. Management interfaces accept connections only from administration networks. Backup systems accept only required backup traffic and administration. Critical infrastructure has explicitly defined access paths.

Controls

• Define each zone's permitted source and destination flows.
• Use firewalls or equivalent policy enforcement at meaningful trust boundaries.
• Do not rely on undocumented “temporary” allow rules.
• Review inter-zone access whenever an application changes.
• Use separate management networks where appropriate.

5. SMB security

SMB is commonly required for file services, but unrestricted SMB creates a powerful lateral-movement path. A compromised workstation does not need SMB access to every server simply because the protocol exists on the network.

How SMB becomes an attack path

• Attackers discover accessible shares.
• Compromised credentials are used against file servers or administrative shares.
• Malicious activity spreads through writable network locations.
• Large-scale file access can be used to encrypt or damage shared data.

Controls

• Permit SMB only between networks and servers that require it.
• Remove unnecessary workstation-to-workstation SMB.
• Restrict administrative shares to legitimate administration paths.
• Apply least privilege to share and NTFS permissions.
• Monitor unusual authentication and file-access patterns.
• Protect high-value shares with stronger monitoring and access controls.

Engineering test: Test SMB connectivity from each user network to each server network. The resulting matrix should contain documented business requirements rather than broad connectivity.

6. RDP and remote administration

RDP is useful for administration but dangerous when broadly reachable. The same principle applies to WinRM, SSH, remote-management agents, hypervisor consoles and device-management interfaces.

Controls

• Do not expose RDP directly to the Internet unless there is an exceptional, well-controlled requirement.
• Restrict RDP to authorised administration networks or jump hosts.
• Require strong authentication and MFA where supported by the access architecture.
• Limit which administrators can access which server groups.
• Apply network-level restrictions as well as identity controls.
• Log remote administration and investigate unexpected source systems.

Engineering test: Attempt RDP from a normal user VLAN to representative servers. The expected result should be denial unless that particular flow is explicitly required.

7. Protect management networks

Management interfaces often have more privilege than the systems they control. A compromised user endpoint should not be able to browse the management plane simply because the management interface has an IP address.

Typical management targets

• Switches and routers
• Firewalls and VPN appliances
• Hypervisors and virtualisation management
• Storage systems
• Backup platforms
• Wireless controllers and management systems
• Remote-management platforms

Controls

• Place management interfaces in a dedicated management zone.
• Permit administration only from approved administrator networks or jump hosts.
• Use dedicated privileged accounts.
• Monitor management authentication and configuration changes.
• Do not assume that an internal address is inherently trusted.

8. Protect identity infrastructure

Domain controllers and other identity systems deserve a higher trust level because compromise of identity infrastructure can turn a local endpoint compromise into an organisation-wide incident.

Controls

• Restrict which systems can communicate with domain controllers and other identity services.
• Do not permit ordinary user networks to administer identity infrastructure.
• Use dedicated administrative paths.
• Monitor authentication, privileged changes and unusual access to domain controllers.
• Protect DNS and other core infrastructure services against unnecessary access.

9. Protect backup networks

Backups should not be treated as ordinary servers. If an attacker can reach the backup platform using compromised production credentials, the network has not provided meaningful recovery isolation.

Controls

• Place backup infrastructure in a restricted security zone.
• Permit only required backup data flows.
• Restrict backup administration to dedicated management paths.
• Prevent ordinary workstation networks from directly reaching backup repositories.
• Monitor connections to backup infrastructure.
• Combine network isolation with separate credentials and protected recovery copies.

Engineering test: From a standard user subnet, attempt to reach backup management and repository services. Document every permitted connection and its business justification.

10. Firewall policy engineering

Firewall rules should express the intended communication model rather than simply making applications work.

Each rule should answer

• Who is allowed to connect?
• What destination is required?
• Which application or protocol is required?
• Which ports are required?
• Why does the flow exist?
• How is the rule logged?
• When should it be reviewed or removed?

Rules to avoid

• Any source to any destination with unrestricted internal access.
• Broad administrative protocol access between user and server zones.
• Temporary rules with no owner or expiry.
• Rules that permit entire subnets when only a small number of systems require access.

Review shadowed, redundant and overly broad rules regularly. Use the Firewall Policy Analyzer to inspect exported firewall policies.

11. DNS and network infrastructure

Core network services can become useful stepping stones if they are broadly accessible or poorly protected. DNS, DHCP, network management and infrastructure administration should therefore be included in the trust model.

• Restrict administrative access to network infrastructure.
• Monitor unexpected changes to DNS and DHCP infrastructure.
• Protect management protocols from ordinary client networks.
• Log significant administrative and configuration events.
• Maintain resilient infrastructure so containment does not remove essential services unnecessarily.

12. Monitoring the network for ransomware behaviour

Network monitoring should look for deviations from the intended communication model.

High-value signals

• A workstation contacting unusually large numbers of internal hosts.
• New SMB or RDP flows from a source that has not previously used them.
• Administrative protocols originating from ordinary user networks.
• Unexpected connections to identity or backup infrastructure.
• Large outbound transfers from systems that do not normally transfer data externally.
• Repeated denied connections followed by successful access.
• New east-west flows immediately after an unusual authentication event.

Correlation is more valuable than any individual event. For example, an unusual authentication followed by new RDP connections and access to multiple file servers provides a stronger signal than any one of those events alone.

13. Containment design

Network containment should be designed before an incident. During an attack, the team may need to isolate a workstation VLAN, server segment or compromised account quickly.

Prepare in advance

• Document which firewall or switching control can isolate each security zone.
• Define emergency rules for blocking SMB, RDP and other lateral protocols.
• Identify dependencies that must remain available during containment.
• Ensure multiple administrators understand the containment process.
• Test emergency changes in a controlled environment.

The objective is targeted containment rather than immediately disconnecting the entire organisation. Poorly planned containment can create a second outage while the security team is responding to the first.

14. Network security validation

Configuration review alone is not enough. Test the network from the perspective of a compromised endpoint.

• Perform representative connectivity tests between every trust zone.
• Verify that prohibited SMB and RDP paths are actually blocked.
• Verify management interfaces are inaccessible from ordinary user networks.
• Verify backup systems are isolated.
• Review firewall logs generated by blocked attempts.
• Test emergency containment procedures.
• Repeat testing after major network or application changes.

Implementation checklist

• Define security zones based on trust and business function.
• Map required traffic between every zone.
• Restrict east-west traffic to documented requirements.
• Remove unnecessary SMB and RDP reachability.
• Isolate management interfaces.
• Protect identity infrastructure with stronger network controls.
• Place backup systems behind a dedicated security boundary.
• Use explicit, reviewable firewall rules.
• Log important inter-zone traffic and administrative activity.
• Monitor unusual internal scanning and lateral movement.
• Document emergency containment actions.
• Test segmentation from a representative compromised-user perspective.
• Review exceptions and temporary rules regularly.