Mysterious wrote:
> Well if you do not have a security policy why then you're blocking
> sites on your firewall?

Its amazing how many sites have a security policy that doesn't have
any teeth. Said sites usually resort to technological fixes (net nanny
url filtering, usually) and even then, have to cut so many holes for
senior management and special interests that they are near meaningless.
As an example, "no sport. except for the CEO, who can if he wants. Oh,
and except for football team xxxx as we are sponsoring them and
marketing need to see the product placement on their site. Oh, and apart
from this guy who needs to check the..." and so on.

Often the worst you can do is report them to HR, who will then ask
"well, what are they looking at then?"; at that point you then have to
explain that you don't know, and that the URLs they are connecting to
actually go to innocent looking servers running legitimate sites, but
that you *know* they are actually using filter bypass software....

Common response then is to tell you to stop them doing it, or at least
present something other than circumstantial evidence.

Campus networks are even worse. Often, you are allowing access from
student machines in labs, professors in offices, and students in their
rooms in on-campus accomodation. You are supposed to block "the bad
stuff" and have a AUP that allows you to block a given node if you don't
approve of their traffic - but again, if you are depriving someone of
access, you could well be required to justify it to non-technical
administration bods, and "trust me, its circumstantial but almost
certainly correct" will only cut it for so long (particularly if its a
tenured professor you just blocked). We haven't even gone into the
privacy issues involved if you have law or medical queries, or the
likely reaction if the students start protesting you blocking "privacy
software"

> First step is always a good security policy, with clear procedures
> and actions to violations. Without that, you will never make your
> environment save.

Agreed. Given a good enough policy (with a high enough penalty for
infraction) you don't even really need to monitor. A few good examples
made of people accessing pr0n or gambling sites from their workstations
using software specifically designed to evade lockdowns, and the cost of
doing so outweighs the benefits.


> Once you've got the policy, make sure every knows that and the
> sanctions for policy violations. Then you can start enforcing your
> security policy, for example ,at your firewall.

And there you hit the first sticking point. Often the worst offenders
are not in the cubicle farm (although once something like this hits
there, it spreads like wildfire) but in the private offices.

Actually, my biggest security headache ATM isn't bypass software like
this, but cheap wireless internet dongles on machines *also* attached to
the corporate network. Or (on two occasions) BUILT IN Wifi on the
laptops accessing an external hotspot "accidentally" from the pub across
the road...

> The solution to this program is not a simple two clicks on imanager
> to add a couple of websites to a blocking rules and you're done. It
> requires a combination of steps to do so. With this first steps,
> you'll be able to block the program but after that you'll still have
> to monitorize because one of your goals have to be, not only block
> the program, but reduce the number of users using it. So if you have
> a good policy, you have blocked the program, you monitorize the
> network to detect new attempts, you catch them and you apply the
> security policy, the number of users will reduce considerablely.

Its a war; at least for now, if you have a way to detect them then you
have enough circumstantial evidence to at least investigate the end
user's pc. There is no guarantee that will remain true tomorrow, but as
you say, the first (and most important) step is a strong AUP and
penalties for its violation, backed by HR sufficiently up the tree that
low ranking offenders will be made an example of.

> As programs get more sophisticate, it is not enough just to apply a
> few rules to the firewall, but a complete sets of procedures.

Indeed. log analysis is currently good enough, but I imagine that the
authors will do something about that. At some point you need to move to
full packet analysis, using something like snort-inline, or possibly
even checking which URLs the target attempts to resolve inside the
envelope - but there we are moving well beyond what is possible in a
bordermanager environment really.

David Howe wrote:

>
> Indeed. log analysis is currently good enough, but I imagine that the
> authors will do something about that. At some point you need to move to
> full packet analysis, using something like snort-inline, or possibly
> even checking which URLs the target attempts to resolve inside the
> envelope - but there we are moving well beyond what is possible in a
> bordermanager environment really.
>

I've wrote tid 7001948.
I put there the rules i used to block freegate.
As i said, the key point is to know what system this program is using
and for that, i had to read tons of lan traces using wireshark to detect
it. It is using the steganography method, hidden the info into media and
gif files.
After blocked, i allowed it to contact the internet again and get a new
set of ip addresses. There were only 4 news ip's, added them to the new
created rules and it was blocked again. It does not have infinitive ip
addresses to use so it tries to reuse the previous ones and new updates
are decreasing the numbers of ip's, make it easier to add them to the
rules and block it again. It is not a guaranteed process but believe is
a good base to make it harder to bypass bordermanager.

Hope it helps

Gonzalo