Apologies if I was unclear. The type of forwarding I was referring to
was indeed TCP forwarding. Using rsync as an example may have been
confusing: what my users are doing is using TCP forwarding to set up
tunnels over which they can use rsync's native protocol, since they have
no direct access to the destination machine. For example, they'll use
SSH to access a gateway machine, and set up a port forward from that
gateway to the destination host behind it, on port 873, to tunnel rsync
connections. They also do the same with other protocols, since they
have no direct access to the destination boxes; all they have open is
SSH to a gateway box.
My problem is that I don't want to disable this sort of access by
disabling forwarding altogether. The sort of access I would like to
deny would be to prevent users from SSHing to a remote host in the data
center, and then reverse-tunneling a port back to their local
workstation. In other words, I don't care if they forward connections
into the data center, but I don't want them tunneling stuff back into
the corporate office.
As a more concrete example of why I want to stop this sort of thing, we
currently have machines that sit behind load balancers. The load
balancers may have port 80 open to the world, and forward connections
to, say, port 8000 on a webserver that sits behind them. In the past,
I've caught users shutting down the port-8000 webserver, and then using
an SSH connection to forward port 8000 back to their workstations. As a
result, they've managed to open up corporate machines to the Internet,
bypassing our firewalls.
What I'm hoping I can do is disable the ability to set up these tunnels
back into corporate, without destroying the ability to access internal
machines over non-SSH protocols via the SSH gateways. In other words,
I'd like to allow forwarding, but only in one direction.
Policies are great, but I see this as a major security risk. I'd rather
not rely on policy alone if there's anything else I can do.
Chris Jensen wrote:
Having said that, TCP Forwarding (number 2) can be disabled with the
AllowTcpForwarding option in the servers sshd_config.
The style employed by 1 and 3, is harder to prevent, you can try using
something like rssh or scponly to restrict the shell so that they
can't execute the tunnelling programs, or you can try locking down the
server - make sure they can't write to /bin directories, and make
anywhere they can write (eg /tmp, /home, /var) non executable (mount
-o noexec)
However, I would strongly recommend trying to deal with this as a
people problem rather than a technical one - if they've figured out
how to tunnel, they may well figure out another way once you lock down
tunnelling.
If this is a security issue then take it to management and ask them to
treat it appropriately, reprimanding people where necissary for
breaching the policy.
As the sshd_config man page says:
Note that disabling TCP forwarding does not improve
security unless users are also denied shell access, as they can
always install their own forwarders.
Regards,
Chris
