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 ;). Regards, Robert Tasarz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
