OpenSSH-Client without reverse tunnel ability
Alexander Wuerstlein
snalwuer at cip.informatik.uni-erlangen.de
Thu Apr 5 01:43:09 AEST 2018
On 2018-04-04T17:27, mlrx <openssh-unix-dev at 18informatique.com> 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.
More information about the openssh-unix-dev
mailing list