RE: can Hopster traffic be blocked?
From: Burton M. Strauss III (BStrauss_at_acm.org)
To: "whiplash" <firstname.lastname@example.org>, <email@example.com> Date: Thu, 5 Aug 2004 10:25:03 -0500
1. Remember, a port is just a number. By CONVENTION many ports are used for
specific things, but there's nothing that REQUIRES it. If you want to set
up a dns daemon listening on port 22, it's dns not ssh...
2. I'd suggest you give it a try - a lot of these tools have many, many
fallbacks so that if one avenue is blocked it tries something else. Thus
you may need to block thing a, figure out how it continues to connect (thing
b) and repeat.
> -----Original Message-----
> From: whiplash [mailto:firstname.lastname@example.org]
> Sent: Wednesday, August 04, 2004 6:23 PM
> To: email@example.com
> Subject: Re: can Hopster traffic be blocked?
> Prakash Purushotham wrote:
> > Any suggestions on how I can block hopster (and other similar socks
> > based tunneling applications) from tunnelling out.
> tcpdump and ehereal are often the syadmin best friends. :)
> Ok, I downloaded this hopster, installed it on a win box, started
> squid on my home linux firewall, putted a rule in FORWARD chain to
> drop packets coming from the win box and then I started to observe.
> hopster wasn't apparently able to automatically detect the squid proxy, so
> I manually configured it.
> Then i started some applications, like an irc client and
> configured them to
> use the localhost socks proxy that hopster binded.
> Ok: what did ethreal showed me?
> First: in all tests I've performed, hopster seems to use just one remote
> http tunneler:
> CONNECT 126.96.36.199:443 HTTP/1.0
> If this observation is correct, a simple acl that denies the
> CONNECT method
> to 188.8.131.52 should be suficient.
> Moreover: despite of the port showed above, the traffic isn't actually
> HTTP/1.0 200 Connection established
> NOTICE AUTH :*** Looking up your hostname...
> ......._NICK whiplash
> So, it is also possible to write content-based acls.
> Blocking hopster, at the moment, seems to be quite easy, if
> things are really like they appear in my quick and dirty
> Things could become more tricky and interesting, anyway.
> Try and imagine nasty applications that really use ssl and
> miscofigured open proxies that support CONNECT method, for