Configurando um servidor NIS restrito

Question

Atualmente, estou tentando configurar um servidor NIS com acesso restrito, de forma que os mapas passwd e group sejam exportados apenas para hosts "confiáveis". Para este fim, eu tentei criar um netgroup (no arquivo apropriadamente nomeado /etc/netgroup ) contendo os nomes dos hosts confiáveis e eu queria adicionar uma regra como

ALL:ALL EXCEPT @nis_netgroup

para /etc/hosts.deny . Isso tem um duplo benefício para mim: restringe o acesso aos mapas NIS e a um compartilhamento NFS. Existem vários problemas com essa abordagem, no entanto, preciso de ajuda com:

• Isso não é muito seguro, pois os nomes de host podem ser facilmente falsificados
• As ferramentas yp insistem que o nome de domínio de todos os meus hosts é .local , independentemente do domínio de pesquisa que eu defini. Portanto, mesmo se eu tivesse configurado um domínio como .my.domain e meu servidor NIS fosse nomeado server (para que seu FQDN fosse server.my.domain ), após a ligação a esse servidor, ypwhich retornaria server.local . Isso requer que eu defina nomes de host "estranhos" no arquivo netgroup .
• Mesmo se eu passar pelos dois passos acima, não funciona : a máquina do servidor NIS continua tentando se ligar e falhar.

A única pista que encontrei em /var/log/syslog que poderia pertencer a esse problema:

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

O que isso significa?

Administrei uma configuração semelhante no passado, exceto que todos os clientes foram configurados com IPs estáticos, então /etc/hosts.allow simplesmente listou esses IPs, enquanto /etc/hosts.deny negaria qualquer outra solicitação. O motivo pelo qual não posso usar essa abordagem na configuração atual é que estou usando DNS dinâmico com IPs atribuídos por DHCP para os clientes. Existe uma maneira de permitir que o acesso ao host seja controlado por meio dos IPs atribuídos dinamicamente (ou seja, fazer pesquisas de endereço de nome de host paranoico usando o DNS dinâmico)? A página hosts_access(5) diz que posso usar uma string começando com / para especificar clientes de um arquivo, então pensei em usar essa sintaxe em conjunto com meu arquivo de zona DNS. Sem alegria! O servidor NIS ainda não se liga a si próprio nessas circunstâncias. Não tenho certeza se isso está relacionado ou não ao problema do domínio .local (os arquivos da zona DNS obviamente usam o .my.domain domain não .local ).

Alguma ajuda?

    

Answer 1

Você está fazendo muitas perguntas, então essa será uma pergunta difícil de responder. Eu acho que a coisa mais fácil a fazer seria compartilhar minha configuração NIS (sim, mesmo que eu tenha dito para você não configurar uma, eu tenho uma configuração em minha LAN em casa para fins de teste).

Para começar, você precisará ter os pacotes ypserv , ypbind e yp-tools instalados. Você não diz qual distro você está usando, então eu vou orientá-lo através da minha configuração no CentOS 5.x. Eu tenho clientes Ubuntu 12.04 no meu domínio NIS para que possamos ajustar essa resposta conforme necessário.

Para manter as coisas breves, vou filtrar os comentários em meus arquivos de configuração e mostrar apenas as linhas que realmente estão fazendo alguma coisa. Novamente, se precisar de esclarecimentos, posso publicá-los, se necessário.

ypserv

Este arquivo configura como eu quero que meu ypserv compartilhe os vários mapas NIS que eu tenho. Abaixo, estou limitando quais sub-redes IP têm permissão para acessar os vários mapas.

# 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

Devo mencionar que aprendi como configurar o NIS / YP de antigos usuários do Sun / Solaris para que minha abordagem fique um pouco fora do caminho. Eles sempre usaram arquivos passwd.adjunct para abrigar as senhas reais, então eu faço o mesmo aqui.

definindo o nome de domínio do NIS

Meu domínio NIS é chamado nis.bubba.home. Sob as distribuições da Red Hat, você normalmente configuraria o domínio NIS neste arquivo: /etc/sysconfig/network . Aqui está o meu:

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

Com esta entrada, quando você executar o comando domainname , deverá obter o valor NISDOMAIN :

# domainname
nis.bubba.home

Muitas pessoas se confundem com esse comando, não tem nada a ver com o nome de domínio do host (bubba.net) é o nome real do domínio NIS. Consulte a página de manual do nome do domínio para obter mais detalhes.

/etc/yp.conf

Este é o arquivo usado pelos clientes ( ypbind ) para que eles saibam a qual servidor se conectar.

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

/etc/nsswitch.conf

Este arquivo controla quais recursos usarão o 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

Para tentar manter as coisas corretas, configurei este diretório e o preenchai com os arquivos dos quais os meus mapas NIS serão construídos. Esta não é uma lista completa, mas aqui estão alguns dos arquivos que eu tenho neste diretório:

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:::

Ao usar o passwd.adjunct, as senhas são armazenadas nesse arquivo e há uma referência (veja acima, por exemplo, ## rhays) que diz qual linha no passwd.adjunct é usada por um usuário em particular.

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

/ var / yp

Este diretório é onde o servidor NIS, ypserv compartilhará os dados. Há um Makefile que você usa para reconstruir as alterações nos mapas enquanto edita os arquivos em /etc/yp .

Este diretório é assim:

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

Antes de entrarmos no Makefile , os outros arquivos aqui que são de interesse são o arquivo securenets . Isso pode controlar quais endereços IP e sub-redes podem se conectar a esse servidor. Aqui está a minha versão desse arquivo:

# securenets
host 127.0.0.1
255.255.255.0   192.168.1.0

Makefile

Aqui estão alguns trechos do meu Makefile para ajudar a mostrar como as coisas são combinadas. Para começar, essas variáveis apontam para meus arquivos de mapa.

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

Existem modificações adicionais que precisam ser feitas no Makefile com base nos arquivos de mapa dos quais seu ambiente específico é composto.

Reunindo tudo

Então, quando você configurar os arquivos de mapa, os arquivos de configuração e instalar todos os pacotes necessários, será necessário fazer o seguinte:

$ 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
...

Então, devo estar executando o NIS?

Eu ainda digo não. É uma tecnologia antiga, tem uma segurança muito fraca e é ridiculamente complicada. Postei este tutorial mais para mostrar por que você não deveria usá-lo, em vez de incentivá-lo a usá-lo.

Pelo tempo investido no aprendizado dos detalhes do NIS, você estaria mais bem atendido ao aprender a implantar o LDAP.

    

Answer 2

Por que vale a pena, eu fiz as coisas um pouco diferente. Como estou um pouco pressionado pelo tempo, decidi dar outra chance ao NIS. Eu desisti da abordagem netgroup e simplesmente configurei meu hosts_access(5) da seguinte forma:

/etc/hosts.allow

ALL: localhost,.my.domain

#Don't lock yourself out:
sshd: ALL 

/etc/hosts.deny

ALL: ALL

Eu controlei quem pode acessar a montagem do NFS da mesma forma em /etc/exports :

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

Acoplado a uma modificação em /etc/nsswitch.conf para ter:

hosts: files dns

Em outras palavras, eu removi mDns porque reconheceria hosts que meu servidor bind9 local não faria.

Agora, meu servidor DHCP atribui IPs apenas a clientes com endereços MAC conhecidos e atualiza os registros bind9 server; Assim, o DNS só resolverá os hosts que terminem em .my.domain se eles forem atribuídos pelo DHCP e, portanto, somente hosts confiáveis poderão ver os mapas NIS ou montar o compartilhamento NFS.

Eu sei que isso pode ser enganado por spoofing de endereços MAC, mas é a melhor solução que consegui encontrar, sem tempo para aumentar o LDAP.