Good day! A few weeks ago, we had a security breach in the company I'm working for, because employees used "ssh -R" to expose systems from our internal network to some SSH server in the outer world. Of course, this is a breach of our internal security policy, but lead us to wonder, whether there is a technical solution to prevent our users from creating SSH-reverse-tunnels. After a lot of googleing, there seems to be no option for the system-wide client config that would do the trick nor any other suitable solution. (Watching ps is not sufficient, as the users can also specify reverse tunnels in their client config or create them from an already existing connection.) 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? Thank you in advance, Jan Bergner -- ________________________________________ *Jan Bergner, M.Sc. * Software Engineer ? *indurad GmbH* *The Industrial Radar Company* ? Belvedereallee 5 52070 Aachen, Germany Office: + 49 241 538070-61 Front Desk: + 49 241 538070-0 Fax: + 49 241 538070-99 jan.bergner at indurad.com www.indurad.com <http://www.indurad.com/> _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180404/055e1a64/attachment.asc>
> Alternatively, would it be possible to add a config option, allowing an > administrator to disable reverse port forwarding or limit it's > destinations?Look for "restrict" in the documentation for "authorized_keys".
Am 04.04.2018 um 13:39 schrieb Philipp Marek:> >> Alternatively, would it be possible to add a config option, >>allowing an administrator to disable reverse port forwarding or >> limit it's destinations? > Look for "restrict" in the documentation for "authorized_keys". Thank you for your quick response, but I want to restrict the SSH-*client* from establishing reverse tunnels to the *outer* world. (As I cannot control all the SSH servers out there.) -- ________________________________________ *Jan Bergner, M.Sc. * Software Engineer ? *indurad GmbH* *The Industrial Radar Company* ? Belvedereallee 5 52070 Aachen, Germany Office: + 49 241 538070-61 Front Desk: + 49 241 538070-0 Fax: + 49 241 538070-99 jan.bergner at indurad.com www.indurad.com <http://www.indurad.com/> _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180404/f55e24a5/attachment.asc>
Hi Jan, I doubt you can control this by inspecting the packets because they are encrypted. SSH could be modified to recognise a new option in /etc/ssh/ssh_config, but if your users can run a non-standard SSH (i.e. one which doesn't have that restriction), then there's not much you can do.? It'd take a very tight ship to prevent users from running a non-standard SSH. My first thought was that they might bring in their own device. My second thought was that an SSH client could be written in Javascript, so every web browser is a potential weak point.? My third thought was that writing a tunnel in Javascript is probably easier than writing a complete SSH client, and so every web browser is doubly a weak point. David
Le 04/04/2018 ? 13:32, Jan Bergner a ?crit?:> Good day! > > A few weeks ago, we had a security breach in the company I'm working > for, because employees used "ssh -R" to expose systems from our internal > network to some SSH server in the outer world. > > Of course, this is a breach of our internal security policy, but lead us > to wonder, whether there is a technical solution to prevent our users > from creating SSH-reverse-tunnels. > > After a lot of googleing, there seems to be no option for the > system-wide client config that would do the trick nor any other suitable > solution. (Watching ps is not sufficient, as the users can also specify > reverse tunnels in their client config or create them from an already > existing connection.) > > 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? > > > Thank you in advance, > > Jan BergnerHello, No -totally sure- way without DPI and/or proxy, I think. 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 Regards, -- benoist -- benoist
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 yesYes, 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.