OpenSSH-Client without reverse tunnel ability

[Nico Kadel-Garcia]

On Wed, Apr 4, 2018 at 11:43 AM, Alexander Wuerstlein
<snalwuer at cip.informatik.uni-erlangen.de> wrote:
> 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.

>From the original description: the security breach occurred because
tunnels arae permitted by the daemon, and the users misused those
privileges. These admins do not have control over the client
configurations: if the clients are using normal system provided SSH
clients like openssh under CygWin, under MacOS, or under Linux, then
client control is pretty much a hopeless cause.

Is there any reason to permit *any* tunneling, at all? I suspect not.
If not, then the *servers* for SSH can be forced to disable it, or to
restrict its use to only certain personnel. Even a separate sshd with
separate sshd_config can be enabled, on a different port, to provide
distinct services if forward tunnels are actually needed. Such SSHD
daemons can even be activataed on a "jumphost", a better managed and
locked down host which all SSH connections *must* go through to avoid
another such security incident and to provide tracking.

Mind you: some weasels are likely to wend their own private way around
any such restriction if you don't keep your eyes peeled. I encountered
years ago a systems architect who ran an SSH port tunnel from inside
the secure network, through NAT port forwarding to his home machine,
and had mysql tunnels activated on his home machine to see the
internal databases from his home. And he had exposed tunnels running
on both sides, internally and externally, to inside and outside the
network. Coupled with this architect's insistence on using
passphrase-free SSH private keys, recorded in his home directory on
multiple servers throughout the development and production environment
and on his home machine, and the same key in use everywhere, and I got
pretty upset when I found out what was going on.

In any case: locking down port forwarding is likely to meet some
resistance, no matter how you do it. Find out what needs to be
forwarded, and why, so that you can make sure people can actually do
their jobs.