TL;DR

If you only have one week, focus on perimeter hygiene: remove risky firewall rules, harden every VPN path, and separate internet-facing services from your main LAN with a simple DMZ pattern. For many SMBs, this is a high-impact, low-complexity move that can reduce exposure immediately while staying within a realistic budget. The practical target is to implement a deny-first firewall posture, strict VPN controls, and controlled remote access using NGFW/pfSense plus identity-aware access layers like Cloudflare Tunnel or Tailscale.

Why this week is the best week to audit your perimeter

Most SMB breaches are not because your security stack was absent; they happened because existing controls were misconfigured. A perimeter hardening week is practical because you can measure and improve real controls without rewriting your entire business systems: clean the rules, lock in VPN behavior, and move internet-facing services behind explicit boundaries.

This is also a business continuity exercise. Most SMB disruptions from ransomware or extortion start with exposed management ports, VPN over-permissioning, and single flat networks. By mapping defenses to practical controls in the ASD Essential Eight and NIST SP 800-41 firewall guidance, you can reduce the most common attack paths while keeping operations stable.

1) Do a strict firewall rule audit first (this is the highest ROI change)

A clean rule set is the foundation of perimeter defence. Many SMBs run with 30+ rules where 70% are old, duplicated, or no longer tied to active services. If you cannot answer “who can use this rule, from where, and why”, remove it or quarantine it before buying new gear.

Practical steps for this week:

  1. Export and snapshot your current firewall policy before editing.
    This gives rollback safety and a baseline for evidence. For managed gear (FortiGate) export policy; for pfSense export firewall rules and NAT rules. Keep copies in change control.

  2. Start with an explicit default-deny model and then allow only necessary traffic.
    The classic mistake is “allow anything to something on the same subnet” because it was easy to troubleshoot years ago. Instead, require all inbound and management traffic to be explicitly allowed by destination, source, and service.

  3. Prioritise cleanup by risk score:

    • Critical: Any/Any inbound/outbound rules, especially on WAN.
    • High risk: WAN exposure of remote management (admin GUIs, SSH, RDP, VNC, WinRM, SMB).
    • Medium risk: rules with old temporary exception comments like “vendor vpn fix” or “temporary access”.
    • Low risk: service-specific legacy allow rules no longer used.

  4. Apply the “deny by default + review by purpose” method.
    For each allow rule, record:

    • business owner,
    • required ports,
    • source IPs/user group,
    • allowed times (if possible),
    • expiry date.

  5. Eliminate rule shadowing and overlaps.
    Overlapping rules hide weaker controls behind broad ones. Remove general rules first, then replace with precise rules.

  6. Force logging on all accept rules near the border.
    Logging every allowed/blocked high-value protocol (eg, VPN, RDP, admin ports) gives visibility for threat hunting and audits.

Common misconfigurations to fix now

  • WAN access to web admin ports from internet.
  • SMB/NetBIOS services exposed outside the LAN.
  • Legacy protocol allow rules still active (FTP, Telnet, outdated SSH versions).
  • “Permit any to any” for troubleshooting that never gets removed.
  • Outbound rules that permit every destination and make data exfiltration monitoring impossible.

2) Harden VPN posture this week (do this before expanding access)

Most SMB remote access “works” but many are still over-privileged, weakly protected tunnels. Attackers increasingly target VPN endpoints first, then pivot into file shares, RMM tools, and finance systems.

Hardening sequence

  1. Retire split tunneling where practical.
    If your users can route local and corporate traffic separately through weak Wi‑Fi, assume credential leakage risk is higher. Route admin and business-critical services through VPN (full tunnel) where performance allows.

  2. Enforce MFA and least privilege on VPN identities.
    At minimum, MFA on every interactive admin and privileged remote user account. Restrict groups to exactly the resources needed.

  3. Disable legacy VPN authentication mechanisms.
    Replace pre-shared keys and password-only remote access where possible. Move to certificate-based or identity-integrated authentication patterns.

  4. Constrain VPN client access by network object not “any”.
    Build per-role groups: finance, support, sales, contractors. Don’t reuse one all-access profile.

  5. Enforce session limits and logs.

    • Idle timeouts for remote users.
    • Max concurrent sessions.
    • Connection logs retained for review.

Tool-specific practical paths

  • FortiGate (NGFW): use built-in VPN profiles with robust TLS ciphers, MFA integration, and role-based firewall policies.
  • pfSense: use strong server certificate handling, firewall rules tied to user groups where possible, and explicit DNS/reverse DNS controls.
  • Cloudflare Tunnel: for public app access, remove inbound firewall exposure by replacing inbound port publish with identity-based tunnels and access policy controls.
  • Tailscale: for remote office/contractor access, use tag-based ACLs and machine identity policies; prevent broad subnet-routers unless truly needed.

3) Add a real DMZ pattern so internet-facing systems stop sitting on the same network

A DMZ is not a separate luxury — it is a practical boundary that prevents one breach from exposing all internal workloads. SMB owners often skip this because they think it is complex; but a minimal two-interface model is enough for most environments.

Minimal practical DMZ architecture for this week

  • Put internet-facing services (web, mail relay, VPN gateway, remote helpdesk tools, public-facing APIs) in a dedicated DMZ segment.
  • Keep file servers, domain controllers, ERP, accounting servers, and workstations on internal LAN segment(s).
  • Use firewall rules that only allow:
    • inbound from WAN to DMZ on strictly required service ports,
    • controlled outbound from DMZ to internal systems only when required (eg, app DB with specific IP and port only).
  • Deny direct inbound from WAN to LAN entirely.
  • Add monitoring for all denied attempts to DMZ/LAN boundary.

“This week” DMZ implementation choices

  1. Cloud-native/hosted services + tunnel first: if a full on-prem DMZ is too heavy, publish apps through Cloudflare Tunnel and leave internal services inaccessible from internet altogether.
  2. Small on-prem shop with few services: use pfSense VLAN/firewall policy to create a DMZ subnet and move one service at a time.
  3. Higher security need / branch offices: use FortiGate NGFW with separate security zones and strict interzone policies.

4) Choose tooling by budget and maturity: what to spend this quarter

Perimeter posture is not all-or-nothing; SMB budgets vary. For most owners, the useful strategy is a staged plan:

Estimated SMB deployment costs (hardware/software + initial implementation)

  • $500–$1,200: pfSense on modest hardware, Cloudflare Tunnel for inbound publishing, and hardening/cleanup effort (DIY or modest consultant hour bundle).
  • $1,500–$3,000: Managed pfSense/NGFW-style deployment with ACL cleanup, logging baseline, and 1–2 policy reviews.
  • $3,000–$5,000: FortiGate SMB deployment with stronger UTM features, managed onboarding, periodic tuning, and ongoing monthly support (annual licensing not included).

A practical rule: if you have more than 30 internet-facing services and regulatory pressure, the NGFW path usually pays off faster because it gives stronger policy visibility and unified inspection. If your stack is small and you have capable internal IT skills, pfSense + hardening plus Cloudflare/Tailscale can be very cost-effective.

Quick-win checklist: 48-hour firewall + VPN inspection

Use this as your one-week execution sheet:

Firewall rule audit (30–60 minutes)

  • Export current rule set and save a backup.
  • Remove/comment out all allow any any inbound/outbound rules after justification review.
  • Restrict management interfaces to trusted source IPs (or separate VPN-only management).
  • Remove stale/static NAT mappings no longer tied to active systems.
  • Add logging for critical accepted flows and all blocked WAN ingress.
  • Verify no internal servers are directly published to WAN without a reverse proxy/Tunnel layer.

VPN posture checks (30–45 minutes)

  • Enforce MFA on all VPN identities.
  • Verify split tunneling policy is documented and restricted.
  • Validate that default user VPN groups are not privileged.
  • Disable legacy VPN protocols/ciphers where possible.
  • Confirm periodic key/cert rotation and session expiry exists.
  • Test from remote location with low-privilege account before end-user rollout.

DMZ sanity checks (20 minutes)

  • Confirm public-facing systems are no longer in the same subnet as file/finance systems.
  • Confirm ingress to DMZ is explicit by service and source.
  • Confirm no unsolicited WAN→LAN rule bypass exists.
  • Confirm monitoring alerts on denied edge activity are enabled.

These checks should be linked to a simple change record so leadership can see “what changed, why, and who approved it,” which also supports governance expectations.

FAQ

If you have modest internet exposure and staff size, a disciplined pfSense deployment with strict policies can be enough. If you want integrated threat detection, advanced IPS signatures, and easier centralized policy analytics at scale, an NGFW such as FortiGate may be the better long-term baseline.

No. Cloudflare Tunnel is excellent for reducing inbound exposure by removing direct inbound ports, but it is not automatically equivalent to full-site VPN behavior for all admin workflows. Use it for publishing services and pair it with appropriate remote access tooling for full internal access if needed.

A basic functional DMZ can be done in a staged sprint: isolate one public service first (usually web or remote entry points), test it, then move remaining internet-facing systems. The critical part is policy order: start with least privilege and enforce that before moving hardware around.

ASD Essential Eight supports reducing exploitation paths by hardening admin access, patching, multi-factor, and segmenting exposures. NIST SP 800-41 provides firewall policy and placement guidance for robust boundary control; your weekly tasks directly implement that principle by moving from permissive defaults to explicit controls and segmentation.

Conclusion

A perimeter defence audit does not need to be a six-month project. In one week, most SMBs can remove the highest-risk firewall and VPN exposures, deploy practical segmentation through a small DMZ model, and introduce stronger identity-aware access without breaking daily operations. Do this in the order above: firewall baseline → VPN hardening → DMZ isolation → evidence and review.

If you want this done with technical confidence and governance-safe evidence, start with a qualified triage at https://lil.business/book/. We’ll begin with authority verification, scoped evidence review, and trust assurance planning, and we will not request credentials, tenant access, active scanning, or live-system testing until a signed scope, access verification, and explicit rules of engagement are in place.

References

  1. ASD Essential Eight - Australian Cyber Security Centre
  2. NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy
  3. Cloudflare Tunnel documentation
  4. pfSense Firewall Manual
  5. Tailscale Security and Access Controls

Need to prove security trust?

Start with qualified triage. We verify authority, minimise access, define scope, and focus on evidence that helps with insurers, customers, tenders, boards, auditors, and AI governance reviewers.

Start Qualified Triage