OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: Antwort: Re: Facts, not Fiction

Re: Antwort: Re: Facts, not Fiction

Bennett Todd (betrahul.net)
Mon, 10 Nov 1997 07:57:08 -0800

On Mon, Nov 10, 1997 at 03:58:04PM +0100, Hartmut.FehlingHamburg-Mannheimer.de wrote:
> So the question is: Is it smart to take the abilities of a FW-Host for
> granted and protect the network / the connected hosts only against stuff
> the FW-Host cannot protect against?
>
> Example: I have an NT-Host behind the FW which is vulnerable to POD or
> NetBIOS-Attacks. However, the FW-Host is supposed to filter out this kind
> of traffic. How far can I trust the _current_ products to do just that?

Interesting question! I don't know the answer to the question as asked.
However, you might be interested in why I haven't cared too much.

My take is that it's good to secure _all_ hosts ``as much as
practical''. How much is practical? That seems to get settled by trading
off the magnitude of the exposure (how much damage can a problem cause,
how likely is it to be exploited) -vs- the cost of fixing it
(implementation cost, inconvenience to users).

By and large, in the places I've been, the cost of tightening hosts down
to the point where they'd be safe if exposed to the internet has been
unacceptable, so we end up with the dread ``soft chewy center hopefully
protected by a hard crunchy shell''. Not the best possible security,
just the best we can live with.

Inside, I work (as resources permit) to tighten up security as far as can
be done without inconveniencing users. So we have a good MTA (qmail)
since that's cheap to implement and completely invisible to users, but
we use NFS, because doing away with that (or failing to use it, if we
were starting off from scratch) would too severely inconvenience users.
We use rsh with .rhosts files. We use YP for passwd data.

For the ``hard crunchy shell'' I pick the technology, using the same
sort of tradeoffs (implementation cost + user inconvenience -vs-
protection). Then I see what that technology succeeds in protecting.

For instance, an application proxy firewall, well-implemented, can be
expected to succeed in enforcing a basic stance of ``only allow what is
explicitly permitted --- completely block anything else'', at the
application traffic level. _Nothing_ unexpected in the underlying
protocol will make it though. By contrast, a packet filter may implement
that stance at the transport level, but when it comes to unexpected
games being played with oddball protocol options, it turns around to
``let anything through unless I explicitly think to block it''.

Example: if you want to toss all NetBIOS traffic between the inside and
the outside, any firewall technology (including a simple screening
router) should work fine. If however you wanted to permit some
restricted traffic through, an application proxy would probably be
stronger than a packet filter at guaranteeing that people can't exploit
weird TCP options to break your NT machines.

-Bennett

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:09:48 CDT