Dear all,

A lot of our students have caught onto the idea of using the freegate
proxy tunnelling application and are getting unfiltered access. I have
applied Craig consultings latest proxy.cfg but users can still get
through. I've made sure that the tunneling control is enabled too.

While we are on the topic, what are other organisations doing to tackle
this issue.

Thanks


--
mtaylor1979
------------------------------------------------------------------------
mtaylor1979's Profile: http://forums.novell.com/member.php?userid=18154
View this thread: http://forums.novell.com/showthread.php?t=350955

mtaylor1979 wrote:
> Dear all,
>
> A lot of our students have caught onto the idea of using the freegate
> proxy tunnelling application and are getting unfiltered access. I have
> applied Craig consultings latest proxy.cfg but users can still get
> through. I've made sure that the tunneling control is enabled too.
>
> While we are on the topic, what are other organisations doing to tackle
> this issue.
>
> Thanks
>
>

normally all this programs work on a similar way, they contact external
proxy servers, normal ones for firewall rules, no suspicious, to tunnel
request thru them. Best you can do is to install the software on your
pc, load wireshark, make sure this pc can not contact the internet,
start taking a lan trace with wireshark and use the program. After it
totally fails, stop the trace and check the servers it was trying to
contact to and then block them on your bm rules. Without initial contact
to this servers, this software will not work.
This is based on how mostly all this software works and i've never look
at this one myself but i do not believe it behaves in a different way.
anyway a lan trace will show you the behavior of the software and once
you know that, then is easily to block it

gonzalo

Mysterious wrote:
> normally all this programs work on a similar way, they contact external
> proxy servers, normal ones for firewall rules, no suspicious, to tunnel
> request thru them. Best you can do is to install the software on your
> pc, load wireshark, make sure this pc can not contact the internet,
> start taking a lan trace with wireshark and use the program. After it
> totally fails, stop the trace and check the servers it was trying to
> contact to and then block them on your bm rules. Without initial contact
> to this servers, this software will not work.
> This is based on how mostly all this software works and i've never look
> at this one myself but i do not believe it behaves in a different way.
> anyway a lan trace will show you the behavior of the software and once
> you know that, then is easily to block it

Unfortunately, FreeGate is specifically designed to resist such
analysis - its defined role is to allow browsing from (for example)
china, where the authorities are taking active steps to track and block
proxy sites; for this reason, it uses a mesh of around two hundred
discrete (and changing) IP addresses, and a successful connection to any
one of them will download a subset of alternatives; if the client can't
connect to any of its assigned IPs, then further IPs can be obtained by
MSN, Email or IRC (possibly away from your LAN) and entered manually.

Unfortunately, if you force a listener to 127.0.0.1:8567 and :8580,
the package just uses the next addresses up the chain (and similarly, if
you assign 8568 and 8581 as well) so you can't block them that way. and
as they listen on 127.0.0.1, you can't portscan your network for them.

You might be able to sarinwrap a custom checker to something like
ClientTrust, assuming they run that from a server; ideally though that
would also need to trap the udp connections to CT so that you only check
when BM queries your node, not on a timer. Depends on how you are
authenticating your BM users, I guess.

As a side question - Moral Dilemma time - if you don't own or control
a given endnode, *but* are responsible for enforcing access
restrictions, to what extent is it ethical to run code on the endnode
computers for enforcement purposes? How open need you be with such an
action, and how much disclosure is required as to the purposes of the
code and how it operates (which ok is STO, but that often reduces issues
in restricted environments)

In the above situation, I would be comfortable installing a service to
enforce policy on institution owned machines (in labs or semi-public
access nodes such as the library) but not on students personal machines,
should they be granted access from student accommodation....

David Howe wrote:

> Unfortunately, FreeGate is specifically designed to resist such
> analysis - its defined role is to allow browsing from (for example)
> china, where the authorities are taking active steps to track and block
> proxy sites; for this reason, it uses a mesh of around two hundred
> discrete (and changing) IP addresses, and a successful connection to any
> one of them will download a subset of alternatives; if the client can't
> connect to any of its assigned IPs, then further IPs can be obtained by
> MSN, Email or IRC (possibly away from your LAN) and entered manually.
>
> Unfortunately, if you force a listener to 127.0.0.1:8567 and :8580,
> the package just uses the next addresses up the chain (and similarly, if
> you assign 8568 and 8581 as well) so you can't block them that way. and
> as they listen on 127.0.0.1, you can't portscan your network for them.
>
> You might be able to sarinwrap a custom checker to something like
> ClientTrust, assuming they run that from a server; ideally though that
> would also need to trap the udp connections to CT so that you only check
> when BM queries your node, not on a timer. Depends on how you are
> authenticating your BM users, I guess.

I'll install and i'll look at it when i've got some time.
I accept bets :-)

Gonzalo

Mysterious wrote:
> David Howe wrote:
>
>> Unfortunately, FreeGate is specifically designed to resist such
>> analysis - its defined role is to allow browsing from (for example)
>> china, where the authorities are taking active steps to track and block
>> proxy sites; for this reason, it uses a mesh of around two hundred
>> discrete (and changing) IP addresses, and a successful connection to any
>> one of them will download a subset of alternatives; if the client can't
>> connect to any of its assigned IPs, then further IPs can be obtained by
>> MSN, Email or IRC (possibly away from your LAN) and entered manually.

Ok i've looked at it. It is the most sophisticate i've seen up to today
and very clever but still blockable. It requires more work than previous
ones but i was able to block it.


>> Unfortunately, if you force a listener to 127.0.0.1:8567 and :8580,
>> the package just uses the next addresses up the chain (and similarly, if
>> you assign 8568 and 8581 as well) so you can't block them that way. and
>> as they listen on 127.0.0.1, you can't portscan your network for them.

That's not an issue, even better, if your environment is properly
configured where browsers can only go our thru proxy and never access
the internet directly, loading on 127.0.0.1 is making you a favor and it
will block itself.

This is how i tested it

1. Bm server, 39sp1, with two interfaces, public and private. Default
filters enable to block all traffic except for proxies
2. PC with IE, configured to use proxy at xx.xx.xx.xx 8080. No dns info
on the pc and no way to get out if it is not thru bm http proxy.
3. Wireshark on the pc to study program's behavior.
4. Launch program:
a. With a listener on 127.0.0.1:8567, it does not work. It tries to
reach the dynaweb servers directly and fails
b. With auto mode enable, so using IE proxy settings, it works,so time
to start taking lan traces.

5. Review the lan traces to see which method uses to connect to the the
internet. Block this methods with access control rules

6. Test it again, still works, dam! :-)
7. Lan traces again to see the fall back mechanism it uses.
8. Read the traces, fall back mechanism identified, blocked with a rule
9. Test it again. Still works, dam ,dam! :-)
10. More traces to see the secondary fall back mechanism.
11. More traces reading, identify it, blocked with a rule.
12. Try it again........it is blocked, nice pop up on my pc screen
instructing me to shut down my firewall because it needs to contact the
internet to get updates ip. funny guys, you're going nowhere.

So right now it is block, but with some caveats:

1. I had to block yahoo.com. sorry about that
2. i had to block graphic formats, what means, it could affect the
display of other web pages
3. Help file tells you to send an email to get an update ip. You should
block this domain name and do not send/receive any email from/to them
and mark them as spam.
4. This is the initial work. Probably if someone enters a valid ip
address to update it, it will be able to work again. That means, you
should enable the http log files and check that. If you detect new ip
addresses using the same behavior as the previous ones, add them to the
rule again.

I hope that someone bets against me, so i can get some money for all my
hard work :-)

Gonzalo

Mysterious wrote:
> 12. Try it again........it is blocked, nice pop up on my pc screen
> instructing me to shut down my firewall because it needs to contact the
> internet to get updates ip. funny guys, you're going nowhere.
.... or go into emergency mode.

When THAT fails (and it isn't any harder to block) it asks for the IP
of a node to be entered manually.

That is the kicker - you are in the Position of the Interior; they
only need to find one address that works, you need to block ALL of them,
and the list today won't be the same tomorrow...

David Howe wrote:
> Mysterious wrote:
>> 12. Try it again........it is blocked, nice pop up on my pc screen
>> instructing me to shut down my firewall because it needs to contact the
>> internet to get updates ip. funny guys, you're going nowhere.
> ... or go into emergency mode.


Emergency mode was also blocked :-)

> When THAT fails (and it isn't any harder to block) it asks for the IP
> of a node to be entered manually.


Correct

> That is the kicker - you are in the Position of the Interior; they
> only need to find one address that works, you need to block ALL of them,
> and the list today won't be the same tomorrow...

Not correct at all. What i said, you have to study the behavior of the
program. The real issue is not the ip addresses but the methods it uses.
Regarding if a new address is manually entered, yes, it will contact the
outside and it will update the ip addresses but, as you;ve already
identified its pattern, a quick look at the proxy log files will show
that, so you'll have to block the new ones again but you'll have as well
the ip address of the pc making the request so you need a strong company
policy and get this guy, punish him and make it visible for other users.
Right now, it looks in the community as this program is undetectable and
this is not true and you have to let them go that you've got a method to
detect it and users will be punished for that.
Of course, the first defensive step is to avoid that the program gets
into the computer.

Regarding that the list of ip's won't be the same, that is not correct.
I've found two flaws on the behavior of this program that helps to keep
it blocked and identify the user.

So, it is the most sophisticate one till date that i've seen but still
blocable and if some one gets a new ip to contact, proxy log files will
show this action and will allow you to quickly block them and catch the
author. The big job is to identify its methods and fall back systems but
one you've got, as i succeed yesterday, it makes it easy to block.
Of course, this is a continuous race and you've got to keep up.

Gonzalo

Mysterious wrote:
> David Howe wrote:
>> Mysterious wrote:
>>> 12. Try it again........it is blocked, nice pop up on my pc screen
>>> instructing me to shut down my firewall because it needs to contact the
>>> internet to get updates ip. funny guys, you're going nowhere.
>> ... or go into emergency mode.
>
>
> Emergency mode was also blocked :-)
>
>> When THAT fails (and it isn't any harder to block) it asks for the IP
>> of a node to be entered manually.
>
>
> Correct
>
>> That is the kicker - you are in the Position of the Interior; they
>> only need to find one address that works, you need to block ALL of them,
>> and the list today won't be the same tomorrow...
>
> Not correct at all. What i said, you have to study the behavior of the
> program. The real issue is not the ip addresses but the methods it uses.
> Regarding if a new address is manually entered, yes, it will contact the
> outside and it will update the ip addresses but, as you;ve already
> identified its pattern, a quick look at the proxy log files will show
> that, so you'll have to block the new ones again but you'll have as well
> the ip address of the pc making the request so you need a strong company
> policy and get this guy, punish him and make it visible for other users.

Which is of course the point. The traffic is quite characteristic, but
unless your corporate/campus access policy permits punishment for
bypassing your lockdowns, you are playing whack-a-mole trying to review
logs, block IPs, then block the *new* IPs that get used when you have
blocked the first set.

I am assuming it is easier for the chinese, they can just shoot the
offenders, no need to follow the bouncing ball any further :)

> Right now, it looks in the community as this program is undetectable and
> this is not true and you have to let them go that you've got a method to
> detect it and users will be punished for that.

Indeed - detect, but not block.


> Of course, the first defensive step is to avoid that the program gets
> into the computer.
>
> Regarding that the list of ip's won't be the same, that is not correct.

I have 25 instances of the program here - there is obviously SOME
overlap in the initial IP lists, but not a great deal.

luckily, it appears to connect to ALL six of its initial IPs for speed
test purposes; Assuming that that list doesn't change for any given
instance of the program (it hasn't the few times I have run a single
instance, but that could just be system behaviour, I haven't done a test
on multiple hosts with a single instance. Deleting the ini file didn't
seem to change that behaviour) so once you have established a subset,
you could probably rely on detecting a fair percentage of the users.

Three items I did notice;

It appears they all use a browser id of "ie 6.0; windows nt 5.1 sv1"
which is old enough that it could be considered a detection vector in
its own right. I haven't seen one that hasn't (yet) but I guess they
could make that morph too. This is followed by a sslv3 handshake (which
I don't think 6.0 supports) but I doubt that would show in any sane log.

Second, the six-IP test is quite characteristic of its startup; six
https CONNECTs to different IP addresses within the space of about 3
seconds is not a common pattern, and in fact in my tests there were
noticably more test connects (the later IPs varied, but a block of
around 10-13 CONNECT tests to discrete IPs in about 3 seconds is common;
I assume that it gains a further list after connecting to its hardcoded
set, and tests those)

I could do some more testing, but I suspect if it is good enough to
get past the great firewall of china, I am not going to crack it :)