fizzlepoof/truenas-stacks
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6659fd929fce0af9d08cfa9e80e9a648319e1241
truenas-stacks/home/doris-dashboard/docs/unifi-minimum-safe-rule-skeleton-2026-05-23.md
Fizzlepoof 462b39e572
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
Details
secret-guardrails / gitleaks (push) Has been cancelled
Details
docs: record unifi firewall enforcement and closeout
2026-05-23 02:08:15 +00:00

9.6 KiB
Raw Blame History

UniFi Minimum Safe Rule Skeleton

Purpose: convert the desired firewall design, the captured gap list, and the host-group proposal into the smallest sane live-apply rule set and exact operator order. This is still a planning artifact. It is written to minimize the chance of locking out admin access or accidentally broadening trust during first enforcement.

Evidence used:

  • home/doris-dashboard/docs/network-firewall-rule-order.md
  • home/doris-dashboard/docs/unifi-firewall-gap-list-2026-05-22.md
  • home/doris-dashboard/docs/unifi-firewall-host-group-proposal-2026-05-22.md
  • home/doris-dashboard/docs/network-migration-remaining-checklist-2026-05-22.md
  • skill guidance: unifi-network-operations

Executive summary

Do not try to apply the entire final segmentation design in one shot.

For the first real live firewall enforcement pass, the minimum safe skeleton should be:

  1. Stateful baseline
  2. Management shield with explicit admin allows first
  3. Trusted -> Servers allow
  4. Guest internet-only pair
  5. DNS/NTP minimum-function rules for restricted lanes
  6. IoT/Cameras/Legacy broad internal deny matrix
  7. Only after validation, consider helper exceptions and any Google/cast discovery carve-outs

That order preserves the management plane, keeps the trusted human lane usable, and delays the riskiest discovery-sensitive exceptions until there is proof they are needed.

1. Preconditions before any live apply

Do not start the live rule phase unless all of these are true:

  • A trusted admin session is already working from Rocinante or another confirmed operator device
  • HOST-ADMIN-TRUSTED is defined narrowly and correctly
  • HOST-CORE-SERVICES is defined
  • HOST-DNS is defined at least as 10.5.30.53
  • NET-MGMT, NET-TRUSTED, NET-SERVERS, NET-IOT, NET-GUEST, NET-CAMERAS, NET-LEGACY-CIA, and NET-RFC1918-ALL exist
  • PORT-DNS, PORT-NTP, PORT-WEB-ADMIN, and PORT-SSH exist
  • HOST-PROTECT-SERVICES is either verified or deliberately deferred
  • Google/cast pilot is still treated as unresolved; do not guess its exceptions into day-one policy
  • Legacy CIA devices remain quarantine-first; no broad trust promotion to make the rules easier

2. Object set to have ready for day-one enforcement

Must-have now

  • HOST-ADMIN-TRUSTED
  • HOST-CORE-SERVICES
  • HOST-DNS

Nice to have, but can be deferred if uncertain

  • HOST-PROTECT-SERVICES
  • HOST-IOT-HELPERS
  • HOST-CAMERA-HELPERS
  • HOST-NTP
  • HOST-LEGACY-EXCEPTIONS

Port groups to use now

  • PORT-DNS
  • PORT-NTP
  • PORT-WEB-ADMIN
  • PORT-SSH

Port groups to defer

  • PORT-PROTECT
  • PORT-CAST

3. Exact first-pass live apply order

Top-to-bottom intended live order:

Block 1: Stateful safety baseline

  1. ALLOW Established/Related

    • Why first: keeps return traffic alive once restrictive rules appear
    • Validation immediately after add:
      • current UniFi UI session remains usable
      • SSH from trusted admin box to one server still works

  2. DROP Invalid

    • Why second: low drama hygiene rule, safe to place early
    • Validation:
      • no obvious reachability loss to controller or PD

Block 2: Management shield

  1. ALLOW Trusted Admin -> Management Admin Surfaces

    • Source: HOST-ADMIN-TRUSTED
    • Destination: NET-MGMT
    • Ports: PORT-WEB-ADMIN, PORT-SSH
    • Validation:
      • load UniFi from the trusted admin box
      • SSH/ping at least one management-plane infra endpoint if applicable

  2. ALLOW Trusted Admin -> Gateway Infra Utilities

    • Source: HOST-ADMIN-TRUSTED
    • Destination: NET-MGMT
    • Ports/protocols: ICMP and only other clearly required infra utilities
    • Validation:
      • gateway reachability checks still pass from the trusted admin box

  3. DROP IoT -> Management

  4. DROP Cameras -> Management

  5. DROP Guest -> Management

  6. DROP Legacy CIA -> Management

  7. DROP Any Internal -> Management

    • Why this order: explicit admin allows must exist before the broad management shield closes
    • Validation after the full block:
      • UniFi still reachable from trusted admin box
      • no urgent household functionality unexpectedly depended on talking to Management
    • Rollback note:
      • if management reachability breaks, disable/remove rule 9 first, then 8/7/6/5 in reverse order

Block 3: Preserve the human/operator lane

  1. ALLOW Trusted -> Servers Approved Access
  • Source: NET-TRUSTED
  • Destination: NET-SERVERS
  • Day-one recommendation: allow broadly enough to preserve normal operator/admin use, then tighten later if desired
  • Validation:
    • SSH to PD, Serenity, NOMAD, and Rocinante from trusted admin device
    • key dashboards/apps reachable from Trusted
  1. ALLOW Trusted -> Cameras Admin/Viewer Access
  • Recommendation: create disabled or defer unless you already know the exact need
  • Reason: safer than inventing camera-viewer requirements blindly
  1. ALLOW Trusted -> IoT Control Exceptions
  • Recommendation: do not enable broad versions of this on day one
  • Reason: this is where cast/discovery sprawl sneaks in

4. Minimum restricted-lane function block

Apply this before the broad internal denies so the constrained lanes still have basic services.

Block 4A: DNS

  1. ALLOW IoT -> DNS
  2. ALLOW Cameras -> DNS
  3. ALLOW Legacy CIA -> DNS
  • Destination: HOST-DNS
  • Ports: PORT-DNS
  • Validation:
    • one client on each lane still resolves DNS

Block 4B: NTP

  1. ALLOW IoT -> NTP
  2. ALLOW Cameras -> NTP
  3. ALLOW Legacy CIA -> NTP
  • Destination:
    • if a real local NTP service is verified, use HOST-NTP
    • otherwise model as outbound/public NTP according to UniFi’s rule model
  • Validation:
    • no obvious time-sync failures on representative devices
  • Caution:
    • do not pretend PD is the universal NTP server unless verified

Block 4C: Internet access

  1. ALLOW Guest -> Internet
  2. ALLOW IoT -> Internet
  3. ALLOW Cameras -> Internet Updates
  4. ALLOW Legacy CIA -> Internet
  • Validation:
    • guest gets internet but not local access
    • IoT devices retain cloud/app functionality where expected
    • cameras only keep expected update/cloud behavior

5. Broad internal deny matrix

Only add this after the basic function rules above are in place.

  1. DROP Guest -> RFC1918/Internal
  2. DROP IoT -> Trusted
  3. DROP IoT -> Servers
  4. DROP IoT -> Cameras
  5. DROP Cameras -> Trusted
  6. DROP Cameras -> Servers
  7. DROP Cameras -> IoT
  8. DROP Legacy CIA -> Trusted
  9. DROP Legacy CIA -> Servers
  10. DROP Legacy CIA -> Cameras
  11. DROP Legacy CIA -> IoT

Validation after this block:

  • guest can browse internet but cannot reach local RFC1918 targets
  • IoT can still do DNS/NTP/internet, but cannot hit Trusted/Servers/Cameras except where later explicit exceptions exist
  • Cameras can still do DNS/NTP/internet or Protect-only needs if that rule has been added
  • Legacy CIA remains hospice-only and cannot laterally move inside the house

Rollback note:

  • if a constrained lane breaks in an unclear way, remove the most recent deny rule in reverse order before touching the earlier management block

6. Rules to defer on the first live pass

These are real design items, but they should not be guessed into the first enforcement wave.

Defer until verified

  • ALLOW Cameras -> Protect Services
  • ALLOW Servers -> IoT Approved Helpers
  • ALLOW IoT -> Approved Server Helpers
  • ALLOW Legacy CIA -> Approved One-Off Exception
  • ALLOW Trusted -> Cameras Admin/Viewer Access if ports/needs are unknown
  • ALLOW Trusted -> IoT Control Exceptions if it would be broad or discovery-heavy

Why defer:

  • HOST-PROTECT-SERVICES still wants verification
  • PORT-PROTECT is intentionally unresolved
  • Google/cast behavior is still pending a one-device pilot
  • helper rules are where accidental over-permissive policy usually appears

7. Suggested operator wave plan

If this becomes a real live session, the safest waves are:

Wave 1: low-drama core

  • rules 1-10 only
  • stop and validate

Wave 2: restricted-lane minimum function

  • rules 13-22
  • stop and validate

Wave 3: broad deny matrix

  • rules 23-33
  • stop and validate

Wave 4: narrow helper/protect exceptions

  • only after proof from real failures or explicit use-cases

8. Validation checklist after each wave

Minimum checks from a trusted admin endpoint:

  • UniFi UI still loads
  • SSH to PD works
  • SSH to NOMAD works
  • SSH to Serenity works
  • dashboard/homepage still loads if expected

Restricted-lane checks after waves 2 and 3:

  • one Guest client has internet and cannot reach local RFC1918 targets
  • one IoT client still has DNS/internet
  • one Camera client still behaves normally
  • one Legacy CIA client is still contained and not silently promoted by exception

9. Blunt recommendation

If doing the first live firewall enforcement pass soon, I would treat these as the true minimum safe starting set:

Definitely include:

  • rules 1-10
  • rules 13-22
  • rules 23-33

Do not force in yet unless verified:

  • rule 11
  • rule 12
  • rules involving Protect, helper hosts, or cast/discovery exceptions

That produces a real skeleton with management protection, operator reachability, guest internet-only posture, and broad quarantine behavior for IoT/Cameras/Legacy without inventing fragile discovery exceptions on day one.

10. Immediate follow-up after this planning artifact

Best non-disruptive next planning steps:

  1. verify the final intended members of HOST-ADMIN-TRUSTED
  2. decide whether HOST-PROTECT-SERVICES really equals 10.5.0.1
  3. complete the one-device Google/cast pilot before any cast/discovery exception design
  4. only then translate this ordered skeleton into exact UniFi Policy Engine objects/payloads for live apply
Reference in New Issue View Git Blame Copy Permalink