OpenSSH-Client without reverse tunnel ability

[Corinna Vinschen]

On Apr  4 13:58, Nico Kadel-Garcia wrote:
> 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,

No, that won't work.  ssh -R has been called from inside the company to
forward outside connections into the company net.  The ssh server is
thus outside the company net and not under control of the company
admins.

One way to discourage this is a company policy.

  "forbidden" " don't do that" "sign here in blood".

Alternatively, SELinux might help, though it's unclear to me how
in this scenario.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180405/5b1ccab9/attachment.asc>