Preparação para o Exame LPI: Gerenciamento de cliente de rede

Administração de Nível Intermediário (LPIC-2) tópico 210

Neste tutorial, o quinto de uma série de sete tutoriais que tratam da administração de rede intermediária no Linux, David Mertz continua preparando você para fazer o Exame 202 do Linux Professional Institute Intermediate Level Administration (LPIC-2). Seguindo este tutorial, você examinará a configuração centralizada das definições de rede em clientes dentro de uma rede, em vários protocolos. O DHCP é amplamente utilizado para estabelecer o handshaking básico para computadores clientes, como a designação de endereços IP. Em um nível mais alto, o NIS e(mais frequentemente) o LDAP são usados com informações compartilhadas arbitrariamente entre as máquinas de uma rede. Este tutorial também trata do PAM — um sistema de autenticação de usuários flexível e conectado em rede.

17 de maio de 2012 - Em resposta a uma solicitação do autor, os links quebrados foram atualizados. Em Sobre este tutorial, foi atualizado o texto do link da URL "lista de objetivos detalhados". Em Recursos, foram atualizadas as URLs do 1) link "Certificações Profissionais do LPIC", 2) link "O LDAP é RFC 2251" e 3) link "Linux-PAM System Administrators' Guide".

David Mertz, Developer, Gnosis Software, Inc.

David Mertz acha que as linguagens artificiais são perfeitamente naturais, mas as linguagens naturais parecem um pouco artificiais. É possível entrar em contato com o David pelo email mertz@gnosis.cx; é possível investigar todos os aspectos da vida pessoal dele em sua página da web pessoal. Confira o livro dele, Text Processing in Python. Sugestões ou recomendações sobre colunas passadas ou futuras são bem-vindas.



16/Ago/2012

Antes de Iniciar

Veja o que esses tutoriais podem ensinar a você e como aproveitá-los ao máximo.

Sobre esta série

O Linux Professional Institute (LPI) certifica administradores de sistema Linux em dois níveis: nível junior (também conhecido como "certificação nível 1") e nível intermediário (também conhecido como "certificação nível 2"). Para obter a certificação nível 1, é necessário ser aprovado nos exames 101 e 102; para obter a certificação nível 2, é necessário passar nos exames 201 e 202.

O developerWorks oferece tutoriais para ajudar você a se preparar para cada um dos quatro exames. Cada exame trata de vários tópicos, e cada tópico tem um tutorial de autoestudo correspondente no developerWorks. Para o exame LPI 202, os sete tópicos e seus tutoriais correspondentes no developerWorks são:

Tabela 1. Exame LPI 202: tutoriais e tópicos
Tópico do exame LPI 202Tutorial do developerWorksResumo do tutorial
Tópico 205Preparação para o exame LPI 202 (tópico 205):
configuração de rede
Aprenda a configurar uma rede TCP/IP básica, da camada de hardware (geralmente Ethernet, modem, ISDN ou 802.11) até o roteamento dos endereços de rede.
Tópico 206Preparação para o exame LPI 202 (tópico 206):
correio e notícias
Aprenda a usar o Linux como servidor de correio e de notícias. Saiba mais sobre o transporte de correio, filtragem do correio local, software de manutenção da lista de emails e software de servidor para o protocolo NNTP.
Tópico 207Preparação para o exame LPI 202 (tópico 207):
DNS
Aprenda a usar o Linux como servidor do Sistema de Nomes de Domínio, usando principalmente o BIND. Aprenda a fazer uma configuração básica de BIND, gerenciar zonas de DNS e proteger um servidor do Sistema de Nomes de Domínio.
Tópico 208Preparação para o exame LPI 202 (tópico 208):
serviços da Web
Aprenda a instalar e configurar o servidor da web Apache e a implementar o servidor proxy Squid.
Tópico 210 Preparação para o exame LPI 202 (tópico 210):
Gerenciamento de cliente de rede
(Este tutorial) Aprenda a configurar um servidor DHCP, um cliente e servidor do NIS, um servidor do LDAP e o suporte para a autenticação do PAM. Veja os objetivos detalhados abaixo.
Tópico 212 Preparação para o exame LPI 202 (tópico 212):
segurança do sistema
Em breve
Tópico 214 Preparação para o exame LPI 202 (tópico 214):
resolução de problemas de rede
Em breve

Para começar a se preparar para a certificação nível 1, consulte os tutoriais do developerWorks para o exame LPI 101. Para se preparar para o outro exame na certificação nível 2, consulte os tutoriais do developerWorks para o exame LPI 201. Leia mais sobre o conjunto completo de tutoriais de LPI no developerWorks.

O Linux Professional Institute não endossa nenhum material de terceiros para a preparação para exame, nem nenhuma técnica específica. Para ver os detalhes, entre em contato com info@lpi.org.

Sobre este tutorial

Bem-vindo ao "gerenciamento de cliente de rede", o quinto de sete tutoriais que tratam da administração de rede intermediária no Linux. Neste tutorial, você aprende sobre a configuração centralizada das definições de rede em clientes dentro de uma rede em vários protocolos, vê como o DHCP é amplamente utilizado para estabelecer handshaking básico para computadores clientes (como a designação de endereços IP) e como, em um nível mais alto, o NIS e (mais frequentemente) o LDAP são usados com informações compartilhadas arbitrariamente entre as máquinas de uma rede. Esse tutorial também trata do PAM (Pluggable Authentication Module), um sistema de autenticação de usuários flexível e conectado em rede.

Como em outros tutoriais das séries 201 e 202 do developerWorks, esse tutorial se destina a ser um guia de estudo e um ponto de entrada para a preparação para o exame, e não uma documentação completa sobre o assunto. Recomenda-se que os leitores consultem a lista de objetivos detalhados e complementem as informações fornecidas aqui com outros materiais conforme a necessidade.

Este tutorial é organizado de acordo com os objetivos do LPI referentes a este tópico. De modo bem geral, no exame, você deve esperar mais perguntas sobre os objetivos com maior peso.

Tabela 2. Serviços da web: objetivos do exame abordados neste tutorial
Objetivo do exame LPIPeso do objetivoResumo do objetivo
2.210.1
Configuração do DHCP
Peso 2Configure um servidor DHCP. Esse objetivo envolve a configuração das opções padrão e por cliente, a inclusão de hosts estáticos e hosts de BOOTP. Envolve também a configuração de um agente de retransmissão de DHCP e a manutenção do servidor DHCP.
2.210.2
Configuração do NIS
Peso 1Configure um servidor NIS. Este objetivo inclui a configuração de um sistema como um cliente NIS.
2.210.3
Configuração do LDAP
Peso 1Configure um servidor do LDAP. Este objetivo envolve trabalhar com a hierarquia de diretórios, grupos, hosts e serviços e a inclusão de outros dados na hierarquia. Envolve também a importação e edição de itens, bem como a inclusão e o gerenciamento de usuários.
2.210.4
Autenticação do PAM
Peso 2Configure o PAM para suportar a autenticação usando vários métodos disponíveis.

Pré-requisitos

Para aproveitar ao máximo este tutorial, é necessário ter um conhecimento básico de Linux e um sistema Linux funcional no qual seja possível praticar os comandos descritos nele.


Introdução

Sobre o DHCP

O Protocolo de Configuração de Host Dinâmico (DHCP) é um sucessor do protocolo BOOTP, mais antigo. A principal função de um servidor DHCP é designar endereços IP a computadores cliente que podem se conectar a uma rede ou desconectar. A maioria das redes de IP — inclusive as que têm topologias estáveis e listas de clientes — usa o DHCP para evitar conflitos na alocação de endereços IP.

Além disso, um servidor DHCP fornece aos clientes informações de sub-rede e roteamento, endereços de DNS e, em alguns casos, outras informações. As designações de DHCP podem ter durações variáveis, que vão de curtas a infinitas, dependendo da configuração do servidor e dos detalhes das solicitações do cliente. Na verdade, o DHCP é consistente com a designação de endereços IP corrigidos para máquinas específicas (por meio dos endereços MAC de hardware) mas, de qualquer forma, evita conflitos entre máquinas.

A especificação formal do DHCP é a RFC 2131 (consulte Recursos mais adiante neste tutorial para ver o link).

Sobre o NIS

O Serviço de Informações de Rede (NIS) é o protocolo de serviço de diretório cliente/servidor "Yellow Pages" (YP) da Sun Microsystems para distribuir dados de configuração do sistema, como os nomes de host e de usuário em uma rede de computadores.

O NIS/YP é usado para manter um diretório central de usuários, nomes de host e outras coisas úteis em uma rede de computadores. Por exemplo, em um ambiente UNIX comum, a lista de usuários (para autenticação) é colocada em /etc/passwd. O uso do NIS inclui outra lista "global" de usuários que é usada para autenticar usuários em qualquer host.

O NIS foi substituído, em grande parte, pelo LDAP — mais geral e mais seguro — para uso geral.

"The Linux NIS(YP)/NYS/NIS+ HOWTO" bom ponto de partida para obter mais informações sobre o NIS (consulte Recursos para obter um link).

Sobre o LDAP

O LDAP é um protocolo de cliente/servidor para acessar serviços de diretório — especificamente, os serviços de diretório baseados em X.500.

O diretório do LDAP é semelhante a um banco de dados, mas tende a conter informações mais descritivas e baseadas em atributos. Sendo assim, o LDAP fornece flexibilidade suficiente para armazenar qualquer tipo de informações baseadas em rede. A frequência de leitura das informações de um diretório é muito maior que a de gravação — portanto, ele é ajustado para dar uma resposta rápida a operações de consulta ou procura com alto volume.

O LDAP tem a capacidade de replicar informações amplamente para aumentar a disponibilidade e a confiabilidade e, ao mesmo tempo, reduzir o tempo de resposta. Quando as informações de diretório são replicadas, as inconsistências temporárias vão ficando sincronizadas ao longo do tempo.

A especificação formal do LDAP é a RFC 2251 (consulte Recursos para obter um link).

Sobre o PAM

O Linux-PAM (Pluggable Authentication Module para Linux) é um conjunto de bibliotecas compartilhadas que permitem ao administrador de sistema local escolher de que forma os aplicativos autenticam os usuários.

Um aplicativo com conhecimento do PAM pode alternar, durante o tempo de execução, os mecanismos de autenticação. De fato, é possível atualizar totalmente o sistema de autenticação local sem recompilar os aplicativos propriamente ditos. Essa biblioteca PAM é configurada localmente com um arquivo do sistema, /etc/pam.conf (ou uma série de arquivos de configuração localizados em /etc/pam.d/), para autenticar uma solicitação do usuário por meio dos módulos de autenticação disponíveis localmente. Os módulos propriamente ditos geralmente estão localizados no diretório /lib/security, na forma de arquivos de objeto que podem ser carregados dinamicamente.

O Linux-PAM System Administrators' Guide é um bom ponto de partida para obter mais informações (consulte Recursos para obter um link).

Outros recursos

Como acontece com a maioria das ferramentas do Linux, sempre é útil examinar as manpages referentes aos utilitários abordados. As versões e comutadores podem variar de acordo com a versão do utilitário ou do kernel e as diversas distribuições do Linux. Para obter informações mais aproximadas, o projeto Linux Documentation oferece uma variedade de documentos úteis, principalmente as instruções. Há vários livros publicados sobre redes em Linux; na minha opinião, TCP/IP Network Administration, de autoria de Craig Hunt e publicado pela O'Reilly, é muito útil. (Consulte Recursos para obter os links.)


Configuração do DHCP

O protocolo geral

Como acontece em muitos protocolos de rede, o Protocolo de Configuração de Host Dinâmico (DHCP) é uma interface de cliente/servidor. O cliente DHCP é um programa muito mais simples, tanto internamente quanto em termos de configuração, que o servidor DHCP. Basicamente, a tarefa de um cliente DHCP é transmitir uma mensagem DHCPDISCOVER em sua sub-rede física local e, em seguida, aguardam uma resposta.

A mensagem DHCPDISCOVER PODE incluir opções que sugerem valores para o endereço de rede e a duração do lease. Os servidores que recebem uma mensagem DHCPDISCOVER devem responder ao endereço MAC solicitante com uma mensagem DHCPOFFER. O cliente, por sua vez, responde com uma mensagem DHCPREQUEST para um dos servidores que oferecem — geralmente para o primeiro (e único) servidor que responde.

Os parâmetros de configuração reais que um cliente usa são recebidos em uma mensagem DHCPACK. Nesse ponto, o cliente recebeu um endereço IP alocado e as suas comunicações passam, por assim dizer, da camada de link de dados (Ethernet) para a camada de rede (IP).

O processo do cliente

Normalmente, um cliente DHCP só precisa ser configurado com o conjunto de informações que ele deseja obter. Por exemplo, as distribuições baseadas em Debian normalmente usam o cliente de DHCP (dhclient), que está configurado com o arquivo /etc/dhcp3/dhclient.conf. O arquivo de amostra que é distribuído com o pacote dhcp3-client está com todas opções de configuração desabilitadas, com exceção de uma. A opção ativada pode ser assim:

Listagem 1. Opção para dhclient.conf
      request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, host-name,
        netbios-name-servers, netbios-scope;

Neste exemplo, a configuração padrão, o cliente basicamente diz "peça tudo o que for possível". Nas mensagens de negociação, a mensagem DHCPACK do servidor conterá informações referentes a todos esses valores solicitados que o cliente usará quando eles forem recebidos. O endereço IP do cliente fica implícito nessa lista, já que configuração sempre é negociada.

Além de especificar as opções de tempo limite e tempo de lease (e algumas outras), o cliente pode — mas na maioria dos casos não precisa — impor algumas restrições aos endereços IP que deseja usar. Para excluir um endereço específico, é possível usar reject 192.33.137.209;. Para especificar o endereço explícito que o cliente deseja usar, utilize fixed-address 192.5.5.213;.

O cliente pode rejeitar uma oferta de lease com a mensagem DHCPDECLINE, mas os servidores tentam atender as solicitações quando possível. Um servidor DHCP também pode fazer uma designação fixa de um endereço IP específico para um endereço MAC solicitante; a configuração do endereço IP máquina por máquina é mais frequente na configuração do servidor que na do cliente.

Para controlar os leases adquiridos, o dhclient mantém uma lista de leases aos quais ele foi designado no arquivo /var/lib/dhcp3/dhclient.leases (o caminho pode variar de uma distribuição para outra); dessa forma, um lease de DHCP não expirado não se perde se um sistema se desconecta da rede física e/ou é reiniciado.

O processo do servidor

O servidor DHCP precisa saber um pouco mais sobre as suas opções, já que fornece várias informações para os clientes em leases de DHCP e também deve garantir que os endereços IP sejam designados de forma exclusiva para cada cliente. O servidor DHCP geralmente executa como o daemon, dhcpd, e obtém as informações de configuração a partir de /etc/dhcpd.conf (esse caminho pode variar de uma distribuição para a outra). Um único daemon dhcpd pode gerenciar várias sub-redes — geralmente se várias redes físicas se conectam a um servidor; entretanto, mais frequentemente, um servidor gerencia uma sub-rede. A Listagem 2 é um exemplo razoavelmente completo de configuração do servidor.

Listagem 2. Opções de configuração de dhcpd.conf
      # default/max lease in seconds: day/week
      default-lease-time 86400;
      max-lease-time 604800;
      option subnet-mask 255.255.255.0;
      option broadcast-address 192.168.2.255;
      option routers 192.168.2.1;
      # DNS locally, fallback to outside local domain
      option domain-name-servers 192.168.2.1, 151.203.0.84;
      option domain-name "example.com";
      # Set the subnet in which IP address are pooled
      subnet 192.168.2.0 netmask 255.255.255.0 {
         range 192.168.2.100 192.168.2.199;
      }
      # Assign a fixed IP to a couple machines by MAC address
      group {
         use-host-decl-names true;
         host first.example.com {
            hardware ethernet 00:00:c1:a2:de:10;
            fixed-address 192.168.2.200;
         }
         host second.example.com {
            hardware ethernet 00:dd:cc:a1:78:34;
            fixed-address 192.168.2.201;
         }

Quando um cliente envia uma mensagem transmitida para um servidor que funciona com essa configuração, ele recebe um lease de 192.168.2.200 or 192.168.2.201, caso tenha o endereço MAC especificado, ou recebe um lease de um endereço disponível no conjunto de 192.168.2.100 a 192.168.2.199.

O cliente também pode usar a mensagem DHCPINFORM para dizer ao servidor que ele já tem um endereço IP designado (por configuração manual), mas quer obter outras informações de configuração. Observe que o ato de informar um servidor de que um cliente está usando um determinado endereço IP não é a mesma coisa que solicitar um endereço IP específico; neste caso, o servidor pode atender a solicitação ou não, dependendo dos leases existentes. No caso anterior, o servidor não interfere na decisão e o lease em si não é dado (mas os servidores tentarão evitar designar para os novos clientes solicitantes endereços IP que reconhecidamente estão em uso).

Quando os leases expiram, os clientes e servidores devem negociar novos leases para que os parâmetros de configuração continuem válidos. É possível usar leases mais curtos quando há probabilidade de que as informações de configuração de um servidor mudem (por exemplo, no caso de DNS dinâmico por meio de uma WAN externa). O cliente pode finalizar o lease elegantemente enviando uma mensagem DHCPRELEASE, mas isso não é obrigatório para a operação correta (afinal de contas, os clientes às vezes travam, reinicializam ou ficam desconectados sem a oportunidade de enviar essa mensagem).

Na ausência de uma mensagem de release, o lease é mantido pelo servidor durante o prazo da designação — portanto, frequentemente uma máquina reiniciada continua usando o lease anterior (que será armazenado em dhclient.leases no servidor e no cliente).


Configuração do NIS

Quando usar o NIS

A maioria dos utilitários associados ao NIS ainda é nomeada com o prefixo yp porque antes ele era conhecido como "Sun Yellow Pages"; problemas de marca registrada obrigaram a mudança do nome para NIS. O NIS é usado para permitir que uma rede de máquinas compartilhem informações, como usuários e grupos (o conteúdo de /etc/passwd e/etc/group, respectivamente), permitindo os direitos de usuário em qualquer máquina dentro de um domínio do NIS.

O NIS opera de forma semelhante ao DNS na definição de domínios nos quais as informações são distribuídas e também na permissão para que os servidores mestre e escravo distribuam as informações hierarquicamente dentro de um domínio. De fato, em termos de princípio, pode-se usar o NIS no lugar do DNS distribuindo as informações de nome de domínio encontradas em /etc/hosts, isso é raro na prática. O NIS tem um certo grau de flexibilidade já que, em princípio, qualquer tipo de informação pode ser colocado em um banco de dados do NIS (que tem o formato DBM, mas a ferramenta makedbm do pacote de servidor do NIS converte arquivos simples para esse formato, geralmente "nos bastidores").

Também há um serviço chamado NIS+, que deveria substituir o NIS e inclui criptografia e autenticação de dados; contudo, o NIS+ não é compatível com versões anteriores do NIS e não é muito usado.

Antes de Iniciar

Para executar qualquer utilitário do NIS, é necessário executar o daemon /sbin/portmap, que converte os números do programa RPC para os números da porta de protocolo TCP/IP (ou UDP/IP), já que os clientes do NIS fazem chamadas de RPC. A maioria das distribuições do Linux ativa /sbin/portmap nos seus scripts de inicialização, mas é necessário se certificar de que esse daemon está executando com % ps -ax | grep portmap.

Se ainda não estiver executando, instale /sbin/portmap e inclua-o na inicialização do sistema.

Utilitários de clientes do NIS(daemon ypbind)

O cliente do NIS client inclui as ferramentas ypbind, ypwhich, ypcat, yppoll e ypmatch. O daemon ypbind deve executar como raiz e normalmente é ativado como parte dos scripts de inicialização do sistema (embora isso não seja obrigatório).

As outras ferramentas dependem dos serviços de ypbind mas executam no nível do usuário. A versão antiga do ypbind transmite uma solicitação de ligação na rede local, mas isso permite que um servidor do NIS mal-intencionado responda a solicitação e forneça informações incorretas sobre usuários e grupos para os clientes. É mais recomendável configurar servidores específicos para que o ypbind se conecte a eles usando o arquivo /etc/yp.conf. Se vários serviços são configurados (ou se a transmissão é utilizada, apesar do perigo), o ypbind pode alternar os servidores ligados a cada 15 minutos, para o servidor que tenha a capacidade de responder mais rapidamente. Esses vários servidores devem ter a configuração mestre/escravo, mas o cliente não precisa saber dos detalhes (nem se importa com eles). Por exemplo, uma configuração ypbind pode ser assim:

Listagem 3. /etc/yp.conf
      ypserver 192.168.2.1
      ypserver 192.168.2.2
      ypserver 192.168.1.100
      ypserver 192.168.2.200

Antes da execução de /usr/sbin/ypbind, é necessário configurar o nome de domínio do NIS da sua rede. Pode ser qualquer nome que o servidor do NIS esteja configurado para usar e, em geral, deve ser escolhido de forma a ser diferente do nome de domínio do DNS. Configure esse nome de domínio do NIS usando (substitua pelo nome real): % ypdomainname my.nis.domain.

Utilitários de clientes do NIS (outras configurações)

Se você quer usar o NIS como parte da sua consulta de nome de domínio, deve modificar /etc/host.conf para incluir o NIS na ordem de consulta; por exemplo, para procurar um nome primeiro em /etc/hosts, depois no NIS e, em seguida, no DNS:

Listagem 4. Modificando a ordem de consulta
      % cat /etc/host.conf
      order hosts,nis,bind

Para habilitar os usuários distribuídos do NIS, é necessário modificar o arquivo /etc/passwd do cliente para incluir +::::::.

As informações do banco de dados do NIS atuam como um modelo para tentativas de login com esse padrão "não preenchido". Se quiser, você poderá fazer um ajuste fino nas informações sobre o usuário — por exemplo:

Listagem 5. /etc/passwd detalhado
      +user1:::::::
      +user2:::::::
      +user3:::::::
      +@sysadmins:::::::
      -ftp
      +:*::::::/etc/NoShell

Isso permite o acesso por login somente a user1, user2 e user3, bem como a todos os membros do netgroup sysadmin, mas fornece os dados da conta de todos os outros usuários no banco de dados do NIS.

As fontes do NIS propriamente ditas são configuradas em /etc/nsswitch.conf. O nome pode sugerir que se trata somente de consulta no servidor de nomes, mas vários tipos de informação são descritos. Basicamente, essa configuração descreve a ordem de procura nas fontes de informações. O nome nis em uma ordem indica informações obtidas a partir de um servidor do NIS server; o nome files indica o uso de um arquivo de configuração local adequado. O nome dns é usado para a opção hosts .

Também é possível especificar o que fazer se uma fonte inicial não contém as informações desejadas: return significa desistir (e, a menos que o NIS simplesmente não esteja respondendo, continue significa tentar a próxima fonte do datum). Por exemplo,

Listagem 6. /etc/nsswitch.conf
      passwd:         compat
      group:          compat
      shadow:         compat
      hosts:          dns [!UNAVAIL=return] files
      networks:       nis [NOTFOUND=return] files
      ethers:         nis [NOTFOUND=continue] files
      protocols:      nis [NOTFOUND=return] files
      rpc:            nis [NOTFOUND=return] files
      services:       nis [NOTFOUND=return] files

Utilitários de cliente do NIS

Os utilitários ypwhich, ypcat, yppoll e ypmatch são usados no nível do usuário para consultar informações do NIS:

  • ypwchich imprime o nome de um servidor do NIS server.
  • ypcat imprime os valores de todas as chaves de um banco de dados do NIS.
  • yppoll imprime a versão e o servidor principal de um mapa do NIS.
  • ypmatch imprime o valor de uma chave (ou mais) de um mapa do NIS.

Consulte as manpages correspondentes de cada utilitário para obter mais informações de uso.

Utilitários de servidor do NIS (ypinit, ypserv)

Um servidor NIS usa o daemon ypserv daemon para fornecer bancos de dados do NIS para os clientes e é configurado com o arquivo /etc/ypserv.conf. Como eu mencionei, é possível executar o servidor mestre e o escravo do NIS dentro de um domínio. O conjunto de bancos de dados do NIS é inicializado em um servidor principal usando (somente na primeira execução; depois disso, use make -C /var/yp desta forma: % /usr/lib/yp/ypinit -m.

O servidor escravo é, na verdade, um cliente do NIS que obtém seus bancos de dados do servidor principal (e executa ypserv). Para copiar informações do servidor principal para o servidor escravo que executa localmente, use % /usr/lib/yp/ypinit -s my.nist.domain.

No servidor principal, os bancos de dados do NIS são criados a partir de informações de alguns dos seguintes arquivos de configuração bem conhecidos:

  • /etc/passwd,
  • /etc/group,
  • /etc/hosts,
  • /etc/networks,
  • /etc/services,
  • /etc/protocols,
  • /etc/netgroup,
  • /etc/rpc.

Os bancos de dados que são exportados são configurados em /var/yp/Makefile, que também propaga as alterações quando ele é reconstruído.

Os servidores escravos serão notificados de qualquer mudança nos mapas do NIS quando eles forem reconstruídos (por meio do programa yppush) e recuperarão automaticamente as mudanças necessárias para sincronizar os bancos de dados. Os clientes do NIS não precisam fazer isso, já que eles "conversam" continuamente com o servidor do NIS para ler as informações armazenadas nos seus bancos de dados DBM.


Configuração do LDAP

Quando usar o LDAP

Em princípio, o protocolo LDAP tem um propósito semelhante ao do NIS. Ambos distribuem algumas informações estruturadas sobre a configuração de rede do cliente para o servidor; entretanto, o LDAP vai além porque estrutura hierarquicamente as informações que são distribuídas para cada cliente, redirecionando as solicitações para outros servidores do LDAP quando necessário e se baseia nos mecanismos de segurança. Além disso, o LDAP fornece mecanismos e ferramentas para clientes, para atualizar as informações contidas nos servidores do LDAP, que, por sua vez, distribuem essas informações a outros clientes que as solicitam (sujeito a permissões, evidentemente).

Instalação

Antes de executar o OpenLDAP (a implementação de software livre geralmente utilizada no Linux, embora existam algumas implementações comerciais), é necessário instalar ou verificar a existência de várias bibliotecas obrigatórias:

  • Os serviços de Segurança da Camada de Transporte (TLS) OpenSSL podem ser obtidos a partir do Projeto OpenSSL (ou por meio dos mecanismos de instalação da sua distribuição do Linux).
  • Os serviços de autenticação do Kerberos são suportados de forma opcional, mas isso é muito recomendável. Tanto MIT Kerberos quanto Heimdal Kerberos funcionam.
  • A Camada de Segurança e Autenticação Simples pode ser instalada como parte da sua distribuição base, mas também pode ser obtida como Cyrus SASL .
  • O Sleepycat Software Berkeley DB é recomendado, embora outras implementações de DBM provavelmente sejam compatíveis.
  • Encadeamentos Posix e wrappers TCP são desejáveis, caso não sejam absolutamente necessários.

Supondo que você tenha preenchido esses pré-requisitos, faça o download da biblioteca OpenLDAP e realize o procedimento mais ou menos usual:

Listagem 7. O procedimento de instalação do OpenLDAP
      % ./configure
      % make depend
      % make
      % make test  # make sure things went OK
      % su root -c 'make install'

Depois da instalação básica, é necessário fazer a configuração do slapd, geralmente em/usr/local/etc/openldap/slapd.conf. A configuração deve incluir os componentes de domínio:

Listagem 8. Componentes de domínio a serem incluídos em slapd.conf
      database bdb
      suffix "dc=eng,dc=uni,dc=edu,dc=eu"
      rootdn "cn=Manager,dc=eng,dc=uni,dc=edu,dc=eu"
      rootpw <secret>
      directory /usr/local/var/openldap-data

Para encontrar um valor para <secret>, use o utilitário slappasswd e use esta cadeia de caracteres criptografada com base64 para o seu "<secret>":

Listagem 9. Descobrindo o seu "secret"
      % slappasswd
      New password: *******
      Re-enter new password: ********
      {SSHA}YzPqL5Jio2+17NFIy/pAz8pqS5Ko13fH

Para obter mais informações sobre permissão, replicação e outras opções, é possível configurar em slapd.conf e examinar atentamente as manpages detalhadas.

A ativação do daemon slapd é muito semelhante à inicialização de qualquer daemon; é possível testar para ver se ele funcionou com ldapsearch:

Listagem 10. Testando para ver se slapd funcionou
      su root -c /usr/local/libexec/slapd
      ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts

Se tudo correr bem, você deve ver algo parecido com isso:

Listagem 11. Resposta quando o slapd está funcionando
      dn:
      namingContexts: dc=eng,dc=uni,dc=edu,dc=eu

Incluindo dados com um arquivo

O formato de dados usado no in LDAP é um formato binário, mas uma serialização de ASCII chamada Formato de Troca de Dados LDAP (LDIF) é usada para exportar e importar dados em um banco de dados LDAP. Os dados binários em LDIF são representados como uma codificação de base64. O OpenLDAP inclui ferramentas para exportar dados de servidores do LDAP para o LDIF (ldapsearch), importar dados do LDIF para os servidores do LDAP (ldapadd) e aplicar um conjunto de mudanças descritas no LDIF aos servidores do LDAP(ldapmodify e ldapdelete).

Além disso, o LDIF é um dos formatos para importar e exportar dados da lista de endereços para o Mozilla Application Suite e outras ferramentas no nível do aplicativo de usuário. Até o Microsoft Windows 2000 Server e o Windows Server 2003 incluem uma ferramenta LDIF, LDIFDE, para transferir dados de/para o Active Directory.

Para incluir informações manualmente no servidor do LDAP, primeiro crie um arquivo LDIF:

Listagem 12. Criando o arquivo LDIF de amostra, example.ldif
      dn: dc=example,dc=com
      objectclass: dcObject
      objectclass: organization
      o: Example Company
      dc: example

      dn: cn=Manager,dc=example,dc=com
      objectclass: organizationalRole
      cn: Manager

Em seguida, inclua-o usando % ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f example.ldif.

Obviamente, você substitui o domínio example.com pelo domínio correspondente ao do seu site. Via de regra, as hierarquias e nomes de domínio do LDAP correspondem aos utilizados pelos nomes de DNS mais conhecidos. Você terá que inserir o valor de rootpw especificado em slapd.conf.

Consultando bancos de dados do LDAP

Há uma ferramenta, slurpd (Standalone LDAP Update Replication Daemon), que replica um banco de dados completo de informações; no entanto, para valores de dados individuais, você usa uma ferramenta como ldapsearch ou, mais provavelmente, o suporte para o LDAP será integrado a algum aplicativo que você executa. A ferramenta slapcat também está disponível para realizar o dumping de um banco de dados do LDAP para o LDIF. Por exemplo, muitos agentes de usuário de email (MUAs) podem usar o LDAP para localizar as informações de endereço e contato.

Dentro dos aplicativos, inclusive os que você mesmo pode programar usando linguagens de aplicativos ou scripting, os recursos do LDAP podem ser acessados por meio das URLs correspondentes. Essas URLs têm a forma de ldap://host:port/dn?attributes?scope?filter?extensions.

A maioria desses campos é opcional. O nome do host padrão é localhost; a porta padrão é 389. O nome distinto da raiz é uma cadeia de caracteres vazia. Se forem necessárias informações sobre autenticação, especifique-as na parte de extensões da URL.

Além das URLs de LDAP, muitos servidores e clientes do LDAP também suportam as URLs de LDAPS, que não são padrão mas são amplamente utilizadas. As URLs de LDAPS usam conexões SSL em vez de conexões de texto simples e usam a porta padrão 636: ldaps://host:port/dn?attributes?scope?filter?extensions.


Autenticação do PAM

Quando usar o PAM

A primeira coisa que se deve ter em mente sobre o Pluggable Authentication Modules (PAM) é que ele não é um aplicativo ou protocolo propriamente dito. É uma coleção de bibliotecas que os aplicativos podem ter sido compilados para utilizar. Se um aplicativo está habilitado para o PAM, a sua política de segurança pode ser configurada por um administrador do sistema sem modificação ou upgrade do aplicativo em si. Muitas ferramentas do Linux, principalmente daemons e servidores, estão habilitadas para o PAM.

Uma forma rápida de verificar se uma determinada ferramenta provavelmente está habilitada para o PAM é usar ldd para ver quais bibliotecas ele usa. Por exemplo, para saber se o meu utilitário de login está habilitado para o PAM:

Listagem 13. O meu login está habilitado para o PAM?
      % ldd /bin/login | grep libpam
      libpam.so.0 => /lib/libpam.so.0 (0xb7fa8000)
      libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fa5000)

O uso de libpam.so e libpam_misc.so por login não garante totalmente que os recursos do PAM realmente estão sendo usados de forma correta por essa ferramenta, mas é uma boa indicação. Da mesma forma, para saber se os meus servidores Apache e FTP estão habilitados para o PAM:

Listagem 14. E os servidores Apache e FTP?
      % ldd /usr/sbin/apache2 | grep libpam
      % ldd /bin/login | grep libpam
      libpam.so.0 => /lib/libpam.so.0 (0xb7fa8000)
      libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fa5000)

Dessa forma, eu fico sabendo que a minha instalação específica do Apache não está habilitada para o PAM (embora existam versões disponíveis que incluam isso).

Para verificar de forma mais detalhada se o PAM está funcionando totalmente com uma determinada ferramenta, é possível criar um arquivo de configuração do PAM referente ao programa. Por exemplo, para testar o utilitário de login, pode-se criar um arquivo /etc/pam.d/login (mas observe que ele provavelmente já existe no seu sistema com uma configuração mais significativa — portanto, não apague a cópia já existente):

Listagem 15. Verificando o login para o PAM com etc/pam.d/login
      auth      required    pam_permit.so
      auth      required    pam_warn.so

A execução de um login adequadamente habilitado para o PAM permitirá que qualquer pessoa faça login, mas registrará a ação no log do sistema. Se syslog mostra uma entrada, o PAM está habilitado para o aplicativo. Os leitores observarão que essa talvez seja a pior configuração possível para login desde que dá a qualquer pessoa acesso de shell. Após perceber isso, saiba que o PAM deve ser configurado com cuidado.

Configuração do PAM

O PAM trabalha com diversos tipos de arquivos de configuração. A maioria das bibliotecas de libpam.so são compiladas no modo "use melhor se estiver disponível, mas aceite o pior". No entanto, também é possível que uma biblioteca do PAM esteja compilada como "use o melhor, mas também verifique o pior." Deixe-me explicar isso.

A forma preferencial atual de configurar o PAM é com os arquivos no diretório /etc/pam.d/ com nomes iguais aos serviços cuja segurança eles descrevem. Um estilo mais antigo e menos recomendável utilizava um único arquivo, /etc/pam.conf, para configurar a política de segurança para todos os aplicativos. Do ponto de vista da possibilidade de manutenção, é mais fácil trabalhar com os arquivos de configuração por aplicativo, e eles também podem ter links simbólicos (symlinks) para "duplicar" uma política de segurança de um aplicativo para outro. Os dois arquivos de configuração parecem basicamente iguais. O arquivo único /etc/pam.conf contém linhas desta forma:

Listagem 16. Os dois arquivos de configuração contêm
      <service>  <module-type>  <control-flag>  <module-path>  <args>

Nos arquivos de configuração por aplicativo, o primeiro campo é omitido, já que é igual ao nome do arquivo. No estilo antigo, a configuração de login somente para teste que vimos é assim:

Listagem 17. /etc/pam.conf
      login     auth      required    pam_permit.so
      login     auth      required    pam_warn.so

O campo <module-type> pode ter um de quatro valores:

  • auth (autenticação),
  • account (permissões que não são de autenticação baseadas no sistema de status do usuário),
  • session (realiza ações antes/depois do uso do serviço) e
  • password (tokens de atualização da autenticação do usuário).

O campo <control-flag> é usado para "empilhar" módulos, algo que dá a você um controle muito sutil referente a quando um método é necessário, se ele é realizado e quando algum outro tipo de fallback é aceitável. Suas opções são

  • required,
  • requisite,
  • sufficient,
  • optional e
  • include.

Abordarei as opções no próximo painel.

O <module-path> nós vimos nos exemplos; ele nomeia uma biblioteca compartilhada no local esperado do módulo, se não é fornecido nenhum caminho, ou em um local explícito se ele começa com "/". Por exemplo, na Listagem 17, você pode ter especificado /lib/security/pam_warn.so. O <args> pode ser qualquer coisa, dependendo do que é necessário para o módulo configurar a sua operação, embora alguns argumentos genéricos devam ser suportados pela maioria dos módulos PAM. Observe que os módulos PAM são extensíveis. Se alguém escreve um novo módulo PAM, é possível simplesmente soltá-lo em /lib/security e todos os seus aplicativos poderão usá-lo depois que os arquivos de configuração deles estiverem atualizados para indicar isso.

Um exemplo de permissão do PAM

Para ver como o <control-flag> funciona, vamos desenvolver um exemplo moderadamente complexo. A primeira coisa a fazer é criar um serviço OTHER especial. Se isso existir e nenhuma política do PAM estiver definida para um serviço, usa-se a política de OTHER. Um padrão seguro pode ser parecido com a Listagem 18:

Listagem 18. /etc/pam.d/other
      auth      required    pam_warn.so
      auth      required    pam_deny.so
      @include safe-account
      @include safe-password
      @include safe-session

Nesse exemplo, uma tentativa de autenticação primeiro é registrada no syslog e, em seguida, é negada. As instruções @include simplesmente incluem conteúdo de outros lugares, como /etc/pam.d/safe-account e amigos, onde essas definições "seguras" podem conter instruções semelhantes de "advertir e depois negar" para os outros <module-type>.

Agora vamos configurar o acesso ao nosso aplicativo hipotético classified-db. Devido à grande preocupação com o acesso, para que um usuário utilize esse aplicativo, ele tem que fornecer uma impressão digital ou passar pela identificação da retina e também inserir uma senha. No entanto, a senha pode estar armazenada nas configurações locais /etc/passwd e /etc/shadow ou disponível por meio de um de dois servidores de banco de dados externos disponíveis.

Nenhum dos módulos de segurança que eu usei nesse exemplo existe de verdade (até onde eu sei), com exceção de pam_unix.so , que é o acesso por senha antigo no estilo UNIX.

Listagem 19. /etc/pam.d/classified-db
      auth      optional    pam_unix.so
      auth      optional    pam_database1.so    try_first_pass
      auth      optional    pam_database2.so    use_first_pass
      auth      requisite   pam_somepasswd.so
      auth      sufficient  pam_fingerprint.so  master=file1 7points
      auth      required    pam_retinaprint.so

O fluxo dessa configuração é moderadamente complexo. Primeiro, tentamos a autenticação de senha por três tipos de módulo optional . Já que eles são optional, a falha em um deles não interrompe o processo de autenticação nem o cumpre. A senha de autenticação padrão do UNIX é tentada primeiro (o usuário tem que inserir uma senha). Depois disso, verificamos as senhas em database1, mas primeiro usamos o argumento de módulo genérico try_first_pass para ver se a senha do UNIX é igual à do banco de dados; solicitamos a senha adicional somente se ela não é. No entanto, com database2 , só tentamos autenticar usando a senha do UNIX que o usuário inseriu (argumento genérico use_first_pass).

Depois de fazer verificações em alguns sistemas de senha optional , usamos um hipotético pam_somepasswd.so que precisa determinar se alguma das verificações de senha anterior foi bem-sucedida (talvez usando um semáforo — mas a forma de fazer isso fica aberta para módulos hipotéticos). A questão é que, como essa verificação é requisite, caso ela falhe, nenhuma autenticação posterior é realizada e a falha é relatada.

As duas últimas verificações de autenticação (caso sejam atingidas) são sufficient. Ou seja, o preenchimento de uma delas retorna um status de sucesso geral para o aplicativo de chamada. Portanto, primeiro tentamos uma verificação de impressão digital usando pam_fingerprint.so (observe que alguns argumentos hipotéticos são passados para o módulo). Somente se isso falhar — talvez por causa da ausência de um scanner de impressão digital ou uma impressão digital inválida — tenta-se a identificação pela retina. Da mesma forma, se a identificação pela retina for bem-sucedida, esse fato é sufficient. Contudo, somente para demonstrar todos os sinalizadores, na verdade, usamos required aqui; isso significa que, mesmo com uma verificação de retina bem-sucedida, continuaríamos verificando outros métodos (mas neste exemplo não há mais nenhum — portanto sufficient faria a mesma coisa).

Também há uma forma de especificar sinalizadores compostos mais ajustados para <control-flag> usando conjuntos entre colchetes de [value1=action1 ...] , mas geralmente as palavras-chave básicas são suficientes.

Recursos

Aprender

Obter produtos e tecnologias

  • Com o o software de teste IBM, disponível para download diretamente do developerWorks, construa seu próximo projeto de desenvolvimento em Linux.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Software livre
ArticleID=830562
ArticleTitle=Preparação para o Exame LPI: Gerenciamento de cliente de rede
publish-date=08162012