Re: SSh Tunnel Over Squid
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.
Reply to: