Hi Patrick,
Several people have figured out the joys of reverse tunneling, and are
now using SSH tunnels to bypass the corporate VPN get into the office
using tunnels they set up in advance for that purpose.
I don't want to disable SSH tunneling completely; it's actually quite
important that users be able to, say, tunnel an rsync connection through
to a machine at the data center. I don't want them getting into the
office that way, though.
Is there a way to stop SSH from allowing this? Maybe a way to deny
reverse tunneling to office IP address space?
SSH tunnelling is different to rsync over SSH I believe.
(1) rsync tunnelling, rsync invokes ssh, and then invokes rsync on the
remote server just as if it were a user invoking ssh and typing rsync
at the shell, the data for rsync transfer is then tranferred in the
same way standard input and output are transported for user invoked
programs (another way to think of this is the way old dialup modems
worked, you couldn't have voice and data at the same time, so the data
takes the place of the voice, just as in SSH rsync's data takes the
place of the shell session).
(2) The tunnelling to which I think you are referring is also known as
tcp forwarding, where SSH opens up extra ports on both hosts to listen
and send and tunnels the data for those ports in the background while
the user continues a normal SSH session (you might think of this like
a modern ADSL connection, both voice are combined onto the one phone
line (or over the same encrypted SSH connection) but it's done in such
a way that they don't interferre)
(3) Or perhaps you are referring to tunnelling where the users,
install their own tunnelling software that works much the same way as
rsync in order to tranfer whatever they want.
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
