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.
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 becausetunnels 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.
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>