Putty (or OpenSSH or alternatives) will also allow you to redirect a local port to one running on a remote host. It is all too easy to redirect to an FTP server running elsewhere via SSH over HTTP and move sensitive data. Squid handles this well -- if you specify a keepalive it is completely usable for almost any type of traffic, including RDP/ICA sessions where you think the proxy would introduce some sort of latency.
I have tried to work out a reasonable way to block this behaviour, but all solutions seem to impact on the usability of the proxy server. Telnetting to the remote port will normally give you an SSH header so maybe some sort of script running regularly, testing connected hosts with remote port 443/80 (based on netstat output perhaps), grepping for SSH and then cutting (http://freshmeat.net/projects/tcpipcutter/) and blocking the remote host would work? ...until they change the SSH connection header :)
Cheers,
Mike
-----Original Message-----
From: Anders Breindahl [mailto:skrewz@skrewz.dk]
Sent: Saturday, 14 May 2005 4:29 AM
To: Tim Sailer
Cc: debian-firewall@lists.debian.org
Subject: Re: SSh Tunnel Over Squid
O.k. I admit not to have ever wondered about that perspective. Thank you for
correcting me.
I am on these mailing-lists to learn. I often do, too.
Regards, Anders Breindahl.
On Friday 13 May 2005 22:07, Tim Sailer wrote:
On Fri, May 13, 2005 at 07:38:31PM +0200, Anders Breindahl wrote:
Not an answer and non-technical:
What is your motivation for actually stopping this tunneling? What harm
does it do to your network, both from a juristidical and a technical
point-of-view?
I am asking out of interest, as I could easily be that fellow behind your
gateway, merely wanting to do some secure communication -- something
which your setup to a large extent prevents me from.
Most entities that have a firewall are trying to protect their networked
resources from 'outsiders'. An ssh tunnel can be configured to bypass that
same firewall, allowing unrestricted access into the firewalled areas.
Also, most sites that have firewalls and proxies have an acceptable use
policy that forbids/restricts access to certain type of sites from
business-owned machines, or during normal work hours. It could be a simple
matter of security policy enforcement.
For us, all the above applies, and also we try to keep the exfiltration of
proprietary research data from happening until the results are offically
released.
Tim
--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org