Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm currently trying to configure an NIS server with restricted access such that the passwd and group maps are exported to "trusted" hosts only. To this end, I have tried creating a netgroup (in the aptly-named file /etc/netgroup) containing the names of trusted hosts and I wanted to add a rule like

ALL:ALL EXCEPT @nis_netgroup

to /etc/hosts.deny. This has a double benefit for me: it restricts access to both the NIS maps and an NFS share. There are several issues with that approach, however, that I need help with:

  • This is not very secure as host names can be easily spoofed
  • The yp tools insist that the domain name for all my hosts is .local, regardless of the search domain I have set. So even if I had set up a domain like .my.domain and my NIS server was named server (so that its FQDN would be server.my.domain), after binding to that server, ypwhich would return server.local. So this requires me to set "strange" host names in the netgroup file.
  • Even if I pass both of the above steps, it doesn't work: the NIS server machine keeps trying to bind to itself and fails.

The one clue I found in /var/log/syslog that could pertain to this problem:

named[<pid>]: bad zone transfer request 'local/IN'

What does this mean?

I have administrated a similar setup in the past except that all clients were configured with static IPs so /etc/hosts.allow simply listed these IPs while /etc/hosts.deny would deny any other requests. The reason I can't use this approach in the current setup is that I'm using dynamic DNS with DHCP-assigned IPs for the clients. Is there a way to let host access be controlled via the dynamically assigned IPs (i.e. to do paranoid hostname-address lookups using the dynamic DNS)? The hosts_access(5) page says I can use a string starting with / to specify clients from a file so I thought I'd use that syntax in conjunction with my DNS zone file. No joy! The NIS server still fails to bind to itself under these circumstances. I'm not sure whether or not this is related to the .local domain issue (the DNS zone files obviously use the .my.domain domain not .local).

Any help?

share|improve this question
1  
People are doing new setups of NIS? –  jordanm Jun 11 '13 at 23:46
    
@jordanm Are you suggesting it's obsolete? vulnerable? ...? Any documentation you can refer me to? –  Joseph R. Jun 11 '13 at 23:49
3  
NIS is vulnerable. The passwd map and the adjunct maps are easy to gain access to. I'd invest in LDAP if you're seriously considering it. –  slm Jun 12 '13 at 0:13
    
Good tutorial if your positive you want to set it up, yolinux.com/TUTORIALS/NIS.html –  slm Jun 12 '13 at 0:20
1  
I'm with @slm on that one. NIS (and NIS+) have been dead ducks for a good while now - do LDAP, seriously. –  tink Jun 12 '13 at 2:54
show 2 more comments

2 Answers

up vote 3 down vote accepted

You're asking a lot of questions so this is going to be touch Q to answer. I guess the easiest thing to do would be to share my NIS setup (yes even though I told you not to set one up, I have one setup in my LAN at home for testing purposes).

To start you'll need to have ypserv, ypbind, and yp-tools packages installed. You don't say what distro you're using, so I'm going to walk you through my setup on CentOS 5.x. I have Ubuntu 12.04 clients in my NIS domain so we can adjust this answer as needed down the road.

To keep things brief I'm going to be filtering out the comments in my config files and only showing you the lines that are actually doing anything. Again if you need clarification I can post them if need be.

ypserv

This file sets up how I want my ypserv to share the various NIS maps that I have. Below I'm limiting what IP subnets are allowed to access the various maps.

# more /etc/ypserv.conf |egrep -v "^#|^$"
dns: no
files: 50
xfr_check_port: yes
192.168.1.  : *       : shadow.byname         : none
192.168.1.  : *       : passwd.adjunct.byname : none
192.168.1.  : *       : passwd.byuid          : none
192.168.1.  : *       : *                     : none
*           : *       : *                     : deny
*           : *       : *                     : none

I should mention that I learned how to set up NIS/YP from old Sun/Solaris guys so my approach might be a little off the path. They always used passwd.adjunct files to house the actual passwords, so I do the same here.

setting NIS domain name

My NIS domain is called nis.bubba.home. Under Red Hat distros you'd typically set the NIS domain in this file: /etc/sysconfig/network. Here's mine:

$ more /etc/sysconfig/network
HOSTNAME="flanders.bubba.net"
NETWORKING="yes"
NISDOMAIN=nis.bubba.home

With this entry when you run the domainname command you should get the NISDOMAIN value:

# domainname
nis.bubba.home

Lots of people get confused by that command, it has nothing to do with the domain name of the host (bubba.net) it's the actual name of the NIS domain. See the domainname man page for more details.

/etc/yp.conf

This is the file that is used by clients (ypbind) so that they know what server to connect to.

# more /etc/yp.conf |egrep -v "^#|^$"
domain nis.bubba.home server 192.168.1.101

/etc/nsswitch.conf

This file controls what facilities will use NIS.

# more /etc/nsswitch.conf |grep nis |egrep -v "^#|^$"
passwd:     files nis
shadow:     files nis
group:      files nis
hosts:      files nis dns
networks:   files nis
protocols:  files nis
services:   files nis
netgroup:   files nis
automount:  files nis
aliases:    files nis

/etc/yp

To try and keep things straight I set this directory up and populated it with the files from which my NIS maps will eventually be built from. This isn't a complete list but here are a couple of the files that I have in this directory:

auto.master, group, passwd, passwd.adjunct & shadow

# shadow
rhays:##rhays:11304::99999::::135545092
tracy:##tracy:12390:0:99999:7:::
tuber:##tuber:12390:0:99999:7:::

In using passwd.adjunct the passwords get stored in that file and there is a reference (see above i.e. ##rhays) that says which line in the passwd.adjunct goes with a particular user.

# passwd.adjunct
rhays:ZNiFOTwsw313B:11299:0:99999:7:::

/var/yp

This directory is where the NIS server, ypserv will share data from. There's a Makefile there which you use to rebuild changes to maps as you edit the files in /etc/yp.

This directory looks like this:

# ls | column
binding     Makefile.orig    nicknames       RCS          ypservers
Makefile    Makefile.rpmnew  nis.bubba.home  securenets

Before we get into the Makefile, the other files here that are of interest are the securenets file. This can control what IP addresses and subnets are allowed to connect to this server. Here's my version of that file:

# securenets
host 127.0.0.1
255.255.255.0   192.168.1.0

Makefile

Here are some excerpts from my Makefile to help show how things get pulled together. For starters these variables point to my map files.

YPSRCDIR = /etc/yp
YPPWDDIR = /etc/yp
YPBINDIR = /usr/lib/yp
YPSBINDIR = /usr/sbin
YPDIR = /var/yp
YPMAPDIR = $(YPDIR)/$(DOMAIN)
...
GROUP       = $(YPPWDDIR)/group
PASSWD      = $(YPPWDDIR)/passwd
SHADOW      = $(YPPWDDIR)/shadow
ADJUNCT     = $(YPPWDDIR)/passwd.adjunct
...
all: passwd group hosts rpc services netid protocols mail \
    netgrp auto.master auto.home auto.packages auto.data1 auto.data2 \
    auto.proj auto.vz_backups passwd.adjunct networks printcap

There are additional modifications that need to be made to the Makefile based on the map files your particular environment is comprised of.

Bringing it all together

So when you've setup the map files, the config files, and installed all the necessary packages, you need to do the following:

$ cd /var/yp && make
$ /etc/init.d/ypserv start
$ /etc/init.d/ypbind start

# who's my domain master?
$ ypwhich 
flanders.bubba.net

# what maps are available?
$ ypwhich -m
passwd.byname flanders.bubba.net
passwd.adjunct.byname flanders.bubba.net
hosts.byaddr flanders.bubba.net
...

So should I be running NIS?

I still say no. It's ancient technology, has very poor security, and is ridiculously complicated. I posted this tutorial more to show you why you shouldn't use it rather than to encourage you to use it.

For the time invested in learning the details of NIS, you'd be better served in learning how to deploy LDAP.

share|improve this answer
    
+1 for the all the details and the overall "good guy Greg" quality of your answer :) I will read up on LDAP. –  Joseph R. Jun 12 '13 at 8:04
    
Thanks, I had to look up Good Guy Greg to remind myself of that reference. Better that then Scumbag Steve 8-). –  slm Jun 13 '13 at 0:26
add comment

For what it's worth, I did things a little differently. Since I'm a bit pressed for time, I decided to give NIS another go. I gave up on the netgroup approach and simply configured my hosts_access(5) as follows:

/etc/hosts.allow

ALL: localhost,.my.domain

#Don't lock yourself out:
sshd: ALL 

/etc/hosts.deny

ALL: ALL

I controlled who can access the NFS mount similarly in /etc/exports:

/my/nfs/share -rw *.my.domain

Coupled with a modification to /etc/nsswitch.conf to have:

hosts: files dns

In other words, I removed mDns because it would recognize hosts that my local bind9 server wouldn't.

Now my DHCP server only assigns IPs to clients with known MAC addresses and updates the bind9 server records; so the DNS will only resolve hosts ending in .my.domain if they were assigned by the DHCP and thus only trusted hosts will be able to see the NIS maps or mount the NFS share.

I know this can be fooled by MAC address spoofing but it's the best solution I could find, lacking the time to ramp up on LDAP.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.