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>
Hello all. First of all, I want to extend my sincere thanks to all the people who came to the rescue so quickly. In any case, there is obviously room for clarification on my part, so I will try to describe the situation we had in more detail. In short: Employees used the openssh-*client* from *within* our company network to create a *reverse* SSH tunnel, using an *external* SSH-Server. We control the Clients but not the servers. So, we wanted to restrict our *Clients*. Of course, we are aware of other tools like socat or employees who can compile openssh on their own, but our aim was not to make data exfiltration impossible, as this would, indeed, mean disconnect from the internet. Obviously, I failed to emphazise, that our employees did not break the rules deliberately, but because they simply were not aware of the impact, their actions had. As a matter of fact, we often legitimately use SSH tunnels, also reverse tunnels, in other situations. (I. e. not on our workstations.) And indeed, we have the sign-it-with-your-blood-policy. The employees did not understand, they were breaking it. Suffice to say, that our case could have been prevented if the employees would have gotten a notification. And since they use SSH by default before they try anything else, this was our starting point. In the end, we figured, the most general way to prevent such breaches would be to restrict reverse tunnels on workstations, so the employees are reminded that this is not allowed. (Since they always could use an external SSH server to do nasty stuff.) Alternatively, any means of monitoring reverse tunnels would be an improvement. However, I gathered this is not possible, right now and cannot easily be added as feature. As far as I am concerned, my question is therefore answered and we will have to find another solution. Thanks again to all of you and best regards 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/20180405/ec529287/attachment.asc>
On Thu, Apr 5, 2018 at 7:13 AM, Jan Bergner <jan.bergner at indurad.com> wrote:> Hello all. > > First of all, I want to extend my sincere thanks to all the people who > came to the rescue so quickly. > > In any case, there is obviously room for clarification on my part, so I > will try to describe the situation we had in more detail. > > In short: > Employees used the openssh-*client* from *within* our company network to > create a *reverse* SSH tunnel, using an *external* SSH-Server. We > control the Clients but not the servers. > So, we wanted to restrict our *Clients*.How difficult would it be to leave a scheduled security check to look for "ssh[ \t].*-R.*" expressions with "pgrep", and file a security abuse report if such processes are seen? It could be worked around, but should catch the most blatant abusers.so they can be notified of inappropriate behavior. I'm not sure what is available for you if you're using OpenBSD or BSD based operating systems, but for Linux RedHat had a bug report for SELinux at https://bugzilla.redhat.com/show_bug.cgi?id=656813 explaining how they'd accidentally disabled port forwarding with SELinux. Perhaps that could help you? Nico Kadel-Garcia <nkadel at gmail.com>