>Return-Path: Brent @
GreatCircle .
COM
>Received: from miles.greatcircle.com (miles.greatcircle.com [198.102.244.34]) by dns.eng.auburn.edu (v8.7.3/8.6.4) with ESMTP id UAA06236 for <Doug .
Hughes @
Eng .
Auburn .
EDU>; Wed, 17 Jan 1996 20:54:24 -0600 (CST)
>Received: from [198.102.244.40] (pm-ppp-2.greatcircle.com [198.102.244.40]) by miles.greatcircle.com (8.7.1/Miles-951221-1) with SMTP id SAA05092; Wed, 17 Jan 1996 18:51:13 -0800 (PST)
>X-Sender: brent @
miles .
greatcircle .
com
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Date: Wed, 17 Jan 1996 20:50:40 +0100
>To: Doug Hughes <Doug .
Hughes @
Eng .
Auburn .
EDU>, firewalls @
GreatCircle .
COM
>From: Brent @
GreatCircle .
COM (Brent Chapman)
>Subject: Re: how secure is NIS
>
>At 5:57 PM 1/17/96, Doug Hughes wrote:
>
>>Thanks, and they work very well for us too. But, does this mean that you
>>think that 'block ports 111 and 2049 at the router to the outside world'
>>is not a good suggestion?
>
>There's nothing wrong with it, but it doesn't accomplish what the original
>message implied it did: block attacker access to NIS servers.
>
>Actually, there is something wrong with it: it's coming at the problem from
>the wrong direction. Instead of making lists of things to deny, you should
>be making lists of things to permit. The list of things to permit is
>usually much shorter, and the consequences of leaving something off that
>list are much less severe (from a security standpoint) than the
>consequences of leaving something off a list of things to deny.
>
>I don't generally block access to NIS or anything else explicitly; I block
>everything by default, and enable access only to certain services, which I
>understand, need, and can safely provide access to.
>
>
Ah, I see your point. Of course, being an academic institution with a mostly
free-access-to-the-internet-for-education-purposes type policy in place, we
block bad/evil/unwanted things and allow all else. So, the step is
useful for us. Your approach is probably what most corporate sites should
use, but it's not particularly desirable here. An application
gateway could possibly work with a lot of setup and maintenance work, but
it hasn't been seriously investigated yet to my knowledge.
In our case, the list of things to permit would be rather unwieldy. :)
Every Yin has a Yang.
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
doug @
eng .
auburn .
edu
Pro is to Con as progress is to congress
|
|
