Ransomware can affect organizations of any size and industry. Firewall best practices close off many of the paths ransomware uses to get in and spread. A malicious link or download is one entry point, but ransomware can just as easily follow stolen credentials, an exposed remote service, or an unpatched system. 

Firewall configuration can help reduce your attack surface, restrict unnecessary access, inspect the traffic your platform supports, and limit lateral movement if an attacker does get in. That makes it one important layer of ransomware prevention, alongside several others. The strongest defense pairs firewall policy with endpoint protection, identity controls, patching, backups, and a tested incident-response plan.

If you manage firewall policy for an SMB network, a single overlooked rule or an exposed remote-access port can be enough to let ransomware in. This guide covers how ransomware typically reaches a network, what a firewall can and can't do about it, and 12 concrete firewall practices you can put in place to reduce your exposure. You'll also find guidance on choosing the right firewall for your environment and what to do if ransomware gets through anyway.

Why Firewall Best Practices Matter for Ransomware Prevention

Ransomware techniques keep changing, and attackers often go after the systems and data that would cause the most operational disruption if lost. Ransomware also shows up as a second-stage payload: an attacker may deploy it only after already gaining access through phishing, a stolen credential, or another technique entirely.

That's why routine firewall review matters. Policies, access rules, remote-access settings, inspection configuration, and monitoring should get revisited on an ongoing basis as your network and the threats you face change. A firewall configured well two years ago may no longer match how your team works today, especially if remote access, cloud apps, or your device count have grown since then.

Understanding how ransomware actually gets in is the first step toward choosing the right layered controls, which is where the rest of this guide starts.

How Ransomware Gets Into a Network

Defending against ransomware starts with understanding what attackers target and how they reach it. Firewall and network controls should be adjusted around your real exposure, your business requirements, and the paths an attacker could use to move from an initial compromise toward higher-value systems.

Attackers usually look for the fastest path to a high-value target, such as a domain controller, file server, or backup infrastructure. Firewall and network practices address two fronts: narrowing which systems are reachable from outside, and limiting how far an attacker can move once they're already in. The 12 practices later in this guide put both fronts into action.

Phishing, Malicious Downloads, and Web Traffic

One common path starts when someone clicks a malicious link or downloads a compromised file. That action can open the door to malware or credential theft, and it's one of several ransomware infection paths your defenses need to cover. 

Phishing defenses, DNS and URL filtering, email security, endpoint protection, and user awareness training work best together. Each one catches something the others might miss: a filtered domain here, a flagged attachment there, a user who pauses before clicking. No single control needs to catch everything on its own, which is the point.

Exposed Remote Services and Stolen Credentials

Internet-exposed remote administration, especially Remote Desktop Protocol (RDP) left open to the public internet, is one of the most consistently exploited paths into SMB networks. Attackers scan for exposed services, then use stolen or guessed credentials to get in directly, often without needing to trick anyone at all.

A few changes go a long way here. Remove remote-access exposure you don't actually need, and require VPN or zero-trust access for what remains. Restrict which source IPs can reach administrative interfaces, require multi-factor authentication (MFA) wherever it's supported, and monitor for repeated failed logins or access attempts at odd hours.

Unpatched Systems and Misconfigurations

Ransomware operators don't only rely on tricking users. They also actively scan for internet-facing vulnerabilities and weak configurations, then exploit whatever they find before a patch gets applied.

Firewall policy plays a supporting role here. Restricting exposure and inspecting traffic buys time and reduces opportunity, but closing the gap for good takes a real patching and vulnerability-management process. Blocking a port isn't the same as patching the system behind it, and treating the two as interchangeable is how gaps get missed. 

What a Firewall Can and Cannot Do Against Ransomware

Modern firewalls can help reduce ransomware risk when they're configured and maintained correctly. They can limit unnecessary exposure, enforce access rules, inspect the traffic they support, identify or block known malicious activity, log security events, and restrict movement between network segments.

No firewall prevents every ransomware attack, so treat it as one control among several rather than a standalone defense. How well it performs depends on which features are enabled, the licensing behind them, where licensing is required, the quality of the rule set, how current the software is, and how closely the logs get monitored. It works best alongside endpoint protection, multi-factor authentication, patching, backups, and an incident-response plan. 

Regular review keeps rules and security controls aligned with your current environment. A rule set that matched your network on day one can quietly fall out of step as things change.

12 Firewall Best Practices to Reduce Ransomware Risk

Each practice below addresses a different part of firewall configuration, from access rules and segmentation to logging and recovery planning. Use your business needs, risk tolerance, and available firewall features to decide which ones to prioritize first, and treat this as a working checklist you'll revisit rather than a one-time project. 

1. Start With Default-Deny and Least-Privilege Rules

Traffic should be explicitly allowed only for a documented business need. Broad, easy-to-set-up rules are exactly how firewalls accumulate risk over time. Every open rule is a door, and a door that nobody remembers opening is the one that stays open the longest.

Watch for "any-any" rules and overly broad address or service objects. These are the shortcuts that firewall configurations tend to accumulate over time, usually added to solve one problem quickly and never revisited. A short rule-review exercise, checking each rule against a real, current business justification, often turns up several that can be tightened or removed entirely.

2. Close Unnecessary Ports and Lock Down RDP

Every exposed service is a larger attack surface, whether or not it's actively being used. Review port-forwarding rules for services nobody remembers setting up, and remove inbound rules that no longer match how the network is actually used.

RDP deserves particular attention. Restrict it wherever possible, and prefer a controlled remote-access method, like a VPN or a managed remote-access tool, over exposing it directly to the internet. If RDP access is genuinely required, lock it down with MFA and IP restrictions. 

3. Segment the Network to Limit Lateral Movement

Splitting your network into zones or VLANs (virtual local area networks), with firewall policy controlling what moves between them, limits how far an attacker can travel after an initial compromise. Separating users, servers, IoT devices, guest traffic, and management systems means a compromised laptop doesn't automatically have a path to your backup server.

Segmentation's job is damage control, not prevention: it reduces the blast radius once an infection happens, which is often the difference between an isolated incident and an organization-wide outage. 

4. Apply Intrusion Prevention and Threat Inspection to Allowed Traffic

An allowed rule shouldn't automatically mean uninspected traffic. Intrusion prevention, malware inspection, and application or security profiles add a layer of scrutiny to traffic that's already been permitted through the firewall.

Feature availability here depends on your platform, your software version, and your licensing. Confirm what's actually enabled on your firewall; don't assume every security feature is active by default. A feature that exists on the platform but isn't turned on or licensed isn't protecting anything.

5. Inspect Encrypted Traffic Where It Is Appropriate

Malicious traffic increasingly travels over HTTPS and Transport Layer Security (TLS) connections, so traffic that looks encrypted and routine can still be carrying a threat. Decrypting and inspecting that traffic can improve visibility into what's actually moving across your network.

It also comes with real tradeoffs: privacy considerations, certificate management overhead, application compatibility issues, and a performance cost. Decrypting everything by default isn't the right call for every organization. Weigh the security benefit against those tradeoffs, and plan for exceptions where inspection genuinely isn't appropriate.

6. Use DNS and URL Filtering to Block Risky Destinations

DNS and web filtering can block connections to known malicious or unwanted destinations before a connection ever completes, which stops some threats before they reach the inspection stage at all. That includes command-and-control domains, phishing sites, and known malware-hosting infrastructure.

Filtering quality depends on current threat intelligence and how the policy is configured. Treat it as one part of a layered approach, alongside the other controls in this guide.

7. Monitor and Restrict Outbound Traffic

Most firewall attention goes toward what's allowed in, but outbound traffic deserves the same scrutiny. Unusual outbound connections can be a sign of command-and-control activity or data exfiltration already in progress.

Restrict which DNS resolvers your network is allowed to use, apply destination restrictions where practical, and set up alerting for outbound behavior that doesn't match your normal traffic patterns. Catching unexpected outbound activity early is often what turns a contained incident into one that gets caught before real damage happens.

8. Harden Firewall Administration and Require MFA Where Supported

The firewall's own management plane needs the same protection as everything it's defending. Restrict administrative access to specific, trusted sources, use secure management protocols, and keep admin accounts separate from everyday user accounts.

Apply role-based access so administrators only have the permissions their role actually requires, and require multi-factor authentication wherever your platform supports it. Confirm what your specific model and license actually support before assuming MFA is available. Not every platform or license tier includes it by default.

9. Keep Firmware, Security Engines, and Signatures Current

Firewall software and the threat-detection components running on it need timely updates to stay effective against current threats. An outdated signature set can miss threats that a current one would catch immediately.

Review vendor security advisories on a regular basis, follow a change-control process for applying updates, and confirm updates installed correctly. "Always auto-update everything" sounds simple, but knowing what changed and confirming it worked is what actually keeps you protected.

10. Centralize Logging, Monitoring, and Alerting

Certain events matter more than others: denied connections, administrative changes, threat detections, repeated remote-access failures, unusual outbound connections, and policy changes all deserve attention when they show up in your logs.

Centralizing that logging, with accurate time synchronization across devices, makes patterns easier to spot and easier to investigate after the fact. Set log retention based on what your organization actually needs for investigation and reporting; the vendor default is rarely the right fit for every environment.

11. Review Firewall Rules on a Defined Schedule

A repeatable rule-review process catches problems that accumulate slowly: identify who owns each rule and why it exists, look for stale or duplicate entries, verify that temporary exceptions haven't quietly become permanent, and confirm that address and service objects still reflect reality.

There's no single review frequency that fits every network. How often you review should reflect how quickly your environment changes and how much risk a stale rule set represents for your organization. Document what changes and why, so the next review starts from a clear record instead of guesswork.

12. Back Up Firewall Configurations and Test Recovery

A current, protected backup of your firewall configuration, paired with a tested restoration process, matters most during an outage or an active incident, exactly when you have the least time to figure it out from scratch.

Keep this separate from your ransomware data backups. Both matter, and each protects something different. Document configuration changes as you make them, and test your restoration process periodically instead of discovering it doesn't work in the middle of an actual incident.

Firewall Rules and Ports to Review for Ransomware Risk

Beyond the 12 practices above, it helps to look at your firewall rule set through the lens of specific services and ports that ransomware operators commonly target. This isn't about handing you a universal list of ports to block. Every network is different, and a port that's safe to close on one network may be a business-critical dependency on another.

Instead, review your rules by purpose. Look closely at remote administration services (RDP and similar), file-sharing protocols like SMB (Server Message Block), any inbound service that isn't clearly tied to a current business need, outbound DNS traffic that bypasses your approved resolvers, and vendor or third-party management access that's been left in place longer than intended.

Before you block or restrict anything, confirm what depends on it. A port or service that looks unnecessary from a firewall log can still be supporting something your team relies on daily. Treat this as an ongoing review-and-confirm exercise, not a project you finish once.

How Network Segmentation Limits Ransomware Lateral Movement

Segmentation is one of the practices above, but it's worth walking through in more detail because of how directly it affects ransomware's ability to spread once it's inside your network. A practical SMB setup typically separates user devices, servers, guest Wi-Fi, IoT devices, and management systems into their own segments, with firewall policy controlling what can pass between them.

Traffic between segments should only flow where there's a real need for it, and that traffic should be inspected or logged according to your policy. A user segment that needs to reach a specific application server doesn't need open access to your entire server segment, and a guest network almost never needs a path to internal systems at all.

The operational benefit shows up when something goes wrong: a compromised endpoint in the user segment shouldn't have an unrestricted path to your servers or your backup systems. That containment is often what separates a single infected laptop from a ransomware incident that takes down the whole network.

Ransomware Prevention Beyond the Firewall

A firewall handles network-level access and inspection, but ransomware prevention depends on several other layers working alongside it. Multi-factor authentication and identity controls close off the credential-based paths a firewall alone can't fully address, since a stolen password used through a legitimate login doesn't look like a firewall violation.

Endpoint detection and protection catch threats that reach a device directly, whether through a download, a USB drive, or an already-compromised connection. Patching and vulnerability management close the gaps that ransomware operators actively scan for, and email security filters out a large share of the phishing attempts that lead to ransomware in the first place. Least-privilege access limits what any single compromised account can reach, which matters as much on the identity side as it does on the network side.

Backups deserve special attention. Offline or otherwise protected backups, kept separate from your primary network, are often the difference between a disruptive incident and a business-ending one. A backup that ransomware can reach and encrypt alongside your production data doesn't function as a backup at all. Test your recovery process on a regular schedule, since a backup that has never been restored is only a plan on paper. 

Security awareness training rounds this out. Firewalls, endpoint tools, and backups all reduce risk, but a workforce that recognizes a phishing attempt before it's clicked stops the incident before any of those other layers need to activate.

For a closer look at how one of these layers works, Cisco Umbrella adds cloud-delivered DNS-layer security and threat intelligence that complements firewall-based filtering, particularly for teams supporting remote or distributed users.

What to Do When Ransomware Is Detected

If ransomware is detected on your network, the immediate priority is containment. Isolate affected systems from the network as quickly as possible to limit how far the infection can spread, and preserve logs and other evidence rather than restarting or wiping affected systems right away.

Engage the internal or external responders your plan calls for, and follow your organization's reporting procedures, which may include legal, regulatory, or insurance obligations depending on your industry and location. This guide covers the operational sequence, not legal guidance, so consult legal counsel for anything related to disclosure, reporting, or breach notification. Whether to pay a ransom is a decision that depends on factors specific to each incident, including guidance from law enforcement and your legal counsel, and shouldn't be treated as a blanket policy decided in advance.

Recovery starts once the incident is contained. Restore affected systems from a backup you've verified is clean. Ransomware sometimes sits undetected for days or weeks before it executes, so the most recent backup isn't automatically the safest one to restore from. Bring systems back online in stages, and confirm each one is clear before reconnecting it to the network.

Once operations are stable, run a post-incident review. Confirm how the attacker got in, close that specific gap, and update the firewall rules, monitoring, and access controls that let it happen. Skipping this step is how the same attack path gets used twice.

Firewall Best Practices Checklist

Here's the quick version of what to review. The goal is to reduce unnecessary exposure, limit the paths ransomware can use to move through the network, and make suspicious activity easier to detect.

• Start with default-deny and least-privilege rules.

• Close unnecessary ports and remove direct internet exposure for remote administration where it isn't required.

• Segment users, servers, guest devices, IoT, backups, and management networks based on business need.

• Apply intrusion prevention and threat inspection to permitted traffic where the platform supports it.

• Inspect encrypted traffic where the security benefit justifies the operational and privacy tradeoffs.

• Use DNS and URL filtering to reduce connections to known malicious or unwanted destinations.

• Control outbound traffic and monitor unexpected external connections.

• Restrict firewall administration, use separate admin accounts, and require MFA where supported.

• Keep firewall software, security engines, and threat signatures current.

• Centralize logging and alerting for policy changes, detections, failed access attempts, and unusual traffic.

• Review firewall rules on a defined schedule and remove stale, duplicate, or overly broad entries.

• Back up firewall configurations and test restoration as part of recovery planning.

Choosing a Firewall for an SMB Ransomware Prevention Strategy

Everything above assumes your firewall can actually support the practices it covers, and that's worth checking before you invest more time refining policy on hardware that's already stretched thin. Size a firewall around your actual throughput needs, whether you plan to inspect encrypted traffic, how many VPN connections you run, your site count, and your user and device count.

Also factor in high-availability requirements if downtime is costly for your business, your logging and management needs, and which security services you actually plan to enable. A spec sheet lists what's possible; your rollout plan determines what's real. Avoid generic "future-proof" claims when comparing options, and don't rely on performance numbers without checking current manufacturer documentation, since real-world throughput often looks different once encryption inspection and security services are switched on.

Hummingbird Networks' firewall category is a reasonable place to start comparing current options across Cisco, Meraki, Fortinet, Sophos, and other manufacturers side by side.

Cisco Secure Firewall or Meraki MX: Which Management Model Fits Your Team?

Both Cisco and Meraki are strong options, and the right one usually comes down to how your team wants to manage security, not just which brand you already use elsewhere. Cisco Secure Firewall tends to fit teams that need deeper policy control and dedicated security operations work, where a network engineer wants granular visibility into rules and inspection settings.

Meraki MX tends to fit cloud-managed branch and distributed environments, where centralized administration across multiple sites is the priority and a smaller team needs to manage security without deep day-to-day tuning. Treat this as a general starting point for your own evaluation, since team structure and priorities vary.

Confirm current model availability, security features, throughput, and license requirements with Hummingbird Networks before deciding, since advanced features on either platform may require the appropriate active license and shouldn't be assumed to be included by default.

Compare firewall options for your network. Whether you're evaluating Cisco Secure Firewall, Meraki MX, or another platform, Hummingbird Networks can help you compare options based on your network size, management model, security requirements, throughput, and licensing.