# 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
3. `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

4. `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

5. `DROP IoT -> Management`
6. `DROP Cameras -> Management`
7. `DROP Guest -> Management`
8. `DROP Legacy CIA -> Management`
9. `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
10. `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

11. `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

12. `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
13. `ALLOW IoT -> DNS`
14. `ALLOW Cameras -> DNS`
15. `ALLOW Legacy CIA -> DNS`
   - Destination: `HOST-DNS`
   - Ports: `PORT-DNS`
   - Validation:
     - one client on each lane still resolves DNS

### Block 4B: NTP
16. `ALLOW IoT -> NTP`
17. `ALLOW Cameras -> NTP`
18. `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
19. `ALLOW Guest -> Internet`
20. `ALLOW IoT -> Internet`
21. `ALLOW Cameras -> Internet Updates`
22. `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.

23. `DROP Guest -> RFC1918/Internal`
24. `DROP IoT -> Trusted`
25. `DROP IoT -> Servers`
26. `DROP IoT -> Cameras`
27. `DROP Cameras -> Trusted`
28. `DROP Cameras -> Servers`
29. `DROP Cameras -> IoT`
30. `DROP Legacy CIA -> Trusted`
31. `DROP Legacy CIA -> Servers`
32. `DROP Legacy CIA -> Cameras`
33. `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