🚀 go-pugleaf

Well,
	In response to my recent query on how to best secure NIS for a wide
range of very different machines running very different versions of unix, I
received a number of replies. It seems (as I suspected) that this is a fairly
difficult thing to do. What our goal is here is to provide NIS services to a
large diverse set of users. These all reside across a range of (soon to be
near a dozen) routed subnets (a point I failed to mention in my initial query).
They all reside on the back side of a firewall but password threats (and
others) don't always come from outside. To that end, we wish to restrict the
access to even the encrypted passwords to only those processes that
require them. I fully realize that this is not totally possible, yet I
would like to make it a non-trivial task.
	I am now more convinced that what we will probably
do is split up the domain so that the more sensitive resources are
served by a small set of NIS slaves that will run some form of
shadowing on both server and client side. For the rest of the
machines, we will certainly implement some set of measures probably
including many of those listed below. This, along with well chosen
passwords and constant vigilence on the machines containing the more
vital resources will be quite sufficient for the level of security we
currently require.

	My thanks go out to all who responded. Below I list my initial
questions (surrounded with ">>>>"s) followed by the (separated with
double rows of "====="s) sections of the responses that pertained to each
question with the responder's name and/or .signature following each reply.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Hi All,
> 	I have a question. Have any of you set up NIS in such a way
> that:
> 	- The NIS servers only allow a certain set of clients to bind
> 	to them. THis could be a set of network addresses in certain
> 	ranges or an explicit list of ethernet addresses, hostnames,
> 	or IP addresses.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

On Sun systems the jumbo NIS security patch 100482-02 permits you to set up 
your NIS servers so that they will only provide maps to machines whose IP
addresses meet certain criteria. (Basically whether, once ANDed with a mask,
the IP number matches a template.) This is stored in a file /var/yp/securenets.
The syntax is (for example)

131.111.0.0 255.255.0.0

which would cause all the machines in 131.111.*.* to be able to get the maps 
but no-one else. 
--------
Bob Dowling:                    UNIX Support,
                                University of Cambridge Computing Service,
rjd4@cus.cam.ac.uk              New Museums Site, Pembroke Street,
+44 223 334728                  Cambridge, UK.  CB2 3QG.
===============================================================================
===============================================================================

You can get 1) by obtaining a patch for NIS from Sun.

For better security, you should go for NIS+.
NIS+ servers can run in NIS compatibility mode, allowing NIS clients
to bind to them. I'm not shure about how much security you have to sacrifice
when you run in NIS compatibility mode.

Birger A. Wathne
Email  : birger@sdata.no        birger@ii.uib.no
Private: Fjoesangervn. 133, N-5032 Minde           Tel: +47 5 200062
Work   : Skrivervik Data A/S                       Tel: +47 5 543740
         Thormoehlensgt 55, N-5008 Bergen          Fax: +47 5 322853
===============================================================================
===============================================================================

All you have to do is to subnet and put all of the machines you want to
use that server on the same logical subnet.

Greg Elkinbard                       # aka Lord Cromis the DragonSlayer
elkinbar@cromis.EBay.Sun.COM         # or gregory.elkinbard@Ebay.Sun.COM
===============================================================================
===============================================================================

Difficult to impossible. It is possible to restrict answering NIS
queries to certain clients. This is what Sun's patch 100482-02 does.
It is not possible to prevent clients to bind to a server for their
domain on the same net. The call ``who serves this domain'' is
implemented through broadcast RPC. Broadcast RPC works via the
portmapper and obscures the origin of the call to the server.
But if it's the data you want to guard, Sun's 100482-02 patch does
the yob.
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
===============================================================================
===============================================================================

The first thing could be accomplished by either configuring the
router to deny IP packets from outside to inside for reversed ports
used for RPC and NIS. Also SUN patch 1004??-2 does that, with a
/etc/securenets file.

                    /~~~~~~~~~~~~~~~~~~~~~~~~~~\                A/~~\A
                    | - From the keyboard of - |               ((o  o))___    
                    |      Rob J. Nauta        |                 \  /     ~~~
    #               |    rob@wzv.win.tue.nl    |  #              (--)\    #  
----#---x---x---x---|   Phone: +31-40-833777   |--#---x---x---x---x---x---#---
    #               \__________________________/  #                    \  #   
----#---x---x---x---x--| |--#---x---x---x-| |--x--#---x---x---x---x---x---#---
    #)( \\|  /*\/|((   | | )#(//  \\)(/  \| |(// \#(//  \|/   \\)|(/   \|)#(/
===============================================================================

For sun there is a patch number 100482-02 that fixes this.

--
Regards
Lars Berntzon			Email: lab@cap.se
Cap Programator AB
Sweden

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> 	- The Clients only allow themselves to bind to this certain set
> 	of NIS servers.
> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Sun's NIS has an option on the slave and client machines (called -ypsetme(?))
which allows the specification of a particular *single* master or server. This
is of less use. 
--------
Bob Dowling:                    UNIX Support,
                                University of Cambridge Computing Service,
rjd4@cus.cam.ac.uk              New Museums Site, Pembroke Street,
+44 223 334728                  Cambridge, UK.  CB2 3QG.
===============================================================================
===============================================================================

Yes when you run ypinit you can specify a list of servers.

Greg Elkinbard                       # aka Lord Cromis the DragonSlayer
elkinbar@cromis.EBay.Sun.COM         # or gregory.elkinbard@Ebay.Sun.COM
===============================================================================
===============================================================================

That would be a good idea. Modern implementations only allow binding
to servers run by root. They also, by way of their implementation,
will only bind to server on the same net. If you can't trust your net,
there's really nothing you can do: they can present themselves on the
net as the ``trusted'' NIS servers.
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
===============================================================================
===============================================================================

The second point is not really relevant, since it's done in the /etc/rc
files. If you worry about a cracker binding to another machine outside,
he must already be root.

                    /~~~~~~~~~~~~~~~~~~~~~~~~~~\                A/~~\A
                    | - From the keyboard of - |               ((o  o))___    
                    |      Rob J. Nauta        |                 \  /     ~~~
    #               |    rob@wzv.win.tue.nl    |  #              (--)\    #  
----#---x---x---x---|   Phone: +31-40-833777   |--#---x---x---x---x---x---#---
    #               \__________________________/  #                    \  #   
----#---x---x---x---x--| |--#---x---x---x-| |--x--#---x---x---x---x---x---#---
    #)( \\|  /*\/|((   | | )#(//  \\)(/  \| |(// \#(//  \|/   \\)|(/   \|)#(/

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 	- The NIS password maps are not generally obtainiable. By
> 	this I mean that the client machines use the maps for login
> 	authentication, BUT J.Fred.User cannot obtain the encrypted
> 	passswords.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Using shadow passwds is difficult in NIS, as differnt vendors do
it differently, and some not at all. You would have to get PD
software and hack it up yourself.

In NIS+ you can set permissions on each field in the database
(Much like UNIX file permissions).

NIS+ is available in Solaris2.0. The Solaris 2.0 CD also contains a
NIS+ implementation for SunOS 4.1 hosts (Server side only).

Birger A. Wathne
Email  : birger@sdata.no        birger@ii.uib.no
Private: Fjoesangervn. 133, N-5032 Minde           Tel: +47 5 200062
Work   : Skrivervik Data A/S                       Tel: +47 5 543740
         Thormoehlensgt 55, N-5008 Bergen          Fax: +47 5 322853
===============================================================================
===============================================================================

You need to be able to get at the user data for things like
ls(1), talk(1), finger(1) etc. You would want to restrict
the distribution of encrypted passwords. Although some NIS shadow
password implementations do exist, none of these will work
in a mixed vendor environment. Personnaly I like the way SUn has
implemented shadow passwords in 4.x (no changes to user code
necessary). The BSD way is also nice: only fill in the encrypted
password in struct passwd when root. Something similar could be
done for NIS: if the query is from a reserverd port, send the encrypted
password, else don't. Not all vendors have added the extra bit of security
that using reserved port in RPC gives.

-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
===============================================================================
===============================================================================

The third could be done with shadow passwords, like sun's C2 and pwdauthd
daemon. This has the disadvantage that the passwords fly over the net
in cleartext.

                    /~~~~~~~~~~~~~~~~~~~~~~~~~~\                A/~~\A
                    | - From the keyboard of - |               ((o  o))___    
                    |      Rob J. Nauta        |                 \  /     ~~~
    #               |    rob@wzv.win.tue.nl    |  #              (--)\    #  
----#---x---x---x---|   Phone: +31-40-833777   |--#---x---x---x---x---x---#---
    #               \__________________________/  #                    \  #   
----#---x---x---x---x--| |--#---x---x---x-| |--x--#---x---x---x---x---x---#---
    #)( \\|  /*\/|((   | | )#(//  \\)(/  \| |(// \#(//  \|/   \\)|(/   \|)#(/
===============================================================================
===============================================================================

For sun there is the C2 package.

--
Regards
Lars Berntzon			Email: lab@cap.se
Cap Programator AB
Sweden

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> 	This would need to be implemented on a very diverse set of
> machines. We currently run: Sun SPARCs (under 4.1.x and Solaris),
> DECstations (2100, 3100, 5000 all running 4.2 variations), SGI
> (Indigos and Irises running IRIX 4.0.x), IBM (rs6000 320s, 340s
> running AIX 3.2.x). Note that most of these platforms do NOT use
> a shadow password file. Is this a *very difficult thing to do*
> or not? What hardware/software do you use for the NIS servers?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Solaris 2.0.1 and above supports NIS+ which will give you all that
and more.

Greg Elkinbard                       # aka Lord Cromis the DragonSlayer
elkinbar@cromis.EBay.Sun.COM         # or gregory.elkinbard@Ebay.Sun.COM
===============================================================================
===============================================================================

Other than the Dec stuff, you sound like us! The latest patches for security
for SunOS 4.1.2 (and I think 4.1.1) allow the host access restrictions
you are looking for. Our unix person tells me that the SGI client can be
forced to bind to only one server, but the Suns will change servers if
they think the main one has gone down. There is a package called securlib
(a shared library) that gives you control of all the NIS daemons (and would
for instance let you stop people getting to ypasswd from certain machines
but we don't have it in yet.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada
===============================================================================
===============================================================================

If you want to protect your maps from the outside world:
use Suns as NIS server (w/ patch 100482-02)

The password thing is much more difficult to impossible. Probably
requires source code of ypserv or `secure map -> shadow file'
daemons on other machines.

SunOS, being the ``reference implementation'' of NIS is always ahead
in protection. The people of SGI are always close behind. Ultrix and AIX
are lagging behind. Suns and Indigos/Irixes can run ypbind -s, which makes
ypbind save from the outside. IRIX 4.x has the added feature of being
able to allow/deny access to the portmapper from the outside. This only
buys you something in conjunction with other measures and doesn't protect
servers (like ypserv) by itself.

AIX still allows anyroot to do a ypset, remotely. DEC is probably even further
behind (they always were, wrt NIS/ Sun RPC)
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
===============================================================================
===============================================================================

This could be a problem, since some of them do not offer much 
configurablity, and NIS sources are not available without a licence.
Probably some reprogramming of daemons might be needed.

Myself, I'm just a mere (but knowledgable) user here. The machine is
a private SUN at the sysadmin's home (sysadmin of the university where
I studied). You could ask him about his setup. (wietse@wzv.win.tue.nl)
Since he wrote tcp_wrapper, ehe knows a lot about these things. The
setup here is very loose since it's UUCP-only, and we need to experiment
around, which is not possible with maximum security.

                    /~~~~~~~~~~~~~~~~~~~~~~~~~~\                A/~~\A
                    | - From the keyboard of - |               ((o  o))___    
                    |      Rob J. Nauta        |                 \  /     ~~~
    #               |    rob@wzv.win.tue.nl    |  #              (--)\    #  
----#---x---x---x---|   Phone: +31-40-833777   |--#---x---x---x---x---x---#---
    #               \__________________________/  #                    \  #   
----#---x---x---x---x--| |--#---x---x---x-| |--x--#---x---x---x---x---x---#---
    #)( \\|  /*\/|((   | | )#(//  \\)(/  \| |(// \#(//  \|/   \\)|(/   \|)#(/
===============================================================================
===============================================================================

Here is the procedure to get NIS pretty secure on SUN's.

	1) Install tcp_wrapper. Avaliable from uunet and cert. Look
           in the FAQ for an archive site(or I will look it up if you
           need me to). This should work under Ultrix and SunOS. Do
	   not about the others.

	2) Get a "secure" version of portmaper. It was posted to one 
 	   of the sources groups. If you need me to I can get you
	   a copy. It again should work on BSD derived machines.

	3) Start all ypbind's that support it with -s option.

	4) Protect you YP master and Slave servers(SUN only) with
	   either the SUN patch 100482-02 or the ypserv avaliable
	   from the following archive:


	   02 Host ltisun.epfl.ch

            File -rw-r--r-- 00089751 1992 Jan 20 00:00:00 GMT ypserv.tar.Z
	
	  The SUN patch only allows you to specify a local DNS domain.
	  The other patch allows you to specify actual host ip #'s(which
	  I think is better).	

	5) Only use SUN masters and slaves because of patch 4.

	6) Choose a domainname that is not easily guessed. Classic STO.

	7) Look into using the shadow password suite avaliable on
	   various archive sites. It should run on a varity of
           hosts. The only problem is password propagation. You
	   will have to "roll" your own way of propagating the password
	   files or use something like ACmaint from purdue.

	8) Make sure all machines are as secure as possible. Install
	   all security related patches on all machines that have them.

	9) Run COP and all machines at least once and fix as many
	   of the errors as possible.

	10) Run crack on the password files on a regular basis. So if
	    someone manages to steal your password file at least
	    you will have a fighting chance.

	11) Install a "facist" password changing program like passwd+
	    or npasswd.


Basically, if you want secure NIS, you need to be sure that your machines
are protected. 

Note: Doing 7 above and getting rid of the password map would really be the
      best. You could still run NIS but just not serve the password map.


	
-- 
Rob Montjoy                   		- Rob.Montjoy@UC.Edu
Computer Engineer    	      		- montjoy@ucbeh.BITNET
University of Cincinnati      		- montjoy@babbage.ece.uc.edu
Electrical and Computer Engineering	- uunet!uceng!rmontjoy

-- Standards are illusions of many faces.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

--
###########################################################################
### Jim Hendrick (hendrick@ctron.com)   ###                             ###
### Cabletron Systems Inc.		###   " My opinions, etc are    ###
### P. O. Box 5005			### exclusively the property	###
### Rochester, NH 03867-5005		### of nobody in particular."	###
### (603) 332-9400 x1457		###				###
### fax:(603)332-1019			###                             ###
###########################################################################