On Tue, 16 Dec 2003, Chuck Yerkes wrote:

>
>Me too.  Don't you hate it when a box that WAS a slave and
>has gone down comes back?  Months later?  Serving random
>people who happen to have bad luck to bind to it?

Yeah.. I've had that happen, it's definitely something you have to keep an
eye out for, but typically it manifests as 'I can't login', and since it's
a known step in any fault tree it's quickly located and fixed.


>Or the fact that about anyone can get your /etc/passwd info
>with some decent luck.

A whole other discussion as I said.. There is _no_ security beyond the
domain name string with NIS. If you require security because you don't
feel your internal LAN policy can trust NIS, then you shoudn't be using
it.


>The only thing that justfies using NIS is the threat of having
>to use NIS+.  A stupendous piece of crap.  "Oops, all the NYC
>machines decided to bind to hosts across the WAN so our WAN
>usage has skyrocketed from 10% to about 90% while performance
>has mostly just stopped."  And Sun had no workaround for this
>"oh, is that bad?" behavior.

As I mentioned in another email to another poster... NIS+ is a steaming
pile of .... I wouldn't touch it with a bargepole :)


>
>
>No, other choices where HESIOD for info, Kerberos for auth or,
>post 1998, LDAP.  SASL authentication (or SSL/IPSec encrypted
>paths - or even private networks for a cabinet of infrastructure)
>and I can scale and offer what NIS offers, just better.

OF course, but you're an expert, many are not, and of the 'easy' solutions
out there, NIS is generally one of the better ones. The real word
intervenes as always.

>
>But not the soft chewy inside?  I hate chewy insides.  Had too many
>incidents on LARGE LARGE (soft chewy) networks where someone got in
>SOMEwhere and was, afterwards, pretty much unrestricted.  I recall
>when I was told that someone came in through a modem that was left
>on on a machine that should never have HAD a modem.  I'll not forget
>that feeling as I pondered where he (usually a HE) might have gone
>and what we'd have to do to verify ALL of the data.  My infrastructure
>machines were locked down, despite common practices in the company.
>We'd set them up as an example of how the machines SHOULD be.

Infrastructure machines _should_ be locked down. However, there is a place
for things such as NIS in a large environment. It really depends on your
company and how you and they want to play it, what sphere of the world
you're in, what your writteb policies are etc... The fact is though, a
large chunk of the world uses NIS, despite more secure alternatives. I'm
not disagreeing with you on the security front, I'm as rabid as the next
Chuck... but sometimes all you can do is inform management of the risks
and let them make the call.

>I don't lock the rooms within my house, but I do secure all the machines.
>
>(and I can glance in all the room and have a pretty decent idea if
>something is missing or changed.  That's just hard with 50 servers
>with 5TB of data.

Yes, but thats a whole different topic.. security management, not 'using
NIS' :)

>> a solution using rdist is of course better, but sometimes requires more
>> work than a novice or even an intermediate administrator would be capable
>> of, and it certainly isn't working 'out of the box'
>
>Except for the "change the password" problem that rdist never addressed.

Yeah, it's a problem, you have to centralise that part of it somehow, and
then you always get people changing it on the individual boxes and
wondering why it changes back.. all you can do is document and train
really.


> >I'm happy to rdist/cfengine lots of config files that turn on better
>authentication mechs.
>

More power to you.. :)

Cheers,

Al