Re: How safe for firewall rule using

From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 10/27/05

Date: Thu, 27 Oct 2005 14:57:24 -0500

In the Usenet newsgroup, in article
<9jU7f.1035$!>, Somebody. wrote:
>"Moe Trin" <ibuprofin@painkiller.example.tld> wrote

>> At work, the solution is quite simple - no VPNs period. I know what
>> my "normal" network traffic looks like, and when I see something out
>> of the ordinary, I investigate.
> For this example, your "no vpns policy" would have to include blocking
> 443. Are you prepared to do that?

No, we have written policy in place - the results of violating it are
well known to the users and harsh. We don't have a problem with this, as
our users are not stupid. But let me point you back at the last sentence
above - and tell you to use a packet sniffer (any - even something like
ethereal) and notice the difference between Alice checking her bank
balance (which is prohibited here, but less likely to trigger disiplinary
action), and Bob using a tunnel for surfing pr0n or mailing the company
secrets to a competitor.

>nothing on the network core or permiter can detect/stop this activity in
>any useful way. It looks like very ordinary https traffic.

Then perhaps you need experience and more training.

>All it takes is a single click "OK" and a few prompts that most people are
>used to sailing through.

Train your users. See that your users are not operating as a privileged
user - if you can't get their applications to run without needing that,
get someone who can. Do not use known broken applications because they are
included in the desktop or what-ever, and it's the only thing your users
are capable of running. (Back in the early 1980s, my wife was using a
spread-sheet as a word processor, database tool, and who knows what else in
addition to it's primary use as a spread-sheet, because that was the only
thing her company thought to buy - but then, it was one of 2 PCs in a 40
person accounting department. Let me assure you that things changed over
time when they started noting massive productivity gains, even given that
an IBM PC-XT was a _substantial_ chunk of coin at the time.)

>Lots of people can be tricked into installing that, very easily,
>thinking it's something else. I agree, untrained users, etc etc.

Why are your users visiting such sites? It is required as part of their
job? (If so, I'd start by asking to disqualify those vendors.)

It just so happens that the most frequently used vector to date is that of
user stupidity (why is it that we laugh at the cartoon animal who falls for
the "stand here and press this button" gag, but so many of us seem content
to "click here and be amazed"?) (Alun Jones in c.s.f)

[Remember that one Alun?]

Social Engineering - Because there is no patch for human stupidity.
Uncrackable computers are already available. It's uncrackable users that
are in short supply.

Really - training makes a HUGE difference.

>So you have this user that installs something he shouldn't -- how
>often does that happen? Pretty often.

Very infrequently - for six reasons.

1. We've trained our users.
2. Corporate policy prohibits personal use of company computers, and not
   many business sites are so stupid as pull stunts.
3. We're not running windoze, never mind Outlook or Internet Exploiter.
4. Our users use an appropriate tool other than some crappy browser because
   it's they only piece of software they can (sorta) use.
5. Our users do not have root (admin) privileges.
6. Our user home directories are network mounted from a file server, and
   most are mounted 'noexec' meaning you can't even create a shell script
   (the *nix equivalent of a batch file) - never mind install shit.

>I'm thinking, if you block most of except for those addresses
>that are absolutely required, you would stop these programs since they
>use an address within that cloud as their local adaptor. means "this computer" - many O/S don't differentiate between
IP addresses within that range. In _most_ cases, that address is yourself,
and if you don't trust yourself, there's not a whole lot anyone can do.
>From a network standpoint - the answer is relatively easy - filtering
on the routers between subnets and at your perimeter. No packet passes
our routers unless the addresses make sense - if it's coming from "this"
network, the packet has a source address from this network, or alarms go
off. Packets coming in to "this" network don't have a source address that
claim to be "this" network or they are dropped and alarms go off. The fits that last rule too.

>So we're left with the question, does 'unblocking' all of
>open up any more exposures, and I'm thinking that yes, it does, to
>garden-variety SSL VPN clients.

Unblocking through on the loopback isn't going
to make a bit of difference. should never be seen in OR out
on a network interface - copper, fiber, or wireless. Some may want to
block specific ports or protocols on the loopback - if you don't trust
may serve some useful purpose. On the other hand, if they have those
privileges, it doesn't make a bit of difference what you do.

        Old guy