Capítulo 29. Servidores de Rede

A configuração do inetd é feita editando o /etc/inetd.conf. Cada linha deste arquivo de configuração representa um aplicativo que pode ser iniciado pelo inetd. Por padrão, cada linha começa com um comentário (), o que significa que inetd não está atendendo a nenhum aplicativo. Para configurar o inetd para escutar as conexões de um aplicativo, remova o no início da linha desse aplicativo.

Depois de salvar suas edições, configure o inetd para iniciar na inicialização do sistema editando o arquivo /etc/rc.conf:

Para iniciar o inetd agora, para que ele ouça o serviço que você configurou, digite:

Uma vez iniciado o inetd, ele precisa ser notificado sempre que uma modificação for feita no arquivo /etc/inetd.conf:

Normalmente, a entrada padrão de um aplicativo não precisa ser editada além da remoção do #. Em algumas situações, pode ser apropriado editar a entrada padrão.

Como exemplo, esta é a entrada padrão para ftpd(8) sobre o IPv4:

As sete colunas em uma entrada são as seguintes:

Onde:

Como a maioria dos daemons de servidor, o inetd tem várias opções que podem ser usadas para modificar seu comportamento. Por padrão, inetd é iniciado com -wW -C 60. Essas opções ativam TCP wrappers para todos os serviços, incluindo serviços internos, e impedem que qualquer endereço de IP solicite qualquer serviço mais de 60 vezes por minuto.

Para alterar as opções padrão que são passadas para inetd, adicione uma entrada para inetd_flags no arquivo /etc/rc.conf. Se o inetd já estiver em execução, reinicie-o com service inetd restart.

As opções disponíveis de limitação de taxa são:

Opções adicionais estão disponíveis. Consulte inetd(8) para a lista completa de opções.

Muitos dos daemons que podem ser gerenciados pelo inetd não são conscientes da segurança. Alguns daemons, como fingerd, podem fornecer informações que podem ser úteis para um invasor. Ative apenas os serviços necessários e monitore o sistema para tentativas excessivas de conexão. max-connections-per-ip-por-minute, max-child e max-child-per-ip podem ser usados para limitar tais ataques.

Por padrão, TCP wrappers estão ativados. Consulte hosts_access(5) para obter mais informações sobre como colocar restrições TCP em vários daemons chamados pelo inetd.

Os sistemas de arquivos que o servidor NFS irá compartilhar são especificados no arquivo /etc/exports. Cada linha neste arquivo especifica um sistema de arquivos a ser exportado, quais clientes têm acesso a esse sistema de arquivos e quaisquer opções de acesso. Ao adicionar entradas a este arquivo, cada sistema de arquivos exportado, suas propriedades e hosts permitidos devem ocorrer em uma única linha. Se nenhum cliente estiver listado na entrada, qualquer cliente na rede poderá montar esse sistema de arquivos.

As seguintes entradas no arquivo /etc/exports demonstram como exportar sistemas de arquivos. Os exemplos podem ser modificados para corresponder aos sistemas de arquivos e nomes de clientes na rede do leitor. Existem muitas opções que podem ser usadas neste arquivo, mas apenas algumas serão mencionadas aqui. Veja exports(5) para a lista completa de opções.

Este exemplo mostra como exportar /cdrom para três hosts chamados alpha, bravo e charlie:

A flag -ro torna o sistema de arquivos somente leitura, impedindo que os clientes façam alterações no sistema de arquivos exportado. Este exemplo assume que os nomes de host estão no DNS ou no arquivo /etc/hosts. Consulte hosts(5) se a rede não tiver um servidor de DNS.

O próximo exemplo exporta /home para três clientes pelo endereço IP. Isso pode ser útil para redes sem DNS ou /etc/hosts. A flag -alldirs permite que os subdiretórios sejam pontos de montagem. Em outras palavras, ele não montará automaticamente os subdiretórios, mas permitirá que o cliente monte os diretórios necessários conforme necessário.

Este próximo exemplo exporta /a para que dois clientes de domínios diferentes possam acessar esse sistema de arquivos. -maproot=root permite que o usuário root no sistema remoto grave os dados no sistema de arquivos exportado como root. Se -maproot=root não for especificado, o usuário root do cliente será mapeado para a conta nobody do servidor e estará sujeito às limitações de acesso definidas para nobody.

Um cliente só pode ser especificado uma vez por sistema de arquivos. Por exemplo, se /usr for um único sistema de arquivos, essas entradas serão inválidas, já que ambas as entradas especificam o mesmo host:

O formato correto para essa situação é usar uma entrada:

A seguir, um exemplo de uma lista de exportação válida, em que /usr e /exports são sistemas de arquivos locais:

Para habilitar os processos requeridos pelo servidor NFS no momento da inicialização, adicione estas opções ao arquivo /etc/rc.conf:

O servidor pode ser iniciado agora executando este comando:

Sempre que o servidor NFS for iniciado, o mountd também é iniciado automaticamente. No entanto, mountd lê apenas /etc/exports quando é iniciado. Para fazer as edições subsequentes de /etc/exports entrarem em vigor imediatamente, force mountd para ler novamente:

Para ativar clientes NFS, defina essa opção no arquivo /etc/rc.conf de cada cliente:

Em seguida, execute este comando em cada cliente NFS:

O cliente agora tem tudo de que precisa para montar um sistema de arquivos remoto. Nestes exemplos, o nome do servidor é server e o nome do cliente é client. Para montar /home no server para o ponto de montagem /mnt no client:

Os arquivos e diretórios em /home agora estarão disponíveis no client, no diretório /mnt.

Para montar um sistema de arquivos remoto toda vez que o cliente for inicializado, adicione-o ao arquivo /etc/fstab:

Consulte fstab(5) para obter uma descrição de todas as opções disponíveis.

Alguns aplicativos exigem o bloqueio de arquivos para funcionar corretamente. Para ativar o bloqueio, adicione estas linhas ao arquivo /etc/rc.conf no cliente e no servidor:

Então inicie as aplicações:

Se o bloqueio não for necessário no servidor, o cliente NFS pode ser configurado para bloquear localmente incluindo -L ao executar o mount. Consulte mount_nfs(8) para mais detalhes.

O recurso autofs(5) é um nome comum para vários componentes que, juntos, permitem a montagem automática de sistemas de arquivos locais e remotos sempre que um arquivo ou diretório dentro desse sistema de arquivos é acessado. Ele consiste no componente do kernel, autofs(5) e vários aplicativos no espaço do usuário: automount(8), automountd(8) e autounmountd(8). Ele serve como uma alternativa para amd(8) de versões anteriores do FreeBSD. Amd ainda é fornecido para fins de compatibilidade com versões anteriores, já que os dois usam formato de mapeamento diferentes; o usado pelo autofs é o mesmo que com outros automontadores do SVR4, como os do Solaris, MacOS X e Linux.

O sistema de arquivos virtual autofs(5) é montado em pontos de montagem especificados por automount(8), geralmente chamado durante a inicialização.

Sempre que um processo tentar acessar o arquivo dentro do ponto de montagem autofs(), o kernel notificará o daemon automountd(8) e irá pausar o processo de disparo. O daemon automountd(8) processará as solicitações do kernel localizando o mapeamento apropriado e irá montar o sistema de arquivos de acordo com ele, então sinaliza ao kernel para liberar o processo bloqueado . O daemon autounmountd(8) desmonta automaticamente os sistemas de arquivos montados automaticamente após algum tempo, a menos que eles ainda estejam sendo usados.

O arquivo de configuração principal do autofs é o /etc/auto_master. Atribui mapeamentos individuais a montagens de nível superior. Para uma explicação do auto_master e da sintaxe do mapeamento, consulte auto_master(5).

Existe um mapeamento especial montado automaticamente em /net. Quando um arquivo é acessado dentro desse diretório, o autofs(5) procura a montagem remota correspondente e monta-a automaticamente. Por exemplo, uma tentativa de acessar um arquivo dentro de /net/foobar/usr informaria automountd(8) para montar a exportação /usr do host foobar.

A saída de showmount mostra /usr como uma exportação. Ao alterar os diretórios para /host/foobar/usr, o automountd(8) intercepta o pedido e tenta resolver o nome do host foobar. Se for bem-sucedido, automountd(8) montará automaticamente a exportação de origem.

Para habilitar autofs(5) no momento da inicialização, adicione esta linha ao arquivo /etc/rc.conf:

Em seguida, autofs(5) pode ser iniciado executando:

O formato de mapeamento de autofs(5) é o mesmo que em outros sistemas operacionais. Informações sobre este formato de outras fontes podem ser úteis, como o documento do Mac OS X.

Consulte as páginas de manuais automount(8), automountd(8), autounmountd(8) e auto_master(5) para maiores informações.

A Tabela 28.1 resume os termos e processos importantes usados pelo NIS:

Existem três tipos de hosts em um ambiente NIS:

Informações em muitos arquivos podem ser compartilhadas usando o NIS . Os arquivos master.passwd, group e hosts são comumente compartilhados via NIS. Sempre que um processo em um cliente precisa de informações que normalmente seriam encontradas nesses arquivos localmente, ele faz uma consulta ao servidor NIS ao qual está vinculado.

Esta seção descreve um ambiente NIS de exemplo que consiste em 15 máquinas FreeBSD sem ponto de administração centralizado. Cada máquina tem seu próprio /etc/passwd e /etc/master.passwd. Esses arquivos são mantidos em sincronia entre si somente por meio de intervenção manual. Atualmente, quando um usuário é adicionado ao laboratório, o processo deve ser repetido em todas as 15 máquinas.

A configuração do laboratório será a seguinte:

Se esta é a primeira vez que um esquema de NIS está sendo desenvolvido, ele deve ser cuidadosamente planejado através do tempo. Independentemente do tamanho da rede, várias decisões precisam ser tomadas como parte do processo de planejamento.

As cópias canônicas de todos os arquivos NIS são armazenadas no servidor master. Os bancos de dados usados para armazenar as informações são chamados de mapas de NIS. No FreeBSD, estes mapas são armazenados em /var/yp/[nome_do_domínio] onde [nome_do_dominio] é o nome do domínio NIS. Como vários domínios são suportados, é possível ter vários diretórios, um para cada domínio. Cada domínio terá seu próprio conjunto independente de mapas.

Os servidores master e slave do NIS lidam com todas as requisições NIS através do ypserv(8). Esse daemon é responsável por receber solicitações de entrada de clientes NIS, traduzindo o domínio e o nome do mapa solicitados para um caminho para o arquivo de banco de dados correspondente e transmitindo dados do banco de dados de volta ao cliente.

Configurar um servidor NIS master pode ser relativamente simples, dependendo das necessidades ambientais. Como o FreeBSD oferece suporte a NIS embutido, ele só precisa ser ativado adicionando as seguintes linhas ao arquivo /etc/rc.conf:

É preciso ter cuidado em um domínio com vários servidores, no qual as máquinas do servidor também são clientes NIS. Geralmente, é uma boa ideia forçar os servidores a fazerem bind em si mesmos, em vez de permitir que eles transmitam solicitações de bind e, possivelmente, fiquem vinculados um ao outro. Modos de falha estranhos podem ocorrer se um servidor cair e outros dependerem dele. Eventualmente, todos os clientes terão tempo limite e tentarão fazer bind em outros servidores, mas o atraso envolvido poderá ser considerável e o modo de falha ainda estará presente, uma vez que os servidores podem ligar-se entre si novamente.

Um servidor que também é um cliente pode ser forçado fazer bind em um servidor em particular adicionando estas linhas adicionais ao arquivo /etc/rc.conf:

Depois de salvar as edições, digite /etc/netstart para reiniciar a rede e aplicar os valores definidos no arquivo /etc/rc.conf. Antes de inicializar os mapas de NIS, inicie ypserv(8):

Para configurar um servidor NIS slave, faça o logon no servidor slave e edite o arquivo /etc/rc.conf assim como para o servidor master. Não gere nenhum mapa de NIS, pois estes já existem no servidor master. Ao executar ypinit no servidor slave, use -s (para slave) ao invés de -m (para master). Esta opção requer o nome do NIS master, além do nome do domínio, como visto neste exemplo:

Isto irá gerar um diretório no servidor slave chamado /var/yp/test-domain que contém cópias dos mapas do servidor principal do NIS. Adicionar estas entradas ao arquivo /etc/crontab em cada servidor slave forçará os slaves a sincronizar seus mapas com os mapas no servidor master:

Essas entradas não são obrigatórias porque o servidor master tenta enviar automaticamente quaisquer alterações no mapa para seus escravos. No entanto, como os clientes podem depender do servidor escravo para fornecer informações corretas de senha, recomenda-se forçar atualizações frequentes de mapas de senha. Isso é especialmente importante em redes ocupadas nas quais as atualizações de mapas nem sempre são concluídas.

Para finalizar a configuração, execute /etc/netstart no servidor slave para iniciar os serviços do NIS.

Um cliente NIS é vinculado a um servidor NIS usando ypbind(8). Esse daemon transmite solicitações de RPC na rede local. Essas solicitações especificam o nome do domínio configurado no cliente. Se um servidor NIS no mesmo domínio receber uma das transmissões, ele responderá a ypbind, que registrará o endereço do servidor. Se houver vários servidores disponíveis, o cliente usará o endereço do primeiro servidor para responder e direcionará todas as suas solicitações de NIS para esse servidor. O cliente irá automaticamente pingar o servidor regularmente para garantir que ainda esteja disponível. Se ele não receber uma resposta dentro de um período de tempo razoável, o ypbind marcará o domínio como não acoplado e começará a transmitir novamente na esperança de localizar outro servidor.

Para configurar uma máquina FreeBSD para ser um cliente NIS:

Para iniciar imediatamente o cliente NIS, execute os seguintes comandos como superusuário:

Depois de concluir estas etapas, a execução do ypcat passwd no cliente deve mostrar o mapa passwd do servidor.

Como o RPC é um serviço baseado em broadcast, qualquer sistema executando o ypbind dentro do mesmo domínio pode recuperar o conteúdo dos mapas do NIS. Para evitar transações não autorizadas, ypserv(8) suporta um recurso chamado "securenets" que pode ser usado para restringir o acesso a um dado conjunto de hosts. Por padrão, essas informações são armazenadas no arquivo /var/yp/securenets, a menos que ypserv(8) seja iniciado com -p e um caminho alternativo. Este arquivo contém entradas que consistem em uma especificação de rede e uma máscara de rede separadas por espaço em branco. Linhas iniciando com # são consideradas comentários. Um exemplo de securenets pode ser assim:

Se ypserv(8) receber uma solicitação de um endereço que corresponda a uma dessas regras, ela processará a solicitação normalmente. Se o endereço não corresponder a uma regra, a solicitação será ignorada e uma mensagem de aviso será registrada. Se o securenets não existir, o ypserv permitirá conexões de qualquer host.

TCP Wrapper é um mecanismo alternativo para fornecer controle de acesso em vez de securenets. Embora o mecanismo de controle de acesso acrescente alguma segurança, ambos são vulneráveis a ataques como "IP spoofing". Todo o tráfego relacionado a NIS deve ser bloqueado no firewall.

Servidores que usam securenets podem não servir clientes legítimos de NIS com implementações arcaicas de TCP/IP. Algumas dessas implementações definem todos os bits do host como zero ao fazer transmissões ou não observam a máscara de sub-rede ao calcular o endereço de transmissão. Embora alguns desses problemas possam ser corrigidos alterando a configuração do cliente, outros problemas podem forçar a desativação desses sistemas clientes ou o abandono do securenets.

O uso de TCP Wrapper aumenta a latência do servidor NIS. O atraso adicional pode ser longo o suficiente para causar timeouts em programas clientes, especialmente em redes ocupadas com servidores NIS lentos. Se um ou mais clientes sofrerem de latência, converta esses clientes em servidores de NIS slaves e force-os a se ligarem a eles mesmos.

A exclusão de usuários especificados do logon em sistemas individuais torna-se imprestável em redes maiores e perde rapidamente o principal benefício do NIS: administração centralizada.

Os netgroups foram desenvolvidos para lidar com redes grandes e complexas com centenas de usuários e máquinas. Seu uso é comparável aos grupos UNIX™, onde a principal diferença é a falta de um ID numérico e a capacidade de definir um netgroup incluindo contas de usuário e outros netgroups.

Para expandir o exemplo usado neste capítulo, o domínio NIS será estendido para adicionar os usuários e sistemas mostrados nas Tabelas 28.2 e 28.3:

Ao usar netgroups para configurar esse cenário, cada usuário é atribuído a um ou mais netgroups e os logins são permitidos ou proibidos para todos os membros do netgroup. Ao adicionar uma nova máquina, as restrições de login devem ser definidas para todos os netgroups. Quando um novo usuário é adicionado, a conta deve ser adicionada a um ou mais netgroups. Se a configuração do NIS for planejada com cuidado, somente um arquivo de configuração central precisará ser modificado para conceder ou negar acesso a máquinas.

O primeiro passo é a inicialização do mapa do NIS netgroup. No FreeBSD, este mapa não é criado por padrão. No servidor NIS master, use um editor para criar um mapa chamado /var/yp/netgroup.

Este exemplo cria quatro grupos de rede para representar funcionários de TI, aprendizes de TI, funcionários e estagiários:

Cada entrada configura um netgroup. A primeira coluna em uma entrada é o nome do netgroup. Cada conjunto de colchetes representa um grupo de um ou mais usuários ou o nome de outro grupo de rede. Ao especificar um usuário, os três campos delimitados por vírgula dentro de cada grupo representam:

Se um grupo contiver vários usuários, separe cada usuário com espaço em branco. Além disso, cada campo pode conter curingas. Veja netgroup(5) para detalhes.

Nomes de grupos maiores que 8 caracteres não devem ser usados. Os nomes diferenciam maiúsculas de minúsculas e usar letras maiúsculas para nomes de grupos de rede é uma maneira fácil de distinguir entre nomes de usuários, máquinas e grupos de rede.

Alguns clientes não-FreeBSD NIS não podem lidar com netgroups contendo mais de 15 entradas. Esse limite pode ser contornado criando vários grupos de sub-redes com 15 usuários ou menos e um grupo de rede real consistindo dos grupos de sub-redes, como visto neste exemplo:

Repita este processo se mais de 225 (15 vezes 15) usuários existirem dentro de um único netgroup.

Para ativar e distribuir o novo mapa do NIS:

Isso gerará os três mapas NIS, netgroup, netgroup.byhost e netgroup.byuser. Use a opção de chave de mapa ypcat(1) para verificar se os novos mapas de NIS estão disponíveis:

A saída do primeiro comando deve lembrar o conteúdo de /var/yp/netgroup. O segundo comando só produz saída se os netgroups específicos do host foram criados. O terceiro comando é usado para obter a lista de netgroups de um usuário.

Para configurar um cliente, use vipw(8) para especificar o nome do netgroup. Por exemplo, no servidor chamado war, substitua esta linha:

com

Isso especifica que apenas os usuários definidos no netgroup IT_EMP serão importados para o banco de dados de senhas deste sistema e somente esses usuários terão permissão para efetuar login nesse sistema.

Essa configuração também se aplica à função ~ do shell e a todas as rotinas que convertem entre nomes de usuário e IDs de usuário numérico. Em outras palavras, cd ~user não funcionará, ls -l mostrará o ID numérico em vez do nome de usuário e find . -user joe -print falhará com a mensagem No such user. Para corrigir isso, importe todas as entradas do usuário sem permitir que elas efetuem login nos servidores. Isto pode ser conseguido adicionando uma linha extra:

Esta linha configura o cliente para importar todas as entradas, mas para substituir o shell nessas entradas com /usr/sbin/nologin.

Certifique-se que a linha extra é colocada após +@IT_EMP:::::::::. Caso contrário, todas as contas de usuário importadas do NIS terão /usr/sbin/nologin como seu shell de login e ninguém poderá efetuar o login no sistema.

Para configurar os servidores menos importantes, substitua o antigo +::::::::: nos servidores com estas linhas:

As linhas correspondentes para as estações de trabalho seriam:

O NIS suporta a criação de grupos de rede de outros grupos de rede, o que pode ser útil se a política relacionada ao acesso do usuário for alterada. Uma possibilidade é a criação de netgroups baseados em funções. Por exemplo, pode-se criar um netgroup chamado BIGSRV para definir as restrições de login para os servidores importantes, outro grupo de rede chamado SMALLSRV para os servidores menos importantes e um terceiro netgroup chamado USERBOX para as estações de trabalho. Cada um desses netgroups contém os netgroups com permissão para efetuar login nessas máquinas. As novas entradas para o mapa do NIS netgroup seriam assim:

Esse método de definir restrições de login funciona razoavelmente bem quando é possível definir grupos de máquinas com restrições idênticas. Infelizmente, esta é a exceção e não a regra. Na maioria das vezes, é necessária a capacidade de definir restrições de login por máquina.

As definições de netgroup específicas da máquina são outra possibilidade para lidar com as mudanças na política. Neste cenário, o /etc/master.passwd de cada sistema contém duas linhas que começam com "+". A primeira linha adiciona um netgroup com as contas permitidas para entrar nesta máquina e a segunda linha adiciona todas as outras contas com /usr/sbin/nologin como shell. Recomenda-se usar a versão "ALL-CAPS" do nome do host como o nome do netgroup:

Quando esta tarefa estiver completa em todas as máquinas, não haverá mais a necessidade de modificar as versões locais de /etc/master.passwd novamente. Todas as alterações posteriores podem ser manipuladas, modificando o mapa do NIS. Aqui está um exemplo de um possível mapa netgroup para este cenário:

Pode não ser sempre aconselhável usar netgroups baseados em máquina. Ao implantar algumas dúzias ou centenas de sistemas, grupos de rede baseados em funções em vez de grupos de rede baseados em máquina podem ser usados para manter o tamanho do mapa do NIS dentro de limites razoáveis.

O NIS requer que todos os hosts em um domínio NIS usem o mesmo formato para criptografar senhas. Se os usuários tiverem problemas para autenticar em um cliente NIS, pode ser devido a um formato de senha diferente. Em uma rede heterogênea, o formato deve ser suportado por todos os sistemas operacionais, onde DES é o padrão comum mais baixo.

Para verificar qual formato um servidor ou cliente está usando, veja esta seção do /etc/login.conf:

Neste exemplo, o sistema está usando o formato DES. Outros valores possíveis são blf para Blowfish e md5 para senhas criptografadas com MD5.

Se o formato em um host precisar ser editado para corresponder ao que está sendo usado no domínio NIS, o banco de dados de recursos de login deve ser reconstruído após salvar a alteração:

O LDAP usa vários termos que devem ser entendidos antes de iniciar a configuração. Todas as entradas de diretório consistem em um grupo de attributes. Cada um desses conjuntos de atributos contém um identificador exclusivo conhecido como Distinguished Name (DN) que é normalmente criado a partir de vários outros atributos, como Common ou Relative Distinguished Name (RDN). Semelhante a como os diretórios têm caminhos absolutos e relativos, considere um DN como um caminho absoluto e o RDN como o caminho relativo.

Um exemplo de entrada LDAP é semelhante ao seguinte. Este exemplo procura a entrada para a conta de usuário especificada (uid), unidade organizacional (ou) e organização (o):

Esta entrada de exemplo mostra os valores para os atributos dn, mail, cn, uid e telephoneNumber. O atributo do cn é o RDN.

Maiores informações sobre o LDAP e sua terminologia podem ser encontradas em http://www.openldap.org/doc/admin24/intro.html.

O FreeBSD não provê um servidor LDAP embutido. Comece a configuração instalando o pacote ou port net/openldap-server:

Aqui está um largo conjunto de opções habilitadas no pacote. Reveja-os rodando o comando pkg info openldap-server. Se não for suficiente (por exemplo se o suporte a SQL for necessário), por favor considere recompilar o port usando o framework apropriado.

A instalação cria o diretório /var/db/openldap-data para conter os dados. O diretório para armazenar os certificados deve ser criado:

A próxima fase é configurar a autoridade de certificação. Os seguintes comandos devem ser executados em /usr/local/etc/openldap/private. Isso é importante, pois as permissões de arquivo precisam ser restritivas e os usuários não devem ter acesso a esses arquivos. Informações mais detalhadas sobre certificados e seus parâmetros podem ser encontradas em OpenSSL. Para criar a Autoridade de Certificação, comece com este comando e siga os prompts:

As entradas para os prompts podem ser genéricas exceto para o Common Name. Esta entrada deve ser diferente do nome do host do sistema. Se este será um certificado auto-assinado, prefixe o nome do host com CA para a Autoridade de Certificação.

A próxima tarefa é criar uma solicitação de assinatura de certificado e uma chave privada. Insira este comando e siga os prompts:

Durante o processo de geração de certificados, certifique-se de configurar corretamente o atributo Common Name. A Solicitação de Assinatura de Certificado deve ser assinada com a Autoridade de Certificação para ser usada como um certificado válido:

A parte final do processo de geração de certificados é gerar e assinar os certificados do cliente:

Lembre-se de usar o mesmo atributo Common Name quando solicitado. Quando terminar, assegure-se de que um total de oito (8) novos arquivos tenham sido gerado através dos comandos procedentes.

O daemon que executa o servidor OpenLDAP é o slapd. Sua configuração é executada através do slapd.ldif: o antigo slapd.conf foi descontinuado pelo OpenLDAP.

Exemplos de configuração para o slapd.ldif estão disponíveis e também podem ser encontrados em /usr/local/etc/openldap/slapd.ldif.sample. As opções estão documentadas em slapd-config(5). Cada seção do slapd.ldif, como todos os outros conjuntos de atributos LDAP, é identificada exclusivamente por meio de um DN. Certifique-se de que nenhuma linha em branco seja deixada entre a instrução dn: e o final desejado da seção. No exemplo a seguir, o TLS será usado para implementar um canal seguro. A primeira seção representa a configuração global:

A Autoridade de Certificação, o certificado do servidor e os arquivos de chave privada do servidor devem ser especificados aqui. Recomenda-se que os clientes escolham a opção de criptografia de segurança e omitam olcTLSCipherSuite (incompatível com clientes TLS diferentes de openssl). A opção olcTLSProtocolMin permite que o servidor exija um nível mínimo de segurança: é recomendado. Enquanto a verificação é obrigatória para o servidor, não é para o cliente: olcTLSVerifyClient: never.

A segunda seção é sobre os módulos de backend e pode ser configurada da seguinte maneira:

A terceira seção é dedicada a carregar os esquemas ldif necessários para serem usados pelos bancos de dados: eles são essenciais.

Em seguida, a seção de configuração do frontend:

Outra seção é dedicada ao backend de configuração, a única maneira de acessar posteriormente a configuração do servidor OpenLDAP é como um superusuário global.

O nome de usuário administrador padrão é cn=config. Digite slappasswd em um shell, escolha a senha e use sua hash olcRootPW. Se essa opção não for especificada agora, antes do arquivo slapd.ldif ser importado, ninguém poderá modificar a seção de configuração global.

A última seção é sobre o back-end do banco de dados:

Esse banco de dados hospeda os conteudos atuais do diretório LDAP. Outros tipos diferentes de mdb estão disponiveis. Esse é super-usuário, não confundir com um global, é configurado aqui: um usuário (possivelmente customizado) em olcRootDN e a hash da senha em olcRootPW; slappasswd pode ser usado como antes.

Esse repositorio contém quatro exemplos do arquivo slapd.ldif. Para converter um arquivo slapd.conf existente dentro de slapd.ldif, referencie a essa página (por favor, note que isso pode introduzir algumas opções inuteis).

Quando a configuração estiver concluída, o slapd.ldif deve ser colocado em um diretório vazio. Recomenda-se criá-lo como:

Importe o banco de dados de configuração:

Inicie o daemon slapd:

A opção -d pode ser usada para depuração, conforme especificado em slapd(8). Para verificar se o servidor está em execução e funcionando:

O servidor ainda deve ser confiável. Se isso nunca foi feito antes, siga estas instruções. Instale o pacote ou o port OpenSSL:

No diretório onde o ca.crt está armazenado (neste exemplo, /usr/local/etc/openldap), execute:

Tanto a CA quanto o certificado do servidor agora são reconhecidos corretamente em suas respectivas funções. Para verificar isso, execute este comando no diretório server.crt:

Se o slapd estiver em execução, reinicie-o. Como declarado em /usr/local/etc/rc.d/slapd, para executar corretamente o slapd na inicialização, as seguintes linhas devem ser adicionadas ao /etc/rc.conf:

O slapd não fornece depuração na inicialização. Verifique o /var/log/debug.log, o dmesg -a e o /var/log/messages para este propósito.

O exemplo a seguir adiciona o grupo team e o usuário john ao banco de dados LDAP de domain.example, que ainda está vazio. Primeiro, crie o arquivo domain.ldif:

Veja a documentação do OpenLDAP para mais detalhes. Use slappasswd para substituir a senha secret em texto puro com um hash no userPassword. O caminho especificado como loginShell deve existir em todos sistemas onde john pode se logar. Finalmente, use o administrador mdb para modificar o banco de dados:

Modificações para a seção configurações globais podem ser feitas apenas pelo super-usuário global. Por exemplo, assume que a opção olcTLSCipherSuite: HIGH:MEDIUM:SSLv3 foi inicialmente especificada e deve agora ser deletada. Primeiro, crie um arquivo que contenha o seguinte:

Em seguida, aplique as modificações:

Quando solicitado, forneça a senha escolhida na seção configuração backend. O nome de usuário não é necessário: aqui, cn=config representa o DN da seção do banco de dados a ser modificada. Como alternativa, use ldapmodify para excluir uma única linha do banco de dados, ldapdelete para excluir uma entrada inteira.

Se algo der errado ou se o superusuário global não puder acessar o backend de configuração, é possível excluir e reescrever toda a configuração:

O slapd.ldif pode então ser editado e importado novamente. Por favor, siga este procedimento somente quando nenhuma outra solução estiver disponível.

Esta é a configuração do servidor apenas. A mesma máquina também pode hospedar um cliente LDAP, com sua própria configuração separada.

O suporte ao cliente DHCP está incluído no instalador do FreeBSD, facilitando a configuração de um sistema recém-instalado para receber automaticamente as informações de endereçamento de rede de um servidor DHCP existente. Consulte Pós-instalação para exemplos de configuração de rede.

Quando o dhclient é executado na máquina cliente, ele inicia as solicitações de transmissão das informações de configuração. Por padrão, esses pedidos usam a porta UDP 68. O servidor responde na porta UDP 67 , fornecendo ao cliente um endereço IP e outras informações de rede relevantes como uma máscara de sub-rede, gateway padrão e endereços de servidor DNS. Esta informação está na forma de uma "concessão" de DHCP e é válida por um tempo configurável. Isso permite que endereços IP obsoletos para clientes que não estejam mais conectados à rede sejam reutilizados automaticamente. Clientes DHCP podem obter uma grande quantidade de informações do servidor. Uma lista exaustiva pode ser encontrada em dhcp-options(5).

Por padrão, quando um sistema FreeBSD inicializa, seu cliente DHCP é executado em segundo plano, ou asynchronously. Outros scripts de inicialização continuam sendo executados enquanto o processo DHCP é concluído, o que acelera a inicialização do sistema.

O DHCP em segundo plano funciona bem quando o servidor DHCP responde rapidamente às solicitações do cliente. No entanto, o DHCP pode levar muito tempo para ser concluído em alguns sistemas. Se os serviços de rede tentarem executar antes que o DHCP tenha atribuído as informações de endereçamento de rede, eles falharão. O uso do DHCP no modo synchronous impede esse problema, pois ele pausa a inicialização até que a configuração DHCP seja concluída.

Esta linha no /etc/rc.conf é usada para configurar o modo background ou assíncrono:

Esta linha pode já existir se o sistema foi configurado para usar o DHCP durante a instalação. Substitua o fxp0 mostrado nesses exemplos pelo nome da interface a ser configurada dinamicamente, conforme descrito em Configurando Placas de Interface de Rede.

Para configurar o sistema para usar o modo síncrono e pausar durante a inicialização enquanto o DHCP é concluído, use “SYNCDHCP”:

Opções adicionais do cliente estão disponíveis. Procure por dhclient in rc.conf(5) para detalhes.

O cliente DHCP usa os seguintes arquivos:

Esta seção demonstra como configurar um sistema FreeBSD para atuar como um servidor DHCP usando a implementação do servidor DHCP do Internet Systems Consortium (ISC). Esta implementação e a sua documentação podem ser instaladas usando o pacote ou port net/isc-dhcp44-server.

A instalação do net/isc-dhcp44-server instala um arquivo de configuração de exemplo. Copie o /usr/local/etc/dhcpd.conf.example para /usr/local/etc/dhcpd.conf e faça as alterações neste novo arquivo.

O arquivo de configuração é composto de declarações para sub-redes e hosts que definem as informações que são fornecidas aos clientes DHCP. Por exemplo, essas linhas configuram o seguinte:

Este arquivo de configuração suporta muito mais opções. Consulte o dhcpd.conf(5), instalado com o servidor, para obter detalhes e exemplos.

Uma vez que a configuração do dhcpd.conf estiver completa, habilite o servidor DHCP em /etc/rc.conf:

Substitua o dc0 pela interface (ou interfaces, separadas por espaço em branco) que o servidor DHCP deverá escutar por solicitações de clientes DHCP.

Inicie o servidor executando o seguinte comando:

Quaisquer mudanças futuras na configuração do servidor exigirão que o serviço dhcpd seja interrompido e, em seguida, iniciado usando service(8).

O servidor DHCP usa os seguintes arquivos. Observe que as páginas de manual são instaladas com o software do servidor.

Os servidores de nomes geralmente vêm em duas formas: servidores de nomes autoritativos e servidores de nomes de armazenamento em cache (também conhecidos como servidores de resolução).

Um servidor de nomes autoritativo é necessário quando:

Um servidor de nomes em cache é necessário quando:

Quando alguém pergunta por www.FreeBSD.org, o resolvedor geralmente consulta o servidor de nomes do ISP e recupera a resposta. Com um servidor local, de cache DNS, a consulta só precisa ser feita uma vez para o mundo externo pelo servidor de Cache DNS. Consultas adicionais não precisarão sair da rede local, pois as informações estão armazenadas em um cache local.

O Unbound é fornecido no sistema básico do FreeBSD. Por padrão, ele fornecerá a resolução de DNS apenas para a máquina local. Embora o pacote básico do sistema possa ser configurado para fornecer serviços de resolução além da máquina local, é recomendável que esses requisitos sejam resolvidos instalando o Unbound da coleção de ports do FreeBSD.

Para ativar o Unbound, adicione o seguinte ao /etc/rc.conf:

Quaisquer servidores de nomes existentes em /etc/resolv.conf serão configurados como forwarders na nova configuração do Unbound.

Quando cada servidor de nomes for confirmado para suportar DNSSEC, inicie o Unbound:

Isso cuidará da atualização do arquivo /etc/resolv.conf para que as consultas para domínios seguros DNSSEC funcionem agora. Por exemplo, execute o seguinte DNSSEC para validar a árvore confiável do FreeBSD.org :

No FreeBSD, o arquivo de configuração principal do Apache HTTP Server é instalado como /usr/local/etc/apache2x/httpd.conf, onde x representa o número da versão. Este arquivo ASCII de texto inicia as linhas de comentário com um #. As diretivas modificadas com mais freqüência são:

É sempre uma boa ideia fazer uma cópia de backup do arquivo de configuração do Apache padrão antes de fazer alterações. Quando a configuração do Apache estiver concluída, salve o arquivo e verifique a configuração usando o apachectl. A execução do apachectl configtest deve retornar Syntax OK.

Para iniciar o Apache na inicialização do sistema, adicione a seguinte linha ao /etc/rc.conf:

Se o Apache deve ser iniciado com opções não-padrão, a seguinte linha pode ser adicionada ao /etc/rc.conf para especificar os flags necessários:

Se o apachectl não relatar erros de configuração, inicie o httpd agora:

O serviço httpd pode ser testado inserindo http://localhost em um navegador da Web, substituindo localhost pelo nome de domínio totalmente qualificado da máquina que está executando o httpd. A página padrão da Web exibida é /usr/local/www/apache24/data/index.html.

A configuração do Apache pode ser testada quanto a erros depois de fazer alterações subsequentes de configuração enquanto o httpd está em execução usando o seguinte comando:

A hospedagem virtual permite que vários sites sejam executados em um servidor Apache. Os hosts virtuais podem ser baseados em IP ou baseados em nome. A hospedagem virtual baseada em IP usa um endereço IP diferente para cada site. A hospedagem virtual baseada em nome usa os cabeçalhos HTTP/1.1 do cliente para descobrir o nome do host, o que permite que os sites compartilhem o mesmo endereço de IP.

Para configurar o Apache para usar hospedagem virtual baseada em nome, adicione um bloco VirtualHost para cada site. Por exemplo, para o servidor Web denominado www.domain.tld com um domínio virtual de www.someotherdomain.tld, adicione as seguintes entradas ao arquivo httpd.conf:

Para cada host virtual, substitua os valores de ServerName e DocumentRoot pelos valores a serem usados.

Para obter mais informações sobre como configurar hosts virtuais, consulte a documentação oficial do Apache em: http://httpd.apache.org/docs/vhosts/.

O Apache usa módulos para aumentar a funcionalidade fornecida pelo servidor básico. Consulte o http://httpd.apache.org/docs/current/mod/ para uma lista completa e detalhes de configuração para os módulos disponíveis.

No FreeBSD, alguns módulos podem ser compilados com o port www/apache24. Digite make config dentro do diretório /usr/ports/www/apache24 para ver quais módulos estão disponíveis e quais estão ativados por padrão. Se o módulo não é compilado com o port, a Coleção de Ports do FreeBSD fornece uma maneira fácil de instalar vários módulos. Esta seção descreve três dos módulos mais usados.

Além do mod_perl e do mod_php, outras linguagens estão disponíveis para a criação de conteúdo dinâmico da web. Estes incluem o Django e o Ruby on Rails.

A etapa de configuração mais importante é decidir quais contas terão permissão para acessar o servidor FTP. Um sistema FreeBSD possui várias contas do sistema que não devem ter acesso ao FTP. A lista de usuários que não permitem acesso FTP pode ser encontrada em /etc/ftpusers. Por padrão, inclui contas do sistema. Usuários adicionais que não devem ter acesso a FTP podem ser adicionados.

Em alguns casos, pode ser desejável restringir o acesso de alguns usuários sem impedi-los completamente de usar o FTP. Isso pode ser feito criando /etc/ftpchroot como descrito em ftpchroot(5). Este arquivo lista usuários e grupos sujeitos a restrições de acesso a FTP.

Para permitir acesso anônimo ao servidor FTP, crie um usuário chamado ftp no sistema FreeBSD. Os usuários poderão então fazer logon no servidor FTP com um nome de usuário ftp ou anonymous . Quando for solicitada a senha, qualquer entrada será aceita, mas por convenção, um endereço de e-mail deverá ser usado como a senha. O servidor FTP chamará chroot(2) quando um usuário anônimo efetuar login para restringir o acesso somente ao diretório home do usuário ftp.

Existem dois arquivos de texto que podem ser criados para especificar mensagens de boas-vindas a serem exibidas para clientes FTP. O conteúdo de /etc/ftpwelcome será exibido aos usuários antes que eles atinjam o prompt de login. Após um login bem sucedido, o conteúdo de /etc/ftpmotd será exibido. Observe que o caminho para esse arquivo é relativo ao ambiente de login, portanto, o conteúdo de ~ftp/etc/ftpmotd seria exibido para usuários anônimos.

Uma vez configurado o servidor FTP, defina a variável apropriada em /etc/rc.conf para iniciar o serviço durante a inicialização:

Para iniciar o serviço agora:

Teste a conexão com o servidor FTP digitando:

O daemon ftpd usa o syslog(3) para registrar mensagens. Por padrão, o daemon de log do sistema gravará mensagens relacionadas a FTP em /var/log/xferlog. A localização do log do FTP pode ser modificada alterando a seguinte linha no /etc/syslog.conf:

O Samba é configurado em /usr/local/etc/smb4.conf. Este arquivo deve ser criado antes que o Samba possa ser usado.

Um simples smb4.conf para compartilhar diretórios e impressoras com clientes Windows™ em um grupo de trabalho é mostrado aqui. Para configurações mais complexas envolvendo LDAP ou Active Directory, é mais fácil usar o samba-tool(8) para criar o smb4.conf.

Para habilitar o Samba no momento da inicialização, adicione a seguinte linha ao /etc/rc.conf:

Para iniciar o Samba agora:

O Samba consiste em três daemons separados. Os daemons nmbd e smbd são iniciados por samba_enable. Se resolução de nomes winbind também é necessária, defina:

O Samba pode ser interrompido a qualquer momento digitando:

O Samba é um conjunto de software complexo com funcionalidade que permite ampla integração com as redes Microsoft™Windows™. Para mais informações sobre a funcionalidade além da configuração básica descrita aqui, consulte https://www.samba.org.

No FreeBSD, o ntpd nativo pode ser usado para sincronizar o relógio do sistema. O Ntpd é configurado usando variáveis no rc.conf(5) e no /etc/ntp.conf, conforme detalhado nas seções a seguir.

O Ntpd se comunica com seus network peers usando pacotes UDP. Quaisquer firewalls entre sua máquina e seus NTP peers devem ser configurados para permitir a entrada e saída de pacotes UDP na porta 123.

O ntpd não precisa de uma conexão permanente com a Internet para funcionar corretamente. No entanto, se uma conexão PPP estiver configurada para discar sob demanda, o tráfego de NTP deverá ser impedido de disparar uma discagem ou manter a conexão ativa. Isso pode ser configurado com as diretivas filter em /etc/ppp/ppp.conf. Por exemplo:

Para mais detalhes, consulte a seção PACKET FILTERING em ppp(8) e os exemplos em /usr/shared/examples/ppp/.

Para configurar um alvo iSCSI, crie o arquivo de configuração /etc/ctl.conf, adicione uma linha ao arquivo /etc/rc.conf para certificar-se de que o daemon ctld(8) seja iniciado automaticamente na inicialização e, em seguida, inicie-o.

A seguir, um exemplo de um arquivo de configuração simples /etc/ctl.conf. Consulte ctl.conf(5) para obter uma descrição mais completa das opções disponíveis deste arquivo.

A primeira entrada define o grupo de portais pg0. Grupos de portal definem quais endereços de rede o daemon ctld(8) irá escutar. A entrada discovery-auth-group no-authentication indica que qualquer iniciador tem permissão para executar descoberta de alvo iSCSI sem autenticação. As linhas três e quatro configuram ctld(8) para escutar em todos os endereços IPv4 (listen 0.0.0.0) e IPv6 (listen [::]) na porta padrão 3260.

Não é necessário definir um grupo de portais, pois há um grupo de portais interno chamado default. Nesse caso, a diferença entre default e pg0 é que com default, a descoberta de alvo é sempre negada, enquanto com pg0, é sempre permitido.

A segunda entrada define um único alvo. O alvo tem dois significados possíveis: uma máquina que atende iSCSI ou um grupo nomeado de LUNs. Este exemplo usa o último significado, onde iqn.2012-06.com.example:target0 é o nome do alvo. Este nome de alvo é adequado para fins de teste. Para uso real, altere com.example para o nome de domínio real, invertido. O 2012-06 representa o ano e o mês de aquisição do controle desse nome de domínio, e target0 pode ser qualquer valor. Qualquer número de alvos pode ser definido neste arquivo de configuração.

A linha auth-group no-authentication permite que todos os iniciadores se conectem ao alvo especificado e portal-group pg0 torna o alvo acessível através do grupo do portal pg0.

A próxima seção define o LUN. Para o iniciador, cada LUN será visível como um dispositivo de disco separado. Múltiplos LUNs podem ser definidos para cada destino. Cada LUN é identificado por um número, onde LUN 0 é obrigatório. A linha path/data/target0-0 define o caminho completo para um arquivo ou zvol que suporta o LUN. Esse caminho deve existir antes de iniciar ctld(8). A segunda linha é opcional e especifica o tamanho do LUN.

Em seguida, para ter certeza que o daemon ctld(8) foi iniciado no boot, adicione esta linha ao arquivo /etc/rc.conf:

Para iniciar o ctld(8) agora, execute este comando:

Quando o daemon ctld(8) é iniciado, ele lê o arquivo /etc/ctl.conf. Se este arquivo for editado depois que o daemon iniciar, use este comando para que as mudanças entrem em vigor imediatamente:

O inicializador iSCSI requer que o daemon iscsid(8) esteja em execução. Este daemon não usa um arquivo de configuração. Para iniciá-lo automaticamente na inicialização, adicione esta linha ao arquivo /etc/rc.conf:

Para iniciar iscsid(8) agora, execute este comando:

Conectar-se a um alvo pode ser feito com ou sem um arquivo /etc/iscsi.conf de configuração. Esta seção demonstra os dois tipos de conexões.