A firewall can block some ransomware-related traffic, but it cannot stop every ransomware attack on its own. It can restrict exposed services, malicious destinations and movement between controlled network zones. Intrusion prevention and inspection may block additional threats. Local file encryption, compromised identities and activity outside its traffic path need other controls, including endpoint protection, MFA and tested, protected backups.
In this briefing
- 01Placement matters: a firewall can enforce a boundary only when the relevant traffic passes through it.
- 02An allowed port or a successful login does not establish that the activity is safe.
- 03Encryption can continue on an infected device even if its internet access is blocked.
- 04Segmentation, endpoint controls and recovery planning cover different parts of the risk.
What a firewall can stop
A firewall controls network traffic according to policy. Network firewalls sit between networks or zones; host firewalls apply rules on individual devices. A basic stateful firewall tracks connections and applies rules using details such as addresses, ports and connection state. It does not automatically inspect every file or decide whether a signed-in user is trustworthy. [1]
Unnecessary remote access
Blocking direct internet access to RDP or SMB removes a route an attacker could use. If remote access is necessary, restrict it to approved paths and users, add strong authentication and patch the access service. A rule allowing every source is a much wider doorway.
Some exploit attempts
An intrusion prevention system (IPS), often integrated with a next-generation firewall, can detect and block recognised attack patterns in traffic it can inspect. That is useful protection, but signatures, configuration and visibility all matter. IPS does not repair the vulnerable application.
Malicious destinations
Egress filtering limits connections leaving a device or network. Reputation, DNS or URL filtering can block known malicious destinations where those features are deployed. A new destination or an abused legitimate service may still evade a rule, so investigate unusual outbound activity.
Unnecessary lateral movement
Internal firewalls and host rules can deny connections from a compromised laptop to systems it does not need. Segmentation creates those controlled boundaries. A perimeter-only rule cannot govern traffic that stays within the same unrestricted internal network.
The NCSC's ransomware guidance recommends hardening remote access, patching devices and using both host and network firewalls. These controls work alongside measures that prevent malicious code from running. [2]
Where the firewall's view ends
Email and legitimate-looking access
A network firewall is not an email inbox scanner. Email-security services may filter messages or attachments, and a security gateway may block a malicious link or download. Those capabilities can reduce phishing risk; they do not mean a basic firewall understands the meaning of every message. Someone can also be tricked into granting access without downloading ransomware.
A stolen account may authenticate successfully. Some firewall products can use identity context to narrow access, but a permitted connection does not prove the person behind it is legitimate. Use phishing-resistant MFA where available, least privilege and monitoring of account behaviour. Our passkeys and authenticator apps comparison explains the difference between stronger sign-in and a transferable one-time code.
Local encryption and traffic that bypasses it
Encrypting a file already accessible on an infected laptop is a local operation. A network firewall does not watch every file write. Ransomware that already has the code and key material it needs can keep encrypting without a live connection to an external server. Blocking command-and-control traffic can disrupt some attacks, but cannot guarantee that encryption stops.
Network activity can still reveal part of the incident. An attacker may contact command infrastructure, copy files over a share or attempt to reach another device. Microsoft documents network-protection capabilities that detect and block ransomware-related command-and-control connections. That capability complements endpoint detection; it does not make every file operation visible at the network boundary. [3]
Which control sees each stage?
The answer depends on the traffic route and the features actually enabled. Treat an NGFW label as a starting point for checking capabilities, not a guarantee that every listed inspection service is active.
| Attack activity | Firewall contribution | Other protection needed |
|---|---|---|
| Phishing message | Email or web filtering may help when provided by an integrated service. Basic traffic rules do not assess the message itself. | Email security, safe handling of requests and identity protection. |
| Exposed RDP or SMB | Block unneeded access, narrow approved sources and log attempts. | Secure remote access, MFA, patching and account controls. |
| Exploit against a reachable service | IPS may block a recognised exploit in inspectable traffic. | Vulnerability remediation and reduced exposure. |
| Use of a stolen account | Restrict reachable services and, where supported, apply identity-aware policy. | Strong authentication, least privilege and identity monitoring. |
| Movement to another device | Internal or host rules can deny connections that cross the enforced boundary. | Segmentation, endpoint detection and protected administration. |
| Local file encryption | No direct inspection of local file writes by a network firewall. | Endpoint prevention and response, restricted file access and recovery. |
| Command traffic or data leaving | Outbound policy and threat filtering may block or expose suspicious connections. | Endpoint, identity and data monitoring, plus incident response. |
Does TLS inspection close the gap?
HTTPS encrypts application content in transit. A basic firewall can still enforce address, port and connection rules, but cannot read the encrypted payload simply because the connection uses port 443. Supported inspection services may decrypt selected traffic, inspect it and re-encrypt it before forwarding. Other filtering can use information available without decrypting the content.
Decryption needs an approved design. Certificate handling, privacy requirements, application compatibility and appliance capacity affect what can safely be inspected. Certificate pinning or client authentication can prevent proxy decryption of some sessions. Test changes and document justified exceptions. Turning on TLS inspection everywhere is not a reliable one-step ransomware fix. [5]
If you are comparing products, ask which traffic will traverse the appliance, which inspection services are included and how the policy is tested. An expensive device running permissive rules can still leave important paths open.
What closes the remaining gaps?
Start with the services, accounts and data that matter to the business. Reduce unnecessary exposure, then choose controls for the routes an attacker could still use. The small-business security priorities guide helps put those decisions in context.

- Protect endpointsUse maintained endpoint protection and detection capabilities, restrict unnecessary software execution and respond to suspicious activity. These controls can observe behaviour on the device that a network firewall cannot directly see.
- Secure identitiesGive accounts only the access they need. Protect remote and administrative access with strong authentication, monitor unusual use and remove access that is no longer required.
- Enforce boundariesSeparate users, servers and recovery infrastructure according to business need. Test which connections really work. See what network segmentation means before treating a VLAN name as an enforced security boundary.
- Prepare recoveryMaintain offline or appropriately isolated, protected backups and test restoration. Backups do not prevent stolen data from being exposed. A recovery plan must also deal with the attacker's access and the systems that were compromised.
- Rehearse responseFollow an approved incident plan to assess the evidence, contain affected systems and restore trusted services. Network isolation can interrupt real work, so agree authority and critical-service priorities before an incident.
CISA's #StopRansomware Guide combines prevention, detection, containment and recovery guidance. No single firewall setting replaces that preparation. [6]
Practise the defensive decisions
Explore the themes through DirtyPhish's games. These are learning games, not security tools or substitutes for testing a real network.
Questions people ask
Can a firewall stop ransomware on its own?
No. It can block some delivery, command-and-control and lateral-movement traffic when that traffic crosses an enforced rule. It cannot guarantee that a device stays uninfected or stop every local encryption event.
Does a next-generation firewall guarantee ransomware protection?
No. Intrusion prevention, filtering and inspection add opportunities to detect or block traffic. Results depend on placement, policy, enabled features, updates and traffic visibility. Endpoint, identity and recovery controls remain necessary.
Can ransomware encrypt files without an internet connection?
Yes. Ransomware that already has the code and key material it needs can encrypt accessible files without contacting an external server. Blocking outbound traffic does not guarantee that local encryption stops.
Can a firewall help after an attacker is inside the network?
Yes. Internal segmentation firewalls and host firewalls can restrict reachable services and lateral movement. A perimeter firewall cannot inspect an internal connection that never passes through it.
Should I enable TLS inspection everywhere?
No blanket rule is appropriate. Assess authorisation, privacy, certificate handling, application compatibility and appliance capacity. Deploy and test an approved policy, with justified exceptions, rather than decrypting every connection indiscriminately.
Are backups enough to protect against ransomware?
Backups support recovery but do not prevent initial access or data theft. Keep protected copies separate from ordinary access and test restoration. Recovery must also address the attacker's access and persistence.
Sources and further reading
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy. Foundational guidance published in 2009, used here for firewall concepts, not current threat statistics.
- UK NCSC: Mitigating malware and ransomware attacks.
- Microsoft: Network protection and command-and-control blocking. Product-specific capabilities are not features of every firewall.
- CrowdStrike: 2026 Global Threat Report findings. Breakout statistics refer to its 2025 eCrime observations.
- Palo Alto Networks: Decryption basics and decryption profiles and limitations. Vendor documentation illustrates implementation details.
- CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide.
General educational guidance. Changes to production firewall rules, inspection and isolation should follow your organisation's authorised change and incident-response processes.

CONTAINMENT STRATEGY
CYBER ARCADE
SECURITY KNOWLEDGE