RE: SSh Tunnel Over Squid
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 :)
From: Anders Breindahl [mailto:firstname.lastname@example.org]
Sent: Saturday, 14 May 2005 4:29 AM
To: Tim Sailer
Subject: Re: SSh Tunnel Over Squid
O.k. I admit not to have ever wondered about that perspective. Thank you for
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
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com