Hi, i think that if you enable proxy authentication you can dificult this. why ??? because the proxy authentication must be provided before the tunnel is established.
Marcos --- Robert Tasarz <[EMAIL PROTECTED]> escreveu: > 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] > > > ____________________________________________________Yahoo! Mail, cada vez melhor: agora com 1GB de espa�o gr�tis! http://mail.yahoo.com.br -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
