So the Zen Server documentation clearly states that there’s no security at all there.
There’s also a DefaultEngine.ini configuration option:
[Zen.AutoLaunch]
AllowRemoteNetworkService=true
which allows the Zen service to listen on all IP addresses that a computer has. This can be (in theory) harmful if e.g. a remote worker enables this while their computer is connected to their house Internet, even as e.g. their game consoles are on a dedicated LAN with a VPN appliance.
Could you please discuss any plans around Zen Server and not “just” leaving it totally open to anyone on the LAN to read? Maybe some kind of API key, at least?
While I haven’t committed to implementing access restriction to zenserver - to this point we expect the user to be on a trusted network before they allow remote access to zenserver - the direction being considered is for locally run zenserver to have a pre-shared key that is generated and stored in a low security context on the local machine. zenserver would then be told it could allow remote access if the remote request had this key in its auth header, otherwise remote requests would be rejected with a 401 status code.
For UE to meet this requirement, we’d likely choose to store the preshared key in the ue.projectstore files that are written (unencrypted, unobfuscated) to disk and copied to target devices, so that when a target device wants to stream from zenserver that it knows not only the host/port/project/oplog to connect to, but also the key to use in the auth header.
Because UE is used in many different environments, I want to be careful about how we make this change. University/College labs are an example of untrusted networks that we want to avoid creating attack surface area in.
If we do it (and that’s an if, not a certainty), it would be in 5.8 or later. Right now we’re focused on zen for localhost requests only, and allowing remote (non-localhost) requests when running on a trusted office-or-home network where you might have remote devices that you want to be able to stream game data from zenserver. We could decide we are ok with relying on a user’s firewall configuration to control this behavior (windows firewall for example behaves differently depending on whether you’ve indicated that you’re on a trusted or untrusted network), but the risk is that people haven’t configured that correctly.
zenserver is not the only item in the UE ecosystem that opens a listen socket, so my motivation here is to avoid adding surface area for attack/leak of information in a way that people wouldn’t be aware of.
Since you referenced the documentation, I assume you’re aware of the presentation on using zenserver for target iteration that was part of Unreal Fest 2024, but if not, it’s a useful reference for how we’re approaching this stuff (even if it doesn’t go into the detail of authentication for remote access):