[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SSh Tunnel Over Squid

On Sat, May 14, 2005 at 05:12:28PM +0200, Robert Tasarz wrote:
> Hi,
> On Sat, May 14, 2005 at 01:54:37PM +0800, Mike Valvasori wrote:
> > 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.
> Hmmm - in case of ftp it seems not so easy... but if you want to send
> something outside and have ssh--why to bother with ftp when you can use scp?
> Or be creative--put WebDAV server somewhere outside for example (accessible
> by https of course) :).
> > 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 :)
> Or simply they put ssh session inside of ssl tunnel. Perfectly with key
> autharization of both sides, so you even cannot check what protocol they are
> transmitting inside (ppp comes in mind) :). 
> In other words - give me one month, maybe less, and reasons to be desperate
> enough and I'll write tunnel for sending ip traffic by http in both
> directions as valid png pictures :) (and I'm guessing someone must done
> something similiar till now).
> Sorry for not suggesting any solution, but I simply don't see any good enough
> for preventing all possible kinds of such abuses. For me only method is policy
> for personnel setting what they can do and adequately restrictive consequences
> for breaking it. And... not to strict rules on firewall - then most of abuses
> aren't too clever and easier to detect ;).

The one way I've started looking for things like this is to watch for long
running connections through the proxy. Normal HTTP traffic is short bursts.
When you have a connection of 5 minutes or more, you either have a large
file  transfer, which should be evident in the SQUID logs, or something else.
THe 'something else' has proven to be real interesting on my end. Word of
advice: Corkscrew . It's evil. As is the various utils that work over tcp 53.


Tim Sailer <sailer@bnl.gov> 
Information and Special Technologies Program
Office of CounterIntelligence 
Brookhaven National Laboratory  (631) 344-3001

Reply to: