[Feature Request] Custom Logic during Security Audit

[cromulon-actual]

An initial scan would be nice, but being able to designate your zones and LAN assignments might make some of the security audit rules adapt to the intent.

Examples:

• Disabling Internet access from within the LAN network settings removes the ability to log on blocks. However, enabling internet access then creating a block rule for any to external zone achieves the same thing and enables the logging capabilities. However, it seems it's looking for that option to be checked.
• Same with network isolation. Smart homes may need to have LAN/Zone interconnects, whitelisting endpoints SRC/DST and SPT/DPT could help mitigate the compliance check flag.
• Change dismiss to ignore and do not include ignored in security checks but still make it obvious rules are being ignored. This would allow a user to continue checking their overall security with defined intent. There are best practices or cookie cutter builds but there may be some use cases that need to override those practices.
• Excessive VLAN tagging on access port: Currently Unifi does not report all clients detected on a port from the port's perspective. It will annotate by client that multiple clients are using the same port. This is also problematic if you're using a downstream non-unifi device like a catalyst switch with multiple clients connected to different VLANs. I think being able to check VLANs tagged and clients using said tagged VLANs could help mitigate this finding. This seems like a false positive.
• Device Classification, IoT is both a specific and general term for device classification. However, someone could classify a device as media versus IoT. Being able to change the device classification could help mitigate some of the incorrect device network placement alarms.
• the way HomePods work are they'll use the configured Wifi of the iPhone it's configured from. I like to place my media devices into a media VLAN which has an PPSK SSID that channels it there. However, some times it'll be on my SSID because that's where my phone is configured.

[tvancott42]

Thanks for the report. I like what you got.

A lot of this is handled already and may just be edge cases on your end, or regressions in refactors since.

I'll give you my initial assessment of each of your bullet points here, and then I'm going to re-test each item I can w/ my home test network and other test networks and have Claude Code deep dive on the ones that seem like legit bugs and report back.

Which OS and Network versions are you on? You imply Zone-Based FW, but let me know if you're still on pre-zone-based. The latter would explain most of this as I had to implement that blind w/ sample API responses only as none of my test networks are on the legacy FW rules still.

Disabling Internet access from within the LAN network settings removes the ability to log on blocks. However, enabling internet access then creating a block rule for any to external zone achieves the same thing and enables the logging capabilities. However, it seems it's looking for that option to be checked.

This one is accounted for and treats a block rule as equivalent to the Network checkbox item, this may be a regression, or edge case. Can you lay out a specific example of this with screenshots of the Issue generated and of your FW rule(s) that cover the effective block?

Same with network isolation. Smart homes may need to have LAN/Zone interconnects, whitelisting endpoints SRC/DST and SPT/DPT could help mitigate the compliance check flag.

Same here, the logic considers block rules the same as Isolate Network, if anything I prefer the latter due to this: https://ozarkconnect.net/blog/unifi-network-isolation-bug - can you same as above give a screenshot of one example of the Issue and FW rule you have covering this so I can figure why it's an edge case?

Change dismiss to ignore and do not include ignored in security checks but still make it obvious rules are being ignored. This would allow a user to continue checking their overall security with defined intent. There are best practices or cookie cutter builds but there may be some use cases that need to override those practices.

I like this idea, but it gets really complicated because the user's intent is often just to silence an audit rule for one device, VLAN, or FW rule.

Excessive VLAN tagging on access port: Currently Unifi does not report all clients detected on a port from the port's perspective. It will annotate by client that multiple clients are using the same port. This is also problematic if you're using a downstream non-unifi device like a catalyst switch with multiple clients connected to different VLANs. I think being able to check VLANs tagged and clients using said tagged VLANs could help mitigate this finding. This seems like a false positive.

Yeah I figured this would happen. There was one Network release where I was doing R&D for this months ago where I thought multi-MACs were reported as connected on the port, but you're right it may be 1:1 on the Port perspective unfortunately. This is not a difficult fix, just hard for me to test without breaking out an unmanaged switch from storage. I'll just need to consult the wired client list vs their uplinks... I'll build a tree either up front or just check for suspected multi-VLAN-tagged access ports. As you've seen, I build this out anyway for Speed Test traces, so no biggie.

Device Classification, IoT is both a specific and general term for device classification. However, someone could classify a device as media versus IoT. Being able to change the device classification could help mitigate some of the incorrect device network placement alarms.

the way HomePods work are they'll use the configured Wifi of the iPhone it's configured from. I like to place my media devices into a media VLAN which has an PPSK SSID that channels it there. However, some times it'll be on my SSID because that's where my phone is configured.

I get this but also, the IoT catch-all keeps things simple as more items are permitted in inter-IoT VLAN scenarios (or could be as I work through more scenarios). The Audit Settings are intended to solve this for people who want easy carve-outs such as for your Homepods situation.

You saw this setting right? Allow Apple streaming devices on main network
Apple TV and HomePod devices on main/corporate VLANs will show as Info instead of Warning

That would likely catch your case even if it's a separate Media VLAN that's being categorized as Purpose = Home.

[cromulon-actual]

I'll work on catching more of these scenarios, but here are some direct examples you've requested.

Which OS and Network versions are you on? You imply Zone-Based FW, but let me know if you're still on pre-zone-based. The latter would explain most of this as I had to implement that blind w/ sample API responses only as none of my test networks are on the legacy FW rules still.

=========

Disabling Internet access from within the LAN network settings removes the ability to log on blocks. However, enabling internet access then creating a block rule for any to external zone achieves the same thing and enables the logging capabilities. However, it seems it's looking for that option to be checked.

=========

As seen in the image above, I have specific Zones for IoT and Security and the rest of my LAN segments exist in Internal etc., not sure how to handle this:

[tvancott42]

@cromulon-actual Some of this is fixed (but not all) in upcoming release v1.3.3 - I'll circle back after you have a chance to check that out once available (ETA 20 min)

[cromulon-actual]

Disregard the "Block Security to Security Any" Was watching a show when I named that policy, it was supposed to be "Block Security to External Any".

[cromulon-actual]

I see the release, is there a more native way to update rather than a clean install? I have this deployed in proxmox (moved it there from my macOS as I wanted something a little more stable via an ethernet.

[tvancott42]

With shell access to the proxmox LXC you can just cd to the install directory directory with the docker config and then docker compose pull && docker compose up -d

I'm sure there's a better way to do this but we don't really use proxmox in enterprise dev much yet so I'm not super familiar.

[cromulon-actual]

I ended up just rebuilding it, no problem. However, after getting it back up and running I reran the security audit:

[cromulon-actual]

Thank you for working on this!

[tvancott42]

Of course. Your network is closer in line with current client site deployments since Zones became a thing so it's great to test.

No improvement then, no delta at all in reported issues?