219 lines
6.9 KiB
Markdown
219 lines
6.9 KiB
Markdown
# UniFi Firewall Gap List
|
||
|
||
Purpose: compare the intended segmentation design against the current staged UniFi firewall artifacts without making any live traffic changes.
|
||
|
||
Evidence used:
|
||
- Desired design: `home/doris-dashboard/docs/network-firewall-rule-order.md`
|
||
- Current groups baseline: `home/doris-dashboard/docs/baselines/unifi-firewallgroup-baseline-2026-05-22-post-stage.json`
|
||
- Current custom policy baseline: `home/doris-dashboard/docs/baselines/unifi-firewall-policies-custom-2026-05-22-post-ui-probe.json`
|
||
|
||
## Executive summary
|
||
|
||
Current state is scaffolding, not finished enforcement.
|
||
|
||
What exists now:
|
||
- network/address groups for the major lanes
|
||
- a handful of port groups
|
||
- one enabled custom outbound-style policy: `Allow Internal to Untrusted`
|
||
- one disabled temp policy: `DORIS-TEMP`
|
||
|
||
What does not yet exist in the captured custom-policy baseline:
|
||
- the actual inter-VLAN segmentation matrix
|
||
- the management shield
|
||
- the quarantine posture for Legacy CIA
|
||
- the lane-specific allow/deny structure described in the design doc
|
||
|
||
So the honest answer is:
|
||
- groups/objects: mostly present
|
||
- real custom segmentation policy: largely still missing
|
||
|
||
## 1. Present in the current staged baseline
|
||
|
||
### Network groups present
|
||
- `NET-MGMT`
|
||
- `NET-TRUSTED`
|
||
- `NET-SERVERS`
|
||
- `NET-IOT`
|
||
- `NET-GUEST`
|
||
- `NET-CAMERAS`
|
||
- `NET-LEGACY-CIA`
|
||
- `NET-RFC1918-ALL`
|
||
|
||
### Port groups present
|
||
- `PORT-DNS`
|
||
- `PORT-DHCP`
|
||
- `PORT-NTP`
|
||
- `PORT-WEB-ADMIN`
|
||
- `PORT-SSH`
|
||
- `PORT-MDNS`
|
||
|
||
### Custom policies present
|
||
1. `Allow Internal to Untrusted`
|
||
- enabled
|
||
- effectively basic internal -> internet/outside allowance scaffolding
|
||
2. `DORIS-TEMP`
|
||
- disabled
|
||
- temporary/non-production artifact, not part of the final design
|
||
|
||
## 2. Missing object inventory compared to the design
|
||
|
||
The rule-order design expects these host/device groups, but they do not appear in the captured firewall-group baseline:
|
||
- `HOST-ADMIN-TRUSTED`
|
||
- `HOST-CORE-SERVICES`
|
||
- `HOST-PROTECT-SERVICES`
|
||
- `HOST-DNS`
|
||
- `HOST-NTP`
|
||
- `HOST-IOT-HELPERS`
|
||
- `HOST-CAMERA-HELPERS`
|
||
- `HOST-LEGACY-EXCEPTIONS`
|
||
|
||
The design also mentions port groups not seen in the captured baseline:
|
||
- `PORT-PROTECT`
|
||
- `PORT-CAST`
|
||
|
||
Impact:
|
||
- exact narrow allow rules for management, Protect, helper traffic, and Google/cast exceptions cannot be cleanly expressed yet using the intended group model
|
||
|
||
## 3. Missing rule sections compared to the design
|
||
|
||
### Section A: Core state handling
|
||
Missing or not evidenced in the captured custom-policy baseline:
|
||
- `ALLOW Established/Related`
|
||
- `DROP Invalid`
|
||
|
||
### Section B: Management protection
|
||
Missing or not evidenced:
|
||
- `ALLOW Trusted Admin -> Management Admin Surfaces`
|
||
- `ALLOW Trusted Admin -> Gateway Infra Utilities`
|
||
- `DROP IoT -> Management`
|
||
- `DROP Cameras -> Management`
|
||
- `DROP Guest -> Management`
|
||
- `DROP Legacy CIA -> Management`
|
||
- `DROP Any Internal -> Management`
|
||
|
||
Meaning:
|
||
- the intended management shield is not yet represented in the captured custom-policy set
|
||
|
||
### Section C: Trusted human lane
|
||
Missing or not evidenced:
|
||
- `ALLOW Trusted -> Servers Approved Access`
|
||
- `ALLOW Trusted -> Cameras Admin/Viewer Access`
|
||
- `ALLOW Trusted -> IoT Control Exceptions`
|
||
|
||
Meaning:
|
||
- the design’s explicit human/operator access model is not yet staged in a visible way
|
||
|
||
### Section D: Server/helper traffic
|
||
Missing or not evidenced:
|
||
- `ALLOW Servers -> IoT Approved Helpers`
|
||
- `ALLOW Cameras -> Protect Services`
|
||
- `ALLOW IoT -> Approved Server Helpers`
|
||
- `ALLOW Legacy CIA -> Approved One-Off Exception`
|
||
|
||
Meaning:
|
||
- no captured evidence yet of the narrow internal service exceptions the design wants
|
||
|
||
### Section E: DNS/NTP baseline for restricted lanes
|
||
Missing or not evidenced:
|
||
- `ALLOW IoT -> DNS`
|
||
- `ALLOW Cameras -> DNS`
|
||
- `ALLOW Legacy CIA -> DNS`
|
||
- `ALLOW IoT -> NTP`
|
||
- `ALLOW Cameras -> NTP`
|
||
- `ALLOW Legacy CIA -> NTP`
|
||
|
||
Meaning:
|
||
- the restricted-lane minimum-function posture is not yet fully expressed in custom rules
|
||
|
||
### Section F: Internet access for constrained lanes
|
||
Partially present at best:
|
||
- there is one broad custom policy, `Allow Internal to Untrusted`
|
||
|
||
Still missing as lane-specific explicit policy:
|
||
- `ALLOW Guest -> Internet`
|
||
- `ALLOW IoT -> Internet`
|
||
- `ALLOW Cameras -> Internet Updates`
|
||
- `ALLOW Legacy CIA -> Internet`
|
||
|
||
Meaning:
|
||
- outbound access is only evidenced in a broad/global way, not in the lane-specific shape called for by the design
|
||
|
||
### Section G: Broad internal denies for restricted lanes
|
||
Missing or not evidenced:
|
||
- `DROP Guest -> RFC1918/Internal`
|
||
- `DROP IoT -> Trusted`
|
||
- `DROP IoT -> Servers`
|
||
- `DROP IoT -> Cameras`
|
||
- `DROP Cameras -> Trusted`
|
||
- `DROP Cameras -> Servers`
|
||
- `DROP Cameras -> IoT`
|
||
- `DROP Legacy CIA -> Trusted`
|
||
- `DROP Legacy CIA -> Servers`
|
||
- `DROP Legacy CIA -> Cameras`
|
||
- `DROP Legacy CIA -> IoT`
|
||
|
||
Meaning:
|
||
- the core segmentation barriers between the restricted lanes and the rest of the network are not yet evidenced in the captured policy set
|
||
|
||
### Section H: Optional discovery exceptions
|
||
Correctly absent for now:
|
||
- no evidence of broad Google/cast discovery exception rules
|
||
- this is good; the design explicitly says these should only appear after real failure testing
|
||
|
||
## 4. Practical interpretation
|
||
|
||
If the captured baselines are still current, then the environment appears to be in this state:
|
||
|
||
1. The naming/object foundation is mostly there.
|
||
2. The network has at least one custom outbound-style policy.
|
||
3. The actual inter-VLAN enforcement plan is still largely unimplemented.
|
||
4. The current state is safer than random ad-hoc rules, but it is not yet the finished segmentation design.
|
||
|
||
## 5. Safe next implementation order
|
||
|
||
Before any live firewall apply, the safest order is:
|
||
|
||
1. Create the missing host groups
|
||
- `HOST-ADMIN-TRUSTED`
|
||
- `HOST-DNS`
|
||
- `HOST-NTP`
|
||
- `HOST-PROTECT-SERVICES`
|
||
- helper/exception groups as needed
|
||
|
||
2. Add the minimum safe rule skeleton first
|
||
- `ALLOW Established/Related`
|
||
- `DROP Invalid`
|
||
- management shield block set
|
||
- explicit Trusted admin -> Management allows
|
||
- Trusted -> Servers allow
|
||
|
||
3. Add the restricted-lane minimum-function rules
|
||
- DNS
|
||
- NTP
|
||
- outbound internet as appropriate
|
||
|
||
4. Add the broad internal deny matrix for Guest / IoT / Camera / Legacy CIA
|
||
|
||
5. Only after that, consider narrow discovery exceptions if the Google/cast pilot proves they are actually needed
|
||
|
||
## 6. What is safe to say right now
|
||
|
||
Accurate phrasing:
|
||
- firewall scaffolding exists
|
||
- the object/group layer is mostly staged
|
||
- a basic outbound custom policy exists
|
||
- the full inter-VLAN segmentation matrix is not yet fully implemented
|
||
|
||
Inaccurate phrasing to avoid:
|
||
- “the firewall is done”
|
||
- “inter-VLAN isolation is fully in place”
|
||
- “Legacy CIA is already fully quarantined by policy”
|
||
|
||
## 7. Recommended next operator action
|
||
|
||
Next safe action, still non-disruptive:
|
||
- define the missing host groups and map real devices/services into them on paper or in staging notes first
|
||
|
||
Next live-action phase after that:
|
||
- apply the minimum safe rule skeleton in a rollback-friendly order, validating management reachability after each step
|