412 lines
12 KiB
Markdown
412 lines
12 KiB
Markdown
# 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
|
|
3. `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`
|
|
|
|
4. `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`
|
|
|
|
5. `DROP IoT -> Management`
|
|
- Action: Drop
|
|
- Source: `NET-IOT`
|
|
- Destination: `NET-MGMT`
|
|
- Comment: `iot never initiates to management`
|
|
|
|
6. `DROP Cameras -> Management`
|
|
- Action: Drop
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: `NET-MGMT`
|
|
- Comment: `camera lane never initiates to management`
|
|
|
|
7. `DROP Guest -> Management`
|
|
- Action: Drop
|
|
- Source: `NET-GUEST`
|
|
- Destination: `NET-MGMT`
|
|
- Comment: `guest blocked from management`
|
|
|
|
8. `DROP Legacy CIA -> Management`
|
|
- Action: Drop
|
|
- Source: `NET-LEGACY-CIA`
|
|
- Destination: `NET-MGMT`
|
|
- Comment: `legacy quarantine blocked from management`
|
|
|
|
9. `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
|
|
10. `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`
|
|
|
|
11. `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`
|
|
|
|
12. `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
|
|
13. `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`
|
|
|
|
14. `ALLOW Cameras -> Protect Services`
|
|
- Action: Allow
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: `HOST-PROTECT-SERVICES`
|
|
- Ports: exact Protect/NVR ports
|
|
- Comment: `camera lane to protect only`
|
|
|
|
15. `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`
|
|
|
|
16. `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
|
|
17. `ALLOW IoT -> DNS`
|
|
- Action: Allow
|
|
- Source: `NET-IOT`
|
|
- Destination: `HOST-DNS`
|
|
- Ports: `PORT-DNS`
|
|
- Comment: `iot dns`
|
|
|
|
18. `ALLOW Cameras -> DNS`
|
|
- Action: Allow
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: `HOST-DNS`
|
|
- Ports: `PORT-DNS`
|
|
- Comment: `camera dns`
|
|
|
|
19. `ALLOW Legacy CIA -> DNS`
|
|
- Action: Allow
|
|
- Source: `NET-LEGACY-CIA`
|
|
- Destination: `HOST-DNS`
|
|
- Ports: `PORT-DNS`
|
|
- Comment: `legacy dns`
|
|
|
|
20. `ALLOW IoT -> NTP`
|
|
- Action: Allow
|
|
- Source: `NET-IOT`
|
|
- Destination: `HOST-NTP` or Any if using public NTP
|
|
- Ports: `PORT-NTP`
|
|
- Comment: `iot ntp`
|
|
|
|
21. `ALLOW Cameras -> NTP`
|
|
- Action: Allow
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: `HOST-NTP` or Any if using public NTP
|
|
- Ports: `PORT-NTP`
|
|
- Comment: `camera ntp`
|
|
|
|
22. `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
|
|
23. `ALLOW Guest -> Internet`
|
|
- Action: Allow
|
|
- Source: `NET-GUEST`
|
|
- Destination: Internet / Not RFC1918
|
|
- Comment: `guest internet only`
|
|
|
|
24. `ALLOW IoT -> Internet`
|
|
- Action: Allow
|
|
- Source: `NET-IOT`
|
|
- Destination: Internet / Not RFC1918
|
|
- Comment: `iot outbound internet`
|
|
|
|
25. `ALLOW Cameras -> Internet Updates`
|
|
- Action: Allow
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: Internet / Not RFC1918
|
|
- Comment: `camera updates/cloud only if needed`
|
|
|
|
26. `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
|
|
27. `DROP Guest -> RFC1918/Internal`
|
|
- Action: Drop
|
|
- Source: `NET-GUEST`
|
|
- Destination: `NET-RFC1918-ALL`
|
|
- Comment: `guest blocked from local networks`
|
|
|
|
28. `DROP IoT -> Trusted`
|
|
- Action: Drop
|
|
- Source: `NET-IOT`
|
|
- Destination: `NET-TRUSTED`
|
|
- Comment: `iot blocked from human lane`
|
|
|
|
29. `DROP IoT -> Servers`
|
|
- Action: Drop
|
|
- Source: `NET-IOT`
|
|
- Destination: `NET-SERVERS`
|
|
- Comment: `iot blocked from servers after helper exceptions`
|
|
|
|
30. `DROP IoT -> Cameras`
|
|
- Action: Drop
|
|
- Source: `NET-IOT`
|
|
- Destination: `NET-CAMERAS`
|
|
- Comment: `iot blocked from camera lane`
|
|
|
|
31. `DROP Cameras -> Trusted`
|
|
- Action: Drop
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: `NET-TRUSTED`
|
|
- Comment: `cameras blocked from human lane`
|
|
|
|
32. `DROP Cameras -> Servers`
|
|
- Action: Drop
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: `NET-SERVERS`
|
|
- Comment: `cameras blocked from servers except protect`
|
|
|
|
33. `DROP Cameras -> IoT`
|
|
- Action: Drop
|
|
- Source: `NET-CAMERAS`
|
|
- Destination: `NET-IOT`
|
|
- Comment: `camera lane blocked from iot`
|
|
|
|
34. `DROP Legacy CIA -> Trusted`
|
|
- Action: Drop
|
|
- Source: `NET-LEGACY-CIA`
|
|
- Destination: `NET-TRUSTED`
|
|
- Comment: `legacy blocked from human lane`
|
|
|
|
35. `DROP Legacy CIA -> Servers`
|
|
- Action: Drop
|
|
- Source: `NET-LEGACY-CIA`
|
|
- Destination: `NET-SERVERS`
|
|
- Comment: `legacy blocked from servers after one-offs`
|
|
|
|
36. `DROP Legacy CIA -> Cameras`
|
|
- Action: Drop
|
|
- Source: `NET-LEGACY-CIA`
|
|
- Destination: `NET-CAMERAS`
|
|
- Comment: `legacy blocked from security lane`
|
|
|
|
37. `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
|
|
38. `ALLOW Trusted -> mDNS Reflector / Discovery Helper`
|
|
- Only if real testing proves needed
|
|
- Prefer reflector/helper architecture over broad subnet trust
|
|
|
|
39. `ALLOW Specific Google/Cast Device -> Specific Helper`
|
|
- Host-specific only
|
|
- Ports exact only
|
|
- Comment with device name and why it exists
|
|
|
|
40. `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
|