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>
On 2018-04-05T14:07, Nico Kadel-Garcia <nkadel at gmail.com> wrote:> 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.Additionally, one could grep home directories for relevant configuration statements in ~/.ssh/config. However that would be necessarily incomplete, because the other relevant config is ~/.ssh/authorized_keys on the remote end. Ciao, Alexander Wuerstlein.
Am 05.04.2018 um 14:11 schrieb Alexander Wuerstlein:> On 2018-04-05T14:07, Nico Kadel-Garcia <nkadel at gmail.com> wrote: >> 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. > > Additionally, one could grep home directories for relevant > configuration statements in ~/.ssh/config. However that would be > necessarily incomplete, because the other relevant config is > ~/.ssh/authorized_keys on the remote end. Yeah, we thought of these options, too and I assume we will eventually go with them, but as was pointed out, these approaches are simple, et incomplete. That's why we asked in the first place. However, since there does not seem to be any reasonable alternative short than doing way more elaborated software development ourselves, these will have to do. Therefore, I consider this matter closed. Thanks again to everybody who helped. Best regards, Jan -------------- 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/20180409/9d813781/attachment.asc>