On 2018-04-04T17:27, mlrx <openssh-unix-dev@xxxxxxxxxxxxxxxxxx> wrote: > Le 04/04/2018 à 13:32, Jan Bergner a écrit : > > Good day! > > > > Is it possible to achieve this without nasty workarounds like wrapper > > scripts monitoring the very-verbose output of SSH or doing DPI? > > Alternatively, would it be possible to add a config option, allowing an > > administrator to disable reverse port forwarding or limit it's destinations? > > But, may be a combination of MATCH blocks with > PermitTunnel can be useful? > According your needs, something like: > > PermitTunnel no #(default) > Match Address other.corp.site.IP,123.123.123.123 > PermitTunnel Ethernet > Match group admin1 > PermitTunnel point-to-point > Match user root > PermitTunnel yes Yes, but PermitTunnel is only available in the daemon's config, not for the client. One could imagine a patch for that maybe. As far as I've understood, the original question was about centrally configuring all clients to not create tunnels. But generally, this is a very hard problem because it only works if one also takes additional measures like preventing any user-installed software (e.g. noexec on all user-writable mounts, because otherwise one would just install an ssh-client that doesn't obey global config restrictions) and preventing other commonly installed tools from being used to create such tunnels. Examples would be 'socat' or combinations of the openssl "demo" executable together with the tcp-redirection capabilities of certain shells, e.g. bash /dev/tcp/hostname/4711. Generally I think the problem of data exfiltration is unsolvable given sufficiently knowledable users and general-purpose software. One will always forget to plug one hole and to blacklist one more approach. Ciao, Alexander Wuerstlein. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
