Administração de Sistemas Linux: Serviços para Internet

Wagner Vieira Léo tem 25 anos de experiência na área de TI, atuando como Analista de Suporte e em Computação de Alto Desempenho, com foco em sistemas operacionais Unix/Linux. Possui graduação em Matemática pela Faculdade de Humanidades Pedro II, com Pós-Graduação em Gestão da Inovação pelo LNCC/UCP. Atualmente ocupa o cargo de Coordenador de Tecnologia da Informação do Laboratório Nacional de Computação Científica e de Coordenador Administrativo do Ponto de Presença da RNP no Rio de Janeiro. Professor do Instituto Superior de Tecnologia da Informação de Petrópolis, IST e da Escola Superior de Redes da RNP, nas áreas de Segurança da Informação e Sistemas Operacionais.

uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP,

LIVRO DE APOIO AO CURSO

André Ramos Carneiro possui graduação em Tecnólogo em Tecnologia da Informação e Comunicação pelo Instituto Superior de Tecnologia em Ciência da Computação (2006). Trabalha com suporte à Linux desde 2005 e atualmente é Tecnologista do Laboratório Nacional de Computação Científica, onde trabalha com administração de servidores, gerência de contas de usuários, implementação de novos serviços, suporte a plataformas de processamento de alto desempenho, compilação de aplicações científicas, administração de storage e backup. Tem experiência na área de Ciência da Computação, com ênfase em Computação de Alto Desempenho, atuando principalmente nos seguintes temas: previsão numérica de tempo, processamento paralelo, aplicações científicas e I/O paralelo.

e Pesquisa – é qualificada como

O curso ensina a projetar, instalar, configurar e disponibilizar os principais serviços para internet em uma rede TCP/IP. Apresenta os conceitos associados a cada um dos serviços, e a instalação e configuração do KVM como base para o ambiente de virtualização. Aborda a autenticação nos serviços com LDAP, com apoio intensivo de atividades práticas.

Administração de Sistemas Linux Serviços para Internet

Bruno Alves Fagundes é tecnólogo em Tecnologia da Informação e da Computação pelo Instituto Superior de Tecnologia (2007) e especialista em Segurança de Redes pela Universidade Estácio de Sá (2011). Tem experiência em administração de servidores Linux, gerenciamento de usuário, implementação e gerência de serviços de rede, clusters, segurança de redes, shell script, PHP, Perl. Atualmente é colaborador do LNCC, onde trabalha na administração dos servidores e clusters do Laboratório de Bioinformática (LABINFO), provendo infraestrutura para a realização de pesquisas e processamento massivo de dados.

A RNP – Rede Nacional de Ensino

Administração de Sistemas Linux

Serviços para Internet Wagner Vieira Leo Bruno Alves Fagundes André Ramos Carneiro

que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação ISBN 978-85-63630-55-1

Ministério da Ciência, Tecnologia e Inovação

9 788563 630551

ads4.capa-NPE-V3.0.0.indd 1

27/04/2016 14:06:54

A RNP – Rede Nacional de Ensino e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP, que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação Ministério da Ciência, Tecnologia e Inovação

Administração de Sistemas Linux:

Serviços para Internet Wagner Vieira Leo Bruno Alves Fagundes André Ramos Carneiro

Administração de Sistemas Linux:

Serviços para Internet Wagner Vieira Leo Bruno Alves Fagundes André Ramos Carneiro

Rio de Janeiro Escola Superior de Redes 2016

Copyright © 2016 – Rede Nacional de Ensino e Pesquisa – RNP Rua Lauro Müller, 116 sala 1103 22290-906 Rio de Janeiro, RJ Diretor Geral

Nelson Simões Diretor de Serviços e Soluções

José Luiz Ribeiro Filho

Escola Superior de Redes Coordenação Nacional

Leandro Marcos de Oliveira Guimarães Edição Lincoln da Mata Revisão Técnica Bruno Alves Fagundes Coordenação Acadêmica de Administração de Sistemas Renato Duarte Equipe ESR (em ordem alfabética) Adriana Pierro, Alynne Pereira, Celia Maciel, Derlinéa Miranda, Edson Kowask, Elimária Barbosa, Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato e Yve Marcial. Capa, projeto visual e diagramação Tecnodesign Versão 3.0.0 Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [email protected]. A Rede Nacional de Ensino e Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a pessoas ou bens, originados do uso deste material. As marcas registradas mencionadas neste material pertencem aos respectivos titulares. Distribuição

Escola Superior de Redes

Rua Lauro Müller, 116 – sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br [email protected]

Dados Internacionais de Catalogação na Publicação (CIP) L799a Léo, Wagner Vieira Administração de sistemas Linux: serviços para internet / Wagner Vieira Léo ... [et. al.] – 3. ed. – Rio de Janeiro: RNP/ESR, 2016. 216 p. : il. ; 27,5 cm.

ISBN 978-85-63630-55-1

1. Linux (Sistema operacional de computador). 2. Serviços de diretório (tecnologia de redes de computador). I. Léo, Wagner Vieira. II. Título.

CDD 005.7

Sumário Escola Superior de Redes A metodologia da ESR xi A quem se destina xii Convenções utilizadas neste livro xiii Permissões de uso xiii Comentários e perguntas xiv Sobre os autores xiv

1. DNS Introdução 1 Domain Name Service (DNS) 2 Por que utilizar DNS? 2 Definições 4 Domínio 4 Zonas de autoridade 5 Exercício de fixação 1 – DNS authoritative answer 6 Registro de recursos 6 Mapeamento direto e reverso 9 Resolver (resolvedor): cliente 10 Servidor DNS 11 Tipos de servidores DNS 11 Servidores raiz DNS 13 Estrutura do DNS no Linux 13 iii

Arquivo de configuração ‘named.conf’ 14 Arquivos de mapas da rede 17 Exemplo de arquivo de mapa de rede 18 Arquivo ‘resolv.conf’ 19 Exercício de fixação 2 – Servidor de DNS Cache 19 Delegação de domínios 20 Serviço em CHROOT 21 DNS com IPv6 21 DNSSEC 23 Implementação do DNSSEC 25 Exercício de fixação 3 – DNSSec 26 Domínios virtuais 26 Testando o servidor DNS 27 Boas práticas para administração do DNS 27

2. NFS Network File System (NFS) 29 Instalando e configurando um servidor NFS 30 Exercício de fixação 1 – Instale o servidor NFS 30 Iniciando os serviços NFS 33 Pré-requisitos  33 Iniciando o portmapper  33 Verificando a execução do NFS 34 Configuração de cliente NFS 35 Montagem de sistemas de arquivos NFS em tempo de boot 36 NFS sobre TCP 36 NFS síncrono versus assíncrono 37 Segurança e NFS 38 NFS e segurança: portmapper 39

3. Servidor LDAP Introdução 41 Serviços de diretório 41 Sem serviço de diretórios 42 Com serviço de diretório 42 LDAP 43 Funcionamento do LDAP 44 iv

Estrutura da base LDAP 45 LDIF 49 Formas de conexão no LDAP 50

4. LDAP Avançado Schemas 53 Classes de objetos 54 Atributos 55 Gerenciando schemas 56 Módulos 56 Manipulação da base 57 Gerenciamento de Logs 59 Cliente LDAP 60 Pacotes para instalação cliente 60 Segurança do Servidor LDAP 62 Criptografia das mensagens Cliente Servidor LDAP 64 Replicação da base LDAP 66 Replicação Master X Slave 66 Replicação Master x Master 67 Diretórios distribuídos 67 Ferramentas gráficas 67 Backup e Restore 68 Backup 69 Restore 69 Atividade de Fixação – Elaborando uma solução de backup da base do LDAP 69

5. Servidor web Introdução 71 Conceitos fundamentais 71 Servidor web 74 Cliente web 74 Protocolo HTTP 74 Requisição (request) 75 Respostas (response) 76 Domínio virtual 79 Servidores web 80 v

6. Servidor proxy Squid Proxy 83 Proxy Squid 85 Instalação 86 Configuração 86 Listas de controle de acesso 87 Configuração dos navegadores 92 Proxy transparente 92 Redirecionadores 94 Relatórios 94 Sarg 95

7. Servidor de correio eletrônico (parte 1) Introdução 97 Correio eletrônico 97 Origens do correio eletrônico 98 Protocolo SMTP 99 Protocolo POP3 101 Comandos POP3 101 Comandos de autenticação (Authorization State) 102 Comandos de transação (Transaction State) 102 Comandos de atualização (Update State) 102 Respostas 102 Protocolo IMAP 103 Conexão e estados do IMAP 104 Configurações prévias 106 Postfix 108 Instalação do servidor Postfix 110 Inicialização do servidor Postfix 111 Configuração do servidor Postfix 111 Teste da entrega dos e-mails 115 Fila de e-mail e IDs da fila 117

vi

8. Servidor de correio eletrônico (parte 2) Introdução  119 Métodos de entrega 119 mbox  120 maildir  120 Servidor para múltiplos domínios 121 Domínios virtuais 121 Estabelecer o alias do nome de domínio virtual 122 Criar um mapa com os destinatários 122 Configurar o Postfix para receber mensagens dos domínios virtuais 122 Recarregar configurações do Postfix  122 Testando o envio de mensagem para endereço virtual 122 Verificando arquivo de log  122 Controle de conteúdo 123 Mail gateway 124 SMTP autenticado 126 Servidores secundários 126 Endereços especiais 127 Servidor de e-mail corporativo 127 Cyrus SASL e Dovecot SASL  128 Courier Maildrop  131 Courier Imap  131 Recomendações de tuning 132 Ajustes em consultas DNS 133 Gargalos na incoming queue  135 Gargalos na maildrop queue  135 Gargalos na deferred queue  135 Gargalos na active queue  136 Práticas Antispam 136 Recomendações do Antispam.br 139

vii

9. Samba Introdução 141 Samba 141 Daemons 143 nmbd 143 smbd 144 winbindd 144 Conjunto de ferramentas 144 Conceitos 145 Samba ADS 146 Instalação e configuração 147 Instalação 147 Principais parâmetros de configuração 149 Parâmetros de configuração para administração de contas 152 Backends de contas 154 smbpasswd 154 tdbsam 154 ldapsam 155 Modelos de segurança 155 Segurança no nível do usuário 155 Modo de Segurança Domain (Segurança ao Nível de Usuário) 156 Modo de Segurança ADS (Segurança ao Nível de Usuário) 156 Contas de usuários, grupos e máquinas 157 Samba como PDC 159 Parâmetros de controle do domínio 161 Parâmetros de ambiente 162 Compartilhamento NETLOGON 162 Compartilhamento PROFILE 163 Serviço de Logon na Rede de Domínio 163 Configurações adicionais 163 Integração com o OpenLDAP 164 Configuração do OpenLDAP  165 Inicialização da base de dados LDAP – Configurando o smbldap-tools 166 Configurando o Samba PDC para acessar a base de dados LDAP 169 Configuração de compartilhamento 171 Atividades administrativas 172

viii

Gerenciamento de Conta de Usuários 174 Criar conta 174 Remover conta 174 Listar conta 175 Outros comandos  175 Gerenciamento de Grupos 177 Gerenciamento de conta de máquinas 178 Alterar as políticas das contas do domínio 179

10. DHCP, FTP e SSH Introdução 181 DHCP 181 Campos em uma mensagem DHCP 183 Funcionamento do protocolo DHCP 185 Edição de arquivos de configuração 186 Exemplos de configuração 188 Iniciando e parando o servidor 189 File Transfer Protocol (FTP) 190 Funcionamento do FTP 191 Tipos de servidor FTP  192 Servidor FTP ativo 192 Servidor FTP passivo 192 Problemas com firewall 193 Secure Shell (SSH) 194 OpenSSH  195 Configuração do servidor OpenSSH 195 Comando ‘ssh’ 196 Estabelecendo conexão 197 SCP 197 SFTP 198 Geração de chaves 199 Agente SSH 200

ix

x

Escola Superior de Redes A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI. A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos educacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do problema, em abordagem orientada ao desenvolvimento de competências. Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

xi

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso O curso tem como objetivo ensinar a projetar, instalar, configurar e disponibilizar os principais serviços para Internet em uma rede TCP/IP; Conhecimento dos conceitos teóricos associados a cada um dos serviços, com a apresentação de cenários que facilitem a sua compreensão; Autenticação nos serviços, sempre que possível, com o uso de LDAP; Os serviços são instalados e testados com o uso intensivo de atividades práticas; Conhecimento de boas práticas para a utilização bem ajustada dos serviços de produção.

A quem se destina Esse curso destina-se a formação de profissionais responsáveis pela instalação, operação e manutenção de plataforma computacional para conexão com a Internet, gerentes de TI e programadores, desde que tenham os pré-requisitos necessários.

xii

Convenções utilizadas neste livro As seguintes convenções tipográficas são usadas neste livro: Itálico Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo Indica referência complementar disponível em site ou página na internet.

Símbolo Indica um documento como referência complementar.

Símbolo Indica um vídeo como referência complementar.

Símbolo Indica um arquivo de aúdio como referência complementar.

Símbolo Indica um aviso ou precaução a ser considerada.

Símbolo Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

Permissões de uso Todos os direitos reservados à RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: TORRES, Pedroet al. Administração de Sistemas Linux: Redes e Segurança. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.

xiii

Comentários e perguntas Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo Rio de Janeiro – RJ – 22290-906 E-mail: [email protected]

Sobre os autores Wagner Vieira Léo tem 25 anos de experiência na área de TI, atuando como Analista de Suporte e em Computação de Alto Desempenho, com foco em sistemas operacionais UNIX/LINUX, Possui graduação em Matemática pela Faculdade de Humanidades Pedro II, com Pós Graduação em Gestão da Inovação pelo LNCC/UCP. Atualmente ocupa o cargo de Coordenador de Tecnologia da Informação do Laboratório Nacional de Computação Científica e de Coordenador Administrativo do Ponto de Presença da RNP no Rio de Janeiro. Professor do Instituto Superior de Tecnologia da Informação de Petrópolis, IST e da Escola Superior de Redes da RNP nas áreas de Segurança da Informação e Sistemas Operacionais. Bruno Alves Fagundes é Tecnólogo em Tecnologia da Informação e da Computação pelo Instituto Superior de Tecnologia (2007) e especialista em Segurança de Redes pela Universidade Estácio de Sá (2011). Tem experiência em administração de servidores Linux, gerenciamento de usuário, implementação e gerencia de serviços de rede, computação de alto desempenho, segurança de redes, shell script, PHP, Perl, soluções de storage e backup. Atualmente é tecnologista no Laboratório Nacional de Computação Científica e professor na Escola Superior de Redes na área de Sistemas Operacionais. André Ramos Carneiro possui graduação em Tecnólogo em Tecnologia da Informação e Comunicação pelo Instituto Superior de Tecnologia em Ciência da Computação (2006). Trabalha com suporte à Linux desde 2005 e atualmente é Tecnologista do Laboratório Nacional de Computação Científica, onde trabalha com administração de servidores, gerência de contas de usuários, implementação de novos serviços, suporte a plataformas de processamento de alto desempenho, compilação de aplicações científicas, administração de storage e backup. Tem experiência na área de Ciência da Computação, com ênfase em Computação de Alto Desempenho, atuando principalmente nos seguintes temas: previsão numérica de tempo, processamento paralelo, aplicações científicas e I/O paralelo.

xiv

1 Conhecer o sistema Domain Name Service (DNS).

Domain Name Service – sistema de tradução de endereços.

conceitos

Introdução O estudo deste capítulo apresenta o conceito do serviço de resolução de nomes (DNS), abordando sua utilização e execução de maneira prática e intuitiva, passando pela instalação, configuração e testes. São apresentados os conceitos e definições comuns ao serviço DNS, tais como: 11 Espaço de Nomes (DNS); 11 Domínio; 11 Zonas de autoridade; 11 Registro de recursos; 11 Mapeamento direto e reverso. 11 Delegação de domínios 11 Serviço em chroot. Em seguida, serão vistos os tipos e montagens típicas de um serviço DNS, que envolvem: 11 Servidor primário; 11 Servidor(es) Secundário(s); 11 Servidor Cache; 11 Servidores raiz da internet. Na etapa seguinte, são abordados os aspectos do DNS associados à sua utilização no Linux, desde instalação e configuração, até formas de teste e diagnóstico.

Capítulo 1 - DNS

objetivos

DNS

1

Por último vêm as atividades práticas: 11 Instalação do servidor DNS; 11 Configuração do servidor DNS Primário; 11 Configuração do servidor DNS Secundário.

Domain Name Service (DNS) O que é o DNS?

q

11 Serviço para tradução de nomes em endereços IP e vice-versa. 11 Também denominado Domain Name System ou Domain Name Server. O Serviço de Tradução de Nomes, ou simplesmente serviço de nomes, é um componente dos serviços em redes que permite a aplicativos e serviços localizar e fazer referência a informações em um ambiente de rede. Os nomes são parte crítica dos serviços em redes, pois ajudam na administração de todos os recursos disponíveis na rede. Domain Name Service (DNS) fornece serviços de nomes e diretórios em redes que implementam a pilha de protocolos Transmission Control Protocol/Internet Protocol (TCP/IP). Podemos considerá-lo como um sistema de banco de dados distribuído, que traduz nomes de estações em endereços, fornecendo informações sobre roteamento e domínios. O DNS é essencial para os sites que se conectam diretamente à internet. Porém, mesmo para redes locais isoladas que utilizam protocolos da pilha TCP/IP, sempre faz sentido utilizá-lo. É particularmente importante para o sistema de correio eletrônico, pois é nele que são definidos registros que identificam a máquina que manipula as correspondências relativas a um dado nome, identificando, assim, onde determinado usuário recebe suas correspondências.

Por que utilizar DNS? Primeiro motivo:

q

11 Máquinas possuem maior facilidade em lidar com números. 11 Pessoas preferem usar nomes. 11 Exemplo:

Administração de Sistemas Linux: Serviços para Internet

22 Página da RNP.

2

22 Mais fácil usar www.rnp.br que http://200.130.35.237 Segundo motivo: 11 Torna o acesso aos serviços de rede independente do endereço IP do servidor. 11 Troca do IP do servidor é transparente para o usuário, pois a localização do IP é fornecida pelo serviço DNS. O esquema de endereçamento utilizado pela internet baseado em endereços IPv4, com 32 bits, ou IPV6, com 128 bits, não é recomendado para uso em navegadores e outros serviços. Desse modo, um usuário da internet, ao usar seu navegador, pode digitar um endereço que lhe é familiar, como www.rnp.br, em vez de algo como 200.130.35.237 ou 2001:12f0:b01:101::ed, possibilitando, dessa forma, que empresas e pessoas possam criar endereços baseados em nomes, associando-os ao nome da empresa ou produto. Cabe ao serviço DNS fazer a associação entre o nome escolhido pelo usuário e o endereço IP.

l Um motivo adicional para o uso de um sistema de endereçamento baseado em nomes é torná-lo independente do endereço IP em uso em determinado momento.

Frequentemente o administrador de rede tem de mudar a faixa de endereço utilizada pelos vários servidores que controla. Tal alteração pode ser necessária pela mudança do bloco de endereços disponibilizado, podendo ocorrer em função de uma mudança de provedor de acesso à internet, o que provoca a alteração de endereços para o novo bloco de endereços disponibilizado pelo novo provedor. Podem ainda ocorrer modificações em função da realocação de endereços do provedor ou mesmo da própria rede do usuário, por causa de rearranjos causados por ampliações ou modificações na topologia da rede. Desse modo, um usuário que acessa o serviço via internet, ou mesmo via intranet, não precisa se preocupar com alterações na topologia e/ou endereçamento do servidor, já que estará acessando o servidor pelo nome, cabendo ao DNS manter essa associação atualizada.

“”

arpa

com

gov

edu

mil

net

org

br

...

rnp

esr

Domínios genéricos

Domínios geográficos

O DNS é um dos componentes básicos da internet. Podemos considerá-lo como um sistema de banco de dados distribuídos de nível mundial, que traduz endereços simbólicos de estações em endereços IP numéricos e vice-versa. Quando se usa serviços não transparentes, como Telnet, FTP, SSH e SFTP, o usuário pode fornecer como argumento um endereço simbólico de estação (o nome de um computador hospedeiro). Funções resolvedoras (resolver functions) do DNS traduzem esse endereço simbólico para um endereço IP numérico. O rápido crescimento da internet levou à introdução dos conceitos de domínios e subdomínios DNS. Os domínios compõem a estrutura básica do DNS e podem ser comparados a diretórios em um sistema de arquivos, com cada domínio aparecendo como subárvores de informações no espaço de nomes de domínio. Um endereço simbólico de estação em um domínio deve ser único, porém esse mesmo endereço simbólico pode existir em outros domínios. Os domínios são implementados como uma hierarquia, que pode ser vista como uma árvore invertida, começando no domínio-raiz, cujo endereço simbólico real é “ ”, ou seja, um rótulo (label) nulo. O domínio raiz é implementado por um grupo de servidores de nomes chamados de servidores raiz. Os servidores raiz só têm informações completas a respeito dos domínios de topo, que se localizam imediatamente a seguir do domínio-raiz na árvore de hierarquia de domínios. Os domínios de topo, por sua vez, têm apontadores para os servidores em domínios de níveis inferiores. Nenhum servidor, nem mesmo os servidores raiz, tem informações completas sobre todos os domínios, mas os seus apontadores podem indicar que outros servidores podem fornecer a informação desejada. Assim, os servidores raiz podem até não saber a resposta para uma pergunta, mas certamente saberão para quem direcioná-la.

Capítulo 1 - DNS

Figura 1.1 Os domínios genéricos, como “net” ou “org”, e os geográficos, como “rnp”.

3

Definições 11 Domínio.

q

11 Zonas de autoridade. 11 Registro de recursos. 11 Mapeamento: 22 Direto. 22 Reverso. 11 Delegação de domínio. 11 Serviço com chroot. A segurança da informação é um ponto crítico para a sobrevivência das organizações na era da informação. Vários são os problemas envolvidos, no entanto, a sociedade depende das informações armazenadas nos sistemas computacionais para tomadas de decisão em negócios, uso de órgãos do governo, entre outros contextos. A informação pode existir em diversos formatos: impressa, armazenada eletronicamente, transmitida pelo correio convencional ou eletrônico etc. Seja qual for o formato, meio de armazenamento ou transmissão, recomenda-se que ela seja protegida adequadamente. Sendo assim, é de responsabilidade da segurança da informação protegê-la de vários tipos de ameaças, a fim de garantir a continuidade do negócio, minimizar riscos e maximizar o retorno sobre os investimentos. Felizmente, é crescente a conscientização das organizações frente ao valor e as vulnerabilidades de seus ativos, no que diz respeito à segurança. Hoje, a segurança da informação é determinante para assegurar competitividade, lucratividade, atendimento aos requisitos legais e a boa imagem da organização junto ao mercado e às organizações, tanto no setor público quanto no setor privado. Em tais contextos, a segurança da informação é um componente que viabiliza negócios como o e-Gov (governo eletrônico) ou e-commerce (comércio eletrônico).

Domínio 11 Subárvore do espaço de nomes DNS.

q

Administração de Sistemas Linux: Serviços para Internet

11 Nome de domínio completo, também denominado Fully Qualified Domain Name (FQDN), consiste em: 22 Nome da máquina. 22 Nome do domínio. 22 Domínio de topo. 22 Exemplo: 33 www.rnp.br . 33 www: máquina (ou host). 33 rnp: domínio. 33 br: domínio de topo (top level domain). Se precisássemos lembrar todos os endereços IP das páginas da web que visitamos diariamente, ficaríamos loucos. Seres humanos não são bons em lembrar séries de números. No entanto, somos bons na lembrança de palavras, e por isso usamos os nomes de domínios. Você possui, provavelmente, vários nomes de domínios guardados em sua cabeça. Exemplos: rnp.br, receita.fazenda.gov.br, g1.com.br, mit.edu, google.com etc. 4

As partes “com”, “edu” e “br” desses servidores são chamadas de domínios principais ou domínios de primeiro nível. Existem vários domínios principais, incluindo “com”, “edu”, “gov”, “mil”, “net” e “org”, além das siglas de duas letras de cada país, para identificar a origem, em inglês. Não custa lembrar que os domínios registrados nos EUA não possuem a identificação (“us”). Em cada domínio principal existe uma enorme lista de domínios secundários. Novos tipos de domínio foram criados para oferecer melhor identificação. Exemplos mais conhecidos são: professor – “prof.br”, pessoais – “nom.br”, rede de televisão – “tv.br” etc. Um domínio é uma subárvore do espaço de nomes DNS. Um domínio completo, também denominado de Fully Qualified Domain Name (FQDN), consiste basicamente em um nome de máquina, um nome de domínio e um domínio de topo. O endereço www.rnp.br é um exemplo de FQDN, onde: 11 www: nome da máquina (ou host); 11 rnp: nome do domínio; 11 br: domínio de topo. Cada subárvore é considerada parte de um domínio. Nesse caso, “rnp” faz parte do domínio “br”. Outra situação é referente a subdomínios dentro da própria rede. Considere o endereço www.df.rnp.br, no qual “df” é uma subárvore de “rnp” e faz parte desse domínio. A seguir, alguns exemplos. Domínio rnp: 11 www.rnp.br: máquina www no domínio rnp.br. 11 mail.rnp.br: máquina mail no domínio rnp.br. Domínio df.rnp.br: 11 www.df.rnp.br: máquina www no domínio df.rnp.br. 11 mail.df.rnp.br: máquina mail no domínio df.rnp.br.

Zonas de autoridade 11 Também denominadas Start of Authority (SOA).

q

11 Domínios e zonas de autoridade não são sempre sinônimos: 22 Um nome de domínio se refere a um único ponto no espaço de nomes. 22 Uma zona de autoridade refere-se ao local no qual estão armazenados os dados sobre as máquinas (hosts) do domínio. Cada nome de domínio possui um registro de zona de autoridade que apresenta informações do domínio e da zona em que o domínio está inserido. Entre essas informações, estão: 11 Nome do servidor de nomes primário; 11 Endereço eletrônico (e-mail) do responsável pelo domínio;

11 Intervalo de refresh: indica o tempo, em segundos, que o servidor de nomes secundário deve verificar por atualizações no servidor de nomes primário; 11 Intervalo de retry: indica o tempo, em segundos, que o servidor de nomes secundário aguarda por uma resposta do servidor de nomes primário, antes de indicar uma falha; 11 Tempo de expire: informa o tempo, em segundos, após o qual o servidor não mais res-

Capítulo 1 - DNS

11 Número de série (serial number) da zona;

ponde por informações daquela zona; 5

11 Tempo minimum: informa o Time To Live (TTL) default caso o domínio não especifique um TTL; 11 Tempo de vida, Time To Live (TTL): valor passado pelo servidor de nomes indicando, para a máquina que originou a pergunta, o tempo que a informação pode ser mantida em cache.

Exercício de fixação 1 e DNS authoritative answer Qual das alternativas a seguir representa uma resposta non-authoritative answer quando realizamos uma consulta a um servidor de DNS? (1) Indica que o tempo de vida (TTL) expirou. (2) Representa uma resposta originada do cache local. (3) Indica um erro no registro SOA. (4) Retorna a informação do próximo servidor DNS. (5) Indica que o cache do servidor de DNS está envenenado (DNS Poisoning).

Registro de recursos 11 Todos os domínios podem ter um conjunto de registro de recursos associado.

q

11 A verdadeira função do DNS é mapear nomes de domínio em registros de recurso. Um registro de recurso é composto por cinco campos. Embora eles sejam codificados em binário para maior eficiência, a maioria dos registros de recurso é apresentada como texto de ASCII, sendo uma linha por registro de recurso, como é mostrado a seguir: domínio, Tempo de vida (TTL), Classe, Tipo e Valor. O campo “Domínio” refere-se ao domínio para o qual esse registro é aplicado. Normalmente, existem muitos registros para cada domínio e cada cópia do banco de dados carrega informação sobre múltiplos domínios. Esse campo é a chave primária de procura usada para satisfazer as buscas. A ordem dos registros no banco de dados não é significante. Quando uma busca é feita sobre um determinado domínio, são devolvidos todos os registros pedidos, emparelhados em classe.

Administração de Sistemas Linux: Serviços para Internet

O campo “Tempo de vida” (Time To Live) dá uma indicação do nível de estabilidade do registro. Informações muito estáveis recebem valor alto, como 86400 (o número de segundos em um dia). Informações altamente voláteis têm um valor pequeno, como 60 (um minuto). O terceiro campo de todo registro de recurso é a “Classe”. Para informação de servidor internet, é sempre IN. Para informações não relacionadas com a internet, são usados outros códigos, que na prática são vistos raramente. O campo “Tipo” fornece a informação do tipo de registro. Os tipos mais importantes são: 11 Start of Authority Information (SOA): contém informações referentes ao servidor de nomes DNS do domínio, versão do banco de dados DNS, e-mail do administrador responsável pelo domínio etc; 11 A (Host Adress): mantém a tabela de endereços IP dos hosts mantendo compatibilidade com a tabela antiga de hosts. Permite mapear um nome de host para um ou cada endereço IP; 11 Name Server Identification (NS): especifica os servidores de nomes responsáveis pelo domínio, zona ou subzona; 6

11 General Purpose Pointer (PTR): permite obter um nome de host, a partir do conhecimento do seu endereço IP. É a contraparte do registro A; 11 Canonical Name Alias (CNAME): permite criar um apelido para um host. Esse registro é útil para ocultar detalhes de implementação da sua intranet, por exemplo: ftp.marketing. corporação.com pode ser apenas um apelido do verdadeiro servidor que executa ftp do marketing; 11 Host Information (HINFO): permite identificar propriedades de hardware e do Sistema Operacional do host que serão exibidas toda vez que o usuário acessar esse host. A padronização de identificação do tipo de CPU e do Sistema Operacional deve obedecer aos nomes listados na RFC 1700; 11 MAIL Exchange (MX): mantém informações referentes aos hosts responsáveis pelo e-mail do domínio. Finalmente, nós temos o campo “Valor”. Esse campo pode ser um número, um nome de domínio, ou um conjunto de caracteres ASCII. A semântica depende do tipo de registro. Considere que todos os domínios podem ter associado um conjunto de registro de recursos. Conforme mencionado anteriormente, uma zona de autoridade refere-se a um local onde estão armazenados os dados sobre as máquinas do domínio. Todos os registros de um determinado domínio estão em uma zona de autoridade responsável por este. Nesse caso podemos ter, considerando os domínios df.rnp.br e rnp.br, duas zonas de autoridade. A primeira responsável pelas informações referentes aos servidores daquele domínio, e a segunda, responsável pelas informações dos servidores do outro domínio. Nesse caso, podemos ter: 11 Servidor 1: SOA do domínio rnp.br e responsável pelas informações de DNS dessa rede; 11 Servidor 2: SOA do domínio df.rnp.br e responsável pelas informações de DNS dessa rede. Esses servidores podem estar inclusive em localidades diferentes, sem relação direta (primário e secundário) um com o outro. Os registros do banco de dados do DNS possuem o seguinte formato:

11 Nome: identifica o objeto. Exemplo: um computador; 11 TTL: tempo que o registro deve ser mantido em cache; 11 Classe: define o tipo de servidor. 22 Servidor Internet (IN): padrão. 11 Tipo: define o tipo de registro; 11 Dados: dados específicos para o tipo de registro de recurso. 22 Exemplo: tipo A contém um endereço; tipo MX contém prioridade e endereço. Os registros do banco de dados do DNS são formados por cinco campos:

11 Time To Live (TTL); 11 Classe; 11 Tipo; 11 Dados.

Capítulo 1 - DNS

11 Nome;

7



Exemplo: www 604800 IN A 200.130.77.75 Tipo

Descrição

Valor

SOA

Início de autoridade

Informações do domínio e da zona

A

Mapeamento de nome para endereço

Endereço IPv4 (32 bits)

PTR

Mapeamento de endereço para nome

Alias para endereço IP

MX

Servidor de correio eletrônico

Domínio e prioridade

NS

Servidor de nomes

Nome de um servidor de nomes

CNAME

Nome canônico (para alias)

Nome no domínio

HINFO

Informações sobre o computador

Recursos de hardware e software

TXT

Informações textuais

Informação de uso geral

Relembrando: registro de recurso é um conjunto de cinco campos, codificados normalmente em ASCII, com cada registro ocupando uma linha do arquivo. Cada registro é composto por: name, Time To Live, type, class e value. Onde name é o nome do recurso (que pode ser um computador, uma impressora etc.), TTL é o tempo de duração da validade da informação em segundos, type é o tipo de registro, class indica a que classe a informação pertence e value é o conteúdo, que depende do parâmetro type. O parâmetro type pode ser: 11 Start Of Authority (SOA): contém informações sobre o domínio e zona; 11 Address (A): endereço IPv4 com 32 bits; 11 Pointer (PTR): associa um endereço IP a um nome; 11 Mail eXchange (MX): identifica o servidor de correio eletrônico; 11 Name Server (NS): nome de um servidor de DNS no domínio; 11 Canonical NAME (CNAME): nome do recurso no domínio; 11 Hardware INFOrmation (HINFO): informações pertinentes ao hardware; 11 TeXT (TXT): informações gerais. Administração de Sistemas Linux: Serviços para Internet

Além desses parâmetros, existem outros menos utilizados: 11 AAAA: mapeia nomes para endereços IPv6 com 128 bits; 11 ISDN: mapeia nomes para números de telefone. Todo domínio, sendo um simples host ou um domínio de nível mais alto, pode ter um conjunto de registros de recurso associado a ele. Para um host qualquer, o registro de recurso mais comum é somente seu IP, embora existam muitos outros tipos de registros de recurso. Quando um resolver envia um nome de domínio ao DNS, o que volta é o registro de recurso associado com aquele nome. Assim, a verdadeira função de DNS é mapear nomes de domínio sobre registros de recurso. Os tipos de dados definem o tipo de registro, o que muitas vezes permite identificar o tipo de servidor. 11 SOA: identifica o servidor Start of Authority do domínio; 11 A e PTR: identificam servidores utilizados respectivamente em mapeamento direto e reverso; 8

Tabela 1.1 tabela de tipos de registros.

11 MX: identifica um servidor de correio eletrônico do domínio. Deve ser acompanhado de um

l

Esse tipo de consulta é usado frequentemente em diagnósticos e na localização de um spammer ou hacker.

número de prioridade caso exista mais de um servidor de correio eletrônico no domínio; 11 NS: indica o servidor de nomes do domínio; 11 CNAME: indica nome canônico, o que permite a um determinado servidor responder por mais de um nome; 11 HINFO: indica informação sobre o hardware e software; pouco utilizado na prática; 11 TXT: indica informações de uso geral.

Mapeamento direto e reverso O mapeamento direto é utilizado na tradução de nomes em endereços IP, que será utilizado como destinatário do pacote a ser transmitido pela rede.

2

DNS

Qual o endereço

Servidor

de mail.rnp.br?

DNS raiz

3 1

DNS

8

4

DNS

Servidor

5

Resposta:

Servidor

200.130.38.66

DNS local

DNS br

6 DNS

Figura 1.2 Mapeamento direto.

7

Servidor DNS rnp

A consulta segue um entre dois processos: 11 O computador do usuário encaminha uma consulta ao servidor DNS presente em sua rede local. Como este não tem a informação em seu banco de dados, procederá com várias consultas até a determinação do endereço IP associado ao nome informado. Em última instância, quem informará o endereço IP associado é o servidor DNS da rede de destino. Todavia, para localização do servidor DNS da rede de destino, é feita uma consulta a um servidor raiz da internet para a determinação do domínio de topo. Em seguida é feita uma consulta sobre a máquina responsável pelo DNS do domínio procurado. Por último é feita uma consulta ao servidor DNS da rede de destino, que por sua vez informará o endereço IP da máquina desejada; 11 O servidor DNS local já possui em cache o endereço procurado. Nesse caso, a resposta é enviada diretamente ao computador que fez a consulta, sem necessidade de encaminhar consultas a outros servidores. O mapeamento reverso é utilizado na tradução de endereços IP em nomes, na consulta raiz e em seguida o servidor DNS na rede de destino. O nome é então passado ao computador que efetuou a consulta.

Capítulo 1 - DNS

encaminhada ao servidor DNS da rede local. O servidor DNS local consulta um servidor DNS

9

Qual o nome da máquina com IP 200.130.77.75?

2

DNS

Servidor

1

DNS

3 4

6 Resposta:

Servidor

www.rnp.br

DNS local

DNS raiz Servidor Resp.

5

Classe C 200.130.77

Resolver (resolvedor): cliente 11 Efetua a montagem das consultas.

q

11 Biblioteca de rotinas link-editada a qualquer aplicação que deseja ter um endereço traduzido. 11 Usa o arquivo /etc/resolv.conf para localizar o servidor DNS. 22 Named: servidor de nomes. 11 Daemon (serviço) responde às consultas efetuadas. O software de serviços de nomes do DNS é dividido conceitualmente em dois componentes: 11 “Resolver” (lado cliente): módulo de software responsável pela montagem das consultas; 11 Named (servidor de nomes): processo responsável por responder às perguntas, fornecendo as respostas apropriadas. A implementação mais comumente encontrada do DNS, tanto para o resolver quanto para o servidor de nomes, é chamada Berkeley Internet Name Domain Server (BIND) para ambientes Unix. O resolver não existe como um processo distinto executado no computador. Ele é, na realidade, uma biblioteca de rotinas de software (chamadas código do resolver) que é ligada (link-editada) a qualquer aplicação que deseja traduzir endereços. Essa biblioteca sabe como solicitar do servidor de nomes informações a respeito de uma determinada estação. Administração de Sistemas Linux: Serviços para Internet

Do ponto de vista de uma aplicação, o acesso ao DNS se dá pelo uso de um módulo de

10

Figura 1.3 O mapeamento reverso em funcionamento.

software chamado resolver, que faz parte da própria aplicação, isto é, ele não faz parte do núcleo do Sistema Operacional (já os protocolos TCP/IP são ligados ao núcleo). Os protocolos TCP/IP no núcleo não conhecem nada a respeito do DNS. Uma aplicação (ou um serviço não transparente TCP/IP) precisa traduzir o endereço simbólico de seu computador hospedeiro para um endereço IP antes de poder iniciar uma conexão de transporte (TCP ou UDP), e é o resolver que faz essa tradução. O resolver se comunica como os servidores de nomes, geralmente, por meio de conexões UDP. Para efetuar a tradução, o resolver contata um ou mais servidores de nomes na rede, conforme indicado no arquivo /etc/resolv.conf.

Servidor DNS 11 Quando um resolvedor efetua uma consulta, esta é enviada a um servidor de

q

nomes local. 11 Se o domínio consultado estiver sob a jurisdição do servidor de nomes, esse retornará os dados oficiais. 11 Ou consultará o cache, que armazena as consultas efetuadas recentemente. 22 As informações no cache podem estar desatualizadas. Servidores DNS fazem a tradução de nomes de domínio em números IP. Isso pode parecer um trabalho simples, e seria, se não fosse por quatro fatores: 11 Existem bilhões de endereços IP atualmente em uso, e a maioria das máquinas possuem um nome; 11 A quantidade de solicitações feitas aos servidores DNS alcança a casa de muitos bilhões em apenas um dia; 11 Nomes de domínio e números IP sofrem alterações diárias; 11 Novos domínios são criados diariamente. O sistema DNS é um imenso banco de dados, e nenhum outro banco de dados recebe tantas solicitações. Nenhum banco de dados no planeta tem milhões de pessoas modificando seu conteúdo, diariamente. Esses fatores é que fazem o serviço DNS ser tão especial. O daemon em execução no servidor DNS “escuta” na porta 53 por consultas feitas a outros computadores. O servidor procura localmente em sua base de dados ou encaminha a consulta a outros servidores (raiz, domínio de topo e domínio). Caso o servidor responsável pelo DNS no domínio seja consultado, retornará os dados oficiais.

Tipos de servidores DNS Existem três tipos de servidores DNS.

q

11 Servidor primário (master): 22 Mantém as informações completas sobre os domínios que administra. 22 Atualizações devem ser feitas no servidor primário. 11 Servidor secundário (slave): 22 Mantém cópias dos dados disponibilizados no servidor primário. 22 Atua mesmo com o servidor primário indisponível. 22 Podem existir múltiplos servidores secundários. 11 Servidor cache (catching): 22 Não mantém informações sobre os domínios, apenas repassa as solicitações recebidas para outros servidores remotos.

22 Os dados possuem tempos de vida (TTL) para possibilitar o descarte de valores desatualizados. 22 Utilizados também para aumento de disponibilidade e desempenho, aliviando a carga sobre os servidores primário e secundários.

Capítulo 1 - DNS

22 Mantém respostas de consultas efetuadas anteriormente.

11

Com o BIND, cada estação usa o código do resolver, porém, nem todas as estações executam o processo servidor de nomes. Uma estação que não executa um processo servidor de nomes localmente e depende de outras estações para conseguir as respostas para seus serviços de nomes é chamada sistema resolvedor (resolver-only system). As configurações somente resolvedoras são comuns apenas em estações sem disco (diskless). A grande maioria das estações executa localmente um processo servidor de nomes. O servidor de nomes do BIND é executado como um processo distinto chamado named (daemon). Os servidores de nomes são classificados de diferentes maneiras, dependendo do modo como estejam configurados. As três principais categorias de servidores de nomes são: 11 Servidor Primário (master): servidor a partir do qual todos os dados a respeito de um domínio são originados. O servidor primário faz a carga das informações a respeito do domínio diretamente a partir de um arquivo de especificações, no formato texto, criado pelo administrador de sistemas. Os servidores primários são autorizados, isto é, têm informações completas e atualizadas a respeito de seus domínios. Só pode existir um único servidor primário para cada domínio. Em outras palavras, esse servidor executa o serviço DNS e é a fonte autorizada de informações sobre um domínio, obtendo informações sobre o domínio de arquivos locais que devem ser mantidos pelo seu administrador; 11 Servidor Secundário (slave): servidores para os quais uma base de dados completa, referente a um determinado domínio, é obtida a partir do servidor primário. Uma base de dados correspondente a um determinado domínio, replicada no servidor secundário, é chamada de arquivo de zona. Copiar uma base de dados de um servidor primário para um servidor secundário garante que ele sempre terá informações atuais sobre um domínio por meio de transferências periódicas de arquivos de zona para esse domínio. Os servidores secundários são autorizados somente para seus domínios. Em outras palavras, esse servidor executa o servidor DNS, mas obtém informações sobre o domínio que está servindo a partir do servidor primário. Atende a consultas DNS mesmo que o servidor primário esteja indisponível, atuando nesse caso como um servidor de backup. 11 Servidor cache (catching): servidores recebem as respostas para todas as consultas de serviços de nomes que venham de outros servidores de nomes. Quando um servidor cache recebe uma resposta para uma consulta, ele guarda essa informação para utilizá-la em outras consultas que venham a ocorrer. A maioria dos servidores de nomes armazena respostas em memória cache e as utiliza dessa maneira. O que torna os servidores de Administração de Sistemas Linux: Serviços para Internet

catching importantes é que essa técnica é a única utilizada na construção de sua base de

12

dados para o domínio correspondente. Servidores cache não são autorizados, isto é, suas informações podem estar incompletas ou desatualizadas, apesar de geralmente estarem coerentes. Atuam somente para armazenamento de consultas prévias. Sua principal função em uma determinada rede ou sub-rede é aumentar a confiabilidade e o desempenho de consultas DNS, aliviando a carga sobre os servidores primário e secundários da rede.

Servidor DNS DNS

primário

Transferência

Transferência

de zonas

de zonas

Servidor DNS

Servidor DNS DNS

secundário

DNS

secundário

Consultas

Consultas

Consultas

Figura 1.4 Tipos de servidores DNS.

Uma boa prática, em redes de grande porte, é o uso de um servidor primário apoiado por um ou dois servidores secundários para toda a rede, colocando servidores de cache em determinadas sub-redes para aumento de desempenho e confiabilidade, conforme mencionado.

Servidores raiz DNS 11 A zona de root é o nível mais alto na hierarquia do sistema DNS.

q

11 Essa zona acomoda a identificação dos 13 servidores raiz de DNS. 11 Mantida pela Internet Assigned Numbers Authority (IANA), vinculada à Internet Corporation for Assigned Names and Numbers (ICANN). 11 Todo servidor DNS deve possuir uma referência aos servidores raiz, utilizados como ponto inicial de consulta pelos servidores DNS da rede. O serviço DNS é essencial ao funcionamento dos principais protocolos utilizados na internet. Como se trata de um ponto crítico para toda a rede mundial de computadores, esses treze servidores estão espalhados pelo planeta. Cada um desses treze servidores é de responsabilidade de um operador, que os arranja em sua maioria em conjunto de múltiplos servidores, denominados clusters, localizados muitas vezes em diferentes cidades e países.

Estrutura do DNS no Linux 11 Servidor:

q

22 Executável. 22 Arquivo de configuração named.conf. 22 Arquivo de mapas da rede (zonas). 22 Arquivo para localização do servidor DNS (resolv.conf ). 11 Cliente: 22 Arquivo para localização do servidor DNS (resolv.conf ). Nos Sistemas Operacionais Linux, a estrutura existente funciona com servidores e clientes. Nos servidores ficam todos os arquivos que compõem o banco de dados DNS: configuração (named.conf ), mapas de rede e o resolv.conf, que aponta para os servidores DNS. Nos clientes, apenas o arquivo resolv.conf é necessário. Um servidor de DNS tem como objetivo fazer a conversão entre nomes de computadores e seus números IP. O programa (daemon) responsável pela tarefa é o /usr/bin/named, que é parte do pacote BIND. Para o funcionamento correto do DNS, alguns arquivos são necessários para a sua configuração.

Capítulo 1 - DNS

l

Estações de usuário

13

Os arquivos podem ter qualquer nome, mas devem estar definidos em named.conf (aqui estamos usando os padrões da internet). 11 /etc/bind/named.conf: principal arquivo de configuração do servidor DNS; 11 /etc/bind/db.root: arquivo que aponta para hosts externos, essencial quando o servidor estiver sendo utilizando na internet; 11 etc/bind/db.local: responsável pela resolução direta do domínio localhost; 11 /etc/bind/db.127: responsável pela resolução reversa do domínio 127.0.0.0; 11 /etc/bind/db.empresa.com.br: responsável pela resolução direta do domínio empresa.com.br; 11 /etc/bind/db.X.168.192: responsável pela resolução reversa do domínio empresa.com.br, supondo que a rede possui endereço de rede 192.168.X.0/255.255.255.0. A estrutura do serviço DNS no Linux, assim como em outros sistemas, consiste em uma arquitetura cliente/servidor. No servidor há alguns arquivos, como: 11 named: arquivo executável (daemon); 11 named.conf: arquivo de configuração lido pelo executável no momento de sua inicialização; 11 Arquivos de mapas da rede: arquivos com as informações sobre o(s) domínio(s) controlado(s) pelo servidor; 11 resolv.conf: arquivo utilizado pelo resolvedor, presente tanto no servidor quanto nas estações Linux.

Arquivo de configuração ‘named.conf’ O arquivo named.conf possui a seguinte estrutura:

q

11 Opções default. 11 Definição das zonas. 22 Cache. 22 Loopback reverso.

Administração de Sistemas Linux: Serviços para Internet

22 Domínio direto. 22 Domínio reverso. Esse é o arquivo que contém as informações referentes a cada uma das zonas administradas. Arquivo de configuração DNS: ‘named.conf’ acl interno { 172.16.72.0/24; 192.168.0.1/24; }; acl externo { 200.138.35.230; }; options { directory “/var/named”; forwarders { 200.221.11.100; 200.221.11.101; externo; }; allow-transfer { none; }; allow-query { interno; externo; };

14

allow-recursion { interno; }; }; zone “.” IN { type hint; file “caching-example/named.ca”; }; zone “localhost” IN { type master; file “caching-example/localhost.zone”; allow-update { none; }; }; zone “0.0.127.in-addr.arpa” IN { type master; file “caching-example/named.local”; allow-update { none; }; }; zone “site.local” IN { type master; file “site.local.zone”; allow-transfer { 192.168.0.1; externo; }; }; zone “rnp.br” IN { type slave; file slave.rnp.br; masters { 200.130.77.69; }; };

11 options: descreve as opções de inicialização do BIND; 11 directory: diretório onde ficam os arquivos de banco de dados do domínio; 11 forwarders: endereços IP dos servidores utilizados para solicitações DNS quando o servidor não souber resolver; 11 zone: zona que será configurada; 11 type: o tipo de aplicação da zona no seu servidor DNS; 11 master: servidor primário; 11 slave: servidor alternativo; 11 file: caminho do arquivo de banco de dados do domínio situado na pasta /var/named;

11 allow-transfer: servidores que possuem a permissão de serem “slaves”. Assim, evita plágio de DNS. 11 allow-query: define as máquinas que podem fazer consultas no servidor de DNS.

Capítulo 1 - DNS

11 allow-update: especifica quais dos servidores da zona serão atualizados. No caso, nenhum;

15

O arquivo /etc/bind/named.conf é o principal arquivo do BIND, e é o responsável pelas informações usadas para que o serviço seja realizado. O arquivo possui informações referentes ao diretório onde estão os arquivos de dados do DNS, os servidores secundários, as zonas atendidas, entre outras informações pertinentes. O arquivo de configuração named.conf possui uma série de cláusulas que são lidas pelo daemon. Essas cláusulas são estruturas que agrupam statements relacionadas, que são como diretivas que norteiam o controle do comportamento do servidor em relação a várias situações. Relação de cláusulas que podem ser utilizadas: 11 Access Control List (ACL): define uma ou mais listas de controle de acesso, grupo de hosts e usuários; 11 Controls: descreve e controla o acesso ao canal de controle utilizado pelo administrador com a chave rndc (Remote Name Daemon Control); 11 include: não é propriamente uma cláusula, mas referência a outros arquivos onde podem ser colocadas cláusulas que influenciam no funcionamento do servidor, e que estão em separado normalmente por questões de segurança ou facilidade de administração; 11 key: define chaves utilizadas em operações que exigem autenticação; 11 logging: define o nível de log e a localização dos arquivos de log; 11 lwres: propriedades do BIND quando usa um resolvedor leve; 11 options: statements para controle de opções genéricas ou globais, que podem ser sobrepostas por configurações nos arquivos de zona; 11 server: define o comportamento do servidor ao responder ou acessar um servidor remoto; 11 trusted-keys: define opções para acessos que exigem autenticação; 11 view: controla as funcionalidades do BIND em função do endereço do host; 11 zone: define as zonas mantidas pelo servidor. As informações disponibilizadas por meio dos statements no arquivo de configuração podem ainda ser consideradas em razão da função que controlam: 11 queries: controlam o comportamento das queries; 11 transfer: controlam o comportamento das transferências de zonas; Administração de Sistemas Linux: Serviços para Internet

11 operations: controlam o comportamento do servidor;

16

11 security: controlam o comportamento do servidor em relação à segurança; 11 statistics: controlam o comportamento da parte de log do servidor. Uma lista completa dos statements pode ser encontrada na documentação do BIND 9.

Arquivos de mapas da rede

q

11 Exemplo de arquivo de mapa de rede: 11 Zona de domínio direto: rede exemplo.com ; arquivo db.zone $TTL

604800

@ IN

SOA

mar.exemplo.com. root.mar.exemplo.com. ( 2

@

; Serial

604800

; Refresh

86400

; Retry

2419200

; Expire

604800 )

; Negative Cache TTL

IN

NS

localhost

mar.exemplo.com.

IN

A

127.0.0.1

mar

IN

A

200.130.77.130

sol

IN

A

200.130.77.131

Esse é o arquivo que contém os nomes dos números IP de cada máquina desse domínio. Arquivo de configuração DNS: mapas de rede ; ; Configurações do domínio site.local. ; $TTL @

86400

IN

SOA

ns01.site.local. root. ( 2007071500; Serial 28800

; Refresh

14400

; Retry

3600000 ; Expire 86400

; Minimum 604800)

; TTL

; ; Definição dos Servidores de Nome. ; IN

NS

ns01.site.local.

IN

NS

ns02.site.local.

; ; Definição dos Mail Exchanger. ; IN

MX

10 mail.site.local.

; ; Definição dos endereços de Hosts. localhost

IN

A

127.0.0.1

ns01

IN

A

192.168.0.254

ns02

IN

A

192.168.0.1

mail

IN

A

192.168.0.10

IN

A

mysql www



192.168.0.9 IN

A

Capítulo 1 - DNS

;

201.26.142.72

17

11 Serial: número serial da zona deve ser incrementado sempre que for feita alguma alteração, para que os servidores secundários possam se atualizar; 11 Refresh: número de segundos entre pedidos de atualização oriundos dos servidores secundários; 11 Retry: número de segundos que os servidores secundários vão esperar para refazer uma consulta que falhou; 11 Expire: número de segundos que um servidor, master ou slave, esperará para considerar a informação expirada, se ele não conseguir alcançar o servidor de nomes primário;  11 Minimum: é o TTL default caso o domínio não especifique um TTL; 11 Time to Live (TTL): número de segundos que um nome de domínio é cacheado localmente antes de expirar e retornar para os servidores de nomes de autoridade para atualização das informações. Conforme mencionado anteriormente, o funcionamento do servidor DNS é baseado em zonas controladas por mapas de rede. Os arquivos de mapas de rede são os arquivos que contêm as informações de cada uma das zonas atendidas pelo servidor DNS. São de dois tipos: tradução direta e tradução reversa. São os arquivos onde cada um dos computadores que pertencem a uma empresa são descritos, com nome, endereço IP e servidor de e-mail, entre outras informações, como Time To Live (TTL), serial para controle de alterações etc. Um servidor DNS necessita de pelo menos quatro arquivos com mapas de rede: 11 root.servers: mantêm uma relação dos servidores raiz da internet; normalmente ficam em um arquivo denominado named.ca; 11 localhost: permite a resolução do nome localhost para o endereço de loop local 127.0.0.1; 11 direct-map: apoiam o processo de conversão de um nome em um endereço IP; 11 reverse-map: apoiam o processo de conversão de um endereço IP em um nome.

Exemplo de arquivo de mapa de rede Zona de domínio reverso: rede 200.130.77: ; arquivo db.77.130.200 $TTL 604800 @

IN SOA

mar.exemplo.com. root.mar.exemplo.com. (

Administração de Sistemas Linux: Serviços para Internet

2

; Serial

604800 86400

; Refresh ; Retry

2419200

; Expire

604800 )

; Negative Cache TTL

; @

IN

NS

mar.exemplo.com.

130

IN

PTR

mar.exemplo.com.

131

IN

PTR

sol.exemplo.com.

Arquivos com os mapas de rede: 11 root.servers (arquivo db.root): servidores raiz da internet; 11 localhost (arquivo db.local): informações sobre o nome localhost; 11 direct-map (arquivo db.zone): informações sobre o domínio da rede; 11 reverse-map (arquivo db.77.130.200): informações sobre a rede 200.130.77.0.

18

q

Arquivo ‘resolv.conf’ O arquivo /etc/resolv.conf é usado pelas máquinas Linux para localizar o servidor DNS.

q

11 Diretivas: 22 nameserver. 33 Endereço IP do servidor DNS. 22 search. 33 Especifica os domínios a serem utilizados na busca pelo host a que se deseja conectar. 33 A adição de muitos domínios pode causar lentidão na resolução dos nomes. 22 domain. 33 Alternativa à diretiva search. Esse é o arquivo responsável por indicar quem são os servidores de nome para consultas de DNS. Ele contém uma lista de domínios ao qual pertence a máquina e os servidores de nome que serão consultados. Arquivo de configuração DNS – ‘resolv.conf’ search site.local nameserver 192.168.0.254 nameserver 192.168.0.1

11 search: especifica os domínios aos quais a máquina pertence; 11 nameserver: especifica o endereço IP dos servidores DNS; 11 domain: alternativa ao search.

Adicionalmente a essas zonas, outras podem ser incluídas. Devem ser incluídas zonas para cada rede ou domínio adicional sob responsabilidade do servidor, além de zona para lidar com servidor secundário. O arquivo /etc/resolv.conf é o arquivo que possui a informação do computador que está rodando o serviço DNS e o domínio a ser utilizado. O arquivo resolv.conf é utilizado pelo resolvedor (resolver) das máquinas Linux para localizar o servidor DNS. A principal informação desse arquivo é o endereço IP do servidor DNS, informado pela diretiva nameserver . Pode ainda ser utilizada a diretiva search ou domain, útil em consultas DNS quando é informado somente o nome do host em vez do endereço completo (FQDN).

Vários domínios podem ser adicionados, o que deve ser evitado, pois causará uma

Exercício de fixação 2 e Servidor de DNS Cache Instale e configure o servidor de DNS apenas com a função de cache.

Capítulo 1 - DNS

consulta DNS em cada um deles.

19

Delegação de domínios Como sabemos, o sistema DNS funciona através da delegação, onde um servidor aponta para outro, sucessivamente, até que a informação que se procura seja encontrada. Essas conexões não são criadas por acaso, e exigem uma sincronização por parte dos administradores dos diversos domínios. Suponhamos então que seja feito o registro do domínio exemplo.com.br. Durante o processo de registro de domínios, será necessário indicar no mínimo dois servidores DNS que estejam respondendo pelo domínio exemplo.com.br. Caso esses servidores estejam corretamente configurados, e as demais informações necessárias estejam também corretas, o processo é finalizado com a inserção de registros NS para o novo domínio nos servidores raiz do domínio BR. Supondo que os servidores DNS do domínio exemplo.com.br sejam ns1.exemplo.com.br e ns2.exemplo.com.br, os registros inseridos nos servidores do REGISTRO.BR terão a forma: exemplo.com.



IN

NS

ns1.exemplo.com.

IN

A



IN

NS

ns2.exemplo.com.

IN

A

exemplo.com.

ns1.exemplo.com. 192.168.0.1 ns2.exemplo.com. 192.168.0.2

Servidores DNS, entretanto, podem atender a dezenas ou centenas de domínios. Se quisermos registrar o domínio outroexemplo.com.br, sob a responsabilidade dos mesmos servidores DNS, o servidor raiz do domínio BR, deverá conter apenas os seguintes registros: outroexemplo.com.

IN

NS

ns1.exemplo.com.

outroexemplo.com.

IN

NS

ns2.exemplo.com.

Até agora vimos duas delegações. Os servidores do domínio raiz delegaram para o REGISTRO.BR autoridade sobre todos os domínios terminados em BR. O REGISTRO.BR, por sua vez, realizou a delegação de autoridade sobre o domínio exemplo.com.br para os servidores DNS ns1.exemplo.com.br e ns2.exemplo.com.br. Em outras palavras, os termos delegação de autoridade significam simplesmente que se alguém desejar obter informações corretas sobre computadores que terminam em exemplo.com.br devem encaminhar suas perguntas para um dos dois servidores registrados do domínio. O REGISTRO.BR não terá em

Administração de Sistemas Linux: Serviços para Internet

seus registros nenhuma informação além do nome dos servidores DNS e do domínio a que

20

servem. Tudo o mais foi delegado. O administrador do domínio exemplo.com.br tem total liberdade para registrar quantos computadores quiser dentro do domínio sobre o qual possui autoridade. Ele pode inclusive continuar delegando autoridade para outros subdomínios. O domínio exemplo.com.br tem representações em todas as capitais do Brasil e cada um desses subdomínios se inicia pelo nome da capital onde está sediado. O administrador do serviço DNS do domínio raiz poderá realizar a delegação de autoridade para os domínios regionais, incluindo registros do tipo: sergipe.exemplo.com.

IN

NS

ns.aracaju.exemplo.com.

Pernambuco.exemplo.com.

IN

NS

ns.recife.exemplo.com.

ceara.exemplo.com.

IN

NS

ns.fortaleza.exemplo.com.

maranhao.exemplo.com.

IN

NS

ns.saoluis.exemplo.com.

para.exemplo.com.

IN

NS

ns.para.exemplo.com.

amazonas.exemplo.com.

IN

NS

ns.amazonas.exemplo.com.

O administrador da base de Aracaju pode delegar autoridade para os representantes em diferentes regiões do estado de Sergipe. A restrição é que o administrador da base de Aracaju tem autoridade sobre o domínio aracaju.exemplo.com.br e pode criar apenas nomes de computadores que terminem com esse nome.

Serviço em CHROOT Em servidores UNIX, é possível executar o BIND em um ambiente chroot (usando a função chroot ()), especificando a opção “-t” para named. Isso pode ajudar a melhorar a segurança do sistema, colocando o BIND em uma “sandbox”, que vai limitar os danos causados se um servidor for comprometido. Outro recurso útil é a capacidade de executar o daemon como um usuário sem privilégios (-u usuário). Sugerimos a execução como um usuário sem privilégios ao usar o recurso chroot. Aqui está um exemplo de comando para carregar o BIND em uma “sandbox” chroot, no diretório /var/named, e com opção de setuid para o usuário 202: /usr/local/sbin/named

-u

202

-t

/var/named

Para que um ambiente chroot possa funcionar corretamente em um diretório específico (por exemplo, /var/named), você terá de criar um ambiente que inclui tudo o que o BIND precisa para ser executado. Do ponto de vista do BIND, o diretório /var/named é a raiz do sistema de arquivos. Ao contrário de versões anteriores do BIND, você normalmente não precisará compilar o BIND estaticamente nem instalar bibliotecas compartilhadas sob a nova raiz. No entanto, dependendo do seu Sistema Operacional, você necessitará criar alguns arquivos, tais como /dev/zero, /dev/random, /dev/log e /etc/localtime.

DNS com IPv6 Com o desenvolvimento do IPv6, surgiu a necessidade de se prover um serviço de

q

nomes que suporte esse novo protocolo. Foi criado um novo registro que armazena endereços no formato do IPv6. 11 AAAA.

Um novo domínio foi criado para a resolução de reverso, descrito na RFC 3152. 11 ip6.arpa. Dois tipos de consultas podem ser realizadas em um DNS: 11 Resolução de nomes. 11 Resolução de endereço reverso. Com o desenvolvimento do IPv6, surge a necessidade de se prover um serviço de nomes que suporte esse novo protocolo. Para isso, foi criado um novo registro que armazena endereços no formato do IPv6, o AAAA. Estão em fase de desenvolvimento novos tipos de registros que facilitarão a manutenção desse serviço. Além disso, um novo domínio foi criado para a

Capítulo 1 - DNS

resolução de reverso, o ip6.arpa, descrito na RFC 3152.

21

Como servidor de nomes, podemos utilizar o BIND versão 9, cuja implementação é a mais robusta. Dois tipos de consultas podem ser realizadas em um DNS: 11 Resolução de nomes: name to address lookups (forward lookups); 11 Resolução de endereço reverso: address to name lookups (reverse lookups).

Resolução de Nomes Para Resolução de Nomes (forward lookups), é usado o tipo AAAA. Os registros AAAA são paralelos e semelhantes aos Registros A no IPv4. Em um único endereço é possível especificar um endereço IPv6 completo. Por exemplo: www.ipv6.br.

IN A

200.160.4.22

www.ipv6.br. IN AAAA 2001:12ff:0:4::22

Resolução de endereço reverso Para resolução de reverso, foi adicionado o registro PTR ip6.arpa, responsável por traduzir endereços IPv6 em nomes. Em sua representação, omitir sequência de zeros não é permitido e o bit menos significativo é colocado mais à esquerda. O arquivo de configuração named.conf deve ser editado e incluída uma nova zona, a reversa, procedendo da seguinte forma com a configuração: Arquivo: ‘named.conf’ zone “0.0.0.0.1.2.f.f.1.0.0.2.ip6.arpa” { type master; file “2001:12ff:0000.ip6.arpa”; };

Passamos, assim, a responder pelo reverso do bloco que foi cedido. Tal prefixo já deve ter sido delegado pelo provedor de endereços IPv6, da mesma forma como ocorre na delegação de subdomínios. A forma como se declara o registro reverso é semelhante ao IPv4, ou seja, começando pelo último dígito hexadecimal do endereço, e é denominado de “nibble format”.

Administração de Sistemas Linux: Serviços para Internet

Arquivo: ‘2001:12ff:0000.ip6.arpa’

22

$TTL 86400 @

IN

SOA

ns.ipv6.br.

root.ipv6..br. (

2001112201

IN

NS

3H

; refresh

15M

; retry

1W

; expiry

1D)

; minimum

ns.ipv6.br.

2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0 IN PTR www.ipv6.br.

DNSSEC 11 Domain Name System SECurity Extensions (DNSSEC) tem por objetivo adicionar mais

q

segurança ao sistema de resolução de nomes. 11 Passou a ser um padrão internacional que estende a tecnologia DNS, garantindo a autenticidade e a integridade das informações. 11 Utiliza o mecanismo de criptografia de chaves públicas. 11 Criado para solucionar alguns problemas encontrados no atual sistema de resolução de nomes. 11 O objetivo da extensão DNSSEC é assegurar o conteúdo do DNS e impedir os ataques. Tem por objetivo adicionar mais segurança ao sistema de resolução de nomes, reduzindo o risco de manipulação das informações por terceiros. Passou a ser um padrão internacional, que estende a tecnologia DNS, garantindo a autenticidade e a integridade das informações. Utiliza o mecanismo de criptografia de chaves públicas. Foi criado para solucionar alguns problemas encontrados no atual sistema de resolução de nomes, como as falsas resoluções que criam oportunidades para alterações de dados em diversos tipos de transações, como por exemplo, compras eletrônicas. No protocolo DNS, um ataque onde a informação é corrompida é extremamente difícil de ser detectado e, na prática, impossível de ser prevenido. O objetivo da extensão DNSSEC é assegurar o conteúdo do DNS e impedir esses ataques, validando os dados e garantindo a origem das informações. 11 Provê segurança para a resolução de endereços; 11 Funciona como um caminho alternativo para a verificação de autenticidade da informação; 11 Sua verificação ocorre antes de outras aplicações de segurança, tais como, ssl, ssh, sftp, PGP etc; 11 Permite que se obtenha com precisão o endereço IP, por meio dos seguintes serviços: 22 Autenticação da origem; 22 Integridade dos dados; 22 Prova de inexistência. O sistema DNSSEC permite que se obtenha com precisão o endereço IP, através dos seguintes serviços: 11 Autenticação da origem: a informação somente pode ser originada do servidor DNS autoritativo do domínio; 11 Integridade dos dados: a informação recebida é exatamente a mesma fornecida pelo servidor DNS autoritativo do domínio; 11 Prova de inexistência: no caso de uma resposta negativa fornecida pelo servidor DNS autoritativo do domínio, podemos comprovar que essa informação está correta. Dependendo do tipo de ataque, isso pode ser suficiente para que o sistema DNSSEC o interrompa;

ções sejam assinadas digitalmente; 11 Novos Registros de Recursos passam a ser criados durante o processo de assinatura digital: 22 DNSKEY; 22 RRSIG; 22 Delegatin Signer (DS);

Capítulo 1 - DNS

11 Para que esses serviços possam ser ativados, o DNSSEC necessita que todas as solicita-

22 NSEC. 23

Para que esses serviços possam ser ativados, o DNSSEC necessita que todas as solicitações sejam assinadas digitalmente, usando uma ou mais chaves privadas e um algoritmo assimétrico de criptografia. Novos Registros de Recursos (RRs) passam a ser criados durante o processo de assinatura digital, usando o utilitário dnssec-signzone. 11 DNSKEY: armazena as chaves públicas utilizadas para a assinatura do domínio; 11 RRSIG: armazena as chaves privadas utilizadas para a assinatura dos Rrset; 11 Delegation Signer (DS): ponteiro para a próxima cadeia de confiança; 11 Next Secure (NSEC): permite autenticar uma resposta negativa.

DNSKEY É um Resource Record que armazena a chave pública da zona de autoridade. exemplo.com.

900

IN

DNSKEY 256 3 5 (

AwEAAeZPN2yMs9q6kgYjFUblEwjCnWWcPq+TGcJrD5ga XXAbP5MAqIkgZ5J4TU1mmpL1A8gMfd/wUmBkVipXR8FK HRajBZSRfgeKnKaQtrxNZ32Ccts2F6Ylv9WaLXtiqebg OZtuJFpQr6pnIt/FoOI+I7BUSNrX28VTq4jXu/qTrmM/ ) ; key id = 62745

RRSIG É um Resouce Record que contém a assinatura de um RRset (conjunto de RR com o mesmo nome de domínio, classe e tipo) específico de uma determinada chave DNSKEY. Possui uma validade inicial e final. exemplo.com.

900 IN RRSIG SOA 5 3 900 20070617200428 ( 20070518200428 62745 mar.exemplo.com glEeCYyd/CCBfzH64y0RAQf9OxYDsI4xuBNaam+8DZQZ xeoSLQEEtwmp6wBtQ7G10wSM9nEjRRhbZdNPNKJMp2PE lLLgLI+BLwdlz0t8MypcpLOaTm9rc7pP7UR5XLzU1k8D m6ePW1bNkId7i0IPSghyoHM7tPVdL2GW51hCujA= )

Delegation Signer (DS) É um hash do registro de recurso DNSKEY. Serve para informar a existência de uma cadeia Administração de Sistemas Linux: Serviços para Internet

de confiança entre um domínio e seus subdomínios. Indica que a zona delegada está assinada e qual a chave que foi utilizada. O Registro de Recurso DS é um ponteiro para a cadeia de confiança, que garante a autenticidade das delegações de uma zona até um ponto de confiança. exemplo.com. IN DS 817 5 1 EAEC29E4B0958D4D3DFD90CC70C6730AD5880DD3

É possível obter os DS da zona utilizando o sistema Whois. $whois rnp.br % Copyright (c) Nic.br % The use of the data below is only permitted as described in % full by the terms of use (http://registro.br/termo/en.html), % being prohibited its distribution, comercialization or % reproduction, in particular, to use it for advertising or % any similar purpose. % 2012-02-16 17:42:15 (BRST -02:00)

24

domain: owner:

rnp.br Associação Rede Nacional de Ensino e Pesquisa

ownerid:

003.508.097/0001-36

responsible: Nelson Simões Silva country:

BR

owner-c:

RCO217

admin-c:

NES

tech-c:

FRK16

billing-c: RCO217 nserver:

teyr.na-cp.rnp.br 200.130.25.17 2001:12f0:3f:3::11

nsstat:

20120216 AA

nslastaa:

20120216

nserver:

bellana.nc-rj.rnp.br 200.143.193.3 2001:12f0:3e:102::3

nsstat:

20120216 AA

nslastaa:

20120216

nserver:

lua.na-df.rnp.br 200.130.77.69 2001:12f0:3d:102::45

nsstat:

20120216 AA

nslastaa:

20120216

dsrecord:

51124 RSA/SHA-1 4ED9FC74C63C99E52E2FC492517C73AEFAC316F2

dsstatus:

20120216 DSOK

dslastok:

20120216

created:

before 19950101

changed:

20111125

status:

published

Next Secure (NSEC) Permite autenticar uma resposta negativa, com pré-assinatura, sem a necessidade de chaves on-line para assinatura, diminuindo a possibilidade de ataque DOS. exemplo.com 900 IN NSEC ns1.exemplo.com. NS SOA RRSIG NSEC DNSKEY

Implementação do DNSSEC 11 Utilizar o aplicativo dnssec-keygen para a geração das chaves do domínio.

q

11 Usar o aplicativo dnssec-signzone para assinar o arquivo de zona do domínio. 11 Atualizar o arquivo named.conf para referenciar o novo arquivo de zona. 11 Reiniciar o Bind. 11 Adicionar o DS no site do registro.br. 11 Aguardar a nova publicação no site do registro.br. 1. Utilizar o aplicativo dnssec-keygen para a geração das chaves do domínio.

O comando vai gerar dois arquivos, com as extensões .key e .private. 2. Usar o aplicativo dnssec-signzone para assinar o arquivo de zona do domínio. $ dnssec-signzone -S -z -o exemplo.com db.exemplo.com

Capítulo 1 - DNS

$ dnssec-keygen -r /dev/urandom -f KSK -a RSASHA1 -b 1024 -ZONE exemplo.com

25

O comando vai gerar um novo arquivo de zona com a extensão .signed. O período de validade das chaves é de 30 dias e as chaves deverão ser revalidadas antes de sua expiração. Para isso, altere o serial no registro SOA e repita o processo. 3. Atualizar o arquivo named.conf para referenciar o novo arquivo de zona. zone “exemplo.com”{ type master; file “db.exemplo.com.br.signed; };

4. Reiniciar o Bind. 5. Adicionar o DS no site do registro.br. $ cat dsset-exemplo.com | head -1 exemplo.com. IN DS 817 5 1 EAEC29E4B0958D4D3DFD90CC70C6730AD5880DD3

Copiar os dados de Key Tag e Digest do arquivo dsset-exemplo.com para a interface no site do registro.br 6. Aguardar a nova publicação no site do registro.br.

Exercício de fixação 3 e DNSSec São vantagens de se implementar o DNSSEC: ( ) Fornece autenticação da origem da informação. ( ) Evita ataque do tipo DDOS. ( ) Evita ataques do tipo Man-in-the-Middle e Spoofing. ( ) Garante a integridade dos dados DNS. ( ) Reduz o consumo de energia, sendo boa prática na TI verde. ( ) Evitar a manipulação da memória cache (Pharming, Phishing etc.).

Administração de Sistemas Linux: Serviços para Internet

( ) Garante a integridade dos dados do usuário. ( ) É independente dos algoritmos criptográficos.

Domínios virtuais 11 Um domínio virtual é uma entrada DNS em um servidor que responde por múltiplos endereços IP. 11 Necessário caso se deseje que um mesmo servidor DNS responda por vários endereços IP. Exemplo: Permitir que uma única máquina atenda por: 11 www.virtual2.exemplo.com: 192.168.1.10 11 www.virtual2.exemplo.com: 192.168.1.20 Utiliza recurso de IP aliasing presente no kernel do Linux. Algumas vezes é necessário recompilar o kernel e depois configurar normalmente arquivos de mapas da rede.

26

q

Domínios virtuais são entradas no DNS para permitir que um servidor possa responder por mais de um número IP; são necessários para que um único servidor DNS responda a solicitações por mais de um número IP.

Testando o servidor DNS Para testar o servidor DNS, podem ser utilizados os seguintes comandos:

q

11 nslookup (em desuso). 11 dig (atual). Comando dig: 11 Ferramenta flexível para consultas DNS, que apresenta informações detalhadas sobre o endereço consultado. 11 Exemplo: 22 dig – x 200.130.77.75 22 dig www.rnp.br Exemplo de utilização do comando dig: dig www.rnp.br ; <<>> DiG 9.2.4 <<>> www.rnp.br ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53116 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: A ;www.rnp.br. IN ;; ANSWER SECTION: www.rnp.br.

290

IN

A

200.143.193.5

www.rnp.br.

290

IN

A

200.130.77.75

;; Query time: 19 msec ;; SERVER: 172.19.0.2#53(172.19.0.2) ;; WHEN: Fri Sep 29 16:49:21 2006 ;; MSG SIZE rcvd: 60

Boas práticas para administração do DNS 11 Limitação de transferência de zonas.

q

11 Separação de servidores. 11 Uso de privilégios mínimos. 11 Cuidado com informações sensíveis no DNS. 11 DNS reverso. 11 Contato no DNS.

Limitação de transferência de zonas As limitações de transferências de zona devem ser aplicadas a todos os servidores com autoridade para um domínio, independente de eles serem mestres ou escravos. Um equívoco comum é limitar as transferências de zona no servidor mestre e não fazê-lo nos

Capítulo 1 - DNS

11 Política de backup.

servidores escravos. 27

Separação de servidores Uma prática recomendável é separar a função de servidor com autoridade (mestre ou escravo) da função de servidor recursivo. Isso minimiza a eficácia de ataques de envenenamento de cache DNS. Na prática, essa separação significa que os servidores que possuem autoridade para uma ou mais zonas respondem somente a consultas relativas a essas zonas; por sua vez, os servidores recursivos não possuem autoridade sobre nenhuma zona DNS.

Uso de privilégios mínimos Em ambientes Unix, muitas vezes é possível executar o servidor DNS em uma jaula chroot(). Versões mais recentes do BIND permitem também que ele seja executado com permissões de um usuário diferente de root. Consulte a documentação do seu software.

Cuidado com informações sensíveis no DNS Informações sobre configuração de sistemas na sua rede devem ser consideradas sensíveis, pois podem ser usadas por um atacante para facilitar o comprometimento desses sistemas (ajudando-o a identificar máquinas com sistemas que possuam vulnerabilidades conhecidas, por exemplo). Em vista disso, o mais prudente é evitar registrar esse tipo de informação no DNS.

DNS reverso Um DNS reverso mal configurado ou inexistente pode causar alguns transtornos. O primeiro deles é que muitos sites negam o acesso a usuários com endereços sem DNS reverso ou com o reverso incorreto. Em segundo lugar, erros na configuração do DNS depõem contra a competência técnica da equipe de administração de redes responsável pelo domínio, e isso pode vir a causar dificuldades quando for necessário interagir com equipes de outras redes.

Contato no DNS Cada domínio registrado em um servidor DNS possui uma série de parâmetros de configuração no registro de SOA (Start of Authority). Um desses parâmetros é o e-mail do responsável pelo domínio, que muitas vezes também é usado para comunicar problemas de segurança envolvendo esse domínio.

Política de backup

Administração de Sistemas Linux: Serviços para Internet

A importância dos backups na administração de sistemas nunca pode ser minimizada. Sem

28

eles, muitos dados são simplesmente irrecuperáveis caso sejam perdidos devido a uma falha acidental ou a uma invasão.

2 Conhecer o sistema Network File System (NFS).

conceitos

Network File System – sistema de arquivos em rede.

Network File System (NFS) Desenvolvido para permitir que máquinas montem partições de disco em

q

máquinas remotas. 11 Compartilhamento na rede. 11 Outros sistemas: 22 Samba. 22 AFS. 22 Entre outros. Este capítulo apresenta os conceitos e a utilização do Network File System (NFS). O NFS foi desenvolvido para permitir que máquinas possam montar uma partição de disco em uma máquina remota como se fosse em um disco local, permitindo o compartilhamento de arquivos na rede. Esse capítulo aborda a teoria desse serviço, configuração, otimização de desempenho e ajustes, sendo que no final serão praticadas a configuração do servidor e do cliente, e ainda testes de funcionamento. Há outros sistemas que proveem uma funcionalidade similar ao NFS; o Samba, por exemplo, provê serviços de arquivos aos clientes Windows; o Andrew File System (AFS), um projeto open source da IBM que provê um mecanismo de compartilhamento de arquivos com características de performance e segurança adicional. Algumas das características do AFS foram incluídas na versão 4 do NFS. Capítulo 2 - NFS

objetivos

NFS

29

Instalando e configurando um servidor NFS Pacotes de instalação:

q

11 nfs-kernel-server. 11 nfs-commom. 22 portmap. Arquivos de configuração: 11 /etc/exports. 11 /etc/hosts.allow. 11 /etc/hosts.deny. Para configurar um servidor NFS, é necessário fazer a configuração do serviço NFS, por meio de seus arquivos de configuração, e disparar a execução do serviço.

Exercício de fixação 1 e Instale o servidor NFS Instale o serviço NFS no servidor 192.168.X.1. Para isso, é necessário que estejam instalados três pacotes: nfs-kernel-server, nfs-common e portmap.

Arquivo ‘/etc/exports’ Lista entradas, com cada uma indicando um volume compartilhado.

q

11 directory machine1 (option11, option12). 11 machine2 (option21, option22). 11 Opções: 22 ro 22 rw 22 no_root_squash 22 no_subtree_check 22 sync

Administração de Sistemas Linux: Serviços para Internet

O arquivo /etc/exports contém uma lista de entradas, onde cada entrada indica um volume

30

compartilhado e como cada um está compartilhado. Uma entrada desse arquivo é similar a: directory machine1(option11,option12) machine2(option21,option22)

Onde: 11 directory: indica o diretório que se deseja compartilhar e pode ser um volume inteiro. Ao compartilhar um diretório, todos os diretórios a seguir dele no mesmo sistema de arquivos também serão compartilhados; 11 machine1 e machine2: máquinas clientes que terão acesso ao diretório especificado em directory. As máquinas podem ser listadas usando endereços IP ou nomes (por exemplo, machine.company.com ou 192.168.0.8). Usar endereços IP é mais confiável e mais seguro; 11 optionXX: lista de opções para cada máquina, que descreverá o tipo de acesso que a máquina terá. Algumas opções importantes serão examinadas a seguir.

Opções do arquivo /etc/exports: 11 ro: diretório compartilhado apenas para leitura; a máquina cliente não será capaz de escrever. Essa é a opção default; 11 rw: a máquina cliente terá acesso de leitura e escrita ao diretório; 11 no_root_squash: por default, qualquer pedido feito pelo superusuário na máquina cliente é tratado como se fosse feito pelo usuário nobody no servidor. Se no_root_squash for selecionado, então o superusuário na máquina cliente terá o mesmo nível de acesso aos arquivos no sistema como superusuário no servidor, o que pode ter sérias implicações de segurança, mas pode ser necessário se quisermos executar trabalhos administrativos na máquina cliente que envolvam diretórios exportados; 11 no_subtree_check: se apenas uma parte do volume é exportada, uma rotina chamada subtree checking verifica se um dado arquivo requisitado do cliente está na parte adequada do volume. Se o volume inteiro for exportado, desabilitar essa opção aumentará a velocidade de transferências; 11 sync: por default, os comandos exportfs usam o comportamento async, indicando para a máquina cliente que um processo de escrita em um dado arquivo está completo quando o NFS finalizar a escrita no sistema de arquivos. Esse comportamento pode causar corrupção nos dados, em caso de reinicialização do servidor, o que pode ser prevenido pela opção “sync”. Um exemplo:

q

11 /usr/local 192.168.0.1 (ro) 192.168.0.2 (ro) 11 /home 192.168.0.1 (rw) 192.168.0.2 (rw) Outro exemplo: 11 /usr/local 192.168.0.0/255.255.255.0 (ro) 11 /home 192.168.0.0/255.255.255.0 (rw) Para usar netgroups NIS, basta anexar o nome do netgroup com um caractere “@”. Suponha que temos duas máquinas clientes, slave1 e slave2, que têm endereços IP 192.168.0.1 e 192.168.0.2, respectivamente, e que queremos compartilhar binários e alguns diretórios com essas máquinas. Uma configuração típica para /etc/exports pode ser:

/usr/local

192.168.0.1 (ro) 192.168.0.2 (ro)



/home

192.168.0.1 (rw) 192.168.0.2 (rw)

Sendo assim, há um compartilhamento read-only para slave1 e slave2, porque eles devem provavelmente conter os binários. Por outro lado, alguns diretórios necessitam ser exportados read-write, se os usuários quiserem efetuar escritas sobre eles. Ao se tratar com uma rede de grande porte, primeiro podemos acessar uma grande faixa de máquinas especificando uma rede e uma máscara. Por exemplo, se quiser permitir o acesso para todas as máquinas com endereços IP entre 192.168.0.0 e 192.168.0.255, então podemos



/usr/local

192.168.0.0/255.255.255.0 (ro)



/home

192.168.0.0/255.255.255.0 (rw)

Para especificar um netgroup NIS no seu arquivo exports, simplesmente anexe o nome do netgroup com um caractere “@”.

Capítulo 2 - NFS

ter as seguintes entradas:

31

Outro formato que pode ser utilizado, em vez de hostnames, é algo do tipo *.foo.com ou 192.168. Algumas precauções devem ser tomadas em relação ao que pode e o que não pode ser exportado. Primeiro, se um diretório é exportado, seus diretórios pai e filho não podem ser exportados se eles estiverem no mesmo sistema de arquivos. Porém, a exportação de ambos os diretórios pode não ser necessária, uma vez que listar o diretório pai no arquivo /etc/exports fará com que todos os diretórios sejam exportados, dentro do sistema de arquivo.

Arquivos ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’ 11 Especificam os hosts que podem usar serviços em uma dada máquina.

q

11 hosts.allow é analisado antes do servidor responder a um pedido. 11 Se a máquina não se associa a uma entrada em hosts.allow, o servidor então verifica hosts.deny. Esses dois arquivos são utilizados para controlar o acesso aos serviços TCP do seu computador, especificando as máquinas que, na rede, podem ou não usar esses serviços. Cada linha dos arquivos é composta pelo nome do serviço e de uma lista de máquinas, que podem (allow) ou não podem (deny) usar o serviço. Ao receber uma solicitação de uma máquina qualquer, o servidor faz o seguinte: 11 Primeiro, verifica no arquivo hosts.allow se a máquina está incluída nele. Se estiver, seu acesso estará permitido; 11 Caso contrário, o servidor verifica no arquivo hosts.deny se a máquina está incluída nele; se estiver, o acesso é negado; 11 Se a máquina não estiver em nenhum dos dois arquivos, o acesso também é permitido. Além de controlar os serviços inetd, tais como telnet e FTP, esses arquivos também podem ser utilizados para restringir a conexão aos daemons envolvidos no serviço NFS. O primeiro daemon a ter seu acesso restringido é o portmapper, que tem como função informar a porta em que cada serviço responde. Restringir o acesso ao portmapper é a melhor defesa contra qualquer um que queira invadir o seu sistema a partir do NFS, porque usuários não autorizados não poderão encontrar os daemons NFS. Todavia, há dois pontos a considerar: 11 Restringir o acesso ao portmapper não é suficiente se algum intruso já souber, por

Administração de Sistemas Linux: Serviços para Internet

alguma razão, como encontrar todos os daemons;

32

11 Se o Network Information Service (NIS) está sendo executado, restringir portmapper também restringirá pedidos ao NIS. Em geral, é também aconselhável negar acesso a endereços IP aos quais não seja preciso permitir acesso explicitamente. O primeiro passo para fazer isso é adicionar a seguinte entrada ao arquivo /etc/hosts.deny: portmap:ALL

Adicione entradas para cada um dos daemons NFS: 11 lockd:ALL 11 mountd:ALL 11 rquotad:ALL 11 statd:ALL

Restringir acesso a portmapper é a melhor defesa contra ataques a NFS. 11 hosts.deny: 22 portmap:ALL, lockd:ALL, mountd:ALL, rquotad:ALL, statd:ALL 11 hosts.allow. 22 service: host [ou network/netmask], host [ou network/netmask] Alguns administradores de sistemas preferem colocar a entrada ALL:ALL no arquivo /etc/hosts.deny, fazendo com que o acesso seja negado a todos os hosts, a menos que seja explicitamente permitido. Depois, é necessário adicionar uma entrada ao hosts.allow para que o acesso aos hosts seja habilitado. As entradas em hosts.allow seguem o formato: service: host [ou network/netmask], host [ou network/netmask]

Onde host é o endereço IP de um cliente e pode ser possível, em algumas versões, usar o nome DNS do host, embora não seja aconselhável. Suponha que desejamos permitir acesso a slave1.foo.com e slave2.foo.com e que os endereços IP dessas máquinas sejam 192.168.0.1 e 192.168.0.2, respectivamente. Teríamos, portanto, as seguintes entradas para /etc/hosts.allow: portmap: 192.168.0.1, 192.168.0.2

Para versões recentes do nfs-utils, podemos adicionar: lockd: 192.168.0.1, 192.168.0.2 rquotad: 192.168.0.1, 192.168.0.2 mountd: 192.168.0.1, 192.168.0.2 statd: 192.168.0.1, 192.168.0.2

Iniciando os serviços NFS Pré-requisitos:

q

11 Versão do kernel que suporte NFS e versão adequada de nfs-utils. Iniciando o portmapper. 11 Localizado em /sbin e, algumas vezes, em /usr/sbin.

Pré-requisitos O servidor NFS deve ser configurado. Primeiro, é preciso ter os pacotes apropriados instalados. Isso consiste principalmente em uma versão de kernel que suporte NFS e uma versão adequada do pacote nfs-utils. Em seguida, antes de iniciar o NFS, verifique se a rede TCP/IP está funcionando corretamente na sua máquina. Feito isso, já é possível iniciar o NFS e executá-lo após reboot da máquina, pois os scripts de inicialização já detectam que o arquivo /etc/exports foi configurado e inicializará o NFS. Se não funcionar corretamente, alguns daemons precisarão ser inicializados para executar os serviços NFS.

NFS depende do daemon portmapper, também chamado portmap ou rpc.portmap. Ele deve estar localizado em /sbin e, algumas vezes, em /usr/sbin. Distribuições mais recentes do Linux inicializam esse daemon no processo de boot; de qualquer modo, é importante ter certeza de que ele está executando antes de trabalhar com o NFS. Digite:

Capítulo 2 - NFS

Iniciando o portmapper

ps aux | grep portmap

33

Daemons do pacote nfs-utils. 11 rpc.nfsd: daemon do NFS que faz a maior parte do trabalho. 11 rpc.lockd e rpc.statd: controlam os acessos de leitura e gravação de arquivos. 11 rpc.mountd: manipula os pedidos iniciais de montagem de file systems. 11 rpc.rquotad: gerência as quotas de disco dos usuários em volumes exportados. Lockd é chamado pelo nfsd sob demanda, portanto não se preocupe em iniciá-lo. Statd precisa ser iniciado separadamente. Distribuições Linux mais recentes têm scripts de inicialização para esses daemons. Os daemons citados são parte do pacote nfs-utils e podem estar nos diretórios /sbin ou /usr/sbin. Se a distribuição em uso não incluí-los nos scripts de inicialização, então devemos adicioná-los e executar configuração para que iniciem na seguinte ordem: 1. rpc.portmap 2. rpc.mountd 3. rpc.nfsd, rpc.statd 4. rpc.lockd (se necessário) 5. rpc.rquotad

Verificando a execução do NFS

q

11 Consulte o portmapper com o comando rpcinfo -p. 11 Se portamapper, nfs e mountd não estiverem listados, retorne e tente novamente inicializar os daemons. 11 A saída é algo como: program vers proto port 100000

2

tcp



111 portmapper

100000

2

udp



111 portmapper

...

Para fazer isso, consulte o portmapper com o comando rpcinfo -p para verificar os serviços Administração de Sistemas Linux: Serviços para Internet

que estão executando. A saída é algo como:

34

program ver proto

port program

ver

proto port

100000

2 tcp

111

portmapper

100003 3

udp 2049 nfs

100000

2 udp

111

portmapper

100024 1

udp 944 status

100011

1 udp

749

rquotad

100024 1

tcp 946 status

100011

2 udp

749

rquotad

300019 1

tcp 830 amd

100005

1 udp

759

mountd

300019 1

udp 831 amd

100005

1 tcp

761

mountd

100021 1

udp 1042 nlockmgr

100005

3 tcp

771

mountd

100021 3

udp 1042 nlockmgr

100005

2 tcp

766

mountd

100021 4

udp 1042 nlockmgr

100005

3 udp

769

mountd

100021 1

tcp 1629 nlockmgr

100005

3 tcp

771

mountd

100021 3

tcp 1629 nlockmgr

100003

2 udp

2049 nfs

100021 4

tcp 1629 nlockmgr

Essa saída indica que as versões 2 e 3 do NFS, a versão 1 do rpc.statd e as versões 1, 3 e 4 do rpc.lockd estão funcionando. Há também outros serviços listados, dependendo do NFS estar sobre TCP ou UDP. O Linux usa UDP por default, a menos que TCP seja explicitamente requisitado. Se não estiverem listados os serviços portmapper, nfs e mountd, então é necessário retornar e inicializar novamente os daemons.

Configuração de cliente NFS Montagem de diretórios remotos:

q

11 Cliente NFS deve executar o portmapper. 11 No cliente e no servidor são necessários os daemons: 22 rpc.statd. 22 rpc.lockd. Exemplo: # mount master.foo.com:/home

/mnt/home

Antes de começar, deve-se ter certeza de que o cliente tem suporte para montagem NFS. Se estiver sendo usado o kernel com o sistema de arquivos /proc, é possível verificar o arquivo /proc/filesystems e ter certeza de que há uma linha contendo NFS. Se não, digite “insmod nfs” para ter certeza de que o NFS foi compilado como um módulo; caso contrário, é necessário construir ou fazer download de um kernel com suporte para NFS. Para usar uma máquina como cliente NFS é necessário que o portmapper esteja rodando nela. Para usar o controle de acesso de arquivos NFS, será necessário também que rpc.statd e rpc.lockd estejam rodando no cliente e no servidor. Distribuições mais recentes iniciam esses serviços por default, em tempo de boot. Com portmap, lockd e statd executando, o administrador deve ser capaz de montar o diretório remoto de seu servidor da mesma forma que é montado um disco local, com o comando mount. Suponha que um dado servidor é chamado master.foo.com e que queremos montar o diretório /home em slave1.foo.com. Basta digitar: # mount master.foo.com:/home /mnt/home

O diretório /home em master aparecerá como diretório /mnt/home em slave 1 (do último exemplo). Montagem em tempo de boot: o tipo de sistema de arquivos têm de ser NFS, e dump e fsck devem ter valor zero. Modos de falha: 11 Soft: 22 Se um arquivo falha, o cliente NFS reportará erro;

22 Não se recomenda esse tipo de configuração. 11 Hard: 22 Quando o servidor NFS voltar ao estado on-line, o programa continuará do ponto em que parou; 22 Recomenda-se esse tipo de configuração.

Capítulo 2 - NFS

22 Pode causar corrupção de arquivos e perda de dados;

35

Montagem de sistemas de arquivos NFS em tempo de boot Sistemas de arquivos NFS podem ser adicionados no arquivo /etc/fstab da mesma maneira que os sistemas de arquivos locais. A única diferença é que o tipo de sistema de arquivos será configurado para NFS, e dump e fsck terão de ser ajustados para zero. Então, para o exemplo, a entrada no /etc/fstab seria: # device

mountpoint

fs-type

options

dump fsck

... master.foo.com:/home /mnt

nfs

rw

0

0

...

Se estiver sendo usado um automounter como amd ou autofs, as opções nos campos correspondentes das listagens do mount seriam similares, se não idênticas.

Opções de montagem Há várias opções a considerar em relação à forma pela qual o cliente NFS manipula uma falha (crash) no servidor ou queda da rede. Existem dois modos de falha distintos: 11 Soft: se um arquivo falha, o cliente NFS reportará um erro para o processo na máquina cliente requisitando o acesso ao arquivo. Não se recomenda esse tipo de configuração, porque pode causar corrupção de arquivos e perda de dados; 11 Hard: o processo não pode ser interrompido ou encerrado, a menos que isso seja especificado, após uma queda no servidor. Quando o servidor NFS voltar ao estado on-line, o programa continuará do ponto em que parou. Recomenda-se o uso dessa configuração. Considerando o exemplo anterior, a entrada fstab seria: # device

mountpoint fs-type

options

dump fsck

... master.foo.com:/home /mnt/home nfs

rw,hard,intr 0

0

...

Tamanho do bloco: “rsize” e “wsize” especificam o tamanho. 11 Não há um tamanho que funcione bem em todos ou na maioria dos setups.

Administração de Sistemas Linux: Serviços para Internet

11 Escolher um tamanho de bloco correto é um fator importante para o desempenho.

36

NFS sobre TCP Vantagens:

q

11 Funciona melhor que UDP em determinadas redes. 11 Melhor desempenho. 11 Manipula melhor as diferenças de velocidade de rede. Desvantagem: 11 Não é um protocolo stateless como o UDP. O overhead gerado pelo protocolo TCP resultará em menor performance do que UDP sobre condições ideais de rede. O uso de TCP tem uma vantagem e uma desvantagem em relação à utilização de TCP sobre UDP.

11 Vantagem: TCP funciona melhor do que UDP em determinadas redes. Quando se usa TCP, um pacote descartado pode ser retransmitido sem a retransmissão do pedido RPC inteiro, resultando em melhor desempenho. Em adição, TCP manipulará diferenças de velocidade de rede melhor do que UDP, devido ao fluxo de controle básico no nível de rede; 11 Desvantagem: TCP não é um protocolo stateless como o UDP. Se o servidor parar no meio de uma transmissão de pacotes, os compartilhamentos serão desmontados e remontados. O overhead gerado pelo protocolo TCP resultará em menor performance do que UDP sob condições ideais de rede, mas o custo não é crítico. Duas opções do comando mount timeo e retrans controlam o comportamento de pedidos UDP quando o cliente sofre timeouts devido aos pacotes descartados, congestionamento de rede e assim por diante. 11 Opção “-o timeo”: permite a designação do tempo, em décimos de segundo, que levará até que o cliente decida que não vai esperar uma resposta do servidor e tentará enviar o pedido novamente. O valor default é de 7 décimos de segundo; 11 Opção “-o retrans”: define o número de timeouts permitidos antes de o cliente desistir e exibir a mensagem de que o servidor não responde. O valor default é de três tentativas. Uma vez que o cliente mostra essa mensagem, ele continuará a tentar enviar o pedido, mas apenas uma vez antes de mostrar a mensagem de erro se outro timeout ocorrer. Quando o cliente restabelece contato, ele estará usando os valores corretos de retrans e mostrará uma mensagem “OK” no servidor. A critério do administrador da rede, esses valores podem ser ajustados, caso esteja havendo quantidade excessiva de retransmissões ou se deseje aumentar o tamanho do bloco de transferência sem contar timeouts e retransmissões. 11 Timeout e valores de retransmissão. 11 timeo e retrans controlam o comportamento de pedidos UDP quando o cliente sofre timeouts. 11 Número de instâncias de nfsd. 11 A maioria dos scripts de inicialização disparam oito instâncias desse daemon. 11 Pode ser modificado, via argumento, para /etc/rc.d/init.d/nfs (no Red Hat). A maioria dos scripts de inicialização iniciam oito instâncias de nfsd. Não há um número ótimo de instâncias; todavia, um servidor mais pesado pode requerer mais instâncias. Pode ser utilizado pelo menos um daemon por processador, mas de quatro a oito por processador pode ser melhor.

NFS síncrono versus assíncrono Comportamento assíncrono de NFSv3.

q

11 async.

sistema de arquivos local. 11 Não espera pelo armazenamento dos dados em meio estável. O comportamento de NFSv3 usado pelo exportfs é assíncrono. Esse valor default permite que o servidor responda aos pedidos clientes tão brevemente quanto são processados e manipulados os pedidos pelo sistema de arquivos local, sem esperar que os dados sejam

Capítulo 2 - NFS

11 Servidor responde a pedido dos clientes assim que processado e manipulado pelo

escritos em meios de armazenamento estável. 37

A opção “async” da lista de exportação do servidor pede ao servidor que informe ao cliente que todos os dados foram escritos para armazenamento estável, independentemente do protocolo usado. Para seguir um comportamento síncrono, o sistema de arquivos do servidor Linux deve ser exportado com a opção “sync”. Note que especificar uma exportação síncrona resultará na situação em que nenhuma opção será vista na lista de exportação do servidor. Para exportar sistemas de arquivos, podem ser usadas diferentes opções: # /usr/sbin/exportfs -o rw,sync *:/usr/local # /usr/sbin/exportfs -o rw *:/tmp

Parâmetros do sistema de arquivos exportado: # /usr/sbin/exportfs –v /usr/local *(rw) /tmp *(rw,async)

Exportação assíncrona: 11 /proc/fs/nfs/exports. 22 Mostra a lista de opções de exportação. 11 Clientes podem explicitamente insistir em comportamento síncrono total, independente de protocolo, usando a opção “O –SYNC” ao abrir arquivos. Se o kernel for compilado com o sistema de arquivos /proc, o arquivo /proc/fs/nfs/exports também mostrará a lista completa de opções de exportação. Quando o comportamento síncrono é especificado, o servidor não concluirá um pedido NFSv2 até que o sistema de arquivos local tenha escrito todos os dados no disco. O servidor concluirá um pedido assíncrono NFS sem esse delay e retornará o status dos dados para informar ao cliente os dados que devem ser mantidos em cache e os dados que podem ser descartados de maneira segura. Há três valores possíveis de status, definidos em include/Linux/nfs.h: 11 NFS_UNSTABLE: os dados não foram armazenados e confirmados em armazenamento estável no servidor, e devem ser colocados em cache no cliente até que um pedido de con-

Administração de Sistemas Linux: Serviços para Internet

firmação do cliente garanta que o servidor enviou os dados para armazenamento estável; 11 NFS_DATA_SYNC: os metadados não foram enviados para armazenamento estável, e devem ser colocados em cache no cliente. Uma confirmação subsequente é necessária; 11 NFS_FILE_SYNC: dados e meta dados não podem ser colocados em cache, e uma confirmação subsequente não precisa ser enviada para a faixa coberta por esse pedido. Em adição ao comportamento síncrono, o cliente pode explicitamente insistir em comportamento síncrono total, independente do protocolo, abrindo todos os arquivos com a opção O-SYNC. Nesse caso, todas as respostas aos pedidos dos clientes vão esperar até que os dados atinjam o disco do servidor.

Segurança e NFS Passos para que um cliente possa acessar um arquivo em um diretório remoto: 11 Montagem: segurança provida por /etc/exports. 11 Acesso aos arquivos: não é específico do NFS, mas parte do controle de acesso do sistema de arquivos no cliente.

38

q

Com NFS, há dois passos requeridos para que um cliente ganhe acesso a um arquivo contido em um diretório remoto no servidor. O primeiro passo é o de montagem. O acesso à montagem é conseguido através da máquina cliente tentando atingir o servidor. Para tal, a segurança é provida pelo arquivo /etc/exports, que lista os nomes ou endereços IP para máquinas que possam acessar o ponto de compartilhamento. Se alguém for capaz de efetuar spoofing, por exemplo, poderá acessar os pontos de montagem. Uma vez que a máquina foi montada em um dado volume, seu Sistema Operacional terá acesso a todos os arquivos naquele volume, e também acesso de escrita se o volume tiver sido exportado com a opção “rw”. O segundo passo é o acesso aos arquivos, uma função de controle de acesso do sistema de arquivos no cliente, e não uma função especializada do NFS. Uma vez que um drive é montado, as permissões do usuário e do grupo nos arquivos determinam controle de acesso.

NFS e segurança: portmapper O portmapper mantém uma lista dos serviços em execução em determinadas portas.

q

11 Algumas distribuições do Linux não se preocupam com a segurança do portmapper. Como tornar mais seguro? 11 Editar /etc/hosts.deny e incluir a linha: 22 portmap:ALL O portmapper mantém uma lista dos serviços em execução em determinadas portas. Essa lista é usada por uma máquina conectada para ver as portas que ela deseja acessar para obter determinados serviços. Algumas distribuições do Linux não se preocupam com a segurança do portmapper; com isso, a maneira mais fácil de fazer essa verificação é executando strings e verificando se foram lidos arquivos relevantes, como /etc/hosts.deny e /etc/hosts.allow. Supondo que o portmapper seja /sbin/portmap, podemos fazer a verificação com o comando: # strings /sbin/portmap | grep hosts

Em uma máquina segura, a saída seria algo como: /etc/hosts.allow /etc/hosts.deny @(#) hosts_ctl.c 1.4 94/12/28 17:42:27 @(#) hosts_access.c 1.21 97/02/12 02:13:22

Primeiro, editamos /etc/hosts.deny, que deve conter a linha portmap: aLL, que negará o acesso a todos. Após isso, execute rpcinfo -p apenas para verificar se o portmapper realmente está lendo o arquivo /etc/hosts.deny. Os arquivos /etc/hosts.allow e /etc/hosts.deny produzem efeito imediatamente após salvos. Não há necessidade de inicializar daemons. Fechar portmapper para todo mundo é uma medida drástica, então podemos abri-lo novamente Capítulo 2 - NFS

editando /etc/hosts.allow, listando todas as máquinas que devem acessar serviços na máquina.

39

40

Administração de Sistemas Linux: Serviços para Internet

3 Entender o funcionamento do serviço de diretório, do protocolo LDAP e da solução OpenLDAP; compreender o funcionamento, objetos e atributos; Instalação do OpenLDAP; Execução do servidor; Criação e manutenção da base de dados.

conceitos

Servidor LDAP, árvore de informação do diretório (DIT), detalhes da árvore de configuração e ferramentas para migração da base.

Introdução Serviços de Diretório

q

11 Protocolo LDAP: 22 Funcionamento 22 Estrutura da Base 22 Formato LDIF 22 Formas de conexão Neste capítulo, vamos conhecermos os conceitos de serviço de diretório e o protocolo Lightweight Directory Access Protocol (LDAP), além da solução OpenLDAP, em aspectos relacionados à instalação, configuração e testes. Na primeira parte, abordaremos o funcionamento, objetos e atributos do protocolo LDAP, em seguida veremos como está organizada a árvore de configuração no formato cn=config e por fim apresentaremos uma forma de importar as contas do sistema para a base do LDAP. A execução do servidor, bem como a criação da base, serão os objetos finais deste capítulo, onde serão colocados em prática os conceitos adquiridos.

Serviços de diretório O que é um serviço de diretório? Serviço de diretório X SGBDs tradicionais DIT (Directory Information Tree)

q

Capítulo 3 - Servidor LDAP

objetivos

Servidor LDAP

41

É uma base de dados especialmente desenvolvida para armazenar informações que necessitam de um grande volume de consultas, ou seja, operações de leitura e escrita não são prioridade nesse tipo de base. Diferentemente dos serviços de bancos de dados tradicionais que armazenam suas informações em tabelas, um serviço de diretório armazena suas informações de forma hierárquica. Essa organização é chamada de Directory Information Tree (DIT) ou Árvore de Informação do Diretório. Apresentaremos mais detalhes sobre uma DIT no decorrer deste capítulo. Geralmente utilizamos um serviço de diretório para armazenar informações sobre os recursos e os usuários de uma rede de computadores. Sua principal vantagem é centralizar todas as informações em um único lugar, facilitando assim o trabalho dos administradores de sistemas.

Sem serviço de diretórios

q

Diferentes aplicações utilizam bases de dados distintas Quando não possuímos um serviço de diretórios disponível na rede, cada aplicação deve

manter sua própria base de dados para autenticação dos clientes. Consequentemente, cada base terá sua própria política de segurança, possibilitando que o usuário tenha uma senha diferente em cada serviço. Esse cenário é terrível para os administradores de sistemas, pois a cada inclusão, alteração ou exclusão de um usuário, será necessária a repetição dos procedimentos em todas as bases de dados de todos os sistemas disponíveis. Isso reduzirá a produtividade da equipe, além de possibilitar brechas de segurança ao manter usuários com acesso a determinados serviços até que o processo tenha sido realizado em todas as bases de dados. Aplicação 1

Registro de usuário

Aplicação 2

Registro de usuário

Aplicação 3

Registro de usuário

Administração de Sistemas Linux: Serviços para Internet

Cliente da aplicação 1

Cliente da aplicação 2

Cliente da aplicação 3

Com serviço de diretório Diferentes aplicações utilizam a mesma base de dados

q

Um serviço de diretório é fundamental para estruturas de sistemas distribuídos. A centralização das contas dos usuários em um único local facilita muito a vidas dos administradores de sistemas e permite que os usuários acessem os serviços de maneira mais transparente. Qualquer operação em um objeto do serviço de diretórios será executada uma única vez em um único lugar, e todos os sistemas terão acesso os dados imediatamente. Esses dados podem ser acessados por qualquer aplicação ou sistema que suportem comunicação padrão LDAP.

42

Figura 3.1 Aplicações acessando bases de dados distintas

Aplicação 1 LDAP Cliente da aplicação 1 Aplicação 2

LDAP

Aplicação 3

LDAP

Registro de usuário

Cliente da aplicação 2

Cliente da aplicação 3

LDAP 11 Protocolo baseado no acesso a serviços de diretório X.500

q

11 Executa sobre protocolos de transporte orientados a conexão 11 Determina o conjunto de regras que controlam o funcionamento do serviço de diretório É um protocolo cliente/servidor utilizado para acessar serviços de diretório baseados em X.500. O LDAP foi desenvolvido na Universidade do Michigan como uma alternativa ao protocolo DAP. O protocolo DAP era baseado no padrão OSI de sete camadas, o que o tornava um protocolo “pesado”; já o protocolo LDAP foi desenvolvido sobre o sistema TCP/IP, que ao ser comparado com o DAP era considerado mais leve, daí o termo “LightWeight” na sigla do protocolo. A RFC 4510 contém a relação de todas as RFCs que descrevem o protocolo: 11 LDAP: The Protocol [RFC4511]; 11 LDAP: Directory Information Models [RFC4512]; 11 LDAP: Authentication Methods and Security Mechanisms [RFC4513]; 11 LDAP: String Representation of Distinguished Names [RFC4514]; 11 LDAP: String Representation of Search Filters [RFC4515]; 11 LDAP: Uniform Resource Locator [RFC4516]; 11 LDAP: Syntaxes and Matching Rules [RFC4517]; 11 LDAP: Internationalized String Preparation [RFC4518]; 11 LDAP: Schema for User Applications [RFC4519]. Assim como qualquer protocolo, o LDAP determina o conjunto de regras que controlam o funcionamento de um serviço de diretórios, ou seja, ele especifica como será realizada a conexão, comunicação e a transferência dos dados. As formas de armazenamento, o Sistema Operacional e o gerenciador de banco de dados não fazem parte do protocolo – essas são características específicas de cada implementação do LDAP. Empresas e instituições dos mais variados tipos e tamanhos possuem uma infinidade de serviços que necessitam da autenticação dos usuários. Tarefas como realizar o login em estações de trabalho, acessar contas de e-mail, acessar sistemas de gestão, sistemas de controle de estoque etc. são realizadas o tempo todo.

Capítulo 3 - Servidor LDAP

Figura 3.2 Aplicações acessando a mesma base de usuários.

43

Funcionamento do LDAP

q

11 Baseado no modelo cliente/servidor 11 Cliente realiza uma requisição ao servidor 11 Servidor responde ou encaminha a requisição para outro servidor LDAP 11 Todos os servidores apresentam a mesma visão do diretório O LDAP é uma aplicação cliente/servidor. Normalmente o servidor utiliza a porta 389 TCP para conexões sem criptografia, e a porta 636 para conexões com SSL. Um cliente LDAP conecta-se a um servidor LDAP e efetua requisições, o servidor responde ou então aponta para onde o cliente pode coletar mais informações, por exemplo, outro servidor LDAP.

Independente de qual servidor o cliente se conecte, todos devem apresentar a mesma visão do diretório.

A utilização do LDAP é recomendada para aplicações que necessitam realizar muitas consultas à base, pois ele foi projetado para atender a grandes volumes de consultas em um curto espaço de tempo, aplicações que necessitam realizar muitas operações de escrita provavelmente não terão um desempenho satisfatório.

q

Operações: 11 Consulta (search e compare) 11 Atualização (add, delete, modify e modifyDN) 11 Operação e controle (bind, unbind, abandon) O protocolo LDAP consiste em nove operações distribuídas em três categorias: consulta; atualização e autenticação e controle. Consulta: 11 search: operação de busca por um (Figura 3.3) ou múltiplos (Figura 3.4) resultados;

Administração de Sistemas Linux: Serviços para Internet

11 compare: operação de comparação com determinada entrada.

44

Search operation Returned entry Result code Cliente LDAP

Servidor LDAP

Figura 3.3 Operação simples de busca.

Search operation First entry returned Second entry returned Nth entry returned Cliente LDAP

Result code

Servidor LDAP

Figura 3.4 Operação de busca com múltiplos resultados.

Atualização: 11 add: operação de adição de um ou mais entradas na base; 11 delete: operação de remoção de dados da base; 11 modify: operação de modificação de dados da base; 11 modify DN: operação de modificação da posição ou renomear dados na base; Autenticação e controle: 11 bind: operação de autenticação; 11 unbind: encerra uma conexão LDAP; 11 abandon: operação de cancelamento unilateral de uma operação. Open connection and bind Bind result Search operation First entry returned Second entry returned Result of search operation Cliente LDAP

Unbind operation

Servidor LDAP

Close connection

Estrutura da base LDAP DIT (Directory Information Tree)

q

11 Objetos 22 Corresponde a um conjunto de atributos (pares chave/valor) que armazenam informações 22 Atributos normais 22 Atributos operacionais 11 LDAP ObjectClass 11 LDAP Schema Uma base LDAP ou diretório LDAP é onde as informações estão armazenadas. Essa base deve seguir o modelo X.500, conforme mencionamos anteriormente. Os objetos de uma base LDAP são organizados hierarquicamente, formando uma estrutura de árvore conhecida como DIT (Directory Information Tree). Cada vértice da DIT é um objeto e suas arestas definem a relação entre eles. Capítulo 3 - Servidor LDAP

Figura 3.5 Operação típica de acesso a base do LDAP.

45

dc= rnp,dc=br

ou=Salvador

ou=Rio de Janeiro

ou=diretoria

ou=operacoes

ou=gerentes

ou=Belém

ou=funcionários

cn=João da Silva

cn=Pedro Souza

Na figura 3.6 temos um exemplo de uma DIT. O vértice mais ao topo (com o nome rnp.br) é chamado de raiz e é a base da nossa árvore. Uma DIT deve ter uma única raiz e todos os outros objetos estarão relacionados a ela, sendo assim dizemos que a DIT é uma árvore enraizada. As arestas que ligam os vértices nos permitem perceber a relação de hierarquia entre os objetos. Por exemplo: vamos considerar que o nosso objetivo é obter as informações referentes ao vértice “Pedro Souza”. Analisando nossa árvore percebemos que ele está abaixo dos vértices “funcionários”, “operações”, “Rio de Janeiro” e “rnp.br”, portanto, para conseguirmos chegar até o nosso alvo precisaremos passar por toda a hierarquia da nossa árvore começando pela raiz seguindo os vértices até chegar ao objeto que contém os valores que desejamos recuperar. Outra forma de ilustrar essa organização é fazer uma comparação com o sistema de arquivos do Linux, onde todas as informações estão organizadas debaixo de uma única raiz. Organizando nossa DIT como uma árvore de diretórios ela ficara semelhante à imagem a seguir: rnp.br |__ Salvador

Administração de Sistemas Linux: Serviços para Internet

|__ Rio de Janeiro

46

|

|__ operacoes

|

|__ gerentes

|

|__ funcionarios

|

|__ João da Silva

|

|__ Pedro Souza

|__ Belem |

|__ diretoria

Uma DIT pode refletir a organização política, geográfica e/ou organizacional da empresa ou instituição, sendo uma prática muito comum basear-se em nomes já existentes, como os domínios de DNS, para definição dos níveis mais básicos da hierarquia.

Figura 3.6 Exemplo de uma árvore de diretório.

Cada vértice da nossa árvore pode representar uma pessoa, unidade organizacional, impressora, documento, grupo de pessoas ou qualquer outra coisa. Essa representação geralmente é chamada de registro ou objeto e corresponde a um conjunto de atributos (pares chave/valor) que armazenam informações que permitem caracterizar essa representação. Existem dois tipos de atributos: 11 Atributos normais: atributos que caracterizam o objeto, como por exemplo: displayName, mail etc.; 11 Atributos operacionais: são utilizados pelo servidor para funcionalidades operacionais e/ou administrativas, como por exemplo: armazenar a data de criação de um objeto. Esses atributos normalmente não são exibidos nos resultados das consultas.

LDAP ObjectClass Determina as características de um objeto, ou seja, corresponde ao conjunto de atributos que ele pode ter. Todo objeto é criado a partir de uma ou mais objectClasses. Uma objectClass pode ser derivada de outra objectClass, que por sua vez também pode ser derivada de outra objectClass. Dessa forma, podemos ter uma hierarquia de classes com superclasses e subclasses que facilitam o nível de abstração para a criação dos schemas.

LDAP Schema Contém todas as definições de objetos e atributos que podem ser utilizados pelo servidor LDAP. É aqui que são definidos quais atributos são obrigatórios e quais são opcionais em uma determinada classe, se um atributo deve receber uma string ou um número inteiro, quais os critérios de pesquisa podem ser utilizados para um determinado atributo etc.

Relative Distinguished Name (RDN) RDN é o atributo que contém um nome único dentro de um determinado nível da DIT

q

Todo objeto deve possuir um atributo RDN Recomenda-se utilizar atributos obrigatórios dos schemas desejados É possível utilizar mais de um atributo para definir um RDN Assim como no sistema de arquivos do Linux não podemos ter dois arquivos com o mesmo nome dentro de um diretório, no LDAP nós não podemos ter dois objetos com o mesmo RDN dentro do mesmo nível da nossa árvore, e o motivo é muito simples: o nosso serviço de diretório utiliza o RDN para identificar o nosso objeto, portanto, o RDN deve possuir um valor único dentro daquele nível da nossa árvore. O RDN é o atributo que armazena o nome único relacionado ao objeto imediatamente superior, ou seja, podem existir vários objetos com o mesmo RDN, desde que não estejam no mesmo nível da nossa árvore.

11 cn=Pedro Souza 11 ou=Rio de Janeiro 11 ou=funcionários

Capítulo 3 - Servidor LDAP

Exemplos de RDNs:

47

Distinguished Name (DN) Forma de identificação de um objeto em relação a toda a base do LDAP

q

Formado pela concatenação do atributo RDN do objeto desejado mais os atributos RDN de todos os objetos imediatamente anteriores até a raiz da base 11 Analogia com o sistema de arquivos do Linux: 22 RDN = caminho relativo de um arquivo 22 DN = caminho absoluto de um arquivo O Distinguished Name ou DN é a forma de identificação de um objeto em relação a toda base do LDAP. Ele não é um atributo do objeto, mas é formado a partir da concatenação do seu próprio atributo RDN seguido por todos os atributos RDN dos objetos superiores até a raiz da árvore. Por exemplo: vamos voltar à figura 3.6 onde escolhemos o vértice “Pedro Souza”, o RDN desse objeto é cn=Pedro Souza, o objeto imediatamente superior possui o RDN ou=funcionarios, o objeto imediatamente superior à ou=funcionarios possui o RDN ou=operacoes, o objeto imediatamente superior possui o RDN ou=Rio de Janeiro e por fim o objeto imediatamente superior é a raiz da nossa árvore. Se juntarmos todos esses atributos RDN teremos o DN no nosso objeto: cn=Pedro Souza,ou=funcionarios,ou=operacoes, ou=Rio de Janeiro,dc=rnp,dc=br. Exemplos de DNs: 11 ou=Salvador,dc=rnp,dc=br 11 cn=funcionarios,ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br Podemos notar que o DN é representado de baixo para cima na nossa árvore, ou seja, após localizarmos o objeto que desejamos identificar devemos seguir as arestas que o ligam até a raiz da nossa DIT dessa forma conseguimos montar o caminho para chegar ele. Para facilitar o entendimento podemos fazer uma analogia ao sistema de arquivos do Linux, onde: 11 RDN: caminho relativo de um arquivo, exemplo: resolv.conf; 11 DN: caminho absoluto de um arquivo, exemplo: /etc/resolv.conf.

Administração de Sistemas Linux: Serviços para Internet

dc= rnp,dc=br RDN: dc=rnp,dc=br DN: dc=rnp,dc=br ou=Rio de Janeiro RDN: ou=Rio de Janeiro DN: ou=Rio de Janeiro,dc=rnp,dc=br ou=operacoes RDN: ou=operacoes DN: ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br ou=funcionários RDN: ou=operacoes DN: ou=funcionários,ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br cn=Pedro Souza RDN: ou=operacoes

DN: cn=Pedro Souza,ou=funcionários,ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br ou=gerentes RDN: ou=operacoes DN: ou=gerentes,ou=funcionários,ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br

48

Figura 3.7 Exemplos de DN e RDN.

Podemos utilizar qualquer atributo para determinar o RDN de um objeto, ficando a cargo do administrador definir qual será o mais indicado para cada caso. É muito importante que o RDN seja um atributo com valor único para aquele ramo da árvore. Em caso de dúvida sobre qual atributo usar, é recomendado utilizar algum atributo definido como obrigatório no schema. Existem casos em que é possível combinar dois ou mais atributos, formando um multi-valued RDN. Exemplo DN: dn: cn=Pedro Souza+uid=psouza,ou=funcionarios,ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br

LDIF Formato utilizado para comunicação com o diretório LDAP

q

Compatível com a grande maioria dos serviços de diretório Arquivo de texto simples com sintaxe específica: : ATENÇÃO: Espaços no final da linha fazem parte do valor de um atributo LDIF (LDAP Data Interchange Format) é o formato utilizado para comunicação com o diretório LDAP. Através dele podemos importar ou exportar informações do diretório, adicionar, excluir ou modificar objetos, modificar configurações do diretório etc. A maioria dos serviços de diretório suportam esse formato, garantindo assim grande interoperabilidade entre eles. Um arquivo LDIF é um arquivo de texto simples com a sintaxe conforme exemplo a seguir: # isso é um comentário dn: : :

Arquivo LDIF simples com duas entradas, onde cada nova entrada deve ser separada da entrada anterior por uma linha em branco. dn: ou=Salvador,dc=rnp,dc=br objectclass: top objectclass: organizationalUnit ou: Salvador dn: cn=Pedro de Souza,ou=funcionarios,ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br objectclass: person objectclass: organizationalPerson cn: Pedro de Souza sn: Souza uid: psouza

Capítulo 3 - Servidor LDAP

objectclass: top

49

Quando um valor possuir algum caractere especial, o nome do atributo deverá possuir mais um caractere “:”, seguido do valor do atributo codificado em base64. Exemplo: dn: uid=jsilva,ou=funcionarios,ou=operacoes,ou=Rio de Janeiro,dc=rnp,dc=br objectClass: top objectClass: account objectClass: posixAccount uid: jsilva cn: Sm/Do28gZGEgU2lsdmEK #cn: João da Silva userPassword: {crypt}X5/DBrWPOQQaI loginShell: /bin/bash uidNumber: 1010 gidNumber: 1010 homeDirectory: /home/jsilva

Ao analisar esses exemplos, começamos a identificar os atributos que serão utilizados pelo nosso servidor LDAP. Vamos comentar com mais detalhes o último exemplo. 11 Linha 1: Apresenta o Distinguished Name. É através dele que conseguimos identificar de maneira única o objeto em nossa árvore. O atributo escolhido para o RDN foi o uid; 11 Linhas 2, 3 e 4: Descrevem quais são as objectClasses do nosso objeto, ou seja, são elas que vão determinar quais serão os atributos que poderemos utilizar para caracterizar nosso objeto; 11 Linha 5: Identificador do usuário UID; 11 Linha 6: Common Name, está codificado em base64, pois possui caracteres especiais; 11 Linha 7: Toda linha que começa com o caractere # será ignorada; 11 Linha 8: Contém o hash da senha do usuário; 11 Linha 9: Define o shell do usuário; 11 Linha 10: Deve possuir um valor inteiro para identificação do usuário, equivalente ao UID do Linux; Administração de Sistemas Linux: Serviços para Internet

11 Linha 11: Deve possuir um valor inteiro para identificação do grupo primário do usuário,

50

equivalente ao GID do Linux; 11 Linha 12: Caminho absoluto para o diretório home do usuário. Para criar o arquivo LDIF, você precisará saber quais os atributos podem ser utilizados e o que cada um representa. Conforme mencionamos anteriormente, essas definições podem ser encontradas nos schemas que estão carregados no diretório. Mais à frente veremos como consultar essas informações.

Formas de conexão no LDAP Conexão sem criptografia – porta 389 TCP Conexão com criptografia – porta 636 TCP Conexão através de socket – arquivo de socket no servidor

q

Podemos nos conectar ao servidor LDAP de três formas diferentes: URL

Protocolo

Transporte

ldap:///

LDAP

TCP porta 389

ldaps:///

LDAP sobre SSL

TCP porta 636

ldapi:///

LDAP

IPC (Unix-domain socket)

Conforme mencionamos anteriormente o servidor LDAP utiliza a porta 389 TCP para conexões sem criptografia e a porta 636 para conexões com SSL, entretanto caso o servidor tenha sido configurado em uma porta diferente da padrão devemos adicionar o caractere “:” após o nome/IP do servidor seguido do número da porta que deverá ser utilizada para a conexão, exemplo: ldap://192.168.0.1:123 ou ldaps://192.168.0.1:321. Para conexões através de socket (IPC) o path completo do arquivo deve ser codificado e informado na URL. Vamos supor que o socket corresponda ao arquivo /var/run/slapd/ldapi, nesse exemplo a URL de conexão será conforme exibida abaixo: ldapi://%2var%2run%2slapd%2ldapi

Existem várias formar de converter um PATH em uma URL válida, vamos citar um exemplo utilizando o perl: perl -MURI::Escape -e ‘print uri_escape(“/var/run/slapd/ldapi”);’

Agora basta utilizar o caminho codificado na hora de realizar a conexão com o servidor:

Capítulo 3 - Servidor LDAP

ldapadd -H ldapi://%2var%2run%2slapd%2ldapi -D “cn=admin,dc=empresa,dc=com,dc=br” …

51

52

Administração de Sistemas Linux: Serviços para Internet

4 Entender melhor o funcionamento dos schemas e das classes de objetos, ativar módulos, habilitar o uso de criptografia na comunicação entre o cliente e o servidor, conhecer os comandos para manipulação e configuração da base e conhecer alguns clientes gráficos.

conceitos

Schemas e classes de objetos, configuração de cliente, uso de criptografia na comunicação entre o cliente e o servidor, formas de manipulação, configuração, backup e restore da base.

Schemas Obtendo informações sobre os schemas carregados no servidor.

q

11 Primeiro passo # slapcat -b cn=config| grep “^dn” 11 Segundo passo # slapcat -b cn=config -a cn={0}core Para adicionar informações à base precisamos saber quais são os atributos que podem ser utilizados para caracterizar nossos objetos, conforme mencionamos no capítulo anterior, os schemas são responsáveis por definir como as informações poderão ser armazenadas na nossa base. Para sabermos quais atributos podemos utilizar devemos consultar os schemas que estão carregados no nosso servidor. O primeiro passo é utilizar o comando slapcat para listar o DN de todos os schemas carregados. # slapcat -b cn=config| grep “^dn”

O segundo passo é utilizar novamente o comando slapcat para realizar o dump de um schema desejado. Exemplo: # slapcat -b cn=config-a cn={0}core

Outra forma de consultar os arquivos de schemas e acessá-los dentro do sistema de arquivos. Quando realizamos a instalação do openLDAP através dos repositórios os arquivos de schemas mais comuns ficam armazenados no diretório /etc/ldap/schema ou /etc/openldap/schema.

Capítulo 4 - LDAP Avançado

objetivos

LDAP Avançado

Tanto os arquivos quanto a saída do comando slapcat estão no formato LDIF. 53

Classes de objetos 11 Criadas pela diretiva olcObjectClasses

q

11 Elementos da criação de uma ObjectClass: 22 OID 22 NAME 22 SUP 22 STRUCTURAL | ABSTRACT | AUXILARY 22 MUST 22 MAY As diretivas olcObjectClasses criam as objectClasses que estarão disponíveis no servidor. Uma objectClass reúne um conjunto de atributos e determina como os objetos deverão ser criados na base do servidor. Para um atributo ser utilizado em um objeto, ele precisa pertencer a uma classe de objetos. olcObjectClasses: ( 2.5.6.6 NAME ‘person’ DESC ‘RFC2256: a person’ SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

11 olcObjectClasses: inicia a definição de uma classe de objetos; 11 2.5.6.6: é o Object Identifier (OID), número fornecido e gerenciado pela IANA, e deve ser único para cada atributo da base; 11 NAME: nome da classe de objetos; 11 SUP: define qual é a objectClass imediatamente superior, formando assim uma hierarquia de classes de objetos; 11 STRUCTURAL: indica que essa classe pode armazenar valores na estrutura da base; 11 MUST: especifica quais são os atributos que devem ser obrigatórios; 11 MAY: lista de atributos opcionais. Existem três tipos de classes de objetos:

Administração de Sistemas Linux: Serviços para Internet

11 STRUCTURAL: podem armazenar valores na base;

54

11 ABSTRACT: classes que não existem de verdade, mas são necessárias por questões de organização; 11 AUXILARY: define as classes de objetos que fazem parte de outras classes, permitindo melhorar o nível de abstração para definição dos objetos.

Atributos 11 Criados pela diretiva olcAttributeTypes

q

11 Principais elementos da criação de um atributo: 22 OID 22 NAME 22 EQUALITY 22 SUBSTR 22 SYNTAX 22 DESC 22 SUP 11 Vantagens e desvantagens de criar atributos e objectClasses As diretivas olcAttributeTypes descrevem cada um dos atributos que fazem parte do schema. Vamos analisar o exemplo do atributo name: olcAttributeTypes: ( 2.5.4.41 NAME ‘name’

EQUALITY caseIgnoreMatch



SUBSTR caseIgnoreSubstringMatch



SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768})

11 olcAttributeTypes: indica que será iniciada a definição do atributos; 11 2.5.4.41: é o OID fornecido, gerenciado pela IANA e deve ser único para cada atributo da base; 11 NAME: nome do atributo; 11 EQUALITY: indica o comportamento do atributo e seus subordinados, quando for utilizando em filtros de pesquisa; 11 SUBSTR: indica o comportamento do atributo e seus subordinados, quando for utilizado em filtros de pesquisa parcial usando caracteres curinga, como por exemplo, o caractere *; 11 SYNTAX: indica qual é o OID do tipo de dado que será armazenado nesse atributo. O número entre chaves representa a quantidade de caracteres do atributo. O valor 1.3.6.1.4.1.1466.115.121.1.15 corresponde ao tipo “Directory string syntax”. Existe também a diretiva SINGLE-VALUE, que determina que o atributo aceita apenas um valor, quando essa não é especificada o atributo pode receber vários valores. Cada valor é separado por um caractere de espaço.Agora veremos um exemplo de atributo que herda as características de outro.



DESC ‘RFC2256: organizational unit this objetct belongs to’



SUP name)

11 olcAttributeTypes: indica que será iniciada a definição do atributos; 11 2.5.4.11: é o OID fornecido e gerenciado pela IANA e deve ser único para cada atributo da base; 11 NAME: nome do atributo; 11 DESC: descrição detalhada sobre o atributo;

Capítulo 4 - LDAP Avançado

olcAttributeTypes: ( 2.5.4.11 NAME ‘ou’ ‘organizationUnitName’ )

55

11 SUP: indica qual é o atributo imediatamente superior. Essa opção permite criar uma hierarquia de atributos. Dessa forma, o atributo herda as características do atributo name. Podemos criar nossos próprios schemas para uma base LDAP. Entretanto, essa escolha deve ser feita com muito critério, pois ferramentas que não conhecem os schemas que criamos não vão conseguir manipular os objetos corretamente.

Gerenciando schemas 11 Instalar novos schemas:

q

22 Possui o arquivo ldif 22 Adicioná-lo a base ldap com o comando ldapadd O modo de configuração cn=config não possui suporte para desinstalar um schema sem parar o servidor. Para instalar um novo schema no servidor, é necessário ter o arquivo no formato ldif e adicioná-lo a base com o comando a seguir. # ldapadd -h 192.168.0.1 -w senhasecreta -x -D “cn=admin,cn=config” -f /caminho/ para/arquivo/novo-schema.ldif

O modelo de configuração cn=config ainda não possui suporte a exclusão dos schemas carregados sem interromper o serviço. Para remover um schema, será necessário parar o servidor e excluir os arquivos correspondentes ao schema. O diretório que contém os arquivos referentes aos schemas carregados geralmente é /diretorio_de_instalacao/ldap.d/cn=config/cn=schema. Debian/Ubuntu # cd /etc/ldap/ldap.d/cn\=config/cn\=schema

RedHat/CentOS # cd /etc/openldap/ldap.d/cn\=config/cn\=schema

Exclua o aquivo ldif correspondente ao módulo que deseja remover e em seguida inicie o servidor.

Administração de Sistemas Linux: Serviços para Internet

# rm cn={idx}novo-schema.ldif

Módulos Funcionalidades adicionais podem ser carregadas em módulos O atributo olcModulePath contém a localização dos módulos no disco Carregados através do atributo olcModuleLoad O OpenLDAP é um servidor que possui diversas funcionalidade organizadas em módulos que podem ser carregadas conforme a necessidade do administrador. Na árvore do diretório os módulos ficam organizados em cn=config,cn=modules. O atributo olcModulePath define a localização dos módulos no disco, geralmente em /usr/lib/ldap, e os módulos são adicionados a partir de arquivos LDIF conforme o exemplo a seguir: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: nome-do-modulo

56

q

Manipulação da base Comandos para manipulação da base

q

11 slaptest 11 slapcat 11 slapadd 11 slappasswd 11 slapindex 11 ldapsearch 11 ldapadd 11 ldapmodify 11 ldapdelete 11 ldapmodrdn Saber manipular as informações da base LDAP é uma tarefa muito importante para um administrador de sistemas e nem sempre temos ferramentas gráficas para nos auxiliar nessa tarefa. Eis os principais comandos disponíveis no Linux para manipulação das informações da base LDAP: slaptest: utilizado para verificar a configuração do servidor openldap. Verifica tanto um arquivo (formato antigo) quanto o diretório cn=config(formato novo). Esse comando é muito útil quando temos de fazer modificações diretamente na base do servidor ou para realizar a migração do modo de configuração slapd.conf para o modo cn=config. Testando a configuração de um arquivo: # slaptest -f /etc/ldap/ldap.conf

Testando a configuração no formato cn=config # slaptest -F /etc/ldap/slapd.d/

slapcat: gera um dump da base do servidor no formato LDIF. O parâmetro -b permite escolher o sufixo da base que será utilizado, e o parâmetro -a permite o uso de filtros. # slapcat -b cn=config # slapcat -a ‘(uid=aluno)’

slapadd: adiciona novos objetos diretamente na base do LDAP, não precisando que o servidor esteja no ar. Pode receber um arquivo LDIF como entrada ou ler a partir da entrada padrão. Esse comando geralmente só está disponível no servidor.

-h permite definir qual será o algoritmo de criptografia da senha – valores válidos para o parâmetro -h: {CRYPT}, {MD5}, {SMD5}, {SSHA} e {SHA}. Exemplos: # slappasswd -h {SHA} -s minhasenha

slapindex: atualiza os índices da base. O daemon do servidor não deve estar rodando durante essa operação. É possível atualizar todos os índices ou apenas os índices desejados:

Capítulo 4 - LDAP Avançado

slapppasswd: utilitário para gerar senhas para serem utilizadas em arquivos LDIF. A opção

57

Exemplos: # slapindex # slapindex uid

ldapsearch: ferramenta para realizar pesquisas na base do servidor LDAP. Pode retornar um ou mais objetos e possui uma série de opções para criação dos filtros de pesquisa, ordenação, definição de escopo, versão do protocolo etc. Exemplos: Listando todos os objetos a seguir de ou=usuarios, dc=empresa, dc=com, dc=br # ldapsearch -D “cn=admin,dc=empresa,dc=com,dc=br” -b “ou=usuarios,dc=empresa,dc=c om,dc=br” -W

Exibindo somente os atributos uid e cn da consulta anterior: # ldapsearch -D “cn=admin,dc=empresa,dc=com,dc=br” -b “ou=usuarios,dc=empresa,dc=co m,dc=br” -W uid cn

ldapadd: conecta no servidor para adicionar um novo objeto à base. Exemplo: considerando que o arquivo /tmp/novousuario.ldif possua o conteúdo a seguir: dn: uid=pedro,dc=empresa,dc=com,dc=br objectClass: person cn: pedro Silva sn: silva title: operador mail: [email protected] uid: pedro # ldapadd -D “cn=admin,dc=empresa,dc=com,dc=br” -W -f /tmp/novousuario.ldif

ldapmodify: permite realizar modificações nos objetos da base. Recebe um arquivo LDIF como parâmetro ou lê a partir da entrada padrão. Se for usando com o parâmetro -a tem a mesma função do comando ldapadd. dn: uid=aluno,ou=usuarios,dc=empresa,dc=br

Administração de Sistemas Linux: Serviços para Internet

changetype: modify

58

replace: mail mail: [email protected]

Adicionando um novo atribuito a um objeto. dn: uid=pedro,ou=usuarios,dc=empresa,dc=br changetype: modify add: telephoneNumber telephoneNumber: 12 3456-7890

Excluindo um atributo de um objeto. dn: uid=professor,ou=usuarios,dc=empresa,dc=br changetype: modify delete: mail # ldapmodify -D “cn=admin,dc=empresa,dc=br” -w senhasecreta -f /tmp/arquivo.ldif

Caso o arquivo LDIF tenha mais de uma modificação, elas devem ser separadas por uma linha em branco. ldapdelete: exclui um objeto da base do LDAP. # ldapdelete “uid=aluno,ou=usuarios,dc=empresa,dc=com,dc=br”

ldapmodrdn: modifica o RDN do objeto. uid=aluno,ou=usuarios,dc=empresa,dc=com,dc=br uid=aluno-novo # ldapmodrdn -D “cn=admin,dc=empresa,dc=com,dc=br” -w senha -r -f /tmp/arquivo.ldif

Gerenciamento de Logs 11 Registra os logs via syslogd utilizando a facilidade LOCAL4

q

11 As modificações devem ser feitas via arquivo LDIF 22 olcLogFile 22 olcLogLevel O Openldap registra seus logs via syslogd usando a facilidade LOCAL4 por padrão. Para realizar qualquer modificação do sistema de armazenamento de logs é preciso criar um arquivo LDIF com as diretivas adequadas. 11 olcLogFile: indica o caminho do arquivo de logs; 11 olcLogLevel: configura a sensibilidade do sistema de logs. dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: stats # ldapmodify -Y EXTERNAL -H ldapi:/// -f configuracao-log.ldif

Número

Hexa

Logname

Descrição

-1

0xFFFF

any

Habilita todos os tipos de log

0

0x0000

-

Desabilita o registro de logs

1

0x1

trace

trace function calls

2

0x2

packets

Habilita o registro de pacotes de debug

4

0x4

args

Pacotes de debug com mais informações

8

0x8

conns

Gerenciamento da conexão

16

0x10

BER

Pacotes enviados e recebidos

32

0x20

filter

Registra apenas informações referentes a filtros de busca

64

0x40

config

Logs referentes as configurações do servidor

128

0x80

ACL

Logs referentes ao processamento das ACLs

Capítulo 4 - LDAP Avançado

A tabela a seguir apresenta os níveis de log que podem ser utilizados:

59

Número

Hexa

Logname

Descrição

256

0x100

stats

Registra os logs de operações/conexões/resultados de buscas (default)

512

0x200

stats2

Logs referente aos objetos enviados

1024

0x400

shell

Comunicação entre backends shell

2048

0x800

parse

Registra debug referente aos objetos acessados

4096

0x1000

cache

caching (não utilizado)

8192

0x2000

index

indexing (não utilizado)

16384

0x4000

sync

Logs de replicação (syncrepl)

32768

0x8000

none

Registra apenas mensagens críticas que não estão categorizadas

Cliente LDAP Para acessar os serviços LDAP, o cliente pode utilizar os três tipos de autenticação:

q

11 Anônima 11 Simples 11 SASL Para acessar os serviços LDAP, o cliente deve se autenticar informando suas credenciais. Após esta etapa a aplicação direciona o cliente de acordo com o que ele pode ver e fazer. No LDAP, a autenticação pode ser de três tipos: anônima, simples e SASL. 11 Anônima: quando o cliente que envia um pedido de autenticação sem fazer um bind. Será tratado como um cliente anônimo; 11 Simples: consiste em enviar ao servidor LDAP o DN do cliente e sua senha (não criptografada); 11 SASL (Simple Authentication and Security Layer): especifica um protocolo cujos dados serão transferidos entre o cliente e o servidor utilizando canais encriptados, como SSL,

Administração de Sistemas Linux: Serviços para Internet

por exemplo, diminuindo assim a exposição da senha.

60

Pacotes para instalação cliente 11 PAM – Pluggable Authentication Modules

q

22 Instalação 22 Configuração 11 NSS – Name Service Switch 22 Instalação 22 Configuração O PAM (Pluggable Authentication Modules) é um conjunto de bibliotecas que são utilizadas pelas aplicações para autenticar os usuários no Linux, e o NSS (Name Service Switch) é uma interface que determina onde as bases de dados para autenticação serão obtidas. Precisaremos instalar e configurar os esses pacotes com suporte ao LDAP.

Debian/Ubuntu # apt-get install libpam-ldap libnss-ldap

Um assistente será executado logo após a instalação dos pacotes. Responda as perguntas de acordo com a configuração do seu ambiente. Exemplo: 11 LDAP URI: ldap://192.168.0.1 11 DN da base: dc=empresa,dc=com,dc=br 11 Versão do protocolo suportada: 3 11 A base do LDAP necessita de login: não 11 Conta de administrador do LDAP: cn=admin,dc=empresa,dc=com,dc=br 11 Senha: senhasecreta RedHat/CentOS # yum install openldap openldap-clients nss-pam-ldapd

Após a instalação, devemos executar o comando authconfig-tui, que vai iniciar uma interface para auxiliar a configuração do cliente. # authconfig-tui

Em Informações do Usuário, marque “Utilizar LDAP” e em Autenticação marque a opção “Utilizar autenticação LDAP”. Na próxima tela, informe o endereço do servidor LDAP e o DN da base. Exemplo: 11 Servidor: ldap://192.168.0.10 11 DN da base: dc=empresa,dc=com,dc=br

Pluggable Authentication Modules Após esses procedimentos, os assistentes terão configurado os arquivos do PAM para permitir o acesso de usuários da base do LDAP. Também podemos realizar as mudanças manualmente editando os arquivos referentes a cada módulo do PAM. Debian/Ubuntu auth

[success=1 default=ignore] pam_ldap.so use_first_pass

account

[success=1 default=ignore] pam_ldap.so

password

[success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok

try_first_pass optional pam_ldap.so

RedHat/CentOS auth

sufficient

pam_ldap.so use_first_pass

account

[default=bad success=ok user_unknown=ignore] pam_ldap.so

password

sufficient pam_ldap.so use_authtok

session

optional pam_ldap.so

Capítulo 4 - LDAP Avançado

session

61

Uma funcionalidade interessante que podemos explorar no PAM é a possibilidade de o sistema criar o homedir dos usuários automaticamente quando o login for realizado. Para utilizar esse recurso, é necessário configurar a funcionalidade editando o arquivo correspondente ao módulo session do PAM e adicionar a linha. session

required pam_mkhomedir.so skel=/etc/skel umask=0022

Debian/Ubuntu /etc/pam.d/common-session

RedHat/CentOS /etc/pam.d/system-auth

Name Service Switch Agora precisamos informar para o sistema de onde as informações referentes aos logins e senhas serão obtidas. Para isso precisamos editar o arquivo /etc/nsswitch.conf. O arquivo é organizado em duas colunas: a primeira indica o nome da base de dados e a segunda coluna indica de onde o sistema vai obter as informações referentes à base. Podemos colocar vários valores para a segunda coluna, e o sistema vai listar os dados na ordem em que aparecem no arquivo. Precisamos alterar a configuração para indicar que as bases de password, group e shadow sejam consultadas a partir do servidor LDAP. password:

ldap files

group:

ldap files

shadow:

ldap files

Dessa forma, o sistema vai consultar primeiro as informações do servidor LDAP. Caso não encontre, realizará a busca no sistema de arquivos do Sistema Operacional. Utilize o comando getent para verificar se as configurações funcionaram corretamente. Como resultado deve aparecer uma relação com todos os usuários cadastrados no LDAP mais os usuários locais. Para que a consulta seja somente aos usuários do LDAP basta remover o parâmetro files, entretanto se o servidor do LDAP estiver fora do ar não será

Administração de Sistemas Linux: Serviços para Internet

possível acessar a máquina com uma conta local.

Ao utilizar a autenticação do LDAP, é recomendado desativar o daemon do nscd para evitar o cache de informações desatualizada.

Segurança do Servidor LDAP 11 Qual o valor da informação armazenada na base do servidor? 11 Qual problema o acesso indevido pode causar a empresa ou instituição? 11 Recurso ACL (Access Control List) 22 Sintaxe: access to [ by [ ] [ ] ]+ Um serviço de diretório pode ser utilizado para diversas finalidades, e quanto mais informação armazenada nele, mais cuidado devemos ter com a sua segurança. Um diretório

62

q

pode conter dados confidenciais que não podem ser acessados por outros usuários ou ser utilizado para controlar o acesso a um determinado serviço. O acesso indevido a essas informações pode causar grandes problemas para uma empresa ou instituição. Um recurso que pode ser implantado para melhorar a segurança do sistema é o uso de uma lista de controle de acesso: ACLs no servidor LDAP, que permite controlar o que, quem e como os dados podem ser acessados. Sintaxe: access to [ by [

] [ ] ]+

11 o que: atributo para o qual o controle será aplicado; 11 quem: usuário ou elemento da base; 11 acesso: determina o nível de acesso do parâmetro “quem”; 11 controle: permite configurar como será o comportamento da ACL. Exemplo 1: olcAccess: {0}to attrs=userPassword,shadowPassword,shadowLastChange

by self write



by annonymous auth



by dn=”cn=admin,dc=empresa,dc=com,dc=br” write



by * none

11 o que: atributos userPassword, shadowPassword e shadowLastChange 11 quem: self, annonyous, cn=admin,dc=empresa,dc=com,dc=br e * 11 acesso: write, auth, write e none 11 controle: não definido, está usando o valor padrão (stop) Essa ACL é responsável pelo acesso aos atributos userPassword, shadowPassword e shadowLastChange, e controla quatro níveis de acesso: 11 1º: usuário dono do atributo (self) tem permissão para alterá-lo (write); 11 2º: força a autenticação, pois é exigida a autenticação para usuários não autenticados (annonymous); 11 3º: usuário cn=admin,dc=empresa,dc=com,dc=br tem permissão para alterar os atributos; 11 4º: todos os outros usuários que não se enquadram em nenhum dos controles anteriores não terão permissão (none) para alterar esses atributos. Exemplo 2: olcAccess: {1}to dn.base=”” by * read o que: dn.base=””

l

Devido à ordem de interpretação das ACLs, crie suas regras mais restritivas primeiro e depois siga com as menos restritivas.

acesso: read

Essa ACL determina que todos os usuários terão acesso apenas de leitura aos objetos da base. Uma solução bem interessante para consultas genéricas realizadas ao servidor. Observe que as ACLs possuem um número entre os caracteres de chaves {N}. Esse número é um índice que determina a ordem em que as ACLs serão interpretadas pelo servidor. Dessa forma, no nosso exemplo, primeiro será interpretada a ACL com o índice 0 e, caso a conexão não atenda a nenhum dos critérios, será interpretada a ACL com índice 1.

Capítulo 4 - LDAP Avançado

quem: *

63

Criptografia das mensagens Cliente Servidor LDAP 11 Suporte aos métodos criptográficos:

q

22 SSL (Secure Sockets Layer) 22 TLS (Transport Layer Security) Os servidores LDAP tem suporte aos métodos criptográficos Secure Sockets Layer (SSL) e o Transport Layer Security (TLS), para estabelecer conexões seguras entre os clientes e o servidor. A segurança de ambos está garantida pela biblioteca do OpenSSL e eles diferem apenas na forma de funcionamento. Enquanto o modo SSL precisa que os clientes se conectem a uma porta específica (geralmente a 636), o modo TLS utiliza a porta padrão do LDAP, mas precisa que o cliente tenha um certificado válido do servidor com a chave para a criptografia das mensagens. A utilização da criptografia impede que os pacotes trocados entre os clientes e o servidor sejam lidos por outros usuários da rede.

Criando a Autoridade Certificadora Para utilizar as vantagens é necessário:

q

11 Criar uma Autoridade Certificadora (AC) 11 Criar Certificados 11 Assinar certificados Para usufruir das vantagens da criptografia, será necessária a criação de uma Autoridade Certificadora (AC) para emissão e assinatura dos certificados de todos os hosts envolvidos na comunicação. O OpenSSL possui um script CA.sh, que cria a Autoridade Certificadora – AC dentro dos padrões do sistema. É necessário criar o diretório onde os certificados serão armazenados. # mkdir /etc/ldap/ssl

Execute o script CA.sh e responda as perguntas que serão feitas. # /usr/lib/ssl/misc/CA.sh

-newca

Criando os certificados Administração de Sistemas Linux: Serviços para Internet

Com a Autoridade Certificadora criada, podemos começar a emitir os nossos certificados.

64

Vamos utilizar o comando openssl para a criação do arquivo. Atenção ao preenchimento do campo “Common Name”. Esse campo deve ser preenchido com o FQDN do nosso servidor. # openssl req -new -nodes -keyout newreq.pem -out newreq.pem

Assinando o certificado A Autoridade Certificadora será a responsável pela assinatura dos certificados dos servidores. # /usr/lib/ssl/misc/CA.sh

-sign

É recomendado renomear o arquivo para facilitar sua identificação. Certificado da AC # cp demoCA/cacert.pem cacert.pem

Certificado do servidor # mv newcert.pem

servidor.pem

Chave do servidor # mv newreq.pem

servidorkey.pem

Configurando o Transport Layer Security no servidor Alterando a configuração do servidor LDAP

q

A configuração do TLS necessita de um arquivo LDIF, contendo as informações apontando o caminho para os certificados. # vi /tmp/ssl.ldif dn: cn=config add: olcTLSCipherSuite olcTLSCipherSuite: NORMAL add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ldap/ssl/cacert.pem add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/ssl/servidor.pem add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/ssl/servidorkey.pem

Com os certificados criados e o servidor OpenLDAP configurado, podemos forçar que todas as conexões sejam criptografadas para garantir que ninguém conseguirá acessar a base por um meio inseguro. O atributo olcSecurity permite essa configuração. Essa configuração deve ser realizada no arquivo security.ldif, e conter as configurações da base do servidor. # vi /tmp/security.ldif dn: cn=config changetype: modify add: olcSecutiry olcSecurity: ssf=1 update_ssf=112 simple_bind=64 # ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/security.ldif

Para testar o funcionamento, adicione o parâmetro -ZZ e faça referência ao FQDN do servidor nas consultas.

=br -w senhasecreta -b dc=empresa,dc=com,dc=br

Configurando Secure Sockets Layer no servidor Para habilitar o LDAP é necessário: 11 Ativar a porta 636 do serviço ldaps 11 Configurar o cliente para usar SSL

q

Capítulo 4 - LDAP Avançado

# ldapsearch -ZZ -H ldap://servidor.empresa.com.br –D cn=admin,dc=empresa,dc=com,dc

65

A configuração do SSL necessita que o serviço seja habilitado para a porta do ldaps. Para isso, é preciso editar o arquivo /etc/default/slapd. SLAPD_SERVICES=”ldap:/// ldapi:///”

Por SLAPD_SERVICES=”ldap:/// ldapi:/// ldaps:///”

Reinicie o servidor do OpenLDAP e teste a conexão informando o protocolo ldaps. # ldapsearch -H ldaps://servidor.empresa.com.br -D cn=admin,dc=empresa,dc=com,dc=br -w senhasecreta -b dc=empresa,dc=com,dc=br

Configurando o cliente SSL Para que os clientes possam se conectar ao servidor utilizando o SSL, será necessário modificar a configuração do arquivo ldap.conf e informar a URI para o protocolo ldaps. URI ldaps://servidor.empresa.com.br

O certificado da AC deve ser enviado e incluído no diretório de todos os clientes, informado no parâmetro TLS_CACERTDIR. É possível desabilitar a verificação do certificado comentando a linha TLS_CACERTDIR e adicionando a linha TLS_REQCERT never.

Replicação da base LDAP 11 Replicação Master X Slave

q

11 Replicação Master x Master 11 Diretórios distribuídos A utilização de serviço de diretório possibilita ganhos em vários aspectos no ambiente de rede, mas torna o ambiente dependente do serviço, uma vez que sua indisponibilidade impede que usuários efetuem login em suas máquinas ou acessem sua lista de contatos. Entre outros, faz com que a importância de disponibilidade seja prioridade na infraestrutura. Em virtude disso, configurar um ambiente que garanta alta disponibilidade dos serviços é cada dia mais comum em grandes empresas. No sistema OpenLDAP existem duas técnicas de replicação da base, que são o slurpd e o syncrepl. O sluprd foi descontinuado a partir da versão 2.4 por apre Administração de Sistemas Linux: Serviços para Internet

sentar uma série de limitações que foram implementadas no syncrepl.

66

O syncrepl é um módulo do OpenLDAP que permite replicação do ambiente, onde o servidor pode assumir duas funções distintas: Master (provedor) ou Slave (consumidor).

Replicação Master X Slave Nesse modo de replicação, temos apenas um servidor máster, que é o responsável por executar todas as modificações na base do LDAP, enquanto os servidores Slave apenas realizam consultas e retornam as respostas para os clientes.

Modificações de cliente Atualizações

Servidor 1

Servidor 2

master

slave

leitura

leitura

e escrita

Cliente Figura 4.1 Replicação Master x Slave.

Consultas

Replicação Master x Master Em um ambiente de replicação Master x Master, temos dois ou mais servidores capazes de atualizar as informações da base do LDAP. Em alguns casos, essa solução pode ser interessante, pois garantimos que além da consulta as atualizações também ficarão disponíveis caso um servidor Master falhe.

Provedor B Replica

Provedor A

Replica Lê

Escreve

Replica

Figura 4.2 Replicação Master x Master.

Cliente

Provedor C

Lê e escreve

Diretórios distribuídos Esse modelo de replicação permite maior flexibilidade ao administrador. Além de criar uma cópia da base em outros servidores, podemos determinar quais informações devem ser replicadas para cada um. Para configurar esse modelo de replicação, é necessário utilizar o

Ferramentas gráficas Ferramentas gráficas auxiliam a administração da base do LDAP. 11 Apache Directory Studio 11 Phpldapadmin 11 LDAP Admin

q

Capítulo 4 - LDAP Avançado

módulo referral do OpenLDAP.

67

Como vimos até agora, a administração da base do LDAP é um pouco trabalhosa, pois precisamos criar arquivos LDIF para realizar qualquer tipo de modificação. Nesse aspecto, as ferramentas gráficas são um recurso muito interessante, pois auxiliam os administradores menos experientes a gerenciar a base do servidor. 11 Apache Directory Studio: mantido pela Apache Software Foundation, é uma ferramenta muito completa que permite navegar pela base de dados, possui um editor de arquivos LDIF, editor de schemas e é multiplataforma, com versões em inglês, francês e alemão; 11 Phpldapadmin: aplicação web baseada em php, que permite navegar e gerenciar o servidor LDAP. Entre as suas funcionalidades podemos destacar: permite a criação e edição dos objetos baseado em templates, cópias recursivas, suporte a importação e expor-

l

tação da base no formato LDIF, navegação em forma de árvore, incremento automático de números UID etc.; 11 LDAP Admin: cliente LDAP para gerenciamento da base de dados, permite navegar, pesquisar, modificar, criar, remover, copiar objetos entre servidores, importar e exportar objetos em formato LDIF, suporte a SSL e o uso de templates. Utilize o comando apropos para pesquisar em todos as páginas de manual pela palavra slapd. # apropos slapd

Backup e Restore 11 Backup

q

slapcat # slapcat > /tmp/backup.ldif ldapsearch # ldapsearch -D “cn=admin,dc=empresa,dc=com,dc=br” -w senhasecreta -b “dc=empresa,dc=com,dc=br” -LLL > /tmp/backup.ldif 11 Restore 22 Indicando o arquivo que contém o backup da base # slapadd -f /tmp/backup.ldif

Administração de Sistemas Linux: Serviços para Internet

22 Utilize o comando slapindex para recriar todos os índices

68

# slapindex -v 22 Inicie o servidor do openLDAP. # service slapd start Tão importante quanto manter um serviço bem configurado e funcionando é ter a garantia de recuperação contra possíveis desastres. Gerenciar e monitorar a realização do backup é uma tarefa muito importante de um administrador de sistemas. Para fazer o backup de uma base LDAP, podemos utilizar os comandos slapcat ou ldapsearch. A saída desses comandos será um arquivo LDIF contendo todos os objetos da base que poderão ser restaurados quando necessário. Existem duas ferramentas que podemos utilizar para realizar o backup da base de dados do LDAP, os comandos slapcat e ldapsearch.

Para mais detalhes sobre as diretivas de configurações do OpenLDAP, acesse a documentação oficial em www.openldap.org/ doc ou leia as páginas de manual do Linux.

Backup slapcat # slapcat > /tmp/backup.ldif

ldapsearch # ldapsearch -D “cn=admin,dc=empresa,dc=com,dc=br” -w senhasecreta -b “dc=empresa,dc=com,dc=br” -LLL > /tmp/backup.ldif

A principal diferença é que no comando slapcat não precisamos informar o DN do administrador da base. No comando ldapsearch, usamos a opção -LLL para garantir que a saída não possuirá nenhum tipo de comentário ou informação referente à versão do LDIF gerado.

Restore Após certificar-se de que a base do LDAP está vazia e que o servidor não está rodando, execute o comando slapadd indicando o arquivo que contém o backup da base. # slapadd -f /tmp/backup.ldif

Utilize o comando slapindex para recriar todos os índices # slapindex -v

Inicie o servidor do openLDAP. # service slapd start

Atividade de Fixação e Elaborando uma solução de backup da base do LDAP 1. Crie um script que realiza o dump da base de dados, armazena o resultado em um diretório específico, compacta o arquivo LDIF gerado e envia o relatório para o e-mail do administrador.

Capítulo 4 - LDAP Avançado

2. Configure o cron para que esse script seja executado todos os dias às 23:00h.

69

70

Administração de Sistemas Linux: Serviços para Internet

5 Aprender a instalar e configurar o servidor web Apache, configurar servidores virtuais e o servidor web seguro, usando certificados digitais, utilização do arquivo.htacces e gerenciamento de módulos no servidor web Apache.

conceitos

Fundamentos de servidores web: arquitetura, esquema de funcionamento, protocolo HTTP, servidor Apache, recursos comuns a servidores web, domínio virtual e servidor seguro (SSL).

Introdução Este capítulo aborda os conceitos fundamentais de servidores web, como arquitetura, esquema de funcionamento, protocolo HTTP, servidores web, servidor Apache e a instalação e testes com o servidor Apache. Na primeira parte são apresentados os conceitos iniciais, arquitetura e protocolo. Em seguida são abordados os recursos comuns aos diversos servidores web atualmente disponíveis e, por último, são apresentados os recursos do servidor web Apache, inclusive sua instalação, configuração e testes.

Conceitos fundamentais World Wide Web (WWW (World Wide Web):

q

11 Desenvolvida para permitir o acesso a informações organizadas em forma de hipertexto. 11 Permite a recuperação de informação: 22 Texto. 22 Imagens (estáticas e animadas). 22 Áudio , etc. 11 Baseada na arquitetura cliente / servidor. 11 O servidor armazena um conjunto de arquivos de dados que são transferidos para o cliente. 11 Identificação de servidores, serviços e arquivos de modo uniforme. 11 Uniform Resource Locator (URL)

Capítulo 5 - Servidor web

objetivos

Servidor web

71

A internet, muitas vezes denominada World Wide Web (WWW), permite um grande e variado trânsito de informações, tais como textos, documentos, conteúdos multimídia, mensagens etc. Umas das ferramentas mais utilizadas para o envio e a recuperação de informações são os servidores web, que permitem o envio de textos, mensagens, imagens e áudio. Para isso, um determinado servidor web pode usar páginas estáticas, que são nada mais do que arquivos presentes no sistema de arquivos do servidor, ou páginas dinâmicas, que são conteúdos gerados dinamicamente e sob demanda para o cliente que as solicita. Esta última forma é muito utilizada em transações pela internet. Nesse caso, o conteúdo pode ser gerado pelo próprio servidor web que atende ao pedido dos clientes, ou então por outro servidor acoplado que processa e repassa o conteúdo. A comunicação web lida com um processo do tipo cliente/servidor. Nesse caso, um cliente (navegador web) envia uma solicitação ao servidor web, que processa a solicitação e envia a resposta ao cliente. A solicitação enviada pelo cliente consiste em uma URL (Uniform Resource Locator), por exemplo: http://www.rnp.br. Essa solicitação é enviada para o servidor web, que encaminha o conteúdo associado a esse endereço, que pode conter textos, imagens e áudio.A URL possui uma estrutura conforme ilustrada na figura 5.1.

q

11 Uniform Resource Locator (URL)

Protocolo://

servidor

[:porta]

/

caminho

/

arquivo

11 Protocolo: indica o serviço desejado, exemplosHyper Text Trasnfer Protocol (HTTP), File Transfer Protocol (FTP), File (para um arquivo local) etc.; 11 Servidor[:porta]: representa o endereço do servidor desejado, pode ser um número IP ou um Fully Qualified Domain Name (FQDN) seguido do número da porta. Se número da porta for omitido será considerada a porta default para o protocolo utilizado; 11 Caminho: indica o caminho no sistema arquivos do servidor; 11 Arquivo: corresponde ao arquivo desejado. 11 Protocolo:

q

11 Indica o serviço desejado:

Administração de Sistemas Linux: Serviços para Internet

11 Hyper Text Transfer Protocol (HTTP (Hyper Text Transfer Protocol).

72

11 File Transfer Protocol (FTP (File Transfer Protocol). 11 MAILTO (para correio eletrônico). 11 Terminal Network (Telnet (Terminal Network). 11 File (para arquivo local). A solicitação enviada pelo cliente consiste em uma URL, que possui componentes como: protocolo, servidor, porta, caminho e arquivo. Essas informações servem para designar o serviço, protocolo e porta que devem ser acessados e utilizados na obtenção dos dados. Desse modo, mesmo quando vários serviços diferentes estão disponíveis no servidor em questão, cada um pode trabalhar de modo independente do outro. Logo poderemos ter em uma mesma máquina diversos serviços, como servidor web, servidor FTP, servidor DNS etc. Um servidor web pode possuir grande quantidade de informação, dispersa por uma grande quantidade de arquivos e pastas.

Figura 5.1 Formato básico da URL.

q

11 Servidor [:porta] 11 Indica o endereço do servidor desejado. 11 Pode ser um Fully Qualified Domain Name (FQDN (Fully Qualified Domain Name): nome da máquina, domínio e domínio de topo. 11 Ou somente o nome da máquina para acessos a partir da mesma rede. 11 Caminho: 11 Indica o caminho no sistema de arquivos do servidor web. 11 Arquivo: 11 Indica o arquivo desejado.

Por isso, é necessário que o cliente, ao buscar por determinado dado, informe o caminho completo até ele, o que usualmente é feito por meio da digitação da URL no navegador, ou de um clique em determinado link disponível em determinada página da internet.O caminho indica em qual pasta ou arquivo a partir de uma pasta raiz está o dado procurado. Essa pasta raiz normalmente não coincide com a raiz do sistema no qual o servidor web está instalado. Entre as várias informações de uma URL, usamos: protocolo, servidor, porta, caminho e arquivo. Alguns desses dados podem ser omitidos quando digitamos a URL no navegador ou em um link da página web. Logo, o acesso a determinada página web pode ser feito digitando, por exemplo: http://www.rnp.br:80/index.html ou www.rnp.br. No exemplo apresentado, não foi necessário, ao informar uma URL no navegador, passar o protocolo, porta e arquivo. Isso é possível porque os navegadores web encaminham por padrão uma consulta utilizando o protocolo HTTP e a porta padrão 80. O servidor web, por sua vez, envia como resposta a página padrão especificada em seu arquivo de configuração, nesse caso, index.html.

URL / HTTP HTML / MIME Web Browser

Web Server

Internet

Web Browser

Web Server

Dispositivo de arquivos

11 Servidor Web 11 Utilizam a porta TCP 80 por padrão 11 Após estabelecida uma conexão o cliente envia uma solicitação e o servidor envia uma resposta. 11 O protocolo utilizado para comunicação é o Hyper Text Transfer Protocol (HTTP)

q

Capítulo 5 - Servidor web

Figura 5.2 Transferência de dados entre cliente e servidor.

73

11 Cliente Web

q

22 O navegador, também chamado de browser, busca a página solicitada, interpreta o conteúdo e apresenta as informações. 22 Entre os navegadores mais conhecidos podemos citar: Google Chrome, Firefox, Safary e Internet Explorer.

Servidor web Os servidores web, por padrão, ficam aguardando conexões na porta 80 TCP. Após estabelecida a conexão o cliente envia uma solicitação e o servidor envia uma resposta. O protocolo que define as solicitações e respostas válidas é chamado de Hyper Text Transfer Protocol (HTTP).

Cliente web Disponibiliza um mecanismo de busca, transferência e apresentação de dados contidos em servidores web. O navegador, também denominado browser, busca a página solicitada, interpreta seu texto, seus comandos de formatação e apresenta os dados na tela.Entre os navegadores mais conhecidos hoje estão: Google Chrome, Firefox, Internet Explorer e Safari. Existe também o Lynx, um navegador de linha de comando muito utilizado em testes e/ou em computadores sem a interface gráfica instalada.

Protocolo HTTP Hyper Text Transfer Protocol (HTTP).

q

Protocolo utilizado para a transferência de informações na web, utilizando TCP. 11 HTTP/0.9 11 HTTP/1.0 11 HTTP/1.1 11 HTTP/2.0 O protocolo HTTP é um protocolo de camada de aplicação utilizado em sistemas distribuídos, colaborativos e de hipermídia. Sua primeira versão HTTP/0.9 está em uso desde 1990, sendo até então um protocolo simples para transferência de dados brutos pela internet. A versão HTTP/1.0 melhorou o protocolo ao permitir a transferência de mensagens no Administração de Sistemas Linux: Serviços para Internet

formato Multipurpose Internet Mail Extensions(MIME), contendo metadados e modifica-

74

dores nas solicitações e respostas. No entanto, não suportava caching, proxies hierárquicos, conexões persistentes ou hosts virtuais. A versão HTTP/1.1 foi desenvolvida para atender a essas necessidades, e ainda às necessidades adicionais de buscas, atualizações de front-end, incluindo um amplo conjunto de métodos e cabeçalhos que indicam a finalidade da solicitação. As mensagens são passadas em um formato semelhante ao das mensagens de e-mail, utilizando o formato MIME. O HTTP é ainda um protocolo genérico para outros sistemas internet, como SMTP, NNTP e FTP, permitindo que diversas aplicações possam acessar conteúdo hipermídia. A versão HTTP/2.0 foi lançada em 18 de fevereiro de 2015, e representa uma mudança significativa em relação à versão anterior. A principal vantagem da nova versão é permitir que as páginas possam ser carregadas com maior velocidade. Para isso o protocolo vai trabalhar com multiplexação, permitindo que uma única conexão baixe múltiplos arquivos simultaneamente e o retorno desses arquivos será feito de forma assíncrona e paralela.

As versões mais recentes dos principais navegadores possuem suporte para a versão 2 do protocolo já os servidores ainda estão em fase experimental de implementação, mas já podem ser utilizados em ambientes de testes. O HTTP é um protocolo do tipo requisição/resposta, e toda comunicação é feita através de mensagens no formato ASCII (texto puro). Em uma comunicação típica, o cliente solicita um documento ao servidor e o servidor envia ou não o documento para o cliente. O servidor não armazena nenhuma informação de estado entre as requisições. Isso porque cada requisição é completamente independente da outra. Uma mensagem HTTP é formada por uma linha inicial que determina se a mensagem é uma requisição ou uma resposta, seguida por um conjunto de linhas que compõem os cabeçalhos, uma linha em branco (delimitador do cabeçalho) e por fim o corpo da mensagem (quando houver). Mensagens HTTP

q

11 Formato da mensagem: [ linha do tipo da mensagem ] [ linhas de cabeçalho ] linha em branco [ corpo da mensagem ] As mensagens do protocolo HTTP podem ser de dois tipos: requisição e resposta

Requisição (request) Mensagem enviada pelo cliente (browser) para o servidor web.

q

Formato: [Request Type] espaço [URI] espaço [HTTP version] Cabeçalhos Métodos (Request Types): 11 GET 11 HEAD 11 PUT 11 POST 11 DELETE 11 LINK/UNLINK Uma mensagem de requisição enviada por um cliente tem os seguintes campos: tipo de requisição (método), uma Universal Resource Identifiers (URI), versão do protocolo, uma mensagem em formato tipo MIME contendo os cabeçalhos da requisição e informações do cliente e conteúdo (quando houver). Formato de uma requisição feita pelo protocolo HTTP: [Request Type] espaço [URI] espaço [HTTP version] Exemplo: GET /diretorio/pagina.html HTTP/1.1 Host: www.rnp.br

Capítulo 5 - Servidor web

l

Mais informações sobre a versão 2 do protocolo HTTP podem ser encontradas nas RFCs 7540 e RFC7541.

User-agent: Mozilla/4.0

75

Os métodos são utilizados tanto para solicitações de páginas web quanto para o envio de informações inseridas pelos usuários nessas páginas. É através deles que informamos ao servidor o tipo de requisição que estamos realizando. Os principais métodos são: 11 GET: recupera qualquer recurso identificado por uma URI disponibilizada do servidor. É o método padrão para requisições de conteúdo através de uma URL; 11 HEAD: idêntico ao método GET, entretanto não possui o corpo da mensagem na resposta; 11 PUT: solicita que o conteúdo da mensagem seja armazenado na URL especificada no servidor; 11 POST: utilizado para enviar algum recurso para o servidor. Geralmente é utilizado em formulários de páginas web; 11 DELETE: solicita que o servidor remova o recurso identificado na requisição; 11 LINK / UNLINK: conecta/finaliza a conexão existente entre dois recursos.

Cabeçalho (header) Utilizados para enviar informações adicionais

q

Não fazem parte do conteúdo da mensagem Existem quatro tipos de cabeçalhos HTTP: 11 General-header 11 Request-header 11 Response-header 11 Entity-header Os cabeçalhos são utilizados para enviar informações adicionais que não fazem parte do conteúdo da mensagem. Cada campo do cabeçalho é colocado em uma linha e o caractere “:” separa o nome do valor do campo. Existem quatro tipos de cabeçalhos HTTP. 11 General-header: informações adicionais sobre a mensagem transmitida; 11 Request-header: permite ao cliente enviar informações referentes aos formatos dos documentos esperados como resposta; 11 Response-header: permite ao servidor enviar informações adicionais que não estão

Administração de Sistemas Linux: Serviços para Internet

presentes nas informações de status;

76

11 Entity-header: utilizado para definir meta informações sobre o corpo da mensagem. A RFC2616 descreve todos os campos dos cabeçalhos HTTP.

Respostas (response) Quando um servidor recebe um pedido ele sempre envia uma resposta para o cliente. Toda resposta possui um código de status 11 Formato das respostas: [HTTP version] [Status code] [Status Message] Cabeçalhos --linha em branco— Resposta

q

Quando um servidor recebe um pedido, ele sempre vai retornar uma resposta ao cliente. As respostas são enviadas com uma linha de status que inclui a versão do protocolo, um código de sucesso ou erro seguido de uma mensagem do tipo MIME que contém os cabeçalhos e o corpo da mensagem. Exemplo: HTTP/1.1 200 OK Date: Fri, 14 Aug 2015 02:29:07 GMT Content-Type: text/html [ Outros cabeçalhos... ] ... – Inicio do conteúdo da resposta

Códigos de status Toda resposta é sinalizada com um código de status. Esse código é utilizado para informar se a requisição foi atendida ou não. Os códigos são formados por três dígitos e divididos em cinco classificações. O primeiro dígito representa a classificação e os outros dois identificam o status dentro da classificação. A tabela a seguir apresenta os principais códigos de status do protocolo HTTP. 1xx - Informação

3xx - Redirecionamento

100 Continue

300

Multiple Choices

101

301

Moved Permanently

2xx - Sucesso

302 Found

200 OK

303

See Other

201 Created

304

Not Modified

202 Accepted

305

Use Proxy

203

Non-Authoritative Information

306

204

No Content

307

205

Reset Content

206

Partial Content

Temporary Redirect

4xx - Erro no cliente

5xx - Erro no Servidor

400

500

Internal Server Error

401 Unauthorized

501

Not Implemented

402

502

Bad Gateway

403 Forbidden

503

Service Unavailable

404

Not Found

504

Gateway Time-out

405

Method Not Allowed

505

HTTP Version Not Supported

406

Not Acceptable

407

Proxy Authentication Required

Bad Request

Payment Required

Capítulo 5 - Servidor web

Switching Protocols

77

4xx - Erro no cliente 408

Request Timeout

409

Conflict

5xx - Erro no Servidor

410 Gone 411

Length Required

412

Precondition Failed

413

Request Entity Too Large

414

Request-URI Too Long

415

Unsupported Media Type

416

Requested Range Not Satis fiable

417

Expectation Failed

Testando a comunicação HTTP O netcat é uma ferramenta muito utilizada para testar a comunicação HTTP.

Tabela 5.1 Principais códigos de status do protocolo HTTP.

q

Criando uma requisição: 11 $ nc http://www.rnp.br 80 11 GET / HTTP/1.1 11 Host: www.rnp.br 11 - - linha em branco - Para os administradores de serviços, é fundamental utilizar ferramentas que permitam testar sua disponibilidade e que permita identificar de forma rápida as possíveis causas do problema. Uma ferramenta muito utilizada nos testes de comunicação entre cliente/ servidor HTTP é o Netcat, que permite simular a comunicação permitindo visualizar as respostas enviadas pelo servidor.

O Netcat é uma ferramenta utilizada para escrever dados em conexões de rede Administração de Sistemas Linux: Serviços para Internet

usando o protocolo TCP/IP.

78

Criando uma requisição # nc http://www.rnp.br 80 GET / HTTP/1.1 Host: www.rnp.br - - linha em branco - -

Resposta recebida HTTP/1.1 200 OK Date: Fri, 14 Aug 2015 16:29:36 GMT Server: Apache Etag: “1439566915-0” X-Content-Type-Options: nosniff

X-Frame-Options: SameOrigin Content-Language: pt-br Link: ; rel=”canonical”,; rel=”shortlink” Cache-Control: public, max-age=0 Last-Modified: Fri, 14 Aug 2015 15:41:55 GMT Expires: Sun, 19 Nov 1978 05:00:00 GMT Vary: Cookie,Accept-Encoding Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 9133 ...

Domínio virtual Diferentes sites são hospedados em um mesmo servidor web.

q

Exemplos: www.exemplo.com e www.exemplo.org Utilizado por grandes empresas e/ou provedores de internet. Elimina a necessidade de múltiplos servidores. Facilitando a administração do servidor web. Economia de recursos. Hardware, software e infraestrutura. Domínio Virtual (Virtual Hosting) é uma técnica que permite a hospedagem de múltiplos sites no mesmo servidor, onde cada um deles contém páginas e conteúdos diversos. Esse recurso é amplamente utilizado por grandes empresas, provedores de internet, datacenters etc. Sua grande vantagem é a eliminação da necessidade de servidores dedicados a cada um dos sites que hospeda, permitindo que uma grande empresa que possua sites diferentes associados à cada divisão e/ou produto possa agrupá-los em um único servidor, o mesmo valendo para provedores de internet e datacenters, que podem reunir em uma única máquina os diversos clientes que possui. Vantagens 11 Facilidade de administração em virtude da redução da quantidade de servidores. Requer menor quantidade de hardware e software; 11 Menor demanda de recursos de infraestrutura, como espaço físico, consumo de energia, e de refrigeração.

DNS resolver cada um dos endereços utilizados, para isso devendo possuir um alias (CNAME) para cada site hospedado.

Capítulo 5 - Servidor web

Quando é utilizado Domínio Virtual, deve-se ficar atento à necessidade de o servidor

79

Servidores web Existem vários sistemas desenvolvidos para prover o serviço web, podemos classificar

q

em dois grandes grupos: Código livre e licença GPL (ou similar): 11 Apache HTTP Server, 11 Nginx, 11 Lighttpd, 11 HTTP Explorer, 11 HFS HTTP File Server. Código fechado e licença proprietária: 11 IBM HTTP Server, 11 Internet Information Services, 11 LiteSpeed Web Server, 11 Oracle HTTP Server. Existem grandes quantidades de sistemas desenvolvidos para prover o serviço web, desde licenciamento livre e proprietário. Código livre e licença GPL (ou similar): 11 Apache HTTP Server; 11 Nginx, Lighttpd; 11 HTTP Explorer; 11 HFS HTTP File Server. Código fechado e licença proprietária: 11 IBM HTTP Server; 11 Internet Information Services; 11 LiteSpeed Web Server;

Administração de Sistemas Linux: Serviços para Internet

11 Oracle HTTP Server.

80

Aspectos relevantes para escolha do servidor web: 11 Autenticação 11 Criptografia 11 Domínio Virtual 11 Conteúdo dinâmico 11 Facilidade de adicionar funcionalidades 11 Compactação de conteúdo 11 Restrições a usuários e controle de banda 11 Modo de execução

q

Ao avaliar as soluções disponíveis, deve-se levar em consideração alguns recursos que devem ser considerados fundamentais em um servidor web, e darão peso na tomada de decisão e escolha da solução. Algumas delas são: 11 Autenticação: autentica um usuário por meio de um login e senha, com texto plano ou criptografado (HMAC); 11 Criptografia (SSL e TLS – Transport Layer Security): suporte à conexão encriptada; 11 Domínio virtual: suporte a múltiplos sites com um único endereço IP; 11 Conteúdo dinâmico (cgi-bin, Servlet, SSI, PHP e ASP): suporte à geração de páginas interativamente; 11 Módulos (carregados dinamicamente): capacidade de carregar módulos sob demanda; 11 Compressão de conteúdo: capacidade de comprimir conteúdo enviado ao usuário para economizar largura de banda; 11 Limitação de usuários e/ou largura de banda: capacidade de limitar largura de banda e/ou número de conexões inclusive por usuário, evitando saturar o servidor ou a rede; 11 Modo de execução (espaço de usuário ou núcleo do sistema): forma de acesso aos

Capítulo 5 - Servidor web

recursos do sistema, especialmente memória e processador.

81

82

Administração de Sistemas Linux: Serviços para Internet

6 Entender o que é servidor proxy, fazer a instalação e configuração do servidor Squid na versão compilada, configurar regras de acesso ACL, emitir relatório de acesso à internet usando SARG e ativar o serviço de proxy transparente.

conceitos

Proxy, solução Squid, configurações no servidor e no cliente, restrição de acesso a conteúdo, redirecionamento, autenticação, proxy transparente.

Proxy Tem por função limitar o tipo de tráfego.

q

Atua na camada de aplicação (7), analisando o conteúdo dos pacotes. Pode barrar pacotes que contenham, por exemplo, palavras inapropriadas. Diferentemente de um filtro de conteúdo que analisa tráfego baseado em camada de rede (3) ou de transporte (4). Um servidor proxy atua como um intermediário em uma rede, que recebe as requisições das máquinas cliente e as encaminha para aos respectivos servidores de destinos. Quando um cliente se conecta a um servidor proxy para solicitar uma página web ou um arquivo, o servidor avalia a requisição do cliente e decide se encaminha o pedido para o servidor de destino. Quando a requisição for respondida, o proxy encaminha a resposta para o cliente e pode armazenar uma cópia localmente para atender uma nova requisição idêntica no futuro. Existem várias aplicações de proxy disponíveis no mercado, como: Apache (utilizando o módulo mod_proxy), HAProxy, Microsoft ISA Server, Nginx, Privoxy, Squid, Varnish, WinGate, Winconnection, Tinyproxy etc. O serviço proxy tem por função limitar o tipo de tráfego que passa por ele. Instalado na borda de uma rede, efetua o monitoramento dos pacotes e, se for o caso, barra o trânsito. De modo análogo ao filtro de pacotes que, baseado na faixa de endereços IP (camada 3) ou porta (camada 4), impede o tráfego de determinadas informações, o proxy atua em camadas mais altas, podendo limitar determinados tipos de protocolos, por exemplo, o ICMP (ping). Por funcionar analisando o tráfego, pode examinar o conteúdo do pacote na camada 7 (aplicação). Um exemplo clássico é procurar nos pacotes por palavras que constem em uma

Capítulo 6 - Servidor proxy Squid

objetivos

Servidor proxy Squid

lista proibitiva, tal como “sexo”. Todo pacote que contiver essa palavra será descartado, 83

impedindo o acesso a páginas que contenham conteúdo impróprio ou estranho às necessidades da rede, seja uma rede residencial, de empresa ou de escola.

q

Web proxy cache: 11 Atua como cache. 11 Reserva uma área em memória para armazenar os conteúdos acessados com maior frequência. 11 Ao buscar uma informação que tenha sido acessada previamente, o servidor proxy cache a entrega diretamente sem buscá-la na internet.

Outra finalidade do proxy é atuar como cache. Nesse caso, o servidor reserva uma área em memória para armazenar os conteúdos estáticos acessados com maior frequência pelos usuários de rede interna. Quando o usuário busca por determinada informação, o servidor proxy cache o entrega diretamente sem acessá-lo na internet. Considere por exemplo um grande portal de notícias da internet. A primeira pessoa a acessá-lo fará com que o conteúdo dessa página fique armazenado no cache do servidor. As próximas pessoas que acessarem essa mesma página, dentro do tempo de expiração programado, vão obtero conteúdo do servidor, em vez do conteúdo da internet. Portanto, essas duas soluções apresentam, por motivos diferentes, melhoria no tráfego da rede. O proxy bloqueia o tráfego considerado inadequado pela política de utilização da rede da empresa, enquanto o cache contribui para reduzir o montante de tráfego no link externo da rede.

l Estudos prévios realizados pela Rede Nacional de Ensino e Pesquisa (RNP) indicam economia de até 35% no tráfego no link externo. Outro estudo indica que 17% do tráfego da internet já é acessado a partir de web proxy cache.

q

Acesso à internet efetuado através de um proxy. Geralmente o proxy está associado a um firewall. Funciona como filtro de conteúdo e como web proxy cache.

Internet

Servidor Proxy

Web

A utilização de um web proxy cache possibilita grande economia de recursos, com impacto Administração de Sistemas Linux: Serviços para Internet

tanto na velocidade quanto no controle de acesso.

84

Na velocidade, o impacto ocorre de duas maneiras. Na primeira, os usuários conseguem acessar as páginas mais rápido, uma vez que elas são carregadas a partir do cache, que está mais próximo do usuário. A segunda maneira é indireta e se aplica a todos os usuários que acessam dados na internet, que por estar com carga menor do que estaria sem o cache apresenta desempenho mais elevado. O controle de acesso é cada vez mais necessário, em empresas de qualquer tamanho. Com a maior penetração obtida pela internet, os benefícios proporcionados são evidentes, como: 11 Agilidade na troca de informações com outras empresas, funcionários e clientes; 11 Melhoria na comunicação pessoal; 11 Comércio eletrônico; 11 Distribuição e compartilhamento de conteúdo etc.

Figura 6.1 Funcionamento de um proxy cache.

Aliado a esses fatores, há a ampliação constante da largura de banda por parte de empresas e usuários domésticos, incentivando-os a utilizar serviços antes inviáveis. Esse cenário gera demanda sempre crescente de largura de banda. Desse modo, é extremamente necessário, em especial por parte de empresas, a definição de uma política de utilização de rede em que todos os envolvidos tenham plena consciência do modo como devem utilizar os recursos disponibilizados. Faz-se necessário o controle do registro de todos os acessos, bloqueando aqueles considerados indevidos, reduzindo o uso de largura de banda em ações estranhas às atividades da empresa, mantendo-a disponível e melhor preparada para a prática de atividades legítimas. Essa política também diminui a circulação de vírus, worms, programas piratas e outros males que apresentam riscos às empresas.

Proxy Squid O Squid é um dos proxies mais utilizados na internet.

q

Considerado simples e confiável. Praticamente obrigatório em qualquer tipo de organização com serviços de internet. De pequenas empresas aos grandes provedores de acesso. Funciona tanto como um servidor proxy quanto como um web cache. Vantagens de um proxy (entre eles o Squid): 11 Capacidade de armazenar documentos da internet. 11 Bloquear o acesso a determinadas páginas. Squid é um dos proxies mais utilizados na internet. Considerado simples e confiável, é um recurso praticamente obrigatório em qualquer tipo de organização que utilize serviços de internet, desde pequenas empresas aos grandes provedores de acesso. Foi originado de um projeto da ARPA, cujo mentor foi DuaneWessels, do NationalLaboratory for Applied Network Research, tendo posteriormente obtido a denominação de Squid. É tanto um servidor proxy quanto um web cache. Como proxy possui características especiais para a filtragem de pacotes, suportando vários protocolos, como HTTP e FTP. Pode ainda atuar como um proxy reverso, funcionando nesse caso como um acelerador para um

Mais informações podem ser obtidas na página oficial do Squid: http://www.squid-cache.org/.

A grande vantagem de um proxy (como o Squid) é a capacidade de armazenar documentos da internet. Possui também o recurso de criação de regras de acesso, que permitem ou bloqueiam o acesso a determinadas páginas. Com isso, podemos vetar a navegação em sites pornográficos, salas de bate-papo, serviços de mensagens instantâneas ou de compartilhamento de arquivos. Frequentemente é associado a um firewall, estando inclusive instalado na mesma máquina.

Capítulo 6 - Servidor proxy Squid

w

servidor web.

85

Instalação Debian/Ubuntu

q

# apt-get install squid3 RedHat/CentOS # yum install squid O Squid por ser instalado a partir do seu código-fonte ou através de pacotes compilados disponíveis nos repositórios oficiais da maioria das distribuições. Debian/Ubuntu # apt-get install squid3

RedHat/CentOS # yum install squid

Configuração O arquivo de configuração do squid.conf possui grande número de parâmetros que podem ser utilizados. Ao colocar o Squid em funcionamento pela primeira vez, é recomendável incluir os parâmetros aos poucos, especialmente as ACLs, justamente para que se possa perceber a efetividade de cada um. Nas distribuições Debian/Ubuntu, o arquivo de configuração fica localizado no diretório /etc/squid3, e nas distribuições baseadas em RedHat/CentOS, o arquivo está localizado no diretório /etc/squid.

Principais parâmetros de configuração:

q

11 http_port 11 auth_param 11 cache_mem 11 cache_dir

Administração de Sistemas Linux: Serviços para Internet

11 access_log

86

11 visible_hostname 11 acl 11 http_access Principais parâmetros de configuração: 11 http_port: número da porta utilizada pelo servidor, em geral 3128; 11 auth_param: define qual será o método de autenticação que o squid vai utilizar. 11 cache_mem: quantidade de memória RAM utilizada pelo proxy web (em MB), default 256 MB; 11 cache_dir: define vários parâmetros de cache, como tipo de armazenamento, diretório de cache, quantidade em MB, número de diretórios de primeiro nível, número de diretórios de segundo nível. Exemplo: cache_dirufs /usr/local/squid/var/cache 500 16 256;

11 access_log: localização do arquivo com logs de acesso ao conteúdo web; 11 cache_log: arquivo com informações de log; 11 cache_store_log: arquivo com detalhes sobre objetos armazenados; registra objetos que entraram e saíram, e o tempo de permanência; 11 pid_filename: arquivo que armazenará o PID do processo do Squid; 11 visible_hostname: nome do host apresentado em mensagens de erro; 11 cache_effective_user: usuário dono dos processos criados pelo Squid; 11 cache_effective_group: grupo do dono dos processos criados pelo Squid; 11 acl: cria um elemento de ACL; 11 http_access: controle de acesso para protocolo http.

Listas de controle de acesso Access Control Lists (ACLs) são regras de acesso utilizadas pelo sistema para controlar

q

quem pode acessar o que e quando. 11 As diretivas do arquivo squid.conf são lidas de cima para baixo 11 A última regra deve sempre bloquear todas as solicitações de acesso 11 Não criar regras redundantes, desnecessárias ou que exijam resolução DNS As listas de controle de acesso ou Access Control Lists (ACLs) são regras de acesso utilizadas pelo sistema para controlar quem pode acessar o que e quando. Por meio de um conjunto de regras encadeadas, permite bloquear ou liberar determinados tipos de acesso, além de limitar o consumo de banda em determinadas situações. Para um bom entendimento do funcionamento das ACLs, é necessário considerar: 11 As diretivas do arquivo squid.conf são lidas de cima para baixo. Cada solicitação de acesso é comparada com cada regra até que seja encontrada uma que combine ou até que seja atingido o final do arquivo; 11 A última regra deve sempre bloquear todas as solicitações de acesso. Desse modo, caso nenhuma regra prévia corresponda à solicitação efetuada, haverá uma última que bloqueia o acesso; 11 Não criar regras redundantes, desnecessárias ou que exijam resolução DNS, pois isso pode acabar reduzindo o desempenho do proxy; 11 Para um grande número de diretivas ou para maior flexibilidade, utilize o Squid associado a outros programas, como o Squirm, SquidGuard ou DansGuardian. As ACLs do Squid são compostas por dois elementos distintos: elemento de ACL (ACL element) por exemplo, os pacotes originados na rede 192.168.0.0/24, enquanto uma lista de acesso corresponde a permitir ou rejeitar a passagem de um pacote pelo servidor. acl rede src 192.168.0.0/24

--- elemento de ACL

http_access deny rede

--- lista de acesso

Principais tipos de elementos de ACL: 11 src: endereço IP de origem (cliente); 11 dst: endereço IP de destino (servidor);

Capítulo 6 - Servidor proxy Squid

e lista de acesso (accesslist). Um elemento de ACL é o que caracteriza um determinado pacote,

87

11 myip: útil quando o servidor possuir mais de um endereço na mesma rede, serve para determinar através de qual endereço IP o servidor recebeu o pacote; 11 arp: Ethernet (MAC) address; 11 srcdomain: nome de domínio do cliente; 11 dstdomain: nome de domínio do servidor; 11 srcdom_regex: expressão regular para nome de domínio do cliente; 11 dstdom_regex: expressão regular para nome de domínio do servidor; 11 src_as: número do Sistema Autônomo da origem (cliente); 11 dst_as: número do Sistema Autônomo do destino (servidor); 11 time: data e hora; 11 url_regex: expressão regular para URL; 11 urlpath_regex: expressão regular para URL-path, não considerando protocolos e hostnames; 11 port: porta de destino do servidor; 11 myport: número da porta local na qual o cliente se conectou; 11 myportname: nome da porta local na qual o cliente se conectou; 11 proto: protocolo de transferência (http, ftpetc.); 11 method: método HTTP (get, post etc.); 11 http_status: código de status do protocolo HTTP (200 302 404 etc.); 11 browser: expressão regular para o cabeçalho user-agent das requisições HTTP; 11 referer_regex: expressão regular para o cabeçalho http-referer das requisições HTTP; 11 ident: nome do usuário; 11 ident_regex: expressão regular para nome do usuário; 11 proxy_auth: autenticação de usuários por um agente externo; 11 proxy_auth_regex: expressão regular para autenticação de usuários por um agente externo; 11 snmp_community: string que indica o nome da comunidade SNMP; 11 maxconn: limite máximo de conexões feitas por um único endereço IP (cliente); 11 max_user_ip: limite máximo de endereços IP que um usuário pode se autenticar ao proxy;

Administração de Sistemas Linux: Serviços para Internet

11 req_mime_type: expressão regular para o cabeçalho content-type das requisições HTTP. Principais tipos de listas de acesso: 11 http_access: controla o acesso à porta http; 11 icp_access: permite que caches “vizinhos” façam requisições ao seu cache através do protocolo ICP; 11 miss_access: permite o encaminhamento (forward) através do cache do servidor; 11 no_cache: define respostas que não deverão ser armazenadas no cache; 11 always_direct: requisições que serão sempre encaminhadas diretamente aos servidores de origem; 11 never_direct: requisições que nunca serão encaminhadas diretamente aos servidores de origem; 11 snmp_access: controla acesso ao agente SNMP do squid; 11 cache_peer_access: define quais requisições serão encaminhadas a um servidor cache “vizinho”. 88

w A lista completa de elementos de ACL e listas de acesso podem ser encontrados em http://wiki.squid-cache. org/SquidFaq/SquidAcl

Baseada na URL Fazendo o uso de expressões regulares, podemos criar uma ACL que restrinja o acesso a URLs que casam com um determinado padrão. No exemplo a seguir criaremos uma ACL que vai negar o acesso a qualquer URL que termine com os caracteres “.mp3”. Isso pode ser útil para impedir o download de músicas. acl

mp3 url_regex

-i

http_access deny all

.*\.mp3$

mp3

Data e hora ACL com controle de data e hora, permitindo que determinados endereços IP acessem a internet em um intervalo de tempo determinado. Para esse exemplo precisaremos criar dois ACL elements, o primeiro chamado “usuários” para determinar a origem das requisições, enquanto o segundo, chamado “almoço”, definirá o horário e os dias da semana em que o acesso será liberado. Quando o Squid avaliar regras, os pacotes recebidos da rede 192.168.0.0/24, de segunda a sexta entre 12h00 e 13h55 serão liberados. Se os critérios dos elementos de ACL “usuários” e “almoço” não forem satisfeitos, essa regra não será executada, e o Squid vai avaliar a próxima regra que nega o tráfego http dos pacotes da rede 192.168.0.0/24. acl

usuarios

acl

almoco

src

time

192.168.0.0/24 MTWHF

http_access

allow

http_access

deny

12:00-13:55

usuarios

almoco

usuarios

Utilizando arquivos externos Podemos utilizar arquivos externos para complementar a configuração de nossas ACLs. No exemplo a seguir vamos criar o arquivo /etc/squid/ips-bloqueados.conf com uma lista de endereços IP que serão utilizados na criação do nosso elemento de ACL. Chamaremos esse elemento de ACL de bloqueados e, em seguida, utilizaremos o controle de acesso http_access para negar o acesso. O arquivo deve conter apenas um endereço IP por linha. # vi

/etc/squid/ips-bloquados.txt

192.168.0.20 192.168.0.54 192.168.0.68 acl

bloqueados src

http_access deny

“/etc/squid/ips-bloquados.conf”

bloqueados

No squid a diretiva auth_param é responsável pela configuração do esquema de autenticação do servidor e com ela podemos definir diversos métodos de autenticação. O cliente utilizará o esquema que for mais conveniente de acordo com a ordem das diretivas auth_param no arquivo de configuração. Sintaxe: auth_param

esquema

parâmetros

[configurações]

Capítulo 6 - Servidor proxy Squid

Autenticação

89

Esquemas A diretiva auth_param é responsável pela configuração do esquema de autenticação, os

q

três pricipais esquemas são: 11 Basic 11 Digest 11 Ntlm Basic É o esquema mais simples e transmite o login e a senha do usuário em texto puro ou como um conjunto de caracteres codificados em base64. Existem vários programas que podem ser utilizados pelo squid para explorar esse esquema de autenticação. Esses programas geralmente são ativados usando a diretiva --enable-basic-auth. Como exemplo podemos citar os helpers NCSA, NIS, LDAP, PAM, SASL, MSNT-multi-domain, getpwnam etc.Parâmetros específicos do esquema basic: 11 credentialsttl timetolive: define por quanto tempo a autenticação será válida; 11 casesentivive on|off: especifica se nomes de usuários serão case sensitive. Digest Mais seguro que o sistema basic, utiliza funções de hash para criptografar as mensagens envidas pelos agentes de usuário. Os programas helpers são ativados com a diretiva --enable-auth-digest. O esquema digest adiciona o conceito de ‘nonce’ (número utilizado uma vez). O nonce é um número aleatório gerado pelo squid e utilizado para melhorar a segurança na troca de mensagens. Parâmetros específicos do esquema digest: 11 nonce_garbage_interval time: intervalo de tempo em que o squid vai limpar o cache nonce; 11 nonce_max_duration time: tempo que um nonce será válido; 11 nonce_max_count número: número máximo de vezes que um nonce pode ser utilizado. Ntlm Interface de comunicação entre o squid e o protocolo NT LanMan, da Microsoft, permite que Administração de Sistemas Linux: Serviços para Internet

o navegador do cliente troque pacotes NTLMSSP com o programa autenticador até que a autenticação seja concluída. Os programas helpers são ativados através da diretiva --enableauth-ntlm. Parâmetros específicos do esquema ntlm: 11 keep_alive on|off: faz com que o squid force o fechamento das conexões iniciais durante a negociação do esquema de autenticação com o browser.

Parâmetros comuns para todos os esquemas 11 ‘program’ cmdline 11 ‘realm’ string ‘program’ cmdline

Determina o caminho completo do programa que será utilizado para realizar a autenticação. ‘realm’ string Texto que será apresentado aos usuários durante a solicitação de autenticação.

90

q

l Não é possível utilizar a autenticação em um ambiente configurado com proxy transparente. Para usufruir dessa funcionalidade será necessário que o endereço do servidor proxy e porta estejam explicitamente configurados nas máquinas cliente.

‘children’ number of children [startup=N] [idle=N] [concurrency=N] [queue-size=N] Especifica o número de processos que serão utilizados para gerenciar os pedidos de autenticação do squid. Caso todos os processos estejam ocupados, as novas requisições de autenticação ficarão em uma fila aguardando para serem atendidas. 11 startup: permite definir o número inicial de processos de autenticação; 11 idle: especifica o número de processos que devem ficar disponíveis para atender as requisições de autenticação até o limite determinado em numberofchildren; 11 concurrency: número de requisições concorrentes que cada processo poderá responder. O valor default é 0, garantindo que cada processo trate apenas uma requisição por vez; 11 queue-size: número máximo de requisições que podem ficar na fila. As requisições que ficarem por mais de trêsminutos acima do limite da fila serão abortadas pelo squid. O valor default é 2*numberofchildren. Exemplos de configuração Autenticação NTLM com controlador de domínio SAMBA. auth_param

ntlm

/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp

auth_param

ntlm

realm Proxy Squid

auth_param

digest children 20 statup=0 idle=1

auth_param

ntlm

keep_alive on

Autenticação Digest usando arquivo com login e senha. auth_param

digest

program /usr/lib/squid3/digest_file_auth

-c /etc/squid3/

password-file auth_param

digest

realm Proxy Squid

auth_param

digest

children 10 statup=0 idle=1

auth_param

digest

nonce_garbage_interval 5 minutes

auth_param

digest

nonce_max_duration 30 minutes

auth_param

digest

nonce_max_count 50

Autenticação básica usando arquivo com login e senha. auth_param

basic

program /usr/lib/squid3/basic_ncsa_auth

auth_param

basic

realm Proxy Squid

auth_param

basic

children 10 statup=0 idle=1

/usr/etc/passwd

Autenticação básica usando LDAP. auth_param

basic

program /usr/lib/squid3/basic_ldap_auth -v 3 -R -b

-f “uid=%s” -H ldap://192.168.0.1 auth_param

basic

realm Proxy Squid

auth_param

basic

children 10 statup=0 idle=1

A diretiva auth_param apenas determina como o squid vai processar a autenticação. Para que possa ser solicitada a autenticação do usuário, será necessário utilizar ACLs baseadas em login como proxy_auth, proxy_auth_regex etc. acl

autenticados

http_access

allow

proxy_auth

REQUIRED

autenticados

Capítulo 6 - Servidor proxy Squid

“dc=empresa,dc=com,dc=br” -D “cn=admin,dc=empresa,dc=com,dc=br” -w “senha-secreta”

91

Configuração dos navegadores A maioria dos navegadores do mercado tem suporte a configuração de Proxy.

q

11 Firefox 11 Internet Explorer 11 Google Chrome A maioria dos navegadores disponíveis no mercado podem ser configurados para acessar a internet através de um servidor proxy. De modo geral, por meio de uma interface de configuração, é possível informar os dados do servidor, como endereço IP e porta. 11 Mozilla Firefox: acesse o menu “Editar”> “Preferências”> “Avançado”>“Rede”, determine como o Firefox conecta-se à internet, faça a configuração manual do proxy e, finalmente, informe o endereço IP e porta utilizados; 11 Internet Explorer: entre no menu “Ferramentas”> “Opções da Internet”. Selecione a aba “Conexões” e clique no botão “Configurações da LAN”. Na janela “Configurações da Rede Local (LAN)”, na sessão “Servidor proxy”, marque a opção para usar um servidor proxy e informe o endereço IP e a porta utilizada pelo servidor proxy; 11 Google Chrome: acesse as configurações do navegador através da URL chrome://settings. Na opção “Rede”, clique sobre o botão “Alterar configurações de proxy...”. O Google Chrome utiliza as configurações de proxy do Sistema Operacional, portanto a janela de configuração padrão do sistema utilizado será aberta para a configuração.

Proxy transparente Resolve dois problemas:

q

11 Necessidade de configuração de cada navegador instalado na rede. 11 Controle de usuários mais experientes que removem as configurações do proxy, evitando assim o controle de tráfego. A utilização de proxy transparente resolve dois problemas. O primeiro é a necessidade de configuração de cada navegador instalado na rede. O segundo ocorre quando um usuário com um pouco mais de experiência remove as configurações do proxy, evitando o controle

Administração de Sistemas Linux: Serviços para Internet

de tráfego.

92

Desse modo, o uso de proxy fica oculto, e os usuários usam-no mesmo que não queiram. Facilita ainda a implementação da política de segurança, pois tira do navegador a configuração para acesso ao proxy. Todas as solicitações feitas na porta 80 são redirecionadas para o Squid, que pode então controlar o tráfego por meio das ACLs. Para configuração do proxy transparente, são necessárias três etapas: 11 Certificar-se de que o servidor Linux está com o encaminhamento de pacotes ativado (ip_forward) 11 Certificar-se de que o Squid foi compilado/instalado com suporte ao Proxy transparente 11 Incluir as regras no Iptables

q

Para configuração do proxy transparente, são necessárias três etapas: 1. Certificar-se de que o Linux está com ao encaminhamento de pacotes ativado (ip_forward) Essa funcionalidade permite que o Linux faça o encaminhamento de pacotes entre as interfaces de rede. Para verificar qual é a configuração atual do seu sistema, execute o comando a seguir: # cat /proc/sys/net/ipv4/ip_forward

O valor 0 indica que a funcionalidade está desativada e o valor 1 indica que ela está ativada. Para ativar durante a execução do sistema, faça: # echo 1 > /proc/sys/net/ipv4/ip_forward

Ou: # sysctl -w net.ipv4.ip_forward=1

Para ativar permanentemente, edite o arquivo /etc/sysctl.confe altere o valor da opção ip_forward para 1. # vi /etc/sysctl.conf net.ipv4.ip_forward=1

Para aplicar a modificação sem precisar reiniciar a máquina. # sysctl -p /etc/sysctl.conf

2. Certificar-se de que o Squid foi compilado e configurado com suporte ao proxy transparente: Se o squid foi compilado, é importante certificar-se de que a opção --enable-Linux-netfilter foi utilizada; caso contrário, será necessário recompilar o software adicionando essa opção. Para as versões instaladas a partir do repositório, essa funcionalidade já vem habilitada por padrão. Utilize o comando squid -v para verificar todas as opções que foram utilizadas na compilação do squid. Debian/Ubuntu # squid3 -v

RedHat/CentOS # squid -v

Para configurar o squid em modo transparente, devemos editar o arquivo de configuração e

http_port 3128 transparent

Salve o arquivo e reinicie o squid. 3. Incluir uma regra no firewall iptables: Incluir uma regra no firewall iptables para redirecionar o tráfego da porta 80 para o Squid (porta 3128): # Redirecionar os pacotes da porta 80 para porta 3128 iptables -t nat -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp --dport 80 -j

Capítulo 6 - Servidor proxy Squid

adicionar a opção transparent na diretiva http_port.

REDIRECT --to-port 3128

93

#Ativar o serviço de NAT iptables -t nat -I POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE

Redirecionadores Ferramentas que permitem ao administrador da rede redirecionar determinadas

q

páginas acessadas pelos usuários. Normalmente em dois casos: 11 Desvio de downloads. 11 Advertência de usuários. Os redirecionadores de URL são ferramentas que permitem ao administrador da rede redirecionar determinadas páginas acessadas pelos usuários, o que normalmente é feito em dois casos: 11 Desvio de downloads; 11 Advertência de usuários. Esses redirecionadores adicionam recursos ao Squid, que já tem entre suas funcionalidades o bloqueio a palavras e páginas proibidas. No primeiro caso o administrador, após observar grande volume de downloads de um ou mais arquivos a partir da internet, pode optar por disponibilizar esse arquivo localmente e redirecionar todos os pedidos, economizando volume de tráfego no link de internet. Um segundo exemplo ocorre quando o usuário acessa páginas com conteúdo proibido. Nesse caso, o acesso é redirecionado para uma página com advertências. Entre os redirecionadores, podemos citar: 11 Squirm: baseado em expressões regulares, rápido e com baixo consumo de memória; 11 Jesred: derivado do squirm 1.0 betaB, chega a ser de duas a três vezes mais rápido que a versão original; 11 SquidGuard: baseado em blacklists e permite autenticação em uma base dados MySQL ou LDAP;

Administração de Sistemas Linux: Serviços para Internet

11 DansGuardian: sua principal diferença está na utilização de um filtro adaptativo que

94

avalia o conteúdo das páginas acessadas e, baseado em um conjunto de regras, decide se a página será acessível ou não.

Relatórios Ferramenta fundamental para o administrador de sistemas

q

Auxilia no monitoramento do bom uso da rede Argumento para solicitação de novos recursos para infraestrutura Implementar restrições no acesso àInternet é uma ótima alternativa para impedir que os usuários utilizem a rede para fins que estão em desacordo com as políticas da empresa, entretanto, sabemos que é praticamente impossível mapear todos os endereços que devem ser bloqueados. Ora somos restritivos demais e acabamos proibindo o acesso a sites autênticos, ora somos permissivos demais, permitindo que muitos usuários acessem páginas que provavelmente estariam bloqueadas.

Em um ambiente com o squid configurado como servidor proxy, o Sarg é a principal ferramenta para geração de relatórios.

Um administrador de sistemas deve estar preocupado com a qualidade do acesso à internet na sua rede. Ele deve garantir que os recursos estão sendo utilizados da maneira mais adequada aos objetivos da empresa. Uma boa ferramenta para isso é a emissão de relatórios periódicos que permitem identificar os horários de pico de utilização, URLs suspeitas, usuários que estão fazendo mal uso dos recursos computacionais, entre outras.

Sarg Gera os relatórios baseado nos logs do servidor squid.

q

Funcionamento é simples: o sarg lê o arquivo de log do squid e gera um arquivo HTML com relatório. Informações agrupadas pelo IP ou login do usuário do squid. O Sarg (Squid Analysis Report Generator) é uma ferramenta que permite ao administrador gerar relatórios baseados nas informações armazenadas nos logs do sevidor proxy squid. Com esses relatórios, podemos identificar quais páginas foram mais acessadas pelos usuários, total de consumo de banda, data e hora do acesso, entre outras informações. O funcionamento é simples: o Sarg lê o arquivo de log gerado pelo squid (geralmente o arquivo /var/log/squid/access.log) e cria um conjunto de páginas HTML contendo as informações de relatório. As informações são agrupadas pelo endereço IP das máquinas e, caso o squid esteja configurado para exigir autenticação, o login dos usuários será exibido ao invés do endereço IP.

Instalação A instalação pode ser feita através do pacote disponível nos repositórios da distribuição ou através da compilação do código-fonte. Como existem distribuições que não possuem o pacote do sarg em seus repositórios oficiais, vamos abordar a instalação a partir do código-fonte. Para instalação a partir do código-fonte, será necessário satisfazer algumas dependências para prosseguir com a instalação. A máquina precisará teros pacotes: 11 Compilador gcc; 11 Bilioteca GD e arquivos de desenvolvimento (gd e gd-devel); 11 make; 11 autoconf; 11 perl-GD; 11 Servidor web. Obtenha a versão mais recente do sarg no site oficial: http://sourceforge.net/projects/sarg/. Descompacte o arquivo e acesse o diretório que contém o código-fonte: # tar # cd

zxvf sarg-versao.tar.gz sarg-versao

Configure o ambiente e inicie a compilação. #./configure # make # make

install

Capítulo 6 - Servidor proxy Squid

l

95

Configuração O arquivo sarg.conf contém as diretivas de configuração do Sarg. Os principais parâmetros são: LANGUAGE Permite definir qual será a linguagem dos relatórios gerados output_dir Indica o caminho onde os arquivos HTML serão gerados. Para que os relatórios fiquem disponíveis através do navegador, esse diretório deve ser acessível pelo servidor web. access_log Especifica o caminho para o arquivo de log do squid que será utilizado para gerar o relatório. Gerando os relatórios O comando sarg gera os relatórios de acesso de acordo com o arquivo de configuração. O parâmetro -d é utilizado para definir um intervalo de datas para a geração dos arquivos de relatório. Exemplo: Gera o relatório de acesso do dia 25 de outubro de 2015. # sarg -d 25/10/2015-25/10/2015

Todos os parâmetros de execução do sarg podem ser visualizados com o comando sarg -h. Caso não seja especificado um intervalo de data, o sarg vai gerar o relatório agrupando todo o período de acesso registrado no arquivo de log. Para visualizar os relatórios acesse, via browser, o diretório configurado no parâmetro output_dir no servidor web.Exemplo:

Administração de Sistemas Linux: Serviços para Internet

http://192.168.0.1/squid-reports

96

l Fique atento ao rotacionamento dos logs! Para relatórios diários, configure o rotacionamento de logs do squid para daily e deixe a última versão sem compactação. No sarg configure o parâmetro access_log para ler o arquivo de log rotacionado. Ex: / var/log/squid/access. log.1 e configure o crontab para executar o comando sarg.

7 Projetar, instalar e configurar um servidor de correio eletrônico Postfix; Entender o funcionamento do correio eletrônico e dos protocolos SMTP, POP e IMAP; Conhecer os recursos da ferramenta Postfix.

conceitos

Servidor Postfix; Teste do serviço através do Shell de comando.

Introdução O estudo deste capítulo tem como objetivo capacitar o aluno a projetar, instalar e configurar um servidor de correio eletrônico Postfix. Serão apresentados conceitos teóricos, o funcionamento do correio eletrônico e os protocolos SMTP, POP e IMAP. Em seguida, aspectos e recursos da ferramenta Postfix. Por último, veremos a parte prática envolvendo instalação, configuração e testes com o servidor de correio eletrônico Postfix, no qual são incentivadas boas práticas de configuração e administração.

Correio eletrônico Também denominado e-mail (eletronic mail).

q

Desenvolvido para permitir a troca de mensagens entre usuários por meio eletrônico. Permite o envio de arquivos anexados às mensagens. Documentos, planilhas, imagens, vídeos etc. O correio eletrônico é um dos serviços mais usados na internet, permitindo que usuários conectados em qualquer ponto da rede troquem mensagens. Através dessas mensagens podem ser enviados textos e arquivos anexados, como documentos, planilhas, imagens, vídeos e outros. É uma ferramenta extremamente importante no incremento da produtividade, pois integra e aproxima os usuários com a facilitação da troca de informações.

Capítulo 7 - Servidor de correio eletrônico (parte 1)

objetivos

Servidor de correio eletrônico (parte 1)

97

Figura 7.1 Troca de mensagem.

O protocolo IMAP4, denominado IMAP versão 4 revisão 1, é orientado à conexão e utiliza a porta TCP 143.

Origens do correio eletrônico Criado originalmente em 1965 para a troca de mensagens entre usuários de mainframes.

q

Em 1966, já permitia a troca de mensagens entre diferentes computadores. Em 1971 surgiu o símbolo @. Com o surgimento da internet, seu uso foi multiplicado. O correio eletrônico foi criado em 1965, originalmente para troca de mensagens entre usuários de computadores de grande porte. Logo foi adaptado para troca de mensagens por meio de terminais remotos. Em 1969, já com a ARPANET, surgiu o uso do símbolo @ como separador entre nome de usuário e domínio. Com a internet, a utilização do e-mail foi multiplicada, tornando-se, em conjunto com o acesso às páginas web, um dos serviços mais utilizados.

Funcionamento do correio eletrônico

q

Baseado em dois subsistemas: 11 Agente de transferência de mensagens – Mail Transport Agent (MTA). 11 Agente de usuário – Mail User Agent (MUA).

MTA1

MTA2

Administração de Sistemas Linux: Serviços para Internet

MUA1

Durante o processo de envio de mensagens são utilizados dois tipos de programas: de transporte e de usuário (também denominados respectivamente de agentes de transferência de mensagens e agentes de usuário). O primeiro tipo cuida do envio da mensagem entre a origem e o destino. O segundo permite ao usuário ler e escrever suas mensagens. Agentes de transferência de mensagens ou Mail Transfer Agent (MTA): 11 Permitem o deslocamento das mensagens da origem ao destino; 11 São os programas (daemons) que executam no ISP (provedor de internet); 11 Exemplo Sendmail, Postfix, Qmail e Exlm. Agentes de usuário ou Mail User Agent (MUA): 11 Permitem aos usuários ler e escrever suas mensagens; 11 São os programas de e-mail no computador do usuário: Eudora, Evolution, KMail, Outlook e Mozilla Thunderbird.

98

MUA2

Figura 7.2 Funcionamento do correio eletrônico.

SMTP Figura 7.3 Protocolos utilizados.

SMTP

POP3/IMAP

POP3/IMAP

Ao longo do processo de envio de uma mensagem, são utilizados alguns protocolos, tais como Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP3) e Internet Message Access Protocol (IMAP). O primeiro é utilizado na transferência de mensagens entre os MTAs, enquanto os outros dois podem ser utilizados no envio de mensagens do MUA para o MTA e vice-versa. O usuário, ao escrever sua mensagem, pode fazê-lo desconectado da rede (off-line). Para enviar suas mensagens, deve estar conectado à rede. De maneira simplificada, podemos afirmar que as mensagens são colocadas em uma espécie de caixa de entrada do servidor de correio eletrônico. O servidor de correio eletrônico fica constantemente verificando se existem mensagens a serem enviadas. Caso a mensagem seja destinada a usuários no mesmo servidor, é encaminhada a uma caixa de entrada para que sejam distribuídas para os usuários. Se a mensagem for destinada a outro servidor de correio, é solicitada uma conexão com esse servidor, sendo então encaminhada a mensagem a ele, que analogamente coloca a mensagem em uma caixa de entrada para posterior distribuição aos seus usuários.

Protocolo SMTP

q

Transfere mensagens de maneira confiável e eficiente. Não depende do subsistema de transmissão. Requer somente um meio de transmissão confiável. Orientado a conexão e utiliza o TCP. O protocolo SMTP objetiva transferir mensagens de maneira confiável e eficiente, sendo

independente do subsistema de transmissão, requerendo somente um meio de transmissão confiável. É orientado à conexão e utiliza o protocolo Transmission Control Protocol (TCP). O SMTP funciona do seguinte modo: como resultado da requisição do usuário, o SMTPdestino final, quanto um intermediário. Os comandos são gerados pelo SMTP-origem e enviados ao SMTP-destino. As respostas fazem o caminho inverso.

Figura 7.4 Protocolo SMTP.

SMTP - origem

Comandos / Respostas SMTP e mensagens (mail)

SMTP - destino

Com a conexão estabelecida, o SMTP-origem envia um comando MAIL indicando a origem da mensagem. Caso o SMTP-destino aceite, é retornada uma mensagem “OK” (código 250). O SMTP-origem envia então o destinatário da mensagem. Duas situações podem ocorrer: na primeira, se o destinatário não existir no SMTP-destino, é enviada uma mensagem de ERRO (código 550) informando que o usuário não existe. Na segunda, se o usuário existe, é enviada uma mensagem “OK” (código 250). Múltiplos destinatários podem ser aceitos. Em seguida o SMTP-origem envia o comando DATA. O SMTP-origem informa o código 354 (iniciar mensagem) e informa que a mensagem deve terminar com uma linha constando somente

Capítulo 7 - Servidor de correio eletrônico (parte 1)

-origem estabelece uma conexão com o SMTP-destino. O SMTP-destino pode tanto ser o

um ponto (.). Após o envio dos dados, o SMTP-destino confirma com “OK”. 99

Para o estabelecimento da conexão, o SMTP-origem envia uma mensagem no seguinte formato: SMTP-destino (R): 220 Service ready SMTP-origem (S): HELO SMTP-destino (R): 250

Para o encerramento: S: QUIT R: 221 ‘ Service closing transmission channel

Exemplo de uma transação SMTP: SMTP-origem (S): MAIL FROM: SMTP-destino (R): 250 OK S: RCPT TO:[email protected] R: 250 Ok S: DATA R: 354 Start mail input; end with . S: ...etc. etc. etc. S: . R: 250 Ok

A seguir são apresentados alguns códigos de reply do protocolo SMTP: 11 211 System status, or system help reply 11 220 Service ready 11 221 Service closing transmission channel 11 250 Requested mail action okay, completed 11 251 User not local; will forward to 11 354 Start mail input; end with . 11 421 Service not available, closing transmission channel 11 450 Requested mail action not taken: mailbox unavailable [mailbox busy]

Administração de Sistemas Linux: Serviços para Internet

11 451 Requested action aborted: local error in processing

100

11 452 Requested action not taken: insufficient system storage 11 500 Syntax error, command unrecognized 11 501 Syntax error in parameters or arguments 11 502 Command not implemented 11 503 Bad sequence of commands 11 504 Command parameter not implemented 11 550 Requested action not taken: mailbox unavailable [mailbox not found, no access] 11 551 User not local; please try 11 552 Requested mail action aborted: exceeded storage allocation 11 553 Requested action not taken: mailbox name not allowed [mailbox syntax incorrect] 11 554 Transaction failed

q

Protocolo POP3 Permite um cliente acessar as mensagens no servidor de modo simples.

q

11 As mensagens acessadas periodicamente são, geralmente, baixadas (feito o download para a máquina cliente) e em seguida removidas do servidor Servidor conectado à internet armazena as mensagens. Não permite muitas opções para a manipulação de mensagen Operações mais complexas são feitas pelo protocolo IMAP4. O protocolo Post Office Protocol Version 3 (POP3) surgiu para resolver um problema: estações que não estão permanentemente conectadas a uma rede IP necessitam receber e tratar suas mensagens. O protocolo POP3 é utilizado por estações para buscar suas mensagens em servidores que as estão armazenando temporariamente. No serviço POP3 existem duas entidades: 11 Cliente: quem faz uso do serviço POP3; 11 Servidor: disponibiliza o serviço POP3. Desse modo, quando um agente de usuário em um cliente deseja enviar uma mensagem a um MTA, uma conexão SMTP é estabelecida e todas as mensagens são entregues a esse MTA, responsável pelo envio. O funcionamento do protocolo ocorre do seguinte modo: 11 O servidor (POP3) em execução escuta a porta TCP 110; 11 Quando um cliente deseja utilizar o serviço, uma conexão é estabelecida com o servidor; 11 No estabelecimento da conexão, o servidor envia uma saudação; 11 Em seguida são trocados pedidos (comandos) e respostas até o fechamento da conexão. Os comandos utilizados são palavras-chave com três ou quatro caracteres de comprimento, seguidos de um ou mais argumentos, onde cada argumento possui até quarenta caracteres de comprimento. As respostas consistem em um indicador de status, de uma palavra-chave e de informações adicionais. Todas as respostas terminam com um par de . As mensagens de status são: “+OK”, quando positivas, e “-ERR”, quando negativas. As respostas podem conter múltiplas linhas. Cada linha termina com . A última linha consiste de um código decimal

Comandos POP3 Autenticação: 11 USER name; PASS string e QUIT. Transação: 11 STAT; LIST [msg]; RETR msg; DELE msg; NOOP; RSET e QUIT. Comandos POP3 (opcionais): 11 Autenticação: APOP name digest. 11 Transação: TOP msg n e UIDL [msg]. Respostas POP3: 11 +OK e -ERR.

q

Capítulo 7 - Servidor de correio eletrônico (parte 1)

046, que equivale ao caractere “.” seguido de um par de .

101

Os comandos utilizados no protocolo POP3 podem ser divididos em:

Comandos de autenticação (Authorization State) O cliente se identifica junto ao servidor: 11 USER name: identifica o usuário; 11 PASS string: senha do usuário; 11 QUIT: finaliza a sessão; 11 APOP: identifica a mailbox e a string MD5 de autorização.

Comandos de transação (Transaction State) O cliente solicita ações por parte do servidor: 11 STAT: lista o tamanho das mensagens; 11 RETR msg: solicita envio de mensagem; 11 RSET: desmarca mensagem; 11 NOOP: testa o servidor; 11 TOP msg n: lista cabeçalho e corpo da mensagem; 11 DELE msg: marca mensagem para remoção; 11 LIST [msg]: lista as mensagens; 11 UIDL [msg]: informa o identificador da mensagem; 11 QUIT: direciona para Update State.

Comandos de atualização (Update State) 11 QUIT: remove mensagens e finaliza.

Respostas 11 “+OK”: resposta positiva a comandos; 11 “-ERR”: resposta negativa a comandos.

Administração de Sistemas Linux: Serviços para Internet

Exemplo de uma sessão POP3:

102

Servidor (S): Cliente (C): S:

+OK POP3 server ready

<[email protected]> C:

APOP mrose

c4c9334bac560ecc979e58001b3e22fb S:

+OK mrose’s maildrop has 2 messages (320 octets)

C:

STAT

C:

LIST

S:

+OK 2 messages (320 octets)

S:

1 120

S:

2 200

S:

.

C:

RETR 1

S:

+OK 120 octets

S:



S:

.

C:

DELE 1

S:

+OK message 1 deleted

C:

RETR 2

S:

+OK 200 octets

S:



S:

.

C:

DELE 2

S:

+OK message 2 deleted

C: QUIT S: S: C:

+OK dewey POP3 server signing off +OK 2 320

(maildrop empty)



Protocolo IMAP Permite a um cliente acessar e manipular mensagens no servidor.

q

Atua de maneira a permitir uma manipulação da caixa postal (pastas remotas) como se fossem pastas locais. Permite: 11 criar; remover; renomear; verificar por novas mensagens; 11 incluir e remover flags; 11 realizar buscas em mensagens, cabeçalho, corpo do e-mail e outras partes. Mensagens são identificadas por números (identificador único). O protocolo IMAP, assim como o POP3, é responsável pela manipulação de mensagens entre o servidor de e-mail e o cliente. O IMAP é mais recente e possui mais funções que o POP3. O POP3 foi projetado para manipular mensagens off-line a partir de um único cliente; desse modo, efetua o download da mensagem, que em seguida é removida do servidor. Já o protocolo IMAP fornece a opção de leitura das mensagens sem necessariamente removê-las do servidor, o que permite, entre outros recursos: a leitura das mensagens a um computador portátil; utilização de webmail e acesso à conta de correio eletrônico por meio de página web. Fornece ainda uma série de recursos para manipulação de mensagens no servidor, tais como: possibilidade de criar, remover e renomear pastas; ativar ou remover marcadores (flags); Multipurpose Internet Mail Extensions (MIME) parsing; busca e seleção de mensagens por dados do cabeçalho, corpo ou anexos. Permite ainda suporte a acesso concorrente a caixas de mensagens compartilhadas. O cliente não precisa conhecer o formato utilizado para o armazenamento das mensagens. Exemplo de uma transação IMAP: 11 Uma conexão IMAP consiste em uma saudação inicial seguida por iterações feitas entre um cliente e um servidor. 11 Essas iterações possuem uma solicitação enviada pelo cliente e uma resposta enviada

q

Capítulo 7 - Servidor de correio eletrônico (parte 1)

partir de múltiplos clientes instalados, por exemplo, em um computador de escritório e em

pelo servidor. 103

q

11 Cada resposta inclui os dados solicitados e o resultado da consulta. 11 Essas iterações são linhas de texto finalizadas com um .

Conexão e estados do IMAP 1. Conexão sem pré-autenticação: OK. 2. Conexão pré-autenticada: PREAUTH. 3. Conexão rejeitada: BYE. 4. LOGIN ou AUTHENTICATE bem-sucedido. 5. Comando SELECT ou EXAMINE bem-sucedido. 6. Comando CLOSE ou falha no comando SELECT ou EXAMINE. 7. Comando LOGOUT ou desligamento do servidor ou conexão encerrada.

Conexão estabelecida

SERVER GREETING

1

2

3

NOT AUTHENTICATED

4

7

AUTHENTICATED

5

7

6

SELECTED

7

Administração de Sistemas Linux: Serviços para Internet

LOGOUT

104

Fim da conexão

Nesse arquivo, deve ser utilizado “” em vez de espaço. Para recuperar uma mensagem ou para efetuar uma entre as várias opções possíveis, é inicialmente estabelecida uma conexão TCP. Após estabelecida uma conexão, ocorre uma operação de saudação (server greeting), e em seguida a conexão muda de estado, podendo estar em: 11 server greeting: saudação inicial do servidor; 11 not authenticated (não autenticado): o cliente deve fornecer credenciais (login e senha) antes de encaminhar qualquer comando. Conexões pré-autenticadas passam diretamente ao estado seguinte;

Figura 7.5 Protocolo IMAP.

11 authenticated (autenticado): o cliente deve selecionar uma caixa de mensagens antes de emitir comandos relacionados às mensagens; 11 selected (selecionado) estado alcançado após uma caixa de mensagens ser selecionada; logout: estado alcançado após uma operação de LOGOUT do cliente ou por ações unilaterais do cliente ou do servidor. Comandos: 11 CAPABILITY: solicita lista de recursos suportados pelo servidor; 11 NOOP: utilizado para zerar algum contador de inatividade (time-out); não solicita nada; 11 LOGOUT: o cliente informa ao servidor que terminou suas atividades e deseja encerrar; 11 AUTHENTICATE: comando para iniciar autenticação (SASL) com o servidor; 11 LOGIN: utilizado para identificar o cliente, sendo informados usuário e senha em texto plano; 11 STARTTLS: comando para iniciar autenticação TLS. Comandos: 11 SELECT: seleciona uma caixa de mensagens para acessá-las; 11 EXAMINE: comando análogo ao SELECT, porém acessa mensagem em modo de leitura (read-only); 11 CREATE: cria uma caixa de mensagens; 11 DELETE: remove uma caixa de mensagens e todas as mensagens em seu interior. Não remove caixa de entrada (INBOX), somente seu conteúdo; 11 RENAME: renomeia uma caixa de mensagens existente; 11 SUBSCRIBE: adiciona uma caixa de mensagens a um servidor de notícias; 11 UNSUBSCRIBE: remove uma caixa de mensagens de um servidor de notícias; 11 LIST: efetua busca baseada em parâmetros, inclusive caractere curinga; 11 LSUB: similar ao LIST, porém utiliza os servidores de notícia; 11 STATUS: solicita o status de uma determinada caixa de mensagens; 11 APPEND: comando para adicionar informação de mensagens a uma determinada caixa de entrada;

11 CLOSE: remove as mensagens marcadas para exclusão; 11 EXPUNGE: remove as mensagens marcadas para exclusão, confirmando sequencialmente; 11 SEARCH: busca por mensagens de acordo com o critério especificado; 11 FETCH: busca dados associados com a mensagem selecionada; 11 STORE: armazena na caixa de mensagens as modificações efetuadas nas mensagens; 11 COPY: copia uma determinada mensagem para o final da caixa de mensagens de destino; 11 UID: funciona de dois modos. No primeiro em conjunto com COPY, FETCH ou STORE, efetua a operação específica sobre a mensagem. No segundo, em conjunto com SEARCH, retorna as mensagens solicitadas.

Capítulo 7 - Servidor de correio eletrônico (parte 1)

11 CHECK: solicita uma atualização (checkpoint) da caixa de mensagens atual;

105

Configurações prévias Para funcionar corretamente, o serviço de correio eletrônico depende de configuração

q

adequada de: 11 Hostname: 11 Conectividade: 11 Sincronização de relógio do sistema: 11 Log: Registro de atividades do servidor 11 DNS. Para o funcionamento correto do serviço de correio eletrônico, alguns itens do servidor devem estar adequadamente configurados. Não ajustar esses itens pode causar erros não esperados durante a operação do sistema, como o extravio ou descarte indevido de mensagens pelo MTA de origem, intermediário ou mesmo de destino. Entre os itens mais importantes estão: 11 Hostname; 11 Conectividade; 11 System Time; 11 Timestamps; 11 Log; 11 DNS.

Hostname O servidor deve possuir um endereço Fully Qualified Domain Name (FQDN).

q

É usado para a saudação a outro servidor. O servidor pode realizar uma consulta reversa ao DNS para confirmar a origem Um servidor deve possuir um endereço Fully Qualified Domain Name (FQDN), por exemplo, mail.empresa.com.br. O hostname é utilizado para saudação a outro servidor. O servidor pode estar repassando mensagens para outros servidores, que verificam o hostname efetu Administração de Sistemas Linux: Serviços para Internet

ando uma consulta reversa ao DNS, descartando a mensagem cuja origem não foi adequa-

106

damente confirmada.

Conectividade O firewall deve permitir tráfego nas portas utilizadas pelo servidor:

q

11 25 (SMTP) e 465 (SMTPS – se utilizado) 11 143 (IMAP – se utilizado) e 993 (IMAPS – se utilizado) 11 110 (POP – se utilizado) e 995 (POPS – se utilizado); O firewall deve permitir conexões de entrada e saída na porta 25 utilizada pelo protocolo SMTP.

System Time e Timestamps System Time e Timestamps: 11 relógio do sistema deve estar sincronizado através do NTP 11 Facilita a análise dos cabeçalhos e verificação de logs

q

É importante que o relógio do sistema esteja sincronizado utilizando, por exemplo, o Network Time Protocol (NTP). A utilização desse tipo de recurso facilita o processo de implantação e ajustes, principalmente ao contatar outros postmasters. Permite ainda uma melhor análise dos cabeçalhos e mensagens de log.

rsyslog Log: configurar a ferramenta para análise e diagnóstico de problemas.

q

Ferramenta do Sistema Operacional utilizada na análise e diagnóstico de problemas. O servidor Postfix utiliza log padrão do Linux. Logo, o serviço rsyslog deve estar em execução, e no arquivo de configuração devem constar entradas associadas ao servidor de mensagens. Por exemplo: Red Hat / CentOS Arquivo: /etc/rsyslog.conf mail.none; authpriv.none; cron.none

-/var/log/messages

mail.* -/var/log/maillog

Debian / Ubuntu Server Arquivo: /etc/rsyslog.d/50-default.conf mail.* -/var/log/mail.log mail.err /var/log/mail.err

DNS Servidor de e-mail deve estar registrado no DNS do domínio.

q

11 Isso possibilita que qualquer servidor na internet possa enviar mensagens a esse servidor. Três tipos de entradas que devem estar presentes no DNS: 11 A: associa um FQDN a um endereço IP. 11 PTR: associa IP ao FQDN; utilizado para autenticar mensagens. 11 MX: informa o servidor responsável pelas mensagens nesse domínio É extremamente importante estar com o serviço DNS do domínio funcionando corretaendereço do servidor de destino, assim como o servidor de destino deve efetuar uma confirmação da origem por meio de uma consulta reversa ao DNS. O servidor DNS do domínio deve possuir entradas associadas ao servidor de e-mail do domínio. Isso é necessário porque, na maior parte dos casos, o MTA do destino efetuará uma autenticação da origem verificando a autenticidade do FQDN informado. Logo, o DNS deve ser capaz de informar os servidores responsáveis por mensagens no domínio. Muitos sistemas não incluem a entrada PTR (utilizada pelo endereçamento reverso), o que acaba causando uma rejeição de mensagens, pois o MTA do destino, ao não obter o FQDN associado, descarta a mensagem supondo que ela seja spam. Outro cuidado a ser tomado é não incluir entradas CNAME ao servidor de e-mail. O protocolo SMTP exige que o servidor de e-mail seja A ou MX.

Capítulo 7 - Servidor de correio eletrônico (parte 1)

mente antes de ativar o servidor Postfix. Ao enviar mensagens, o MTA precisa resolver o

107

Havendo mais de um servidor responsável por mensagens no mesmo domínio, deve ser atribuída prioridade às entradas MX. Utilize sempre o comando dig para testar o funcionamento do servidor DNS, verificando as respostas por ele devolvidas. Exemplo: # dig mail.empresa.com.br MX ; <<>> DiG 9.2.2 <<>> mail.empresa.com.br MX ;; global options: printcmd ;; ->>HEADER<<- opcode: QUERY, status:NOERROR, id: 23929 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION ; mail.empresa.com.br.

IN

MX

;; ANSWER SECTION ; mail.empresa.com.br. 86400 IN MX 10 mail.empresa.com. br. ; mail.empresa.com.br. 86400 IN MX 20 mail2.empresa.com. br. ;; AUTHORITY SECTION 86400 IN NS mar.empresa.com.br. ; mar.empresa.com.br. ;; Query time: 10 msec ;; Server: 172.25.0.130#53

Postfix O servidor de e-mail Postfix:

q

Consiste em uma Mail Transport Agent (MTA). 11 Capaz de aceitar mensagens de outros MTAs e usuários. Possui ainda outros subprogramas (distribuição e tratamento de mensagens localmente). Consolida-se como principal substituto do Sendmail. Tem foco em velocidade, facilidade de administração e segurança.

Administração de Sistemas Linux: Serviços para Internet

O Postfix é um MTA que envia mensagens de um MUA, ou cliente de e-mail, para um servidor

108

remoto utilizando o protocolo SMTP. Pode ainda receber mensagens de outros MTA e encaminhá-las (relay) para outros MTAs. A responsabilidade do Postfix se resume a receber ou enviar mensagens para outros MTAs. A distribuição de mensagens ao usuário final, utilizando o protocolo POP3 ou IMAP, é de responsabilidade de outros servidores. Existem atualmente muitos MTAs que podem ser utilizados dependendo dos requisitos necessários, incluindo: funcionalidades; facilidade de instalação, configuração e manutenção; robustez; entre outros. A instalação e configuração do Postfix podem ser feitas de maneira intuitiva. A instalação padrão é relativamente segura e simples. Todavia, é necessário conhecer os parâmetros para ajustá-los. Recomenda-se que alguns ajustes sejam feitos antes de colocar o servidor em produção. Outros poderão ser feitos com o servidor em produção, especialmente ajustes em filtros de conteúdo e controle de spam.

Segurança e estabilidade são outras características positivas do servidor, devido ao seu arranjo modular, e ao fato de que cada componente executa com o mínimo de privilégio no sistema. Possui ainda ampla conectividade com outras aplicações, tais como: banco de dados; serviço de diretório LDAP etc. O funcionamento do Postfix é semelhante ao de um roteador quando avalia pacotes IP. Ao receber a mensagem, o Postfix avalia o destino (destinatário) e a origem (remetente) para decidir para aonde encaminhar a mensagem. Figura 7.6 Funcionamento do Postfix

Mensagem (Origem)

Figura 7.7 Conexões e mapas.

Mensagem (Destinatário)

Postfix

SMTP

SMTP LMTP

UUCP

Postfix

QMQP

local pipe

sendmail

transport

virtual

aliases

De modo análogo a um roteador, o Postfix também recebe mensagens por múltiplas origens e pode encaminhá-las também a múltiplos destinos. Uma mensagem pode chegar por meio do sendmail local, por uma conexão SMTP, Unix to Unix Copy (UUCP), ou mesmo Quick Mail Queuing Protocol (QMQP). O destino dessa mensagem pode ser uma caixa local, outro servidor SMTP, uma conexão Local Mail Transfer Protocol (LMTP), ou ainda um pipe para um programa. Para determinar se as mensagens que chegam serão aceitas, ou mesmo para determinar o método que será utilizado para encaminhar a mensagem, o Postfix faz uso dos “mapas”, que impõem permissões ou restrições baseadas na origem, destino, e mesmo no conteúdo das mensagens.

transport

aliases

.forward

resolve

local

mailbox

local rewrite “sendmail”

maildrop

Internet

RBL

pickup cleanup

incoming

active

qmgr

smtp

Internet

canonical

virtual

deferred

relocated

pipe

UUCP etc.

smtpd

access

Capítulo 7 - Servidor de correio eletrônico (parte 1)

Figura 7.8 Arquitetura do Postfix.

109

Fazem parte da arquitetura do Postfix os seguintes componentes: 11 sendmail: comando Postfix para emular o Sendmail. Mantém compatibilidade com programas que chamam por /usr/sbin/sendmail. Melhor utilizar SMTP em vez do Sendmail, por razão de desempenho; 11 maildrop: sendmail envia mensagem para maildrop queue e notifica pickup; 11 pickup: coleta a mensagem no maildrop queue, efetua o denominado sanity check e passa a mensagem ao cleanup; 11 smtpd: cuida da comunicação com outros programas de e-mail; protege o restante do sistema; 11 rewrite: age sob demanda do cleanup, reescrevendo endereços para o padrão user@fqdn; 11 cleanup: verifica formatação da mensagem e a envia para incoming queue; 11 incoming: entrada de mensagem; mensagens não prontas possuem código 0600. Mensagens prontas possuem código 0700 e são coletadas pelo qmgr; 11 active: mensagens prontas para envio, mas não necessariamente em processo de envio; 11 deferred: mensagens cujo envio falhou para, pelo menos, um dos destinatários; 11 resolve: resolve o endereço considerando transport, nexthop, destinatário e flags; 11 qmgr: parte principal do Postfix, envia tarefas para SMTP, local, LMTP e pipe; 11 local: responsável pela entrega das mensagens, utiliza o formato mbox ou maildir; 11 smtp: cliente Postfix para enviar mensagens a destinatários remotos; 11 pipe: interface de saída para outros mecanismos de transporte de mensagens.

Instalação do servidor Postfix Pré-requisitos:

q

11 Servidor Linux instalado e conectado à Internet. 11 Configurações prévias. Remover MTA pré-instalado pelo Sistema Operacional 11 Se necessário Instalação: Administração de Sistemas Linux: Serviços para Internet

11 Red Hat/CentOS: yum install 11 Debian/Ubuntu Server: apt-get install Para a instalação do servidor Postfix, é necessário um servidor com o Sistema Operacional Linux e acesso à internet. Todas as distribuições Linux já vêm com um MTA instalado, que a princípio trata apenas localmente as mensagens. O MTA que normalmente acompanha as distribuições é o Sendmail, Postfix ou Exim. O administrador do sistema pode optar por manter o programa instalado, e nesse caso modifica as configurações que permitem ao servidor executar as tarefas de envio, recebimento ou encaminhamento de mensagens oriundas ou destinadas a outras estações ou domínios. Antes de instalar o postfix, recomenda-se desinstalar o servidor anterior, caso exista. Em resumo: Red Hat / CentOS yum erase SERVIDOR_ANTERIOR yum install postfix

110

Debian/Ubuntu Server apt-get purge SERVIDOR_ANTERIOR apt-get install postfix

Inicialização do servidor Postfix Inicialização:

q

11 Red Hat/CentOS 22 root# systemclt postfix 11 Debian/Ubuntu Server 22 root# service postfix O parâmetro pode ser: start, stop, restart ou reload. Ao ser iniciado, o servidor Postfix lê as configurações do arquivo de configuração main.cf. Opcionalmente, podemos incluir configurações adicionais em outros arquivos de configuração, referenciando-os em main.cf. Para iniciar o servidor: Red Hat/CentOS root# systemclt postfix

Debian/Ubuntu Server root# service postfix

O parâmetro pode ser: start, stop, restart ou reload. O arquivo de configuração main.cf possui um conjunto de diretivas que norteiam o comportamento do servidor de e-mail Postfix. Nesse arquivo é informado se o servidor cuidará somente de mensagens locais do sistema ou de determinada rede ou domínio; os destinos permitidos para o envio de mensagens; as redes a partir das quais são aceitas mensagens; se esse servidor encaminha mensagens oriundas de outros servidores (relay) etc. O arquivo de configuração pode ser editado utilizando um editor de texto ou através do

Configuração do servidor Postfix Arquivos de configuração main.cf e master.cf Sintaxe: 11 diretiva = valor Principais diretivas de configuração: myhostname mydomain myorigin mydestination mynetworks inet_interfaces

q

Capítulo 7 - Servidor de correio eletrônico (parte 1)

comando postconf -e parâmetro=valor.

111

Único domínio O servidor de e-mail Postfix possui centenas de diretivas (parâmetros) que podem ser inseridas em seu arquivo de configuração. Não é necessário configurar cada uma delas, pois todas possuem um valor padrão (default) assumido quando a diretiva é omitida no arquivo de configuração. Cada diretiva possui o formato: parâmetro = valor. Pode ainda referenciar o conteúdo de outra diretiva: outro_parametro = $parametro. Nesse caso, o conteúdo de parâmetro será atribuído a outro_parametro. Pode ainda aceitar múltiplos valores. Exemplos: myhostname = mail.empresa.com.br myorigin = $mydomain mydestination = $myhostname localhost.$mydomain localhost $mydomain

Entre as diretivas que devem ser configuradas inicialmente estão: 11 $myhostname: nome enviado durante a saudação entre MTAs. Por padrão, é configurado com o FQDN do servidor; 11 $mydomain: domínio do sistema de e-mail, determinado automaticamente se o myhostname estiver configurado; 11 $mydestination: aceita mensagens para os domínios listados: 22 Exemplo: mydestination = $mydomain, exemplo.com.br. 11 $myorigin: domínio que aparece em mensagens enviadas a outras máquinas. Utilizado para garantir que mensagens estejam com remetente no formato FQDN; 11 $inet_interfaces: interface de rede por onde o servidor receberá as mensagens. Por padrão é configurado com o valor “all”: 22 Exemplo: inet_interfaces = $myhostname, localhost 11 $mynetworks_style: especifica de onde serão aceitas mensagens. Valores aceitos – host: quando o servidor aceita somente mensagens da máquina local; subnet: quando o servidor aceita mensagens de máquinas pertencentes à sua sub-rede; class: quando o servidor aceita mensagens originárias de servidores com endereço IP de classe igual à sua; Administração de Sistemas Linux: Serviços para Internet

11 $mynetworks: lista de clientes autorizados a efetuar relay a partir desse servidor.

112

O valor é um endereço de rede no formato Classless Inter-Domain Routing (CIDR): 22 Por exemplo: mynetworks = 192.168.0.0/24, 127.0.0.0/8 Por padrão, o Postfix armazena os e-mails no arquivo /var/spool/mail/$USUARIO ou /var/mail/$USUARIO, no formato “mbox”. Essa configuração pode ser alterada através do parâmetro $home_mailbox. Geralmente os e-mails são armazenados em:

q

11 /var/spool/mail/ ou /var/mail Comando postfix check Mapas de aliases Sempre que os arquivos de configuração forem modificados, o comando postfix check deve ser executado para verificar a sintaxe. Estando Ok, eles devem ser lidos novamente para que seus novos valores entrem em vigor. Recomenda-se utilizar nesse caso o parâmetro reload,

que faz com que o servidor leia as novas informações sem reiniciar. O parâmetro restart faz com que o servidor tenha sua execução interrompida e reiniciada, o que causa a indisponibilidade do servidor por alguns momentos. Uma configuração adicional diz respeito à associação entre contas de e-mail e contas de usuário no sistema. Normalmente, o Postfix somente entrega mensagens a usuários do sistema. Porém, usualmente podemos desejar desmembrar o nome do usuário da conta no sistema. Existem diversas razões para isso, principalmente questões de segurança e administrativas. A primeira trata da não divulgação das contas de usuário (login) na internet. A segunda é o fato de nem todos os usuários possuírem contas de e-mail. Para efetuar essa associação, devemos editar um arquivo de mapas denominado /etc/postfix/aliases, incluindo as associações desejadas. usuario1 uc0001 usuario2 uc0002 joao uc0003

Em seguida, deve-se atualizar os mapas com o comando newaliases e, na sequência, recarregar o Postfix.

Configuração do servidor Postfix com TLS SSLg TLS:

q

11 Autenticação e sessões criptografadas Para habilitar o TLS no Postfix: 11 Obter os certificados 11 Configurar os parâmetros: 22 smtpd_tls_security_level 22 smtpd_tls_auth_only 22 smtpd_tls_key_file 22 smtpd_tls_cert_file 22 smtpd_tls_CAfile 22 smtpd_tls_loglevel

22 smtpd_tls_session_cache_timeout 22 tls_random_source 22 smtp_tls_security_level O Transport Layer Security (TLS), anteriormente chamado de Secure Socket Layer (SSL), fornece autenticação baseada em certificados e sessões criptografadas. Uma sessão criptografada protege a informação que está sendo transmitida através do SMTP ou em uma autenticação SASL. Os passos necessários para habilitar o suporte ao TLS são: 11 Obter os certificados que são utilizados durante o estabelecimento da conexão TLS; 11 Adicionar os parâmetros ao arquivo de configuração do Postfix para habilitar o TLS.

Capítulo 7 - Servidor de correio eletrônico (parte 1)

22 smtpd_tls_received_header

113

Os certificados utilizados pelo Postfix são: 11 Certificado da AC: o certificado de uma Autoridade Certificadora AC é opcional. Ele é utilizado quando um cliente deseja validar o certificado emitido pelo servidor Postfix. Esse certificado pode ser de uma CA oficial ou de uma autoassinada, gerada dentro do próprio servidor; 11 Certificado público do servidor: necessário quando a conexão é estabelecida; 11 Certificado privado do servidor: é assinado pela CA e contém a chave privada do servidor. Os certificados podem ser autoassinados ou de uma CA privada, que seja amplamente reconhecida. A primeira opção é mais simples, rápida e sem custo. O inconveniente é que alguns browers podem não aceitar o certificado e uma mensagem de “certificado não confiável” é emitida aos usuários. A segunda opção é a geralmente envolve um custo. Porém, há a opção de utilizar o site StartSSL (www.startssl.com) para obter um certificado gratuito, confiável e que é aceito pela maioria dos browsers e clientes de e-mail. Os parâmetros necessários para a configuração do Postfix são: 11 smtpd_tls_security_level = VALOR: desabilitado por padrão. Se configurada com “may”, habilita o suporte ao STARTTLS para os clientes remotos, mas não obriga o uso da encriptação via TLS. Para forçar o uso do TLS, esse parâmetro deve ser configurado com o valor “encrypt”; 11 smtpd_tls_auth_only = VALOR: desabilitado por padrão. Se configurado com o valor “yes”, faz com que as autenticações SASL não sejam aceitas através de conexões não criptografadas; 11 smtpd_tls_key_file = /caminho/chave.pem: configura o arquivo com a chave RSA privada, no formato PEM, do servidor SMTP Postfix. 22 * A chave privada deve ser acessível sem uma senha, ou seja, não deve ser criptografada. 11 smtpd_tls_cert_file = /caminho/certificado.pem: configura o arquivo com o certificado RSA, no formato PEM, do servidor SMTP Postfix; 11 smtpd_tls_CAfile = /caminho/certificadoCA.pem: configura o arquivo com o certificado da CA, no formato PEM; 11 smtpd_tls_loglevel = VALOR: habilita o registro adicional, no log do Servidor SMTP

Administração de Sistemas Linux: Serviços para Internet

Postfix, das atividades TLS. Os valores possíveis são:

114

22 0 – (Valor padrão) Desabilita o log das atividades TLS; 22 1 – Registra somente uma mensagem de sumário ao completar o TLS Handshake; 22 2 – Registra também as atividades durante as negociações do TLS; 22 3 – Registra também o dump, em hexadecimal e ASCII, do processo de negociação do TLS; 22 4 – Registra também o dump, em hexadecimal e ASCII, da transmissão finalizada, após o STARTTLS; 22 * A utilização de valor igual ou maior que 2 só é recomendada em casos de problemas no funcionamento do servidor. 11 smtpd_tls_received_header = VALOR: configurada com o valor “yes”, faz com que o Servidor SMTP do Postix produza cabeçalhos de mensagens “Received:” que incluem informação sobre o protocolo e o cifrador utilizado;

11 smtpd_tls_session_cache_timeout = SEGUNDOS: especifica a validade, em segundos, do cache de informação da sessão TLS do Servidor SMTP do Postfix. Após esse tempo, uma limpeza de cache é realizada; 11 tls_random_source = dev:/dev/urandom: a fonte externa para o pool do Gerador de Número Pseudoaleatório (PRNG) do tlsmgr; 11 smtp_tls_security_level = VALOR: define o nível de segurança do TLS do cliente SMTP do Postfix. As opções mais utilizadas são: 22 none: não utilizará o TLS; 22 may: utilizará o TLS se for suportado pelo servidor SMTP. Caso contrário, utilizará o “plaintext”; 22 encrypt: obrigatoriamente utilizará o TLS. Para que o Postfix inicie o servidor SMTP ouvindo na porta 465 (smtps), é necessário descomentar ou incluir as seguintes linhas no arquivo /etc/postfix/master.cf: smtps

inet

n

-

-

-

-

smtpd

-o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=encrypt -o smtpd_reject_unlisted_recipient=no -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Para verificar se o suporte ao TLS está habilitado no servidor SMTP do Postfix, estabelecer uma conexão utilizando o telnet: # telnet localhost 25

Após estabelecer a conexão, executar o comando ehlo para verificar se o TLS está sendo oferecido pelo servidor: ehlo localhost

Na lista deve aparecer a linha 250-STARTTLS.

Usando o comando telnet: 11 # telnet localhost 25 22 >helo mail.empresa.com.br 22 >mail from: usuario1 22 >rcpt to: usuario2 22 >data 22 >E-mail de teste 22 >. 22 >quit

q Capítulo 7 - Servidor de correio eletrônico (parte 1)

Teste da entrega dos e-mails

115

É possível testar se o servidor Postfix está funcionando corretamente e entregando as mensagens, através do comando Telnet (em negrito estão os comandos smtp a serem digitados): # telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is ‘^]’. 220 ESMTP SERVIDOR helo mail.empresa.com.br ... mail from: usuario1

l

rcpt to: usuario2 data 354 End data with .

Para terminar a mensagem (comando data), é necessário digitar uma linha só com o caractere ‘.’ (ponto).

E-mail de teste . 250 Ok: queued as #QUEUE-ID quit

Testando com uma conexão TLS: Testando com uma conexão TLS

q

22 # openssl s_client –connect localhost:25 –starttls smtp 22 >mail from: usuario1 22 >rcpt to: usuario2 22 >data 22 >E-mail de teste 22 >. 22 >quit # openssl s_client -connect localhost:25 -starttls smtp ...

Administração de Sistemas Linux: Serviços para Internet

mail from: usuario1

116

rcpt to: usuario2 data 354 End data with . E-mail de teste . 250 Ok: queued as #QUEUE-ID quit

Para verificar se o e-mail foi entregue, basta executar o comando mail. Se tudo estiver Ok, o e-mail deve estar na caixa de entrada da conta. Caso o e-mail não esteja na caixa de entrada, é possível verificar a fila de e-mail e o arquivo de log do servidor. Outra forma de enviar um e-mail de teste é através do comando: echo “E-mail de teste” | mail -s Teste usuario1

Fila de e-mail e IDs da fila

q

Comando mailq Consultando informações sobre a entrega das mensagens Buscando no arquivo de log

O entendimento da fila de e-mail do Postfix é muito útil. O Postfix colocará todo e-mail que aceitou na sua fila, antes que outro processo pegue o e-mail e tente entregá-lo ao destinatário. A fila do Postfix pode ser vista através do comando mailq. Em um servidor muito ocupado, é possível ver centenas de e-mails parados por várias razões. Um exemplo pode ser visto a seguir: 04D8CA8C442

2399 Tue May 31 09:49:11

MAILER-DAEMON

(connect to mx.example.com [192.168.0.1]:25: Connection timed out) [email protected]

O “04D8CA8C442” é o ID da fila. Para descobrir o que aconteceu com esse e-mail, é possível procurar no arquivo de log: 11 Red Hat / CentOS # grep 04D8CA8C442 /var/log/mail.log

11 Debian / Ubuntu Server # grep 04D8CA8C442 /var/log/mail.log

Resultado: May 31 09:49:11 mx1 postfix/smtpd[4428]: 04D8CA8C442: client=web. localnet[10.10.41.3] May 31 09:49:11 mx1 postfix/cleanup[4473]: 04D8CA8C442: messageid=<[email protected]> May 31 09:49:11 mx1 postfix/qmgr[25512]: 04D8CA8C442: from=<>, size=2399, nrcpt=1 (queue active) May 31 09:49:41 mx1 postfix/smtp[4945]: 04D8CA8C442: to=, relay=none, delay=30, delays=0.05/0.06/30/0, dsn=4.4.1, status=deferred (connect to

Os diferentes processos do Postfix que lidam com o e-mail são exibidos após o “postfix/…”. O “smtpd” recebeu o e-mail vindo do servidor web.localnet. Então, o processo “cleanup” o coloca na fila de e-mail. O “qmgr” moveu o e-mail para a fila ativa e o “smtp” tentou entregá-lo. Não foi possível contatar o servidor remoto mx.example.com, então o Postfix manteve o e-mail na fila. O código da notificação do estado da entrega (Delivery Status Notification – DSN) foi 4.4.1. Todos os códigos começando com 4 representam erros temporários, o que significa que o Postfix tentará entregar o e-mail novamente. Os códigos começando com 5 representam erros permanentes, fazendo com que o Postfix descarte o e-mail e informe ao remetente sobre a falha na entrega. Os códigos começando com 2 representam que a entrega foi bem-sucedida.

Capítulo 7 - Servidor de correio eletrônico (parte 1)

mx.example.com [192.168.0.1]:25: Connection timed out)

117

Se a entrega tivesse sido bem-sucedida, a linha do “postfix/smtp” se pareceria com: Jun

5 12:41:10 mail postfix/smtp[12044]: 2171CA860E0: to=
com>, relay=mx.example.com[192.168.0.1]:25, delay=0.32, delays=0.04/0/0.17/0.1, dsn=2.0.0,

Administração de Sistemas Linux: Serviços para Internet

status=sent (250 2.0.0 Ok: queued as B0BAC736372)

118

8 Servidor de correio eletrônico (parte 2)

e o uso de domínios virtuais; Controlar o conteúdo, mail gateways e autenticação SMTP; Aprender as boas práticas para um servidor de e-mail corporativo e orientações para ajuste de performance; Realizar a troca do método de entrega para maildir; Configuração dos servidores POP e IMAP, além de testes com os clientes com esses protocolos.

conceitos

Configuração do serviço de entrega/maildir; Configuração do serviço de recebimento POP/IMAP; Configuração do cliente para acesso a e-mail via serviço POP.

Introdução O estudo deste capítulo visa complementar o aprendizado da administração do serviço de correio eletrônico, onde são ministrados os métodos de entrega de mensagens e o uso de domínios virtuais. São abordados o controle de conteúdo, mail gateways e a autenticação SMTP, além de recomendações de boas práticas para um servidor de e-mail corporativo, complementadas com orientações para ajuste de desempenho. Ao final, são praticados a troca do método de entrega para maildir, a configuração dos servidores POP e IMAP e testes com os clientes utilizando esses protocolos.

Métodos de entrega 11 Após receber uma mensagem, um MTA chama outra aplicação para efetuar a entrega na caixa de mensagens do usuário. 11 As mensagens destinadas a determinado usuário ficarão em sua caixa postal até que ele as recupere. 11 Existem algumas formas de armazenar as mensagens de cada usuário: 22 mbox 22 maildir

q

Capítulo 8 - Servidor de correio eletrônico (parte 2)

objetivos

Administrar o serviço de correio eletrônico, os métodos de entrega de mensagens

119

Após receber uma mensagem, um MTA chama uma aplicação que se encarregará de entregar a mensagem da caixa de mensagens do usuário apropriado. Essas mensagens ficarão disponíveis até que o usuário venha recuperá-las, através dos protocolos POP ou IMAP. As mensagens devem então ser armazenadas apropriadamente no servidor, uma vez que poderão ficar disponíveis ao usuário por tempo indeterminado. Existem várias formas de fazer isso. As mais usuais: mbox, maildir ou banco de dados relacional (SQL).

mbox Formato padrão para caixa de mensagens.

q

Mensagens de um usuário armazenadas em um único arquivo. 11 From [email protected] Qui Set 12 18:34:00 2006 11 Received: 12 Set 18:33:59 -0300 11 From: [email protected] 11 To: [email protected] 11 Subject: olá 11 Corpo da mensagem O formato mbox é o formato padrão utilizado em sistemas baseados em Unix. As mensagens de cada usuário ficam em um único arquivo, normalmente localizado em /var/spool/mail. Uma variante dessa opção é o uso do formato mbox para armazenamento das mensagens em $HOME/Mailbox, a solução mais comum e suportada pela maioria dos MUAs. O arquivo possui todas as mensagens em sequência. Cada mensagem começa em uma linha iniciada por “From”. Essa linha não faz parte do cabeçalho da mensagem utilizada pelo sistema para localizar o início de cada mensagem. Embora o mbox seja amplamente difundido no Linux e funcione adequadamente em um sistema local, não é a melhor forma de tratar mensagens em um servidor de e-mail.

Esse formato não é suportado pelo IMAP. Desse modo, o usuário fica limitado a utilizar o protocolo POP3 para recuperar suas mensagens.

Administração de Sistemas Linux: Serviços para Internet

maildir

120

Formato recomendado atualmente e suportado pelo protocolo IMAP. A caixa de mensagens

q

do usuário é organizada em várias pastas, geralmente maildir, contendo outras três pastas: 11 new 11 cur 11 tmp O maildir é o formato recomendado atualmente, por ser o mais confiável. Além disso, é o formato suportado pelo protocolo IMAP. Nesse formato a caixa de mensagens do usuário é organizada em várias pastas. Cada pasta contém as mensagens distribuídas em uma mensagem por arquivo, além de um arquivo de índice. Geralmente uma pasta denominada maildir contém outras três pastas: 11 new: para mensagens não lidas; 11 cur: para mensagens lidas; 11 tmp: para mensagens em processo de entrega.

Um dos maiores benefícios do formato maildir é a confiabilidade, em razão das mensagens estarem distribuídas uma por arquivo, podendo ser localizadas pelo arquivo de índice associado. Além disso, é compatível com o protocolo IMAP, no qual é possível: recuperar somente os cabeçalhos de cada mensagem e manipular cada pasta e as mensagens dentro dela. A simples instalação do Postfix não cria as pastas utilizadas pelo maildir. Nesse caso, existem duas opções: a primeira é usar o utilitário maildirmake, que acompanha o programa Courier Maildrop; a segunda opção é criar as pastas normalmente, o que pode ser feito de vários modos. O mais recomendado é criar as pastas com as devidas permissões em /etc/skel. Desse modo, cada novo usuário criado terá automaticamente as pastas prontas.

Servidor para múltiplos domínios Postfix pode enviar, receber e armazenar mensagens para mais de um domínio.

q

Para isso, existem dois métodos: 11 Virtual alias domains: 22 Expande o número de domínios pelo qual o servidor responde. 11 Virtual mailbox domains: 22 Cria caixas de mensagens virtuais. 22 Elimina a necessidade do usuário de possuir conta local na máquina. O método mais simples de responder por múltiplos domínios é acrescentá-los aos domínios que estão listados no parâmetro de configuração mydestination e adicionar os usuários ao arquivo /etc/passwd do Linux. Porém, se o número de usuários for muito grande, administrá-los é um problema; além disso, não é possível, para o sistema, diferenciar a que domínio pertence um usuário, pois todos serão do domínio principal. Com o uso do virtual alias domain, cada domínio virtual possui suas próprias configurações e os endereços de e-mail são direcionados tanto para contas locais como para endereços remotos. À medida que aumenta o número de domínios e consequentemente o de usuários, torna-se indesejável fornecer uma conta para cada usuário. Com o uso de virtual mailbox domains, além de não ser necessária a tradução de cada endereço de e-mail para um endereço diferente (alias), não é necessária a criação de contas no sistema Linux.

O Postfix, por padrão, reconhece como destino final somente os nomes especificados no

q

parâmetro mydestination; denominado de domínio canônico. Para domínios adicionais (virtuais), é necessário: 11 Estabelecer o alias do nome de domínio virtual. 11 Criar um mapa com os destinatários. 11 Configurar o Postfix para receber mensagens dos domínios virtuais. O Postfix reconhece por padrão, como destino final, os nomes especificados no parâmetro mydestination, o que é denominado de “domínio canônico”. Para que funcione como destino final para domínios adicionais ou virtuais, é necessário que sejam efetuadas algumas configurações adicionais: 11 Estabelecer o alias do nome de domínio virtual; 11 Criar um mapa com os destinatários; 11 Configurar o Postfix para receber mensagens dos domínios virtuais;

Capítulo 8 - Servidor de correio eletrônico (parte 2)

Domínios virtuais

11 Recarregar as configurações. 121

Estabelecer o alias do nome de domínio virtual Informar ao Postfix que é o destinatário padrão para outros domínios além do próprio do sistema. No parâmetro virtual_alias_domains, é definida o uso de um mapa com os domínios virtuais. O valor desse parâmetro é um arquivo contendo os domínios virtuais. Por exemplo: # arquivo /etc/postfix/virtual_alias_domains dominiovirtual.com 20061210

Após a criação desse arquivo, deve ser gerado um mapa indexado com o comando postmap: # postmap hash:/etc/postfix/virtual_alias_domains

Criar um mapa com os destinatários Nesta etapa deve ser criado um arquivo /etc/postfix/virtual_alias_maps com os endereços do domínio virtual. Por exemplo: # /etc/postfix/virtual_alias_maps [email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

Após a criação desse arquivo, deve ser gerado um mapa indexado com o comando postmap, conforme segue: # postmap hash:/etc/postfix/virtual_alias_maps

Configurar o Postfix para receber mensagens dos domínios virtuais Edite o arquivo de configuração main.cf, incluindo os parâmetros e valores apropriados: # /etc/postfix/main.cf virtual_alias_domains = hash:/etc/postfix/virtual_alias_domains virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

Administração de Sistemas Linux: Serviços para Internet

Recarregar configurações do Postfix

122

# /etc/init.d/postfix reload ou service postfix reload

Testando o envio de mensagem para endereço virtual # echo test | /usr/sbin/sendmail \ [email protected]

Verificando arquivo de log # tail /var/log/mail.log

Deve ser visualizado da seguinte maneira: Dez 11 11:20:50 mail postfix/pickup[17850]: B84629AB38: uid=0 from= Dez 11 11:20:50 mail postfix/cleanup[17863]: B84629AB38: messageid=<20061210092050. [email protected]> Dez 11 11:20:50 mail postfix/gmgr[17851]: B84629AB38: from=@mail.exemplo. com>, size 282, nrcpt=1 (queue active)

Dez 11 11:20:50 mail postfix/local[17866]: B84629AB38: to=, orig_to=, relay=local, delay=0, status=sent (mailbox)

Controle de conteúdo Controle de conteúdo efetuado por ferramentas embutidas ou externas.

q

11 Embutidas: resolvem problemas mais simples. 22 Restrictions: 33 Supervisiona o diálogo SMTP. 22 Checks: 33 Examina o conteúdo da mensagem e bloqueia mensagens com determinados títulos e tipos de anexos potencialmente perigosos. 11 Externas: lidam com problemas mais complexos. 22 Delegam a filtragem de mensagens a aplicações externas. 22 Onde o controle de cabeçalho e corpo da mensagem já não conseguem atuar. 22 Em geral efetuam varredura procurando por vírus ou worms e detectando spams. O assunto de controle de conteúdo em tráfego de mensagens de e-mail é bem amplo. Serão abordados neste curso apenas alguns aspectos que permitem iniciar o controle. O estudo mais aprofundado será necessário à medida que tais controles forem sendo colocados em prática. No Postfix, o controle de conteúdo pode ser dividido em duas partes: 11 Ferramentas embutidas: visam em geral resolver problemas simples; 11 Ferramentas externas: lidam com problemas mais complexos. As ferramentas embutidas efetuam dois tipos de controle: 11 Restrictions: supervisiona o diálogo SMTP, aceitando ou rejeitando mensagens com base no remetente (mail from), destinatário (rcpt), IP ou hostname. 11 Checks: examina o conteúdo da mensagem, verificando cabeçalho, corpo da mensagem, anexos e cabeçalhos de mensagens anexadas. Apesar de funcionamento relativamente simples, o administrador deve tomar cuidado com a complexidade originadas de certos tipos de programas; com determinados títulos (subject); e tipos de anexos potencialmente perigosos. 11 As ferramentas externas atuam onde o controle de cabeçalho e corpo da mensagem não conseguem atuar, em geral efetuando varredura procurando por vírus ou worms e detectando spams. Os daemons pipe, SMTP e LMTP podem delegar a filtragem de mensagens a aplicações externas. Em geral instala-se o programa amavisd-new como um intermediário entre os daemons citados e as ferramentas de antispam (por exemplo, SpamAssassin) ou antivírus. O Postfix possui um parâmetro warn_if_reject extremamente útil para avaliar o impacto de uma regra de rejeição. Esse parâmetro permite que o log registre a mensagem que seria rejeitada. Desse modo, pode-se avaliar o impacto de determinada regra sem descartar mensagens.

Capítulo 8 - Servidor de correio eletrônico (parte 2)

das expressões regulares utilizadas. Em geral é utilizado para bloquear mensagens

123

A filtragem ideal não é atingida em um primeiro momento, devendo ser implementada e

q

testada aos poucos: 11 Colocar poucas restrições e testá-las. 11 Colocar em uso somente após avaliar o impacto. 11 Parâmetro warn_if_reject para testar restrições. Observação importante: a filtragem ideal não é atingida em um primeiro momento; por isso, deve ser implementada e testada aos poucos. Devemos colocar poucas restrições, testá-las e somente depois colocá-las efetivamente em uso. É necessário ainda considerar a questão dos falsos positivos e negativos. No primeiro podemos rejeitar e-mails que a princípio não deveriam estar sendo rejeitados, e no segundo caso ocorre o inverso.

Mail gateway Também denominado smarthost.

q

11 Servidor de mensagens que conecta duas redes distintas. 11 De um lado, recebe o tráfego de mensagens da internet e, do outro, repassa as mensagens para o servidor de e-mail verdadeiro. 11 Protege o servidor tanto de conexões quanto de conteúdos maliciosos. Um mail gateway também denominado smarthost é um servidor que conecta duas redes distintas. De um lado, recebe o tráfego de mensagens da internet; do outro, repassa as mensagens para o servidor de e-mail verdadeiro. Desse modo, protege o servidor tanto de conexões quanto de conteúdos maliciosos. Para quem está na rede externa, o mail gateway aparece como o destinatário final das mensagens, já que é ele que consta nos registros DNS. Logo, todo o tráfego de mensagens que

DNS

entra na rede passa por esse servidor.

(Sistema de Nomes de Domínios, na sigla em inglês) é um sistema de gerenciamento de nomes hierárquico e distribuído com duas definições: examinar e atualizar seu banco de dados e resolver nomes de domínios em endereços de rede (IP).

Por outro lado, para a rede interna o mail gateway aparece como gateway para todas as mensagens que saem da rede. Configurando então o mail gateway para repassar somente mensagens originadas do servidor de e-mail, aliado a um firewall que bloqueie qualquer tráfego SMTP saindo da rede (exceto pelo mail gateway), temos um controle do tráfego Administração de Sistemas Linux: Serviços para Internet

SMTP de entrada e saída impedindo o servidor de e-mail de receber diretamente um ataque

124

oriundo da internet. Para isso são necessárias permissões para: 11 Servidor interno utilizar mail gateway como relay; 11 Estabelecer os domínios que farão relay para a rede interna; 11 Estabelecer o host para o qual serão feitos os relays; 11 Definir destinatários para os quais será feito relay. Para seu funcionamento, devemos: 11 Configurar servidor interno para utilizar gateway como relay. 11 Estabelecer os domínios que farão relay para a rede interna. 11 Estabelecer o host para o qual serão feitos os relays. 11 Atualizar e gerar um mapa indexado.

q

Para seu funcionamento, é preciso:

q

11 Definir destinatários para os quais será feito relay. 11 Recarregar configurações do Postfix.

1. Configurar servidor interno para utilizar gateway como relay. Deve-se adicionar no mail gateway a lista de servidores para o qual serão encaminhadas as mensagens que saem. Editar o arquivo main.cf, incluindo os endereços permitidos. mynetworks = 127.0.0.0/8 172.25.0.0/24

2. Estabelecer os domínios que serão feitos de relay para a rede interna. Configurar o mail gateway para aceitar mensagens da rede externa para o servidor interno. relay_domains = exemplo.com

3. Estabelecer o host para o qual serão feitos os relays. Configurar o mail gateway informando para qual servidor na rede interna devem ser encaminhadas as mensagens. Editar o arquivo /etc/postfix/transport: exemplo.com smtp:[mail.servidor.exemplo.com]

Após a criação desse arquivo, deve ser gerado um mapa indexado com o comando postmap: # postmap hash:/etc/postfix/transport

Definir o parâmetro transport_maps, no arquivo main.cf, ajustando a configuração: transport_maps = hash:/etc/postfix/transport

4. Definir destinatários para os quais será feito relay. Em geral um gateway repassa para o servidor interno tudo o que recebe, inclusive spams, vírus e mensagens para usuários não existentes. Para evitar esse efeito, deve ser incluído um mapa de usuários válidos. Criar o arquivo /etc/postfix/relay_recipients e inserir os registros: [email protected] OK [email protected] OK

postmap: # postmap hash:/etc/postfix/relay_recipients

5. Recarregar configurações do Postfix: # /etc/init.d/postfix reload ou service postfix reload

Capítulo 8 - Servidor de correio eletrônico (parte 2)

Após a criação desse arquivo, deve ser gerado um mapa indexado com o comando

125

SMTP autenticado Permitir o envio de mensagens sem autenticação do cliente pode facilitar o envio de

q

spam ou o abuso por parte de spammers. Existem diferentes mecanismos de autenticação, no mínimo devem ser suportados PLAIN, LOGIN e CRAM-MD5 11 Reservar a porta 25/TCP para comunicação entre MTAs 11 Usar porta 587/TCP para envio de mensagens 11 RFC4954 Normalmente, o protocolo SMTP trabalha sem utilizar autenticação e não diferencia se a conexão está sendo feita por um cliente ou por outro MTA. A falta de autenticação por parte de um cliente ao utilizar o MTA para o envio de mensagens pode facilitar o envio de spam ou o abuso por parte de spammers. Para evitar esse tipo de abuso, uma das medidas é exigir que qualquer cliente, independentemente do endereço IP de origem, apresente credenciais de acordo com a RFC 4954, a não ser que o destino da mensagem seja local. Praticamente todos os MTAs possuem recursos de autenticação, sejam nativos ou por meio de patches. Há diferenças entre os mecanismos suportados pelos vários MTAs e MUAs, mas no mínimo devem ser suportados PLAIN, LOGIN e CRAM-MD5. Os dois primeiros são considerados inseguros, pois as credenciais passam pela rede em texto claro, o que pode ser resolvido usando SMTP em canal seguro, pela porta 465/TCP. Uma configuração que é bastante efetiva contra abusos consiste em reservar a porta 25/TCP somente para troca de mensagens entre MTAs e usar a porta 587/TCP para mensagens enviadas por um cliente para o seu MTA. Costuma-se usar o termo MSA (Mail Submission Agent) para o MTA configurado para responder pela porta 587/TCP. Para o uso da porta de submissão, onde a autenticação é obrigatória, é necessário que todos os MUAs dos clientes reconfigurados para o uso da nova porta e fornecimento de credenciais. Mais informações sobre a adoção do padrão de Message Submission e a diferenciação entre os serviços de submissão e de troca de mensagens podem ser encontradas na seção

Administração de Sistemas Linux: Serviços para Internet

Gerência de Porta 25.

126

Servidores secundários É bastante comum uma rede possuir dois (ou mais) servidores de correio eletrônico destinados à recepção de mensagens: um principal, responsável por entregar as mensagens para as caixas postais dos destinatários e outros secundários que não fazem entrega de mensagens diretamente aos destinatários. Caso o servidor principal fique impossibilitado de receber mensagens, os secundários as recebem e as enfileiram, para retransmiti-las ao principal quando esse estiver restabelecido. Para evitar que servidores secundários sejam abusados por spammers, alguns cuidados devem ser tomados ao configurá-los: 11 Todas as medidas antispam adotadas no servidor principal, como SPF, greylisting etc., devem, na medida do possível, ser implementadas no servidor secundário também, de modo que o spam seja barrado igualmente em qualquer um deles;

11 O servidor secundário deve saber para quais domínios ele pode fazer relay. Esse servidor não deve ser configurado como “null relay cliente”, para evitar que sua combinação com o servidor principal forme um relay aberto de segundo nível; 11 O servidor principal deve assumir que o servidor secundário é confiável, e não fazer testes de SPF nem colocar em greylisting mensagens que venham dele. Pois se ele foi corretamente configurado, essas verificações já foram feitas. Caso seja utilizado SPF, podemos implementar SRS no servidor secundário.

Endereços especiais A RFC 2142 (Mailbox Names for Common Services, Roles and Functions) prevê um conjunto de endereços especiais, que devem ser configurados como aliases para os e-mails do pessoal responsável pelas áreas específicas. Esses endereços devem estar corretamente configurados, de acordo com o descrito na sessão sobre e-mails especiais e dados de WHOIS.

Servidor de e-mail corporativo Uma solução completa de e-mail corporativo deve considerar uma série de boas prá-

q

ticas, contendo: 11 Postfix. 11 Cyrus SASL e Dovecot SASL. 11 Courier Maildrop. 11 Courier Imap. 11 OpenLDAP. Os itens abordados até permitem a montagem de servidores de correio eletrônico que atendem a uma ampla gama de redes, que vão de algumas dezenas até várias centenas de usuários. Para ambientes em que devem ser suportados milhares de usuários e para fins de facilitar a administração, recomenda-se uma abordagem um pouco diferente. Nessa abordagem é proposta o uso de algumas ferramentas associadas ao Postfix: Cyrus SASL, Courier Maildrop, Courier Imap e OpenLDAP. Serão abordados neste curso os conceitos e a aplicabilidade dessa utilização, que em conjunto com os assuntos dos outros capítulos fornecerão subsídios para que os alunos possam Capítulo 8 - Servidor de correio eletrônico (parte 2)

posteriormente e por conta própria implementar suas próprias soluções.

127

Autentica e envia e-mail

Postfix Envia para LDA

Courier Maildrop

Valida destinatários e verifica endereço de origem

Recebe e gerencia e-mail

Cliente

OpenLDAP

Autentica destinatários

Courier IMAP

Obtém localização de mailbox e permissões Entrega para mailbox

Obtém regra para novas mensagens

Virtual

Acessa mailbox e gerencia e-mail

Figura 8.1 Servidor de e-mail corporativo.

Regras Filtro

11 Postfix: delega a autenticação do usuário para o servidor LDAP quando os usuários tentam conectar-se a ele utilizando SMTP AUTH. Quando uma mensagem chega, o Postfix consulta ainda o LDAP para verificar os usuários locais e aliases. Ao receber a mensagem, o Postfix entrega-a para o Courier Maildrop, que é o Local Delivery Agent (LDA); 11 Courier Maildrop: responsável pela entrega local das mensagens, pergunta ao LDAP pela localização das caixas de mensagens. Pode verificar ainda mensagens por meio de regras de filtragem de spam baseadas em uma pasta denominada “.spam”; 11 Courier Imap: utilizado pelo usuário que se conecta para recuperar suas mensagens. As credenciais do usuário são verificadas junto ao servidor LDAP, que ainda informa onde localizar as mensagens e os identificadores de usuário (UID) e de grupo (GID), que devem ser utilizados. O propósito de utilização do serviço de diretório OpenLDAP é evitar a necessidade de criação de conta de usuário no sistema para conta de e-mail. Utilizando contas locais baseadas em /etc/passwd, o Linux está limitado a 65.536 usuários, o que tem ainda implicações Administração de Sistemas Linux: Serviços para Internet

de segurança, pois não há associação entre contas de usuário no sistema e contas de e-mail.

Cyrus SASL e Dovecot SASL Suporte a autenticação através do Simple Authentication and Security Layer (SASL)

q

A configuração do SASL pode ser dividida em dois passos: 11 Configurar a implementação SASL para oferecer os mecanismos de autenticação desejados 11 Configurar o Postfix para habilitar a autenticação através do SASL. Os servidores SMTP precisam decidir se um cliente SMTP está autorizado a enviar e-mail para destinos remotos ou somente para os destinos que são de responsabilidade do próprio servidor. Geralmente, os servidores SMTP aceitam e-mails direcionados a destinos remotos quando o endereço IP do cliente está “na mesma rede” (rede local) do endereço IP do servidor. Os clientes SMTP que estão fora da rede do servidor SMTP precisam de uma maneira diferente para obter os mesmos privilégios dos que estão rede local. Para resolver esse problema,

128

o Postfix suporta a autenticação através do Simple Authentication and Security Layer: SASL (RFC 4954). Utilizando o SASL, um cliente SMTP pode se autenticar em um servidor SMTP remoto, lhe conferindo os mesmos privilégios de clientes que estão na rede local. O Postfix utiliza implementações existentes do SASL para conferir o suporte ao servidor SMTP. A configuração da autenticação SASL no servidor SMTP do Postfix envolve dois passos diferentes: 11 Configurar a implementação SASL para oferecer uma lista de mecanismos adequados para a autenticação e, dependendo da implementação do SASL utilizada, configurar os backends de autenticação que verificam os dados de autenticação do cliente SMTP remoto; 11 Configurar o servidor SMTP do Postfix para habilitar a autenticação através do SASL. Atualmente o Postfix suporta as implementações Cyrus SASL e Dovecot SASL. Para configurar a comunicação do Postfix com o Dovecot: 11 Instalar o pacote do Dovecot; 11 Editar o arquivo /etc/dovecot/conf.d/10-master.conf: ... service auth { ... unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } ... } ...

11 Editar o arquivo /etc/dovecot/conf.d/10-master.conf auth_mechanisms = plain login

11 Configurar o Postfix para utilizar a implementação do Dovecot, editando o arquivo main.cf com as seguintes variáveis: #Habilita a autenticacao via SASL smtpd_sasl_auth_enable = yes smtpd_sasl_type = dovecot #Defini o local do socket smtpd_sasl_path = private/auth #Habilita a interoperabilidade com os clientes SMTP remotos que implementam uma versão obsoleta do comando AUTH broken_sasl_auth_clients = yes #Nao utilizar mecanismos que permitem autenticacao anonima smtpd_sasl_security_options = noanonymous #Nao utilizar mecanismos que permitem autenticacao anonima, mesmo com TLS smtpd_sasl_tls_security_options = noanonymous

Capítulo 8 - Servidor de correio eletrônico (parte 2)

#Especifica a utilizacao do plugin do Dovecot

129

Para configurar a autenticação SASL com Cyrus no Postfix: 11 Instalar o pacote do Cyrus; 11 Editar o arquivo de configuração do SASL com o conteúdo a seguir: 22 Red Hat / CentOS - /etc/sasl2/smtpd.conf 22 Debian / Ubuntu Server - /etc/postfix/sasl2/smtpd.conf pwcheck_method: saslauthd mech_list: PLAIN LOGIN

11 Habilitar a verificação de senha através do shadows, editando o arquivo: 22 Red Hat / CentOS - /etc/sysconfig/saslauthd 22 Debian / Ubuntu Server - /etc/default/saslauthd MECHANISMS=”shadow”

* O Cyrus SASL aceita os seguintes mecanismos de autenticação: sasldb getpwent kerberos5 pam rimap shadow ldap 11 Testar a autenticação do saslauthd: testsaslauthd -u username -p password

11 Configurar o Postfix para utilizar a implementação do Cyrus, editando o arquivo main.cf com as seguintes variáveis: #Habilita a autenticacao via SASL smtpd_sasl_auth_enable = yes #Especifica a utilizacao do plugin do Cyrus smtpd_sasl_type = dovecot #Habilita a interoperabilidade com os clientes SMTP remotos que implementam uma versão obsoleta do comando AUTH broken_sasl_auth_clients = yes #Nao utilizar mecanismos que permitem autenticacao anonima smtpd_sasl_security_options = noanonymous #Nao utilizar mecanismos que permitem autenticacao anonima, mesmo com TLS

Administração de Sistemas Linux: Serviços para Internet

smtpd_sasl_tls_security_options = noanonymous

130

Para verificar se o servidor SMTP do Postfix está oferecendo suporte à autenticação SASL, estabelecer uma conexão utilizando o telnet:

# telnet localhost 25

E executar o comando ehlo para verificar os serviços oferecidos pelo servidor:

ehlo localhost

Na lista, deve constar uma linha com “250-AUTH PLAIN LOGIN”. Com a configuração correta, o cliente consegue se autenticar. Após a autenticação do utilizando o SASL, o servidor SMTP do Postfix pode decidir o que o cliente SMTP remoto possui autorização para fazer, como por exemplo enviar um e-mail para um destinatário remoto. Essa permissão não está habilitada por padrão.

Configurando o filtro permit_sasl_authenticated na restrição smtpd_recipient_restrictions, no arquivo main.cf, permite que os clientes SMTP autenticados via SASL enviem e-mails para destinatários remotos. Exemplo: ... smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, ...outras regras… ...

Courier Maildrop 11 Agente local para a entrega de mensagens.

q

11 Recebe mensagens do Postfix e as armazena em caixas de mensagens no formato maildir. 11 Pode ainda aplicar filtros nas mensagens. Courier Maildrop é um agente local para a entrega de mensagens que recebe mensagens de um agente de transporte (Postfix) e armazena-as em caixas de mensagens no formato maildir. Pode ainda aplicar filtros nas mensagens. Um recurso adicional interessante é o uso conjunto com cotas em diretórios, uma vez que nesse formato as mensagens de cada usuário ficam em diretórios separados. A instalação do Courier Maildrop exige a criação de usuário e grupo específicos: # useradd -u 1003 vmail # groupadd -g 1003 vmail

Para efetuar a instalação, utilize as seguintes opções quando for construí-lo: #./configure --enable-restrict-trusted=1 --enable-trusted-users=‘root vmail’ --enable-trusted-groups=‘root vmail’ --enable-maildirquota --enable-trashquota --enable-maildropldap

Após essa etapa, execute os comandos make install-strip e install-man para instalar os binádo Postfix (que não executa como root): # chmod 750 /usr/local/bin/maildrop # chmod u+s /usr/local/bin/maildrop # chown root:vmail /usr/local/bin/maildrop

Courier Imap Oferece os serviços: 11 POP. 11 POP-SSL. 11 IMAP. 11 IMAP-SSL. Suporta o formato maildir.

q

Capítulo 8 - Servidor de correio eletrônico (parte 2)

rios e o manual. Efetue ainda os seguintes ajustes de permissão em razão do daemon pipe

131

Courier Imap suporta o formato maildir e oferece os serviços POP, POP-SSL, IMAP e IMAP-SSL para os clientes que a ele se conectam para manipulação das mensagens. Para a instalação, utilize as seguintes opções quando for construí-lo: #./configure --enable-workarounds-for-imap-client-bugs --enable-unicode --withoutauthpgsql --without-socks --with-redhat make

O parâmetro --with-redhat deve ser utilizado somente em distribuições baseadas em Red Hat. Em seguida, execute os comandos make install e install-configure. É necessária ainda a criação dos certificados para autenticação, que pode ser feita manualmente ou por meio do utilitário mkimapdcert, executado automaticamente ao iniciar o imapd-ssl.

Recomendações de tuning 11 Ajustes básicos.

q

11 Identificação de gargalos. 11 Ajustes para alto volume de tráfego. O Postfix é rápido, e essa é uma de suas principais características. Todavia, como muitos outros programas, pode ter seu desempenho aumentado com alguns ajustes. Além disso, algumas situações, como limitações de hardware, software ou flutuações bruscas (como um pico no volume de spam) podem afetar sua performance. Entre os ajustes básicos, alguns itens sempre merecem ser verificados para maior garantia de ausência de problemas inesperados. Podemos citar: ajustes em consultas DNS; verificar se o servidor está atuando como relay, recusando mensagens para usuários inexistentes, bloqueando mensagens oriundas de redes da lista negra ou reduzindo a frequência de retransmissões. Gargalos afetam o desempenho do sistema, eventualmente sobrecarregando o servidor e causando nos usuários a percepção da ocorrência de problemas. Ao chegar ao servidor, durante seu processamento, uma mensagem é movida de uma fila para outra. As filas são: 11 Incoming: todas as mensagens que entram são colocadas nessa fila pelo daemon clean, e quando ficam prontas, o qmgr é notificado;

Administração de Sistemas Linux: Serviços para Internet

11 Deferred: mensagens que já foram enviadas a alguns destinatários, mas com falha para

132

um ou mais destinatários, aguardam nessa fila por nova varredura do qmgr; 11 active: mensagens nessa fila estão prontas para envio, mas ainda não foram enviadas; 11 maildrop: aguardam nessa fila mensagens enviadas pelo comando sendmail e que ainda não foram enviadas para as filas do Postfix pelo daemon pickup. Para alto volume de tráfego, considere utilizar um servidor em separado para mensagens que chegam. Separe ainda, se for o caso, a máquina que efetua filtragem de vírus, desabilitando nessa máquina consultas DNS, uma vez que ela encaminhará as mensagens sempre para um mesmo destino.

Ajustes em consultas DNS DNS deve estar funcionando adequadamente.

q

11 Efetuar teste com o comando dig. Verificar: 11 Arquivo resolv.conf. 11 Saturação de tráfego na rede. 11 Configurações do firewall. 22 Disponibilização de um servidor cache DNS. Quando o sistema possui alto volume de tráfego, é importante que o DNS esteja configurado adequadamente, sobretudo se a verificação de origem através do Fully Qualified Domain Name (FQDN) está sendo efetuada. Utilize o comando dig para efetuar uma consulta DNS. Recomenda-se efetuar esse teste duas vezes verificando o tempo de resposta na primeira e segunda consultas. Os valores obtidos variam de rede para rede; no entanto, no primeiro teste o valor deverá ser superior a 100 ms, enquanto que em uma segunda consulta deverá ficar por volta de 10 ou 20 ms, indicando que o servidor DNS está efetuando cache corretamente. Persistindo os problemas, verifique: 11 As configurações do arquivo resolv.conf, principalmente os servidores indicados na diretiva nameservers; 11 Problemas de tráfego na rede; caso a rede esteja saturada, verifique a possibilidade de otimizar o uso da banda, ou mesmo priorizar o tráfego dos servidores DNS; 11 Configurações do firewall; 11 Disponibilização de um servidor cache DNS caso o servidor DNS esteja sobrecarregado ou não esteja no mesmo segmento de rede do servidor de e-mail e se queira aliviar o tráfego na rede e melhorar o tempo de resposta. Verificar se o servidor está atuando como relay.

q

11 Carga desnecessária no servidor e na rede. 11 Servidor acabará incluído em listas negras.

11 Listados no parâmetro mynetworks. 11 Autenticados via SMTP. 11 Autenticados com certificados TLS. Verifique se o servidor não está atuando como um relay aberto. Deixar o servidor efetuando relay de qualquer origem é extremamente prejudicial, pois além de submeter o servidor de e-mail a uma carga desnecessária, essa atitude fará com que o servidor acabe sendo incluído em listas negras (black lists), fazendo com que as mensagens legítimas da rede sejam recusadas por muitos destinos. Permita somente o envio de mensagens de clientes listados no parâmetro mynetworks no arquivo de configuração; de clientes autenticados via SMTP e de clientes que se autentiquem utilizando certificados TLS.

Capítulo 8 - Servidor de correio eletrônico (parte 2)

Permita o envio de mensagens somente de clientes:

133

Recusando mensagens para usuários inexistentes.

q

11 Servidor deve recusar mensagens para usuários inexistentes. 22 Caso aceite, enviará mensagens com notificações de não entrega de mensagens, causando acúmulo de mensagens na fila de saída. 11 Configure os parâmetros: 22 local_recipient_maps 22 relay_recipient_maps Configure o servidor para recusar mensagens de usuários inexistentes. Caso o Postfix aceite esse tipo de mensagem, o sistema acabará enviando mensagens com notificações de não entrega de mensagens (undeliverable messages), causando acúmulo de mensagens na fila de saída. Além disso, essas mensagens ocuparão grande espaço no sistema. Outra questão surge quando o servidor está atuando como relay; nesse caso, o servidor de destino acabará enviando de volta mensagens (bounce) não entregues, utilizando o Return-Path do cabeçalho. Para esses ajustes, configure os parâmetros local_recipient_maps e relay_recipient_maps (caso o servidor esteja atuando como relay para outro servidor na rede interna). Caso o servidor esteja recebendo muitas mensagens de volta (bounce), e isso esteja se tornando um problema, verifique na internet a lista de servidores que não aceitam suas mensagens de volta. Caso o servidor esteja nessa lista, inclua-o em sua lista negra, o que pode ser feito automaticamente com o parâmetro: check_rhsbl_sender dsn.rfc-ignorant.org

Bloqueando mensagens oriundas de redes da lista negra.

q

11 Existem atualmente vários tipos de listas negras, inclusive de DNS. 22 A utilização de listas reduz a carga de spam no servidor. Reduzindo a frequência de retransmissões. 11 Quando há grande número de mensagens não entregues na primeira tentativa: 22 Usar um relay para fallback.

Administração de Sistemas Linux: Serviços para Internet

22 Aumentar o tempo entre as tentativas.

134

Existem atualmente vários tipos de listas negras, inclusive de DNS, que listam endereços IP, faixas de endereços IP ou mesmo domínios. Essas listas contêm poucos falsos positivos em razão dos critérios utilizados para inclusão. A utilização dessas listas fará com que o servidor receba carga menor de spam. Outra questão surge quando o servidor tem grande número de mensagens que não são entregues na primeira tentativa. Existem duas alternativas: 11 Usar um relay para fallback; delega tentativas malsucedidas a outro servidor, que se encarrega desse tipo de mensagem; 11 Aumentar o tempo entre as tentativas pelo parâmetro maximal_backoff_time para diminuir a frequência com que uma mesma mensagem entra novamente na fila de saída. Faz com que tentativas de envio de mensagens a servidores que estejam fora do ar sejam feitas em intervalos maiores.

Gargalos na incoming queue Lentidão em consultas externas. Exemplo: LDAP.

q

As mensagens que chegam são colocadas nessa fila pelo cleanup com permissão 0600 até que estejam completas e prontas para processamento, quando sua permissão é alterada para 0700. Em condições normais a fila incoming quase não possui mensagens 0600. Caso ocorram picos de recebimento de mensagens anterior da capacidade do qmgr, essa fila pode crescer consideravelmente. Nesse caso, o que pode estar retardando o qmgr é o serviço trivial-rewrite, sobretudo por lentidão nas consultas LDAP ou SQL. Evite que uma quantidade excessiva de mensagens seja entregue via pickup. Caso necessário, utilize opções alternativas de injeção de mensagens por meio de programas como mini_sendmail.

Gargalos na maildrop queue Retardo decorrente de excesso de mensagens ou de consumo excessivo de CPU devido

q

às verificações do pickup. Mensagens enviadas pelo comando sendmail e ainda não coletadas pelo daemon pickup permanecem na fila maildrop. Mensagens enviadas pelo comando sendmail mesmo com o Postfix fora de execução vão para essa fila. O pickup periodicamente verifica essa fila ou realiza a verificação quando é notificado da chegada de novas mensagens pelo postdrop. Executando em uma única thread, processa somente uma mensagem por vez, verificando cabeçalho, corpo e outras informações, demandando muito processamento de entrada e saída de disco. Retardos causados nessa fila são decorrentes de excesso de mensagens ou consumo excessivo de CPU devido às verificações do pickup. Convém observar que quando a fila active estiver cheia, o cleanup diminui a injeção de mensagens. A fila active possui limite de 20 mil mensagens.

Gargalos na deferred queue Havendo grande volume de mensagens nessa fila, podemos tentar ajustar diminuindo o

q

tempo mínimo e aumentando o tempo máximo das mensagens, agilizando o envio de men-

Quando o Postfix não consegue entregar a mensagem para algum dos destinatários, esta é colocada na fila deferred. O qmgr verifica periodicamente a fila conforme especificado no parâmetro queue_run_delay. Uma fração das mensagens é periodicamente reinjetada na fila active de acordo com o tempo de espera, que varia entre os valores de minimal_backoff_time e maximal_backoff_time, respectivamente o tempo mínimo e máximo que cada mensagem aguarda antes de ser recolocada para envio. Cada nova tentativa dobra o tempo de vida da mensagem na fila. Mensagens com tempo menor possuem tentativas mais frequentes e mensagens mais antigas têm tempo maior entre as tentativas. Havendo grande volume de mensagens nessa fila, pode ser feita a tentativa de ajuste diminuindo o tempo mínimo e aumentando o tempo máximo das mensagens, o que agiliza um pouco o envio de mensagens com pouco tempo na fila sem provocar muitas tentativas para todas as mensagens.

Capítulo 8 - Servidor de correio eletrônico (parte 2)

sagens com pouco tempo na fila, sem provocar muitas tentativas para todas as mensagens.

135

Gargalos na active queue 11 Quando o destino funciona a uma velocidade muito menor, causa acúmulo nessa fila.

q

11 Caso a fila active esteja realmente lenta: 22 Reduzir a injeção de mensagens nessa fila. 22 Aumentar o throughput incrementando a concorrência (quantidade de processos SMTP em execução) ou reduzindo a latência (melhorias no DNS, mapas). O qmgr tenta enviar cada mensagem dessa fila para seu destino. Quando o destino funciona com velocidade muito menor, provoca certo acúmulo nessa fila. Caso o destino saia do ar por alguns momentos, o qmgr considera esse destino como morto e transfere todas as mensagens para deferred, o que libera a fila active, mas entrega muitas mensagens na fila deferred. Caso a fila active esteja realmente lenta, existem dois modos de resolver o problema: reduzir a injeção de mensagens nessa fila ou aumentar o throughput. Para aumentar o throughput pode ser incrementada a concorrência (quantidade de processos SMTP em execução) ou reduzida a latência (melhorias no DNS, mapas).

O aumento da concorrência pode ser feito pela modificação do valor no parâmetro default_process_limit no main.cf. Para modificação baseada no destinatário, utilize o utilitário qshape, que apresenta na forma de uma tabela o total de mensagens na fila baseadas no destinatário. Podem ser utilizados os comandos: # qshape -s hold # qshape deferred # qshape incomming active deferred

Por último, deve-se evitar recarregar ou reiniciar o servidor, quando possível. Apesar de a fila active em memória estar vazia, a fila active em disco pode conter muitas mensagens, que são devolvidas à fila incoming, demandando muito consumo de memória.

Práticas Antispam Administração de Sistemas Linux: Serviços para Internet

Restrições do servidor SMTP do Postfix

136

Blacklists, Realtime blacklists e Graylists Sender Policy Framework (SPF) Para tentar combater os spams no servidor de e-mail, as seguintes atividades podem ser adotadas: O Postfix fornece a habilidade de aplicar alguns filtros durante a sessão SMTP. Quando um e-mail chega ao servidor SMTP, ele passa pelas seguintes etapas: 11 CLIENT: conexões TCP chegando através da porta 25; 11 HELO: o servidor de e-mail que está enviando a mensagem informa o seu nome; 11 MAIL FROM: o nome e o endereço de e-mail do remetente; 11 RCPT TO: o destinatário do e-mail; 11 DATA: nessa etapa da sessão SMTP, o e-mail é enviado; 11 QUIT: fim da sessão SMTP.

q

Através da configuração das restrições do Servidor SMTP do Postfix é possível controlar quais verificações serão realizadas quando um e-mail é recebido. Essas restrições são definidas no arquivo de configuração main.cf, através dos parâmetros: 11 smtpd_client_restrictions (Valor padrão: vazio) 11 smtpd_helo_restrictions (Valor padrão: vazio) 11 smtpd_sender_restrictions (Valor padrão: vazio) 11 smtpd_recipient_restrictions (Valor padrão: permit_mynetworks, reject_unauth_destination) 11 smtpd_data_restrictions (Valor padrão: vazio) Esses parâmetros aceitam uma lista de restrições, separados por vírgula. Algumas das restrições mais utilizadas para cada filtro são: 11 reject_unknown_client_hostname: filtro aplicado à restrição do cliente que rejeita uma conexão quando, através de uma consulta DNS, o IP do cliente não confere com o seu hostname; 11 reject_non_fqdn_helo_hostname: filtro aplicado à restrição do comando HELO que rejeita a requisição quando o hostname apresentado durante o HELO ou EHLO não é um FQDN; 11 reject_invalid_helo_hostname: filtro aplicado à restrição do comando HELO que rejeita a requisição quando o hostname apresentado durante o HELO ou EHLO for malformado; 11 reject_unknown_helo_hostname: filtro aplicado à restrição do comando HELO que rejeita a requisição quando o hostname apresentado durante o HELO ou EHLO não possui um registro A ou MX no DNS; 11 reject_non_fqdn_sender: filtro aplicado à restrição do remetente que rejeita o e-mail quando o endereço presente no “MAIL FROM” não está no formato FQDN; 11 reject_unknown_sender_domain: filtro aplicado à restrição do remetente que rejeita o e-mail quando o domínio presente no “MAIL FROM” não possuir um registro A e MX no DNS; 11 reject_unauth_destination: filtro aplicado à restrição do destinatário que rejeita o e-mail quando o domínio presente no “RCPT TO” é destinado a um domínio que não é hospedado pelo servidor Postfix, ou seja, que não está configurado nos parâmetros relay_domains, mydestination, virtual_alias_domains ou virtual_mailbox_domains; 11 reject_non_fqdn_recipient: filtro aplicado à restrição do destinatário que rejeita o e-mail quando o domínio presente no “RCPT TO” não está no formato FQDN;

o e-mail quando o domínio presente no “RCPT” não possuir um registro A e MX no DNS; 11 reject_unauth_pipelining: rejeita o e-mail quando o cliente envia comandos SMTP antes do tempo.

Para as restrições de HELO funcionarem, é necessário configurar o parâmetro smtpd_helo_required com o valor “yes”. As blacklists são listas que possuem os endereços IP de servidores responsáveis por enviar spams. É possível configurar o Postfix, através do filtro reject_rbl_client na restrição smtpd_ recipient_restrictions, para consultar diversas blacklists remotas em tempo real, chamadas de Realtime Blacklists (RBL). Alguns exemplos de RBLs: 11 www.spamhaus.org: reject_rbl_client zen.spamhaus.org

Capítulo 8 - Servidor de correio eletrônico (parte 2)

11 reject_unknown_recipient_domain: filtro aplicado à restrição do destinatário que rejeita

11 www.barracudacentral.org: reject_rbl_client b.barracudacentral.org 137

11 www.sorbs.net: reject_rbl_client dnsbl.sorbs.net 11 www.spamcop.net: reject_rbl_client bl.spamcop.net O Sender Policy Framework (SPF) é uma medida para prevenir o spoofing (falsificar, mascarar) do endereço de origem, ou seja, algum servidor configurado de forma mal-intencionada para se passar por outro. Para utilizar o SPF, é criado um registro no DNS do domínio informando uma lista de endereços IPs válidos que são permitidos enviar e-mail em nome do domínio. Dessa forma, qualquer um pode verificar se o e-mail foi enviado de um endereço IP (servidor) válido e com permissão para atuar como servidor de e-mail para o domínio. Um exemplo de um registro SPF no DNS: empresa.com.br.

IN

TXT

“v=spf1 a mx ip4:192.0.2.32/27 -all”

Nesse caso, a política estabelece que pode enviar mensagens em nome do domínio empresa.com.br umamáquina que satisfaça um dos seguintes critérios: 11 Seu endereço IP deve ser um RR tipo A do domínio empresa.com.br (a); 11 Seja designada como MX do domínio empresa.com.br (mx); 11 Pertença ao bloco de endereços IP 192.0.2.32/27 (ip4). A cláusula “-all” diz que devem ser recusados (“-”, prefixo Fail) e-mails partindo de qualquer outro endereço IP (all). As opções de prefixos são: 11 “+” Pass 11 “-” Fail 11 “~” SoftFail 11 “?” Neutral Para fazer com que o servidor SMTP do Postfix verifique o SPF, é necessário instalar o pacote postfix-policyd-spf-python, configurar o filtro check_policy_service da restrição smtpd_recipient_restrictions com o valor unix:private/policyd-spf e incluir a seguinte seção no arquivo master.cf do Postfix: policy-spf

unix

-

n

n

-

-

spawn

Administração de Sistemas Linux: Serviços para Internet

user=nobody argv=/usr/bin/policyd-spf

138

O graylisting é outra forma de reduzir a quantidade de spam recebida. Ele é um intermediário entre o whitilist (sempre aceitar e-mails de determinadas origens) e blacklist (sempre recusar e-mails de determinadas origens), que recusa receber o e-mail durante alguns minutos. Os servidores que estão enviando spams apenas tentam entregar o e-mail de spam uma única vez. Porém, os servidores legítimos de e-mail possuem uma fila de saída de e-mail e, quando recebem um código erro temporário, tentam enviar o e-mail novamente. Se é o servidor que está enviando um e-mail ao destinatário pela primeira vez, então o mecanismo de greylist retornará um código de erro temporário (delivery status 4.x.x), que informa ao servidor do remetente para tentar enviar o e-mail novamente após alguns minutos. O servidor de destino registrará o endereço IP do servidor remetente e, após um determinado período (geralmente 10 minutos), o bloqueio é removido e a próxima vez que o e-mail for enviado ele será aceito. O lado negativo do greylist é que há um atraso na entrega dos e-mails.

lMais informações sobre o SPF em www. antispam.br/admin/spf e www.openspf.org.

Para implementar o greylisting no servidor SMTP do Postfix, é necessário instalar o pacote postgrey, configurar o filtro check_policy_service da restrição smtpd_recipient_restrictions com o valor inet:127.0.0.1:10023, configurar o postgrey para iniciar na porta 10023 (POSTGREY_OPTS=”--inet=10023”) no arquivo: 11 Red Hat / CentOS:

O Antispam.br (http://antispam.br), site mantido pelo Comitê Gestor da Internet no Brasil (CGI. br), constitui uma fonte de referência sobre o spam, além de possuir várias informações úteis, como boas práticas, no combate ao spam.

/etc/sysconfig/postgrey

11 Debian / Ubuntu Server: /etc/default/postgrey

Por final, iniciar o serviço do postgrey: 11 Red Hat / CentOS: systemctl restart postgrey

11 Debian / Ubuntu Server service postgrey restart

Recomendações do Antispam.br Relay aberto

q

Restringir ao máximo os endereços IP que tem permissão para usar o servidor como relay Podemos utilizar o comando telnet para verificar se o Relay está aberto no servidor. $ telnet mailserver.example.com 25 Trying 192.0.2.8 Connected to mailserver.example.com. …

Relays abertos Relays abertos são MTAs que transmitem mensagens de qualquer domínio, ou mesmo só de domínios determinados, para qualquer outro, sem pedir autenticação, sem restringir (ou restringindo muito pouco) a faixa de endereços IP de origem. Os relays abertos são utilizados por spammers pelo fato de proverem anonimato. Para o responsável pelo MTA com relay aberto sendo abusado, as consequências são o consumo de recursos e a possível inclusão do MTA em listas de bloqueio. Além disso, ele pode passar a receber mensagens de erro e reclamações sobre os spams enviados via seu MTA. Os softwares atuais para servidores MTA costumam vir em sua maioria configurados por padrão para não aceitar a transmissão indiscriminada de mensagens. Normalmente esses softwares permitem a manutenção de uma lista de domínios pelos quais um determinado MTA responde e uma lista de endereços autorizados a usar seu relay. É importante, ao configurar um MTA, restringir ao máximo os endereços IP que têm permissão para usá-lo como relay, se possível limitando ao localhost. Há também casos em que dois MTAs, aparentemente bem configurados, agem como se fossem um relay aberto. A mensagem chega ao primeiro MTA, é retransmitida para o segundo, que por sua vez a retransmite para qualquer outro servidor. Essa situação ocorre

Capítulo 8 - Servidor de correio eletrônico (parte 2)

l

139

quando o primeiro MTA tem o segundo como seu “mail hub” e o segundo tem o primeiro na lista de IPs autorizados a usá-lo como relay. É uma situação bem difícil de diagnosticar e fácil de ser explorada. Antes de tornar um serviço de correio eletrônico público é fundamental verificar se ele está se comportando como relay aberto. Uma maneira fácil de fazer isso é através de um telnet pela porta adequada, digitando os comandos SMTP diretamente. A ferramenta openssl, com o comando s_client, pode ser usada no caso de sessões cifradas. Exemplo: myhost:~$ telnet mailserver.example.com 25 Trying 192.0.2.82... Connected to mailserver.example.com. Escape character is ‘^]’.

220 babbo.example.com ESMTP Sendmail 8.13.4/8.13.4;

Tue, 20 Sep 2005 16:31:04 -0300 helo myhost.example.net 250 babbo.example.org Hello IDENT:[email protected] [192.0.2.44], pleased to meet you mail from: 250 2.1.0 ... Sender ok

rcpt to:

550 5.7.1 ... Relaying denied. Proper authentication required. quit 221 2.0.0 babbo.example.com closing connection

Administração de Sistemas Linux: Serviços para Internet

Connection closed by foreign host.

140

9 Instalar o Samba; Configurar um Servidor Primário de Domínio (PDC); Integrar o PDC com uma base de autenticação LDAP; Controlar informações de usuários e autenticação para clientes Windows.

conceitos

Estrutura e funcionamento do Samba. SMB/CIFS. Compartilhamento de arquivos. Autenticação através de LDAP

Introdução O estudo deste capítulo terá foco na utilização do Samba no modo clássico, ou seja, como um Servidor Primário de Domínio estilo Windows NT4. Ele se inicia pelos conceitos do serviço Samba, passando por aspectos técnicos importantes do seu funcionamento, e concluindo com sua instalação, configuração e testes relevantes nas situações reais em que está inserido. Em seguida, estudaremos a instalação e a configuração do Samba, com especial atenção aos parâmetros e seções mais importantes de seu arquivo de configuração. Apresentaremos ainda o compartilhamento de um disco Linux e a montagem de diretórios do Windows.

Samba O que é o SAMBA?

q

11 Conjunto de aplicações baseadas no protocolo Server Message Block (SMB). 11 Possibilita a comunicação com todas as estações da rede que utilizam SMB. 11 Criado em 1991 por Andrew Tridgell 11 O nome é baseado na em uma busca em um dicionário por uma palavra que continha as letras “S”, “M” e “B”. O Samba é um conjunto de aplicações, executadas em um sistema Linux ou UNIX, que utiliza o protocolo Server Message Block (SMB)/Common Internet File System (CIFS).

Capítulo 9 - Samba

objetivos

Samba

141

Os Sistemas Operacionais Microsoft Windows utilizam o SMB para realizar comunicações cliente-servidor e compartilhar arquivos e impressoras. Ao suportar esse protocolo, o Samba torna possível que computadores utilizando sistemas UNIX/Linux participem das comunicações entre sistemas Windows. O Samba nasceu no final de 1991, pelas mãos de Andrew Tridgell, um australiano que na época era estudante do curso de PhD em ciências da computação. Ele precisava rodar um software da DEC, chamado “eXcursion”, que trabalhava em conjunto com o Patchworks, um software de compartilhamento de arquivos. O Patchworks era um software proprietário, que utilizava um protocolo sobre o qual não existiam muitas informações disponíveis. Andrew decidiu estudar o protocolo, desenvolvendo um pequeno programa, chamado sockspy, que era capaz de examinar o tráfego da rede, capturando as mensagens enviadas pelo cliente e as respostas do servidor. Com isso, ele foi capaz de implementar o suporte às principais chamadas e desenvolveu um programa servidor, que era capaz de conversar com os clientes rodando o Patchworks. Esse programa também funcionava em conjunto com o LanManager da Microsoft, permitindo compartilhar arquivos de um servidor Unix com máquinas rodando o MS-DOS. O protocolo usado pelo Patchworks se revelou uma implementação do protocolo SMB, que havia sido desenvolvida internamente pela DEC. Pouco depois, em janeiro de 1992, ele disponibilizou o “Server 0.1”, que foi rapidamente seguido por uma versão aprimorada, o “Server 0.5”. A versão seguinte (1.5), que foi lançada apenas em dezembro de 1993, passou a se chamar “smbserver”. O nome “Samba” surgiu em 2004, devido à impossibilidade de continuar a usar o nome “smbserver”. O novo nome surgiu a partir de uma simples busca dentro do dicionário por palavras que possuíssem as letras S, M e B, de “Server Message Blocks”, posicionadas nessa ordem. A melhor alternativa que a busca retornou foi a palavra “samba”. Uma curiosidade é que não existiu um “Samba 1.0”, pois a primeira versão a utilizar o nome “Samba” foi a 1.6.05, que foi a sucessora imediata do “smbserver 1.6.4”. Funcionalidades 11 Controlador de Domínio NT ou AD; 11 Relações de confiança entre Domínios Windows NT;

Administração de Sistemas Linux: Serviços para Internet

11 Diferentes modos de segurança;

142

11 Diferentes backends de base de dados de contas; 11 Compartilhamento e armazenamento de arquivos entre Windows e Linux; 11 Compartilhamento de impressoras; 11 Autenticação de clientes; 11 Resolução de nome com WINS; 11 Integração entre usuários de diferentes Sistemas Operacionais; Ele cresceu muito desde então, e agora fornece funcionalidades e características compatíveis com instalações de grande escala. Entre elas, podemos citar: 11 Substituir um Controlador de Domínio Windows NT ou um Controlador de Domínio Windows AD; 11 Possui excelente interoperabilidade com Domínios Windows NT, assim como Domínios Microsoft Active Directory;

q

11 Permite relações de confiança completas entre Domínios Windows NT; 11 Possui diferentes modos de segurança, o que confere autenticação mais flexível do que as disponíveis nos Controladores de Domínio Microsoft Windows NT; 11 Permite o uso de diferentes backends de base de dados de contas; 11 Compartilhamento de diretórios e espaço de armazenamento entre clientes Windows e Linux; 11 Compartilhamento de impressoras instaladas no servidor entre clientes Windows e Linux; 11 Permite autenticar clientes que estão realizando login em domínios Windows; 11 Fornece resolução de nome com Windows Internet Name Service (WINS); 11 Suporte a um mix de usuários que utilizam diferentes Sistemas Operacionais; 11 Integração entre a autenticação de sistemas Linux e Windows, mantendo apenas uma única base de contas de usuários que funciona em ambos os sistemas. Modos de operação

q

11 Controlador Primário (e de Backup) de um Domínio – Modo clássico 11 Controlador de Domínio Active Directory 11 Servidor Membro em um Domínio 11 Servidor Standalone 11 Servidor de Impressão O servidor Samba pode operar como uma das seguintes formas: 11 Controlador Primário (e de Backup) de um Domínio Windows NT4 – Modo clássico (PDC/ BDC – Primary Domain Controller/Backup Domain Controller); 11 Controlador de Domínio Active Directory (AD-DC: Active Directory Domain Controller); 11 Servidor Membro em um Domínio AD ou Domínio Windows NT4; 11 Servidor Standalone; 11 Servidor de Impressão Windows.

Daemons Nmbd

q

11 Controla as requisições de registro e resolução de nome smbd 11 Gerencia os recursos compartilhados entre o servidor Samba e seus clientes winbindd 11 Utilizado quando o servidor Samba possui uma relação de confiança com outro domínio O Samba contém vários programas que fornecem funcionalidades diferentes, porém relacionadas. A maioria dos programas do Samba giram em torno de três deamons no modo

nmbd Esse daemon controla todas as requisições de registro e resolução de nome. É o principal mecanismo envolvido na navegação na rede SMB. Ele também gerencia todos os protocolos baseados em UDP. O daemon nmbd deve ser o primeiro iniciado durante o processo de

Capítulo 9 - Samba

clássico, que são:

inicialização do Samba. 143

smbd Esse daemon gerencia os recursos compartilhados entre o servidor Samba e seus clientes, através de conexões TCP/IP. Ele fornece serviços de acesso a arquivos, impressão e navegação aos clientes SMB. Ele também lida com todas as notificações entre o servidor Samba e seus clientes na rede, e é responsável pela autenticação de usuários, bloqueio de recursos e compartilhamento de dados através do protocolo SMB. Deve ser iniciado imediatamente após o nmbd.

winbindd Esse daemon deve ser iniciado quando o Samba é membro de um Domínio NT ou AD. Também é necessário quando o servidor Samba possui uma relação de confiança com outro domínio. Ele é utilizado para buscar informação sobre os usuários e grupos que estão em servidores Windows NT, e permitir que o Samba autorize o acesso dos usuários através de um servidor Windows NT/2000.

Conjunto de ferramentas 11 net

q

11 pdbedit 11 rpcclient 11 smbclient 11 smbcontrol 11 smbpasswd 11 smbspool 11 smbstatus 11 smbtar 11 testparm A distribuição do Samba também contém um conjunto de ferramentas, utilizadas na administração e operação. Os principais são:

Administração de Sistemas Linux: Serviços para Internet

11 net: um programa que pode ser utilizado para realizar administração remota nos servi-

144

dores Samba; 11 pdbedit: um programa utilizado para o gerenciamento das contas de usuários que residem em uma base de dados SAM; 11 rpcclient: um programa que pode ser utilizado para executar funções MS-RPC em clientes Windows; 11 smbclient: um cliente parecido com o FTP, que pode ser utilizado para se conectar com compartilhamentos SMB e realizar operações neles; 11 smbcontrol: um utilitário de administração que envia mensagens ao nmbd ou smbd; 11 smbpasswd: um programa que permite a um administrador alterar as contas utilizadas pelo Samba; 11 smbspool: um programa de fila de impressão, utilizado para enviar arquivos para impressoras remotas que estão compartilhadas na rede SMB;

11 smbstatus: um programa que apresenta um relatório atual das conexões de rede aos compartilhamentos em um servidor Samba; 11 smbtar: um programa similar ao comando tar do Linux, para realizar backup dos dados em compartilhamentos SMB; 11 testparm: um programa simples para realizar verificações no arquivo de configuração do Samba.

Conceitos Samba utiliza o protocolo SMB/CIFS.

q

O SMB surgiu junto com o Windows 3.11. NetBIOS: uma API para troca de mensagens entre microcomputadores ligados em rede. NetBIOS foi expandido, dando origem ao protocolo NetBEUI CIFS foi a evolução do SMB, inclui diversos novos recursos 11 Como o uso de uma única porta TCP (445) no lugar das três portas (137 UDP, 138 UDP e 139 TCP) Workgroup, herdado do SMB: Conjunto segmentado de computadores na mesma rede Domínio NT: Workgroup utilizando uma máquina como controladora SID: Identificador Único de Segurança RID: Identificador Relativo Como foi mencionado, o Samba utiliza o protocolo SMB/CIFS. O SMB surgiu junto com o Windows 3.11. Esse protocolo governa o compartilhamento de arquivos e impressoras em redes Microsoft, incluindo a navegação na rede, o estabelecimento de conexões e a transferência de dados. Ele utiliza o NetBIOS para a troca de mensagens entre os hosts. O NetBIOS (Network Basic Input Output) é uma API para troca de mensagens entre microcomputadores ligados em rede. Foi originalmente desenvolvido pela IBM, em 1984, para servir como uma extensão do BIOS da placa-mãe, oferecendo recursos de rede. Em 1985, o NetBIOS foi expandido, dando origem ao protocolo NetBEUI (NetBIOS Extended User Interface), que foi durante muito tempo o principal protocolo usado em redes locais, antes da popularização do TCP/IP. O CIFS foi desenvolvido pela Microsoft como a evolução do SMB, que inclui diversos novos recursos, abandona o uso do NetBIOS (devido a problemas relacionados ao uso intensivo de pacotes de broadcast e do UDP) e passa a utilizar uma única porta TCP (445) no lugar das três portas (137 UDP, 138 UDP e 139 TCP) utilizadas pelo SMB. Outro conceito importante no Samba é o uso dos Workgroups e Domínios. O workgroup, herdado do SMB, é um conjunto segmentado de computadores na mesma rede, onde todos estão no mesmo nível e compartilham recursos. A segurança no acesso aos recursos é controlada pela própria máquina, normalmente definida ao nível do que é compartilhado e

O modelo de rede ponto-a-ponto dos workgroups funciona razoavelmente bem, contanto que o número de computadores na rede seja pequeno. Entretanto, em redes maiores, a simplicidade dos workgroups se torna um fator limitante. Os workgroups oferecem somente o nível mais básico de segurança. Para suportar as necessidades de grandes redes, a Microsoft introduziu os domínios com o Windows NT 3, que essencialmente é um work-

Capítulo 9 - Samba

utilizando um usuário/senha para acessar cada compartilhamento que a máquina possui.

group de computadores SMB com uma adição: um computador atuando como controlador 145

de domínio (DC – Domain Controller), que fica responsável por armazenar todas as contas, utilizadas pelo usuário para acessar os recursos existentes em outras máquinas, e scripts de logon configurados para fazer ajustes, sincronismo, manutenção ou qualquer outra tarefa programada pelo administrador do sistema. O principal benefício introduzido pela utilização do Domínio é o “Single Sign-On” (SSO). Ele permite que os usuários em uma rede realizem o logon em qualquer estação de trabalho que seja membro de um domínio, e acessem os recursos da rede (compartilhamento, arquivos, impressoras etc.) como se estivessem em seus próprios computadores. Um domínio fornece um identificador único de segurança (SID). Os identificadores de segurança das contas de usuários, máquinas e grupos do domínio são compostos do SID do domínio mais um identificador relativo (RID), que é único para a conta. Os SIDs de conta (SID do domínio mais o RID) podem ser utilizados para criar listas de controle de acesso (ACLs), que são associadas aos recursos de rede. Um típico SID de domínio se parece com o seguinte formato: S-1-5-21-726309263-4128913605-1168186429

Quando a conta é criada, o Samba gera o RID dela de forma algorítmica. O Linux utiliza uma base de dados separada para os identificadores de usuário e de grupo (o UID e GID), mas o Windows aloca o RID utilizando uma única base. Um usuário Windows e um grupo Windows não podem ter o mesmo RID. Assim como o UID 0 é utilizado para o usuário root no Linux, a conta Administrador do Windows possui o RID 500. O RID é concatenado ao SID do domínio Windows. Dessa forma, a conta Administrador de um domínio que possui o SID acima, terá o seguinte SID de usuário: S-1-5-21-726309263-4128913605-1168186429-500

O resultado é que toda conta em uma rede Windows possui um identificador de segurança globalmente único.

Samba ADS Disponível a partir da Versão 4

q

Administração de Sistemas Linux: Serviços para Internet

Servidor Samba atua como um Controlador de Domínio AD

146

11 Possui sua própria implementação do LDAP 11 Possui um KDC Kerberos 11 Possui um servidor DNS interno 11 Trabalha com apenas um daemon, chamado samba A partir da versão 4, o Samba passou a suportar o ambiente de logon em domínios Active Directory (AD), utilizados pelos Sistemas Operacionais Windows, da versão 2000 em diante. A implementação do Controlador de Domínio AD do Samba inclui internamente seu próprio servidor LDAP (não sendo possível utilizar um servidor externo) e um Key Distribution Center (KDC) Kerberos.

Diferentemente do modo clássico PDC do Samba, onde é necessário executar três daemons (smbd, nmbd e winbindd), o Samba AD só precisa da execução de um único daemon, chamado “samba”, e a ferramenta para administrar os serviços do AD é chamada de “samba-tool”. Como o DNS é uma parte integral do AD, o Samba 4 passou a fornecer duas soluções integradas de DNS: um servidor DNS interno e um plugin para o BIND, utilizando o mecanismo BIND DLZ. Toda a parte de integração com LDAP, incluindo a inicialização da base de dados, é realizada internamente pela nova ferramenta de configuração e provisionamento do Samba.

Instalação e configuração Instalação Red Hat/CentOS

q

11 # yum install samba4 samba4-client samba4-common ou 11 # yum install samba samba-client samba-common Debian/Ubuntu Server 11 # apt-get install samba samda-doc Iniciar/Para os serviços Red Hat/CentOS 11 root# systemctl nmb {start|stop|reload|restart|force-reload|status} 11 root# systemctl smb {start|stop|reload|restart|force-reload|status} Debian/Ubuntu Server 11 root# service {start|stop|reload|restart|force-reload|status} nmbd 11 root# service {start|stop|reload|restart|force-reload|status} smbd 11 root# service {start|stop|reload|restart|force-reload|status} winbindd É recomendada a instalação dos pacotes binários do Samba através do próprio gerenciador de pacotes da distribuição Linux. Dessa forma, ele instalará também todas as dependências necessárias para instalar e executar o Samba.

Red Hat/CentOS # yum install samba4 samba4-client samba4-common

ou # yum install samba samba-client samba-common

Debian/Ubuntu Server

Iniciar/Para os serviços Red Hat/CentOS root# systemctl nmb {start|stop|reload|restart|force-reload|status} root# systemctl smb {start|stop|reload|restart|force-reload|status}

Capítulo 9 - Samba

# apt-get install samba samda-doc

147

Debian/Ubuntu Server root# service {start|stop|reload|restart|force-reload|status} nmbd root# service {start|stop|reload|restart|force-reload|status} smbd root# service {start|stop|reload|restart|force-reload|status} winbindd

Arquivo de configuração smb.conf Arquivo texto /etc/samba/smb.conf

q

11 Seções: 22 Representam um compartilhamento ou um meta-serviço 22 Definido pelo nome da seção entre colchetes. Ex: [secao1] 11 Atributos: 22 Definidos por pares de “chave” e “valor”, separados pelo sinal de igual. Ex: chave1 = valorA 22 Podem ser globais ou locais 11 Seções especiais: 22 [global] 22 [homes] 22 [profile] 22 [printers] 22 Comentários: “#” ou “;” A configuração do Samba é armazenada no arquivo smb.conf, que geralmente fica localizado no diretório Linux. Dessa forma, ele instalará também todas as dependênciocal correto de onde o arquivo de configuração deve ficar, basta executar o seguinte comando:

root#

smbd -b | grep smb.conf

O arquivo smb.conf utiliza a mesma sintaxe de vários antigos arquivos .ini do Windows 3.1. Consiste de várias seções, que são iniciadas colocando o nome da seção entre colchetes. Os atributos de cada seção são representados por pares de “chave” e “valor”, separados pelo

Administração de Sistemas Linux: Serviços para Internet

sinal de igual (“=”). É um simples arquivo de texto, então é possível editá-lo com qualquer

148

editor de texto. Cada seção no arquivo smb.conf representa um compartilhamento ou um meta-serviço em um servidor Samba. A seção [global] é especial, tendo em vista que ela contém configurações que são aplicadas ao servidor Samba. O Samba suporta vários meta-serviços, cada um tendo seu propósito específico. Por exemplo, o compartilhamento [homes] é um meta-serviço que faz com que o Samba forneça um compartilhamento do diretório home pessoal para cada usuário. O compartilhamento [printers] é um meta-serviço que estabelece um suporte à fila de impressão. A seção [profile] define um perfil de usuário quando o servidor Samba é usado como PDC de domínio. As linhas iniciadas por “#” ou “;” são tratadas como comentário. Quebras de linha podem ser especificadas com uma “\” no final da linha. A seguir um exemplo de uma configuração mínima do smb.conf:

[global] workgroup = GRUPO netbios name = SMBSERVER map to guest = bad user security = share [homes] guest ok = no read only = no [dados] path = /data comment = Meus arquivos read only = No guest ok = yes Browseable = yes

É importante validar o conteúdo do arquivo smb.conf antes de iniciar os daemons. Para isso, basta executar o comando testparm:

root#

testparm /etc/samba/smb.conf

O testparm analisará o arquivo de configuração e reportará qualquer parâmetro desconhecido ou com a sintaxe incorreta. Ele também verifica os erros de configuração mais comuns e emite um aviso caso encontre algum.

Principais parâmetros de configuração 11 server role

q

11 netbios name 11 workgroup 11 invalid users 11 valid users 11 log file 11 log level 11 os level 11 domain master 11 local master 11 preferred master 11 passdb backend

11 comment 11 browseable 11 guest 11 account

Capítulo 9 - Samba

11 security path

149

11 public

q

11 write list 11 read list 11 available 11 printable 11 read only 11 create mask 11 directory mask 11 volume Os parâmetros de configuração estão documentados na página do man do smb.conf. Alguns parâmetros podem ser utilizados somente na seção [global], outras somente em seções de compartilhamentos ou de meta-serviços. 11 server role = “funcao”: parâmetro utilizado na seção [global] que determina o modo básico de operação de um Servidor Samba e é um dos parâmetros mais importantes de configuração. As opções de configuração aceitas são: 22 AUTO: esse é o valor padrão, e faz com que o Samba consulte o parâmetro “security” para determinar o modo de operação do servidor. Se o parâmetro “security” não estiver configurado, o Samba será configurado como um simples servidor de arquivos, não estando conectado a nenhum Domínio; 22 STANDALONE: nesse modo de operação, um cliente precisa primeiro realizar o “logon” utilizando um usuário e uma senha válidos. Senhas criptografadas são utilizadas por padrão nesse modo; 22 MEMBER SERVER: nesse modo o Samba tentará validar o login/senha encaminhando a solicitação de autenticação para o Controlador de Domínio. Esse modo só funcionará corretamente se o comando net foi utilizado para adicionar esse servidor no domínio. É esperado que o parâmetro “encrypted passwords” esteja configurado com o valor “yes”; 22 CLASSIC PRIMARY DOMAIN CONTROLLER: nesse modo de operação, o Samba executa como um Controlador Primário de Domínio clássico, fornecendo os serviços Administração de Sistemas Linux: Serviços para Internet

de logon de domínio aos clientes; 22 CLASSIC BACKUP DOMAIN CONTROLLER: o Samba executa, nesse modo de operação, como um Controlador Backup de Domínio clássico, fornecendo serviços de logon de domínio aos clientes; 22 ACTIVE DIRECTORY DOMAIN CONTROLLER: nesse modo de operação, o Samba executa como um Controlador de Domínio AD, fornecendo serviços de logon de domínio aos clientes. 11 netbios name = “nome do servidor”: parâmetro utilizado na seção [global] que especifica o nome NetBIOS primário do servidor Samba. Caso não seja ajustado, ele usará o hostname da máquina como valor padrão; 11 workgroup = “grupo de trabalho ou domínio”: parâmetro utilizado na seção [global] que especifica qual o nome do grupo de trabalho ou do domínio da máquina Samba; 11 invalid users = “user1 user2 @group1”: define uma lista de usuários, separados por espaço, que não terão acesso aos recursos do servidor ou compartilhamento. Nomes começados com “@” são interpretados como grupos; 150

11 valid users = “user1 user2 @group1”: semelhante à opção invalid users, mas permite que somente os usuários especificados tenham acesso ao sistema; 11 log file= “/caminho/arquivo”: parâmetro utilizado na seção [global] que define a localização e nome do arquivo de log gerado pelo Samba; 11 log level = “valor”: parâmetro utilizado na seção [global] que define o nível de debug dos daemons do Samba, variando de 0 (menos informação) a 9 (muita informação); 11 os level=“num”: parâmetro utilizado na seção [global] que especifica o nível do Sistema Operacional. Esse número é usado para as eleições NetBIOS para definir o master browser local e o controlador de domínio. O valor pode ser de 0 a 255, e o padrão é 32; 11 domain master = “valor”: parâmetro utilizado na seção [global] que especifica se o servidor tentará se tornar o master browser de domínio. Os valores que podem ser especificados são: “yes” (valor padrão), “no” e “auto”. O valor padrão é auto; 11 local master = “valor”: parâmetro utilizado na seção [global] que define se o servidor participará ou não das eleições para master browser local. Os valores que podem ser especificados são: “yes” e “no”; 11 preferred master = “valor”: parâmetro utilizado na seção [global] que define se o servidor Samba terá ou não vantagens de ganhar uma eleição local. O servidor poderá se tornar de forma garantida o master browser do domínio se essa opção for usada em conjunto com domain master = yes. Os valores podem ser “yes”, “no” e “auto” (valor padrão); 11 passdb backend = “tipo:local”: parâmetro utilizado na seção [global] que permite escolher qual o tipo de “backend” será utilizado para armazenar as informações das contas. O valor é dividido em duas partes, sendo a primeira o nome/tipo do backend e a segunda (opcional) uma string definindo o local onde será armazenada. Mais sobre esse assunto no item “Backends de contas”; 11 security = “valor”: parâmetro utilizado na sessão [global] que permite definir o Modo de segurança do Samba e como os clientes respondem durante a autenticação. Esse parâmetro é um dos mais importantes e será tratado mais detalhadamente no item “Modelos de Segurança”; 11 path = “/caminho/do/diretório”: parâmetro utilizado em uma seção de compartilhamento para especificar qual diretório o usuário terá acesso. No caso de um compartilhamento de impressora, especifica o diretório do spool de impressão, onde os arquivos serão armazenados antes de serem enviados para a impressora; 11 comment = “Descrição do Compartilhamento”: descrição do compartilhamento que será mostrada na janela de procura de rede ou no comando smbclient -L maquina; 11 browseable = “valor”: define se o compartilhamento será ou não exibido na janela de procura de rede. Mesmo não sendo exibido, o compartilhamento poderá ser acessado. Valores aceitos são “yes” e “no”; 11 guest account = “username”: conta que será usada para fazer acesso sem senha (convidado) quando o parâmetro guest ok ou public forem usados em um compartilhamento. 11 public = “valor”: permite aos usuários se conectarem ao compartilhamento sem fornecer uma senha, usando o usuário definido em guest account. Aceita os valores “yes” e “no”. Esse parâmetro possui o mesmo efeito do parâmetro “guest ok”; 11 write list = “usuario1 usuario2 @grupo1”: lista de usuários, separados por espaço ou vírgula, que poderão ler e gravar no compartilhamento. Caso o nome for iniciado por “@”, será tratado como um grupo UNIX e todos os usuários daquele grupo terão acesso de gravação;

Capítulo 9 - Samba

Por padrão, ela é mapeada para o usuário nobody;

151

11 read list = “usuario1 usuario2 @grupo1”: lista de usuários separados por espaço ou vírgula que terão acesso de apenas leitura no compartilhamento. Caso o nome for iniciado por “@”, será tratado como um grupo UNIX; 11 available = “valor”: parâmetro utilizado para habilitar e desabilitar um compartilhamento. Aceita os valores “yes” e “no”; 11 printable = “valor”: especifica se o compartilhamento é uma impressora (yes) ou um compartilhamento de arquivo/diretório (no). O padrão é “no”; 11 read only = “valor”: especifica se o compartilhamento é somente para leitura (yes) ou não (no) para todos os usuários. O parâmetro writable é um antônimo equivalente a esse parâmetro, só que utiliza as opções invertidas; 11 create mask = “valor”: máscara do modo padrão para criação de arquivos no compartilhamento. Valor configurado como a máscara de criação de arquivos do Linux; 11 directory mask = “valor”: máscara do modo padrão para a criação de diretórios no compartilhamento. Valor configurado como a máscara de criação de diretórios do Linux; 11 volume = “nome”: parâmetro utilizado para configurar o rótulo do volume de um compartilhamento.

Parâmetros de configuração para administração de contas Parâmetros para administração automática de contas

q

11 Adicionados na seção [global] 22 add user script: Adicionar um usuário 22 delete user script: Remover um usuário 22 add group script: Adicionar um grupo 22 delete group script: Remover um grupo 22 add user to group script: Adicionar um usuário a um grupo 22 delete user from group script: Remover um usuário de um grupo 22 set primary group script: Defini o grupo primário 22 add machine script: Adicionar uma máquina Os parâmetros a seguir, definidos na seção [global], são utilizados para a administração das Administração de Sistemas Linux: Serviços para Internet

contas, principalmente durante operações remotas executadas no servidor Samba:

152

11 add user script: caminho completo para o script/comando que será executado como root pelo smbd para criar uma conta de usuário; 11 delete user script: caminho completo para o script/comando que será executado como root pelo smbd para remover uma conta de usuário; 11 add group script: caminho completo para o script/comando que será executado como root pelo smbd para criar um grupo; 11 delete group script: caminho completo para o script/comando que será executado como root pelo smbd para remover um grupo; 11 add user to group script: caminho completo para o script/comando que será executado como root pelo smbd para adicionar uma conta de usuário a um grupo; 11 delete user from group script: caminho completo para o script/comando que será executado como root pelo smbd para remover uma conta de usuário a um grupo;

11 set primary group script: caminho completo para o script/comando que será executado como root pelo smbd para definir o grupo primário de um usuário; 11 add machine script: caminho completo para o script/comando que será executado como root pelo smbd para adicionar uma conta de máquina; Os comandos definidos nesses parâmetros, que podem apontar para as próprias ferramentas de administração do Linux ou para scripts específicos, são executados para realizar as operações definidas sob demanda, como, por exemplo, quando uma máquina ingressa no domínio. Se o parâmetro add machine script estiver corretamente configurado, quando a máquina ingressa no domínio, a conta de máquina é automaticamente criada.

Variáveis de substituição Variáveis de substituição

q

Podem ser configuradas em qualquer lugar do arquivo: 11 %U: login do usuário da sessão; 11 %G: grupo primário do %U; 11 %h: hostname do servidor que está executando o Samba; 11 %m: o nome NetBIOS da máquina cliente; 11 %L: o nome NetBIOS do servidor Samba; 11 %M: o hostname da máquina cliente; 11 %I: endereço IP da máquina cliente; 11 %T: data e hora do Servidor Samba; 11 %$(envvar): o valor da variável de ambiente definida no Linux 22 (Exemplo: $PATH, $SHELL, $HOSTNAME); 11 %u: login do usuário do serviço/compartilhamento; 11 %g: grupo primário do %u; 11 %H: o diretório home do usuário %u. Muitas das strings que são configuradas no arquivo smb.conf aceitam substituições. Por exemplo, o parâmetro “path = /tmp/%u” é interpretado como “path = /tmp/aluno” se o usuário conectado possuir o login “aluno”. As mais comumente utilizadas são: 11 %U: login do usuário da sessão; 11 %G: grupo primário do %U; 11 %h: hostname do servidor que está executando o Samba; 11 %m: o nome NetBIOS da máquina cliente; 11 %L: o nome NetBIOS do servidor Samba;

11 %I: endereço IP da máquina cliente; 11 %T: data e hora do Servidor Samba; 11 %$(envvar): o valor da variável de ambiente definida no Linux (Exemplo: $PATH, $SHELL, $HOSTNAME); 11 %u: login do usuário do serviço/compartilhamento;

Capítulo 9 - Samba

11 %M: o hostname da máquina cliente;

153

11 %g: grupo primário do %u; 11 %H: o diretório home do usuário %u.

Backends de contas 11 Backend: mecanismo utilizado para armazenar as contas

q

11 smbpasswd 22 Arquivo texto, similar ao passwd/shadow utilizado pelo Linux 11 tdbsam 22 Melhoria em relação ao smbpasswd 22 Armazena informações estendidas SAM (Security Accoutn Manager) 22 Arquivo binário no formato TDB (Trivial Database) 22 Recomendado para ambientes com um único Controlador de Domínio 11 ldapsam 22 Possibilita a integração e comunicação com um Servidor LDAP 22 Recomendado para ambientes que necessitam de múltiplos Controladores de Domínio (Primário e de Backup) O “passdb backend” é apenas um mecanismo para armazenar as contas. Essas contas são as contas de usuários, contas de grupos, contas de relação de confiança de máquina e contas de relação de confiança entre domínios. Os três backends suportados pelo Samba são: smbpasswd, tdbsam e ldapsam. Desses, apenas o ldapsam suporta armazenar ambas as contas dos usuários Linux (POSIX) e Samba em um único repositório.

smbpasswd Essa opção permite utilizar o arquivo smbpasswd, que é um simples arquivo texto (ASCII) contendo as senhas criptografadas e um campo de informação sobre a conta. Essa forma de backend não armazena qualquer informação SAM, necessária para sistemas Windows a partir da versão NT, e que utilizam os controles extras de segurança e acesso.

O uso desse backend não é recomendado, e só deve ser utilizado em casos onde a Administração de Sistemas Linux: Serviços para Internet

retrocompatibilidade é necessária.

154

tdbsam Esse backend fornece uma rica base de dados para servidores locais. Ele não é recomendado para ambientes com múltiplos controladores de domínio (um PDC e um ou mais BDCs). O backend tdbsam armazena as informações do backend smbpasswd, mais as informações estendidas do SAM (Security Account Manager), presentes nos servidores Windows, tudo em um único arquivo binário no formato TDB (Trivial Database). A inclusão das informações estendidas tornou possível ao Samba implementar os mesmos controles de acesso de contas e sistema existente nos servidores Windows.

ldapsam Esse backend fornece acesso ao serviço de diretório LDAP, com suporte ao sistema de gerenciamento distribuído de contas. O Samba possui um schema para integrar a operação com o servidor LDAP.

Modelos de segurança 11 Segurança ao nível do Usuário

q

11 Segurança ao nível do Domínio 11 Segurança de Domínio AD A rede SMB/CIFIS possui apenas dois níveis de segurança: “ao nível do usuário” e “ao nível do compartilhamento”. Um servidor SMB informa ao cliente, durante a configuração inicial da sessão, o nível de segurança que o servidor está utilizando. O nível que o cliente receber afetará a forma como o cliente tenta se autenticar, mas não afetará diretamente a forma como o servidor Samba realiza a segurança. No SMB, tudo é iniciado e controlado pelo cliente, e o servidor pode apenas “informar” ao cliente o que está disponível e se uma ação é permitida. O Samba possui três formas de implementar a segurança ao nível de usuário. Essas implementações do Samba são chamadas de métodos de segurança, e são: user (usuário), domain (domínio) e ADS.

Segurança no nível do usuário Modelo padrão do Samba

q

11 A máquina cliente envia uma solicitação ao servidor, fornecendo usuário/senha 11 Não é focado no compartilhamento/recurso que o usuário tem acesso 11 O servidor aceita ou recusa a conexão apenas com base nas credenciais 11 Após a conexão ser aceita, não será mais necessário entrar com usuário e senha 11 Configuração – Incluir na seção [global]: 22 security = use Nesse nível, o cliente envia um pedido de configuração de seção diretamente após a negociação do protocolo, fornecendo um username e uma senha. O servidor pode aceitar ou recusar a combinação username/senha. Durante esse estágio, o servidor ainda não tem informações sobre qual compartilhamento o cliente tentará eventualmente utilizar, se baseando somente nas informações de username/senha e o nome da máquina cliente para aceitar/rejeitar a seção. Se o servidor aceitar as credenciais username/senha, o cliente espera ser capaz de montar os compartilhamentos sem a necessidade de entrar com a senha novamente. É esperado configurado durante a inicialização da seção. Para configurar esse nível de segurança, basta incluir o seguinte parâmetro na seção [global] do arquivo de configuração smb.conf: security = user

Capítulo 9 - Samba

que todos os direitos de acesso utilizarão o conjunto de credenciais username/senha que foi

155

Modo de Segurança Domain (Segurança ao Nível de Usuário) Mecanismo central para armazenar as contas

q

Compartilhado entre os controladores de domínio Um único servidor PDC mantém a base de dados Torna o Servidor Samba um Servidor Membro de um Domínio As requisições de autenticação são encaminhadas diretamente para o PDC 11 Configuração – Incluir na seção [global]: 22 security = domain 22 workgroup = NOME-DO-DOMINIO Esse modo fornece um mecanismo para armazenar todas as contas de usuários e grupos em um repositório central e compartilhado. O repositório centralizado é compartilhado entre controladores de domínio. Os servidores que atuam como controladores de domínio fornecem os serviços de autenticação e validação para todas as máquinas que participam no contexto de segurança do domínio. O PDC é responsável por manter a integridade e segurança da base de dados de conta. Os BDCs fornecem somente logon de domínio e autenticação de serviço. O servidor Samba, quando está operando no modo “security = domain”, possui uma conta de relação de confiança (uma conta de máquina) e faz com que todas as requisições de autenticação sejam encaminhadas diretamente para os controladores de domínio, tornando o Servidor Samba um servidor membro de domínio. Para configurar o Samba como um Servidor Membro de Domínio, é necessário configurar os seguintes parâmetros no arquivo smb.conf: security = domain workgroup = DOMINIO1

Modo de Segurança ADS (Segurança ao Nível de Usuário) 11 Utilizado para ingressar o Servidor Samba como membro de domínio AD

q

11 Configuração – Incluir na seção [global]: Administração de Sistemas Linux: Serviços para Internet

22 realm = kerberos.REALM

156

22 security = ADS 22 password server = kerberos.server O Samba pode ingressar em um domínio Active Directory (AD) utilizando um método de segurança baseado em RPC estilo NT4. Isso é possível se o domínio estiver executando em modo nativo. O AD em modo nativo permite membros de domínio estilo NT. Para configurar o Samba para atuar dessa forma, é necessário realizar as seguintes configurações no arquivo smb.conf: realm = kerberos.REALM security = ADS password server = kerberos.server

O termo “realm” é utilizado para descrever a arquitetura de segurança baseada em Kerberos, que é utilizada pelo Microsoft ADS.

Essa configuração não faz com que o Samba atue como um Controlador de Domínio AD.

Contas de usuários, grupos e máquinas Toda operação no Linux necessita de um identificador de usuário (chamado UID), assim como no Windows é necessário um identificador de segurança (chamado SID). O Samba fornece duas maneiras para mapear um usuário Windows para um usuário Linux. Na primeira, todas as contas na base de dados SAM do Samba necessitam de um UID do Linux para qual a conta será mapeada. Antes de adicionar uma conta de usuário no Samba, é necessário que a conta local correspondente já exista na base de usuários do Linux. Todas as contas na base SAM do Samba necessitam de uma conta de usuário Linux, que pode ser uma conta local do sistema (passwd e shadow) ou uma conta em um Servidor NIS. A segunda forma de mapear um SID Windows para um UID ou GID Linux é através do parâmetro “idmap config”, presente no arquivo smb.conf, e que é utilizado para especificar um range de UID/GID a serem utilizados no mapeamento. Esse método utiliza uma tabela de mapeamento SID à UID/GID, chamada de IDMAP. O winbind é o responsável por manter e gerenciar a tabela de mapeamento, e associar um SID a um UID ou GID. O Samba consulta o Linux para obter um UID, através das funcionalidades “passwd”, “shadow” e “group”, configuradas no arquivo de controle do NSS (nsswitch.conf ). A forma como o NSS obterá o UID pode ser configurada de diversas formas. É possível utilizar o winbindd e suas bibliotecas, fornecido pelo próprio Samba, ou utilizar o LDAP, por exemplo. A conta de máquina, também conhecida como conta de relação de confiança, é uma conta especial, utilizada para autenticar uma máquina cliente no servidor que é o controlador do domínio. O propósito dessa conta é fazer com que nenhum outro computador possa utilizar o mesmo nome de uma máquina confiável e, assim, utilizar os compartilhamentos que ela tem permissão de acesso. A senha da conta de máquina atua como um segredo compartilhado para a comunicação segura com o controlador do domínio. O nome da máquina deve ser o nome NetBIOS do cliente que ingressará no domínio, acrescido do caractere “$”. Esse caractere serve para que o Samba reconheça essa conta como uma conta de máquina. Os principais mecanismos que o Samba oferece para armazenar a base de dado das contas são o tdbsam e o ldapsam. O tdbsam armazena os dados de contas de usuário e de máquina em um único arquivo binário no formato TDB (trivial database). Ele armazena as seguintes informações: 11 UNIX username: username da conta no Linux/UNIX;

11 Account Flags: uma string de 11 caracteres, cercada por colchetes, representando as flags de controle da conta; 11 User SID: SID da conta de usuário no domínio; 11 Primary Group SID: SID do grupo primário do usuário no domínio; 11 Full Name: nome completo do usuário;

Capítulo 9 - Samba

11 NT username: username da conta no domínio NT;

157

11 Home Directory: diretório home do usuário. Pode estar no formato UNC; 11 HomeDir Drive: especifica a letra do dispositivo ao qual o caminho do diretório home será mapeado; 11 Logon Script: especifica o script (um arquivo .CMD, .EXE, ou .BAT) de logon do usuário, que será executado no lado cliente; 11 Profile Path: especifica o caminho do perfil do usuário; 11 Domain: especifica o nome do domínio ao qual o usuário pertence; 11 Account desc: uma breve descrição da conta. Similar ao campo GECOS das contas UNIX/Linux; 11 Workstations: lista de máquinas, separadas por vírgula, nas quais o usuário pode realizar logon. Se vazio, o usuário pode realizar logon em qualquer máquina; 11 Logon time: o timestamp (data e hora) da última vez em que o usuário realizou logon; 11 Logoff time: o timestamp (data e hora) da última vez em que o usuário realizou logoff; 11 Kickoff time: o timestamp (data e hora) de quando o usuário deve ser deslogado automaticamente; 11 Password last set: o timestamp (data e hora) da última vez em que a senha do usuário foi alterada; 11 Password can change: o timestamp (data e hora) a partir de quando a senha do usuário pode ser alterada; 11 Password must change: o timestamp (data e hora) a partir de quando a senha do usuário expira; 11 Last bad password: o timestamp (data e hora) da última vez em que ocorreu uma tentativa de logon que falhou; 11 Bad password count: número de tentativas de logon que falharam; 11 Logon hours: quantidade de horas em que o usuário pode permanecer logado; As flags de controle utilizadas pelo Samba são: 11 D: a conta está desabilitada; 11 H: um diretório “home” é obrigatório;

Administração de Sistemas Linux: Serviços para Internet

11 I: uma conta de relação de confiança entre domínios; 11 L: a conta foi bloqueada automaticamente; 11 M: uma conta de logon MNS (Microsoft Network Service); 11 N: a senha não é obrigatória; 11 S: uma conta de relação de confiança de servidor; 11 T: conta Duplicada Temporariamente; 11 U: conta de usuário normal; 11 W: conta de relação de confiança de Workstation; 11 X: senha nunca expira. O tdbsam é recomendado para novas instalações que não necessitem do LDAP. O mecanismo ldapsam é indicado para ambientes muito grandes e que necessitem da implementação de servidores BDC, além do PDC, para realizar a replicação da base de dados de contas. O pacote do Samba inclui o arquivo de schema necessário para integrar com o servidor LDAP e armazenar as informações utilizadas pelo Samba. 158

O objeto sambaSamAccount deve complementar as informações da conta de usuário do sistema Linux. Ele é um objeto do tipo ObjectClass auxiliar, o que significa que ele pode ser utilizado para ampliar as informações da conta de usuário existente no diretório LDAP, disponibilizando as informações necessárias para o Samba poder gerenciar a conta. Para poder armazenar toda informação da conta de usuário (Linux e Samba) dentro do diretório, é necessário utilizar as ObjectClass sambaSamAccount e posixAccount de forma combinada. Entretanto, o smbd ainda obterá a informação da conta de usuário Linux através das bibliotecas do próprio sistema. Isso significa que o servidor Samba deve também ter a biblioteca LDAP NSS instalada e funcionando corretamente.

Samba como PDC PDC – Controlador Primário de Domínio

q

11 Servidor que registra e se divulga como um PDC 11 Fornece serviço de logon de rede 11 Fornece compartilhamento especial – NETLOGON 11 Inicia e mantém a base de dados do Domínio Configurar o Servidor como PDC 11 Configuração correta da rede TCP/IP e da rede Windows; 11 Configuração correta do parâmetro para definir a função do servidor; 11 Configuração correta do serviço do DNS; 11 Logons de domínio para os clientes Windows; 11 Configuração de perfis remotos ou forçar o uso de perfil local; 11 Configuração das políticas de rede e de sistema; 11 Adição e gerenciamento de contas de usuários do domínio; 11 Clientes Windows como membros de domínio. Um Controlador de Domínio é uma máquina que é capaz de atender às requisições de logon das estações de trabalho na rede. O Microsoft LanManager e o IBM LanServer eram dois produtos iniciais que suportavam essa funcionalidade. Essa tecnologia se tornou conhecida como o serviço LanMan Netlogon. Quando o Microsoft Windows NT 3 foi lançado, ele suportava um novo estilo de Controle de Domínio e, com ele, uma nova forma de realizar o serviço de logon de rede e que possuía funcionalidades estendidas. Esse serviço se tornou conhecido como o NT NetLogon Service. O Controlador Primário de Domínio (Primary Domain Controller) é um servidor SMB/CIFS que: 11 Registra e divulga a si mesmo como um controlador de domínio, através de mensagens NetBIOS de broadcast ou registros em um servidor WINS; 11 Fornece o serviço de logon de Rede;

O PDC desempenha um papel importante no domínio. É ele quem inicia uma nova base de dados para controle do domínio.

Capítulo 9 - Samba

11 Fornecer um compartilhamento especial, chamado de NETLOGON.

159

Os seguintes passos são necessários para configurar o Samba como um PDC estilo Windows NT para clientes Windows: 11 Configuração correta da rede TCP/IP e da rede Windows; 11 Configuração correta do parâmetro para definir a função do servidor, no arquivo smb.conf; 11 Configuração correta do serviço de resolução de nomes; 11 Logons de domínio para os clientes Windows; 11 Configuração de perfis remotos ou forçar o uso de perfil local; 11 Configuração das políticas de rede e de sistema; 11 Adição e gerenciamento de contas de usuários do domínio; 11 Configurar os clientes Windows para se tornarem membros de domínio. Cada controlador Samba de domínio deve fornecer o serviço de logon de rede, funcionalidade é que configurada no Samba através do parâmetro domain logons no arquivo de configuração smb.conf. O primeiro passo para criar um PDC Samba funcional é entender os parâmetros necessários no arquivo smb.conf. Um exemplo de configuração de um PDC pode ser visto a seguir: [global] server role = classic primary domain controller workgroup = DOMINIO1 netbios name = SMBSERVER passdb backend = tdbsam os level = 33 preferred master = auto domain master = yes local master = yes security = user domain logons = yes logon path = \\%L\profiles logon drive = H: logon home = \\%L\%U add user script = /usr/sbin/useradd -m ‘%u’ Administração de Sistemas Linux: Serviços para Internet

delete user script = /usr/sbin/userdel -r ‘%u’ add group script = /usr/sbin/groupadd ‘%g’ delete group script = /usr/sbin/groupdel ‘%g’ add user to group script = /usr/sbin/usermod -G ‘%g’ ‘%u’ add machine script = /usr/sbin/useradd -s /bin/false -d /var/lib/nobody -g maquinamaquinas ‘%u’ logon script = logon.cmd [netlogon] path = /var/lib/samba/netlogon read only = yes

[profiles] path = %H/profiles

160

read only = no create mask = 0600 directory mask = 0700 [homes] comment = Diretorios Home valid users = %S read only = No browseable = No

11 Definem o modo de operação e a estrutura do Domínio

q

11 server role 11 workgroup 11 netbios name 11 passdb backend 11 server role: parâmetro que define o modo de operação padrão do Servidor Samba; 11 workgroup: parâmetro que define o nome do domínio, quando configurado como PDC; 11 netbios name: parâmetro que configura o nome NetBIOS pelo qual o servidor Samba será conhecido. Por padrão, é configurado com o mesmo nome atribuído ao host no DNS; 11 passdb backend: é onde toda a informação das contas de usuários e grupos será armazenada. Os valores aceitáveis para a configuração de um PDC são: tdbsam e ldapsam.

Parâmetros de controle do domínio 11 Configuram o funcionamento do Domínio:

q

22 os level 22 preferred master 22 ddomain master 22 security 22 encrypt passowrds 22 domain logons Os parâmetros os level, preferred master, domain master, security, encrypt password e domain logons são peças-chave para garantir o funcionamento do domínio e o suporte à logon de rede. O “os level” deve ser configurado com um valor igual ou acima de 32. Um controlador de domínio deve ser o DMB, deve ser configurado para utilizar o modo de segurança user, deve suportar senhas encriptadas compatíveis com o Windows, e deve fornecer o serviço de

11 os level: para o PDC, esse valor deve ser configurado como igual ou acima de 32; 11 preferred master: deve ser configurado com o valor “yes”, para o nmbd forçar uma eleição do Master Browser do Domínio; 11 domain master: deve ser configurado com o valor “yes”, para que o servidor Samba seja

Capítulo 9 - Samba

logon de rede (domain logons).

identificado como um Master Browser do Domínio; 161

11 security: deve ser configurado como “user”; 11 encrypt passowrds: parâmetro que controla se as senhas criptografadas serão negociadas com o cliente. Alguns clientes Windows só conseguem se conectar com o Samba utilizando o suporte às senhas criptografadas; 11 domain logons: deve ser configurado para “yes”, fazendo com que o Samba forneça o serviço de logon de rede, e funcione como um controlador de domínio estilo Windows NT.

Parâmetros de ambiente Facilita operações de logon na rede

q

Fornece funcionalidades de controle 11 logon path 11 logon home 11 logon drive 11 logon script Os parâmetros logon path, logon home, logon drive e logon script são configurações de suporte ao ambiente que ajudam a facilitar as operações de logon dos clientes. Também ajudam a fornecer funcionalidades de controle automatizadas para diminuir as sobrecargas do gerenciamento de rede. 11 logon path: esse parâmetro especifica o diretório onde os perfis remotos são armazenados. Também especifica o diretório a partir do qual alguns diretórios, como “Área de Trabalho”, “Aplicações” e “Áreas de Rede”, são carregados e exibidos na máquina cliente. Para desabilitar o perfil remoto, basta deixar esse parâmetro em branco (”logon path = “); 11 logon home: esse parâmetro especifica o local do diretório home quando clientes Windows realizam logon em um PDC Samba. Ele pode ser usado para garantir que os perfis remotos sejam armazenados em um subdiretório do diretório “home” do usuário. Para desabilitar o perfil remoto, basta deixar esse parâmetro em branco (”logon home = “); 11 logon drive: é a unidade de disco que terá o homedir do usuário mapeado; 11 logon script: esse parâmetro especifica o arquivo de script batch (.bat) ou um arquivo de comandos NT (.cmd) que será executado na máquina cliente quando um usuário realizar

Administração de Sistemas Linux: Serviços para Internet

um login. O arquivo deve ser no estilo DOS, utilizando os finalizadores de linha CR/LF. O

162

caminho do script é relativo ao compartilhamento [netlogon]. Essa opção só e útil quando o Samba é configurado como um servidor de logon. Exemplo: net time \\smbserver /set /yes net use Z: \\smbserver\COMPARTILHAMENTO /yes

Se esse script for criado no Linux, ele deve ser convertido para DOS, utilizando o comando unix2dos.

Compartilhamento NETLOGON Compartilhamento especial Definido para dar suporte ao logon de rede Configura o local onde serão armazenados o scripts de logon e arquivos de política de grupo

q

Esse compartilhamento é fundamental no suporte a logon e associação de domínio. Ele é fornecido em todos os controladores de domínio Microsoft e é utilizado para fornecer scripts de logon, armazenar arquivos de política de grupo (NTConfig.POL), e localizar outras ferramentas que podem ser necessárias para o processamento do logon.

Compartilhamento PROFILE Compartilhamento especial

q

Utilizado para armazenar os perfis dos usuários O diretório especificado deve existir antes da realização do logon Esse compartilhamento é utilizado para armazenar os perfis de área de trabalho do usuário. Cada usuário deve possuir um diretório na raiz desse compartilhamento. É necessário que o diretório especificado no parâmetro “path” nesse compartilhamento exista antes do usuário realizar logon na rede e também que tenha as corretas permissões de leitura e escrita. Se o diretório “profiles” for especificado dentro do homedir do usuário, o recomendado é incluir esse diretório dentro do “skel”. Exemplo: mkdir /etc/skel/profiles

Dessa forma, toda vez que uma conda de usuário for criada, o diretório “profiles” é automaticamente criado.

Serviço de Logon na Rede de Domínio 11 Executar o serviço de netlogon

q

22 Configurar o parâmetro “domain logon” com o valor “yes” 11 Somente o PDC configurará o parâmetro “domain master” com o valor “yes” Todos os controladores de domínio devem executar o serviço netlogon (domain logon no Samba). O PDC deve ser configurado com o parâmetro “domain master = yes”.

Configurações adicionais Alguns itens adicionais a serem verificados e executados após a configuração do Samba. Reiniciar os serviços do Samba: 11 Red Hat / CentOS root# systemctl restart nmb root# systemctl restart smb

11 Debian /Ubuntu Server root# service nmbd restart root# service winbindd restart

Adicionar a conta do usuário root no Samba. Essa conta é essencial nas atividades regulares de manutenção e administração: root#

smbpasswd -a root

New SMB password: XXXXXXXX

Capítulo 9 - Samba

root# service smbd restart

Retype new SMB password: XXXXXXXX

163

Verificar as regras do iptables. Pode ser necessário liberar no firewall as portas utilizadas pelo Samba, que são: 11 Porta 137: serviço de Nome NetBIOS Name Service; 11 Porta 138: serviço de Datagrama do NetBIOS; 11 Porta 139: serviço de Sessão NetBIOS Session Service; 11 Porta 445: serviço de Diretório Microsoft. As regras mais simples para liberar a entrada nessas portas, no iptables, seriam: root# iptables -A INPUT --dport 137 -m state --state NEW,ESTABLISHED -j ACCEPT root# iptables -A INPUT --dport 138 -m state --state NEW,ESTABLISHED -j ACCEPT root# iptables -A INPUT --dport 139 -m state --state NEW,ESTABLISHED -j ACCEPT root# iptables -A INPUT --dport 445 -m state --state NEW,ESTABLISHED -j ACCEPT

Outra opção, utilizada somente em ambiente de testes, é remover todas as regras do firewall: root# iptables -F

Integração com o OpenLDAP 11 Necessário em ambientes com PDC e BDCs

q

11 Único backend que permite utilização distribuída 11 Alta disponibilidade através da replicação/sincronização de Servidores LDAP 11 Todas as contas ficam centralizadas (uma única conta para acessar Windows e Linux) O principal fator que torna necessário a integração do Samba com o LDAP é a implementação de Servidores Samba BDCs, pois esse é o único backend de base de usuários que permite o uso de forma distribuída. A operação de Alta Disponibilidade pode ser obtida através da replicação/sincronização do diretório, e configuração de servidores master/slave. Outra grande vantagem de integrar o Samba com o LDAP é que todas as contas ficam centralizadas em uma única base, evitando assim a necessidade de criar uma conta para um usuário em duas bases diferentes (Samba e NIS, por exemplo). O OpenLDAP é uma plataforma madura para hospedar a infraestrutura de diretório orga Administração de Sistemas Linux: Serviços para Internet

nizacional, e pode incluir todas as contas Linux, diretório de armazenamento de e-mail, e muito mais. Da perspectiva do OpenLDAP, as contas do sistema Linux são armazenadas em extensões do schema POSIX. O Samba fornece seu próprio schema para permitir o armazenamento dos atributos necessários de conta. O backend LDAP é utilizado para armazenar: 11 Contas de Usuários de Rede Windows; 11 Contas de Grupo Windows NT; 11 Informação de Mapeamento entre Grupos UNIX e Grupos Windows NT; 11 Mapeamento entre SIDs e UIDs. A utilização do Samba com o OpenLDAP torna necessário armazenar as contas UNIX e as contas de Rede Windows no backend LDAP. Isso significa que é necessário utilizar algumas ferramentas para fazer a resolução entre as contas. Basicamente, os passos para realizar a integração são: 11 OpenLDAP instalado e operacional; 11 Incluir o schema do Samba no OpenLDAP. 164

11 Configurar o Samba PDC para acessar a base de dados LDAP; 11 Inicializar o arquivo secrets.tdb do Samba;

Configuração do OpenLDAP Incluir suporte ao objeto sambaSamAccount – adicionar o schema do Samba

q

no OpenLDAP 11 Copiar o arquivo do schema 22 root# zcat /usr/share/doc/samba/examples/LDAP/samba.ldif.gz > /etc/ldap/ schema/samba.ldif 11 Carregar o schema 22 root# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/samba.ldif 11 Criar índices para os atributos mais utilizados Para incluir suporte ao objeto sambaSamAccount em um servidor OpenLDAP, primeiro é necessário copiar o arquivo samba.ldif para a diretório de configuração do slapd. Esse arquivo pode ser encontrado o diretório examples/LDAP da distribuição do Samba, ou através do pacote samba-doc: root# zcat /usr/share/doc/samba/examples/LDAP/samba.ldif.gz > /etc/ldap/schema/ samba.ldif

Carregar o schema na configuração do OpenLDAP: root# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/samba.ldif

Para verificar se o novo esquema foi adicionado corretamente e está disponível: root# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config”(objectClass=olcSchemaConfig)” dn

É recomendado que alguns índices sejam mantidos sobre alguns dos atributos mais úteis, para agilizar as buscas realizadas nas classes de objeto sambaSamAccount, posixAccount e posixGroup. Isso é feito criando o arquivo samba_indice.ldif, com o conteúdo: dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: loginShell eq olcDbIndex: memberUid eq,pres,sub olcDbIndex: uniqueMember eq,pres olcDbIndex: sambaSID eq olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaSIDList eq olcDbIndex: sambaDomainName eq olcDbIndex: default sub

Se já existir a configuração de índices no OpenLDAP, editar o arquivo samba_indice.ldif para conter somente os índices para os campos utilizados pelo Samba.

Capítulo 9 - Samba

olcDbIndex: sambaGroupType eq

165

Utilizar o comando ldapmodify para carregar os novos índices na configuração do OpenLDAP: root# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f samba_indice.ldif

É possível verificar os novos índices utilizando o comando ldapsearch: root# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=configolcDatabase={1}hdb olcDbIndex

Inicialização da base de dados LDAP – Configurando o smbldap-tools Pacote com conjunto de ferramentas para gerenciar as contas Inicializar a base do LDAP 11 I. Obter o SID do domínio Samba: 22 root# net getlocalsid 11 II. Editar o arquivo /etc/smbldap-tools/smbldap.conf 22 SID=”SID DO DOMINIO” 22 sambaDomain=”DOMINIO” 22 slaveLDAP=“ldap://SERVIDOR/” 22 masterLDAP=“ldap://SERVIDOR/” 22 ldapTLS= “VALOR” 22 verify= “VALOR” 22 dclientcert=“/CAMINHO/CERTIFICADO” 22 clientkey=“/CAMINHO/CHAVE” 22 suffix=“BASE DN” 22 usersdn=“DN DOS USUARIOS” 22 computersdn=“DN DAS MAQUINAS” 22 groupsdn=“DN DOS GRUPOS” 22 idmapdn=“DN DOS MAPEAMENTOS”

Administração de Sistemas Linux: Serviços para Internet

22 sambaUnixIdPooldn=“VALOR” 22 oscope=“VALOR” 22 hash_encrypt=“VALOR” 22 crypt_salt_format=”%s” 22 userLoginShell=”SHELL” 22 userHome=”DIRETORIO” 22 userHomeDirectoryMode=”VALOR” 22 userGecos=”DESCRICAO” 22 defaultUserGid=”GID” 22 defaultComputerGid=”GID” 22 skeletonDir=”DIRETORIO” 22 defaultMaxPasswordAge=“NUMERO DE DIAS” 22 userSmbHome=“CAMINHO UNC” 22 userProfile=“CAMINHO UNC” 166

q

22 userHomeDrive=“LETRA:”

q

22 userScript=”SCRIPT.BAT” 22 mailDomain=”DOMINIO” 11 III. Editar o arquivo /etc/smbldap-tools/smbldap_bind.conf 22 slaveDN=”ADMIN DN” 22 slavePw=”SENHA” 22 masterDN=”ADMIN DN” 22 masterPw=”SENHA” 11 IV. Popular a base do OpenLDAP: 22 root# smbldap-populate O pacote smbldap-tools possui um bom conjunto de ferramentas para gerenciar as contas, quando utilizando o Samba com o OpenLDAP. Essas ferramentas permitem o gerenciamento da maioria dos componentes que são necessários para as contas, especialmente para a administração de usuários, máquinas e grupos. Outro ponto positivo desse pacote é que os scripts contidos nele podem ser utilizados como parâmetros no smb.conf. Antes de adicionar as contas na base de dados do LDAP, é necessário criar a estrutura onde serão armazenadas (caso ainda não exista). Para essa tarefa, será utilizado o script smbldap-populate. Para inicializar e popular a base de dados do OpenLDAP com smbldap-populate, é necessário configurar o pacote smbldap-tools, editando os arquivos /etc/smbldap-tools/smbldap. conf e /etc/smbldap-tools/smbldap_bind.conf, para se adequar às características do ambiente. Para isso, os seguintes passos são necessários: Obter o SID do domínio Samba: root# net getlocalsid SID for domain SERVER is: S-1-5-21-3102374607-2088646784-3588851380

Editar o arquivo /etc/smbldap-tools/smbldap.conf. Esse é o arquivo que contém toda a configuração do Samba e do OpenLDAP: root# zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz > /etc/smbldaptools/smbldap.conf

As variáveis a serem configuradas no arquivo smbldap.conf são: 11 SID=”SID DO DOMINIO”: deve conter o SID do domínio, obtido através do comando “net getlocalsid”; 11 sambaDomain=”DOMINIO”: domínio do Samba; 11 slaveLDAP=“ldap://SERVIDOR/”: endereço do servidor LDAP secundário;

11 ldapTLS=“VALOR”: utilizado para configurar a criptografia na conexão com o OpenLDAP. Aceita os valores “1”, para utilizar o start_tls, ou “0”, para desabilitar;

Capítulo 9 - Samba

11 masterLDAP=“ldap://SERVIDOR/”: endereço do servidor LDAP principal;

167

11 verify=“VALOR”: define se verificará o certificado do servidor OpenLDAP. Aceita os valores “none” (não verifica/solicita o certificado), “optional” (verifica o certificado, se existir. Aceita a conexão mesmo se o certificado não existir ou não for válido) e “required” (só aceita a conexão se o certificado existir e for válido); 11 clientcert=“/CAMINHO/CERTIFICADO”: certificado utilizado para se conectar ao servidor OpenLDAP; 11 clientkey=“/CAMINHO/CHAVE”: chave do certificado utilizada para se conectar ao servidor OpenLDAP; 11 suffix=“BASE DN”: define o DN da base da estrutura do diretório no OpenLDAP. Exemplo “dc=empresa,dc=com,dc=br”; 11 usersdn=“DN DOS USUARIOS”: define onde as contas dos usuários serão armazenadas na estrutura do diretório no OpenLDAP. Exemplo “ou=usuarios,${suffix}”; 11 computersdn=“DN DAS MAQUINAS”: define onde as contas das máquinas serão armazenadas na estrutura do diretório no OpenLDAP. Exemplo “ou=maquinas,${suffix}”; 11 groupsdn=“DN DOS GRUPOS”: define onde as contas dos grupos serão armazenadas na estrutura do diretório no OpenLDAP. Exemplo “ou=grupos,${suffix}”; 11 idmapdn=“DN DOS MAPEAMENTOS”: define onde os mapeamentos de UID/SID serão armazenados na estrutura do diretório no OpenLDAP. Exemplo “ou=idmap,${suffix}”; 11 sambaUnixIdPooldn=“VALOR”: onde armazenar os próximos UID e GID disponíveis para as novas contas de usuários e grupos. Exemplo “${sambaDomain},${suffix}”; 11 scope=“VALOR”: escopo padrão utilizado na estrutura do diretório do OpenLDAP. Define o ponto inicial de uma busca e até que nível ela vai a partir da Base DN. Aceita os valores “base” (busca somente no nível da Base DN), “one” (realiza a busca em todas as entradas um nível a seguir da Base DN) e “sub” (realiza a busca em todas as entradas e em todos os níveis a seguir da Base DN); 11 hash_encrypt=“VALOR”: encriptação da senha do Linux. Aceita os valores “CRYPT”, “MD5”, “SMD5”, “SSHA”, “SHA” e “CLEARTEXT”; 11 crypt_salt_format=”%s”: se o parâmetro “hash_encrypt” estiver configurado como “CRYPT”, é possível configurar o formato do salt. O valor padrão é “%s”; 11 userLoginShell=”SHELL”: shell de login do usuário. Exemplo “/bin/bash”;

Administração de Sistemas Linux: Serviços para Internet

11 userHome=”DIRETORIO”: Diretório home do usuário. Exemplo: “/home/%U”;

168

11 userHomeDirectoryMode=”VALOR”: permissão padrão para o diretório home do usuário. Exemplo “700”; 11 userGecos=”DESCRICAO”: campo de GECOS padrão utilizado para a criação das contas dos usuários. Exemplo “Usuário do SAMBA”; 11 defaultUserGid=”GID”: número do GID padrão utilizado para a criação das contas dos usuários. Exemplo “513”; 11 defaultComputerGid=”GID”: número do GID padrão utilizado para a criação das contas de máquinas. Exemplo “515”; 11 skeletonDir=”DIRETORIO”: diretório skel utilizado para a criação das contas de usuários. Exemplo “/etc/skel”; 11 defaultMaxPasswordAge=“NUMERO DE DIAS”: tempo padrão, em dias, da validade das senhas; 11 userSmbHome=“CAMINHO UNC”: o caminho no formato UNC para a localização do

home drive do usuário (aceita a substituição %U para o username – Mesmo valor do parâmetro “logon home” do arquivo smb.conf). Exemplo “\\SMBSERVER\%U”; 11 userProfile=“CAMINHO UNC”: o caminho no formato UNC para a localização do perfil do usuário (aceita a substituição %U para o username – Mesmo valor do parâmetro “logon script” do arquivo smb.conf ). Exemplo “\\SMBSERVER\%U\profiles”; 11 userHomeDrive=“LETRA:”: a letra para o mapeamento padrão do home drive (Mesmo valor do parâmetro “logon drive” do arquivo smb.conf ). Exemplo “H:”; 11 userScript=”SCRIPT.BAT”: o nome do script padrão utilizado para realizar o netlogon do usuário (Mesmo valor do parâmetro “logon script” do arquivo smb.conf). Exemplo: “logon.cmd”; 11 mailDomain=”DOMINIO”: domínio adicionado ao atributo “mail” dos usuários. Exemplo: “empresa.com.br”; Editar o arquivo /etc/smbldap-tools/smbldap_bind.conf, onde as credenciais para conexão com o servidor OpenLDAP são configuradas: root# cp /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf /etc/smbldap-tools/.

Editar os seguintes parâmetros no arquivo smbldap_bind.conf: 11 slaveDN=”ADMIN DN”: define o DN da conta do Administrador do servidor OpenLDAP secundário. Exemplo: “cn=admin,dc=exemplo,dc=com,dc=br”; 11 slavePw=”SENHA”: define a senha do DN da conta do Administrador do servidor OpenLDAP secundário; 11 masterDN=”ADMIN DN”: define o DN da conta do Administrador do servidor OpenLDAP primário. Exemplo: “cn=admin,dc=exemplo,dc=com,dc=br”; 11 masterPw=”SENHA”: define a senha do DN da conta do Administrador do servidor OpenLDAP primário; Popular a base do OpenLDAP: root# smbldap-populate

Esse comando vai ler os arquivos de configuração e criará a estrutura de diretório (caso ainda não exista) dentro do servidor OpenLDAP, conforme definido no arquivo smbldap.conf.

Configurando o Samba PDC para acessar a base de dados LDAP Configurações a serem realizadas no Servidor Samba, para habilitar a comunicação

q

com o LDAP 11 Parâmetros na seção [global] 22 ldap admin dn = ADMIN DN ldap ssl = valor 22 passdb backend = ldapsam:ldap://SERVIDOR[:porta]

22 ldap suffix = BASE DN 22 ldap user suffix = ou=usuarios 22 ldap group suffix = ou=grupos 22 ldap machine suffix = ou=maquinas

Capítulo 9 - Samba

22 ldap delete dn = valor

169

Os seguintes parâmetros devem ser configurados na seção [global] do arquivo smb.conf, para habilitar o uso do LDAP: 11 ldap admin dn = ADMIN DN: define o DN da conta de administrador, utilizada para se conectar ao servidor LDAP. A senha é armazenada no arquivo secrets.tdb, através do comando “smbpasswd -w ‘SENHA’”; 11 ldap ssl = valor: configura a conexão SSL com o servidor LDAP. Aceita os valores ‘off’, ‘on’ (valor padrão) e ‘start tls’; 11 passdb backend = ldapsam:ldap://SERVIDOR[:porta]: configura o backend ldapsam para se conectar ao servidor LDAP. Adicionalmente, pode ser configurada a porta de acesso utilizada; 11 ldap delete dn = valor: especifica se uma operação de remoção realizada no ldapsam apaga o registro inteiro, inclusive da base do LDAP, ou somente os atributos específicos do Samba. Aceita os valores ‘yes’ e ‘no’; 11 ldap suffix = BASE DN: especifica o DN da base do OpenLDAP, utilizada para armazenar o objeto sambaDomain. Exemplo ”dc=empresa,dc=com,dc=br”; 11 ldap user suffix = ou=usuários: esse parâmetro especifica onde as contas dos usuários serão adicionados na estrutura do diretório no OpenLDAP. O valor configurado é adicionado ao valor definido no parâmetro ldap suffix; 11 ldap group suffix = ou=grupos: esse parâmetro especifica onde as contas dos grupos serão armazenados na estrutura do diretório no OpenLDAP. O valor configurado é adicionado ao valor definido no parâmetro ldap suffix; 11 ldap machine suffix = ou=maquinas: esse parâmetro especifica onde as contas das máquinas serão armazenadas na estrutura do diretório no OpenLDAP. O valor configurado é adicionado ao valor definido no parâmetro ldap suffix.

Configurações adicionais 11 O Servidor Samba deve ser configurado como um cliente LDAP

q

11 Configurar a senha do rootDN 22 root# smbpasswd -W 11 Criar o usuário root do Samba (caso ainda não exista): Administração de Sistemas Linux: Serviços para Internet

22 root# smbpasswd –a root 11 Reiniciar o Samba Para que o Sistema Linux do Samba consiga identificar as contas que estão dentro da base do OpenLDAP como usuários válidos, é necessário que o Sistema do Servidor do Samba seja configurado como um cliente LDAP e que os pacotes NSS/PAM e o NSCD estejam instalados e configurados com o suporte para utilizar o LDAP. Outro passo é configurar a senha do rootDN, definida no Samba através do parâmetro ldap admin dn. Essa é a conta que o Samba utiliza para se autenticar e administrar a base de dados do OpenLDAP: root# smbpasswd -W

Criar o usuário root do Samba (caso ainda não exista): root# smbpasswd –a root

Após a configuração do arquivo smb.conf, é necessário reiniciar os serviços do Samba. 170

Configuração de compartilhamento Área de armazenamento que será compartilhada na rede

q

Definida como 11 [nome_do_compartilhamento] É possível criar um compartilhamento público ou restrito a determinados usuários Principais parâmetros para configurar um compartilhamento 11 path 11 comment 11 browseable 11 guest account 11 public 11 guest only 11 write list 11 read list 11 valid users 11 invalid users 11 locking 11 available 11 read only 11 writable 11 create mask 11 directory mask 11 volume Para criar um compartilhamento de rede, é necessário definir a área que será disponibilizada para armazenamento. A definição de um compartilhamento é feita configurando uma seção [nome_do_compartilhamento] no arquivo smb.conf. A seguir um exemplo da configuração de um compartilhamento chamado smbdados. Esse compartilhamento utilizará o diretório /mnt/dados e será acessível a todos os usuários. [smbdados] comment = Espaço para Compartilhamento de Dados path = /mnt/dados writable = yes public = yes

Para restringir o acesso ao compartilhamento, é necessário remover o parâmetro public e

É possível criar vários compartilhamentos, cada um configurado com diferentes controles de acesso e utilizando diferentes áreas de armazenamento. Alguns dos principais parâmetros utilizados para configurar o compartilhamento são: path, comment, browseable, guest account, public, guest only, write list, read list, valid users, invalid users, locking, available, read only, writable, create mask, directory mask e volume.

Capítulo 9 - Samba

definir quais usuários terão direito de acesso, utilizando o parâmetro valid users.

171

Atividades administrativas Comandos de administração pdbedit, smbpasswd e smbldap-tools smbpasswd

q

11 Ferramenta básica, similar aos programas passwd e yppasswd 11 Não depende do backend 11 Utilizada para criar uma conta, alterar uma senha, habilitar/desabilitar uma conta, entre outras atividades pdbedit 11 Criado para administrar o backend tdbsam 11 Consegue configurar as políticas de segunraça 11 Além de realizar as operaçãoes do smbpasswd, também pode: 22 Listar as informações sobre as contas 22 Migrar as contas entre diferentes backends 22 Gerenciar políticas de contas 22 Gerenciar configurações das políticas de acesso do domínio smbldap-tools 11 Possui vários comandos para administrar as contas 22 Criar, remover, modificar, listar, entre outras atividades 22 É o único que consegue alterar diretamente as informações na base de dados do OpenLDAP 22 Só deve ser utilizado quando o Servidor Samba está integrado com o LDAP A ferramenta smbpasswd é similar aos programas passwd e yppaswd. Ela trabalha independentemente dos métodos utilizados para armazenar as contas e as senhas, especificados pelo parâmetro ”passdb backend” no arquivo smb.conf. O smbpasswd funciona em um modo cliente/servidor, onde ele contacta o smbd local para alterar a senha do usuário. Ele também é capaz de alterar senhas de usuários de domínio

Administração de Sistemas Linux: Serviços para Internet

em servidores PDC Windows NT.

172

Outras aplicabilidades do smbpasswd: 11 Adicionar e remover contas de usuário ou de máquina; 11 Habilitar e desabilitar contas de usuário ou de máquina; 11 Configurar como NULL as senhas de usuários; 11 Gerenciar as contas de relação de confiança entre domínios. Quando executado por um usuário normal, o comando smbpasswd permitirá apenas a troca da senha no Samba. Quando executado pelo usuário root, o comando aceita argumentos opcionais, como o utilizado para especificar o usuário que será alterado. O pdbedit é uma ferramenta que só pode ser executada pelo root. Ele é utilizado para gerenciar o passdb backend, assim como várias configurações de políticas de segurança das contas do domínio. Além de ser capaz de realizar todas as operações do smbpasswd, ele também pode:

11 Listar as informações sobre as contas de usuários, grupos e máquinas; 11 Migrar as contas de usuários, grupos e máquinas entre diferentes mecanismos de armazenamento; 11 Gerenciar políticas de contas; 11 Gerenciar configurações das políticas de acesso do domínio. Os principais controles de políticas da conta do Samba

q

11 maximum password age 11 minimum password age 11 min password length 11 password history 11 bad lockout attempt 11 lockout duration Os principais controles de políticas da conta do Samba são: 11 maximum password age: a validade máxima das senhas, em segundos. O valor ‘-1’ representa que as senhas nunca expiram; 11 minimum password age: a validade mínima das senhas, em segundos. A senha não pode ser alterada antes desse tempo; 11 min password length: o tamanho mínimo das senhas; 11 password history: número de senhas armazenadas que foram utilizadas previamente. Utilizado para impedir o usuário de reutilizar a mesma senha; 11 bad lockout attempt: número de tentativas de logon que falharam antes da conta ser bloqueada; 11 lockout duration: tempo de duração do bloqueio de conta, definido em minutos. O pdbedit é a única ferramenta que pode gerenciar as configurações de segurança, as políticas e flags de controle de conta. Uma funcionalidade interessante dele é a capacidade de importar e exportar informações de um tipo de passdb backend para outro tipo (Por exemplo: tdbsam > ldapsam). O pdbedit, assim como o smbpasswd, necessita que uma conta de usuário POSIX já exista na base de contas de usuários do sistema Linux. Nenhuma das duas ferramentas criará automaticamente a conta no sistema. O pacote smbldap-tools possui vários comandos que são utilizados para administrar as contas. Através deles é possível alterar todos os campos das contas armazenadas na base de dados do OpenLDAP.

Os comandos de administração do Samba possuem vários parâmetros, e são utilium dos comandos (man smbpasswd, man pdbedit etc.).

Capítulo 9 - Samba

zados para as mais diversas atividades. É recomendado estudar o manual de cada

173

Gerenciamento de Conta de Usuários Criar conta

q

Utilizando o backend tdbsam 11 Criar a conta no Linux 22 root# useradd -c “Descricao” -m USUARIO 22 root# passwd USUARIO 11 Criar a conta no Samba 22 root# smbpasswd -a USUARIO ou 22 root# pdbedit -a -u USUARIO

Utilizando o backend ldapsam (através do smbldap-tools) 11 root# smbldap-useradd -a -P USUARIO Utilizando o backend tdbsam: #Criar a conta no Linux root#

useradd -c “Descricao” -m

root#

passwd USUARIO

USUARIO

#Criar a conta no Samba root#

smbpasswd -a USUARIO

ou root#

pdbedit -a -u USUARIO

Utilizando o backend ldapsam (através do smbldap-tools): root#

smbldap-useradd -a -P USUARIO

Remover conta Utilizando o backend tdbsam

Administração de Sistemas Linux: Serviços para Internet

11 root# pdbedit -x USUARIO

174

11 root# userdel USUARIO

Utilizando o backend ldapsam (através do smbldap-tools) 11 root# smbldap-userdel USUARIO Utilizando o backend tdbsam: root#

pdbedit -x USUARIO

root#

userdel USUARIO

Utilizando o backend ldapsam (através do smbldap-tools): root# smbldap-userdel USUARIO

q

Listar conta Utilizando o backend tdbsam

q

11 root# pdbedit -L 11 root# pdbedit -Lv USUARIO

Utilizando o backend ldapsam (através do smbldap-tools) 11 root# smbldap-userlist -u 11 root# smbldap-usershow USUARIO Utilizando o backend tdbsam: root#

pdbedit -L

root#

pdbedit -Lv USUARIO

Utilizando o backend ldapsam (através do smbldap-tools): root#

smbldap-userlist -u

root#

smbldap-usershow USUARIO

Outros comandos 11 Verificar usuários conectados ao Servidor Samba

q

22 root# smbstatus

11 Alterar a informação da conta 22 root# pdbedit -r –-fullname=”Nome completo do Usuário” USUARIO ou 22 root# smbldap-usermod --givenName “Nome” --surName “Sobrenome” USUARIO

11 Alterar a data da expiração da senha 22 root# pdbedit --pwd-must-change-time=”2017-01-01” --time-format=”%Y-%m-%d” USUARIO ou 22 root# smbldap-usermod --sambaExpire “2017-01-01” USUARIO

11 Alteração das flags da conta 22 root# pdbedit -r -c “[DLX]” USUARIO ou

11 Desabilitar uma conta 22 root# smbpasswd -d USUARIO ou 22 root# smbldap-usermod -I USUARIO

Capítulo 9 - Samba

22 root# smbldap-usermod -H “[DLX]” USUARIO

175

11 Habilitar uma conta 22 root# smbpasswd -e USUARIO ou 22 root# smbldap-usermod -J USUARIO

11 Alterar a senha 22 root# passwd USUARIO 22 root# pdbedit -a USUARIO ou 22 root# smbldap-passwd USUARIO Alguns outros comandos e exemplos de atividades administrativas que regularmente são executados. Verificar usuários conectados ao Servidor Samba root# smbstatus

Alterar a informação da conta root#

pdbedit -r –-fullname=”Nome completo do Usuário” USUARIO

ou root#

smbldap-usermod --givenName “Nome” --surName “Sobrenome” USUARIO

Alterar a data da expiração da senha root#

pdbedit --pwd-must-change-time=”2017-01-01” --time-format=”%Y-%m-%d”

USUARIO

ou root#

smbldap-usermod --sambaExpire “2017-01-01” USUARIO

Alteração das flags da conta

Administração de Sistemas Linux: Serviços para Internet

root#

176

pdbedit -r -c “[DLX]” USUARIO

ou root#

smbldap-usermod -H “[DLX]” USUARIO

Nesse exemplo, a conta será bloqueada (D), ativará o bloqueio automático (L) e a senha não vai expirar (X).

Desabilitar uma conta root#

smbpasswd -d USUARIO

ou root#

smbldap-usermod -I USUARIO

q

Habilitar uma conta root#

smbpasswd -e USUARIO

ou root#

smbldap-usermod -J USUARIO

Alterar a senha root#

passwd USUARIO

root#

pdbedit -a USUARIO

ou root#

smbldap-passwd USUARIO

Gerenciamento de Grupos Criar grupos Utilizando o backend ldapsam (através do smbldap-tools):

q

11 root# smbldap-groupadd -a GRUPO Mapear um grupo já existente 11 root# smbldap-groupmod -a GRUPO Utilizando o backend ldapsam (através do smbldap-tools): root#

smbldap-groupadd -a GRUPO

Esse comando criará o grupo UNIX/Linux e realizará o mapeamento automaticamente para um grupo do Windows, associando um SID. Para realizar esse mapeamento a um grupo UNIX/Linux já existente, é necessário executar o comando: root#

smbldap-groupmod -a GRUPO

Remover grupo Utilizando o backend ldapsam (através do smbldap-tools):

q

11 root# smbldap-groupdel GRUPO Utilizando o backend ldapsam (através do smbldap-tools): root#

smbldap-groupdel GRUPO

Listar grupo Utilizando o backend ldapsam (através do smbldap-tools):

q

11 root# smbldap-grouplist -tS 11 root# smbldap-groupshow GRUPO

root#

smbldap-grouplist -tS

root#

smbldap-groupshow GRUPO

Capítulo 9 - Samba

11 Utilizando o backend ldapsam (através do smbldap-tools):

177

Gerenciamento de conta de máquinas A conta de máquina pode ser criada automaticamente quando o cliente ingressa em um domínio e o parâmetro add machine script está configurado no smb.conf. Os comandos para criação manual estão descritos a seguir:

Criar conta de máquina Utilizando o backend tdbsam:

q

11 root# useradd -g GRUPO-DE-MAQUINAS -M -d /dev/null -c “MAQUINA DO DOMINIO” -s /bin/false NOME-DA-MAQUINA$ 11 root# passwd -l NOME-DA-MAQUINA$ 11 root# pdbedit -a -m -u NOME-DA-MAQUINA Utilizando o backend ldapsam (através do smbldap-tools): 11 root# smbldap-useradd -W NOME-DA-MAQUINA Utilizando o backend tdbsam: root#

useradd -g GRUPO-DE-MAQUINAS -M -d /dev/null -c “MAQUINA DO DOMINIO” -s /

bin/false NOME-DA-MAQUINA$ root#

passwd -l NOME-DA-MAQUINA$

root#

pdbedit -a -m -u NOME-DA-MAQUINA

Utilizando o backend ldapsam (através do smbldap-tools): root# smbldap-useradd -W NOME-DA-MAQUINA

Remover conta de máquina Utilizando o backend tdbsam:

q

11 root# pdbedit -x -m -u NOME-DA-MAQUINA 11 root# userdel NOME-DA-MAQUINA$ Utilizando o backend ldapsam (através do smbldap-tools): 11 root# smbldap-userdel NOME-DA-MAQUINA$

Administração de Sistemas Linux: Serviços para Internet

Utilizando o backend tdbsam:

178

root#

pdbedit -x -m -u NOME-DA-MAQUINA

root#

userdel NOME-DA-MAQUINA$

Utilizando o backend ldapsam (através do smbldap-tools): root#

smbldap-userdel NOME-DA-MAQUINA$

Listar conta de máquina Utilizando o backend ldapsam: 11 root# smbldap-userlist -m 11 root# smbldap-usershow NOME-DA-MAQUINA$ Utilizando o backend ldapsam: root#

smbldap-userlist -m

root#

smbldap-usershow NOME-DA-MAQUINA$

q

Alterar as políticas das contas do domínio Listar as políticas root#

pdbedit -P “?”

root#

pdbedit -P “NOME_DA_POLITICA”

Alterar uma política Listar as políticas

q

11 root# pdbedit -P “?” 11 root# pdbedit -P “NOME_DA_POLITICA” O comando para alterar uma política é: 11 root# pdbedit -P “NOME_DA_POLITICA” -c VALOR Exemplos: 11 Definir que o tamanho mínimo de senha seja de 8 caracteres: 22 root# pdbedit -P “min password length” -C 8 11 Definir que a validade máxima da senha seja de 90 dias: 22 root# pdbedit -P “maximum password age” -C 7776000 O comando para alterar uma política é: root#

pdbedit -P “NOME_DA_POLITICA” -c VALOR

Exemplos: Definir que o tamanho mínimo de senha seja de 8 caracteres: root#

pdbedit -P “min password length” -C 8

Definir que a validade máxima da senha seja de 90 dias: pdbedit -P “maximum password age” -C 7776000

Capítulo 9 - Samba

root#

179

180

Administração de Sistemas Linux: Serviços para Internet

10 Aprender a teoria e prática do serviço DHCP; Conhecer formas de transferência de arquivos entre computadores; Entender o funcionamento do File Transfer Protocol (FTP); Analisar formas seguras de transferência de arquivos envolvendo encriptação e autenticação, inclusive na administração remota de outros servidores e backup.

conceitos

Fundamentos, funcionamento e a estrutura do Dynamic Host Configuration Protocol (DHCP), do File Transfer Protocol (FTP) e do SSH (Secure Shell).

Introdução O estudo deste capítulo está dividido em três partes: DHCP, FTP e SSH. Na primeira parte são abordados aspectos teóricos e práticos do serviço DHCP, sendo examinadas algumas possibilidades de uso dessa solução. Na segunda parte serão estudadas as formas de transferência de arquivos entre computadores, com o serviço FTP, associadas a grupos de usuários e pastas. Na última parte conheceremos formas seguras de transferência de arquivos, que envolvem encriptação e autenticação, inclusive na administração remota de outros servidores e backup.

DHCP Protocolo de rede cuja função é atribuir informações TCP/IP para as máquinas clientes.

q

As informações são concentradas em um servidor (DHCP), que passa para as máquinas clientes informações como: 11 Endereço IP e máscara de rede. 11 Gateway. 11 Servidor DNS. 11 Domínio. O protocolo Dynamic Host Configuration Protocol (DHCP) provê, através de um servidor DHCP, informações para estações IP em uma rede. Possui dois componentes: (I) um proto-

Capítulo 10 - DHCP, FTP e SSH

objetivos

DHCP, FTP e SSH

colo para distribuir parâmetros de configuração específicos a partir de um servidor DHCP; 181

(II) um mecanismo para alocação de endereços de rede para as estações. É baseado na arquitetura cliente e servidor, onde o servidor DHCP distribui endereços IP e parâmetros de configuração de rede para as estações, tais como: máscara de sub-rede; endereço do roteador de saída (gateway); informações de domínio e outras que serão mencionadas adiante. Existem alguns protocolos que fornecem recursos utilizados pelo protocolo DHCP, tais como: bOOTP; Reverse Address Resolution Protocol (RARP), através do Dynamic RARP (DRARP); Trivial File Transfer Protocol (TFTP) e internet Control Message Protocol (ICMP). 11 BOOTP: mecanismo de transporte de informações de configuração. Permite que estações diskless obtenham um endereço IP, o endereço IP do servidor BOOTP, e um arquivo a ser carregado em memória para realizar o boot do sistema. Pode ser utilizado ainda como relay para servidores DHCP, eliminando a necessidade de um servidor DHCP em cada rede física; 11 RARP: protocolo que permite a obtenção de um endereço IP a partir de um endereço MAC. Uma estação envia uma mensagem de broadcast na rede com a finalidade de que o servidor DHCP lhe forneça um endereço IP; 11 TFTP: protocolo utilizado para transferência de arquivos, no qual cada pacote é confirmado (ACK) individualmente; 11 ICMP: protocolo utilizado para permitir que estações localizem roteadores por meio de mensagens ICMP Redirect. Motivação:

q

11 Ferramenta que facilita a administração de redes. Funcionalidades: 11 Controla a forma de atribuição de endereços IP às máquinas cliente da rede. 11 Estabelecimento de faixas de endereços utilizados. 11 Informações para as máquinas clientes referentes aos endereços do roteador de saída (gateway), servidor DNS e domínio. O serviço DHCP foi projetado para suportar as RFCs associadas aos requisitos para funcionamento das estações. Após a obtenção dos parâmetros por meio do protocolo DHCP, as estações devem ser capazes de trocar pacotes com qualquer outra na internet.

Administração de Sistemas Linux: Serviços para Internet

O DHCP suporta três mecanismos para alocação de endereços IP:

182

q

11 Alocação automática. 11 Alocação dinâmica. 11 Alocação manual. O DHCP suporta três mecanismos para alocação de endereços IP: 11 Alocação automática: um endereço IP é atribuído permanentemente para uma estação; 11 Alocação dinâmica: um endereço IP é atribuído para uma estação por um período determinado de tempo; 11 Alocação manual: um endereço IP é atribuído para uma estação pelo administrador da rede, o que é feito por meio do arquivo de configuração do DHCP. Podemos utilizar um ou mais desses mecanismos ao mesmo tempo em uma determinada rede. Uma estação cliente deve ser capaz de descobrir os parâmetros necessários ao seu funcionamento, inserindo-os automaticamente em seu sistema sem intervenção manual.

Do mesmo modo, o servidor deve funcionar de maneira automática sem a necessidade de intervenção manual do administrador para o funcionamento de cada estação cliente, exceto em casos especiais onde seja necessário fixar determinado endereço a um cliente específico. O Servidor deve ainda suportar estações que utilizem o protocolo BOOTP (RFC 2132), IPv6 (RFC 4361), SIP (RFC 3319) e IEEE 1394 (RFC 2855).

OP (1)

HTYPE (1)

HLEN (1)

HOPS (1)

XID (4) SECS (2)

FLAGS (2) CIADDR (4) YIADDR (4) SIADDR (4) GIADDR (4) CHADDR (16) SNAME (64)

Figura 10.1 Formato de uma mensagem DHCP indicando campos e tamanho em bytes.

FILE (128) OPTIONS (variável)

Campos em uma mensagem DHCP OP (Operation Code)

q

HTYPE (Hardware Address Type) HLEN (Hardware Address Length) HOPS XID (Transaction ID) SECS FLAGS

YIADDR (Your Client IP Address) SIADDR (Server IP Address) GIADDR (Gateway IP Address) CHADDR (Client Hardware Address) SNAME (Server Name) FILE (Boot Filename)

Capítulo 10 - DHCP, FTP e SSH

CIADDR (Client IP Address)

OPTIONS 183

11 OP (Operation Code): em uma mensagem DHCP, uma solicitação e uma resposta possuem os mesmos campos. O que as diferenciam é o conteúdo do campo OP. Os valores são: 22 1 = DHCPDISCOVER 22 2 = DHCPOFFER 22 3 = DHCPREQUEST 22 4 = DHCPDECLINE 22 5 = DHCPPACK 22 6 = DHCPNACK 22 7 = DHCPRELEASE 22 8 = DHCPINFORM 11 HTYPE (Hardware Address Type): informa o padrão de rede utilizado pelo adaptador de rede; 11 HLEN (Hardware Address Length): especifica o tamanho do endereço de hardware na mensagem, valor 6 para endereço MAC; 11 HOPS: quantidade de roteadores pelos quais a mensagem deverá passar; 11 XID (Transaction ID): número de identificação, gerado aleatoriamente pelo cliente, utilizado para associar uma requisição à resposta recebida do servidor DHCP; 11 SECS: segundos desde que o cliente iniciou o processo de aquisição ou renovação de endereço; 11 FLAGS: primeiro bit 1 para broadcast; demais reservados para uso futuro; 11 CIADDR (Client IP Address): campo preenchido pelo cliente com o endereço IP atual, durante o processo de renovação; 11 YIADDR (Your Client IP Address): endereço IP que o servidor está atribuindo ao cliente; 11 SIADDR (Server IP Address): endereço IP, informado pelo servidor DHPC, do próximo servidor a ser utilizado no processo de boot; 11 GIADDR (Gateway IP Address): endereço IP do roteador da rede local, utilizado quando o boot é realizado por meio deste;

Administração de Sistemas Linux: Serviços para Internet

11 CHADDR (Client Hardware Address): endereço de hardware do cliente;

184

11 SNAME (Server Name): campo opcional que define o nome do servidor DHCP; 11 FILE (Boot Filename): nome do arquivo de boot. Nulo em mensagem DHCPDISCOVER; caminho completo de arquivo em DHCPOFFER; 11 OPTIONS: parâmetros opcionais. Esse campo é utilizado para informar que tipo de resposta ou solicitação DHCP (DHCPDISCOVER, DHCPOFFER etc.) está sendo enviada para o cliente ou para o servidor.

Funcionamento do protocolo DHCP

q

Cliente envia DHCPDISCOVE O servidor pode responder DHCPOFFER O cliente envia DHCPREQUEST O servidor salva as configurações e responde com DHCPACK O cliente realiza verificações utilizando. Pode responder com DHCPDECLINE – problema com a configuração. O servidor envia, se necessário, DHCPNACK – reiniciando o processo;

Lado cliente

Mensagens

Lado servidor

DHCPDISCOVER Determina Recebe resposta Cliente DHCP

DHCPOFFER DHCPREQUEST DHCPACK DHCPRELEASE

Libera lease

Figura 10.2 Funcionamento do protocolo DHCP

configuração

Commit

Servidor DHCP

Inicialização completa

Tempo Durante a obtenção dos parâmetros de configuração, algumas mensagens são trocadas entre o servidor e o cliente DHCP. A seguir é descrita a sequência desses comandos com seus respectivos significados: 11 Cliente envia mensagem broadcast DHCPDISCOVER. Inclui o endereço físico, podendo incluir sugestão de endereço IP e duração do lease; 11 O servidor pode responder com uma mensagem DHCPOFFER, que inclui um endereço IP disponível no campo YIADDR e outros parâmetros em OPTIONS. O servidor verifica a disponibilidade do endereço IP antes de disponibilizá-lo; 11 O cliente envia uma mensagem DHCPREQUEST que inclui o identificador do servidor DHCP. Isso é necessário para o caso de o cliente receber respostas de mais de um servidor DHCP; 11 O servidor, após receber a mensagem, salva as configurações e responde com uma mensagem DHCPACK contendo as configurações ofertadas anteriormente; 11 O cliente efetua uma verificação utilizando o protocolo ARP com o endereço fornecido. o cliente receba uma mensagem DHCPNACK, o processo é reiniciado; 11 O cliente pode ainda liberar o endereço informando seu CHADDR. Caso o cliente já saiba o endereço IP, desejando apenas renová-lo, enviará diretamente um DHCPREQUEST. É necessário efetuar algumas verificações antes da edição do arquivo de configuração e ativação do servidor DHCP. Entre elas: verificar se o daemon está instalado e conferir a sua localização, assim como a existência do arquivo com a base de dados e a forma de interação

Capítulo 10 - DHCP, FTP e SSH

Caso perceba que o endereço já está em uso, envia uma mensagem DHCPDECLINE. Caso

com o serviço DNS. 185

Instalação do DHCP

q

11 Red Hat / CentOS: yum install dhcp 11 Debian / Ubuntu Server: apt-get install isc-dhcp-server 11 Criar o arquivo dhcpd.leases 11 Definir o esquema de interação com o DNS 1. Verificar se o daemon está instalado: Conferir localização do daemon dhcpd. # whereis dhcpd

Instalar o Servidor do DHCP Red Hat / CentOS # yum install dhcp

Debian / Ubuntu Server apt-get install isc-dhcp-server

2. Criação do arquivo dhcpd.leases: Verificar existência do arquivo dhcpd.leases, que deverá existir quando da execução do servidor DHCP.

# find / –name dhcpd.leases

Deve retornar algo do tipo: /var/lib/dhcp/dhcpd.leases. Caso o arquivo dhcpd.leases não exista, deverá ser criado.

# touch /var/lib/dhcp/dhcp.leases

3. Escolha do esquema de interação com o DNS: Existem dois métodos de interação entre o DHCP e o DNS: ddns-update-style interim – permite o uso de mecanismo failover. Esse mecanismo possibilita que dois ou mais servidores DHCP dividam o conjunto de endereços IP disponíveis.ddns-update-style ad-hoc:

Administração de Sistemas Linux: Serviços para Internet

opção descontinuada e que não deve ser utilizada.

186

Deve-se escolher o método a ser utilizado pelo servidor. A opção deve ser incluída no início do arquivo dhcpd.conf.

Edição de arquivos de configuração Criar o arquivo de configuração dhcpd.conf, que consiste em: 11 Informações de cabeçalho. 11 Parâmetros. 11 Declarações. 11 Comentários. As opções podem ser: 11 Globais, posicionadas antes das { }. 11 Específicas para cada cliente.

q

O arquivo de configuração dhcpd.conf possui os valores a serem passados como parâmetros de configuração para as estações clientes. Possui uma estrutura com quatro componentes: cabeçalho, parâmetros, declarações e comentários. 11 Cabeçalho: esquema de interação entre DHCP e DNS, conforme visto anteriormente; 11 Parâmetros: como, quando e quais informações devem ser enviadas aos clientes. Os parâmetros iniciados pela palavra option não são obrigatórios e não interferem no funcionamento do servidor; no entanto, a ausência de alguns deles pode causar problemas para as estações cliente; 11 Declarações: informações sobre a topologia da rede, incluindo sub-redes, endereços fixos destinados a clientes específicos e especificação de domínio; 11 Comentários: linhas iniciadas com # são consideradas como comentários. Quaisquer mudanças nos arquivos de configuração somente terão efeito após a reinicialização do servidor. Exemplo de arquivo de configuração com alguns valores típicos: # Arquivo dhcpd.conf

ddns–update–style interim;



subnet 192.168.0.0 netmask 255.255.255.0 {



option routers 192.168.0.254;



option subnet–mask 255.255.255.0;



option domain–name “empresa.com.br”;



option domain–name–servers 192.168.0.253;



default-lease-time –18000;



range 192.168.0.2 192.168.0.250;

}

O conteúdo do arquivo de configuração apresentado indica: 11 Interação com DNS: ddns-update-style interim; 11 Servidor responsável por distribuir informações na rede: 192.168.0.0/255.255.255.0; 11 Parâmetros utilizados: 22 routers: indica gateway; 22 subnet-mask: máscara de sub-rede; 22 domain-name: nome do domínio; 22 domain-name-servers: endereço do servidor DNS; 22 default-lease-time: tempo de lease, representado em segundos; o valor 0xffffffff é utilizado para representar o infinito;

Capítulo 10 -

22 range: faixa de endereços IP que o servidor DHCP utilizará para configurar os clientes.

187

Exemplos de configuração # Arquivo dhcpd.conf

ddns–update–style interim;



subnet 192.168.0.0 netmask 255.255.255.0 {



option routers 192.168.0.254;



option subnet–mask 255.255.255.0;



option domain–name “empresa.com.br”;



option domain–name–servers 192.168.0.253;



default-lease-time –18000;



range 192.168.0.2 192.168.0.250;

}

Outro exemplo de arquivo de configuração, nesse caso para duas sub-redes com VLANs diferentes: # Arquivo dhcpd.conf ddns-update-style interim; default-lease-time -18000; max-lease-time -18000; option domain-name-servers 192.168.0.253; #Rede vlan 10 subnet 192.168.10.0 netmask 255.255.255.0 {

option routers 192.168.10.254;



option domain-name “rede10.empresa.com.br”;



range 192.168.10.11 192.168.10.19;

} #Rede vlan 20 subnet 192.168.20.0 netmask 255.255.255.0 {

option routers 192.168.20.254;



option domain-name “rede20.empresa.com.br”;



range 192.168.20.21 192.168.20.29;

}

Administração de Sistemas Linux: Serviços para Internet

Para que essa configuração com VLAN funcione corretamente, é necessário que as

188

interfaces estejam configuradas corretamente com o ID de cada VLAN e disponíveis para o DHCP. A seguir, é apresentado outro exemplo de arquivo de configuração. Nesse caso, com a inclusão de grupo e de IP fixos para determinadas máquinas da rede: # Arquivo dhcpd.conf

ddns–update–style interim;



group {



option routers 192.168.1.254;



option subnet mask 255.255.255.0;



option domain–name “empresa.com.br”;



option domain–name–servers 192.168.0.253;



default-lease-time –18000;



max-lease-time –18000;



host leao {

q



option host–name “leao.empresa.com.br”;



hardware ethernet 00:D0:B7:89:7E:5E;

fixed-address 192.168.0.2;

}



host tigre {



option host–name “tigre.empresa.com.br”;



hardware ethernet 00:D0:B7:89:01:D1;

fixed-address 192.168.0.3;

}

}

Iniciando e parando o servidor Red Hat / CentOS

q

11 systemctl dhcpd Debian / Ubuntu Server 11 service isc-dhcp-server Parâmetro: start, stop ou restart Red Hat / CentOS systemctl dhcpd

Debian / Ubuntu Server service isc-dhcp-server Parâmetro: start, stop ou restart Observação: o arquivo dhcpd.leases deverá existir.

Quando o servidor dispõe de mais de uma interface de rede, podemos especificar qual interface o servidor utilizará para ouvir as requisições DHCP. Essa funcionalidade é extremamente útil quando o servidor se encontra conectado a uma rede interna a qual deve prover DHCP, e a uma rede externa a qual não se deseja acesso ao DHCP. Por padrão, o daemon do DHCP só ouvirá nas interfaces para as quais ele encontrar uma declaração de sub-rede no arquivo de configuração dhcpd.conf. Se for necessário restringir explicitamente quais interfaces ele utilizará, é necessário realizar os seguintes passos: Red Hat / CentOS root# cp /usr/lib/systemd/system/dhcpd.service /etc/systemd/system/ root# vi /etc/systemd/system/dhcpd.service > ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid root# systemctl --system daemon-reload root# systemctl restart dhcpd.service

Editar a variável INTERFACES, no arquivo /etc/default/isc-dhcp-server, adicionando as interfaces a serem utilizadas.

Capítulo 10 -

Debian / Ubuntu Server

189

Podem ser passados parâmetros como: 11 -p : especifica a porta na qual o servidor DHCP atuará; padrão 67 e 68; 11 -f: executa o servidor em foreground; 11 -d: modo debugging: os logs são gerados para a tela, em vez de serem enviados para / var/log/messages; 11 -cf : especifica a localização do arquivo de configuração dhcpd.conf. Originalmente em /etc/dhcp/dhcpd.conf; 11 -lf : especifica a localização do arquivo de lease. Originalmente em / var/lib/dhcp/dhcpd.leases. No Red Hat / CentOS, esses parâmetros são configurados no arquivo /etc/systemd/ system/dhcpd.service, direto na linha de inicialização do daemon. Já no Debian / Ubuntu Server, são configurados na variável OPTIONS do arquivo /etc/default/isc-dhcp-server.

A configuração de um cliente DHCP pode ser efetuada em dois momentos: (I) durante a instalação do Sistema Operacional; (II) em qualquer momento, se for realizada pelo usuário com privilégios de administrador da máquina. Durante o processo de instalação do Sistema Operacional, surgirá uma mensagem solicitando que seja escolhida a opção de configuração da rede: automática (DHCP) ou manual. Escolhendo a opção automática, a máquina iniciará o processo para obtenção dos parâmetros de rede. Após o processo de instalação, a configuração pode ser feita por meio de interface gráfica ou linha de comando. Para a configuração por linha de comando, o arquivo a ser editado é /etc/sysconfig/network-scripts/ifcfg-eth0, nas distribuições Red Hat/CentOS, ou no arquivo /etc/network/interfaces, no Ubuntu Server.

File Transfer Protocol (FTP) Transferência de arquivo confiável de/para servidores de arquivos.

q

11 Upload: transferência de arquivos para um servidor.

Administração de Sistemas Linux: Serviços para Internet

11 Download: transferência de arquivos de um servidor.

190

Tipos de arquivos transferidos: 11 Arquivos texto: manipulados como sendo compostos por uma cadeia de caracteres ASCII ou EBCDIC. 11 Arquivos binários: formados por uma sequência de octetos transferidos sem qualquer conversão. O protocolo File Transfer Protocol (FTP) está entre os meios mais populares utilizados para transferência de arquivos pela internet. Há vários servidores FTP disponíveis tanto na internet quanto em redes locais, utilizados para distribuição de conteúdo, documentos etc. Muitos servidores web se utilizam do recurso FTP como meio para disponibilizar arquivos e programas. A facilidade de acesso aos dados e a confiabilidade provida pelo Transmission Control Protocol (TCP) são fatores que estimulam seu uso. Existem vários servidores FTP disponíveis para o Linux. Entre os mais populares estão o VSFTPD e o PROFTPD.

Esse serviço pode ser configurado para permitir o acesso a todo e qualquer usuário, denominado anônimo, ou para restringir o acesso a determinados usuários. Em ambos os casos podemos determinar quem acessa o quê e os privilégios que possui nas pastas que acessa. Podemos ainda efetuar ajustes para facilitar a passagem por meio de firewalls, para utilização de múltiplos servidores virtuais, e também para permitir o uso por grupos de usuários. O administrador de um servidor FTP tem pleno controle sobre quem pode acessar o quê. Nesse caso, podemos escolher entre permitir ou restringir o acesso de usuários anônimos. Podemos ainda relacionar usuários cadastrados a determinadas pastas. Em todos os casos os privilégios de leitura, escrita, criação ou remoção de arquivos e pastas podem ser controlados. De modo geral há dois tipos de usuários: 11 Usuário normal: usuário cadastrado. Possui login e senha, e por meio deles acessa determinadas pastas e arquivos; 11 Usuário anônimo: usuário que acessa o serviço sem ser autenticado. De modo geral possui somente permissão de leitura, podendo efetuar download de arquivos considerados públicos. Nos dois casos é possível conceder privilégios de leitura (download) e escrita (upload) a determinadas pastas e arquivos. Entretanto, recomenda-se manter o usuário com acesso somente para leitura e na pasta pública. Caso não seja necessário um usuário anônimo, é desejável ainda bloquear o acesso desse tipo de usuário.

Figura 10.3 Funcionamento do FTP.

Funcionamento do FTP Baseado no estabelecimento de conexões entre o cliente e o servidor:

q

1 Conexão de controle: usada na transferência de arquivos. 1 Conexão de dados: uma para cada arquivo transferido. O protocolo FTP é baseado em conexões TCP. No entanto, existem dois tipos de conexão: 11 Conexão de controle: estabelecida e mantida durante todo o tempo de sessão. É através dessa conexão que são enviados os comandos; 11 Conexões de dados: estabelecidas sempre que é solicitada uma transferência de dados. Cada um desses arquivos é transferido em uma conexão separada. Pode haver múltiplas

Capítulo 10 -

conexões simultâneas.

191

Tipos de servidor FTP FTP ativo Conexão de controle De: porta alta cliente Para: porta 21 servidor

Conexão de dados Cliente FTP

De: porta 20 servidor Para: porta alta cliente

Servidor FTP

FTP passivo Conexão de controle De: porta alta cliente Para: porta 21 servidor

Conexão de dados Cliente FTP

De: porta alta cliente Para: porta alta servidor

Servidor FTP

Um servidor FTP pode funcionar no modo passivo ou ativo. Nos dois casos existem as conexões de controle e as conexões de dados. A diferença está na parte que origina cada conexão.

Servidor FTP ativo Cliente utiliza uma conexão de controle com o servidor

q

11 É utilizado uma porta alta no cliente 11 É utilizado a porta 21 no servidor O servidor inicia a transferência de arquivos 11 Origem na porta 20 do servidor O cliente se conecta ao servidor por meio de uma conexão de controle, que se origina em uma porta alta do cliente e se destina à porta 21 do servidor. Quando é solicitado o envio de arquivos, o servidor inicia uma conexão de dados que se origina na porta 20 do servidor e se destina a uma porta alta no cliente. Desse modo, a conexão de controle é iniciada pelo cliente, e as conexões de dados são iniciadas pelo servidor.

Administração de Sistemas Linux: Serviços para Internet

O acesso a um servidor ativo muitas vezes é bloqueado pelo firewall da rede, uma vez que as

192

conexões de dados são iniciadas por máquinas de fora da rede e com destino a máquinas na rede interna.

A resposta ao comando ls, que lista os diretórios do servidor, é enviada pela porta 20.

Servidor FTP passivo Cliente utiliza uma conexão de controle com o servidor 11 É utilizado uma porta alta no cliente 11 É utilizado a porta 21 no servidor O cliente que inicia a transferência de arquivos 11 Origem em uma porta alta do cliente com destino a porta 20 do servidor

q

Figura 10.4 Tipos de Servidores – Ativo e Passivo.

O cliente se conecta ao servidor por meio de uma conexão de controle, que se origina em uma porta alta do cliente e se destina à porta 21 do servidor. A diferença é que, quando é solicitada a transferência de arquivos, a conexão de dados é iniciada por uma porta alta do cliente e se destina a uma porta alta no servidor. Desse modo, o servidor nunca inicia uma conexão TCP, que é sempre iniciada pelo cliente. Essa opção funciona melhor quando o cliente está protegido por um firewall Alguns comandos utilizados para conexão ao servidor FTP e envio ou recebimento de arquivos: 11 ?: ajuda dos comandos; 11 binary: coloca as transferências em modo binário; 11 bye: termina a sessão de FTP e sai; 11 cd: muda de diretório a ser trabalhado; 11 close: termina apenas sessão do FTP; 11 delete: remove um arquivo do servidor; 11 dir: cria uma lista de arquivos do diretório; 11 get: recebe um arquivo; 11 help: exibe a ajuda do servidor local; 11 cd: muda o diretório; 11 ls: lista o conteúdo dos diretórios; 11 rmdelete: remove vários arquivos; 11 mget: recebe vários arquivos; 11 mkdir: cria um diretório no servidor; 11 mput: envia vários arquivos; 11 open: conecta a um servidor FTP; 11 put: envia um arquivo; 11 pwd: exibe o nome do diretório atual; 11 quit: termina a sessão do FTP e sai; 11 recv: recebe um arquivo; 11 rename: renomeia um arquivo.

Problemas com firewall Firewalls normalmente não aceitam conexões de entrada.

q

Considerações de segurança: 11 Restrição de acesso a usuários. 11 Envio de arquivo como anônimo (Anonymous Upload). 11 Mudar banner de saudação. 11 Utilização de SCP como alternativa ao FTP.

uma conexão ao servidor FTP normalmente. Entretanto, ao utilizar os comandos ls, dir ou get, o que inicia uma conexão de dados originada do servidor FTP em direção ao cliente, a transação é bloqueada impedindo o uso do serviço. Para isso são possíveis duas soluções:

Capítulo 10 -

Firewalls normalmente não aceitam conexões de entrada. Desse modo, um cliente inicia

193

1. Utilizar o servidor FTP em modo ativo: criar regras que permitam o funcionamento das conexões de controle e de dados. Em especial o estabelecimento de uma conexão originada do servidor FTP, caso não seja permitido utilizar servidor passivo; 2. Utilizar o servidor FTP em modo passivo: criar regras que permitam o estabelecimento de conexões de controle e de dados originadas a partir do cliente. Ao configurar o servidor FTP, é recomendado levar em consideração as seguintes questões relacionadas à segurança: 11 Restrição de acesso a usuários: adicionar restrição de usuários do sistema que possuem privilégios de acesso e que por isso não podem utilizar o FTP; 11 Acesso de usuários anônimos: caso seja permitido o acesso a usuários anônimos, verificar se a pasta pública possui permissão somente de leitura; 11 Mudar o banner de saudação: trocar o valor da diretiva ftpd_banner. O valor padrão traz indicações do sistema, informações que podem ser utilizadas por usuários maliciosos; 11 Utilização de criptografia com o FTP: a adoção de medidas de segurança pode prevenir uma invasão ou utilização indevida do serviço. Por padrão, os dados, inclusive login e senha, são transmitidos em texto plano. Servidores como o VSFTPF e PROFTPD suportam o uso do SSL/TLS. Como alternativa, é possível utilizar o Secure Copy (SCP) ou Secure FTP (SFTP) para a transmissão de arquivos sigilosos;

Secure Shell (SSH) Permite a utilização de um terminal remoto e conexões para transferência de arquivos

q

entre clientes e servidores. Utiliza autenticação para estabelecer sessão. Utiliza encriptação para transmissão de dados. Secure Shell (SSH) surgiu como uma substituição ao Remote Shell (RSH), que permite conectar um shell a uma máquina remota. O RSH possui dois problemas: 1. Todo o tráfego é feito em texto plano, não garantindo a privacidade da informação; 2. Os arquivos /etc/hosts.equiv e ~/.rhosts listam máquinas e usuários autenticados, podendo

Administração de Sistemas Linux: Serviços para Internet

fazer conexão RSH sem futuras autenticações.

194

SSH encripta todo o tráfego, incluindo a senha ou chave de autenticação. Também usa chaves de hosts para identificação dos dois hosts envolvidos na comunicação. A versão do SSH1 era aberta até o release 1.2.12. A partir da versão 1.2.13, a licença mudou para comercial. O OpenSSH tem a licença GPL, e foi desenvolvido a partir do SSH versão 1.2.13, tendo implementado também as características do protocolo SSH2. Se possível, deve-se usar clientes e servidores que suportem SSH2.

OpenSSH Implementação open source do SSH.

q

Solução amplamente utilizada em ambiente Linux. Existem ainda OpenSSH Secure Copy (SCP) e Secure FTP (SFTP). 11 SCP e SFTP são utilizados como alternativa ao FTP. OpenSSH é utilizado como alternativa ao Telnet. 11 A utilização de SSH não é restrito ao mundo Linux. 11 Existem vários clientes Windows para acesso ao SSH e SCP. OpenSSH é uma implementação open source do SSH. Desde a versão 2.9, usa chaves RSA como padrão. O pacote OpenSSH possui os seguintes componentes: 11 ssh: cliente SSH (console remoto); 11 sshd: servidor de shell seguro SSH; 11 scp: programa para transferência de arquivos entre cliente e servidor; 11 ssh-keygen: gera chaves de autenticação para o SSH; 11 sftp: cliente FTP com suporte para comunicação segura; 11 ssh-add: adiciona chaves de autenticação DSA ou RSA ao programa de autenticação; 11 ssh-agent: agente de autenticação, sua função é armazenar a chave privada para autenticação via chave pública (DSA ou RSA); 11 ssh-keyscan: escaneia por chaves públicas de autenticação de hosts especificados. O principal objetivo é ajudar na construção do arquivo local know_hosts.

Configuração do servidor OpenSSH Requer a instalação do pacote pacote:

q

11 openssh-server Editar arquivo de configuração: 11 /etc/ssh/sshd_config Ativar o serviço sshd. A configuração de um cliente OpenSSH requer os pacotes: 11 openssh-clients 11 openssh Para utilização do serviço OpenSSH, é necessário que a máquina remota, denominada servidor, tenha o pacote openssh–server instalado. É necessário ainda que o arquivo de configuração esteja com a configuração correta, e, opcionalmente, que o daemon sshd esteja configurado para iniciar durante a inicialização do sistema. O arquivo de configuração do servidor é /etc/ssh/ sshd_config, enquanto o arquivo de configuração do cliente é /etc/ssh/ssh_configura. Embora o OpenSSH esteja pronto para execução logo após instalado, recomenda-se que Entre os ajustes possíveis: 11 Mudar a porta utilizada pelo serviço: parâmetro Port. Pode ser configurado no servidor e no cliente;

Capítulo 10 -

alguns ajustes sejam feitos no arquivo de configuração, o que eleva a segurança do sistema.

195

11 Configurar para aceitar somente a versão SSH2: parâmetro Protocol. Pode ser configurado no servidor e no cliente; 11 Não permitir acesso como root pelo OpenSSH: parâmetro PermitRootLogin. Só pode ser configurado no servidor; 11 Ignorar arquivos.rhosts e.shosts: já que eles autorizam logins subsequentes sem senha: parâmetro IgnoreRhosts. Só pode ser configurado no servidor; 11 Não permitir senhas em branco: parâmetro PermitEmptyPasswords. Só pode ser configurado no servidor; 11 Habilitar o uso do servidor SFTP (opcional): parâmetro Subsystem. Só pode ser configurado no servidor. A seguir são apresentados alguns parâmetros do arquivo de configuração. Parte do conteúdo do arquivo /etc/ssh/sshd_config: # /etc/ssh/sshd_config Port 2020 Protocol 2 ListenAddress 0.0.0.0 PermitRootLogin no X11Forwarding no CheckMail no RSAAuthentication yes DSAAuthentication yes RhostsAuthentication no RhostsRSAAuthentication no IgnoreRhosts yes PasswordAuthentication yes PermitEmptyPassword no

Comando ‘ssh’ Permite efetuar login e executar comandos em uma máquina remota. Exemplo:

q

11 Comando: # ssh [email protected] Administração de Sistemas Linux: Serviços para Internet

11 Efetua conexão à máquina leao.empresa.com.br, autenticando-se como usuario1.

196

11 Será solicitada senha. 11 Em seguida será concedido acesso à máquina remota. O comando ssh é a ferramenta usada para iniciar seções de console remoto. O arquivo de configuração de usuários é ~/.ssh/config, e o arquivo global /etc/ssh/ssh_config. Para conectar a um servidor ssh remoto: ssh usuá[email protected]

Caso o nome do usuário seja omitido, seu login atual do sistema será usado. O uso da opção -C é recomendado para ativar o modo de compactação dos dados (útil em conexões lentas). Uma porta alternativa pode ser especificada usando a opção -p porta (a 22 é usada por padrão). Variáveis de ambiente personalizadas para o ssh poderão ser definidas no arquivo ~/.ssh/environment. Comandos que serão executados somente na conexão ssh em ~/.ssh/rc e /etc/ssh/sshrc.

Estabelecendo conexão Ao conectar-se pela primeira vez a determinado servidor, é exibida a seguinte mensagem:

q

“The authenticity of host ‘leao.empresa.com.br (192.168.0.3)’ can’t be established.” RSA key fingerprint is 51:2f:c5:95:38:a3:6d:3e:43:ff:1e:ef:4c:f0:c6:01. “Are you sure you want to continue connecting (yes/no)?” 11 Respondendo “yes”, a máquina remota é adicionada em uma lista de máquinas conhecidas (known_hosts). Ao conectar-se pela primeira vez a determinado servidor, uma mensagem apresenta uma chave e solicita a confirmação de que se trata da máquina que se quer acessar. “The authenticity of host ‘leao.empresa.com.br (192.168.0.3)’ can’t be established.” RSA key fingerprint is 51:2f:c5:95:38:a3:6d:3e:43:ff:1e:ef:4c:f0:c6:01. “Are you sure you want to continue connecting (yes/no)?”

Respondendo “yes”, a máquina remota é adicionada em uma lista de máquinas conhecidas (arquivo ~/.ssh/known_hosts). Nas próximas vezes em que for feito login nesse mesmo host, apenas a senha será solicitada. Após o estabelecimento da conexão, é solicitada a senha do usuário remoto. Em acessos subsequentes, caso seja apresentada uma mensagem de aviso do tipo “Warning: remote host identification has changed. Someone could be eavesdropping on you right now”, pode estar ocorrendo uma das seguintes situações: 11 A máquina remota não é a desejada, sendo no caso uma impostora. Nesse caso não digite nenhuma senha. Convém informar ao administrador da máquina remota; 11 A máquina remota teve seu sistema ou o OpenSSH reinstalado. Nesse caso a chave pública, localizada no arquivo known_hosts, deve ser removida conforme instruções na mensagem.

SCP Permite a cópia de arquivos entre hosts de forma segura.

q

Utiliza os mesmos mecanismos de segurança do SSH. Exemplo de utilização: 11 # scp @: / 11 # scp [email protected]:/tmp/teste.txt Copia o arquivo texte.txt do computador remoto leao.empresa.com.br para o diretório atual. O Secure Copy (SCP) é uma alternativa ao FTP na transferência de arquivos e faz parte do pacote OpenSSH. Ao contrário do FTP, que por padrão não é um método seguro e cujos dados trafegam em texto plano, no SCP a conexão é autenticada e os dados são criptografados. Outra vantagem do SCP é o fato de os comandos serem similares ao comando cp. com um comando do tipo: # scp [email protected]:/tmp/teste.txt

Capítulo 10 -

Desse modo, a transferência de um ou mais arquivos entre duas máquinas pode ser feita

197

Podem ainda ser transferidos todos os arquivos de uma determinada pasta: # scp –R [email protected]:/home/usuário1/pasta/* * -R (recursividade): todas as pastas e arquivos a partir da pasta.

Ou ainda na direção contrária: # scp * [email protected]:/home/usuário1/

SFTP Permite realizar de forma segura a transferência de arquivos entre hosts.

q

Utiliza os mesmos mecanismos de segurança do SSH. Exemplo de utilização: 11 # sftp usuario@ Assim como o SCP, o SFTP é uma alternativa segura ao FTP na transferência de arquivos e também utiliza criptografia para transmissão de dados. Uma vantagem do SFTP em relação ao SCP ocorre quando não sabemos exatamente a localização do arquivo a ser transferido. A seguir é apresentado um exemplo de acesso, no qual é efetuado o download do arquivo teste.txt: sftp 192.168.0.1

Connecting to 192.168.0.1



[email protected]’s password:



sftp> ls

pasta1 pasta2 pasta3

sftp> cd pasta1



sftp> ls

teste.txt

sftp> get teste.txt



teste.txt 100% 10KB 12.3KB/s



sftp> exit

Administração de Sistemas Linux: Serviços para Internet

O serviço SFTP já vem habilitado por padrão no servidor, através da seguinte linha, que é

198

configurada no arquivo /etc/ssh/sshd_config: Subsystem sftp /usr/lib/openssh/sftp-server

Por padrão, ele está disponível para todos os usuários, que possuem os mesmos direitos de acesso aos arquivos de sistema. Ao disponibilizar esse serviço na internet, é recomendado configurá-lo para um grupo restrito de usuários, que ficarão confinados a um diretório específico, através do chroot. Para isso, basta comentar a linha acima e incluir a seguinte configuração no final no arquivo /etc/ssh/sshd_config: #Subsystem sftp /usr/lib/openssh/sftp-server ... Subsystem sftp internal-sftp Match Group sftp ChrootDirectory /ftp/%u X11Forwarding no

AllowTcpForwarding no ForceCommand internal-sftp

Com isso, temos: 11 Subsystem sftp internal-sftp: faz com que todo acesso ao sftp seja gerenciado pelo servidor sftp interno; 11 Match group sftp: para os usuários terem acesso ao SFTP, terão de estar no grupo sftp. Todas as linhas subsequentes de configuração se aplicarão somente aos usuários do grupo sftp; 11 ChrootDirectory /ftp/%u: os usuários terão acesso apenas ao diretório /ftp. 11 X11Forwarding no: não redirecionar o X11. 11 AllowTcpForwarding no: não permitir redirecionamento de TCP. 11 ForceCommand internal-sftp: o conjunto de comandos a serem utilizados será do SFTP. Configuração dos usuários que só terão acesso ao sftp: #Criar o grupo de sistema sftp: groupadd -r sftp #Criar o diretório mkdir /ftp chmod 755 /ftp #Criar usuários useradd -d /ftp/userftp1 -m -g sftp -s /sbin/nologin userftp1 passwd userftp1 #Corrigir as permissões do diretório utilizado pelo chroot chown root:root /ftp/userftp1 #Criar o diretório de utilização do usuário mkdir /ftp/userftp1/data chown userftp1:sftp /ftp/userftp1/data

Para que o chroot funcione, o diretório especificado na variável ChrootDirectory do arquivo sshd_configura deve pertencer ao usuário root.

Geração de chaves ssh-keygen -t

q

Onde pode ser: 11 rsa1: gera chaves no padrão RSA para a versão SSH1. 11 rsa: gera chaves no padrão RSA para a versão SSH2. 11 das: gera chaves no padrão DSA apenas para versão SSH2. 11 ecdsa: gera chaves no padrão ECDSA apenas para versão SSH2. Em algumas situações, pode ser necessário o uso de scripts que copiarão arquivos de um entre servidores espelho, de backup, de armazenamento de logs etc. Nesses casos, esses scripts precisarão acessar o servidor remoto para enviar ou buscar arquivos sem o uso de senha. Para isso, podem ser geradas chaves de encriptação baseadas em endereços IP dos dois servidores.

Capítulo 10 -

servidor para outro, o que geralmente ocorre em situações de replicação de conteúdo

199

Para evitar que um usuário ou administrador de um servidor acesse livremente o outro, recomenda-se a criação de usuários com poucos privilégios nas duas máquinas. 11 A seguir, os passos necessários:Gerar a chave com o comando ssh-keygen -t ; Onde pode ser: 22 rsa1: gera chaves no padrão RSA para a versão SSH1; 22 rsa: gera chaves no padrão RSA para a versão SSH2; 22 das: gera chaves no padrão DSA apenas para a versão SSH2; 22 ecdsa: gera chaves no padrão ECDSA apenas para a versão SSH2. 11 Copiar o arquivo contendo a chave pública, id_.pub, para a máquina de destino; 11 Incluir a chave pública no arquivo ~/.ssh/authorized_keys, na máquina remota (cat id_.pub >> ~/.ssh/authorized_keys);

Agente SSH Permite automatizar a autenticação através de um agente SSH.

q

Senha solicitada apenas uma vez em cada sessão Linux. As chaves são removidas após o encerramento da sessão. A automatização do acesso por SSH sem senha pode ser feita com o uso de um agente SSH. Essa opção deve ser considerada em situações em que o servidor remoto vai ser acessado repetidas vezes ao longo de um período, mas o acesso sem senha não deve ser tornado permanente. Nesse caso, usa-se um meio termo no qual a senha será armazenada por determinado Shell, que, enquanto estiver aberto, acessará o servidor sem senha. Para isso, são usados dois comandos: 11 ssh-agent $SHELL: cria uma sessão com o shell padrão;

Administração de Sistemas Linux: Serviços para Internet

11 ssh-add: acrescenta as chaves ao agente SSH.

200

Wagner Vieira Léo tem 25 anos de experiência na área de TI, atuando como Analista de Suporte e em Computação de Alto Desempenho, com foco em sistemas operacionais Unix/Linux. Possui graduação em Matemática pela Faculdade de Humanidades Pedro II, com Pós-Graduação em Gestão da Inovação pelo LNCC/UCP. Atualmente ocupa o cargo de Coordenador de Tecnologia da Informação do Laboratório Nacional de Computação Científica e de Coordenador Administrativo do Ponto de Presença da RNP no Rio de Janeiro. Professor do Instituto Superior de Tecnologia da Informação de Petrópolis, IST e da Escola Superior de Redes da RNP, nas áreas de Segurança da Informação e Sistemas Operacionais. Bruno Alves Fagundes é tecnólogo em Tecnologia da Informação e da Computação pelo Instituto Superior de Tecnologia (2007) e especialista em Segurança de Redes pela Universidade Estácio de Sá (2011). Tem experiência em administração de servidores Linux, gerenciamento de usuário, implementação e gerência de serviços de rede, clusters, segurança de redes, shell script, PHP, Perl. Atualmente é colaborador do LNCC, onde trabalha na administração dos servidores e clusters do Laboratório de Bioinformática (LABINFO), provendo infraestrutura para a realização de pesquisas e processamento massivo de dados. André Ramos Carneiro possui graduação em Tecnólogo em Tecnologia da Informação e Comunicação pelo Instituto Superior de Tecnologia em Ciência da Computação (2006). Trabalha com suporte à Linux desde 2005 e atualmente é Tecnologista do Laboratório Nacional de Computação Científica, onde trabalha com administração de servidores, gerência de contas de usuários, implementação de novos serviços, suporte a plataformas de processamento de alto desempenho, compilação de aplicações científicas, administração de storage e backup. Tem experiência na área de Ciência da Computação, com ênfase em Computação de Alto Desempenho, atuando principalmente nos seguintes temas: previsão numérica de tempo, processamento paralelo, aplicações científicas e I/O paralelo.

Wagner Vieira Léo tem 25 anos de experiência na área de TI, atuando como Analista de Suporte e em Computação de Alto Desempenho, com foco em sistemas operacionais Unix/Linux. Possui graduação em Matemática pela Faculdade de Humanidades Pedro II, com Pós-Graduação em Gestão da Inovação pelo LNCC/UCP. Atualmente ocupa o cargo de Coordenador de Tecnologia da Informação do Laboratório Nacional de Computação Científica e de Coordenador Administrativo do Ponto de Presença da RNP no Rio de Janeiro. Professor do Instituto Superior de Tecnologia da Informação de Petrópolis, IST e da Escola Superior de Redes da RNP, nas áreas de Segurança da Informação e Sistemas Operacionais.

uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP,

LIVRO DE APOIO AO CURSO

André Ramos Carneiro possui graduação em Tecnólogo em Tecnologia da Informação e Comunicação pelo Instituto Superior de Tecnologia em Ciência da Computação (2006). Trabalha com suporte à Linux desde 2005 e atualmente é Tecnologista do Laboratório Nacional de Computação Científica, onde trabalha com administração de servidores, gerência de contas de usuários, implementação de novos serviços, suporte a plataformas de processamento de alto desempenho, compilação de aplicações científicas, administração de storage e backup. Tem experiência na área de Ciência da Computação, com ênfase em Computação de Alto Desempenho, atuando principalmente nos seguintes temas: previsão numérica de tempo, processamento paralelo, aplicações científicas e I/O paralelo.

e Pesquisa – é qualificada como

O curso ensina a projetar, instalar, configurar e disponibilizar os principais serviços para internet em uma rede TCP/IP. Apresenta os conceitos associados a cada um dos serviços, e a instalação e configuração do KVM como base para o ambiente de virtualização. Aborda a autenticação nos serviços com LDAP, com apoio intensivo de atividades práticas.

Administração de Sistemas Linux Serviços para Internet

Bruno Alves Fagundes é tecnólogo em Tecnologia da Informação e da Computação pelo Instituto Superior de Tecnologia (2007) e especialista em Segurança de Redes pela Universidade Estácio de Sá (2011). Tem experiência em administração de servidores Linux, gerenciamento de usuário, implementação e gerência de serviços de rede, clusters, segurança de redes, shell script, PHP, Perl. Atualmente é colaborador do LNCC, onde trabalha na administração dos servidores e clusters do Laboratório de Bioinformática (LABINFO), provendo infraestrutura para a realização de pesquisas e processamento massivo de dados.

A RNP – Rede Nacional de Ensino

Administração de Sistemas Linux

Serviços para Internet Wagner Vieira Leo Bruno Alves Fagundes André Ramos Carneiro

que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação ISBN 978-85-63630-55-1

Ministério da Ciência, Tecnologia e Inovação

9 788563 630551

ads4.capa-NPE-V3.0.0.indd 1

27/04/2016 14:06:54