fizzlepoof/truenas-stacks
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ab348932ff8ccffdc80d2fb2a47e1873aa6778ac
truenas-stacks/home/doris-dashboard/docs/network-firewall-rule-order.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

12 KiB
Raw Blame History

Home Network Redesign Firewall Rule Order

For Doris: this is the intended UniFi firewall ordering for the redesign. Use groups/comments so every rule is explainable at 2 AM.

Goal: enforce clean segmentation between Management, Trusted, Servers, IoT, Guest, Cameras, and Legacy CIA quarantine without using broad lazy exceptions.

Assumptions:

  • Current live networks:
    • Management -> 10.5.0.0/24
    • Trusted -> 10.5.1.0/24
    • IoT -> 10.5.10.0/24
    • Cameras -> 10.5.20.0/24
    • Servers -> 10.5.30.0/24
    • Guest -> 10.5.90.0/24
    • Legacy CIA quarantine -> 192.168.1.0/24 retained temporarily
  • Use address/object groups where UniFi allows them.
  • Apply stateful best practice first: established/related before policy rules.
  • Specific allows always go above broad denies.

1. Object / Group Inventory To Create First

Create these objects before writing rules:

Network groups

  • NET-MGMT
  • NET-TRUSTED
  • NET-SERVERS
  • NET-IOT
  • NET-GUEST
  • NET-CAMERAS
  • NET-LEGACY-CIA
  • NET-RFC1918-ALL = all internal subnets above plus any other local internal ranges

Device / host groups

  • HOST-ADMIN-TRUSTED
    • your main laptop
    • your phone/tablet if you really need admin from it
  • HOST-CORE-SERVICES
    • PD
    • Serenity
    • Nomad
    • Rocinante
    • any controller/helper hosts
  • HOST-PROTECT-SERVICES
    • NVR / Protect endpoints if separate from above
  • HOST-DNS
    • whichever DNS resolvers clients should use
  • HOST-NTP
    • if you use local NTP, otherwise this can be omitted
  • HOST-IOT-HELPERS
    • only services IoT devices are explicitly allowed to hit
  • HOST-CAMERA-HELPERS
    • only services Cameras are explicitly allowed to hit
  • HOST-LEGACY-EXCEPTIONS
    • only for ugly one-off CIA quarantine exceptions

Port groups

  • PORT-DNS = 53 TCP/UDP
  • PORT-DHCP = 67-68 UDP
  • PORT-NTP = 123 UDP
  • PORT-WEB-ADMIN = 80,443,8443,9443 or whatever you actually use
  • PORT-SSH = 22
  • PORT-PROTECT = exact ports only if needed
  • PORT-MDNS = 5353 UDP
  • PORT-CAST = exact discovery/control ports if later proven necessary

2. Rule Philosophy

  • Trusted is the only lane that gets routine admin rights.
  • Management is infrastructure-only and should accept traffic only from explicit admin initiators.
  • Servers accept specific human/service traffic from Trusted and tightly scoped helper traffic from IoT/Cameras.
  • IoT, Cameras, and Legacy CIA are default-deny internally.
  • Guest is internet-only.
  • Legacy CIA is hospice, not production.

3. Recommended Rule Order

This is ordered top to bottom.

Section A: Core state handling

  1. ALLOW Established/Related

    • Action: Allow
    • States: Established, Related
    • Source: Any
    • Destination: Any
    • Comment: baseline stateful return traffic

  2. DROP Invalid

    • Action: Drop
    • States: Invalid
    • Source: Any
    • Destination: Any
    • Comment: drop broken/invalid sessions early

Section B: Management protection

  1. ALLOW Trusted Admin -> Management Admin Surfaces

    • Action: Allow
    • Source: HOST-ADMIN-TRUSTED
    • Destination: NET-MGMT
    • Ports: PORT-WEB-ADMIN, PORT-SSH and anything truly required
    • Comment: explicit admin to management

  2. ALLOW Trusted Admin -> Gateway Infra Utilities

    • Action: Allow
    • Source: HOST-ADMIN-TRUSTED
    • Destination: NET-MGMT
    • Ports: ICMP plus other explicitly needed management utilities
    • Comment: ping/test/manage infra

  3. DROP IoT -> Management

    • Action: Drop
    • Source: NET-IOT
    • Destination: NET-MGMT
    • Comment: iot never initiates to management

  4. DROP Cameras -> Management

    • Action: Drop
    • Source: NET-CAMERAS
    • Destination: NET-MGMT
    • Comment: camera lane never initiates to management

  5. DROP Guest -> Management

    • Action: Drop
    • Source: NET-GUEST
    • Destination: NET-MGMT
    • Comment: guest blocked from management

  6. DROP Legacy CIA -> Management

    • Action: Drop
    • Source: NET-LEGACY-CIA
    • Destination: NET-MGMT
    • Comment: legacy quarantine blocked from management

  7. DROP Any Internal -> Management

    • Action: Drop
    • Source: NET-RFC1918-ALL
    • Destination: NET-MGMT
    • Comment: default management shield after explicit allows

Section C: Trusted human lane

  1. ALLOW Trusted -> Servers Approved Access
  • Action: Allow
  • Source: NET-TRUSTED
  • Destination: NET-SERVERS
  • Ports: Any or explicit service groups depending on how tight you want day one
  • Comment: trusted human lane to servers
  1. ALLOW Trusted -> Cameras Admin/Viewer Access
  • Action: Allow
  • Source: NET-TRUSTED
  • Destination: NET-CAMERAS
  • Ports: exact ports if known, otherwise temporary broader allow during migration
  • Comment: trusted operator to camera lane
  1. ALLOW Trusted -> IoT Control Exceptions
  • Action: Allow
  • Source: NET-TRUSTED
  • Destination: NET-IOT
  • Ports: only what control/discovery really needs
  • Comment: trusted control to iot where required

Section D: Server helper traffic

  1. ALLOW Servers -> IoT Approved Helpers
  • Action: Allow
  • Source: HOST-IOT-HELPERS or NET-SERVERS narrowed to real helper hosts
  • Destination: NET-IOT
  • Ports: exact service ports only
  • Comment: ha/mqtt/etc only if actually used
  1. ALLOW Cameras -> Protect Services
  • Action: Allow
  • Source: NET-CAMERAS
  • Destination: HOST-PROTECT-SERVICES
  • Ports: exact Protect/NVR ports
  • Comment: camera lane to protect only
  1. ALLOW IoT -> Approved Server Helpers
  • Action: Allow
  • Source: NET-IOT
  • Destination: HOST-IOT-HELPERS
  • Ports: exact ports only
  • Comment: iot can only hit specific helper services
  1. ALLOW Legacy CIA -> Approved One-Off Exception
  • Action: Allow
  • Source: specific host(s) in NET-LEGACY-CIA
  • Destination: specific host(s)
  • Ports: exact ports only
  • Disabled by default unless proven needed
  • Comment: ugly but narrow quarantine exception

Section E: DNS / NTP baseline for restricted lanes

  1. ALLOW IoT -> DNS
  • Action: Allow
  • Source: NET-IOT
  • Destination: HOST-DNS
  • Ports: PORT-DNS
  • Comment: iot dns
  1. ALLOW Cameras -> DNS
  • Action: Allow
  • Source: NET-CAMERAS
  • Destination: HOST-DNS
  • Ports: PORT-DNS
  • Comment: camera dns
  1. ALLOW Legacy CIA -> DNS
  • Action: Allow
  • Source: NET-LEGACY-CIA
  • Destination: HOST-DNS
  • Ports: PORT-DNS
  • Comment: legacy dns
  1. ALLOW IoT -> NTP
  • Action: Allow
  • Source: NET-IOT
  • Destination: HOST-NTP or Any if using public NTP
  • Ports: PORT-NTP
  • Comment: iot ntp
  1. ALLOW Cameras -> NTP
  • Action: Allow
  • Source: NET-CAMERAS
  • Destination: HOST-NTP or Any if using public NTP
  • Ports: PORT-NTP
  • Comment: camera ntp
  1. ALLOW Legacy CIA -> NTP
  • Action: Allow
  • Source: NET-LEGACY-CIA
  • Destination: HOST-NTP or Any if using public NTP
  • Ports: PORT-NTP
  • Comment: legacy ntp

Section F: Internet access for constrained lanes

  1. ALLOW Guest -> Internet
  • Action: Allow
  • Source: NET-GUEST
  • Destination: Internet / Not RFC1918
  • Comment: guest internet only
  1. ALLOW IoT -> Internet
  • Action: Allow
  • Source: NET-IOT
  • Destination: Internet / Not RFC1918
  • Comment: iot outbound internet
  1. ALLOW Cameras -> Internet Updates
  • Action: Allow
  • Source: NET-CAMERAS
  • Destination: Internet / Not RFC1918
  • Comment: camera updates/cloud only if needed
  1. ALLOW Legacy CIA -> Internet
  • Action: Allow
  • Source: NET-LEGACY-CIA
  • Destination: Internet / Not RFC1918
  • Comment: legacy quarantine outbound only

Section G: Broad internal denies for restricted lanes

  1. DROP Guest -> RFC1918/Internal
  • Action: Drop
  • Source: NET-GUEST
  • Destination: NET-RFC1918-ALL
  • Comment: guest blocked from local networks
  1. DROP IoT -> Trusted
  • Action: Drop
  • Source: NET-IOT
  • Destination: NET-TRUSTED
  • Comment: iot blocked from human lane
  1. DROP IoT -> Servers
  • Action: Drop
  • Source: NET-IOT
  • Destination: NET-SERVERS
  • Comment: iot blocked from servers after helper exceptions
  1. DROP IoT -> Cameras
  • Action: Drop
  • Source: NET-IOT
  • Destination: NET-CAMERAS
  • Comment: iot blocked from camera lane
  1. DROP Cameras -> Trusted
  • Action: Drop
  • Source: NET-CAMERAS
  • Destination: NET-TRUSTED
  • Comment: cameras blocked from human lane
  1. DROP Cameras -> Servers
  • Action: Drop
  • Source: NET-CAMERAS
  • Destination: NET-SERVERS
  • Comment: cameras blocked from servers except protect
  1. DROP Cameras -> IoT
  • Action: Drop
  • Source: NET-CAMERAS
  • Destination: NET-IOT
  • Comment: camera lane blocked from iot
  1. DROP Legacy CIA -> Trusted
  • Action: Drop
  • Source: NET-LEGACY-CIA
  • Destination: NET-TRUSTED
  • Comment: legacy blocked from human lane
  1. DROP Legacy CIA -> Servers
  • Action: Drop
  • Source: NET-LEGACY-CIA
  • Destination: NET-SERVERS
  • Comment: legacy blocked from servers after one-offs
  1. DROP Legacy CIA -> Cameras
  • Action: Drop
  • Source: NET-LEGACY-CIA
  • Destination: NET-CAMERAS
  • Comment: legacy blocked from security lane
  1. DROP Legacy CIA -> IoT
  • Action: Drop
  • Source: NET-LEGACY-CIA
  • Destination: NET-IOT
  • Comment: legacy does not mingle with clean iot

Section H: Optional discovery exceptions

  1. ALLOW Trusted -> mDNS Reflector / Discovery Helper
  • Only if real testing proves needed
  • Prefer reflector/helper architecture over broad subnet trust
  1. ALLOW Specific Google/Cast Device -> Specific Helper
  • Host-specific only
  • Ports exact only
  • Comment with device name and why it exists
  1. DROP Any Temporary Discovery Exception Cleanup Marker
  • Not a real rule type, just a process note
  • Every temporary discovery rule gets a unique comment and review date

4. Rule Notes By Lane

Management:

  • Most-protected lane.
  • Admin access only from known trusted admin devices.

Trusted:

  • Primary operator lane.
  • Allowed to talk where humans need to talk, but still not a dumping ground.

Servers:

  • Prefer exact service-based exposure later.
  • For tomorrow, a broader Trusted -> Servers allow is acceptable if you document it and tighten later.

IoT:

  • Default deny inward and outward to internal LANs except helper carve-outs.

Cameras:

  • Same philosophy as IoT, but even stricter.
  • If Protect is local, keep camera-to-protect flow exact.

Legacy CIA:

  • Outbound internet, DNS, NTP, nothing more unless explicitly justified.
  • Every exception should feel embarrassing.

5. What To Stage Tomorrow Versus Later

Stage tomorrow:

  • established/related
  • invalid drop
  • management shield
  • guest internet-only pattern
  • IoT/Cameras/Legacy broad internal denies
  • Trusted admin to Management
  • Trusted to Servers
  • DNS/NTP for restricted lanes
  • Legacy CIA quarantine posture

Defer if not needed immediately:

  • mDNS/cast helper rules
  • fancy service-specific microsegmentation between Trusted and Servers
  • any discovery exceptions not proven by real failure testing

6. Validation Checklist After Rule Deployment

  • Trusted admin client can still reach UniFi/gateway/switch/AP admin surfaces
  • Trusted can reach core server services
  • Guest gets internet and cannot reach local IPs
  • IoT device can resolve DNS, keep time, and reach vendor cloud if expected
  • Camera/security device remains online and can reach Protect if required
  • Legacy CIA device still works only at minimum acceptable level
  • No restricted lane can initiate into Management

7. Red Flags

Do not do these:

  • allow IoT -> Servers any
  • allow Legacy CIA -> Trusted any
  • allow Guest -> RFC1918 any
  • put discovery/broadcast panic rules above security structure without device-specific justification
  • leave unnamed temporary rules in place after testing

8. First Tightening Pass After Tomorrow

After the cutover stabilizes:

  • narrow Trusted -> Servers from broad allow to explicit service sets if useful
  • delete any temporary discovery exceptions that proved unnecessary
  • audit whether Cameras even need outbound internet
  • audit whether Legacy CIA can lose individual devices or the whole SSID
Reference in New Issue View Git Blame Copy Permalink