SERVIÇOS DE REDES EM LINUX by ARL UFLA

Curso de Pós-Graduação “Lato Sensu” (Especialização) a Distância Administração em Redes Linux

SERVIÇOS DE REDES EM LINUX

2a Edição

Joaquim Quinteiro Uchôa Fernando Cortez Sica Luiz Eduardo Simeone

Universidade Federal de Lavras – UFLA Fundação de Apoio ao Ensino, Pesquisa e Extensão – FAEPE Lavras – MG

PARCERIA UFLA – Universidade Federal de Lavras FAEPE – Fundação de Apoio ao Ensino, Pesquisa e Extensão REITOR Antônio Nazareno Guimarães Mendes VICE-REITOR Ricardo Pereira Reis DIRETOR DA EDITORA Marco Antônio Rezende Alvarenga PRÓ-REITOR DE PÓS-GRADUAÇÃO Joel Augusto Muniz PRÓ-REITOR ADJUNTO DE PÓS-GRADUAÇÃO “LATO SENSU” Marcelo Silva de Oliveira COORDENADOR DO CURSO Heitor Augustus Xavier Costa PRESIDENTE DO CONSELHO DELIBERATIVO DA FAEPE Edson Ampélio Pozza EDITORAÇÃO Grupo Ginux (http://ginux.comp.ufla.br/) IMPRESSÃO Gráfica Universitária/UFLA Ficha Catalográfica preparada pela Divisão de Processos Técnicos da Biblioteca Central da UFLA Uchôa, Joaquim Quinteiro Serviços de Redes em Linux/ Joaquim Quinteiro Uchôa, Fernando Cortez Sica, Luiz Eduardo Simeone. - - 2.ed. Lavras: UFLA/FAEPE, 2004. 94 p. : il. - Curso de Pós-Graduação “Lato Sensu” (Especialização) a Distância: Administração em Redes Linux. Bibliografia. 1. Redes de Computadores. 2. Sistemas Operacionais. 3. Linux. 4. Protocolos. 5. Comunicação de Dados. 6. Protocolos de Redes. I. Uchôa, J. Q. II. Sica, F. R. III. Simeone, L. E. IV. Universidade Federal de Lavras. V. Fundação de Apoio ao Ensino, Pesquisa e Extensão. VI. Título. CDD-001.64404 Nenhuma parte desta publicação pode ser reproduzida, por qualquer meio ou forma, sem a prévia autorização.

SUMÁRIO

1 Introdução

2 Redes TCP/IP

2.1 Conceitos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 Endereçamento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2 Roteamento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.3 Resolução de nomes de máquinas . . . . . . . . . . . . . . . . . . . .

2.2 Interfaces de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Point-to-Point protocol (PPP) em Linux

. . . . . . . . . . . . . . . . . . . . .

2.4 Outras Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4.1 DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4.2 ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Linux como Roteador IP ou Firewall

3.1 Roteamento em Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Firewall em Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 Uso do iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1 CHAINS e políticas padrão . . . . . . . . . . . . . . . . . . . . . . . .

3.4.2 Criando novas regras de filtragem . . . . . . . . . . . . . . . . . . . .

3.4.3 iptables-save e iptables-restore . . . . . . . . . . . . . . . .

3.5 Network address translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . .

3.5.1 O que é NAT e qual a sua utilidade . . . . . . . . . . . . . . . . . . . .

3.5.2 Source-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.3 Destination-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Serviços de Correio Eletrônico

4.1 Conceitos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Uso de Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Configuração Básica do sendmail . . . . . . . . . . . . . . . . . . . . . . .

4.4 Outros Exemplos de Sistema de E-Mail . . . . . . . . . . . . . . . . . . . . .

4.4.1 QMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.2 Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5 Listas de Discussão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 O Servidor WWW

5.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Configuração Básica do Apache . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.1 O Arquivo httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.2 Os Arquivos srm.conf e access.conf . . . . . . . . . . . . . . . .

5.3 Habilitação do https . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1 Criação de Chaves para HTTPS . . . . . . . . . . . . . . . . . . . . .

6 Compartilhamento de Arquivos

6.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 Uso de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.1 Configurando o Servidor NFS . . . . . . . . . . . . . . . . . . . . . . .

6.2.2 Configuração do Cliente NFS . . . . . . . . . . . . . . . . . . . . . . .

6.3 O Servidor FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4 Integração do Linux com redes Windows . . . . . . . . . . . . . . . . . . . .

6.4.1 Configurando o Servidor SAMBA . . . . . . . . . . . . . . . . . . . . .

6.5 Acessando Compartilhamentos Windows . . . . . . . . . . . . . . . . . . . .

7 Serviços de Informação em Redes

7.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 Serviço de Domínio de Nomes (DNS) . . . . . . . . . . . . . . . . . . . . . .

7.2.1 Resolução de Nomes em Linux . . . . . . . . . . . . . . . . . . . . . .

7.2.2 O Servidor DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.3 Configurando o named . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.4 Configurando Zonas de Domínios . . . . . . . . . . . . . . . . . . . .

7.2.5 Base de Dados DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.6 Consultando o DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3 Compartilhamento de Informações . . . . . . . . . . . . . . . . . . . . . . . .

7.4 DHCP e OpenSLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.5 Servidores de Bancos de Dados . . . . . . . . . . . . . . . . . . . . . . . . .

8 Servidores de Acesso Remoto

8.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2 Configuração Básica do SSH . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3 Configuração do Cliente SSH . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4 Configuração do Servidor SSH . . . . . . . . . . . . . . . . . . . . . . . . . .

8.5 Configuração de Provedores de Acesso Remoto . . . . . . . . . . . . . . . .

Referências Bibliográficas

LISTA DE FIGURAS

2.1 Exemplo de Sub-redes com roteadores . . . . . . . . . . . . . . . . . . . . .

3.1 Arquivo com as regras do iptables . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Exemplos de Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Exemplos de Conteúdo para o Arquivo .forward . . . . . . . . . . . . . . .

4.3 Exemplo de Arquivo m4 para sendmail.cf em Máquinas Clientes . . . . .

4.4 Exemplo de Arquivo m4 para sendmail.cf em Máquina Servidora . . . . .

4.5 Arquivo m4 para Domínio Genérico . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Etapas para Instalação do Apache . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Trecho para Inicialização do Apache no Momento de Boot . . . . . . . . . . .

5.3 Exemplo de Definição de Domínio Virtual para EmpresaX . . . . . . . . . . .

5.4 Exemplo de Definição de Domínio Virtual para EmpresaX . . . . . . . . . . .

5.5 Exemplo de Arquivo .htaccess . . . . . . . . . . . . . . . . . . . . . . . . .

5.6 Exemplo de Arquivo .htaccess . . . . . . . . . . . . . . . . . . . . . . . . .

5.7 Carregando o Módulo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.8 Carregando o Módulo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.9 Carregando o Módulo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1 Arquivo /etc/exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 Exemplo de Arquivo smb.conf – Seção global . . . . . . . . . . . . . . . .

6.3 Exemplo de Arquivo smb.conf – Compartilhamentos . . . . . . . . . . . . .

7.1 Árvore DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 Arquivo /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3 Arquivo /etc/host.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4 Arquivo /etc/nsswitch.conf . . . . . . . . . . . . . . . . . . . . . . . . .

7.5 Arquivo /etc/resolv.conf . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6 Exemplo de /etc/named.conf . . . . . . . . . . . . . . . . . . . . . . . . .

7.7 A Seção zone do Arquivo /etc/named.conf . . . . . . . . . . . . . . . . .

7.8 Base de Dados de DNS Direto . . . . . . . . . . . . . . . . . . . . . . . . . .

7.9 Base de Dados de DNS Reverso . . . . . . . . . . . . . . . . . . . . . . . . .

7.10 Uso do Comando dig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.11 Exemplo de Arquivo /etc/dhcpd.conf . . . . . . . . . . . . . . . . . . . .

8.1 Man-In-The-Middle Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2 Arquivo /etc/ssh/ssh_config . . . . . . . . . . . . . . . . . . . . . . . .

8.3 Arquivo /etc/ssh/sshd_config . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE TABELAS

2.1 Divisão do endereço IP e Classes . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Redes IP reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Alvos ou TARGETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Parâmetros para a filtragem de pacotes . . . . . . . . . . . . . . . . . . . . .

3.3 Parâmetros para filtragem de pacotes TCP e UDP . . . . . . . . . . . . . . .

3.4 Estado dos pacotes testados pelo parâmetro -m state . . . . . . . . . . . .

4.1 Ações Associadas aos Aliases na Figura 4.1 . . . . . . . . . . . . . . . . . .

4.2 Descrição das Linhas do Exemplo Contido na Figura 4.3

. . . . . . . . . . .

4.3 Descrição das Linhas do Exemplo de Arquivo m4 para sendmail.cf da Figura 4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Descrição dos Arquivos de Configuração do QMail . . . . . . . . . . . . . . .

4.5 Exemplo de conteúdo dos arquivos de configuração do QMail . . . . . . . . .

5.1 Módulos Úteis não Incluídos na Instalação Padrão . . . . . . . . . . . . . . .

6.1 Opções do Arquivo /etc/exports . . . . . . . . . . . . . . . . . . . . . . .

6.2 Opções de Compartilhamento no SAMBA . . . . . . . . . . . . . . . . . . . .

7.1 Domínios Genéricos de Alto Nível . . . . . . . . . . . . . . . . . . . . . . . .

7.2 Domínios de Países . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3 Informações Compartilhadas . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4 Bases Utilizadas no /etc/nsswitch.conf . . . . . . . . . . . . . . . . . .

7.5 Taxionomia de Servidores de Nomes . . . . . . . . . . . . . . . . . . . . . . .

7.6 Seções Usadas no /etc/named.conf . . . . . . . . . . . . . . . . . . . . .

7.7 Opções da Seção options no /etc/named.conf . . . . . . . . . . . . . .

7.8 Tipos de Registros DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 INTRODUÇÃO

Este texto tem por principal objetivo instruir o seu leitor nos passos básicos necessários à administração de um servidor Linux. Por servidor, em geral, compreende-se qualquer computador que ofereça serviços em rede, que são utilizados pelo usuário final em outra máquina. Isso implica que, na maioria dos casos, um servidor não é considerado uma estação. Ao processo de gerenciamento de uma servidor, dá-se o nome de administração de serviços ou administração de redes. Seguindo essa abordagem, esta obra pretende orientar o usuário nos passos necessários à uma adequada configuração de um servidor, para uso em ambiente TCP/IP. Dessa maneira, não será abordado aqui a configuração de dispositivos (mesmo os de rede), já abordados em (UCHÔA, 2007). A configuração e o gerenciamento de servidores UNIX depende principalmente do tipo de serviço oferecido. Nesse sentido, o texto foi organizado de forma que o leitor possa abordar cada aspecto de configuração individualmente. Cada capítulo foi pensado de forma que possa ser lido individualmente, mas fazendo parte de um todo organizado e dirigido. Inicialmente, o Capítulo 2 apresenta uma visão geral do TCP/IP em ambientes UNIX, ressaltando-se os principais aspectos para a configuração de rede em um servidor Linux. O Capítulo 3, por sua vez, mostra como utilizar o Linux para roteamento TCP/IP ou serviços de firewall. O Capítulo 4 apresenta o serviço de correio eletrônico, com certeza um dos mais importantes. Além da configuração básica dos principais servidores de e-mail, ele aborda o uso do /etc/aliases e gerenciamento de listas de discussão. Outro serviço importante, o WWW, é visto no Capítulo 5. Os serviços de compartilhamento de arquivos são apresentados no Capítulo 6. Além dos tradicionais serviços de FTP e NFS, esse capítulo também apresenta o servidor SAMBA, responsável pela integração do servidor Linux com estações Windows. Os tradicionais serviços de diretório, como NIS e LDAP, são explicados no Capítulo 7. Esse capítulo também

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

aborda a configuração dos serviços de DNS. O Capítulo 8, por sua vez, apresenta os principais serviços de acesso remoto, dando especial destaque ao SSH. Este texto foi escrito pensando em um usuário intermediário do sistema operacional Linux (ou equivalente). Ele foi produzido principalmente a partir da experiência adquirida pelos autores em administração de laboratórios e uso de diversos sistemas operacionais. Essa experiência em administração de sistemas foi enriquecida pela leitura de diversos materiais, destacando-se, principalmente: (NEMETH et al., 1995), (NEMETH et al., 2001), (STANFIELD; SMITH, 2001), (WIRZENIUS; OJA; STAFFORD, 2001), (FRAMPTON, 1999), (MANN; MITCHELL, 2000), (ANONYMOUS, 2000), (KIRCH; DAWSON, 2002), (BAUTTS; DAWSON; PURDY, 2005). A essas referências devem ser acrescidos vários Howtos1 disponibilizados pela The Linux Documentation Project 2 . Fernando Cortez Sica, um dos autores do livro, é bacharel em Ciência da Computação pela Universidade Estadual Paulista (UNESP), campus de Bauru/SP, mestre em Engenharia Elétrica pela UNICAMP e doutorando em Ciência da Computação pela UFMG. Dentre outras atividades, implantou e foi o administrador de um laboratório baseado em estações IBM RISC6K dotadas de UNIX AIX4.1 no Departamento de Computação da Universidade Federal de Ouro Preto, onde é professor desde 1996. Atua principalmente nas linhas de Sistemas de Computação (Sistemas Operacionais, Redes de Computadores e afins) e Sistemas Integrados de Hardware e Software (Arquitetura de Computadores, Sistemas Embutidos, Eletrônica Digital, etc). Joaquim Quinteiro Uchôa é licenciado em Matemática pela Universidade Federal de Mato Grosso (UFMT), com mestrado em Ciência da Computação pela Universidade Federal de São Carlos (UFSCar). Antes de adotar o Linux, em 1998, já havia trabalhado com Solaris, MS-DOS (lembram-se do CISNE?) e OS/2, passando, obviamente pelos Windows 2.0, Windows 3.1 (e 3.11) e Windows 95. Segundo amigos, ele já superou o trauma do uso desses três últimos SOs(?), apesar de ter desenvolvido aversão a alguns tipos de janelas. Foi o responsável pela instalação do primeiro laboratório baseado em Linux na UFLA e um dos maiores disseminadores desse sistema operacional na universidade. Professor da UFLA, desde 1997, atua principalmente nas áreas de Teoria da Computação e Inteligência Artificial. Luiz Eduardo Simeone, o outro autor, é Bacharelando em Ciência da Computação pela Universidade Federal de Lavras. Teve o primeiro contato com Linux em 2000, incentivado por professores. Trabalhou com suporte ao usuário no Departamento de Administração e Economia da UFLA, com sistemas Windows 95, Windows 98 e Windows NT workstation. 1 Um

Howto é um pequeno guia que ensina um usuário a configurar um serviço ou fazer uma dada tarefa. Linux Documentation Project: http://www.tldp.org/. A tradução de parte dos documentos desse projeto podem ser encontrados em http://br.tldp.org/. 2 The

Introdução

Em seguida foi administrador da rede do Centro de Tecnologia em Informática da UFLA UFLATEC, onde foi responsável pela implantação do servidor de e-mail utilizando Linux, e integrando os sevidores Windows 2000 e Linux com estações Windows 2000 e Linux. Atualmente trabalha na equipe técnica do ARL, administrando servidores do curso e do Departamento de Ciência da Computação. Os autores se sentirão realizados com a escrita desta obra se ela contribuir para disseminar ainda mais o uso de Linux no Brasil e desejam um bom aprendizado ao leitor.

EDITORA - UFLA/FAEPE - Serviรงos de Redes em Linux

2 REDES TCP/IP

2.1 2.1.1

CONCEITOS BÁSICOS Endereçamento IP

Um endereço IP, na versão 4, é um conjunto de 4 números de 0 até 255, separados por ponto, ex: 192.168.4.1. Esse endereço é dividido em duas partes: o endereço da rede e o endereço do host, sendo que primeira parte é o endereço da rede, e o restante é o endereço do host. O tamanho da rede, ou o número de hosts que uma rede pode ter, depende do tamanho do endereço da rede, e do tamanho do endereço do host. E para organizar melhor as redes, elas foram divididas em classes, definidas a partir do endereço da rede. As redes classe ’A’ tem endereços entre 1.0.0.0 e 127.255.255.255, sendo o endereço da rede o primeiro número. As redes classe ’B’ tem endereços entre 128.0.0.0 e 191.255.255.255, sendo o endereço da rede os dois primeiros números. As redes classe ’C’ tem endereços entre 192.0.0.0 e 223.255.255.255, e o endereço da rede são os três primeiros números. Por fim, as redes classes ’D’ tem endereço entre 224.0.0.0 e 239.255.255.255 e as redes classes ’E’ tem endereço entre 240.0.0.0 e 255.255.255.255. As duas últimas são experimentais ou tem uso específico, e por isso não definem nenhuma rede. Os números 0 e 255 tem características especiais, e por isso não podem ser usados para definir o endereço de um host. O primeiro define uma rede, e é chamado de endereço de broadcast. Então o IP 192.168.4.1 é um host da rede 192.168.4.0. O segundo número se refere a todos os hosts de uma rede. Portanto o IP 192.168.4.255 significa todos os hosts da rede classe C 192.168.4.0. A Tabela 2.1 ilustra esses conceitos. Existem também endereços e faixas de endereços IP que são reservados, como mostra a Tabela 2.2. O endereço 0.0.0.0 é conhecido como rota padrão. A rota padrão faz parte da tabela de rota, no roteamento de pacotes IP. A rede 127.0.0.0 é reservada para o tráfego local, no próprio host. Geralmente o IP 127.0.0.1 é associado a uma

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Tabela 2.1: Divisão do endereço IP e Classes

Endereço 192.168.4.1 135.33.140.29 97.44.150.32

Endereço da rede Endereço do host Classe 192.168.4.0 1 C 135.33.0.0 140.29 B 97.0.0.0 44.150.29 A

Tabela 2.2: Redes IP reservadas

Classe A B C

Rede Reservada 10.0.0.0 até 10.255.255.255 172.16.0.0 até 172.31.0.0 192.168.0.0 até 192.168.255.0

interface especial, chamada de loopback. Todo tráfego de pacotes TCP e UDP direcionados para loopback retornam para o host de origem, como se estivesse chegando de uma rede qualquer. A interface loopback é especialmente útil para desenvolvimento de software para rede, sem a necessidade de estar conetado a uma, e também para vários serviços locais. As faixas de IP reservadas servem para fazer redes privadas e os pacotes com esses endereços não são roteados na internet, ou seja: não existe nenhum host na internet com estes endereços. Esses endereços são geralmente usados com NAT, abordado na seção 3.5. 2.1.2

Roteamento IP

Para entender como é feito o roteamento de pacotes em uma rede IP é muito importante conhecer o conceito de sub-rede. Seja uma instituição de ensino superior chamada UCJ (Universidade dos Cafundós do Judas), que tem uma rede IP classe B 148.75.0.0, com mascara de rede 255.255.0.0. A UCJ é dividida em diversos departamentos e setores, como por exemplo o DMV (Depto. de Medicina Veterinária), DCF (Depto. de Ciências Florestais), e a PRG (Pró-reitoria de Graduação). Para facilitar a administração da rede, o Centro de Processamento de Dados resolveu dividir a rede da UCJ da seguinte forma: o DMV vai ficar com a rede 148.75.2.0, com mascara de rede 255.255.255.0; o DCF com a rede 148.75.3.0, com mascara de rede 255.255.255.0; e a PRG com a rede 148.74.4.0, com mascara de rede 255.255.255.0, como ilustrado na Figura 2.1 As redes do DCF, DMV e PRG são sub-redes da rede da UCJ. Entre as redes dos departamentos e o backbone central da UCJ, existe um roteador, que é responsável pela entrega

Redes TCP/IP

Rede UCJ

DCF 148.75.3.0

DMV 148.75.2.0

Roteador DCF

Roteador DMV

Roteador PRG

PRG 148.75.4.0

Figura 2.1: Exemplo de Sub-redes com roteadores

dos pacotes da sub-rede do seu departamento. Assim, existe um roteador no DMV, um no DCF, um na PRG e assim por diante. Pensando nas dimensões da internet, o roteamento em redes IP implementa a famosa técnica do ”dividir para conquistar”, pois a tarefa de rotear os pacotes é dividida entre um número incalculável de servidores em todo o mundo. Agora, imagine se todo o roteamento de pacotes fosse feito por apenas 3 ou 4 roteadores? Simplesmente a internet seria inviável. 2.1.3

Resolução de nomes de máquinas

O endereço IP de um host é um número de 32 bits, que muitas vezes não é fácil de ser lembrado. Entretanto, é possivel chamar um host de “laranjada“ ou “onibus“. O processo de transformar esses nomes comuns em endereços IP é chamado resolução do nome de um host. Existem formas diferentes de transformar nomes em IP. Uma delas, e a mais simples, é adicionar um IP associado a um nome no arquivo /etc/hosts. Existe também o NIS, e a base de dados LDAP, que funcionam como um serviço de diretório ou Yellow Pages (páginas amarelas), além do DNS (Domain Name System) que serão estudados no Capítulo 7.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

2.2

INTERFACES DE REDE

Para suportar a grande variedade de hardware disponível no mercado, o protocolo TCP/IP definiu uma inteface, que é virtual, através da qual o sistema acessa o hardware . Essa interface só pode ser usada após ter um endereço associado a ela. É como se a interface fosse a porta, e o endereço fosse o número a ela associado. O nome das interfaces varia de acordo com tipo de hardware a ela associado, como por exemplo as interfaces ethernet chamam-se eth0, eth1 . . . ethn, as interfaces PPP chamam-se ppp0, ppp1 . . . pppn, assim por diante.

2.3

POINT-TO-POINT PROTOCOL (PPP) EM LINUX

O Point-to-Point Protocol (ou protocolo ponto-a-ponto), é responsável por conexões IP sobre um link serial, como as linhas telefônicas. PPP em Linux é implementado em três partes: uma parte no kernel, uma através do daemon pppd, e a outra através do programa chat. No kernel são implementados protocolos de baixo nível. O pppd ajuda o kernel na inicialização e na autenticação necessárias antes do tráfego de dados na linha serial. O pppd também pode ser configurado ao gosto do usuário, mas esse não é o objetivo desta seção, uma vez que existem inúmeros aplicativos com essa facilidade (como o KPPP, o vppp, o linuxconf, o rp3 ou o wvdial). O wvdial e o linuxconf, inclusive, possuem interface em modo texto. Para maiores detalhes sobre o PPP é recomendada a leitura do PPP-HOWTO1 .

2.4 2.4.1

OUTRAS TECNOLOGIAS DSL

A tecnologia DSL (Digital Subscriber Loop) permite comunicação dedicada em alta velocidade através de uma linha telefônica comum. Uma das características importantes do DSL, principalmente do ADSL (Asynchronous DSL), é possibilidade de compartlhamento da linha com serviços de voz e até ISDN. Isso é possivel devido ao DSL utilizar uma faixa de freqüência inferior a de voz (freqüência de voz está acima de 4KHz), criando assim dois canais na mesma linha: um para voz e outro para dados. Isso é fundamental para viabilizar o serviço, pois diminui muito o custo das empresas de telecomunicações na manutenção

1 http://www.tldp.org/HOWTO/PPP-HOWTO/index.html

Redes TCP/IP

dessas linhas. O principal público-alvo desse serviço são so usuários SOHO (Small Office and Home Office ou usuários domésticos e pequenas empresas) devido ao seu baixo custo. 2.4.2

ISDN

A tecnologia ISDN (Integrated Services Digital Network) é uma série de padrões que especificam uma rede digital de uso geral. Uma chamada ISDN cria um serviço PPP síncrono, normalmente em um link de alta velocidade. Esse link é dividido em vários canais, e esses canais podem tanto originar quanto receber chamadas. Esse serviço pode ser oferecido tanto em uma linha telefônica comum, como em uma linha dedicada para dados. A intenção dessa tecnologia é permitir às empresas prestadoras de serviços de telecomunicação fornecer um serviço simples de transmissão de dados.

EDITORA - UFLA/FAEPE - Serviรงos de Redes em Linux

3 LINUX COMO ROTEADOR IP OU FIREWALL

3.1

ROTEAMENTO EM LINUX

O roteamento em um sistema Linux é nativo do kernel, ou seja, ao iniciar o serviço de rede, o o kernel já ativou o roteamento de pacotes. O servico roda inicialmente de uma forma local, roteando apenas os pacotes da própria máquina. Para que o kernel possa rotear pacotes de outras máquinas é preciso dizer que ele deve fazer isso, que é feito inserindo o valor 1 no arquivo /proc/sys/net/ipv4/ip_forward. • Verificando o valor de ip_forward # cat /proc/sys/net/ipv4/ip_forward 0 • Mudando o valor de ip_forward # echo 1 > /proc/sys/net/ipv4/ip_forward • Verificando o novo valor de ip_forward # cat /proc/sys/net/ipv4/ip_forward 1

Existem alguns programas, como o zebra 1 e o routed que ajudam o kernel a gerenciar as tabelas de rota e o cache. Vale a pena salientar que o zebra, ao ser iniciado já altera o valor de ip_forward para 1. Se a opção for o routed, existe a necessidade de alterar esse valor. Isso pode ser feito de várias maneiras. Por exemplo, pode-se colocar no arquivo /etc/rc.d/rc.local o comando para mudar o valor de 0 para 1 (usando echo ou o comando sysctl). Também é possível fazer isso, e de uma forma mais adequada, editando-se o arquivo /etc/sysctl.conf. 1 http://www.zebra.org

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Para cada sub-rede que vai se utilizar o roteador, deve haver uma interface associada, nem que ela seja virtual, ou alias. Utilizando o exemplo da seção 3.1, o roteador do DMV tem uma interface de rede com o ip 148.75.2.1, que está ligada à sub-rede do DMV, e uma outra interface 148.75.1.6, que está ligada à rede da UCJ. Se as redes forem segmentadas físicamente, cada uma das interfaces tem que estar associadas a um dispositivo físico exclusivo para si. Mas se as redes trafegarem sob o mesmo meio físico, pode ser feito um alias, isto é, associar um único dispositivo físico a várias interfaces. Usar aliases pode ser interessante dependendo da situação, mas não é recomendável. Existe uma perda de desempenho razoável com essa situação. O ideal é que as redes sejam segmentadas fisicamente, pois isso evita que algum usuário consiga ”driblar” o roteador, e que mesmo que a rede trafegue no mesmo meio físico, que cada interface tenha um dispositivo de hardware exclusivo à sua disposição.

3.2

FIREWALLS

Um firewall é uma muralha que protege o sistema contra agentes maliciosos do mundo exterior, como crackers e cavalos-de-tróia, e contra pacotes indesejados como o ICMP (o famoso “ping”). É importante salientar que o firewall, principalmente em Linux, é um software. E como todo software, ele tem bugs. E esses bugs podem se tornar possíveis portas de entrada para agentes não muito bem-vindos. Em resumo, nenhum firewall é totalmente seguro. Até os sistemas da NASA e do Pentágono (Quartel-General das forças armadas norte-americanas) já foram invadidos. O importante é que o administrador tenha a consciência de quem (quais redes) pode acessar o que (quais protocolos/portas), e que mesmo com o firewall é sempre importante fazer verificações periódicas nos registros do sistema e demais formas de controle.

3.3

FIREWALL EM LINUX

Os firewalls existem no Linux desde o kernel 1.1, com o ipfw, originário do BSD. Esse filtro era userspace, ou seja, rodava como um programa comum no sistema, similarmente ao BIND (servidor de nomes). Com o kernel 2.0 veio o ipfwadm, que ainda era uma ferramenta userspace e controlava as regras de filtragem do kernel. Na versão 2.2 do kernel, veio o ipchains (ainda presente em algumas distribuições) e em 1999, veio o iptables 2 , presente a partir do kernel 2.3.15. O iptables, que será o tema da próxima seção, se relaciona com o kernel de forma que ele saiba como filtrar os pacotes. 2 http://www.netfilter.org

Linux como Roteador IP ou Firewall

3.4

USO DO IPTABLES

3.4.1 CHAINS e políticas padrão No iptables, existem tabelas de filtragem (chains), e três delas são básicas e nao podem ser apagadas: INPUT, OUTPUT e FORWARD. A chain INPUT trata dos pacotes de entrada, aqueles que chegam da rede. A chain OUTPUT trata dos pacotes de saída, aqueles que vão para a rede. E finalmente a chain FORWARD trata do encaminhamento de pacotes, ou seja, roteamento. Para outras necessidades podem ser criadas novas chains, ao gosto do administrador do sistema. Essas chains tem políticas de tratamento padrão (targets), para os casos que não são tratados pelas regras descritas ali. Os targets, ou alvos, básicos são o ACCEPT, que aceita os pacotes e o DROP que rejeita pacotes. Na Tabela 3.1 é possível observar os targets disponíveis e sua descrição básica. Tabela 3.1: Alvos ou TARGETs

TARGET Descrição ACCEPT DROP LOG REJECT QUEUE

Aceita os pacotes em questão. Rejeita os pacotes. Permite fazer log dos pacotes que se encaixam na regra. Tem o mesmo efeito de DROP, porem pode ser configurado para retornar mensagens de erro. Coloca o pacote em uma fila userspace, ou seja ao alcance do usuário para que ele use esses pacotes como bem entender. Este target ainda está em fase experimental.

Chains só podem ter como alvo DROP e ACCEPT, sendo a última o alvo padrão. Alguns comandos básicos para alterações em chains e políticas: • Adicionando uma chain: # iptables -N <nome-da-chain> • Apagando uma chain vazia: # iptables -X <nome-da-chain> • Mudando a política de uma chain: # iptables -P <nome-da-chain> <target> • Apagando todas as regras de uma chain: # iptables -F <nome-da-chain>

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

• Listando todas as regras de uma chain: # iptables -L <nome-da-chain> • Renomeando uma chain: # iptables -E <nome-da-chain> <novo-nome> 3.4.2

Criando novas regras de filtragem

Para criar novas regras de filtragem é importante saber se o pacote que queremos tratar é um pacote que está está chegando da rede ou se é um pacote que está sendo mandado para a rede. Outros pontos importantes são: o protocolo, as redes ou hosts que devem ser filtrados, a porta (relacionada com o serviço) e o que queremos fazer com esse pacote. É importante salientar que as regras são testadas na ordem que foram inseridas, ou seja, ao criar as regras, deve ser observada a ordem das mesmas, para que não haja funcionamento indesejado do firewall. Apenas para exemplificar a criação de uma regra simples, queremos bloquear todos os pacotes de vindos de 192.168.4.39. Para adicionar uma regra a uma chain usamos a seginte sintaxe do iptables:

# iptables -A <nome-da-chain> <especificação-da-regra>

Voltando ao exemplo, na parte <especificação-da-regra> do comando acima, podem ser passados vários parâmetros. O parâmetro que determina o endereço de origem dos pacotes é o ”-s <endereço-IP>”. Outro parâmetro que deve ser passado é o alvo, ou target do pacote, para onde ele deve ser mandado. Isso é feito passando ”-j <TARGET>”. Então a regra do exemplo acima ficaria:

# iptables -A INPUT -s 192.168.4.39 -j DROP

Cada tipo de protocolo tem parâmetros específicos para a filtragem de pacotes. Mas existem alguns deles que são comuns a todos os protocolos e eles funcionam como descrito na Tabela 3.2. Existem parâmetros específicos dos protocolos TCP e UDP. Eles são habilitados pelos parâmetros -p tcp e -p udp. Na Tabela 3.3 há uma descrição dos parâmetros e para quais protocolos ele está disponível. Merece destaque o parâmetro -m <argumento> que habilita algumas extensões do iptables. Quando o <argumento> é state, a opção --state é habilitada. Esta opção testa o estado dos pacotes tratados pela regra, e o uso de ”!” tem o significado do operador lógico NOT. Na Tabela 3.4 são especificados os estados possíveis. O argumento mac habilita a opção --mac-source que associa o endereço Ethernet (físico, ou endereço

Linux como Roteador IP ou Firewall

Tabela 3.2: Parâmetros para a filtragem de pacotes

Parâmetro -i <interface> -o <interface> -s <IP> -d <IP> -p <protocolo> -m <argumento>

Descrição Determina a interface de entrada. Determina a interface de saída. Determina o endereço de origem dos pacotes. Determina o endereço de destino dos pacotes. Determina o protocolo (tcp, udp, icmp, etc). Habilita extensões do iptables. O <argumento> pode ser: state, mac e limit.

Tabela 3.3: Parâmetros para filtragem de pacotes TCP e UDP

Parâmetro

Protocolos

Descrição

Especifica a porta de origem do pacote. Deve ser especificada apenas 01 porta, e o uso de ”!” tem o sentido do operador lógico NOT --souce-port <porta> TCP e UDP Tem o mesmo efeito de --sport <porta> --dport <porta> TCP e UDP Funciona de forma similar a --sport <porta>, so que a porta especificada é a de destino. --destination-port <porta> TCP e UDP Tem o mesmo efeito de --dport <porta> --sport <porta>

TCP e UDP

MAC) do pacote, sendo que o operador ”!” tem o mesmo sentido que em state. O argumento limit habilita dois parâmetros: --limit, que deve ser seguido de um número. Esse número determina o limite máximo de pacotes (ou LOGs) por segundo. Também é possível especificar a unidade de tempo com /second ou /s, /minute ou /m, /hour ou /h, /day ou /d. O outro parâmetro, --limit-burst, determina quantas entradas podem ocorrer antes dos pacotes serem limitados pelo parâmetro --limit. Após a apresentação do iptables, vamos a alguns exemplos de regras mais elaboradas.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Tabela 3.4: Estado dos pacotes testados pelo parâmetro -m state

Estado do pacote Descrição NEW ESTABLISHED RELATED

INVALID

Estado de um pacote que está envolvido em uma nova conexão. Pacote que faz parte de conexões anteriormente estabelecidas. Pacote que não faz parte de uma conexão previamente estabelecida, mas que está relacionado com uma. Pacote que não pode ser identificado, ou por ser desconnhecido, ou por estar defeituoso.

• Aceitar pacotes HTTP (protocolo TCP, porta 80) do host 192.168.4.50. # iptables -A INPUT -s 192.168.4.50 -p tcp -m tcp \ --dport 80 -j ACCEPT • Bloquear todos os pacotes UDP de qualquer origem. # iptables -A INPUT -p udp -j DROP • Bloquear o acesso dos usuários locais ao host 200.131.251.9, no serviço FTP (protocolo TCP, porta 21). # iptables -A OUTPUT -d 200.131.251.9 -p tcp -m tcp \ --dport 21 -j DROP • Bloquear os pacotes TCP inválidos. # iptables -A INPUT -p tcp -m state --state INVALID -j DROP • Bloquear o roteamento de pacotes do host 200.131.251.21. # iptables -A FORWARD -s 200.131.251.21 -j DROP • Limitar o numero de pacotes ICMP que chegam da rede em até 5 por segundo. Essa regra é especialmente interessante para evitar o ”ping da morte” (ping of death), famoso ataque de negação de serviço (Denial Of Service). # iptables -A INPUT -p icmp -m limit --limit 5/s -j ACCEPT • Aceitar todos os pacotes de conexões previamente estabelecidas e pacotes relacionados com conexões estabelecidas. # iptables -A INPUT -m state --state ESTABLISHED,RELATED \ -j ACCEPT

Linux como Roteador IP ou Firewall

3.4.3 iptables-save e iptables-restore Os programas iptables-save e iptables-restore são de grande importância pois eles permitem que as regras do iptables que estão em memória possam ser salvos em um arquivo e carregar para a memória as regras a partir de um arquivo. O iptables-save naturalmente coloca as regras na saida padrão, então para colocá-las em um arquivo basta direcionar a saída, da seguinte forma: # iptables-save > <arquivo-de-saída>

Já para restaurar as regras, basta especificar o arquivo onde elas estão descritas: # iptables-restore <arquivo-de-entrada>

Na figura 3.1 temos um exemplo de um arquivo com as regras geradas por iptables-save e que podem ser reestabelecidas com iptables-restore. # Completed on Tue Jan 28 13:55:24 2003 # Generated by iptables-save v1.2.4 on Tue Jan 28 13:55:24 2003 *filter #definição das chains :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [986:121665] #definição das regras [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT [1258:183506] -A INPUT -j REJECT --reject-with icmp-port-unreachable [62:2425] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT [315:27146] -A FORWARD -m state --state INVALID -j DROP [78:6256] -A FORWARD -s 192.168.1.21 -m state --state NEW -j ACCEPT [78:6256] -A FORWARD -d 192.168.1.21 -m state --state NEW -j ACCEPT [12214:876431] -A FORWARD -j REJECT --reject-with icmp-net-prohibited COMMIT # Completed on Tue Jan 28 13:55:24 2003

Figura 3.1: Arquivo com as regras do iptables

Esta seção teve por objetivo apenas apresentar o iptables como ferramenta de filtragem de pacotes. Existem outras extensões que aqui não foram abordadas, mas que podem

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

ser usadas. Para um maior entendimento, é recomendada a leitura da documentação do iptables 3 .

3.5 NETWORK ADDRESS TRANSLATION (NAT) 3.5.1

O que é NAT e qual a sua utilidade

NAT (Network Address Translation), ou tradução de endereço de rede, é uma técnica que altera os endereços de um pacote, e altera os pacotes de forma inversa. Isso não é simples de se fazer, pois o sistema não foi projetado para trabalhar dessa forma. Mas, dadas as imperfeições existentes nos protocolos de rede, são perfeitos, existe a necessidade de utilizar técnicas como essa para driblar algumas limitações. O NAT tem três utilidades básicas: o SNAT, O DNAT e proxy transparente. O SNAT ou Source-NAT, consiste em alterar o endereço de origem dos pacotes. A principal utilização do SNAT é o Masquerading, ou mascaramento de IPs, permitindo o compartilhamento de um único endereço IP válido com acesso à internet com uma rede de IPs não-válidos. O DNAT, ou Destination-NAT, é a alteração o endereço de destino dos pacotes. Isso é útil para prover acesso externo à servidores que estão em uma rede de endereços IP nãoválidos, existindo assim apenas a necessidade do roteador ter acesso à internet. Proxy é um programa que fica entre a rede local e o mundo externo, controlando a comunicação entre eles. O termo ”transparente” deve-se ao fato de os usuários não perceberem que estão sob um proxy. O Squid 4 , específico para fazer proxy, também pode ser usado para fazer um proxy transparente. 3.5.2 Source-NAT O SNAT é feito na chain POSTROUTING, da tabela nat. Ou seja, a alteração no endereço de saída do pacote é a última coisa a ser feita antes de ele ser enviado para a rede. O target do pacote deve ser SNAT, e o endereço de saída é especificado pelo parâmetro --to-source <endereço-de-saída>. Também pode ser especificada uma faixa de IPs ou endereços discretos. Também é possível determinar a origem dos pacotes na rede, restringindo os hosts que podem fazer SNAT. Existe uma modalidade de SNAT chamada Masquerading, especialmente útil para fazer SNAT em conexões com IP dinâmico (DHCP, linha discada), que é feita usando como target MAQUERADE e especificando a interface de saída. Para conexões com IP estático, deve ser usada a primeira forma de SNAT apresen3 http://www.netfilter.org/documentation/ 4 http://www.squid-cache.org

Linux como Roteador IP ou Firewall

tada. Segue abaixo dois exemplos, um utilizando SNAT para endereço de saída estático e outra para endereço de saída dinâmico. • SNAT com endereço de saída estático: # iptables -t nat -A POSTROUTING -s 192.168.4.0/24 -o eth0 \ -j SNAT -to-source 20.13.25.3 • SNAT com endereço de saída dinâmico: # iptables -t nat -A POSTROUTING -s 192.168.4.0/24 \ -o ppp0 -j MASQUERADE 3.5.3 Destination-NAT O Destination-NAT ou DNAT é feito na chain PREROUTING, também da tabela nat. As alterações no pacote serão feitas antes de qualquer coisa, então todas as outras regras do iptables já irão tratar o pacote com o novo endereço de destino. Para fazer DNAT, é necessário especificar o target DNAT, o novo endereço de destino, com o parâmetro --to-destination <endereço-de-destino>. Podem ser especificados também a interface de entrada. Também é possível fazer redirecionamento de porta usando DNAT. Basta especificar a porta de entrada, e também a porta no endereço de saída. Abaixo alguns exemplos: • Regra de DNAT simples: # iptables -t nat -A PREROUTING -i eth0 -DNAT \ --to-destination 192.168.1.6 • Regra de DNAT usando redirecionamento de porta: # iptables -t nat -A PREROUTING -i eth0 --dport 80 -DNAT \ --to-destination 192.168.1.6:8080 A utilização das idéias e ferramentas aqui apresentadas levam a utilização de um sistema rodando linux a ser um roteador e firewall simples e funcional. Existem necessidades especiais de roteamento e filtragem que não foram abordadas neste texto. Mas se os conceitos aqui apresentados forem absorvidos de maneira consistente, a tarefa de atender essas necessidades certamente consistirá apenas em utilizar extensões da ferramenta abordada de maneira diferente da apresentada.

EDITORA - UFLA/FAEPE - Serviรงos de Redes em Linux

4 SERVIÇOS DE CORREIO ELETRÔNICO

4.1

CONCEITOS BÁSICOS

Atualmente, a utilização de correio eletrônico tornou-se praticamente necessária sob o ponto de vista de negócios e social. Sendo assim, a configuração de sistemas de correio eletrônico tornou-se uma tarefa quase que obrigatória por parte dos administradores de sistema. Antes de abordar a configuração dos sistemas de correio eletrônico, são descritos alguns conceitos e termos relacionados: Mail-box: o mail-box é representado por um arquivo ou diretório cuja função é armazenar os e-mails recebidos por um usuário. Para o armazenamento das mensagens, geralmente são utilizados os diretórios /var/spool/mail ou /var/mail e as mensagens são vinculadas a arquivos cuja identificação (nome) consiste no próprio login do usuário proprietário das mensagens. Mail user agents (MUA): são aplicações diretamente ligadas aos usuários a fim de que esses possam manipular os seus e-mails (por exemplo, lê-los e escrevê-los). Quanto ao conteúdo das mensagens, antigamente era possível apenas o envio de informações textuais, porém atualmente, os MUAs já suportam o padrão MIME (Multipurpose Internet Mail Extensions) para o transporte de informações não textuais. Como exemplos de MUA, destacam-se o elm, mailx, pine, Netscape, mutt, evolution e zmail. Mail transfer agents (MTA): responsável por encaminhar as mensagens entre as máquinas. Realiza diversas funções de endereçamento de rede a fim de proporcionar a entrega correta e oferecer facilidades aos MUAs. O protocolo manipulado pelos MTAs consiste no SMTP (Simple Mail Transport Protocol – RFC 821) ou no Extended SMTP (ESMTP – RFC 1869, 1870, 1891 e 1985). Dentre os MTAs utilizados, destaca-se o sendmail, comumente instalado nos computadores em operação. Ainda em relação à transferência entre máquinas, surge a figura do mail sender agent (MSA). A função do MSA é aliviar a carga de trabalho do MTA realizando todo o pré-processamento

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

antes do efetivo envio. Neste caso, o MSA situa-se entre o MUA e o MTA, utilizando, para tanto, a porta 587 (ao invés da 25 utilizada pelo MTA). Delivery agents: visam a gravação das mensagens entregues pelo MTA da máquina específica do destinatário nos respectivos mail-boxes. Como exemplos de agentes de entrega tem-se: /bin/mail (entrega para usuários locais), /bin/sh (entrega para arquivos ou programas), mail.local e procmail (utilizado também como agente). Access agents: Os agentes de acesso permitem realizar o download a partir de MUA localizado remotamente em relação ao local de armazenamento dos e-mails. Para tanto, são utilizados dois protocolos de comunicação: o IMAP (Internet Message Protocol – http://www.imap.org/) e o POP (Post Office Protocol). Tais agentes são representados pelos daemons imapd e popd, respectivamente. Composição de uma mensagem: uma mensagem é composta por três partes distintas: envelope, cabeçalhos e corpo. O envelope identifica o emissor e destinatário da mensagem (relacionados aos campos From e To do SMTP. Por outro lado, os cabeçalhos seguem a recomendação RFC 822 e denotam, por exemplo, informações como data e hora do envio e quais MTAs foram envolvidos na comunicação. Por último, o corpo é representado pelo conteúdo da mensagem em si. Existem diversos modos para implementar o serviço de correio eletrônico em um domínio de computadores. Cabe ao administrador adotar a filosofia correta em função de, por exemplo, tamanho em relação ao número de máquinas e usuários, quantidade de tráfego correspondentes às mensagens e critérios de segurança das informações e do domínio em si (segurança tanto no sentido de fora para dentro quanto de dentro para fora). Adotar diversas máquinas para cada uma desempenhar um papel dentro do serviço de correio eletrônico ou adotar mecanismos de proxies são também políticas interessantes sob os pontos de vista funcional e administrativo. É conveniente lembrar que, para o bom funcionamento do serviço de correio eletrônico, os registros MX do sistema de DNS também deverão ser corretamente configurados. Veja mais detalhes no Capítulo 7.

4.2

USO DE ALIASES

Em alguns casos, é necessário redirecionar as mensagens para usuários ou locais distintos a fim de ser possível, por exemplo, a implementação de sistemas para listas de discussões. O sendmail suporta diversos mecanismos de aliases, como os configurados pelos administradores e usuários comuns, como também o LDAP (Lightweight Directory Access Protocol), NetInfo (NeXT/Apple), NIS e NIS+ (da Sun), dentre outros.

Serviços de Correio Eletrônico

Antes de abordar a manipulação de LDAP, é conveniente abordar os mecanismos tradicionais de aliases: aqueles mantidos pelo MTA, aqueles cuja localização do arquivo correspondente é /etc/mail/aliases (ou /etc/aliases) e aqueles mantidos pelo próprio usuário em seu arquivo ~/.forward. Para os dois primeiros casos, a sintaxe geral para cada linha é dada abaixo: nome_local:

destinatário1, destinatário2

A Figura 4.1 apresenta alguns exemplos de linhas que poderão estar contidas no arquivo de aliases. Essas linhas possuem ações associadas, descritas na Tabela 4.1. fulanoA: fulanoC: fulanoE: fulanoF: fulanoG: fulanoH:

fulanoB fulanoD@empresaX.com.br fulanoA, fulanoB, fulanoC :include:/etc/mail/lista1.mails /home/visitors/fulanoG/mail.in "| /home/prof/fulanoH/filter" Figura 4.1: Exemplos de Aliases

Tabela 4.1: Ações Associadas aos Aliases na Figura 4.1

Linha 1 2 3 4 5 6

Descrição Toda mensagem endereçada a fulanoA deve ser despachada para fulanoB na máquina local Toda mensagem endereçada a fulanoC deve ser despachada para fulanoD no endereço empresaX.com.br Toda mensagem endereçada a fulanoE deve ser despachada para fulanoA, fulanoB e fulanoC (localmente) Toda mensagem endereçada a fulanoF deve ser despachada para todos os usuários relacionados no arquivo /etc/mail/lista1.mails Toda mensagem endereçada a fulanoG deve ser anexada ao arquivo /home/visitors/fulanoG/mail.in Toda mensagem endereçada a fulanoH deve ser enviada ao aplicativo cujo código executável encontra-se em /home/prof/fulanoH/filter. Nesse caso nota-se a presença das aspas duplas em virtude do aparecimento do caracter especial ‘|’ (pipe), utilizado para representar a comunicação entre processos.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Os aliases são recursivos. Assim, caso haja o envio de uma mensagem para fulanoE, na verdade, fulanoB receberia a mensagem duas vezes (em função da linha 3 diretamente e em função da regra da linha 1 por intermédio de fulanoA) e fulanoC nunca receberia a mensagem, uma vez que a mesma seria redirecionada segundo a linha 2. O administrador de sistemas, por motivo de segurança, deve evitar a utilização de aliases do tipo aos indicados nas linhas 5 e 6. Existem linhas que deverão sempre estar contidas nos aliases, como por exemplo, a indicação do usuário real que exerce o papel do Mailer-Daemon (postmaster) e o usuário que receberá as mensagens relativas às pseudo-contas, como por exemplo, bin, sys e daemon. Uma questão a ser atentada refere-se à possibilidade de formação de loops de aliases, ou seja, por exemplo, caso tem-se: usr1 → usr2; usr2 → usr3; usr3 → usr1. Nesse caso, a mensagem ficaria em loop que seria detectado pelo sendmail. O limite de hops (um hop denota uma visita a uma máquina) por default vale 25, porém pode ser configurado pelo administrador de sistema. Usuários normais também podem ter os seu arquivo de aliases representado pelo “.forward”. A utilização de tal arquivo tem como vantagem o baixo overhead de modificação em relação ao overhead introduzido pela atualização de aliases do sistema. Um exemplo de conteúdo do arquivo .forward (localizado no diretório home do usuário) é mostrado na Figura 4.2. fulano@empresaX.com.br fulano@universidade.br Figura 4.2: Exemplos de Conteúdo para o Arquivo .forward

No exemplo da Figura 4.2, as mensagens endereçadas ao proprietário do arquivo .forward seriam redirecionadas para dois endereços: fulano@empresaX.com.br e fulano@universidade. br. A seguir é mostrada uma outra possibilidade de conteúdo do arquivo .forward: \fulano, "/home/fulano/mails.in", fulano@empresaX.com.br Nesse caso, as mensagens seriam mantidas no local padrão de e-mails recebidos (item iniciado pelo caracter ‘\’), além de serem gravados no arquivo /home/fulano/mails.in e enviados para fulano@empresaX.com.br. Com a finalidade de otimizar o tempo na procura de aliases por parte do sendmail, sugere-se a utilização de um sistema baseado em hash sobre o sistema de base de dados da Berkeley denominado ndbm ou dbm (esse último mais eficiente, desenvolvido por Keith

Serviços de Correio Eletrônico

Bostic e Margo Seltzer, disponível em http://www.sleepycat.com/). Para a criação de novos aliases utilizando-se DB, executa-se o comando newaliases ou sendmail -bi.

4.3

CONFIGURAÇÃO BÁSICA DO SENDMAIL

Esta seção aborda o sendmail como exemplo de sistema de transporte para correio eletrônico devido à sua alta utilização e, também, devido à sua eficiência e completude funcional frente aos demais sistemas. A configuração do sendmail consiste em, essencialmente, editar o arquivo de configuração sendmail.cf geralmente localizado no diretório /etc. Foi utilizada a palavra essencialmente, pois o sistema de correio eletrônico pode ser dependente de outros serviços porventura ativos na máquina, como NIS/NIS+ e DNS. O arquivo de configuração determina seis itens envolvidos com o funcionamento do sendmail: escolha de agentes de entrega, regras de reescrita de endereço, formatos dos cabeçalhos das mensagens, opções de funcionamento, critérios de segurança e atuação frente a spam. Para a configuração, será tratada aqui a utilização do manipulador de macro m4 ao invés de atuar diretamente sobre o arquivo sendmail.cf. A utilização das macros cobre cerca de 98% das necessidades de configuração do sendmail, além de apresentar uma complexidade bem inferior em relação à edição direta sobre o arquivo de configuração do sendmail. Para melhor ilustrar a utilização de macros, é colocado na Figura 4.3 um exemplo do arquivo de configuração de máquinas clientes dentro de um domínio pequeno (empresaX. com.br). Sugere-se que a máquina colocada no exemplo (smtp.empresaX.com.br) seja um alias, ou seja, um CNAME do DNS para uma máquina real do domínio da empresa. Note que os itens no formato m4 são iniciados com uma crase e terminados com um apóstrofe. A Tabela 4.2 descreve cada linha do exemplo da Figura 4.3.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

divert(-1) #### Definições para criação do sendmail.cf - máquinas clientes divert(0) VERSIONID(‘versão do sendmail...’) OSTYPE(‘linux’) FEATURE(‘nocanonify’) undefine(‘ALIAS_FILE’) define(‘MAIL_HUB’, ‘smtp.empresaX.com.br’) define(‘SMART_HOST’, ‘smtp.empresaX.com.br’) define(‘confFORWARD_PATH’, ‘’) MAILER(‘local’) MAILER(‘smtp’) Figura 4.3: Exemplo de Arquivo m4 para sendmail.cf em Máquinas Clientes

1 2 3 4 5 6 7 8 9 10 11 12

Serviços de Correio Eletrônico

Linha 01 02

03 04 05

08 09

10 11

Tabela 4.2: Descrição das Linhas do Exemplo Contido na Figura 4.3 Descrição Elimina lixos no fluxo de saída do m4 – útil para colocar comentários no início do arquivo Linha de comentário precedida pelos caracteres ‘#’. Caso o comentário venha no meio do arquivo, sugere-se a utilização da macro dnl (delete to new line) a fim de que as palavras contidas no comentários não sejam confundidas com palavras pertencentes ao repertório do m4, exemplo: dnl #comentário Final do comentário do início do arquivo A macro VERSIONID permite introduzir a versão sob manipulação. Tal definição aparecerá como comentário no arquivo sendmail.cf resultante Com a macro OSTYPE, o m4 pode incluir algumas flags ou particularidades inerentes ao sistema operacional identificado. No exemplo, o tipo identificado é o linux, porém poderia ser, por exemplo, solaris2, hpux11 e bsd4.4 O FEATURE (macro) possibilita instanciar características importantes ao comportamento do sendmail. No exemplo, foi utilizado o recurso nocanonify, o qual explicita que as pesquisas de DNS deverão ser realizadas na máquina servidora (e não nas clientes) A linha contendo undefine(‘ALIAS_FILE’) anula a utilização local dos arquivos de aliases, ou seja, toda a manipulação de aliases será feita na máquina servidora. Caso fosse necessária a utilização de algum arquivo de aliases, pode-se explicitá-lo com o define da seguinte forma: define(‘ALIAS_FILE’, ‘/etc/aliases’). Nesse caso, o sendmail verificaria o arquivo /etc/aliases. Caso fosse necessário fazer pesquisa em vários arquivos, usa-se: define(‘ALIAS_FILE’, “/etc/aliases, nis:mail.aliases”). Nesse caso, caso a busca em /etc/aliases falhasse, seria tentado o mapa NIS denominado mail.aliases O MAIL_HUB sinaliza que todos os e-mails são recebidos por intermédio da máquina servidora, no caso, denominada como smtp.empresaX.com.br Assim como pode-se definir a máquina que disponibilizará os e-mails a serem recebidos, há como especificar a máquina que tratará os e-mails a serem enviados. No exemplo aqui colocado, foi utilizado a macro SMART_HOST para indicar que os e-mails locais serão tratados localmente e aqueles endereçados às pessoas externas serão manipulados pela máquina servidora (smtp.empresaX.com.br) A linha com o confFORWARD_PATH define ou anula a utilização do arquivo .forward. No caso, é instanciado como nulo, deixando a utilização apenas para a máquina servidora A macro MAILER indica qual ou quais os agentes de entrega que estarão ativos no ambiente. Com essa macro, pode-se utilizar as seguintes opções: local, smtp, fax, usenet, procmail, qpage, cyrus, pop, phquery e uucp. No exemplo, a linha referencia a ativação do agente local Por último, assim como o agente de entrega local é ativado, o agente smtp é também ativado conforme a última linha do exemplo

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Por outro lado, existe o arquivo de configuração do sendmail por parte da máquina servidora. O exemplo da Figura 4.4 ilustra tal configuração (também baseada em macros m4). A Tabela 4.3 descreve as linhas referentes a esse exemplo. divert(-1) #### definições para criação do sendmail.cf - máquina servidora divert(0) VERSIONID(‘versão do sendmail’) OSTYPE(‘linux’) DOMAIN(‘generic’) MASQUERADE_AS(‘empresaX.com.br’) MASQUERADE_DOMAIN(‘empresaX.com.br’) undefine(‘BITNET_RELAY’) undefine(‘UUCP_RELAY’) define(‘confCHECK_ALIASES’, ‘True’) define(‘confCOPY_ERRORS_TO’, ‘Postmaster’) define(‘confEBINDIR’, ‘/usr/lib’) define(‘confERROR_MODE’, ‘m’) define(‘confHOST_STATUS_DIRECTORY’, ‘.hoststat’) define(‘confNO_RCPT_ACTION’, ‘add-to-undisclosed’) define(‘confPRIVACY_FLAGS’, ‘authwarnings,needmailhelo,noexpn,novrfy’) define(‘confTRUSTED_USERS’, ‘majordomo’) define(‘confMAX_DAEMON_CHILDREN’, ‘30’) FEATURE(‘allmasquerade’) FEATURE(‘masquerade_entire_domain’) FEATURE(‘masquerade_envelope’) FEATURE(‘always_add_domain’) FEATURE(‘local_lmtp’) define(‘LOCAL_MAILER_FLAGS’, ‘SXfmnz9PE’) FEATURE(‘mailertable’, ‘hash /etc/mail/mailertable’) FEATURE(‘virtusertable’, ‘hash /etc/mail/virtusertable’) MAILER(‘local’) MAILER(‘smtp’) Figura 4.4: Exemplo de Arquivo m4 para sendmail.cf em Máquina Servidora

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Serviços de Correio Eletrônico

Tabela 4.3: Descrição das Linhas do Exemplo de Arquivo m4 para sendmail.cf da Figura 4.4 Linha 06 07

09 10 11 12 13 14 15

18 19

Descrição Identifica um arquivo m4 que caracteriza o domínio. Nesse caso, o arquivo denotado é o generic.m4, o qual é ilustrado na Figura 4.5 A macro MASQUERADE_AS faz com que todas as mensagens provenientes do domínio tenham como endereço fonte a string passada como argumento. Por exemplo, toda mensagem emitida por fulanoA@maq01.empresaX.com.br será marcada como sendo proveniente de fulanoA@empresaX.com.br, omitindo-se, nesse caso, o nome do host responsável pelo envio Mascara domínios em ambientes que hospedam domínios virtuais. A lista de domínios virtuais é encontrada com o uso do recurso use_cw_file, o qual será descrito junto à explicação do domínio genérico, na Figura 4.5 Desativa recursos associados à BITNET Desativa recursos associados à UUCP Quando a opção confCHECK_ALIASES é ativada, todo alias é verificado pelo DNS em todo o momento que se executa o newaliases Endereço de cc para mensagens que retratam erros. No exemplo, cc é direcionado ao Postmaster Localização do binário relativo ao mail.local Define a forma de manipulação de erro. No exemplo, a diretiva ‘m’ indica para retornar ao remetente mensagens de erros A opção HOST_STATUS_DIRECTORY é utilizada em ambientes que apresentam um alto volume de e-mails a serem reenviados devido à uma falha na tentativa anterior de entrega. Nesse caso, o sendmail organizará suas filas por nome de hosts a fim de priorizar aqueles encontrados nessa situação e, também, permitir uma otimização em relação ao envio Essa linha determina a ação que deverá ser realizada quando a mensagem tiver algum recipiente inválido. No caso, o campo TO é instanciado como undisclosed-recipients PRIVACY_FLAGS define as flags para o processamento do sendmail. No exemplo, tem-se: authwarnings (adiciona cabeçalho Authentication-Warning); needmailhelo (exige SMTP HELO); noexpn (não permite o comando SMTP EXPN) e novrfy (não permite o comando SMTP VRFY) O TRUSTED_USERS é utilizado para determinar usuários representativos de lista de discussões. No arquivo de configuração também há a possibilidade de definir quantos processos filhos poderão ser criados a partir do sendmail original. No exemplo, definiu-se esse número como 30 O recurso allmasquerade mascara tanto o emissor quanto o destinatário da mensagem

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

21 22 23 24

masquerade_entire_domain mascara o domínio inteiro O masquerade_envelope mascara, também, os endereços do envelope e os endereços do cabeçalho O preenchimento dos campos dos recipientes podem ser completados com o always_add_domain A linha com o indicativo local_lmtp permite que o correio local seja manipulado por um agente capaz de manipular o LMTP (Local Mail Transport Protocol – RFC 2033) liberando um pouco o processamento por parte do sendmail A referida linha permite definir as flags com as quais o agente local irá ser executado. As flags lsDFM são sempre inclusas. Portanto, no exemplo, além das aqui citadas, as flags SXfmnz9PE são igualmente incluídas na lista (para maiores detalhes, ver o manual do sendmail) O recurso mailertable permite que mensagens endereçadas a um host ou um domínio sejam redirecionadas a um destino alternativo por intermédio de um agente de correio específico. O arquivo que representa a tabela é passada como parâmetro e, nesse exemplo, utiliza o método hash para facilitar a busca dentro do arquivo. Tal recurso é útil quando são manipuladas outras estruturas de correio eletrônico, como UUCP e BITNET. Caso o sistema manipule domínios virtuais, é necessário habilitar o recurso virtusertable a fim de suportar os aliases associados. Neste caso, os registros MX do DNS devem estar corretamente configurados e o arquivo cw deve estar presente ou especificado como argumento do recurso

Conforme citado, o exemplo da Figura 4.4 requer um arquivo m4 que representa o domínio local (conforme a linha 6). Tal arquivo representa as particularidadees para o domínio genérico e é listado na Figura 4.5. A linha que contém confFORWARD_PATH foi quebrada apenas para fins de editoração.

divert(-1) #### arquivo m4 para Domínio genérico divert(0) VERSIONID(‘indicativo da versão’) define(‘confFORWARD_PATH’,‘$z/.forward.$w+$h:$z/.forward+$h:$z/ .forward.$w:$z.forward’) define(‘confMAX_HEADERS_LENGTH’, ‘32768’) FEATURE(‘redirect’) FEATURE(‘use_cw_file’) EXPOSED_USER(‘root’) Figura 4.5: Arquivo m4 para Domínio Genérico

1 2 3 4 5 6 7 8 9 10

Serviços de Correio Eletrônico

No exemplo da Figura 4.5 nota-se a presença do redirect. Esse recurso faz com que mensagens destinadas a pessoas que não mais pertençam ao domínio sejam devolvidas ao emissor junto com o novo endereço do destinatário a fim de atualizar o seu cadastro. Para efetivar o redirect, no arquivo de aliases deve aparecer: fulanoA: novonome@novaempresa.com.br.REDIRECT Por sua vez, o use_cw_file habilita a classe interna w do sendmail contendo o nome de todos os hosts locais aptos a entregarem e receberem mensagens manipuladas pelo servidor. O nome do arquivo contendo a relação de hosts é denominado, por default, como sendmail.cw porém o seu nome pode ser alterado com opção confCW_FILE. Para efetivar a atualização desse arquivo é necessário enviar um sinal de HUP ao sendmail (kill -1). Finalizando o exemplo, a macro EXPOSED_USER determina que o usuário root seja excluído das alterações realizadas pelo MASQUERADE, ou seja, as mensagens provenientes do root carregarão, por exemplo, o nome da máquina emissora do e-mail. Após a edição dos arquivos m4, deve-se criar efetivamente o arquivo sendmail.cf por intermédio do comando m4: # m4 sendmail.mc > /etc/sendmail.cf Os arquivos de aliases poderão ser criados pelo comando newaliases. E, após isso, deve-se proceder a reiniciação do daemon do sendmail para efetivar as alterações referentes ao funcionamento do sistemas de correio eletrônico.

4.4

OUTROS EXEMPLOS DE SISTEMA DE E-MAIL

Essa seção se destina a dar uma visão genérica de dois outros sistemas para a manipulação de correio eletrônico: QMail e Postfix. 4.4.1

QMail

Um outro exemplo de sistema para correio eletrônico é o QMail (http://www.qmail. org/), criado por D.J. Bernstein e lançado (primeira verão pública – vs 0.7 beta) no início de 1996. Como o projeto de desenvolvimento de QMail foi iniciado após a grande expansão da internet, questões como segurança e eficiência foram levadas em consideração durante sua implementação. Por esses motivos, atualmente ocupa a segunda colocação entre os servidores de e-mail mais utilizado no mundo UNIX.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

O QMail apresenta contra seu uso o fato de que não é software livre (apesar de poder ser usado gratuitamente) e não implementar todas as funcionalidades existentes no sendmail. Ele utiliza arquivos de configuração bem definidos, os quais são listados na Tabela 4.4 e exemplificados na Tabela 4.5. Tabela 4.4: Descrição dos Arquivos de Configuração do QMail Arquivo (diretório /var/qmail) Descrição alias/.qmaildefault alias/.qmail-mailer-daemon alias/.qmail-postmaster alias/.qmail-root control/defaultdomain control/defaulthost

control/locals control/me control/plusdomain control/smtproutes

control/rcpthosts

4.4.2

Informa o endereço para o envio da mensagem caso a entrega utilizando o agente local falhe Representa o usuário real que irá responder pelo mailer-daemon Representa o usuário real que irá responder pelo postmaster Representa o usuário real que irá responder pelo root Identifica o nome do domínio Caso este arquivo exista, todas as mensagens serão mascaradas para simplesmente o nome do domínio, desprezando-se, por exemplo, a identificação do host no qual a mensagem foi gerada Identificação dos hosts identificados como locais (para as mensagens serem manipuladas pelo agente local) Nome da máquina local Identificação do domínio superior Roteia todas as mensagens para a máquina servidora. Caso este arquivo não exista, as mensagens serão despachadas diretamente aos servidores dos destinatários (útil para o caso de provedores). Caso apareça ‘:’ , as mensagens não locais serão roteadas para a máquina servidora. Rotas específicas podem ser criadas para domínios ou usuários específicos – estes deverão ser colocados antes do ‘:’ Caso exista este arquivo, identifica os domínios autorizados a receber mensagens pelo QMail

Postfix

Um outro exemplo de sistema de correio eletrônico atualmente bastante difundido é o Postfix. O projeto desenvolvido por Wietse Venema no T. J. Watson Research Center (IBM), tendo várias características que o qualificam como concorrente direto do QMail.

Serviços de Correio Eletrônico

Tabela 4.5: Exemplo de conteúdo dos arquivos de configuração do QMail Arquivo (diretório /var/qmail) Exemplo de conteúdo alias/.qmaildefault alias/.qmail-mailer-daemon alias/.qmail-postmaster alias/.qmail-root control/defaultdomain control/defaulthost control/locals control/me control/plusdomain control/smtproutes

| forward "$LOCAL"@mail.empresaX.com.br root root root empresaX.com.br empresaX.com.br empresaX.com.br host1.empresaX.com.br host1.empresaX.com.br com.br :mail.empresaX.com.br

O Postfix apresenta facilidades de configuração, utiliza a biblioteca PCRE (Perl Compatible Regular Expression) a fim de poder filtrar as mensagens de modo eficiente, suporta apenas UUCP e, para a reescrita de endereços, utiliza consultas a arquivos simples, DB, dbm, LDAP, NIS ou NetInfo. Para a manipulação das mensagens, o Postfix implementa quatro filas: maildrop: fila que recebe, do agente do usuário, as mensagens a serem enviadas; incoming: para armazenar as mensagens recebidas; active: armazena as mensagens que ainda estão sendo processadas para o envio; deferred: mensagens que cuja tentativa de envio falhou. O Postfix utiliza vários utilitários, porém os mesmos não possuem relação entre eles (por exemplo, relação pai/filho): postfix: deve ser executado como root a fim de iniciar a parar o sistema de correio; postalias: utilzado para manipular aliases (como o newaliases); postcat: lista o conteúdo de arquivos na fila; postconf: exibe o edita o arquivo de configuração do Postfix (main.cf); postdrop: adiciona mensagens à fila maildrop. Para adicionar uma segurança adicional em relação à escrita na fila, pode-se configurar o postdrop como setgid; postkick, postlock, postlog: fornece bloqueio e registro em log para scripts em shell; postmap: cria tabelas de bases de dados (semelhante ao makemap do UNIX); postsuper: gerencia as filas.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Para a configuração, são utilizados, essencialmente, dois arquivos: master.cf que faz a configuração geral do sistema e o main.cf, que apresenta uma sintaxe semelhante ao sendmail.cf e é responsável pelas informações inerentes ao roteamento, reescrita e filtragem. Exemplos de configuração podem ser encontrados junto com a distribuição do sistema.

4.5

LISTAS DE DISCUSSÃO.

Sistemas para listas de discussão manipulam, em primeira instância, aliases para correio eletrônico. Dessa maneira, um gerenciador de lista de discussão permite a configuração de grupos de discussão por e-mail, pois associa um único endereço a vários e-mails de pessoas interessadas na discussão sobre um dado tema. Entre as principais alternativas gratuitas para gerenciamento de listas de discussão, merecem destaque o Ecartis (http: //www.ecartis.org/, Majordomo (http://www.greatcircle.com/majordomo/) e o Mailman (http://www.list.org/). Cada gerenciador é configurado de forma particular, possuindo mecanismos próprios para criação e gerenciamento de listas de discussão. Dessa maneira, essa apostila não irá abordar a configuração desses gerenciadores.

5 O SERVIDOR WWW

5.1

COMENTÁRIOS INICIAIS

Assim como os protocolos FTP e SMTP, os protocolos utilizados pelos serviços WWW utilizam o conceito de cliente-servidor. O principal protocolo utilizado pelo WWW é o HTTP (HyperText Transfer Protocol), o qual baseia-se no TCP, usando a porta 80 para a transferência das informações. Um outro protocolo utilizado, baseado no SSL (Secure Sockets Layer), é o HTTPS (Secure HTTP), padronizado para utilizar a porta TCP 443. Além de disponibilizar informações estáticas, o servidor HTTP também pode fornecer informações dinâmicas utilizando-se, para tal, scripts CGI (Common Gateway Interface). Tais scripts são programas escritos por intermédio de uma linguagem que suporte manipulação de entrada e saída sob demanda (por exemplo, C e Perl) a fim de interfacear com o servidor HTTP. Administrador e programadores responsáveis pelos scripts têm que observar bastante questões relacionadas ao aspecto de segurança, uma vez que tais programas são chamados remotamente e têm a possibilidade de acessar arquivos, periféricos e qualquer outro recurso na máquina na qual se realizará o processamento. Informações sobre segurança poderão ser obtidas no endereço: http://www.w3.org/Security/Faq/www-security-faq. html. Existem diversos servidores de HTTP disponíveis atualmente, onde o mais popular, por razões de desempenho e quantidade de sistemas operacionais suportados, é o Apache. Em razão de sua difusão, o Apache foi aqui escolhido para ilustrar a manipulação de servidores HTTP.

5.2

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

CONFIGURAÇÃO BÁSICA DO APACHE

A configuração do Apache consiste, basicamente, de duas etapas: compilação / instalação e a configuração propriamente dita. Caso a instalação seja feita via compilação local, Após o download do pacote, deve-se executar o script de instalação, especificando o diretório no qual o Apache será instalado. Tal especificação é feita por intermédio da opção “- -prefix”, conforme ilustrado abaixo: # ./configure - -prefix=/usr/local/apache Além da opção prefix, é possível também incluir ou remover módulos através das opções, respectivamente, “- -enable_module” e “- -disable_module”. A Tabela 5.1 lista alguns módulos úteis e não inclusos na instalação padrão.

Módulo

Tabela 5.1: Módulos Úteis não Incluídos na Instalação Padrão Descrição

auth_dbm auth_db usertrack rewrite expires proxy

Autenticação de usuários utilizando DBM Autenticação de usuários utilizando Berkeley DB Monitora as ações de click do usuário em navegadores que suportam cookies Mapeamento URL-nome_de_arquivo usando expressões regulares Incorpora datas de expiração aos documentos Embute a funcionalidade de servidor proxy ao Apache

Para obter uma lista completa dos módulos a serem incluídos na instalação padrão, o administrador pode consultar o arquivo src/Configuration na distribuição do Apache ou consultar o endereço http://www.apache.org/docs/mod/index.html. Duas páginas sugeridas que podem ser acessadas pelo administrador seriam: http://www.cpan. org/modules/by-module/Apache/ e http://modules.apache.org. Em tais páginas, podem ser encontrados diversos módulos adicionais a serem, possivelmente, incorporados ao Apache. Convém salientar que a incorporação de módulos específicos pode proporcionar a habilitação de suporte a ASP, PHP e afins. O procedimento para a adição de módulos após o processo de instalação pode ser encontrado na Seção 5.2.1. Quando o processo representado pelo configure finalizar, há a necessidade de executar o utilitário make e, após, o make install para completar o processo de compilação e instalação (seqüência ilustrada na Figura 5.1). Caso o administrador use distribuições baseadas em pacotes (DEB ou RPM), então basta instalar o pacote relativo ao Apache disponibilizado em sua distribuição.

O Servidor WWW

# ./configure --prefix=/usr/local/apache --enable_module=auth_dbm #make #make install Figura 5.1: Etapas para Instalação do Apache

Após a compilação e instalação, o administrador deve configurar o Apache de acordo com as suas necessidades. Para tanto, há a necessidade de manipulação de três arquivos (mantidos, em geral, no diretório /etc/httpd/conf): httpd.conf, srm.conf e access.conf. Após configurado, o Apache pode ser iniciado manualmente por intermédio do comando apachectl, conforme exemplo abaixo: # /usr/local/apache/apachectl start Caso seja conveniente o início automático, no momento de boot da máquina, do serviço de servidor de páginas, pode-se introduzir o trecho ilustrado na Figura 5.2 em /etc/ rc.d/rc.local. Na maioria das distribuições, será providenciado um script de inicialização /etc/rc.d/init.d/httpd que também pode ser usado. Em várias distribuições, o Apache também pode ser iniciado com o comando service httpd start. if [ -x /usr/local/apache/httpd ] ; then /usr/local/apache/apachectl start echo -n ’Apache Server iniciado’ fi Figura 5.2: Trecho para Inicialização do Apache no Momento de Boot

Informações adicionais sobre a configuração do Apache podem ser encontradas no endereço: http://httpd.apache.org/docs/configuring.html. As diretivas utilizadas nos arquivos de configuração podem ser vistas em http://www.redhat.com/ docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-apache-config.html. 5.2.1

O Arquivo httpd.conf

No arquivo de configuração geral do Apache, denominado http.conf, as diretivas de operação estão agrupadas em três seções básicas: diretivas globais de controle, diretivas para as manipulações dentro do domínio principal e diretivas para manipular as requisições endereçadas aos domínios virtuais. Um exemplo do arquivo http.conf pode ser encontrado no endereço http://webmaster.bankhacker.com/php/http.conf.phtml.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Ainda sobre o referido arquivo, caso a máquina faça a hospedagem de vários domínios, há a necessidade da introdução de cláusulas do tipo VirtualHost a fim de determinar os domínios virtuais sediados na máquina em questão (uma cláusula para cada interface virtual). A Figura 5.3 exibe um trecho exemplo a ser colocado no referido arquivo de modo a informar ao Apache a existência de um domínio virtual da empresaX. Nesse exemplo, os arquivos do site www.empresaX.com.br (configurado pela diretiva ServerName) poderão ser encontrados no diretório /var/www/empresaX (configurado pela diretiva DocumentRoot). <VirtualHost 200.129.35.88> ServerAdmin webmaster@www.empresaX.com.br DocumentRoot /var/www/empresaX ServerName www.empresaX.com.br ErrorLog logs/www.empresaX.com.br-error_log TransferLog logs/www.empresaX.com.br-access_log </VirtualHost> Figura 5.3: Exemplo de Definição de Domínio Virtual para EmpresaX

No caso de uso de domínios virtuais, é comum o uso de interfaces virtuais. Uma interface virtual é criada sob uma interface real, providenciando um outro endereço IP para o mesmo dispositivo de rede. Para adicionar interfaces virtuais, o procedimento é análogo à manipulação de interfaces físicas, ou seja, pelo comando ifconfig. A única diferença consiste na forma de se identificar as interfaces. Por exemplo, para a definição de interfaces virtuais a partir da eth0, basta diferenciá-las por intermédio da sintaxe eth0:y, onde y representa o número da interface (com y ≥ 0). Dessa forma, o comando a seguir define os parâmetros de configuração da interface virtual eth0:0 que ficará sob responsabilidade da interface física eth0: # ifconfig eth0:0 200.129.35.88 netmask 255.255.255.0 up Observe que o uso de interfaces virtuais pode degradar o desempenho do servidor, pois haverá um único dispositivo real para vários endereços IPs. Dado o atual baixo custo de placas de rede, recomenda-se, preferencialmente o uso de várias placas de rede, isolando o tráfego de maneira mais eficiente. Como mencionado anteriormente, há a possibilidade de adição de módulos com a finalidadem de manipular serviços e mecanismos não previstos durante a etapa de instalação e configuração inicial. Para tanto, pode-se utilizar a diretiva LoadModule conforme ilustrado a seguir:

O Servidor WWW

LoadModule <nome_do_módulo> modules/<nome_do_arquivo.so> Caso o administrador esteja incluindo, por exemplo, um módulo PHP, não deve se esquecer de relacionar as extensões ao serviço. Para tanto, usa-se a diretiva AddType conforme o exemplo a seguir: AddType application/x-httpd-php .php .php4 .phtml .whatever A carga do módulo praticamente sob demanda é possível pelo fato de que o Apache suporta DSO (Dynamic Shared Object). Desta forma, o administrador pode criar seus próprios módulos em função da necessidade corrente e incorporá-los ao Apache. Tais módulos deverão ficar no diretório /usr/lib/httpd ou /usr/lib/apache. Uma documentação sobre a criação de módulos pode ser encontrada no endereço http://httpd.apache. org/docs-2.0/dso.html. Após a alteração do httpd.conf, há a necessidade de reiniciar o Apache por intermédio, por exemplo, da opção reload: # service httpd reload 5.2.2

Os Arquivos srm.conf e access.conf

O arquivo srm.conf é responsável pela identificação dos recursos acessados pelo servidor de páginas. Dentre os recursos, destacam-se a localização do documento raiz a ser transferido ao cliente e a seqüência de busca frente àqueles pertinentes aos usuários. Um exemplo do arquivo srm.conf pode ser encontrado no endereço http://www. webmeister.ch/server/webserver/apache/srm_conf.htm. Por último, o arquivo access.conf determina aspectos relacionados ao controle de acesso. Tal controle pode ser em função de arquivos específicos ou em função de diretórios. A sua sintaxe e descrição de seus campos podem ser observados em http://www.webmeister. ch/server/webserver/apache/access_conf.htm. Observe que, em versões mais recentes do Apache, a recomendação é utilizar apenas o arquivo httpd.conf, deixando os arquivos srm.conf e access.conf vazios. Isso facilita a manutenção de configurações, simplificando processos de manutenção e atualização de servidores. Dessa maneira, o arquivo httpd.conf irá conter também as diretivas de recursos e permissões de acesso. A Figura 5.4 mostra um exemplo de configuração de permissão no diretório raiz. Na configuração efetuada na Figura 5.4, a linha contendo a diretiva “Options” especifica o que é válido para essa árvore de diretórios. A opção “Indexes” faz com que seja

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

<Directory "/var/www/html"> # Opções do Diretório Options Indexes FollowSymLinks # Opções para .htaccess AllowOverride All # Controlando quem pode acessar Order allow,deny Allow from all </Directory> Figura 5.4: Exemplo de Definição de Domínio Virtual para EmpresaX

listado o conteúdo dos diretórios ou subdiretórios, caso não sejam encontrados arquivos de índice (index.html, index.htm ou similares). A opção “FollowSymLinks” especifica que é possível usar links simbólicos nessa árvore. Se for habilitada a opção “ExecCGI”, então poderão ser executados arquivos CGI nesse diretório (e também em seus subdiretórios). Observe que o uso de CGIs deve ser controlado para evitar ataques. A diretiva “AllowOverride, ilustrada na Figura 5.4, permite especificar quais opções podem ser sobrepostas via arquivo .htaccess. Dessa maneira, o administrador pode definir métodos de autenticação para diretórios específicos. A Figura 5.5 ilustra um exemplo desse arquivo limitando o acesso para usuários cadastrados no arquivo /var/www/html/ .htusers. Nesse caso, esses usuários são cadastrados por meio do comando htpasswd. A Figura /5.6, por sua vez usa restrição de acesso por IP. Consulte a documentação do Apache para maiores detalhes. AuthName "restricted stuff" AuthType Basic AuthUserFile /var/www/html/.htusers require valid-user Figura 5.5: Exemplo de Arquivo .htaccess AuthName "restricted stuff" Order deny,allow deny from all allow from 127.0.0.1 allow from 200.131.251. Figura 5.6: Exemplo de Arquivo .htaccess

O Servidor WWW

5.3

HABILITAÇÃO DO HTTPS

O serviço de HTTPS pode ser manipulado pelo Apache de duas maneiras: uma é utilizar o Apache-SSL (http://www.apache-ssl.org/), uma versão do Apache com suporte próprio a SSL. A outra forma, talvez a mais comum, é utilizar um módulo específico para SSL, o mod_ssl (http://www.modssl.org). Nesse caso, utiliza-se o servidor padrão. Qualquer que seja a opção do administrador, as duas estratégias vão funcionar de maneira semelhante, com excessão da configuração do módulo em si. Na maioria das distribuições, o suporte ao HTTPS já vem habilitado na configuração padrão, não sendo necessário alterar em nada a configuração do Apache. Nesse caso, o servidor WEB será responsável por atender pedidos HTTPS na porta 443 e HTTP na porta 80, de acordo com o padrão. O administrador deverá então criar as chaves para os sites exportados pelo servidor. Caso não faça isso, será utilizada uma chave padrão, portanto, sem segurança adequada. O processo de criação de chaves será visto na Seção 5.3.1. Considerando-se o uso do mod_ssl, inicialmente ele deve ser habilitado através do uso das diretivas LoadModule e AddModule. A Figura 5.7 ilustra essas diretivas. Nesse exemplo, são utilizados comandos de pré-processamento <IfDefine HAVE_SSL> ... </IFDefine>. Nesse caso, somente se encontrado o módulo mod_ssl é que o apache tentará carregá-lo. A variável HAVE_SSL é habilitada pelo script de inicialização /etc/rc. d/init.d/httpd. O uso das diretivas é desnecessário, mas facilita a manutenção de uma única configuração para vários servidores. <IfDefine HAVE_SSL> LoadModule ssl_module </IfDefine> <IfDefine HAVE_SSL> AddModule mod_ssl.c </IfDefine>

modules/libssl.so

Figura 5.7: Carregando o Módulo SSL

Uma vez habilitado o módulo SSL, resta a sua configuração, o que é ilustrado nas Figura 5.8 e Figura 5.9. Na Figura 5.8 são configurados os parâmetros básicos da negociação inicial feita pelo protocolo SSL, bem como os arquivos de registro dessa negociação. Na Figura 5.9, por sua vez, é configurado o domínio virtual padrão (que usa o mesmo nome da máquina). Nesse caso, note que é habilitada a diretiva SSLEngine, bem como é definido onde estão localizadas a chave e o certificado do servidor. É importante estar atento a esses caminhos, pois ele deve apontar para as chaves criadas para o servidor.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

<IfModule mod_ssl.c> SSLPassPhraseDialog builtin SSLSessionCache shm:logs/ssl_scache(512000) SSLSessionCacheTimeout 300 SSLMutex file:logs/ssl_mutex SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLLog logs/ssl_engine_log SSLLogLevel error </IFModule> Figura 5.8: Carregando o Módulo SSL <IfDefine HAVE_SSL> <VirtualHost _default_:443> ErrorLog logs/error_log TransferLog logs/access_log SSLEngine on SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key </VirtualHost> </IFDefine> Figura 5.9: Carregando o Módulo SSL

5.3.1

Criação de Chaves para HTTPS

O processo de criação de chaves é feito através do uso do arquivo /etc/httpd/conf/ Makefile, na verdade um link para /usr/share/ssl/certs/Makefile. Pode-se criar as chaves e o certificado entrando nesses diretórios e emitindo os comandos make server.key e make server.crt Uma vez criada as chaves, elas devem ser copiadas para o diretório especificado no arquivo httpd.conf. Essa chave irá exigir senha (passphrase) para inicializar o servidor. Caso haja confiança no servidor pode-se evitar a necessidade de digitação da senha, efetuandose os seguintes passos entre a criação da chave e do certificado:

O Servidor WWW

• cp -p server.key server.key.orig • openssl rsa -in server.key.orig -out server.key • chmod 400 server.key server.key.orig • chown root server.key server.key.orig Uma outra forma de se criar a chave e o certificado, usando-se apenas o comando openssl é ilustrada a seguir: • openssl req -new -text -out cert.req • openssl rsa -in privkey.pem -out server.key • openssl req -x509 -in cert.req -text -key server.key \ -out server.crt • chmod 400 server.key server.crt • chown root server.key server.crt

EDITORA - UFLA/FAEPE - Serviรงos de Redes em Linux

6 COMPARTILHAMENTO DE ARQUIVOS

6.1

COMENTÁRIOS INICIAIS

Compartilhamento de arquivos é uma necessidade antiga na internet. O serviço de FTP (File Transfer Protocol) é um dos mais antigos e conhecidos, por exemplo. Existem várias formas de compartilhamento de arquivos em UNIX. A mais usada, em redes locais é o uso do NFS (Network File Server). Para uso remoto, o FTP é o mais conhecido. Além disso, também é possível utilizar o SAMBA, uma implentação do CIFS (Common Internet File System), para compartilhamento de arquivos com máquinas Windows. Dessa maneira, o objetivo deste capítulo é abordar o compartilhamento de arquivos em Linux, especialmente NFS, FTP e SAMBA. Essa abordagem será feita principalmente sob o ponto de vista do servidor, mas também será visto a configuração de clientes NFS ou SAMBA.

6.2

USO DE NFS

O NFS foi desenvolvido para permitir o compartilhamento de diretórios em rede. Atualmente, encontra-se na versão 3. Essa versão é suportado por kernel com versão 2.4 ou superior. Além disso, já encontra-se definido o protocolo do NFS versão 4, mas nenhuma implementação consistente do mesmo. Os serviços de NFS são implementados ou diretamente no kernel ou como módulos. Entretanto, é recomendável instalar o pacote nfs-utils, que fornece uma série de ferramentas extras para o NFS, aumentando a performance do servidor NFS de Linux tradicional. Além disso, possui o aplicativo showmount, que consulta o daemon de uma máquina remota por informação acerca do servidor NFS (Network File System) dessa máquina. Consulte a página de manual desse comando para mais detalhes.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

O processo de uso de NFS é relativamente simples, sendo necessário efetuar configurações na máquina servidora para compartilhar os diretórios. Na máquina cliente, o processo é de montagem de partições, com o uso do mount e edição do /etc/fstab. 6.2.1

Configurando o Servidor NFS

Em geral, a única configuração a ser feita para compartilhar um diretório é a edição de uma linha no arquivo /etc/exports. Uma entrada nesse arquivo possui a seguinte sintaxe: diretório maq1(op11,op12) ...

maqn(opn1,opn2)

Nesse caso, diretório é o diretório a ser compartilhado, maq1 e maqn são as máquinas para as quais o diretório está sendo exportado e opxy é opção de compartilhamento. As opções de compartilhamento mais importantes são listadas na Tabela 6.1. Outras opções podem ser verificadas na página de manual do arquivo /etc/exports (man export). Tabela 6.1: Opções do Arquivo /etc/exports

Opção

Descrição

ro rw

O diretório é compartilhado apenas para leitura O diretório é compartilhado para leitura e escrita pela máquina cliente Por padrão, qualquer requisição feita pelo usuário root na máquina cliente é convertido para o usuário anônimo (geralmente nobody ou nfsnobody) na máquina servidora, aumentando o nível de segurança do processo. Caso o usuário root da máquina cliente deva ter acesso irrestrido ao diretório compartilhado, então deve-se usar a opção no_root_squash Mapeia todos usuários e grupos para o usuário anônimo

no_root_squash

all_squash

Um exemplo de configuração do arquivo /etc/exports pode ser visualizado na Figura 6.1. Nessa figura, o leitor pode perceber que é possível exportar um diretório para uma rede ou para uma máquina. Além disso, também é possível utilizar máscaras de rede, bem como os caracteres coringas ‘*’ (para representar um conjunto de caracteres) e ‘?’ (para representar um único caracter). No exemplo da Figura 6.1, tem-se que o diretório /usr encontra-se exportado para as máquinas na rede 192.168, para a máquina de nome madonna, para as máquinas

Compartilhamento de Arquivos

/usr 192.168 (ro) madonna (rw) lab*.dominio.com.br (ro) 100.1.0.2 (ro) /usr/local 192.168 (ro) madonna (rw,no_root_squash) lab*.domain.com (ro) /home 192.168.0.0/255.255.255.0(rw) *.domain.com (ro) Figura 6.1: Arquivo /etc/exports

do domínio domain.com cujos nomes iniciem com lab (ex.: laboratorio, lab01, etc.) e para a máquina 100.1.0.2. Nesse caso ainda, a máquina madonna possui poderes de leitura e escrita nesse diretório, ao contrário das outras máquinas. Ainda, no caso do diretório /usr/local, o superusuário da máquina madonna tem os mesmos poderes do superusuário da máquina que está exportando os arquivos. Uma observação importante a ser feita sobre exportação de diretórios é que o NFS não exporta subdiretórios que estejam em outras partições. Assim, por exemplo, se /usr e /usr/local estiverem em partições distintas, eles necessitam ser exportados independentemente, como é o caso da Figura 6.1. Configurado o arquivo /etc/exports, o próximo passo é carregar o servidor NFS. A bem da verdade, o NFS envolve três servidores: o rpc.nfsd, o rpc.mountd e o exportfs. Como o NFS usa RPC (Remote Procedure Calls – chamadas de procedimentos remotos), ele também precisa do portmap. Na maioria das distribuições, o processo de inicialização pode ser feito com a chamada service nfs start ou executando-se o comando /etc/rc.d/init.d/nfs start Caso o arquivo /etc/exports seja alterado durante a execução do servidor, o processo de sincronização do novo arquivo pode ser feito com o comando exportfs -r Veja a página de manual desse comando para mais detalhes. 6.2.2

Configuração do Cliente NFS

Como comentado em (UCHÔA, 2007), o sistema de arquivos adotado no Linux baseiase numa camada virtual (VFS – Virtual FileSystem), construída para suportar múltiplos

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

sistemas de arquivos. Essa estrutura permitiu ao Linux um gerenciamento poderoso desse recurso. Entre os sistemas de arquivos inclui-se o NFS. Assim, supondo-se que uma estação cliente possua os devidos privilégios, ela utilizar uma partição /usr/local no servidor myserv, montando essa partição em um diretório local (por exemplo, /usr/myserv): mount -t nfs myserv:/usr/local /usr/myserv Em várias versões recentes do comando mount, o uso da opção -t nfs é desnecessária. Caso o uso desse ponto de montagem seja freqüente, basta adicionar uma linha no /etc/fstab, utilizando-se o nfs para o tipo de partição: myserv:/usr/local /usr/myserv nfs defaults 0 0 Para maiores detalhes sobre montagem de dispositivos e o arquivo /etc/fstab, consulte (UCHÔA, 2007). Uma observação final sobre NFS é que os arquivos são compartilhados levando-se em conta o UID e o GID do usuário. Assim, é extremamente importante manter o mesmo valor de UID e GID dos usuários no servidor e nas estações. Caso contrário, corre-se o risco de arquivos de um usuário no servidor poderem serem abertos por outro em uma estação.

6.3

O SERVIDOR FTP

A configuração de um servidor é relativamente simples. Entre os servidores mais conhecidos destacam-se o wu-ftpd, o proftpd e o vs-ftpd. Uma observação importante é que servidores FTP só devem ser instalados em provedores ou similares, i.e., para prover serviços anônimos de FTP. Jamais user FTP para uso normal por usuários. O tráfego de dados no FTP é feito de forma não-criptografada, facilitando a captura de senhas por hackers. Utilize serviços baseados em SSH ou SSL (como o sftp) para essa finalidade. Caso se pretenda a configuração de um servidor anônimo de FTP, não basta instalar o servidor: é preciso copiar os aplicativos que o usuário ftp poderá utilizar durante a transferência de arquivos para o diretório /bin dentro da árvore do FTP. Em geral, isso é feito automaticamente com a instalação do pacote anomftp. A instalação desse pacote habilita a configuração de um ftp anônimo com raiz em /var/ftp. Em geral, é possível fazer várias configurações extras nos servidores FTP. Entretanto, essas configurações raramente são utilizadas e dependem do servidor utilizado. Assim, consulte a documentação do servidor FTP instalado para maiores detalhes sobre isso.

Compartilhamento de Arquivos

6.4

INTEGRAÇÃO DO LINUX COM REDES WINDOWS

A integração do Linux com redes Windows é feita via protocolo CIFS (Common Internet File System), também conhecido como SMB (Server Message Block). A implementação do CIFS para UNIX é conhecida como SAMBA. Entre os serviços providenciados pelo CIFS e suportados pelo SAMBA, encontram-se: • compartilhamento de arquivos; • compartilhamento de impressoras; • autenticação e autorização; • resolução de nomes; • anúncio de serviços (browsing). A maioria da funcionalidade do SAMBA é implementada por dois servidores: o smbd e o nmbd. O nmbd é responsável pelo anúncio de serviços e resolução de nomes. Já o smbd implementa compartilhamento de arquivos e impressoras, bem como autenticação e autorização. Além dos servidores, a distribuição do SAMBA também providencia outros aplicativos, entre eles clientes para montagem de partições Windows em máquinas UNIX, por exemplo. 6.4.1

Configurando o Servidor SAMBA

A maioria das distribuições Linux oferecem versões do SAMBA nos CDs de instalação. Uma vez instalado, deve-se editar o arquivo de configuração smb.conf. Em geral, esse arquivo costuma encontrar-se no /etc, mas versões mais recentes utilizam um diretório próprio (/etc/samba) para as configurações do SAMBA. Esse arquivo pode ser dividido em duas partes. A primeira é uma seção de configuração global do servidor, ilustrada na Figura 6.2. A segunda parte são os compartilhamentos, ilustrados na Figura 6.3. Como pode ser verificado nas Figura 6.2 e Figura 6.3, é possível inserir comentários utilizando-se ‘;’ ou ‘#’. Dada as inúmeras opções de configuração, existe um aplicativo, o testparm, que checa se as configurações do servidor estão corretas. Após qualquer alteração no arquivo smb.conf, recomenda-se a execução desse aplicativo para verificar se não há erros de sintaxe. A primeira configuração a ser feita para o servidor SAMBA é a especificação do grupo de trabalho do servidor e sua descrição. De acordo com as linha 3 e 4, na Figura 6.2, o servidor será conhecido como Samba Server no ambiente de rede Windows e fará parte da rede MYGROUP. A linha 5, que está comentada, permite configurar quais as estações que

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

# Configuração global [global] workgroup = MYGROUP server string = Samba Server ; hosts allow = 192.168.1. 192.168.2. 127. ; interfaces = 192.168.12.2/24 192.168.13.2/255.255.255.0 ; remote browse sync = 192.168.3.25 192.168.5.255 ; remote announce = 192.168.1.255 192.168.2.44 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 printcap name = /etc/printcap load printers = yes printing = cups ; guest account = pcguest log file = /var/log/samba/%m.log max log size = 0 security = user ; password server = <NT-Server-Name> encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd unix password sync = Yes passwd program = /usr/bin/passwd %u passwd chat = *New*password* %n\n *Retype*new*password* %n\n *passwd:*all*authentication*tokens*updated*successfully* ; username map = /etc/samba/smbusers ; local master = no ; os level = 33 ; domain master = auto ; preferred master = auto ; domain logons = yes ; logon script = %m.bat ; logon script = %U.bat ; logon drive = z: ; logon path = \%H\Profile ; wins support = yes ; wins server = w.x.y.z ; wins proxy = yes dns proxy = no ; preserve case = no ; short preserve case = no ; default case = lower ; case sensitive = no

Figura 6.2: Exemplo de Arquivo smb.conf – Seção global

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

Compartilhamento de Arquivos

# Compartilhamentos [homes] comment = Home Directories browseable = no writable = yes valid users = %S create mode = 0664 directory mode = 0775

1 2 3 4 5 6 7 8 9

[printers] comment = All Printers path = /var/spool/samba browseable = no guest ok = no writable = no printable = yes

10 11 12 13 14 15 16 17

;[tmp] ; comment = Temporary file space ; path = /tmp ; read only = no ; public = yes

18 19 20 21 22 23

;[public] ; comment = Public Stuff ; path = /home/samba ; public = yes ; writable = yes ; printable = no ; write list = @staff

24 25 26 27 28 29 30 31

;[pchome] ; comment = PC Directories ; path = /usr/local/pc/%m ; public = no ; writable = yes

32 33 34 35 36

Figura 6.3: Exemplo de Arquivo smb.conf – Compartilhamentos

podem ter acesso aos serviços SAMBA. É extremamente importante configurar esse item para garantir um nível extra de segurança. O servidor SAMBA irá ouvir, por padrão, todas as interfaces ativas capazes de broadcast, com excessão da interface de loopback. A linha 6 da Figura 6.2 apresenta um exemplo de configuração de interfaces. Com a opção remote browse sync (linha 7), o servidor

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

nmbd irá, periodicamente, requerer sincronização de listas de serviços com um servidor SAMBA em outro segmento de rede. Com a opção remote announce (linha 8), o servidor nmbd irá periodicamente anunciar a si mesmo para uma máquina em outro segmento de rede. Com a opção socket options (linha 9), é possível controlar as opções de conexão (socket) do servidor ao cliente. A configuração utilizada na Figura 6.2 é a adequada para a grande maioria dos casos. Entretanto, outras opções podem ser verificadas na página de manual do smb.conf (man smb.conf). A habilitação de impressoras é feita nas linhas 10 a 12 na Figura 6.2. A lista de impressoras disponíveis é feita lendo-se o arquivo /etc/printcap. Com a especificação do printcap e a opção load printers ativada, todas as impressoras instaladas localmente serão compartilhadas. Caso não seja isso o desejado, é possível configurar de outra maneira (veja a página de manual do smb.conf para saber como). O tipo de controlador de impressão utilizado é configurado com a opção printing. Entre as opções utilizadas, mais próximas ao Linux encontram-se: bsd, cups e lprng. Como pode ser verificado na linha 13 da Figura 6.2, é possível habilitar um usuário convidado que acessará determinados recursos sem uso de senha. Isso pode ser útil, por exemplo, para impressão compartilhada. Na linha 14, é possível verificar que é possível configurar um arquivo de registro para cada máquina que acessa o serviço SAMBA. O parâmetro %m é automaticamente substituído pelo nome da máquina cliente. Também é possível usar o nome (%u) ou o grupo do usuário (%g). Caso essa opção não seja especificada, o SAMBA irá usar um único arquivo de registro. Recomenda-se, entretanto, ou um arquivo por máquina ou um por usuário. O tamanho máximo do arquivo de registro é especificado com a diretiva max log size, sendo que 0 significa infinito. As linhas de 16 a 23 na Figura 6.2 especificam o processo de autenticação no SAMBA. Dessas, a mais importante é a opção security. Ela especifica o nível de segurança dos compartilhamentos. É possível implementar segurança por compartilhamento, usando o valor share ou validar a senha em outro servidor SMB, utilizando o valor server. Além disso é possível autorizar utilizando um servidor primário de domínio, utilizando a opção domain. Mas o valor mais interessante para essa opção é user, que implementa segurança por usuário. Caso seja utilizado um outro servidor de senhas para autenticação de usuários, deve-se configurar a opção password server, especificando o nome do servidor responsável por essa tarefa. A menos que estejam sendo utilizadas versões antigas do Windows, deve-se habilitar a opção encrypt passwords que faz com que a negociação de senhas seja feita de forma criptografada.

Compartilhamento de Arquivos

A opção smb passwd file especifica onde se encontra o arquivo de senhas criptografadas do SAMBA. Observe que as senhas do SAMBA e do Linux são armazenadas em locais distintos. Dessa maneira, caso pretenda-se manter as senhas Linux e SAMBA ativadas, deve-se ativar a opção unix password sync. Nesse caso, também deve ser especificado o programa de alteração de senhas para o Linux (veja a linha 21). As linhas 22 e 23 são, a bem da verdade, uma única linha no arquivo de configuração (foram quebradas por finalidades de editoração) e especificam a janela de diálogos para troca de senha Linux. Todo usuário SAMBA é, a princípio, um usuário UNIX. Assim, para cada conta SAMBA, deve ser criada uma conta UNIX com o mesmo login. Caso queira-se utilizar um login diferente no SAMBA, é possível fazer um mapeamento de contas UNIX no Windows. Nesse caso, a opção username map irá especificar qual o arquivo utilizado para esse mapeamento. Assim, por exemplo, o conteúdo root = admin administrator administrador nesse arquivo pode ser usado para mapear o usuário UNIX root nos usuários Windows admin, administrator e administrador. Também é possível fazer mapeamentos do tipo pgabriel = Peter Gabriel onde o usuário UNIX pgabriel é mapeado no usuário Windows Peter Gabriel. A criação de usuários no SAMBA é feito com o comando smbpasswd. Esse comando também permite a alteração de senhas SAMBA pelos usuários ou pelo superusuário. Para adicionar um usuário ao SAMBA, basta emitir o comando smbpasswd -a usuario senha Caso a senha não seja informada, esse comando irá solicitar a digitação da senha do usuário, de forma semelhante ao passwd. Note que, nesse caso, já precisa existir a conta usuario no UNIX. Para autenticação de usuários em estações Windows NT ou Windows 2000, é necessário criar uma conta para a máquina, o que pode ser feito a partir das próprias estações. Isso também pode ser feito com o comando smbpasswd, adicionando-se a opção -m: smbpasswd -a -m maquina Nesse caso, uma conta maquina$ (note o ‘$’ no final) deve ser adicionada ao arquivo /etc/ passwd.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

As linhas de 25 a 28 na Figura 6.2 são referentes à configuração do serviço de browsing, provido pelo nmbd. Ativar a opção domain master habilita o nmbd a confrontar listas de anúncio entre subredes. Observe que essa opção não deve ser ativada se houver um servidor Windows NT fazendo esse serviço. Caso haja um servidor Windows PDC na mesma subrede, esse servidor irá tentar se tornar o mestre do domínio (não havendo como impedir isso) e as listas de anúncio podem ficar estranhas se o nmbd também estiver fazendo isso. Nesse caso, ou deixa-se esse serviço para o NT ou move-se o NT para outro grupo de trabalho. Ativando-se a opção local master irá fazer com que o nmbd tente ser o mestre de domínio local da subrede onde se encontra. Note que não basta que essa opção esteja ativa, apenas que o nmbd irá participar da eleição para mestre de domínio local. Desativando-se essa opção fará com que o nmbd não participe dessa eleição. A chance do nmbd ganhar essa eleição é dada pelo valor do os level. Quando o parâmetro preferred master está ativado, nmbd irá forçar uma eleição quando iniciado e ter uma leve vantagem para ganhar a eleição. Recomenda-se esse opção quando a opção domain master também está ativa. O leitor deve ter percebido que, no exemplo da Figura 6.2, as opções domain master e preferred master estão no modo automático. É que essas opções não serão ativadas (mesmo que configuradas de modo diverso) se o servidor SAMBA não for também um servidor de logons. Assim, quando a opção domain logons (linha 29 da figura) estiver ativa, as opções domain master e preferred master serão ativadas se forem configuradas no modo automático. Com a opção domain logons ativada, é possível autenticar usuários em estações Windows 95/98 e mesmo no Windows NT. Em últimas versões, foi possível obter sucesso com estações Windows 2000 no laboratório de computação do DCC/UFLA. Caso esse seja o interesse, o administrador também deve dar atenção às linhas 30 a 33 da Figura 6.2. Elas permitem configurar vários aspectos do login do usuário ao SAMBA. A opção logon script permite configurar um arquivo de lote que será executado na estação tão logo o usuário se logue a uma estação. Esse arquivo pode ser único, ou pode ser configurado um arquivo .bat para cada usuário (linha 31) ou para cada estação (linha 30). Além disso, em estações NT ou 2000, é possível atribuir uma letra de drive para a pasta do usuário, o que é feito na linha 32. Observe para o funcionamento adequado dessa opção é imprescindível que os diretórios pessoais estejam compartilhados, o que será visto mais adiante. O parâmetro logon path especifica qual o diretório onde são armazenados os arquivos de profile do usuário. No profile ficarão armazenados as configurações do usuário,

Compartilhamento de Arquivos

incluíndo-se os itens que ele adiciona ao Menu Iniciar. No exemplo, na linha 33, o logon path é configurado para o diretório Profile na pasta pessoal do usuário. As linhas de 34 a 37 no exemplo da Figura 6.2 especificam como deve ser feito o processo de resolução de nomes de máquinas Windows (se usa WINS ou DNS, etc.). Já as linhas de 38 a 41 configuram como o SAMBA irá tratar maiúsculas e minúsculas para arquivos, dado que Windows não é sensível ao caso, ao contrário do UNIX. Veja a página de manual do smb.conf (man smb.conf) para saber mais detalhes sobre esses itens. Uma vez configurado o servidor SAMBA nos parâmetros globais, deve-se especificar os compartilhamentos que serão feitos. Isso é exemplificado na Figura 6.3. Nessa figura, é possível perceber que cada compartilhamento é feito em uma seção do arquivo smb.conf. Dois compartilhamentos são extremamente importantes e merecem especial atenção: os diretórios pessoais dos usuário, feito na seção homes e as impressoras, feito na seção printers. A Tabela 6.2 apresenta as principais opções utilizadas no compartilhamento de arquivos ou impressoras.

Tabela 6.2: Opções de Compartilhamento no SAMBA Opção

Descrição

comment browseable

Descrição do compartilhamento Especifica se o compartilhamento é visualizado na lista de itens compartilhados. Também é reconhecido como browsable Habilita escrita no dispositivo a quem de direito. Possui writable como sinônimo Lista de usuários permitidos a logar-se no recurso. Usa-se %S para o nome do serviço, o que é feito na seção homes. Também pode ser escrito create mask e especifica a permissão padrão dos arquivos criados Idem ao create mode, porém aplicado a diretórios. Também pode ser escrito directory mask Caminho em disco do serviço compartilhado Também pode ser escrito como public, habilita acesso público (sem senha) ao compartilhamento, muito útil para compartilhamento de impressoras Habilita impressão no compartilhamento Especifica o compartilhamento como apenas de leitura Lista os usuários que tem acesso de escrita e leitura ao compartilhamento Lista os usuários que tem acesso apenas de leitura ao compartilhamento

writeable valid users create mode directory mode path guest ok printable read only write list read list

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Obviamente, existem vários outros itens e observações a serem feitas sobre o servidor SAMBA. Entretanto, espera-se que esta seção contenha os elementos básicos para o administrador instalar e configurar corretamente um servidor SAMBA. Maiores detalhes e outras opções podem ser consultadas na documentação (incluindo páginas de manual e vários outros) do SAMBA.

6.5

ACESSANDO COMPARTILHAMENTOS WINDOWS

O acesso a compartilhamentos Windows pode ser feito de várias formas. Configuração de impressoras é feita de forma relativamente simples com a maioria dos aplicativos de configuração dos servidores de impressão Linux (incluíndo-se CUPS e LPRng). O acesso a diretórios compartilhados pode ser feito através do aplicativo smbclient que permite acessar o recurso com uma interface semelhante ao ftp. Também é possível usar o comando smbmount para montar compartilhamentos em um diretório específico. A forma mais prática, entretanto, é utilizar o comando mount com a opção de sistema de arquivos smbfs, como ilustrado a seguir: mount -t smbfs //maq1/mp3z /mnt/mp3z \ -o username=joao,password=batista Nesse caso, esse comando está montando o compartilhamento mp3z da máquina maq1 no diretório local /mnt/mp3z. Note que, nas opções do comando mount, foram passadas o usuário e a senha para acessar o recurso. É possível também adicionar uma linha no arquivo /etc/fstab para facilitar o processo de montagens, quando isso ocorre com freqüência. Consulte (UCHÔA, 2007) para maiores detalhes sobre montagem de dispositivos.

7 SERVIÇOS DE INFORMAÇÃO EM REDES

7.1

COMENTÁRIOS INICIAIS

Uma questão importante em administração de redes é o compartilhamento de informações. Em geral, compartilham-se três tipos de informações: Informações de Sistemas: referem-se a informações essenciais ao bom funcionamento de um dado ambiente computacional. Nessa categoria, inserem-se informações como nomes de máquinas, dados de contas de usuário, entre outros. Informações de Aplicativos: referem-se a informações compartilhadas por determinadas aplicações. Sistemas comerciais, como cadastros de clientes, produtos ou fornecedores, costumam utilizar-se desse tipo de informação compartilhada. Informações Pessoais: referem-se a informações compartilhadas sobre os usuários de sistema. Nessa categoria, encaixam-se informações disponibilizadas, por exemplo, pelo comando finger. Neste capítulo, a atenção maior será dada aos serviços de compartilhamento de informações sistemas, destacando-se os serviços de DNS, NIS e LDAP, que podem ser classificados como serviços de diretórios. Serviços de Banco de Dados e finger também são abordados, mas em menor detalhe.

7.2

SERVIÇO DE DOMÍNIO DE NOMES (DNS)

Como comentado no Capítulo 2, a cada máquina em um ambiente de rede TCP/IP, é associado um ou mais números de IP. Mas se lembrar o número IP de uma máquina interna a uma dada rede é uma tarefa complicada, o que se pode dizer dos provedores de serviço na internet? Para simplificar o acesso a servidores remotos, houve a necessidade da criação de maneiras de associar nomes a esses números, simplificando o processo de

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

memorização. Afinal, ginux.comp.ufla.br é um endereço mais simples de se guardar que 200.131.251.7. Outra vantagem desse tipo de associação é que isso permite mais facilmente isolar máquinas de serviços. Assim, por exemplo, o administrador pode ter um servidor WWW em www.dominio.com, sem se preocupar se esse servidor está na máquina 222.222. 222.15 ou 222.222.222.21. Dessa maneira, fica mais simples mover um dado serviço de uma máquina para outra. Inicialmente essa associação de IPs a máquinas era feita por um arquivo texto, controlado de forma centralizada e distribuído a todas as máquinas na ARPANET. Os nomes utilizados não eram hierárquicos e o processo de associar um nome a uma máquina implicava em verificar se ninguém no mundo já não havia pego o nome pretendido. A atualização desse arquivo tomava grande parte da largura de banda da ARPANET e o arquivo estava constantemente desatualizado. Esse problema tornava-se cada vez maior com a expansão da ARPANET. Em 1983, Paul Mockapetris especifica formalmente o DNS (Domain Name System) em (MOCKAPETRIS, 1983a) e (MOCKAPETRIS, 1983b). Essa especificação foi posteriormente alterada em (MOCKAPETRIS, 1987a) e (MOCKAPETRIS, 1987b). O DNS especifica uma estrutura hierárquica de nomes para máquinas e endereços IPs em uma forma distribuída. Isso implica, a grosso modo, que cada site armazena informações sobre seus computadores. Quando uma máquina de um dado domínio necessita do endereço de uma máquina em outro site, há uma troca de informações entre os servidores DNS desses domínios. Nomes podem ser relativos ou absolutos. Nomes relativos são aqueles válidos dentro de um dado domínio. Assim, por exemplo ginux é um nome válido dentro do domínio comp.ufla.br. Um nome absoluto, por sua vez, distingue a máquina de forma única na internet. Esse nome absoluto é também chamado de FQDN (Fully Qualified Domain Name – Nome de domínio totalmente qualificado). Assim, ginux.comp.ufla.br. é um nome absoluto. Note a existência de um ponto no final do nome: o endereço ginux.comp. ufla.br continua sendo um endereço relativo. Por sistema hierárquico, entende-se que o DNS possui uma estrutura de domínios dentro de domínios, semelhante a uma árvore. Assim, uma máquina é, de certa forma, uma “folha” na ramificação produzidas pelos domíníos e subdomínios a que pertence. A Figura 7.1 ilustra esse conceito. Nessa figura, tem-se o domínio raiz “.”. Em um segundo nível, tem-se domínios que indicam o país de hospedagem do site ou o tipo de organização do mesmo. No terceiro ou quarto nível tem-se, em geral, o nome da instituição ao qual o computador está associado. O nome do computador fica em uma das folhas da árvore. De acordo com

Serviços de Informação em Redes

a árvore da Figura 7.1, tem-se que ginux.comp.ufla.br., zeus-pub.kernel.org. e www.freshmeat.net. são FQDNs válidos.

barney

.conectiva .comp oberon www www

ftp

.slackware .redhat

.com

.br

ginux

.com .ufla .unicamp

www rpmfind www zeus−pub www

.speakeasy linux kernel debian

.org

.net

.freshmeat

Abaixo do nível raiz “.”, encontram-se os domínios genéricos de alto nível. Os domínios mais utilizados são apresentados na Tabela 7.1. Historicamente, os quatro primeiros domínios (com, org, net e edu) foram utilizados apenas nos Estados Unidos, mas mudanças recentes na política de nomes atribuíram que esses domínios são globais por natureza. O quinto domínio (arpa) é utilizado pelo DNS para buscas reversas. Em uma busca reversa, o usuário sabe o IP de uma máquina e quer saber o nome a ela associado.

Figura 7.1: Árvore DNS

Além dos domínios apresentados na Tabela 7.1, também são utilizados domínios associados aos países. Nesse caso, adota-se o código de duas letras definidos na ISO3166. Uma cópia dessa relação pode ser encontrado em http://www.iso.org/iso/ en/prods-services/iso3166ma/02iso-3166-code-lists/index.html. Uma relação dos domínios de países mais comuns é apresendado na A Tabela 7.2.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Tabela 7.1: Domínios Genéricos de Alto Nível

Domínio

Descrição

com org net edu arpa mil int gov

organizações e companhias comerciais organizações não comerciais gateways e provedores instituições educacionais âncora para árvore de endereços IP intituições militares organizações internacionais agências governamentais

Tabela 7.2: Domínios de Países

Domínio

País

au ca br de fi fr jp se ch hu nl uk us

Austrália Canadá Brasil Germany Finlândia França Japão Suécia Suíça Hungria Holanda Reino Unido Estados Unidos

Algumas observações importantes se fazem necessárias. Em geral, os países adotam como subdomínios aqueles apresentados na Tabela 7.1. No Brasil, isso é parcialmente verdadeiro, uma vez que se adota .com.br, .org.br e .gov.br. Entretanto, as instituições educacionais, como a UFLA, utilizam-se apenas do .br. Na Inglaterra, se adota .co.uk para companhias comerciais e .ac.uk para instituições acadêmicas. Isso ocorre por que cada país é livre para organizar a árvore de DNS abaixo de seu domínio.

Serviços de Informação em Redes

Por razões históricas, o domínio .us ainda não é muito utilizado. Mas dado seu baixo custo (ou mesmo gratuidade) frente a domínios globais, é de se esperar que ele se difunda ainda mais. Alguns domínios de países tem sido utilizados fora desses países. Isso ocorre porque o domínio associado a esses países são extremamente atrativos para determinados grupos. Exemplos de domínios desse tipo são o .to, .tm e .tv. Consulte a ISO-3166 para saber os países associados a esses domínios. 7.2.1

Resolução de Nomes em Linux

Em redes pequenas, ou para máquinas que não precisem ou devam ter nomes válidos na internet, pode não ser interessante utilizar o DNS para fazer uma associação nome/máquina. Entretanto, ainda pode ser útil ter essa associação de alguma forma. Em UNIX, além do DNS, é possível fazer isso através do arquivo /etc/hosts. Um arquivo desse tipo é ilustrado na Figura 7.2. Como se vê nessa figura, a cada IP é associado um ou mais nomes. 127.0.0.1 202.231.25.1 202.231.25.2 192.168.0.1 192.168.0.2 192.168.0.3

localhost localhost.localdomain servidor1.tuix.com.br www mail servidor2.tuix.com.br ftp maq01.tuix.com.br maq01 maq02.tuix.com.br maq02 maq03.tuix.com.br maq03 Figura 7.2: Arquivo /etc/hosts

Quando se configura uma estação Linux em rede, é necessário informar como os nomes de máquinas serão resolvidos. Essa resolução de nomes é feita pela biblioteca resolver, principalmente pelas rotinas gethostbyname() e gethostbyaddr(). As funções de resolução lêem os arquivos de configuração do sistema que informam onde consultas de nomes devem ser efetuadas. Em Linux, três arquivos são utilizados com freqüência: host.conf, nsswitch.conf e resolv.conf, todos no diretório /etc/. A principal utilidade do arquivo /etc/host.conf é informar a seqüência desejada para a consulta de nomes. A Figura 7.3 ilustra um exemplo desse arquivo. Nesse exemplo, tem-se que a consulta de nomes utilizará inicialmente o arquivo local /etc/hosts. Caso a consulta local não seja bem sucedida, então a consulta será repassada ao NIS. Por último, consultas não respondidas pelo NIS serão repassadas ao DNS. Em geral, em estações sem uso de NIS, recomenda-se a configuração order hosts,bind. A título de informação, o nome do servidor DNS mais utilizado é o BIND, donde esse valor para DNS no /etc/host.conf. Observe que NIS será visto mais à frente, neste mesmo capítulo.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

order hosts,nis,bind nospoof on spoofalert on Figura 7.3: Arquivo /etc/host.conf

Uma proteção extra contra spoofing pode ser obtida ativando-se as opções nospoof e spoofalert no arquivo /etc/host.conf. Quando essas opções estão ativas, como ilustrado na Figura 7.3, o resolver pode ser configurado para checar se um dado IP é realmente associado com o nome obtido. A versão 2 da biblioteca padrão GNU (a Glibc) utiliza um mecanismo mais poderoso e flexível para configuração de resolução de nomes. O conceito de serviços de nomes foi extendido para incluir uma variedade maior de informações. Configurações para diferentes bases de informações utilizam um único arquivo de configuração: /etc/nsswitch.conf. Nesse arquivo, são informadas em quais bases devem ser efetuadas as consultas para obtenção de informações de sistema. A Figura 7.4 apresenta um exemplo de um arquivo /etc/nsswitch.conf. passwd: shadow: group:

files ldap nisplus files ldap nisplus files ldap nisplus

hosts:

files nisplus dns

networks: protocols: rpc: services:

files files nisplus files files nisplus

aliases:

files nisplus Figura 7.4: Arquivo /etc/nsswitch.conf

Na Figura 7.4, percebe-se que a configuração de resolução de informações segue, em geral, a forma:

informação:

base1 base2 ...

Serviços de Informação em Redes

As informações compartilhadas com freqüência são listadas na Tabela 7.3. Os tipos de bases utilizadas, por sua vez, são listadas na Tabela 7.4. Para maiores detalhes, consulte a página de manual do nsswitch.conf. Tabela 7.3: Informações Compartilhadas Informação

Descrição

aliases

aliases de e-mail utilizados pelo sendmail – atualmente essa opção é ignorada grupos de usuários dados de usuários senhas de usuários nomes e endereços de máquinas nomes e endereços de redes nomes de protocolos nomes e números de chamadas de procedimentos remotos (rpcs) serviços de redes parâmetros de inicialização do sistema

group passwd shadow hosts networks protocols rpc services bootparams

Tabela 7.4: Bases Utilizadas no /etc/nsswitch.conf database

Descrição

files db nisplus ou nis+ nis ou yp compat hesiod dns

arquivos locais base de dados local NIS+ (NIS versão 3) NIS, também chamado de YP (NIS versão 2) NIS em modo de compatibilidade Hesiod é um serviço de compartilhamento de informações baseado no BIND usa o DNS para serviços de nomes

Quando se configura a biblioteca resolver para utilizar o DNS para resolução de nomes, é necessário informar quais os servidores utilizados. O arquivo utilizado para isso é o /etc/resolv.conf, ilustrado na Figura 7.5. Nesse arquivo, duas diretivas são as essenciais ao bom uso do sistema. A diretiva search informa quais os domínios que podem ser anexados automaticamente a uma busca. Assim, caso seja feita uma busca para a máquina pt01 e não for encontrada resposta, automaticamente essa busca será estendida para pt01.contabil.tuix.com.br e pt01.tuix.com.br. Ainda no caso do exemplo, a consulta DNS será feita nos servidores 202.231.25.1 e 202.231.26.1, nessa ordem.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

search contabil.tuix.com.br tuix.com.br nameserver 202.231.25.1 nameserver 202.231.26.1 Figura 7.5: Arquivo /etc/resolv.conf

7.2.2

O Servidor DNS

O servidor DNS mais utilizado, se não o único, em ambiente UNIX é o BIND (Berkeley INternet Domain service). BIND foi criado em 1985 por Kevin Dunlap e é mantido atualmente pelo ISC (Internet Software Consortium)1 . A importância do BIND é tão grande que, historicamente, DNS tem sido definido como “aquilo que o BIND implementa”. A especificação base do DNS, implementada no BIND, pode ser encontrada nas RFC 1034 (MOCKAPETRIS, 1987a) e RFC 1035 (MOCKAPETRIS, 1987b). Entretanto, várias outras RFCs mais recentes adicionaram novas funcionalidades ao serviço, o que pode ser verificado com facilidade em http://www.rfc-editor.org/. O servidor de nomes do BIND é o named. Um servidor named pode operar de diversas formas em uma dada zona. Uma zona é um domínio sem seus subdomínios. Assim, dentro do domínio .ufla.br, existem as zonas .ufla.br e .comp.ufla.br. Note que freqüentemente se utiliza o termo “domínio”, onde deveria ser usado o termo “zona”. Um mesmo servidor named pode exercer diferentes papéis em diferentes zonas. A Tabela 7.5 apresenta uma taxionomia de servidores de nomes com relação a uma dada zona. Optou-se, nessa tabela, por manter os termos em língua inglesa, para simplificar o processo de compreensão da configuração de um servidor named. A distinção entre servidores master, slave e caching se dá por duas características: de onde os dados vêm e se o servidor é quem tem autoridade (é authoritative) sobre o domínio. Cada zona tem um servidor mestre, que mantém os dados em arquivo. A alteração de dados de uma zona, portanto, é feita nos arquivos do servidor mestre dessa zona. Um servidor escravo, por sua vez, obtém seus dados de um servidor mestre, através de um processo denominado “transferência de zonas” (zone transfers). Uma zona pode ter inúmeros servidores escravos e deveria ter ao menos um. Um servidor stub é um tipo especial de servidor slave que apenas copia dados de nomes de servidores. Já um servidor caching apenas lê o endereço de servidores para o domínio raiz e faz cache das respostas das consultas a que é submetido. Esse tipo de servidor não possui dados e, portanto, não tem autoridade sobre nenhuma zona. Observe que servidores mestres e escravos têm au1 ISC:

http://www.isc.org/

Serviços de Informação em Redes

Tabela 7.5: Taxionomia de Servidores de Nomes

Tipo de Servidor

Descrição

authoritative master

representante oficial de uma zona repositório primário dos dados de uma zona, obtendo os dados de um arquivo copia seus dados de um servidor mestre similar ao slave, mas copia apenas o nome do servidor (não copiando dados de máquinas) um servidor que é visível apenas dentro de um domínio responde uma consulta do cache sem saber se o dado ainda é válido armazena dados de consultas anteriores; geralmente não possui zonas locais faz consultas em nome de vários clientes, construíndo um grande cache faz consulta em seu próprio nome até que possa retornar uma resposta ou um erro recorre a outro servidor se não pode responder uma consulta

slave stub distribution noauthoritative caching forwarder recursive nonrecursive

toridade sobre suas próprias zonas, mas não para informações que armazenam de outros servidores. 7.2.3

Configurando o named

A configuração completa do named consiste principalmente do arquivo de configuração /etc/named.conf e, para servidores mestres, os arquivos com dados de zonas (geralmente no diretório /var/named). O arquivo named.conf consiste de uma série de declarações, cada uma terminada por um ponto-e-vírgula. Informações nesse arquivo são agrupadas, dentro de um contexto específico, pelo uso de chaves. A Figura 7.6 apresenta um exemplo de um arquivo de configuração de um servidor named. Como pode ser verificado na Figura 7.6, o arquivo /etc/named.conf configura o servidor de nomes através do uso de seções. Cada seção especifica uma funcionalidade do servidor. As opções usadas são descritas na Tabela 7.6. Comentários podem ser feitos como em C++, usando-se “//” ou “/* */”, ou como em scripts, usando-se “#”. Algumas das opções listadas na Tabela 7.6 são de extrema importância para a correta configuração do named. Elas serão descritas em mais detalhes a partir de agora, tomando-

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

options { directory "/var/named"; forwarders{ 200.131.250.1; 200.19.159.1; }; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "." IN { type hint; file "named.ca"; }; zone "comp.ufla.br"{ type master; #mestre do domínio file "comp.ufla.br"; //arquivo do domínio notify yes; /* notificar alterações */ }; zone "251.131.200.IN-ADDR.ARPA"{ type master; file "200.131.251."; notify yes; }; include "/etc/rndc.key"; Figura 7.6: Exemplo de /etc/named.conf

se, como exemplo, a configuração apresentada na Figura 7.6. A opção zone permite a configuração de zonas e será vista detalhadamente na Seção 7.2.4. A opção include tem, em geral, duas funcionalidades. A primeira é permitir que o arquivo de configuração seja dividido em vários outros arquivos, especialmente útil em servidores cujo arquivo de configuração seja relativamente grande. A segunda e melhor funcionalidade é permitir a inclusão de arquivos com permissão de leitura apenas ao named. Como exemplo desse tipo de arquivo, tem-se o arquivo contendo a chave do servidor para uso em autenticação. Opções gerais do servidor são configuradas na seção options. Atualmente, mais de 50 opções estão disponíveis. As mais importantes são listadas na Tabela 7.7. À opção directory geralmente é atribuído o valor /var/named, como exemplifica a Figura 7.6.

Serviços de Informação em Redes

Tabela 7.6: Seções Usadas no /etc/named.conf

Seção

Funcionalidade

include options server key acl zone trusted-keys controls logging view

inclui um arquivo opções padrões do servidor especifica as configurações de um servidor remoto define informações de autenticação especifica lista de controle de acesso configura uma zona chaves pré-configuradas define canal usado para controlar o servidor especifica categorias de logs e seus destinos define uma visão do espaço de nomes

Tabela 7.7: Opções da Seção options no /etc/named.conf

Opção

Funcionalidade

version

permite alterar a string que informa a versão do BIND – não se deve confiar nesse recurso como proteção contra ataques especifica o caminho absoluto utilizado pelo named especifica uma lista de servidores para consultas externas especifica se o servidor mestre deve notificar alterações a servidores escravos especifica uma lista extra de servidores (não necessariamente escravos) para notificação habilita recursão (o servidor irá fazer consultas em nome dos clientes a outros servidores) especifica o número máximo de arquivos que podem ser abertos pelo named espefica a porta e a interface onde named irá escutar as consultas lista os IPs das máquinas que podem consultar o servidor lista os IPs das máquinas que podem efetuar transferências de zonas lista servidores aos quais não irá repassar consultas

directory forwarders notify also-notify recursion files listen-on allow-query allow-transfer blackhole

A opção forwarders, também exemplificada na Figura 7.6, é útil em servidores de zonas que são subdomínios de outros servidores locais. Toda consulta a qual o servidor local não tenha autoridade é repassada a um forwarder. Como o servidor de nomes é um ótimo “devorador” de memória, essa é uma maneira de manter os servidores dos subdomínios

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

mais leves. Observe que para um forwarder valer a pena, é essencial que ele possa ser acessado rapidamente pelo servidor local. Quando se utiliza servidores de nomes escravos, a opção notify serve para informar ao servidor mestre para notificar servidores escravos sempre que houver alteração nos dados das zonas pelas quais é responsável. A configuração padrão é ter a notificação ativa, o que é desejável na maioria dos casos. Caso se queira notificar também servidores não-escravos, então é possível fazer isso com a opção also-notify, da seguinte forma: also-notify {ip1; ip2; ...; ipn;}; onde ip1 é o endereço IP do primeiro servidor a ser notificado e assim por diante. As opções allow-query e allow-transfer são utilizadas para impor um adicional de segurança ao servidor DNS. Com allow-query, é possível especificar quais máquinas podem utilizar o servidor para consultas de nomes. Já allow-transfer informa quais os servidores escravos que podem fazer transferência de zonas. Se não especificados, então a permissão é dada a todos os computadores na internet. A especificação pode ser feita da seguinte forma: allow-query {ip1; ip2; ...; ipn;}; onde ip1 pode tanto ser o endereço IP de uma máquina que pode usar o servidor DNS para consultas, como o endereço IP de toda uma rede, como exemplificado a seguir: allow-query {128.111/16; 204.111.111/24; 200.111.200.101;}; Nesse caso, todas as máquinas na rede 128.111 e na rede 204.111.111 podem utilizar o servidor para consultas de nomes. Além disso, essa permissão também é dada à máquina 200.111.200.101. Como já comentado anteriormente, a seção options permite a configuração de inúmeros itens do servidor named. Recomenda-se uma olhada na página de manual do named.conf para maiores detalhes. A seção acl permite especificar um conjunto de endereços para utilização em opções do tipo allow-query ou allow-transfer. Para criar uma acl, basta: acl nome_da_acl { ip1; ip2; ...; ipn }; Uma observação importante é que o named lê o arquivo de configuração em uma única passada. Assim, a declaração de um acl deve vir antes de seu uso. Além disso, algumas

Serviços de Informação em Redes

acls já se encontram previamente configuradas: any (para todos as máquinas na internet), localhost (para o servidor apenas), none (para nenhuma máquina) e localnets (para as redes locais às quais o servidor pertence). 7.2.4

Configurando Zonas de Domínios

As seções zone são a parte mais importante de um arquivo /etc/named.conf. Nessas seções, são configuradas as zonas que o servidor de nomes tem acesso. A Figura 7.7 apresenta o formato padrão utilizado para a configuração de zonas.

zone "nome_da_zona"{ type master|slave|stub|hint|forward; file "path"; notify yes|no; //default = yes allow-query { lista_de_endereços }; //default = any allow-transfer { lista_de_endereços }; //default = any allow-update { lista_de_endereços }; //default = none fowarders { lista_de_endereços }; //default = none }; Figura 7.7: A Seção zone do Arquivo /etc/named.conf

Como pode ser percebido na Figura 7.7, algumas das opções globais podem ser utilizadas em zonas, como notify, forwarders, allow-query e allow-transfer. A configuração dessas opções já foi abordada na seção anterior. A opção path permite que se configure o caminho onde os dados dessa zona estão arquivados. Em geral, path é um caminho relativo no diretório especificado na opção global directory. No caso da Figura 7.6, o arquivo de configuração da zona comp.ufla.br é o arquivo /var/named/ comp.ufla.br. A opção type especifica o papel do servidor de nomes com relação à zona, de acordo com o já discutido na Seção 7.2.2. O leitor não deve encontrar dificuldades para a configuração de servidores tipo master, slave e stub. Uma observação é que, para a configuração de DNS reverso, utiliza-se uma zona cuja raiz é “.IN-ADDR.ARPA”, como mostra a Figura 7.6. Por DNS reverso, compreende-se a tarefa de descobrir qual o nome associado a um dado IP. Observe que nesse caso, o IP da rede é escrito de forma que a parte mais significativa está mais próxima da raiz. Assim, por exemplo, a rede 233.222.111 teria associada a ela a zona 111.222.233.in-addr.arpa.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

O tipo forward serve para sobrepor configurações globais do arquivo named.conf, na seção options. Ele deve ser usado quando, para uma dada zona, pretende-se que os forwarders sejam outros servidores que não os padrões. Para acessar zonas sobre as quais o servidor não tem conhecimento, o servidor named precisa conhecer os servidores padrões para o domínio raiz (o domínio “.”). Isso é feito através da opção zone "." { type hint; file "hints-path"; };

no arquivo de configuração /etc/named.conf. Com isso, o arquivo hints-path irá listar os servidores raiz da árvore DNS. 7.2.5

Base de Dados DNS

No caso do servidor ser mestre ou escravo de uma dada zona, serão utilizados arquivos locais para configuração (ou cache, no caso de um servidor escravo) das zonas sobre as quais o servidor tem autoridade. Como já comentado, esses arquivos costumam ser armazenados no diretório /var/named. Esses arquivos consistem a base de dados dessas zonas. A Figura 7.8 e a Figura 7.9 apresentam exemplos de arquivos de configuração de DNS direto e reverso, respectivamente. O arquivo da base de dados contém dois tipos de entradas: comandos de parser e registros de recursos. Os comandos de parser são diretivas globais para o named no que se refere à zona do arquivo em questão. Essas diretivas iniciam-se com o caracter “$”. Existem quatro diretivas: ORIGIN, TTL, INCLUDE e GENERATE. Dessas, as mais importantes são as duas primeiras. Quando da configuração de uma máquina na base DNS, o named adiciona aos nomes que não estejam totalmente qualificados a zona especificada no arquivo de configuração. A diretiva ORIGIN permite sobrepor essa informação. Assim, independente do que esteja configurado no arquivo de configuração, as máquinas da Figura 7.8 terão adicionados a zona comp.ufla.br. em seus nomes. A diretiva TTL, por sua vez, configura o tempo de vida padrão dos registros da base em questão. Esse tempo de vida, em segundos, especifica o tempo que o dado em questão pode ser armazenado no cache e ainda ser considerado válido. Um valor baixo de TTL (Time To Live) implica que outros máquinas irão questionar o servidor named com mais

Serviços de Informação em Redes

$TTL 86400 $ORIGIN comp.ufla.br. @ IN SOA

@ @ ansi_c assembler assembly assembly awk bash ftp ginux www.ginux ftp.ginux www

IN IN IN IN IN IN IN IN IN IN IN IN IN

assembly.comp.ufla.br root.comp.ufla.br ( 2003022801 ; serial (d.adams) 3H ; refresh 15M ; retry 1W ; expire 1D ) ; minimum NS assembly MX 5 assembly A 200.131.251.2 A 200.131.251.3 A 200.131.251.1 MX 5 assembly A 200.131.251.9 A 200.131.251.7 CNAME awk.comp.ufla.br. CNAME bash.comp.ufla.br. CNAME bash.comp.ufla.br. CNAME bash.comp.ufla.br. CNAME assembly.comp.ufla.br.

Figura 7.8: Base de Dados de DNS Direto

freqüência a respeito das zonas a que domina. Um valor alto, por sua vez, implica que outros servidores possam demorar a atualizar as informações (em cache) sobre essas zonas. Recomenda-se que a configuração desse valor seja próxima do prazo com que as informações são alteradas na base. Configurada as diretivas, se for o caso, deve-se passar à configuração dos registros DNS propriamente ditos. A configuração de um registro no DNS segue a seguinte sintaxe: [nome] [ttl] [classe] tipo dado Nesse caso, tem-se os seguintes significados desses campos: nome: esse campo identifica o nome da entidade em questão (geralmente máquina ou domínio). O nome pode ser relativo ou absoluto (FQDN). ttl: tempo de vida, em segundos, do registro. classe: tipo de rede em questão. Existem três tipos de classes reconhecidas pelo named: IN para internet, CH para ChaosNet e HS para Hesiod. Para DNS, a rede usada é IN.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

$TTL @

@ 1 2 3 7 9

86400 IN

IN IN IN IN IN IN

SOA assembly.comp.ufla.br. root.comp.ufla.br. ( 2003012201 ; serial 3H ; refresh 15M ; retry 1W ; expire 1D ; default_ttl ) NS assembly.comp.ufla.br. PTR assembly.comp.ufla.br. PTR ansi_c.comp.ufla.br. PTR assembler.comp.ufla.br. PTR bash.comp.ufla.br. ;ginux PTR awk.comp.ufla.br. ;servidor ftp Figura 7.9: Base de Dados de DNS Reverso

A rede CH, hoje obsoleta, é utilizada no DNS apenas para informar a versão do Bind sendo utilizada. Hesiod, por sua vez, é um serviço de informação equivalente ao NIS que é construído utilizando o Bind. tipo: identifica o tipo do registro. dado: o conteúdo esse campo depende do tipo do registro. Quanto ao tipo, os registros DNS podem ser agrupados em quatro grande grupos: Registros de Zona: identificam domínios e servidores de nomes. Registros Básicos: mapeia nomes para endereços e roteia e-mail. Registros de Segurança: adiciona autenticação e assinaturas para arquivos de bases DNS. Registros Opcionais: providencia informação extra sobre máquinas e domínios. A Tabela 7.8 apresenta os tipos de registros mais comuns. Para uma relação mais completa, consulte (NEMETH et al., 2001). O registro SOA marca o início de uma zona, definindo a autoridade sobre ela. Utilizandose a Figura 7.8 como exemplo, tem-se @ IN SOA assembly.comp.ufla.br root.comp.ufla.br ( ...

)

Nesse caso, @ indica o nome do domínio corrente (especificado no campo zone do arquivo named.conf ou na diretiva ORIGIN). Tem-se que a classe desse registro é internet (IN).

Serviços de Informação em Redes

Tabela 7.8: Tipos de Registros DNS

Tipo SOA NS A A6 PTR MX KEY SIG CNAME SRV TXT

Nome

Função

Registros de Zona Start of Autority Define uma zona de autoridade DNS Name Server Indica um servidor de nomes e delega autoridade Registros Básicos IPv4 Address Atribui um IP a um nome (DNS Direto) IPv6 Address Atribui um IPv6 a um nome Pointer Atribui um nome a um IP (DNS Reverso) Mail Exchanger Controla rota de e-mail Registros de Segurança Public Key Chave pública para um nome DNS Signature Assinatura para zona autenticada Registros Opcionais Canonical Name Apelido (nome alternativo) de uma máquina Services Indica localização de serviços mais conhecidos Text Comentário ou informação extra

Logo após o tipo (SOA), vem o nome do servidor mestre dessa zona e o e-mail do responsável por ela. Observe que no e-mail, ao invés do @, utiliza-se ponto, dado o significado do @ no servidor DNS. Para dividir os dados em várias linhas, utiliza-se os parênteses. Geralmente os parênteses são usados em registros SOA ou SRV. Dentro dos parênteses, a primeira informação é o número serial da base DNS. Pode ser qualquer valor inteiro incremental, mas geralmente adota-se um formato que indique a data da alteração da base. Assim, 2003022803 significa a terceira alteração do dia 28 de fevereiro de 2003. Recomenda-se o uso dessa estratégia. Observe que se a base for alterada e não for alterado o serial, os servidores escravos não serão informados da alteração e manterão a base antiga. O parâmetro refresh indica de quanto em quanto tempo os servidores escravos devem checar o servidor mestre em busca de alterações. O parâmetro retry indica quanto tempo após uma tentativa o servidor escravo deve tentar uma reconexão ao servidor mestre. Na ausência do servidor mestre, o servidor escravo irá assumir o domínio por um prazo máximo estabelecido no parâmetro expire. O parâmetro minimum, por sua vez informa a outros servidores qual o TTL para respostas negativas do DNS. Recomenda-se valores superiores a quatro horas para evitar sobrecarga na rede.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

A indicação de servidores de nomes e as zonas sobre as quais são responsáveis é feita com o registro NS, geralmente na forma: domínio IN NS servidor Como o domínio local é conhecido, a informação da zona local logo após o registro SOA pode ser armazenado da seguinte forma: IN NS servidor Note, na Figura 7.8 que é possível usar @ ao significando o domínio. O nome de uma máquina é atribuído pelo registro A. Ele possui a seguinte sintaxe: nome IN A endereço Veja exemplos de uso na Figura 7.8. Também no DNS direto é possível atribui apelidos a uma máquina. Isso é feito com o registro CNAME que possui a sintaxe: apelido IN CNAME nome-oficial como também ilustra a Figura 7.8. Também essa figura ilustra o uso de registros MX, usado para indicar quais são os servidores de e-mail de um dado domínio. Ele possui a sintaxe: nome IN MX preferência máquina O parâmetro preferência indica a preferência de um servidor sobre outro para um dado domínio. O uso de registro MX facilita o roteamento de e-mail entre domínios. Para DNS reverso, utiliza-se registros do tipo PTR, ilustrado na Figura 7.9 que possui sintaxe muito próxima a um registro do tipo A, invertendo-se a ordem do endereço com o nome apenas e substituíndo-se o tipo do registro. 7.2.6

Consultando o DNS

Consultas à bases DNS podem ser feitas com os comandos nslookup, host e dig. O comando nslookup não é mais mantido e seu uso deve ser evitado. O comando dig é extremamente flexível e informa o contexto do nome consultado, como mostra a Figura 7.10.

Serviços de Informação em Redes

# dig ginux.comp.ufla.br ; <<>> DiG 9.2.1 <<>> @200.131.250.1 ginux.comp.ufla.br ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45570 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;ginux.comp.ufla.br.

;; ANSWER SECTION: ginux.comp.ufla.br. bash.comp.ufla.br.

86346 86346

IN IN

CNAME A

bash.comp.ufla.br. 200.131.251.5

;; AUTHORITY SECTION: comp.ufla.br.

86400

assembly.comp.ufla.br.

;; ADDITIONAL SECTION: assembly.comp.ufla.br.

86400

200.131.251.1

;; ;; ;; ;;

Query time: 1 msec SERVER: 200.131.250.1#53(200.131.250.1) WHEN: Mon Mar 3 18:09:47 2003 MSG SIZE rcvd: 122 Figura 7.10: Uso do Comando dig

7.3

COMPARTILHAMENTO DE INFORMAÇÕES

Em um ambiente de rede, é comum haver várias máquinas com perfis semelhantes de configuração. Nesse caso, pode ser interessante fazer com que esses perfis sejam compartilhados de alguma forma. Isso é verdadeiro principalmente com relação às informações armazenadas nos arquivos passwd, shadow, group, hosts, services e aliases no diretório /etc. Para o compartilhamento desse tipo de informação, duas abordagens são possíveis:

1. Manter uma cópia matriz da configuração em algum servidor e distribuí-la às máquinas que precisam estar de acordo com esse perfil.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

2. Fazer com que as máquinas obtenham sua configuração de um servidor central. A primeira alternativa é extremamente simples e facilmente implementável em qualquer ambiente UNIX. Para isso, basta fazer uso de estratégias baseadas em NFS ou nos aplicativos rdist, rsync ou expect. Também não é complicado a um programador intermediário em C/C++ construir um mini-servidor para envio dos arquivos de configuração de um servidor à determinadas estações. As desvantagens dessa alternativa é garantir a sincronização de configuração das estações com aquelas armazenadas no servidor. Dessa maneira, pode ser interessante utilizar algum sistema de compartilhamento de informações em rede, como NIS ou LDAP. Uma das desvantagens dessa abordagem é que as estações ficam dependentes do servidor para funcionar adequadamente. Mas com certeza a maior desvantagem dessa estratégia é o fato de que no momento os sistemas de compartilhamento de informação possuem sérias deficiências, como será visto mais à frente. O primeiro sistema de compartilhamento de informações é o NIS (Network Information System), criado na década de 80 pela Sun. Originalmente, chamava-se Sun Yellow Pages. Por questões legais, a Sun viu-se obrigada a renomear a produto. Entretanto, ainda existem profissionais que usam esse termo para o NIS. Por causa desse motivo, a maioria dos aplicativos NIS começam com o prefixo yp. NIS é um sistema relativamente simples de configurar, como pode ser verificado em (KIRCH; DAWSON, 2002), (NEMETH et al., 2001) e (KUKUK, 2002). Entretanto, como já observado em (NEMETH et al., 2001), o NIS não é seguro. Qualquer máquina na rede pode se tornar o servidor de um dado domínio, enviando dados não-confiáveis a clientes NIS. Além disso, qualquer pessoa pode ter acesso à informações compartilhadas pelo NIS. Ou seja: as vantagens de uso de senhas sombreadas (shadow) caem por terra em um ambiente NIS. Em resumo: se o administrador está preocupado com segurança ele não deve usar NIS. Isso é principalmente válido em um ambiente de compartilhamento de dados de usuários, onde seria mais útil. Por esses motivos, este texto não irá abordar o uso e configuração de NIS. Uma alternativa mais promissora ao NIS é o LDAP (Lightweight Directory Access Protocol). LDAP é uma implementação do serviço de diretório X.500. Um serviço de diretório possui semelhanças com serviços de bancos de dados, mas otimizado para busca de informações relativamente pequenas e simples. Assim, um serviço de diretório possui as seguintes características: • dados armazenados são relativamente pequenos; • informações são baseadas em atributos;

Serviços de Informação em Redes

• dados são lidos com freqüência, mas escritos raramente; • operações de busca são freqüentes; • base é geralmente replicada e cacheada.

LDAP aparece, portanto, extremamente promissor para a tarefa de compartilhamento de informações em rede. Em (DOMINGUES; SCHNEIDER; UCHÔA, 2001), podem ser vistas instruções de uso do LDAP para autenticação de usuários, usando SSL no tráfego de dados. Esse artigo é baseado em experiências no laboratório de computação do DCC/UFLA. Entretanto, em implementações mais recentes, usando-se a mesma estratégia não foi possível utilizar SSL com LDAP para autenticação. Em partes isso ocorre porque LDAP ainda é um serviço em grande processo de construção, tanto que (NEMETH et al., 2001) compara o estágio atual do LDAP ao do Java no início da década de 90. Assim, ao menos que o administrador realmente precise desse tipo de serviço, recomenda-se um pouco mais de espera até que o uso de LDAP esteja mais fácil. O administrador, entretanto, deve estar atento, pois essa tecnologia promete bastante funcionalidade para o compartilhamento de informações em rede. Uma outra tecnologia também utilizada na autenticação de usuários é o Hesiod. Hesiod é implementado pelo MIT no topo do DNS. Como a princípio os dados no BIND são disponíveis publicamente, ele sofre dos mesmos problemas do NIS: mesmo que se consiga configurar uma zona segura, a segurança de uso de senhas sombreadas é perdida. Observe que Hesiod não foi pensado originalmente para autenticação distribuída e sim para compartilhar outros tipos de informação. Informações básicas sobre usuários em uma rede pode ser fornecido com o servidor fingerd. Esse serviço permite compartilhar em rede informações básicas sobre um dado usuário. Em geral, esse serviço deve ser configurado para impedir seu uso por usuários externos à rede interna. Caso contrário, essas informações poderão ser usadas para obtenção de logins de usuários para uso em tentativas de invasão ou envio de SPAM. A configuração segura desse servidor é feita com o uso de tcp-wrappers, o que será visto em (UCHÔA, 2005).

7.4

DHCP E OPENSLP

O protocolo DHCP (Dynamic Host Configuration Protocol) permite que clientes dentro de uma mesma rede física possam efetuar suas configurações de rede de forma automática. Dessa maneira, com o uso do serviço DHCP, estações podem buscar em um servidor várias informações como, por exemplo:

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

• endereços e máscaras de rede (IP); • endereço de roteadores (gateways); • endereços de servidores de nomes; • endereços de servidores de fontes; • endereços de servidores WINS (Windows Name Server); • endereços de servidores proxy.

Outras informações podem ser fornecidas via DHCP, mas essas o mais comum é utilizar um servidor DHCP para compartilhar as três primeiras. Para Linux, existem dois clientes: o dhcpcd, ou o pump. O servidor disponível é o dhcpd da ISC. A configuração do cliente é trivial, podendo ser efetuada através de várias ferramentas de configuração, como netconfig ou linuxconf. De qualquer forma, basta-se editar o arquivo /etc/sysconfig/network-scripts/ifcfg-eth0, ou o relacionado à interface que será usada, modificar o parâmetro BOOTPROTO para o valor dhcp e remover as entradas IPADDR, NETMASK, NETWORK e BROADCAST desse arquivo. Além disso, deve-se remover as entradas HOSTNAME e GATEWAY do arquivo /etc/sysconfig/network. Antes de instalar um servidor DHCP, o administrador deve pesar os prós e contras dessa tecnologia. Com o uso normal do DHCP, qualquer usuário pode plugar uma máquina na rede e fazer uso dela. Assim, na forma de uso mais comum do DHCP, o administrador pode mais facilmente perder o controle sobre os endereços da rede. Por outro lado, ele não se vê obrigado a configurar máquinas de usuários iniciantes. DHCP também é extremamente útil quando há mais máquinas que IP em uma dada rede, mas nem todas as máquinas estão ligadas ao mesmo tempo. Dessa maneira, DHCP é utilizada com freqüência em provedores. Para configurar o servidor DHCP, utiliza-se o arquivo /etc/dhcpd.conf. Um exemplo desse arquivo é ilustrado na Figura 7.11. A configuração ilustrada nesse arquivo faz com que o tempo padrão de concessão seja de 600 segundos, com máximo de 7200 segundos. A máscara de rede é 255.255.255.0, o roteador possui endereço 192.168.1.254 e os servidores de nomes são as máquinas com IP 192.168.1.1 e 192.168.1.2. Além disso, o domínio utilizado pela máquina será o mydomain.org. O servidor WINS utilizado nessa rede possui endereço 192.168.1.1. Note ainda na Figura 7.11 que o servidor configura uma rede 192.168.1 na faixa entre 192.168.1.10 e 192.168.1.100 e entre 192.168.1.150 e 192.168.1.200. Além disso, como mostra essa mesma figura, é possível usar o DHCP para atribuir automaticamente um endereço específico a uma dada máquina. No caso, a máquina com placa de rede possuidora do endereço MAC 08:00:2b:4c:59:23 receberá o nome dbowie e o endereço 192.168.1.111.

Serviços de Informação em Redes

# Exemplo de arquivo /etc/dhcpd.conf default-lease-time 600; max-lease-time 7200; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.254; option domain-name-servers 192.168.1.1, 192.168.1.2; option domain-name "mydomain.org"; option netbios-name-servers 192.168.1.1; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.100; range 192.168.1.150 192.168.1.200; } host dbowie { hardware ethernet 08:00:2b:4c:59:23; fixed-address 192.168.1.111; } Figura 7.11: Exemplo de Arquivo /etc/dhcpd.conf

Com o uso da diretiva host, inclusive, é possível incrementar a segurança na rede, pois apenas máquinas com placas de redes já conhecidas poderão utilizar os recursos de rede. Entretanto isso implicará em trabalho adicional para o administrador que precisará identificar o endereço MAC de qualquer placa de rede que precise de acesso à rede. Note que o endereço MAC de uma dada máquina host1 pode ser verificado através do comando arp -a host1.

7.5

SERVIDORES DE BANCOS DE DADOS

Existem vários servidores de bancos de dados (SGBDs) para Linux. Entre os comerciais, o destaque recai para o Oracle. Entretanto existem alternativas gratuitas de grande qualidade, como o PostgreSQL ou o Firebird (implementação gratuita do Interbase). Entre os gratuitos, o PostgreSQL possui a mais poderosa implementação, suportanto inclusive construções básicas orientadas a objetos. Além disso, possui suporte a triggers e transações. O Firebird vem crescendo aos poucos sua participação no mercado de software livre.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

Um outro SGBD muito usado é o mySQL, relativamente mais rápido para consultas mais simples, mas sem suporte a transações. Para uso em bases mais simples (como de consultas na internet), o mySQL pode ser a melhor escolha. Caso pretenda-se algo mais elaborado ou poderoso, a escolha deve recair preferencialmente sobre o PostgreSQL. O Firebird é uma alternativa atraente aos que já trabalham com o Interbase e também é uma boa escolha. A configuração de um SGBD depende de qual será o servidor adotado. Assim, cada um desses servidores possui configurações e ferramentas próprias. Em geral, essas ferramentas permitem: criar e remover bases de dados, criar e remover usuários para acessar as bases, fazer cópia de segurança e restauração de dados. Em geral, os servidores (principalmente os aqui citados) possuem farta documentação sobre o processo de configuração, que costuma ser relativamente simples. Por esses motivos, este texto não abordará a configuração de SGBDs em Linux.

8 SERVIDORES DE ACESSO REMOTO

8.1

COMENTÁRIOS INICIAIS

Uma das maiores vantagens do UNIX sobre outros sistemas operacionais é a possibilidade de execução de comandos de forma remota. Somente recentemente o Windows 2000 incorporou um recurso semelhante (o Windows Terminal Server), mas sem a mesma funcionalidade dos serviços de Telnet ou SSH. Através do Telnet ou do SSH, é possível abrir uma sessão local em máquinas remotas, facilitando o processo de administração, pois permite o gerenciamento remoto. Como o serviço de Telnet é inseguro, esta apostila não irá entrar em detalhes sobre ele. O serviço de SSH, entretanto é abordado na Seção 8.2. Observe que o SSH oferece os mesmos serviços do Telnet, porém de forma criptografada. Além do SSH, esse capítulo também aborda os conceitos básicos necessários para configuração de provedores, na Seção 8.5.

8.2

CONFIGURAÇÃO BÁSICA DO SSH

Existem várias implementações de SSH para Linux, mas a mais conhecida e utilizada é o OpenSSH, uma implementação baseada nos serviços de SSH do FreeBSD. Essa implementação utiliza a OpenSSL para fazer o tunelamento criptográfico de dados. Uma outra versão muito usada é disponibilizada em http://www.ssh.com/, gratuita para fins não comerciais. Os autores deste texto recomendam o uso do OpenSSH. Uma vez instalado o OpenSSH, sua configuração é relativamente simples. Os arquivos de configuração ficam no diretório /etc/ssh. Além dos arquivos de configuração, esse diretório também contém as chaves públicas e privadas do servidor SSH. Observe que, para não obter mensagens de man-in-the-middle attack, como ilustra a Figura 8.1 é importante manter as chaves entre reinstalações do servidor. Esse ataque consiste quando

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

uma máquina entre o servidor e a estação tenta se passar pelo servidor, fazendo que o tráfego criptográfico seja entre a estação e o falso servidor. A garantia do servidor verdadeiro reside nas chaves utilizadas, donde a importância de seu controle. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 37:d3:20:ba:e0:09:56:22:38:a7:9d:32:f7:42:fe:cd. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:1 RSA host key for prolog has changed and you have requested strict checking. Host key verification failed.

Figura 8.1: Man-In-The-Middle Attack

8.3

CONFIGURAÇÃO DO CLIENTE SSH

O cliente SSH constitui-se do aplicativo ssh que pode ser configurado da seguinte forma: 1. inicialmente, são configuradas as opções passadas em linha de comando; 2. é lido o arquivo de configuração pessoal do usuário no arquivo .ssh/config em seu diretório pessoal; 3. o que não estiver ainda configurado seguirá a configuração global em /etc/ssh/ ssh_config. As opções de linha de comando do ssh podem ser verificados em sua página de manual. Assim, esta seção irá abordar apenas a configuração global, uma vez que a sintaxe do arquivo de configuração pessoal é idêntica. A Figura 8.2 mostra um exemplo de configuração global do ssh. Nesse arquivo, o trecho comentado refere-se às configurações padrões. Note, no exemplo da Figura 8.2, a habilitação de execução de aplicações gráficas remotas para todas as máquinas, com o uso da diretiva ForwardX11 habilitada. Note também

Servidores de Acesso Remoto

que, por padrão, é habilitado autenticação por senha ou por chave RSA. Mais detalhes podem ser obtidas na página de manual do comando ssh. # Host * # ForwardAgent no # ForwardX11 no # RhostsAuthentication yes # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking ask # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, # aes192-cbc, aes256-cbc # EscapeChar ~ Host * ForwardX11 yes Figura 8.2: Arquivo /etc/ssh/ssh_config

8.4

CONFIGURAÇÃO DO SERVIDOR SSH

A configuração do servidor SSH é extremamente simples, bastando-se editar o arquivo /etc/ssh/sshd_config, como ilustrado na Figura 8.3. Note que existem outras opções não ilustradas nessa figura, apenas as mais importantes. Observe que foi habilitado a execução remota automática de aplicações gráficas e o servidor sftp (Secure FTP), uma alternativa mais segura ao serviço de FTP. Uma vez habilitado o serviço de sftp, os usuários do sistema podem utilizar os comandos scp e sftp para transferência de arquivos. Consulte as páginas de manuais desses comandos para maiores detalhes.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

#HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #RSAAuthentication yes #PasswordAuthentication yes #PermitEmptyPasswords no #X11Forwarding no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #KeepAlive yes #UseLogin no # Mensagem apresentada no antes do {\em login} #Banner /some/path #VerifyReverseMapping no # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server Figura 8.3: Arquivo /etc/ssh/sshd_config

8.5

CONFIGURAÇÃO DE PROVEDORES DE ACESSO REMOTO

Configurar um provedor consiste basicamente em duas etapas. Inicialmente deve-se habilitar o PPP para receber chamadas remotas. Observe que isso é feito pelo pppd, o mesmo utilizado para que a estação faça chamadas remotas. Isso ocorre porque o PPP é um protocolo ponto a ponto. Assim, em termos formais, no serviço PPP, a tarefa de cliente e a de servidor é feita pelo mesmo aplicativo. Recomenda-se, nesse caso, a leitura do PPP-HOWTO1 , em especial o Capítulo 28 (Setting up a PPP server). Configurado o servidor PPP, resta ainda o processo de autenticação e contabilidade de acesso dos usuários, o que é feito geralmente com o uso do protocolo RADIUS (Remote Authentication in Dial-In User Service). Existem vários servidores RADIUS disponíveis, entre eles o GNU Radius, que faz parte do projeto GNU. Esse servidor possui excelente documentação orientando sua configuração e uso, sendo recomendada sua leitura por administradores interessados.

1 http://www.tldp.org/HOWTO/PPP-HOWTO/index.html

REFERÊNCIAS BIBLIOGRÁFICAS

ANONYMOUS. Maximum Linux Security: A Hacker’s Guide to Protecting Your Linux Server and Workstation. Indianapolis: Sams, 2000. BAUTTS, T.; DAWSON, T.; PURDY, G. N. Linux Network Administrator’s Guide. 3. ed. Sebastopol: O’Reilly, 2005. DOMINGUES, M. A.; SCHNEIDER, B. d. O.; UCHÔA, J. Q. Autenticação em sistemas Linux usando OpenLDAP. In: Semac2001 - XII Semana da Computação - IV Workshop em Linux, Internet e Aplicações. São José do Rio Preto: UNESP, 2001. Disponível em: <http://www.ginux.ufla.br/˜joukim/extensao/>. FRAMPTON, S. Linux Administration Made Easy. [S.l.]: The Linux Documentation Project, 1999. URL: http://www.tldp.org/guides.html. KIRCH, O.; DAWSON, T. Linux Network Administrator’s Guide. 2. ed. Sebastopol: O’Reilly, 2002. Disponível em: <http://www.tldp.org/guides.html>. KUKUK, T. The Linux NIS(YP)/NYS/NIS+ HOWTO, v1.2, 4 August 2002. 2002. The Linux Documentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/ HOWTO/NIS-HOWTO. Disponível em: <http://www.tldp.org/pub/Linux/docs/HOWTO/NISHOWTO>. MANN, S.; MITCHELL, E. L. Linux System Security: An Administrator’s Guide to Open Source Security Tools. New Jersey: Prentice-Hall, 2000. MOCKAPETRIS, P. Domain Names – Concepts and Facilities. Internet Engineering Task Force (IETF), Novembro 1983. (Request for Comments: 882). URL: http: //www.ietf.org/. MOCKAPETRIS, P. Domain Names – Implementation and Specification. Internet Engineering Task Force (IETF), Novembro 1983. (Request for Comments: 883). URL: http://www.ietf.org/.

EDITORA - UFLA/FAEPE - Serviços de Redes em Linux

MOCKAPETRIS, P. Domain Names – Concepts and Facilities. Internet Engineering Task Force (IETF), Novembro 1987. (Request for Comments: 1034). URL: http: //www.ietf.org/. MOCKAPETRIS, P. Domain Names – Implementation and Specification. Internet Engineering Task Force (IETF), Novembro 1987. (Request for Comments: 1035). URL: http://www.ietf.org/. NEMETH, E. et al. UNIX System Administration Handbook. 2. ed. New Jersey: Prentice-Hall, 1995. NEMETH, E. et al. UNIX System Administration Handbook. 3. ed. New Jersey: Prentice-Hall, 2001. STANFIELD, V.; SMITH, R. W. Linux System Administration. San Francisco: Sybex, 2001. (Craig Hunt Linux Library). UCHÔA, J. Q. Segurança Computacional. 2. ed. Lavras: UFLA/FAEPE, 2005. (Curso de Pós Graduação “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). UCHÔA, J. Q. Gerenciamento de Sistemas Linux. 3. ed. Lavras: UFLA/FAEPE, 2007. (Curso de Pós Graduaçãoo “Lato Sensu” (Especialização) a Distância em Administração em Redes Linux). WIRZENIUS, L.; OJA, J.; STAFFORD, S. The Linux System Administrator’s Guide; Version 0.7. [S.l.]: The Linux Documentation Project, 2001. URL: http://www.tldp.org/ guides.html.