449cd1e2fe
The `roundrobin`, `signed`, and `unsigned` host-selection modes route
requests against an operator-curated `Server.Hosts` list. The `any`
mode does not -- it forwards to whatever `?host=` value the request
carries, which makes the gateway usable as a generic TCP relay
against whatever the gateway can reach (loopback, RFC1918, link-local,
the cloud metadata service, arbitrary high-numbered ports on public
hosts).
Add a small destination policy applied only in `any` mode:
* Reject hosts that resolve to loopback, RFC1918, IPv6 ULA,
link-local, unspecified, or multicast addresses. Operators can opt
back in with `Server.AllowPrivateDestinations: true`.
* Restrict the destination port to `Server.AllowedDestinationPorts`
(default {3389}).
The other host-selection modes are unaffected -- the operator already
curates their hosts list.
The DestinationPolicy zero value is the secure default, so direct
&Handler{} constructions in tests still get the expected behavior.
DNS names are resolved at validation time and every returned address
is checked.
1.6 KiB
Upgrading
Unreleased
hostselection: any now refuses non-routable destinations and non-RDP ports by default
Previously, when server.hostselection: any was set, rdpgw forwarded
to whatever ?host= value the request carried with no check on the
target. The gateway would happily relay TCP traffic to loopback,
RFC1918, link-local, or arbitrary high-numbered ports on public hosts.
After upgrading, any mode rejects any destination that resolves to a
loopback / RFC1918 / link-local / IPv6 ULA / unspecified / multicast
address, and any port that is not in AllowedDestinationPorts. The
default port allow-list is [3389].
If your deployment legitimately reaches private destinations or extra
ports through any mode, opt back in:
Server:
HostSelection: any
AllowedDestinationPorts:
- 3389
- 5985 # add what you actually need
AllowPrivateDestinations: true
The other host-selection modes (roundrobin, signed, unsigned)
already use the operator-curated Server.Hosts allow-list and are
unaffected by this change.
Upgrading from 1.X to 2.0
In 2.0 the options for configuring client side RDP settings have been removed in favor of template file. The template file is a RDP file that is used as a template for the connection. The template file is parsed and a few settings are replaced to ensure the client can connect to the server and the correct domain is used.
The format of the template file is as follows:
# <setting>:<type i or s>:<value>
domain:s:testdomain
connection type:i:2
The filename is set under client > defaults.