Where camera segmentation goes wrong

The permit list is the easy part; these are the places where vendor defaults quietly make the rule set wider than the design.

Nobody argues about the drawing. Cameras on their own VLAN, one recorder, a defined management source, deny everything else: the design passes review in ten minutes. The rule set built from it three weeks later permits things the design never mentioned, and the reasons are boringly repeatable. Four of them come from properties of camera and VMS software that the vendors print in their own documentation, in documents nobody has open at the moment the access list gets written.

The permit list itself, and the method for checking a segment from inside it, are in the hardening guide. What follows is the arithmetic underneath.

Five thousand ports per agent#

Genetec's Archiver takes live unicast video from cameras on UDP 15000–19999, inbound on the Archiver and outbound from the camera. Each additional ArchiverAgent on the same server starts 5,000 higher — 20000–24999, then 25000–29999. Two agents and the permitted range is ten thousand ports wide before anyone has drawn a second recorder.

Version scoping matters here and Genetec's own documentation does not settle it. That range appears on the "Opening firewall ports for Security Center communication" page, which covers Security Center 5.9 through 5.12. The separate "Default ports used by Security Center 5.13" page was published for a later release, and where the two disagree we could not determine which governs a 2026 deployment. Check both against the version you are running before you write anything down.

Nobody maintains a hand-written ACL with five thousand destination ports in it. What gets typed instead is a permit for UDP to anything, and once one line in the table says any, the rest of the table stops being read. The width in the port dimension is Genetec's decision and you are not going to win it. The address dimension is still yours:

permit udp 10.20.0.0/24 host 10.30.0.11 range 15000 19999
deny   udp 10.20.0.0/24 any

One source prefix, one destination host, an explicit deny beneath it. That is a rule an auditor can read in five seconds and a rule that survives someone adding a second Archiver, because the second Archiver will fail visibly rather than work by accident.

The port you closed inbound is open outbound#

Bosch changed its camera factory defaults to close five listening ports: RCP+ 1756, HTTP 80, RTSP 554, iSCSI server 3260 and NTP server 123. Two of the five keep working in the other direction, and Bosch says so in the same document.

The iSCSI one is the important one for a camera VLAN. Closing the server port stops anything on the network reaching the camera's SD card as an iSCSI target, but "The iSCSI client, which is used by the camera to record onto iSCSI targets, uses the same port 3260 in 'outgoing' direction, which is still open". The camera writes its own recordings to storage. Since the device holding 3260 open is the camera, this is an egress rule on the camera VLAN, and it is the exact rule a default-deny outbound policy will break at the moment recordings start to matter. NTP behaves the same way: with the server closed, the device is "still listening on port 123 to synchronize its time base".

So a table listing 3260 as recorder-to-storage has attached the flow to the wrong device, and a rule set derived from that table has a hole where the camera's storage path should be. Write egress from the camera range as three named destinations: the iSCSI target on 3260, the time source on 123, the recorder on its media and control ports, with a deny beneath them. All three are host addresses somebody can look up.

Two caveats on Bosch's documentation. It states that the discovery ports are deliberately left open and declines to print their numbers; the 1757/1758 pair repeated across the trade press could not be confirmed from any Bosch-authored document. And Bosch's video knowledge base has migrated to keenfinity-group.com, where the article URLs currently return navigation shells or 404, so this TechNote is doing more citation work than one document should.

Identical defaults collide, and the fix is usually the wrong one#

Dahua's Network Camera Web 3.0 manual prints multicast defaults of group 224.1.2.4 with main stream on 40000 and sub-streams on 40016 and 40032. Those values ship the same on every device carrying that interface, so several cameras on one L2 segment collide on 224.1.2.4:40000 unless somebody reconfigures them.

Two repairs are available. Renumbering is per-device manual work through each camera's web interface, done at commissioning, recorded somewhere alongside the addresses. Widening — flooding the group across the boundary, or relaxing the multicast rule until the symptom goes away — is one line typed by whoever is on site when the streams stop. We have no measurement of which one estates choose, and no vendor documents it. Only one of the two is a segmentation decision, and it is not the one that takes ten minutes.

The same manual carries a note that undercuts a related assumption. Above the port table it warns that "0-1024, 1900, 3800, 5000, 5050, 9999, 37776, 37780-37880, 39999, 42323 are occupied for specific uses". It advises against assigning those and does not say the device refuses to let you. Read alongside the documented 37777 TCP and 37778 UDP pair, that means Dahua's proprietary port surface is wider than the two numbers everyone quotes, and both a firewall rule and a scan built on 37777 alone cover less than they look like they cover.

An upgrade that changes nothing#

Bosch's new defaults rolled out per platform: CPP13 with firmware 8.90 in July 2023, CPP14 with 9.10 in March 2024, and CPP7.3, CPP7 and CPP6 with the 7.89 maintenance release in June 2024. For RCP+, HTTP and RTSP on CPP14 and on CPP6/7/7.3, though, "New defaults will not automatically become effective during a firmware upgrade but require a factory default to be applied". Only CPP13 at 8.90 gets them on upgrade.

An estate upgraded in place therefore reports a firmware version that carries hardened defaults while every port its old defaults opened is still answering. Any posture inventory that reads a version string and infers a closed port is wrong on two of the three platforms, by the vendor's own account.

The check is a scan from a host sitting inside the camera VLAN, run per device rather than per model, and it has to look wider than the defaults: RTSP alone runs off 554 often enough that a sweep restricted to it missed roughly 44% of the internet-exposed population in Modat's March 2026 scan (how cameras become internet-exposed has the measurement). Widen the port list, keep the address list tight, and compare what answers against what the drawing says should answer.

The boundary a port-forward review cannot see#

Hikvision tells installers that for Hik-Connect platform access the firewall must not close 6002, 6800, 8555, 9010 and 9020, which it labels the STUN ports, and that the device must reach dev.hik-connect.com along with its lite and US siblings. The article does not state the transport per port, nor that the sessions are outbound only, so neither is asserted here. Dahua describes its own P2P as "a private network traversal technology which enables user to manage devices easily without requiring DDNS, port mapping or transit server", and warns that with it enabled "The information of the IP address, MAC address, device name, and device SN will be collected."

The structural point belongs to NAT-traversal cloud relay as a class rather than to either vendor's documented design: a review of the router's port forwards, and an external scan of the site's public address, will not show a fleet that is reachable through vendor infrastructure. Hunt.io's Operation CameraSwarm, disclosed on 18 August 2026, reached 283 of its 14,530-plus compromised Dahua cameras through the Easy4IP relay using serial numbers alone, alongside 12,324 unique IPs brute-forced on TCP 37777. The full breakdown sits on camera cybersecurity.

Which leaves one rule worth typing before any of the others. Deny the camera range outbound to the internet, then wait to be told what stopped working. The list that comes back — licence activation, a mobile app, a remote-maintenance path an integrator configured years ago — is the inventory of cloud dependencies nobody wrote down, and it is cheaper to collect that way than to discover it during an incident.