Re: SSh Tunnel Over Squid
i think that if you enable proxy authentication you
can dificult this.
because the proxy authentication must be provided
before the tunnel is established.
--- Robert Tasarz <firstname.lastname@example.org>
> 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
> > 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 ;).
> Robert Tasarz.
> To UNSUBSCRIBE, email to
> with a subject of "unsubscribe". Trouble? Contact
____________________________________________________Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br