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 -- Tim Sailer <[EMAIL PROTECTED]> Information and Special Technologies Program Office of CounterIntelligence Brookhaven National Laboratory (631) 344-3001 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
