Security

Firewall Hardening Checklist for Small Business Networks

Most small business firewalls are installed once and then left alone for years. This practical, vendor-neutral checklist shows you how to harden the management plane, clean up the rule base, filter outbound traffic, segment the network and log what actually matters.

In many small businesses, the firewall was configured once during installation, then left alone while the business grew around it. New rules were added in a hurry, nobody removed the old ones, the firmware is a few versions behind and the admin page is still reachable from places it should not be. None of this is unusual, and all of it is fixable. This vendor-neutral firewall hardening checklist walks you through the controls that matter most: preparation, the management plane, rule-base hygiene, inbound and outbound policy, VPN, segmentation, zero trust principles, logging and lifecycle. It applies whether you run a small appliance or a pair of enterprise next-generation firewalls.

Before you start: inventory, backup and baseline

Hardening a firewall you do not fully understand is how outages happen. Spend the first hour on preparation:

  • Back up the current configuration and store it off the device. Confirm you know how to restore it.
  • Record the hardware model, firmware version and licenses, including when support and security subscriptions expire.
  • Inventory interfaces and zones: which networks sit behind which interface, and which are trusted, untrusted or somewhere in between.
  • Export the rule base with hit counts so you can see which rules are actually used.
  • List every published service: port forwards, VPN portals, and anything the internet can reach.
  • Agree on a maintenance window and a rollback plan with the business.

Write the results down. A current diagram and a rule inventory make every later step faster and are the foundation of the practices in the network documentation guide.

Watch out: Never remove rules on the assumption that they are unused based only on a short observation period. Some rules support monthly or quarterly processes such as payroll exports or backups to an offsite provider. Disable first, monitor, then delete.

Harden the management plane

The management plane is how administrators reach and configure the firewall. If an attacker controls it, every other control is irrelevant. Firewall and VPN management interfaces have been the target of many serious vulnerabilities, so treat this section as top priority.

  1. Disable management access from the internet on the WAN interface. If remote administration is required, reach the firewall through a VPN first.
  2. Restrict management to a dedicated management network or a short list of administrator IP addresses.
  3. Use encrypted protocols only: HTTPS (TCP 443) and SSH (TCP 22). Disable HTTP, Telnet (TCP 23) and any legacy management protocols.
  4. Change or disable default accounts, and rename the default administrator account where the platform allows it.
  5. Use individual named accounts for every administrator, never a shared login, so actions are traceable.
  6. Enable multi-factor authentication for administrative access, ideally through central authentication with RADIUS or TACACS+ tied to your directory.
  7. Apply role-based access control: read-only accounts for monitoring and help desk staff, full rights only for those who need them.
  8. Keep one local break-glass account with a long random password stored in a password vault, for when central authentication is unavailable.
  9. Set idle session timeouts and login lockout after repeated failures.
  10. Replace the self-signed management certificate with one from your internal or public CA so administrators are not trained to click through warnings.
  11. Use SNMPv3 with authentication and encryption, or disable SNMP. Remove default SNMPv1 and v2c communities such as “public.”
  12. Configure NTP from reliable sources so logs and certificates work correctly.
  13. Disable unused services on the firewall itself, such as UPnP, unused DHCP or DNS services, and unused remote access portals.

Rule-base hygiene

A firewall is only as good as its rule base. Over the years, rule bases collect “temporary” rules that became permanent, overly broad rules created to make something work quickly, and duplicates nobody dares to remove. Cleaning this up has a real security payoff and makes troubleshooting much easier.

Principles

  • Default deny. Anything not explicitly allowed is blocked. End each policy with an explicit deny rule that logs, so you can see what is being blocked.
  • Least privilege. Each rule allows only the specific source, destination and service required. Avoid “any” in more than one field of a rule, and never use any-to-any-allow.
  • Specific rules above general rules. Firewalls evaluate rules top-down and stop at the first match, so order matters.
  • Every rule has an owner and a reason. Use the description or comment field for the business purpose, the requester, a ticket number and the date.
  • Temporary rules expire. Use scheduled rules or calendar reminders, and review them on the date.

Cleanup tasks

Finding What it means Action
Zero hit count over a long period The rule may be unused Confirm with the owner, disable, monitor, then remove
Shadowed rule A rule above it already matches all its traffic, so it never matches Remove it or reorder if the intent was different
Redundant rule Duplicates the effect of another rule Consolidate into one
Overly broad rule “Any” source, destination or service where a narrower scope works Use logs to see what actually matches and narrow it
No description or owner Nobody knows why it exists Investigate, document or retire
Rules referencing old hosts Objects point at decommissioned servers or IPs Remove rules and objects; reused IPs can grant unintended access

Use named objects and groups rather than raw IP addresses. A rule that allows “ACCOUNTING-USERS” to “FILE-SERVERS” on “SMB” is easier to review than a list of addresses and port numbers, and changes become safer.

Inbound exposure, remote access and egress filtering

Reduce inbound exposure

Every service reachable from the internet is attack surface. Go through each published service and ask whether it truly needs to be public.

  • Never expose Remote Desktop (TCP 3389), SMB (TCP 445) or database ports directly to the internet. Put remote access behind a VPN with MFA or a zero trust access service.
  • Publish only what is required, to the specific internal host and port, and prefer hosting public services in a DMZ or with a hosting provider rather than on the internal network.
  • Restrict source addresses where possible. If only a partner’s network needs access, allow only that range.
  • Use geo-blocking with care. It reduces noise but is easily bypassed, so treat it as an extra layer, not a control you rely on.
  • Remember IPv6. If your firewall and ISP provide IPv6, apply equivalent inbound policy. A strict IPv4 policy with a permissive IPv6 policy is a common gap. The IPv6 for network admins guide covers what to allow, including the ICMPv6 types IPv6 needs to work.

Verify from the outside. A scan of your public address from an external host shows what the internet sees, which is often different from what you think you configured:

# Run only against addresses you own and are authorized to test
nmap -Pn -sS -p- --open 203.0.113.10
nmap -Pn -sU --top-ports 50 203.0.113.10

Harden VPN and remote access

Remote access gateways are among the most attacked devices on any network. Harden them deliberately:

  • Require MFA for every remote user, without exceptions for executives or service accounts.
  • Use modern cryptography. For IPsec, prefer IKEv2 with AES-GCM, SHA-256 or stronger, and Diffie-Hellman groups 19, 20 or 21 (or at least group 14). Disable IKEv1 aggressive mode, DES, 3DES, MD5 and DH groups 1, 2 and 5.
  • Limit what VPN users reach. Apply firewall policy to VPN traffic by user or group instead of giving every remote user access to the entire internal network.
  • Patch quickly. VPN appliance vulnerabilities are often exploited within days of disclosure. Track the CISA Known Exploited Vulnerabilities catalog and your vendor’s advisories.
  • Disable unused portals, such as a legacy web VPN you replaced years ago.
  • Review accounts: remove VPN access for leavers on the same day, and audit regularly.

Filter outbound traffic

Many small business firewalls allow all outbound traffic. That makes life easy for malware, which needs to reach command-and-control servers and move data out. You do not need a perfect allow list on day one; start with high-value restrictions:

  • DNS: allow UDP and TCP 53 outbound only from your internal resolvers or DNS filtering service. Consider blocking DNS over TLS (TCP 853) from clients, and use your platform’s options for managing DNS over HTTPS if you rely on DNS filtering.
  • SMTP: allow TCP 25 outbound only from your mail server or relay, if you have one. Workstations should never send mail directly.
  • SMB and NetBIOS: block TCP 445 and TCP/UDP 137 to 139 to the internet.
  • NTP: allow UDP 123 to your chosen time sources.
  • Servers: restrict servers to only the outbound destinations they need, such as update services. Servers browsing the internet freely is a red flag.

Segmentation and zero trust principles

A flat network, where every device can talk to every other device, lets one compromised laptop reach your servers, printers, cameras and backups. Segmentation limits that blast radius. In a small business, segmentation usually means VLANs, each mapped to a firewall zone or interface, with policy between them. The VLANs explained guide covers the switching side.

Segment Contains Typical policy
Users Staff laptops and desktops Internet access; specific server ports only
Servers File, application and directory servers Reachable from users on required ports only; limited outbound
Management Switch, firewall, AP and hypervisor management interfaces Reachable only from admin workstations or a jump host
Voice IP phones Call control and media to the PBX or cloud provider
IoT and building systems Cameras, printers, sensors, door controllers No access to users or servers; only required cloud or controller destinations
Guest Visitor devices Internet only; no internal access at all
Backup Backup servers and storage Tightly restricted; ideally pulled from, not pushed to

Applying zero trust principles

Zero trust, as described in NIST SP 800-207, is not a product you buy. It is a set of principles you can apply incrementally, even in a small network:

  • Never trust based on location. Being on the internal network or VPN should not grant broad access by itself.
  • Verify explicitly. Base access on user identity, device health and context, using identity-aware firewall rules or access proxies where available.
  • Use least privilege. Grant access to specific applications, not entire subnets.
  • Assume breach. Design segmentation and logging so a compromised device is contained and detected quickly.
Pro tip: Segment in phases. Start with guest and IoT, which are easy to isolate and carry the most risk, then separate management, then servers. Use logging rules between segments for a week before switching to deny, so you discover real dependencies before you break them.

Security services and inspection

Next-generation firewalls offer intrusion prevention, application control, URL and DNS filtering, malware scanning and TLS inspection. They add real value when they are licensed, updated and tuned:

  • Keep subscriptions active. An IPS with expired signatures provides little protection while giving a false sense of security.
  • Apply IPS to the traffic that matters most: inbound published services, traffic between users and servers, and outbound user traffic.
  • Use DNS or URL filtering to block known malicious and newly registered domains. It is one of the most cost-effective controls available.
  • Plan TLS inspection carefully. It increases visibility but requires certificate deployment, exceptions for sensitive categories such as banking and healthcare, and consideration of privacy obligations and performance.

Logging, monitoring and alerting

Logs you never read do not protect you, but logs you do not keep make incidents impossible to investigate. Aim for both:

  • Log denied traffic, allowed traffic on sensitive rules, VPN authentication, admin logins and every configuration change.
  • Send logs off the device to a syslog server or SIEM. Traditional syslog uses UDP 514; prefer TCP or syslog over TLS (TCP 6514) for reliability and confidentiality where supported.
  • Synchronize time with NTP so events correlate across devices.
  • Define retention that meets your investigative and regulatory needs.
  • Alert on high-value events: configuration changes, admin logins from unusual sources, repeated VPN failures, IPS critical events and high-availability failovers.
  • Monitor health: CPU, memory, session counts, interface errors and license expiry.

The Network Monitoring 101 guide explains how to build syslog, SNMP and alerting into a practical monitoring stack, and logs are the first place you will look when you apply the structured troubleshooting methodology to a blocked application.

Firmware, lifecycle and change management

  • Patch on a schedule and out of band for critical, actively exploited vulnerabilities.
  • Track end-of-life dates. A firewall that no longer receives security updates should be replaced, not tolerated.
  • Use high availability where downtime is costly, and test failover periodically.
  • Back up configurations automatically after every change, and store copies securely off the device.
  • Use change control: describe the change, the reason, the rollback and the verification, even if the approver is only one other person.
  • Audit annually against this checklist or a framework such as the CIS Benchmarks or NIST SP 800-41.

The checklist at a glance

Use this summary to plan the work. Priorities assume a typical small business; adjust them to your own risk and compliance requirements. Tackle the high-priority items first, since they close the paths attackers use most often, then schedule the rest as a project rather than squeezing it into a single evening.

Area Control Priority
Preparation Configuration backup, firmware and license inventory, rule export with hit counts High
Management plane No management from the internet; HTTPS and SSH only; restricted admin sources High
Management plane Named accounts, MFA, role-based access, break-glass account in a vault High
Inbound No published RDP, SMB or database ports; external scan matches intent High
Remote access MFA for every VPN user, modern IKEv2 cryptography, prompt patching High
Rule base Default deny with logging; no any-to-any rules; owner and reason on every rule High
Egress DNS only via approved resolvers; SMTP only from the mail relay; outbound SMB blocked Medium
Segmentation Guest and IoT isolated, then management, then servers Medium
Logging Off-box syslog, NTP, alerts on config changes and admin logins Medium
Security services Active subscriptions, IPS on key flows, DNS filtering Medium
Rule base Quarterly review of unused, shadowed and expired rules Ongoing
Lifecycle Patch schedule, end-of-life tracking, tested HA failover, annual audit Ongoing

Key takeaways

  • Prepare first: back up, inventory and export rule hit counts before you change anything.
  • Lock down the management plane: no internet management, MFA, named accounts, encrypted protocols only.
  • Keep a clean, documented, least-privilege rule base with default deny and logged denies.
  • Minimize inbound exposure, never publish RDP or SMB, and add egress filtering for DNS, SMTP and SMB.
  • Segment users, servers, management, IoT and guests, and apply zero trust principles incrementally.
  • Centralize logs with accurate time, alert on what matters, and keep firmware and subscriptions current.

Hardening a production firewall without breaking the business takes care and experience. The Firewall & Security Hardening service reviews your configuration against this checklist and implements the fixes safely, and the Small Business Network Setup service builds a segmented, secure network from the ground up. Have questions about your environment? Contact us.

Frequently asked questions

How often should firewall rules be reviewed?

Review the full rule base at least quarterly and after any major change, such as a new application, office or provider. Use hit counts to find unused rules, check that every rule still has an owner and a business reason, and remove temporary rules whose expiry date has passed.

Is it safe to expose RDP or the firewall admin page to the internet if I use a strong password?

No. Internet-exposed remote desktop and management interfaces are scanned constantly and are a common entry point for ransomware. Put them behind a VPN with multi-factor authentication or a zero trust access service, and restrict management to a dedicated internal network.

Do I need outbound (egress) filtering on a small business firewall?

Yes. Allowing all outbound traffic makes it easy for malware to reach command-and-control servers and exfiltrate data. Start by restricting high-risk protocols such as outbound SMB, direct SMTP from workstations and DNS to anything other than your approved resolvers, then tighten further over time.

What logs should a small business firewall keep?

At minimum, log denied traffic, allowed traffic on sensitive rules, VPN logins, administrator logins and configuration changes. Send logs to an external syslog server or SIEM with accurate NTP time so they survive a firewall failure or compromise, and keep them long enough to investigate incidents.

Does zero trust mean I can remove my firewall?

No. Zero trust is a set of principles, not a product, and it changes how you grant access rather than removing network controls. Firewalls remain essential for segmentation and enforcement, but rules become narrower, identity-aware where possible, and based on the assumption that any network may be compromised.

Keep learning

Related guides


Ready when you are

Let’s make your network faster, safer and easier to run

Tell us what you are working on — a messy rack, a flat network, an upcoming CCNA exam — and we will suggest the simplest next step.