serviÇos de redes em linux
DESCRIPTION
APOSTILA SERVIÇOS DE REDES EM LINUXTRANSCRIPT
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ôaFernando Cortez Sica
Luiz Eduardo Simeone
Universidade Federal de Lavras – UFLAFundação de Apoio ao Ensino, Pesquisa e Extensão – FAEPE
Lavras – MG
PARCERIAUFLA – Universidade Federal de LavrasFAEPE – Fundação de Apoio ao Ensino, Pesquisa e Extensão
REITORAntônio Nazareno Guimarães Mendes
VICE-REITORRicardo Pereira Reis
DIRETOR DA EDITORAMarco Antônio Rezende Alvarenga
PRÓ-REITOR DE PÓS-GRADUAÇÃOJoel Augusto Muniz
PRÓ-REITOR ADJUNTO DE PÓS-GRADUAÇÃO “LATO SENSU”Marcelo Silva de Oliveira
COORDENADOR DO CURSOHeitor Augustus Xavier Costa
PRESIDENTE DO CONSELHO DELIBERATIVO DA FAEPEEdson Ampélio Pozza
EDITORAÇÃOGrupo Ginux (http://ginux.comp.ufla.br/)
IMPRESSÃOGráfica Universitária/UFLA
Ficha Catalográfica preparada pela Divisão de Processos Técnicosda Biblioteca Central da UFLA
Uchôa, Joaquim QuinteiroServiç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çãode Apoio ao Ensino, Pesquisa e Extensão. VI. Título.
CDD-001.64404
Nenhuma parte desta publicação pode ser reproduzida, por qualquermeio ou forma, sem a prévia autorização.
SUMÁRIO
1 Introdução 9
2 Redes TCP/IP 13
2.1 Conceitos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Endereçamento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Roteamento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3 Resolução de nomes de máquinas . . . . . . . . . . . . . . . . . . . . 15
2.2 Interfaces de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Point-to-Point protocol (PPP) em Linux . . . . . . . . . . . . . . . . . . . . . 16
2.4 Outras Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Linux como Roteador IP ou Firewall 19
3.1 Roteamento em Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Firewall em Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Uso do iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.1 CHAINS e políticas padrão . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.2 Criando novas regras de filtragem . . . . . . . . . . . . . . . . . . . . 22
3.4.3 iptables-save e iptables-restore . . . . . . . . . . . . . . . . 25
3.5 Network address translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1 O que é NAT e qual a sua utilidade . . . . . . . . . . . . . . . . . . . . 26
3.5.2 Source-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.3 Destination-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Serviços de Correio Eletrônico 29
4.1 Conceitos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Uso de Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Configuração Básica do sendmail . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Outros Exemplos de Sistema de E-Mail . . . . . . . . . . . . . . . . . . . . . 39
4.4.1 QMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.2 Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Listas de Discussão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 O Servidor WWW 43
5.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Configuração Básica do Apache . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 O Arquivo httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.2 Os Arquivos srm.conf e access.conf . . . . . . . . . . . . . . . . 47
5.3 Habilitação do https . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.1 Criação de Chaves para HTTPS . . . . . . . . . . . . . . . . . . . . . 50
6 Compartilhamento de Arquivos 53
6.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Uso de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.1 Configurando o Servidor NFS . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.2 Configuração do Cliente NFS . . . . . . . . . . . . . . . . . . . . . . . 55
6.3 O Servidor FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Integração do Linux com redes Windows . . . . . . . . . . . . . . . . . . . . 57
6.4.1 Configurando o Servidor SAMBA . . . . . . . . . . . . . . . . . . . . . 57
6.5 Acessando Compartilhamentos Windows . . . . . . . . . . . . . . . . . . . . 64
7 Serviços de Informação em Redes 65
7.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2 Serviço de Domínio de Nomes (DNS) . . . . . . . . . . . . . . . . . . . . . . 65
7.2.1 Resolução de Nomes em Linux . . . . . . . . . . . . . . . . . . . . . . 69
7.2.2 O Servidor DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.2.3 Configurando o named . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.2.4 Configurando Zonas de Domínios . . . . . . . . . . . . . . . . . . . . 77
7.2.5 Base de Dados DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2.6 Consultando o DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.3 Compartilhamento de Informações . . . . . . . . . . . . . . . . . . . . . . . . 83
7.4 DHCP e OpenSLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.5 Servidores de Bancos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . 87
8 Servidores de Acesso Remoto 89
8.1 Comentários Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.2 Configuração Básica do SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.3 Configuração do Cliente SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.4 Configuração do Servidor SSH . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.5 Configuração de Provedores de Acesso Remoto . . . . . . . . . . . . . . . . 92
Referências Bibliográficas 93
LISTA DE FIGURAS
2.1 Exemplo de Sub-redes com roteadores . . . . . . . . . . . . . . . . . . . . . 15
3.1 Arquivo com as regras do iptables . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Exemplos de Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Exemplos de Conteúdo para o Arquivo .forward . . . . . . . . . . . . . . . 32
4.3 Exemplo de Arquivo m4 para sendmail.cf em Máquinas Clientes . . . . . 34
4.4 Exemplo de Arquivo m4 para sendmail.cf em Máquina Servidora . . . . . 36
4.5 Arquivo m4 para Domínio Genérico . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Etapas para Instalação do Apache . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Trecho para Inicialização do Apache no Momento de Boot . . . . . . . . . . . 45
5.3 Exemplo de Definição de Domínio Virtual para EmpresaX . . . . . . . . . . . 46
5.4 Exemplo de Definição de Domínio Virtual para EmpresaX . . . . . . . . . . . 48
5.5 Exemplo de Arquivo .htaccess . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6 Exemplo de Arquivo .htaccess . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Carregando o Módulo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.8 Carregando o Módulo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.9 Carregando o Módulo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1 Arquivo /etc/exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Exemplo de Arquivo smb.conf – Seção global . . . . . . . . . . . . . . . . 58
6.3 Exemplo de Arquivo smb.conf – Compartilhamentos . . . . . . . . . . . . . 59
7.1 Árvore DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2 Arquivo /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Arquivo /etc/host.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.4 Arquivo /etc/nsswitch.conf . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.5 Arquivo /etc/resolv.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.6 Exemplo de /etc/named.conf . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.7 A Seção zone do Arquivo /etc/named.conf . . . . . . . . . . . . . . . . . 77
7.8 Base de Dados de DNS Direto . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.9 Base de Dados de DNS Reverso . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.10 Uso do Comando dig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.11 Exemplo de Arquivo /etc/dhcpd.conf . . . . . . . . . . . . . . . . . . . . 87
8.1 Man-In-The-Middle Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.2 Arquivo /etc/ssh/ssh_config . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3 Arquivo /etc/ssh/sshd_config . . . . . . . . . . . . . . . . . . . . . . . . 92
LISTA DE TABELAS
2.1 Divisão do endereço IP e Classes . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Redes IP reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Alvos ou TARGETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Parâmetros para a filtragem de pacotes . . . . . . . . . . . . . . . . . . . . . 23
3.3 Parâmetros para filtragem de pacotes TCP e UDP . . . . . . . . . . . . . . . 23
3.4 Estado dos pacotes testados pelo parâmetro -m state . . . . . . . . . . . . 24
4.1 Ações Associadas aos Aliases na Figura 4.1 . . . . . . . . . . . . . . . . . . 31
4.2 Descrição das Linhas do Exemplo Contido na Figura 4.3 . . . . . . . . . . . 35
4.3 Descrição das Linhas do Exemplo de Arquivo m4 para sendmail.cf da Fi-gura 4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Descrição dos Arquivos de Configuração do QMail . . . . . . . . . . . . . . . 40
4.5 Exemplo de conteúdo dos arquivos de configuração do QMail . . . . . . . . . 41
5.1 Módulos Úteis não Incluídos na Instalação Padrão . . . . . . . . . . . . . . . 44
6.1 Opções do Arquivo /etc/exports . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 Opções de Compartilhamento no SAMBA . . . . . . . . . . . . . . . . . . . . 63
7.1 Domínios Genéricos de Alto Nível . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2 Domínios de Países . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3 Informações Compartilhadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4 Bases Utilizadas no /etc/nsswitch.conf . . . . . . . . . . . . . . . . . . 71
7.5 Taxionomia de Servidores de Nomes . . . . . . . . . . . . . . . . . . . . . . . 73
7.6 Seções Usadas no /etc/named.conf . . . . . . . . . . . . . . . . . . . . . 75
7.7 Opções da Seção options no /etc/named.conf . . . . . . . . . . . . . . 75
7.8 Tipos de Registros DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
1INTRODUÇÃ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 qualquercomputador que ofereça serviços em rede, que são utilizados pelo usuário final em outramáquina. Isso implica que, na maioria dos casos, um servidor não é considerado umaestação. Ao processo de gerenciamento de uma servidor, dá-se o nome de administraçãode 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. Dessamaneira, 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 tipode serviço oferecido. Nesse sentido, o texto foi organizado de forma que o leitor possaabordar cada aspecto de configuração individualmente. Cada capítulo foi pensado de formaque 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. OCapítulo 3, por sua vez, mostra como utilizar o Linux para roteamento TCP/IP ou serviçosde firewall.
O Capítulo 4 apresenta o serviço de correio eletrônico, com certeza um dos mais im-portantes. Além da configuração básica dos principais servidores de e-mail, ele aborda ouso 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émdos 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 ser-viços de diretório, como NIS e LDAP, são explicados no Capítulo 7. Esse capítulo também
10 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 prin-cipais serviços de acesso remoto, dando especial destaque ao SSH.
Este texto foi escrito pensando em um usuário intermediário do sistema operacionalLinux (ou equivalente). Ele foi produzido principalmente a partir da experiência adquiridapelos 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 diversosmateriais, 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 dis-ponibilizados pela The Linux Documentation Project 2.
Fernando Cortez Sica, um dos autores do livro, é bacharel em Ciência da Computaçãopela Universidade Estadual Paulista (UNESP), campus de Bauru/SP, mestre em Engenha-ria Elétrica pela UNICAMP e doutorando em Ciência da Computação pela UFMG. Dentreoutras atividades, implantou e foi o administrador de um laboratório baseado em estaçõesIBM RISC6K dotadas de UNIX AIX4.1 no Departamento de Computação da UniversidadeFederal de Ouro Preto, onde é professor desde 1996. Atua principalmente nas linhas deSistemas de Computação (Sistemas Operacionais, Redes de Computadores e afins) e Sis-temas Integrados de Hardware e Software (Arquitetura de Computadores, Sistemas Embu-tidos, Eletrônica Digital, etc).
Joaquim Quinteiro Uchôa é licenciado em Matemática pela Universidade Federal deMato Grosso (UFMT), com mestrado em Ciência da Computação pela Universidade Federalde São Carlos (UFSCar). Antes de adotar o Linux, em 1998, já havia trabalhado comSolaris, MS-DOS (lembram-se do CISNE?) e OS/2, passando, obviamente pelos Windows2.0, Windows 3.1 (e 3.11) e Windows 95. Segundo amigos, ele já superou o trauma do usodesses 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 eum dos maiores disseminadores desse sistema operacional na universidade. Professor daUFLA, desde 1997, atua principalmente nas áreas de Teoria da Computação e InteligênciaArtificial.
Luiz Eduardo Simeone, o outro autor, é Bacharelando em Ciência da Computação pelaUniversidade Federal de Lavras. Teve o primeiro contato com Linux em 2000, incentivadopor professores. Trabalhou com suporte ao usuário no Departamento de Administração eEconomia da UFLA, com sistemas Windows 95, Windows 98 e Windows NT workstation.
1Um Howto é um pequeno guia que ensina um usuário a configurar um serviço ou fazer uma dada tarefa.2The Linux Documentation Project: http://www.tldp.org/. A tradução de parte dos documentos
desse projeto podem ser encontrados em http://br.tldp.org/.
Introdução 11
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 doDepartamento de Ciência da Computação.
Os autores se sentirão realizados com a escrita desta obra se ela contribuir para disse-minar ainda mais o uso de Linux no Brasil e desejam um bom aprendizado ao leitor.
12 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
2REDES TCP/IP
2.1 CONCEITOS BÁSICOS
2.1.1 Endereçamento IP
Um endereço IP, na versão 4, é um conjunto de 4 números de 0 até 255, separadospor ponto, ex: 192.168.4.1. Esse endereço é dividido em duas partes: o endereço darede 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 tamanhodo 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 primeironúmero. As redes classe ’B’ tem endereços entre 128.0.0.0 e 191.255.255.255, sendoo endereço da rede os dois primeiros números. As redes classe ’C’ tem endereços entre192.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 asredes classes ’E’ tem endereço entre 240.0.0.0 e 255.255.255.255. As duas últimassã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 usadospara definir o endereço de um host. O primeiro define uma rede, e é chamado de endereçode broadcast. Então o IP 192.168.4.1 é um host da rede 192.168.4.0. O segundonúmero se refere a todos os hosts de uma rede. Portanto o IP 192.168.4.255 significatodos 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 mostraa Tabela 2.2. O endereço 0.0.0.0 é conhecido como rota padrão. A rota padrão fazparte da tabela de rota, no roteamento de pacotes IP. A rede 127.0.0.0 é reservadapara o tráfego local, no próprio host. Geralmente o IP 127.0.0.1 é associado a uma
14 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
Tabela 2.1: Divisão do endereço IP e Classes
Endereço Endereço da rede Endereço do host Classe192.168.4.1 192.168.4.0 1 C135.33.140.29 135.33.0.0 140.29 B97.44.150.32 97.0.0.0 44.150.29 A
Tabela 2.2: Redes IP reservadas
Classe Rede ReservadaA 10.0.0.0 até 10.255.255.255
B 172.16.0.0 até 172.31.0.0
C 192.168.0.0 até 192.168.255.0
interface especial, chamada de loopback. Todo tráfego de pacotes TCP e UDP direcionadospara loopback retornam para o host de origem, como se estivesse chegando de uma redequalquer. A interface loopback é especialmente útil para desenvolvimento de software pararede, 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 essesendereços não são roteados na internet, ou seja: não existe nenhum host na internet comestes endereços. Esses endereços são geralmente usados com NAT, abordado na seção3.5.
2.1.2 Roteamento IP
Para entender como é feito o roteamento de pacotes em uma rede IP é muito impor-tante conhecer o conceito de sub-rede. Seja uma instituição de ensino superior chamadaUCJ (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 seto-res, como por exemplo o DMV (Depto. de Medicina Veterinária), DCF (Depto. de CiênciasFlorestais), e a PRG (Pró-reitoria de Graduação). Para facilitar a administração da rede, oCentro de Processamento de Dados resolveu dividir a rede da UCJ da seguinte forma: oDMV vai ficar com a rede 148.75.2.0, com mascara de rede 255.255.255.0; o DCFcom a rede 148.75.3.0, com mascara de rede 255.255.255.0; e a PRG com a rede148.74.4.0, com mascara de rede 255.255.255.0, como ilustrado na Figura 2.1 Asredes do DCF, DMV e PRG são sub-redes da rede da UCJ. Entre as redes dos departa-mentos e o backbone central da UCJ, existe um roteador, que é responsável pela entrega
Redes TCP/IP 15
DMV
RoteadorDMV
DCF
RoteadorDCF
148.75.2.0
148.75.3.0
148.75.4.0
PRG
RoteadorPRG
Rede UCJ
Figura 2.1: Exemplo de Sub-redes com roteadores
dos pacotes da sub-rede do seu departamento. Assim, existe um roteador no DMV, um noDCF, um na PRG e assim por diante.
Pensando nas dimensões da internet, o roteamento em redes IP implementa a famosatécnica do ”dividir para conquistar”, pois a tarefa de rotear os pacotes é dividida entre umnúmero incalculável de servidores em todo o mundo. Agora, imagine se todo o roteamentode 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 serlembrado. Entretanto, é possivel chamar um host de “laranjada“ ou “onibus“. O processode transformar esses nomes comuns em endereços IP é chamado resolução do nome deum host. Existem formas diferentes de transformar nomes em IP. Uma delas, e a maissimples, é adicionar um IP associado a um nome no arquivo /etc/hosts. Existe tambémo NIS, e a base de dados LDAP, que funcionam como um serviço de diretório ou YellowPages (páginas amarelas), além do DNS (Domain Name System) que serão estudados noCapítulo 7.
16 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 protocoloTCP/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 sea interface fosse a porta, e o endereço fosse o número a ela associado. O nome dasinterfaces varia de acordo com tipo de hardware a ela associado, como por exemplo asinterfaces 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 IPsobre um link serial, como as linhas telefônicas. PPP em Linux é implementado em trêspartes: uma parte no kernel, uma através do daemon pppd, e a outra através do programachat. 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áfegode dados na linha serial. O pppd também pode ser configurado ao gosto do usuário, masesse não é o objetivo desta seção, uma vez que existem inúmeros aplicativos com essafacilidade (como o KPPP, o vppp, o linuxconf, o rp3 ou o wvdial). O wvdial e olinuxconf, inclusive, possuem interface em modo texto. Para maiores detalhes sobre oPPP é recomendada a leitura do PPP-HOWTO1.
2.4 OUTRAS TECNOLOGIAS
2.4.1 DSL
A tecnologia DSL (Digital Subscriber Loop) permite comunicação dedicada em alta ve-locidade através de uma linha telefônica comum. Uma das características importantes doDSL, principalmente do ADSL (Asynchronous DSL), é possibilidade de compartlhamentoda linha com serviços de voz e até ISDN. Isso é possivel devido ao DSL utilizar uma faixade freqüência inferior a de voz (freqüência de voz está acima de 4KHz), criando assim doiscanais na mesma linha: um para voz e outro para dados. Isso é fundamental para viabilizaro serviço, pois diminui muito o custo das empresas de telecomunicações na manutenção
1http://www.tldp.org/HOWTO/PPP-HOWTO/index.html
Redes TCP/IP 17
dessas linhas. O principal público-alvo desse serviço são so usuários SOHO (Small Officeand 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 es-pecificam 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 essescanais podem tanto originar quanto receber chamadas. Esse serviço pode ser oferecidotanto 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çãofornecer um serviço simples de transmissão de dados.
18 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
3LINUX 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 derede, o o kernel já ativou o roteamento de pacotes. O servico roda inicialmente de umaforma local, roteando apenas os pacotes da própria máquina. Para que o kernel possarotear pacotes de outras máquinas é preciso dizer que ele deve fazer isso, que é feitoinserindo 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 gerenciaras tabelas de rota e o cache. Vale a pena salientar que o zebra, ao ser iniciado já alterao valor de ip_forward para 1. Se a opção for o routed, existe a necessidade de alteraresse valor. Isso pode ser feito de várias maneiras. Por exemplo, pode-se colocar no ar-quivo /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.
1http://www.zebra.org
20 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 DMVtem uma interface de rede com o ip 148.75.2.1, que está ligada à sub-rede do DMV, euma outra interface 148.75.1.6, que está ligada à rede da UCJ. Se as redes forem seg-mentadas físicamente, cada uma das interfaces tem que estar associadas a um dispositivofísico exclusivo para si. Mas se as redes trafegarem sob o mesmo meio físico, pode ser feitoum alias, isto é, associar um único dispositivo físico a várias interfaces. Usar aliases podeser interessante dependendo da situação, mas não é recomendável. Existe uma perda dedesempenho razoável com essa situação. O ideal é que as redes sejam segmentadas fisi-camente, pois isso evita que algum usuário consiga ”driblar” o roteador, e que mesmo quea rede trafegue no mesmo meio físico, que cada interface tenha um dispositivo de hardwareexclusivo à sua disposição.
3.2 FIREWALLS
Um firewall é uma muralha que protege o sistema contra agentes maliciosos do mundoexterior, 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, é umsoftware. E como todo software, ele tem bugs. E esses bugs podem se tornar possíveisportas de entrada para agentes não muito bem-vindos. Em resumo, nenhum firewall é to-talmente seguro. Até os sistemas da NASA e do Pentágono (Quartel-General das forçasarmadas norte-americanas) já foram invadidos. O importante é que o administrador tenhaa consciência de quem (quais redes) pode acessar o que (quais protocolos/portas), e quemesmo com o firewall é sempre importante fazer verificações periódicas nos registros dosistema 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. Essefiltro era userspace, ou seja, rodava como um programa comum no sistema, similarmente aoBIND (servidor de nomes). Com o kernel 2.0 veio o ipfwadm, que ainda era uma ferramentauserspace e controlava as regras de filtragem do kernel. Na versão 2.2 do kernel, veio oipchains (ainda presente em algumas distribuições) e em 1999, veio o iptables 2, presentea partir do kernel 2.3.15. O iptables, que será o tema da próxima seção, se relaciona como kernel de forma que ele saiba como filtrar os pacotes.
2http://www.netfilter.org
Linux como Roteador IP ou Firewall 21
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 naopodem ser apagadas: INPUT, OUTPUT e FORWARD. A chain INPUT trata dos pacotes deentrada, aqueles que chegam da rede. A chain OUTPUT trata dos pacotes de saída, aquelesque 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 gostodo 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ásicossão o ACCEPT, que aceita os pacotes e o DROP que rejeita pacotes. Na Tabela 3.1 é possívelobservar os targets disponíveis e sua descrição básica.
Tabela 3.1: Alvos ou TARGETs
TARGET Descrição
ACCEPT Aceita os pacotes em questão.DROP Rejeita os pacotes.LOG Permite fazer log dos pacotes que se encaixam
na regra.REJECT Tem o mesmo efeito de DROP, porem pode ser
configurado para retornar mensagens de erro.QUEUE Coloca o pacote em uma fila userspace, ou seja
ao alcance do usuário para que ele use essespacotes como bem entender. Este target aindaestá em fase experimental.
Chains só podem ter como alvo DROP e ACCEPT, sendo a última o alvo padrão. Algunscomandos 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>
22 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 mandadopara a rede. Outros pontos importantes são: o protocolo, as redes ou hosts que devem serfiltrados, 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, aocriar as regras, deve ser observada a ordem das mesmas, para que não haja funcionamentoindesejado do firewall. Apenas para exemplificar a criação de uma regra simples, queremosbloquear todos os pacotes de vindos de 192.168.4.39. Para adicionar uma regra a umachain 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, po-dem ser passados vários parâmetros. O parâmetro que determina o endereço de origemdos pacotes é o ”-s <endereço-IP>”. Outro parâmetro que deve ser passado é o alvo, outarget 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. Masexistem alguns deles que são comuns a todos os protocolos e eles funcionam como des-crito na Tabela 3.2. Existem parâmetros específicos dos protocolos TCP e UDP. Eles sãohabilitados pelos parâmetros -p tcp e -p udp. Na Tabela 3.3 há uma descrição dosparâmetros e para quais protocolos ele está disponível.
Merece destaque o parâmetro -m <argumento> que habilita algumas extensões doiptables. Quando o <argumento> é state, a opção --state é habilitada. Esta opçãotesta o estado dos pacotes tratados pela regra, e o uso de ”!” tem o significado do ope-rador lógico NOT. Na Tabela 3.4 são especificados os estados possíveis. O argumentomac habilita a opção --mac-source que associa o endereço Ethernet (físico, ou endereço
Linux como Roteador IP ou Firewall 23
Tabela 3.2: Parâmetros para a filtragem de pacotes
Parâmetro Descrição
-i <interface> Determina a interface de entrada.-o <interface> Determina a interface de saída.
-s <IP> Determina o endereço de origem dos pacotes.-d <IP> Determina o endereço de destino dos pacotes.
-p <protocolo> Determina o protocolo (tcp, udp, icmp, etc).-m <argumento> 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
--sport <porta> TCP e UDP Especifica a porta de origem dopacote. Deve ser especificadaapenas 01 porta, e o uso de ”!”tem o sentido do operador lógicoNOT
--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 aporta especificada é a de des-tino.
--destination-port <porta> TCP e UDP Tem o mesmo efeito de--dport <porta>
MAC) do pacote, sendo que o operador ”!” tem o mesmo sentido que em state. O ar-gumento 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, /hourou /h, /day ou /d. O outro parâmetro, --limit-burst, determina quantas entradaspodem 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.
24 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 Estado de um pacote que está envolvido emuma nova conexão.
ESTABLISHED Pacote que faz parte de conexões anteriormenteestabelecidas.
RELATED Pacote que não faz parte de uma conexão pre-viamente estabelecida, mas que está relacio-nado com uma.
INVALID Pacote que não pode ser identificado, ou por serdesconnhecido, 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 de-ath), 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 rela-cionados com conexões estabelecidas.# iptables -A INPUT -m state --state ESTABLISHED,RELATED \
-j ACCEPT
Linux como Roteador IP ou Firewall 25
3.4.3 iptables-save e iptables-restore
Os programas iptables-save e iptables-restore são de grande importânciapois eles permitem que as regras do iptables que estão em memória possam ser salvos emum 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 bastadirecionar 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-savee 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 filtragemde pacotes. Existem outras extensões que aqui não foram abordadas, mas que podem
26 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
ser usadas. Para um maior entendimento, é recomendada a leitura da documentação doiptables 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écnicaque 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, dadasas imperfeições existentes nos protocolos de rede, são perfeitos, existe a necessidade deutilizar 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 ouSource-NAT, consiste em alterar o endereço de origem dos pacotes. A principal utilizaçãodo SNAT é o Masquerading, ou mascaramento de IPs, permitindo o compartilhamento deum único endereço IP válido com acesso à internet com uma rede de IPs não-válidos. ODNAT, ou Destination-NAT, é a alteração o endereço de destino dos pacotes. Isso é útilpara prover acesso externo à servidores que estão em uma rede de endereços IP não-vá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çãoentre eles. O termo ”transparente” deve-se ao fato de os usuários não perceberem queestão sob um proxy. O Squid 4, específico para fazer proxy, também pode ser usado parafazer um proxy transparente.
3.5.2 Source-NAT
O SNAT é feito na chain POSTROUTING, da tabela nat. Ou seja, a alteração no ende-reç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 deIPs 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 chamadaMasquerading, 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 desaída. Para conexões com IP estático, deve ser usada a primeira forma de SNAT apresen-
3http://www.netfilter.org/documentation/4http://www.squid-cache.org
Linux como Roteador IP ou Firewall 27
tada. Segue abaixo dois exemplos, um utilizando SNAT para endereço de saída estático eoutra 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 re-gras 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 ainterface 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. Abaixoalguns 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 sis-tema rodando linux a ser um roteador e firewall simples e funcional. Existem necessidadesespeciais de roteamento e filtragem que não foram abordadas neste texto. Mas se osconceitos aqui apresentados forem absorvidos de maneira consistente, a tarefa de aten-der essas necessidades certamente consistirá apenas em utilizar extensões da ferramentaabordada de maneira diferente da apresentada.
28 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
4SERVIÇOS DE CORREIO ELETRÔNICO
4.1 CONCEITOS BÁSICOS
Atualmente, a utilização de correio eletrônico tornou-se praticamente necessária sob oponto de vista de negócios e social. Sendo assim, a configuração de sistemas de correioeletrônico tornou-se uma tarefa quase que obrigatória por parte dos administradores desistema. Antes de abordar a configuração dos sistemas de correio eletrônico, são descritosalguns conceitos e termos relacionados:
Mail-box: o mail-box é representado por um arquivo ou diretório cuja função é armaze-nar 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 men-sagens são vinculadas a arquivos cuja identificação (nome) consiste no próprio logindo usuário proprietário das mensagens.
Mail user agents (MUA): são aplicações diretamente ligadas aos usuários a fim de queesses possam manipular os seus e-mails (por exemplo, lê-los e escrevê-los). Quantoao 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 (MultipurposeInternet Mail Extensions) para o transporte de informações não textuais. Como exem-plos de MUA, destacam-se o elm, mailx, pine, Netscape, mutt, evolution ezmail.
Mail transfer agents (MTA): responsável por encaminhar as mensagens entre as máqui-nas. Realiza diversas funções de endereçamento de rede a fim de proporcionar aentrega correta e oferecer facilidades aos MUAs. O protocolo manipulado pelos MTAsconsiste 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 osendmail, 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çãodo MSA é aliviar a carga de trabalho do MTA realizando todo o pré-processamento
30 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 es-pecífica do destinatário nos respectivos mail-boxes. Como exemplos de agentes deentrega tem-se: /bin/mail (entrega para usuários locais), /bin/sh (entrega paraarquivos 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 loca-lizado 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 repre-sentados 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 men-sagem (relacionados aos campos From e To do SMTP. Por outro lado, os cabeçalhosseguem a recomendação RFC 822 e denotam, por exemplo, informações como datae 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, porexemplo, tamanho em relação ao número de máquinas e usuários, quantidade de tráfegocorrespondentes às mensagens e critérios de segurança das informações e do domínioem si (segurança tanto no sentido de fora para dentro quanto de dentro para fora). Adotardiversas máquinas para cada uma desempenhar um papel dentro do serviço de correio ele-trônico ou adotar mecanismos de proxies são também políticas interessantes sob os pontosde 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. Vejamais detalhes no Capítulo 7.
4.2 USO DE ALIASES
Em alguns casos, é necessário redirecionar as mensagens para usuários ou locais dis-tintos a fim de ser possível, por exemplo, a implementação de sistemas para listas de dis-cussões. O sendmail suporta diversos mecanismos de aliases, como os configurados pelosadministradores e usuários comuns, como também o LDAP (Lightweight Directory AccessProtocol), NetInfo (NeXT/Apple), NIS e NIS+ (da Sun), dentre outros.
Serviços de Correio Eletrônico 31
Antes de abordar a manipulação de LDAP, é conveniente abordar os mecanismos tradi-cionais de aliases: aqueles mantidos pelo MTA, aqueles cuja localização do arquivo corres-pondente é /etc/mail/aliases (ou /etc/aliases) e aqueles mantidos pelo própriousuá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 arquivode aliases. Essas linhas possuem ações associadas, descritas na Tabela 4.1.
fulanoA: fulanoB
fulanoC: [email protected]
fulanoE: fulanoA, fulanoB, fulanoC
fulanoF: :include:/etc/mail/lista1.mails
fulanoG: /home/visitors/fulanoG/mail.in
fulanoH: "| /home/prof/fulanoH/filter"
Figura 4.1: Exemplos de Aliases
Tabela 4.1: Ações Associadas aos Aliases na Figura 4.1
Linha Descrição
1 Toda mensagem endereçada a fulanoA deve ser despachada para fulanoB
na máquina local2 Toda mensagem endereçada a fulanoC deve ser despachada para fulanoD
no endereço empresaX.com.br
3 Toda mensagem endereçada a fulanoE deve ser despachada para fulanoA,fulanoB e fulanoC (localmente)
4 Toda mensagem endereçada a fulanoF deve ser despachada para todos osusuários relacionados no arquivo /etc/mail/lista1.mails
5 Toda mensagem endereçada a fulanoG deve ser anexada ao arquivo/home/visitors/fulanoG/mail.in
6 Toda mensagem endereçada a fulanoH deve ser enviada ao aplicativo cujo có-digo executável encontra-se em /home/prof/fulanoH/filter. Nesse casonota-se a presença das aspas duplas em virtude do aparecimento do caracterespecial ‘|’ (pipe), utilizado para representar a comunicação entre processos.
32 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 diretamentee em função da regra da linha 1 por intermédio de fulanoA) e fulanoC nunca receberiaa 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 ali-ases do tipo aos indicados nas linhas 5 e 6. Existem linhas que deverão sempre estarcontidas nos aliases, como por exemplo, a indicação do usuário real que exerce o papeldo Mailer-Daemon (postmaster) e o usuário que receberá as mensagens relativas àspseudo-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. Nessecaso, 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 configuradopelo 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 modi-ficação em relação ao overhead introduzido pela atualização de aliases do sistema. Umexemplo de conteúdo do arquivo .forward (localizado no diretório home do usuário) émostrado na Figura 4.2.
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 .forwardseriam redirecionadas para dois endereços: [email protected] e [email protected]. A seguir é mostrada uma outra possibilidade de conteúdo do arquivo .forward:
\fulano, "/home/fulano/mails.in", [email protected]
Nesse caso, as mensagens seriam mantidas no local padrão de e-mails recebidos (iteminiciado pelo caracter ‘\’), além de serem gravados no arquivo /home/fulano/mails.in
e enviados para [email protected].
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 dadosda Berkeley denominado ndbm ou dbm (esse último mais eficiente, desenvolvido por Keith
Serviços de Correio Eletrônico 33
Bostic e Margo Seltzer, disponível em http://www.sleepycat.com/). Para a criação denovos 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 correioeletrônico devido à sua alta utilização e, também, devido à sua eficiência e completudefuncional frente aos demais sistemas. A configuração do sendmail consiste em, essenci-almente, 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 serdependente 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 dosendmail: escolha de agentes de entrega, regras de reescrita de endereço, formatos doscabeçalhos das mensagens, opções de funcionamento, critérios de segurança e atuaçãofrente a spam. Para a configuração, será tratada aqui a utilização do manipulador de macrom4 ao invés de atuar diretamente sobre o arquivo sendmail.cf. A utilização das macroscobre cerca de 98% das necessidades de configuração do sendmail, além de apresentaruma complexidade bem inferior em relação à edição direta sobre o arquivo de configuraçãodo sendmail.
Para melhor ilustrar a utilização de macros, é colocado na Figura 4.3 um exemplo doarquivo 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) sejaum alias, ou seja, um CNAME do DNS para uma máquina real do domínio da empresa. Noteque 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.
34 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
divert(-1) 1
#### Definições para criação do sendmail.cf - máquinas clientes 2
divert(0) 3
VERSIONID(‘versão do sendmail...’) 4
OSTYPE(‘linux’) 5
FEATURE(‘nocanonify’) 6
undefine(‘ALIAS_FILE’) 7
define(‘MAIL_HUB’, ‘smtp.empresaX.com.br’) 8
define(‘SMART_HOST’, ‘smtp.empresaX.com.br’) 9
define(‘confFORWARD_PATH’, ‘’) 10
MAILER(‘local’) 11
MAILER(‘smtp’) 12
Figura 4.3: Exemplo de Arquivo m4 para sendmail.cf em Máquinas Clientes
Serviços de Correio Eletrônico 35
Tabela 4.2: Descrição das Linhas do Exemplo Contido na Figura 4.3Linha Descrição
01 Elimina lixos no fluxo de saída do m4 – útil para colocar comentários no início do arquivo02 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 aspalavras contidas no comentários não sejam confundidas com palavras pertencentes aorepertório do m4, exemplo: dnl #comentário
03 Final do comentário do início do arquivo04 A macro VERSIONID permite introduzir a versão sob manipulação. Tal definição apare-
cerá como comentário no arquivo sendmail.cf resultante05 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émpoderia ser, por exemplo, solaris2, hpux11 e bsd4.4
06 O FEATURE (macro) possibilita instanciar características importantes ao comporta-mento do sendmail. No exemplo, foi utilizado o recurso nocanonify, o qual expli-cita que as pesquisas de DNS deverão ser realizadas na máquina servidora (e não nasclientes)
07 A linha contendo undefine(‘ALIAS_FILE’) anula a utilização local dos arquivos dealiases, ou seja, toda a manipulação de aliases será feita na máquina servidora. Casofosse necessária a utilização de algum arquivo de aliases, pode-se explicitá-lo com odefine da seguinte forma: define(‘ALIAS_FILE’, ‘/etc/aliases’). Nessecaso, o sendmail verificaria o arquivo /etc/aliases. Caso fosse necessário fazerpesquisa em vários arquivos, usa-se: define(‘ALIAS_FILE’, “/etc/aliases,
nis:mail.aliases”). Nesse caso, caso a busca em /etc/aliases falhasse, seriatentado o mapa NIS denominado mail.aliases
08 O MAIL_HUB sinaliza que todos os e-mails são recebidos por intermédio da máquinaservidora, no caso, denominada como smtp.empresaX.com.br
09 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 exemploaqui colocado, foi utilizado a macro SMART_HOST para indicar que os e-mails locais se-rão tratados localmente e aqueles endereçados às pessoas externas serão manipuladospela máquina servidora (smtp.empresaX.com.br)
10 A linha com o confFORWARD_PATH define ou anula a utilização do arquivo .forward. Nocaso, é instanciado como nulo, deixando a utilização apenas para a máquina servidora
11 A macro MAILER indica qual ou quais os agentes de entrega que estarão ativos no am-biente. 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 refe-rencia a ativação do agente local
12 Por último, assim como o agente de entrega local é ativado, o agente smtp é tambémativado conforme a última linha do exemplo
36 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
Por outro lado, existe o arquivo de configuração do sendmail por parte da máquinaservidora. O exemplo da Figura 4.4 ilustra tal configuração (também baseada em macrosm4). A Tabela 4.3 descreve as linhas referentes a esse exemplo.
divert(-1) 1
#### definições para criação do sendmail.cf - máquina servidora 2
divert(0) 3
VERSIONID(‘versão do sendmail’) 4
OSTYPE(‘linux’) 5
DOMAIN(‘generic’) 6
MASQUERADE_AS(‘empresaX.com.br’) 7
MASQUERADE_DOMAIN(‘empresaX.com.br’) 8
undefine(‘BITNET_RELAY’) 9
undefine(‘UUCP_RELAY’) 10
define(‘confCHECK_ALIASES’, ‘True’) 11
define(‘confCOPY_ERRORS_TO’, ‘Postmaster’) 12
define(‘confEBINDIR’, ‘/usr/lib’) 13
define(‘confERROR_MODE’, ‘m’) 14
define(‘confHOST_STATUS_DIRECTORY’, ‘.hoststat’) 15
define(‘confNO_RCPT_ACTION’, ‘add-to-undisclosed’) 16
define(‘confPRIVACY_FLAGS’, ‘authwarnings,needmailhelo,noexpn,novrfy’) 17
define(‘confTRUSTED_USERS’, ‘majordomo’) 18
define(‘confMAX_DAEMON_CHILDREN’, ‘30’) 19
FEATURE(‘allmasquerade’) 20
FEATURE(‘masquerade_entire_domain’) 21
FEATURE(‘masquerade_envelope’) 22
FEATURE(‘always_add_domain’) 23
FEATURE(‘local_lmtp’) 24
define(‘LOCAL_MAILER_FLAGS’, ‘SXfmnz9PE’) 25
FEATURE(‘mailertable’, ‘hash /etc/mail/mailertable’) 26
FEATURE(‘virtusertable’, ‘hash /etc/mail/virtusertable’) 27
MAILER(‘local’) 28
MAILER(‘smtp’) 29
Figura 4.4: Exemplo de Arquivo m4 para sendmail.cf em Máquina Servidora
Serviços de Correio Eletrônico 37
Tabela 4.3: Descrição das Linhas do Exemplo de Arquivo m4 para sendmail.cf da Figura 4.4
Linha Descrição06 Identifica um arquivo m4 que caracteriza o domínio. Nesse caso, o arquivo denotado é o
generic.m4, o qual é ilustrado na Figura 4.507 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 men-sagem emitida por [email protected] será marcada como sendoproveniente de [email protected], omitindo-se, nesse caso, o nome do hostresponsável pelo envio
08 Mascara domínios em ambientes que hospedam domínios virtuais. A lista de domíniosvirtuais é 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
09 Desativa recursos associados à BITNET10 Desativa recursos associados à UUCP11 Quando a opção confCHECK_ALIASES é ativada, todo alias é verificado pelo DNS em
todo o momento que se executa o newaliases
12 Endereço de cc para mensagens que retratam erros. No exemplo, cc é direcionado aoPostmaster
13 Localização do binário relativo ao mail.local
14 Define a forma de manipulação de erro. No exemplo, a diretiva ‘m’ indica para retornarao remetente mensagens de erros
15 A opção HOST_STATUS_DIRECTORY é utilizada em ambientes que apresentam um altovolume de e-mails a serem reenviados devido à uma falha na tentativa anterior de en-trega. Nesse caso, o sendmail organizará suas filas por nome de hosts a fim de priori-zar aqueles encontrados nessa situação e, também, permitir uma otimização em relaçãoao envio
16 Essa linha determina a ação que deverá ser realizada quando a mensagem ti-ver algum recipiente inválido. No caso, o campo TO é instanciado comoundisclosed-recipients
17 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 per-mite o comando SMTP VRFY)
18 O TRUSTED_USERS é utilizado para determinar usuários representativos de lista de dis-cussões.
19 No arquivo de configuração também há a possibilidade de definir quantos processosfilhos poderão ser criados a partir do sendmail original. No exemplo, definiu-se essenúmero como 30
20 O recurso allmasquerade mascara tanto o emissor quanto o destinatário da mensa-gem
38 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
21 masquerade_entire_domain mascara o domínio inteiro22 O masquerade_envelope mascara, também, os endereços do envelope e os endere-
ços do cabeçalho23 O preenchimento dos campos dos recipientes podem ser completados com o
always_add_domain
24 A linha com o indicativo local_lmtp permite que o correio local seja manipulado porum agente capaz de manipular o LMTP (Local Mail Transport Protocol – RFC 2033)liberando um pouco o processamento por parte do sendmail
25 A referida linha permite definir as flags com as quais o agente local irá ser executado. Asflags lsDFM são sempre inclusas. Portanto, no exemplo, além das aqui citadas, as flagsSXfmnz9PE são igualmente incluídas na lista (para maiores detalhes, ver o manual dosendmail)
26 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 cor-reio específico. O arquivo que representa a tabela é passada como parâmetro e, nesseexemplo, utiliza o método hash para facilitar a busca dentro do arquivo. Tal recurso é útilquando são manipuladas outras estruturas de correio eletrônico, como UUCP e BITNET.
27 Caso o sistema manipule domínios virtuais, é necessário habilitar o recurso virtusertablea fim de suportar os aliases associados. Neste caso, os registros MX do DNS devemestar corretamente configurados e o arquivo cw deve estar presente ou especificadocomo argumento do recurso
Conforme citado, o exemplo da Figura 4.4 requer um arquivo m4 que representa o do-mínio local (conforme a linha 6). Tal arquivo representa as particularidadees para o domíniogenérico e é listado na Figura 4.5. A linha que contém confFORWARD_PATH foi quebradaapenas para fins de editoração.
divert(-1) 1
#### arquivo m4 para Domínio genérico 2
divert(0) 3
VERSIONID(‘indicativo da versão’) 4
define(‘confFORWARD_PATH’,‘$z/.forward.$w+$h:$z/.forward+$h:$z/ 5
.forward.$w:$z.forward’) 6
define(‘confMAX_HEADERS_LENGTH’, ‘32768’) 7
FEATURE(‘redirect’) 8
FEATURE(‘use_cw_file’) 9
EXPOSED_USER(‘root’) 10
Figura 4.5: Arquivo m4 para Domínio Genérico
Serviços de Correio Eletrônico 39
No exemplo da Figura 4.5 nota-se a presença do redirect. Esse recurso faz com quemensagens destinadas a pessoas que não mais pertençam ao domínio sejam devolvidasao 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: [email protected]
Por sua vez, o use_cw_file habilita a classe interna w do sendmail contendo o nomede todos os hosts locais aptos a entregarem e receberem mensagens manipuladas peloservidor. O nome do arquivo contendo a relação de hosts é denominado, por default, comosendmail.cw porém o seu nome pode ser alterado com opção confCW_FILE. Para efeti-var 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 sejaexcluído das alterações realizadas pelo MASQUERADE, ou seja, as mensagens provenientesdo 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 referen-tes 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 mani-pulaçã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íciode 1996. Como o projeto de desenvolvimento de QMail foi iniciado após a grande expansãoda internet, questões como segurança e eficiência foram levadas em consideração durantesua implementação. Por esses motivos, atualmente ocupa a segunda colocação entre osservidores de e-mail mais utilizado no mundo UNIX.
40 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 poderser usado gratuitamente) e não implementar todas as funcionalidades existentes no send-mail. Ele utiliza arquivos de configuração bem definidos, os quais são listados na Tabela 4.4e exemplificados na Tabela 4.5.
Tabela 4.4: Descrição dos Arquivos de Configuração do QMailArquivo (diretório /var/qmail) Descrição
alias/.qmaildefault Informa o endereço para o envio da mensagem caso a en-trega utilizando o agente local falhe
alias/.qmail-mailer-daemon Representa o usuário real que irá responder pelomailer-daemon
alias/.qmail-postmaster Representa o usuário real que irá responder pelopostmaster
alias/.qmail-root Representa o usuário real que irá responder pelo root
control/defaultdomain Identifica o nome do domíniocontrol/defaulthost 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 noqual a mensagem foi gerada
control/locals Identificação dos hosts identificados como locais (para asmensagens serem manipuladas pelo agente local)
control/me Nome da máquina localcontrol/plusdomain Identificação do domínio superiorcontrol/smtproutes Roteia todas as mensagens para a máquina servidora.
Caso este arquivo não exista, as mensagens serão despa-chadas diretamente aos servidores dos destinatários (útilpara o caso de provedores). Caso apareça ‘:’ , as men-sagens não locais serão roteadas para a máquina servi-dora. Rotas específicas podem ser criadas para domíniosou usuários específicos – estes deverão ser colocados an-tes do ‘:’
control/rcpthosts Caso exista este arquivo, identifica os domínios autoriza-dos a receber mensagens pelo QMail
4.4.2 Postfix
Um outro exemplo de sistema de correio eletrônico atualmente bastante difundido é oPostfix. 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 41
Tabela 4.5: Exemplo de conteúdo dos arquivos de configuração do QMailArquivo (diretório /var/qmail) Exemplo de conteúdoalias/.qmaildefault | forward "$LOCAL"@mail.empresaX.com.br
alias/.qmail-mailer-daemon root
alias/.qmail-postmaster root
alias/.qmail-root root
control/defaultdomain empresaX.com.br
control/defaulthost empresaX.com.br
control/locals empresaX.com.br
host1.empresaX.com.br
control/me host1.empresaX.com.br
control/plusdomain com.br
control/smtproutes :mail.empresaX.com.br
O Postfix apresenta facilidades de configuração, utiliza a biblioteca PCRE (Perl Compa-tible Regular Expression) a fim de poder filtrar as mensagens de modo eficiente, suportaapenas 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 implementaquatro 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 adicionalem 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: ge-rencia as filas.
42 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
Para a configuração, são utilizados, essencialmente, dois arquivos: master.cf quefaz a configuração geral do sistema e o main.cf, que apresenta uma sintaxe semelhanteao sendmail.cf e é responsável pelas informações inerentes ao roteamento, reescrita efiltragem. Exemplos de configuração podem ser encontrados junto com a distribuição dosistema.
4.5 LISTAS DE DISCUSSÃO.
Sistemas para listas de discussão manipulam, em primeira instância, aliases para cor-reio 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 depessoas interessadas na discussão sobre um dado tema. Entre as principais alternativasgratuitas para gerenciamento de listas de discussão, merecem destaque o Ecartis (http://www.ecartis.org/, Majordomo (http://www.greatcircle.com/majordomo/) eo Mailman (http://www.list.org/).
Cada gerenciador é configurado de forma particular, possuindo mecanismos própriospara criação e gerenciamento de listas de discussão. Dessa maneira, essa apostila não iráabordar a configuração desses gerenciadores.
5O SERVIDOR WWW
5.1 COMENTÁRIOS INICIAIS
Assim como os protocolos FTP e SMTP, os protocolos utilizados pelos serviços WWWutilizam 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 trans-ferência das informações. Um outro protocolo utilizado, baseado no SSL (Secure SocketsLayer), é 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 fornecerinformaçõ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 manipu-lação de entrada e saída sob demanda (por exemplo, C e Perl) a fim de interfacear com oservidor HTTP.
Administrador e programadores responsáveis pelos scripts têm que observar bastantequestões relacionadas ao aspecto de segurança, uma vez que tais programas são chama-dos remotamente e têm a possibilidade de acessar arquivos, periféricos e qualquer outro re-curso na máquina na qual se realizará o processamento. Informações sobre segurança po-derã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, porrazõ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 servi-dores HTTP.
44 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
5.2 CONFIGURAÇÃO BÁSICA DO APACHE
A configuração do Apache consiste, basicamente, de duas etapas: compilação / ins-talação e a configuração propriamente dita. Caso a instalação seja feita via compilaçãolocal, Após o download do pacote, deve-se executar o script de instalação, especificando odiretó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 listaalguns módulos úteis e não inclusos na instalação padrão.
Tabela 5.1: Módulos Úteis não Incluídos na Instalação PadrãoMódulo Descrição
auth_dbm Autenticação de usuários utilizando DBMauth_db Autenticação de usuários utilizando Berkeley DBusertrack Monitora as ações de click do usuário em navegadores que suportam cookiesrewrite Mapeamento URL-nome_de_arquivo usando expressões regularesexpires Incorpora datas de expiração aos documentosproxy 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, oadministrador pode consultar o arquivo src/Configuration na distribuição do Apache ouconsultar o endereço http://www.apache.org/docs/mod/index.html. Duas pági-nas sugeridas que podem ser acessadas pelo administrador seriam: http://www.cpan.org/modules/by-module/Apache/ e http://modules.apache.org. Em tais pági-nas, podem ser encontrados diversos módulos adicionais a serem, possivelmente, incor-porados ao Apache. Convém salientar que a incorporação de módulos específicos podeproporcionar a habilitação de suporte a ASP, PHP e afins. O procedimento para a adiçãode 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 execu-tar o utilitário make e, após, o make install para completar o processo de compilaçãoe instalação (seqüência ilustrada na Figura 5.1). Caso o administrador use distribuiçõesbaseadas em pacotes (DEB ou RPM), então basta instalar o pacote relativo ao Apachedisponibilizado em sua distribuição.
O Servidor WWW 45
# ./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 acordocom as suas necessidades. Para tanto, há a necessidade de manipulação de três arqui-vos (mantidos, em geral, no diretório /etc/httpd/conf): httpd.conf, srm.conf eaccess.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 ser-viç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, oApache 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 noendereço: http://httpd.apache.org/docs/configuring.html. As diretivas utili-zadas 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 deoperação estão agrupadas em três seções básicas: diretivas globais de controle, diretivaspara as manipulações dentro do domínio principal e diretivas para manipular as requisiçõesendereçadas aos domínios virtuais. Um exemplo do arquivo http.conf pode ser encontradono endereço http://webmaster.bankhacker.com/php/http.conf.phtml.
46 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 de-terminar os domínios virtuais sediados na máquina em questão (uma cláusula para cadainterface virtual). A Figura 5.3 exibe um trecho exemplo a ser colocado no referido ar-quivo 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 diretivaServerName) poderão ser encontrados no diretório /var/www/empresaX (configuradopela diretiva DocumentRoot).
<VirtualHost 200.129.35.88>
ServerAdmin [email protected]
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 in-terface virtual é criada sob uma interface real, providenciando um outro endereço IP parao 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çaconsiste na forma de se identificar as interfaces. Por exemplo, para a definição de interfa-ces virtuais a partir da eth0, basta diferenciá-las por intermédio da sintaxe eth0:y, ondey representa o número da interface (com y ≥ 0). Dessa forma, o comando a seguir defineos parâmetros de configuração da interface virtual eth0:0 que ficará sob responsabilidadeda 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, poishaverá um único dispositivo real para vários endereços IPs. Dado o atual baixo custo deplacas de rede, recomenda-se, preferencialmente o uso de várias placas de rede, isolandoo tráfego de maneira mais eficiente.
Como mencionado anteriormente, há a possibilidade de adição de módulos com a fina-lidadem de manipular serviços e mecanismos não previstos durante a etapa de instalação econfiguração inicial. Para tanto, pode-se utilizar a diretiva LoadModule conforme ilustradoa seguir:
O Servidor WWW 47
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 es-quecer de relacionar as extensões ao serviço. Para tanto, usa-se a diretiva AddType con-forme 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 Apachesuporta 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ódulosdeverão ficar no diretório /usr/lib/httpd ou /usr/lib/apache. Uma documentaçãosobre 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 reiniciaro 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 ser-vidor de páginas. Dentre os recursos, destacam-se a localização do documento raiz aser 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 suasintaxe 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 apenaso arquivo httpd.conf, deixando os arquivos srm.conf e access.conf vazios. Issofacilita 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 diretivasde recursos e permissões de acesso. A Figura 5.4 mostra um exemplo de configuração depermissão no diretório raiz.
Na configuração efetuada na Figura 5.4, a linha contendo a diretiva “Options” espe-cifica o que é válido para essa árvore de diretórios. A opção “Indexes” faz com que seja
48 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” especificaque é 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çõespodem ser sobrepostas via arquivo .htaccess. Dessa maneira, o administrador podedefinir métodos de autenticação para diretórios específicos. A Figura 5.5 ilustra um exemplodesse 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 doApache 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 49
5.3 HABILITAÇÃO DO HTTPS
O serviço de HTTPS pode ser manipulado pelo Apache de duas maneiras: uma é utilizaro Apache-SSL (http://www.apache-ssl.org/), uma versão do Apache com suportepróprio a SSL. A outra forma, talvez a mais comum, é utilizar um módulo específico paraSSL, 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 maneirasemelhante, 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çãopadrão, não sendo necessário alterar em nada a configuração do Apache. Nesse caso, oservidor WEB será responsável por atender pedidos HTTPS na porta 443 e HTTP na porta80, de acordo com o padrão. O administrador deverá então criar as chaves para os sitesexportados 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 douso das diretivas LoadModule e AddModule. A Figura 5.7 ilustra essas diretivas. Nesseexemplo, são utilizados comandos de pré-processamento <IfDefine HAVE_SSL> ...
</IFDefine>. Nesse caso, somente se encontrado o módulo mod_ssl é que o apachetentará 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 modules/libssl.so
</IfDefine>
<IfDefine HAVE_SSL>
AddModule mod_ssl.c
</IfDefine>
Figura 5.7: Carregando o Módulo SSL
Uma vez habilitado o módulo SSL, resta a sua configuração, o que é ilustrado nas Fi-gura 5.8 e Figura 5.9. Na Figura 5.8 são configurados os parâmetros básicos da negociaçãoinicial feita pelo protocolo SSL, bem como os arquivos de registro dessa negociação. NaFigura 5.9, por sua vez, é configurado o domínio virtual padrão (que usa o mesmo nome damáquina). Nesse caso, note que é habilitada a diretiva SSLEngine, bem como é definidoonde estão localizadas a chave e o certificado do servidor. É importante estar atento aesses caminhos, pois ele deve apontar para as chaves criadas para o servidor.
50 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 criaras 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 arquivohttpd.conf. Essa chave irá exigir senha (passphrase) para inicializar o servidor. Casohaja confiança no servidor pode-se evitar a necessidade de digitação da senha, efetuando-se os seguintes passos entre a criação da chave e do certificado:
O Servidor WWW 51
• 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 comandoopenssl é 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
52 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
6COMPARTILHAMENTO DE ARQUIVOS
6.1 COMENTÁRIOS INICIAIS
Compartilhamento de arquivos é uma necessidade antiga na internet. O serviço deFTP (File Transfer Protocol) é um dos mais antigos e conhecidos, por exemplo. Existemvá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émdisso, também é possível utilizar o SAMBA, uma implentação do CIFS (Common InternetFile System), para compartilhamento de arquivos com máquinas Windows.
Dessa maneira, o objetivo deste capítulo é abordar o compartilhamento de arquivos emLinux, especialmente NFS, FTP e SAMBA. Essa abordagem será feita principalmente sobo ponto de vista do servidor, mas também será visto a configuração de clientes NFS ouSAMBA.
6.2 USO DE NFS
O NFS foi desenvolvido para permitir o compartilhamento de diretórios em rede. Atu-almente, encontra-se na versão 3. Essa versão é suportado por kernel com versão 2.4 ousuperior. Além disso, já encontra-se definido o protocolo do NFS versão 4, mas nenhumaimplementaçã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 ferra-mentas extras para o NFS, aumentando a performance do servidor NFS de Linux tradicio-nal. Além disso, possui o aplicativo showmount, que consulta o daemon de uma máquinaremota por informação acerca do servidor NFS (Network File System) dessa máquina. Con-sulte a página de manual desse comando para mais detalhes.
54 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çãode uma linha no arquivo /etc/exports. Uma entrada nesse arquivo possui a seguintesintaxe:
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 compartilha-mento. As opções de compartilhamento mais importantes são listadas na Tabela 6.1. Ou-tras opções podem ser verificadas na página de manual do arquivo /etc/exports (manexport).
Tabela 6.1: Opções do Arquivo /etc/exports
Opção Descrição
ro O diretório é compartilhado apenas para leiturarw O diretório é compartilhado para leitura e escrita pela máquina
clienteno_root_squash Por padrão, qualquer requisição feita pelo usuário root na má-
quina cliente é convertido para o usuário anônimo (geralmentenobody ou nfsnobody) na máquina servidora, aumentando onível de segurança do processo. Caso o usuário root da má-quina cliente deva ter acesso irrestrido ao diretório comparti-lhado, então deve-se usar a opção no_root_squash
all_squash Mapeia todos usuários e grupos para o usuário anônimo
Um exemplo de configuração do arquivo /etc/exports pode ser visualizado na Fi-gura 6.1. Nessa figura, o leitor pode perceber que é possível exportar um diretório parauma 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 paraas máquinas na rede 192.168, para a máquina de nome madonna, para as máquinas
Compartilhamento de Arquivos 55
/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 poderesde leitura e escrita nesse diretório, ao contrário das outras máquinas. Ainda, no caso dodiretório /usr/local, o superusuário da máquina madonna tem os mesmos poderes dosuperusuá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ãoexporta 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 indepen-dentemente, 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 oexportfs. Como o NFS usa RPC (Remote Procedure Calls – chamadas de procedimen-tos remotos), ele também precisa do portmap. Na maioria das distribuições, o processode 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 pro-cesso 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 baseia-se numa camada virtual (VFS – Virtual FileSystem), construída para suportar múltiplos
56 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
sistemas de arquivos. Essa estrutura permitiu ao Linux um gerenciamento poderoso desserecurso. 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 servidormyserv, 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 é desneces-sá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 emconta o UID e o GID do usuário. Assim, é extremamente importante manter o mesmo valorde UID e GID dos usuários no servidor e nas estações. Caso contrário, corre-se o risco dearquivos 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 co-nhecidos 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 pro-ver serviços anônimos de FTP. Jamais user FTP para uso normal por usuários. O tráfegode dados no FTP é feito de forma não-criptografada, facilitando a captura de senhas porhackers. 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 instalaro servidor: é preciso copiar os aplicativos que o usuário ftp poderá utilizar durante atransferê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 pacotehabilita 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 57
6.4 INTEGRAÇÃO DO LINUX COM REDES WINDOWS
A integração do Linux com redes Windows é feita via protocolo CIFS (Common InternetFile System), também conhecido como SMB (Server Message Block). A implementação doCIFS para UNIX é conhecida como SAMBA. Entre os serviços providenciados pelo CIFS esuportados 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á osmbd implementa compartilhamento de arquivos e impressoras, bem como autenticaçãoe autorização. Além dos servidores, a distribuição do SAMBA também providencia outrosaplicativos, 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, essearquivo costuma encontrar-se no /etc, mas versões mais recentes utilizam um diretóriopróprio (/etc/samba) para as configurações do SAMBA. Esse arquivo pode ser divididoem duas partes. A primeira é uma seção de configuração global do servidor, ilustrada naFigura 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áriosutilizando-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 qualqueralteração no arquivo smb.conf, recomenda-se a execução desse aplicativo para verificarse não há erros de sintaxe.
A primeira configuração a ser feita para o servidor SAMBA é a especificação do grupode trabalho do servidor e sua descrição. De acordo com as linha 3 e 4, na Figura 6.2, oservidor será conhecido como Samba Server no ambiente de rede Windows e fará parteda rede MYGROUP. A linha 5, que está comentada, permite configurar quais as estações que
58 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
# Configuração global 1
[global] 2
workgroup = MYGROUP 3
server string = Samba Server 4
; hosts allow = 192.168.1. 192.168.2. 127. 5
; interfaces = 192.168.12.2/24 192.168.13.2/255.255.255.0 6
; remote browse sync = 192.168.3.25 192.168.5.255 7
; remote announce = 192.168.1.255 192.168.2.44 8
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 9
printcap name = /etc/printcap 10
load printers = yes 11
printing = cups 12
; guest account = pcguest 13
log file = /var/log/samba/%m.log 14
max log size = 0 15
security = user 16
; password server = <NT-Server-Name> 17
encrypt passwords = yes 18
smb passwd file = /etc/samba/smbpasswd 19
unix password sync = Yes 20
passwd program = /usr/bin/passwd %u 21
passwd chat = *New*password* %n\n *Retype*new*password* 22
%n\n *passwd:*all*authentication*tokens*updated*successfully* 23
; username map = /etc/samba/smbusers 24
; local master = no 25
; os level = 33 26
; domain master = auto 27
; preferred master = auto 28
; domain logons = yes 29
; logon script = %m.bat 30
; logon script = %U.bat 31
; logon drive = z: 32
; logon path = \%H\Profile 33
; wins support = yes 34
; wins server = w.x.y.z 35
; wins proxy = yes 36
dns proxy = no 37
; preserve case = no 38
; short preserve case = no 39
; default case = lower 40
; case sensitive = no 41
Figura 6.2: Exemplo de Arquivo smb.conf – Seção global
Compartilhamento de Arquivos 59
# Compartilhamentos 1
[homes] 2
comment = Home Directories 3
browseable = no 4
writable = yes 5
valid users = %S 6
create mode = 0664 7
directory mode = 0775 8
9
[printers] 10
comment = All Printers 11
path = /var/spool/samba 12
browseable = no 13
guest ok = no 14
writable = no 15
printable = yes 16
17
;[tmp] 18
; comment = Temporary file space 19
; path = /tmp 20
; read only = no 21
; public = yes 22
23
;[public] 24
; comment = Public Stuff 25
; path = /home/samba 26
; public = yes 27
; writable = yes 28
; printable = no 29
; write list = @staff 30
31
;[pchome] 32
; comment = PC Directories 33
; path = /usr/local/pc/%m 34
; public = no 35
; writable = yes 36
Figura 6.3: Exemplo de Arquivo smb.conf – Compartilhamentos
podem ter acesso aos serviços SAMBA. É extremamente importante configurar esse itempara garantir um nível extra de segurança.
O servidor SAMBA irá ouvir, por padrão, todas as interfaces ativas capazes de broad-cast, com excessão da interface de loopback. A linha 6 da Figura 6.2 apresenta um exemplode configuração de interfaces. Com a opção remote browse sync (linha 7), o servidor
60 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
nmbd irá, periodicamente, requerer sincronização de listas de serviços com um servidorSAMBA em outro segmento de rede. Com a opção remote announce (linha 8), o servi-dor nmbd irá periodicamente anunciar a si mesmo para uma máquina em outro segmentode 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 agrande maioria dos casos. Entretanto, outras opções podem ser verificadas na página demanual do smb.conf (man smb.conf).
A habilitação de impressoras é feita nas linhas 10 a 12 na Figura 6.2. A lista de im-pressoras disponíveis é feita lendo-se o arquivo /etc/printcap. Com a especificaçãodo printcap e a opção load printers ativada, todas as impressoras instaladas local-mente serão compartilhadas. Caso não seja isso o desejado, é possível configurar de outramaneira (veja a página de manual do smb.conf para saber como). O tipo de controladorde 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árioconvidado 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ívelconfigurar 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ívelusar o nome (%u) ou o grupo do usuário (%g). Caso essa opção não seja especificada, oSAMBA irá usar um único arquivo de registro. Recomenda-se, entretanto, ou um arquivopor máquina ou um por usuário. O tamanho máximo do arquivo de registro é especificadocom 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 doscompartilhamentos. É possível implementar segurança por compartilhamento, usando o va-lor 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 porusuário.
Caso seja utilizado um outro servidor de senhas para autenticação de usuários, deve-seconfigurar a opção password server, especificando o nome do servidor responsável poressa tarefa. A menos que estejam sendo utilizadas versões antigas do Windows, deve-sehabilitar a opção encrypt passwords que faz com que a negociação de senhas seja feitade forma criptografada.
Compartilhamento de Arquivos 61
A opção smb passwd file especifica onde se encontra o arquivo de senhas crip-tografadas do SAMBA. Observe que as senhas do SAMBA e do Linux são armazenadasem locais distintos. Dessa maneira, caso pretenda-se manter as senhas Linux e SAMBAativadas, deve-se ativar a opção unix password sync. Nesse caso, também deve serespecificado o programa de alteração de senhas para o Linux (veja a linha 21). As linhas 22e 23 são, a bem da verdade, uma única linha no arquivo de configuração (foram quebradaspor 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 di-ferente no SAMBA, é possível fazer um mapeamento de contas UNIX no Windows. Nessecaso, a opção username map irá especificar qual o arquivo utilizado para esse mapea-mento. 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 Windowsadmin, administrator e administrador. Também é possível fazer mapeamentos dotipo
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 comandotambém permite a alteração de senhas SAMBA pelos usuários ou pelo superusuário. Paraadicionar 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 dousuário, de forma semelhante ao passwd. Note que, nesse caso, já precisa existir a contausuario no UNIX.
Para autenticação de usuários em estações Windows NT ou Windows 2000, é neces-sá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.
62 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 deanúncio entre subredes. Observe que essa opção não deve ser ativada se houver um ser-vidor Windows NT fazendo esse serviço. Caso haja um servidor Windows PDC na mesmasubrede, esse servidor irá tentar se tornar o mestre do domínio (não havendo como impedirisso) 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 detrabalho.
Ativando-se a opção local master irá fazer com que o nmbd tente ser o mestre de do-mí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-seessa opção fará com que o nmbd não participe dessa eleição. A chance do nmbd ganharessa 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 paraganhar a eleição. Recomenda-se esse opção quando a opção domain master tambémestá 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 ser-vidor 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 configuradasno modo automático.
Com a opção domain logons ativada, é possível autenticar usuários em estaçõesWindows 95/98 e mesmo no Windows NT. Em últimas versões, foi possível obter sucessocom estações Windows 2000 no laboratório de computação do DCC/UFLA. Caso esse sejao interesse, o administrador também deve dar atenção às linhas 30 a 33 da Figura 6.2. Elaspermitem 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 naestação tão logo o usuário se logue a uma estação. Esse arquivo pode ser único, ou podeser configurado um arquivo .bat para cada usuário (linha 31) ou para cada estação (linha30). Além disso, em estações NT ou 2000, é possível atribuir uma letra de drive para apasta do usuário, o que é feito na linha 32. Observe para o funcionamento adequado dessaopção é imprescindível que os diretórios pessoais estejam compartilhados, o que será vistomais adiante.
O parâmetro logon path especifica qual o diretório onde são armazenados os arqui-vos de profile do usuário. No profile ficarão armazenados as configurações do usuário,
Compartilhamento de Arquivos 63
incluíndo-se os itens que ele adiciona ao Menu Iniciar. No exemplo, na linha 33, ologon 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 pro-cesso de resolução de nomes de máquinas Windows (se usa WINS ou DNS, etc.). Já aslinhas de 38 a 41 configuram como o SAMBA irá tratar maiúsculas e minúsculas para ar-quivos, dado que Windows não é sensível ao caso, ao contrário do UNIX. Veja a página demanual 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 especificaros 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: osdiretórios pessoais dos usuário, feito na seção homes e as impressoras, feito na seçãoprinters. A Tabela 6.2 apresenta as principais opções utilizadas no compartilhamento dearquivos ou impressoras.
Tabela 6.2: Opções de Compartilhamento no SAMBA
Opção Descrição
comment Descrição do compartilhamentobrowseable Especifica se o compartilhamento é visualizado na lista de itens compartilha-
dos. Também é reconhecido como browsable
writeable Habilita escrita no dispositivo a quem de direito. Possui writable comosinônimo
valid users Lista de usuários permitidos a logar-se no recurso. Usa-se %S para o nomedo serviço, o que é feito na seção homes.
create mode Também pode ser escrito create mask e especifica a permissão padrãodos arquivos criados
directory mode Idem ao create mode, porém aplicado a diretórios. Também pode ser es-crito directory mask
path Caminho em disco do serviço compartilhadoguest ok Também pode ser escrito como public, habilita acesso público (sem senha)
ao compartilhamento, muito útil para compartilhamento de impressorasprintable Habilita impressão no compartilhamentoread only Especifica o compartilhamento como apenas de leiturawrite list Lista os usuários que tem acesso de escrita e leitura ao compartilhamentoread list Lista os usuários que tem acesso apenas de leitura ao compartilhamento
64 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
Obviamente, existem vários outros itens e observações a serem feitas sobre o servi-dor SAMBA. Entretanto, espera-se que esta seção contenha os elementos básicos para oadministrador instalar e configurar corretamente um servidor SAMBA. Maiores detalhes eoutras opções podem ser consultadas na documentação (incluindo páginas de manual evá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 deconfiguração dos servidores de impressão Linux (incluíndo-se CUPS e LPRng). O acesso adiretórios compartilhados pode ser feito através do aplicativo smbclient que permite aces-sar o recurso com uma interface semelhante ao ftp. Também é possível usar o comandosmbmount para montar compartilhamentos em um diretório específico.
A forma mais prática, entretanto, é utilizar o comando mount com a opção de sistemade 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 passa-das o usuário e a senha para acessar o recurso. É possível também adicionar uma linhano arquivo /etc/fstab para facilitar o processo de montagens, quando isso ocorre comfreqüência. Consulte (UCHÔA, 2007) para maiores detalhes sobre montagem de dispositi-vos.
7SERVIÇ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 funcionamentode um dado ambiente computacional. Nessa categoria, inserem-se informações comonomes de máquinas, dados de contas de usuário, entre outros.
Informações de Aplicativos: referem-se a informações compartilhadas por determinadasaplicações. Sistemas comerciais, como cadastros de clientes, produtos ou fornecedo-res, costumam utilizar-se desse tipo de informação compartilhada.
Informações Pessoais: referem-se a informações compartilhadas sobre os usuários desistema. 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 infor-mações sistemas, destacando-se os serviços de DNS, NIS e LDAP, que podem ser classi-ficados como serviços de diretórios. Serviços de Banco de Dados e finger também sãoabordados, 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áquinainterna a uma dada rede é uma tarefa complicada, o que se pode dizer dos provedores deserviço na internet? Para simplificar o acesso a servidores remotos, houve a necessidadeda criação de maneiras de associar nomes a esses números, simplificando o processo de
66 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
memorização. Afinal, ginux.comp.ufla.br é um endereço mais simples de se guardarque 200.131.251.7.
Outra vantagem desse tipo de associação é que isso permite mais facilmente isolarmáquinas de serviços. Assim, por exemplo, o administrador pode ter um servidor WWWem 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çode uma máquina para outra.
Inicialmente essa associação de IPs a máquinas era feita por um arquivo texto, con-trolado de forma centralizada e distribuído a todas as máquinas na ARPANET. Os nomesutilizados não eram hierárquicos e o processo de associar um nome a uma máquina impli-cava em verificar se ninguém no mundo já não havia pego o nome pretendido. A atualizaçãodesse arquivo tomava grande parte da largura de banda da ARPANET e o arquivo estavaconstantemente desatualizado. Esse problema tornava-se cada vez maior com a expansãoda ARPANET.
Em 1983, Paul Mockapetris especifica formalmente o DNS (Domain Name System) em(MOCKAPETRIS, 1983a) e (MOCKAPETRIS, 1983b). Essa especificação foi posterior-mente alterada em (MOCKAPETRIS, 1987a) e (MOCKAPETRIS, 1987b). O DNS especi-fica uma estrutura hierárquica de nomes para máquinas e endereços IPs em uma formadistribuída. Isso implica, a grosso modo, que cada site armazena informações sobre seuscomputadores. Quando uma máquina de um dado domínio necessita do endereço de umamáquina em outro site, há uma troca de informações entre os servidores DNS desses do-mínios.
Nomes podem ser relativos ou absolutos. Nomes relativos são aqueles válidos dentrode um dado domínio. Assim, por exemplo ginux é um nome válido dentro do domíniocomp.ufla.br. Um nome absoluto, por sua vez, distingue a máquina de forma única nainternet. Esse nome absoluto é também chamado de FQDN (Fully Qualified Domain Name– Nome de domínio totalmente qualificado). Assim, ginux.comp.ufla.br. é um nomeabsoluto. 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 den-tro de domínios, semelhante a uma árvore. Assim, uma máquina é, de certa forma, uma “fo-lha” na ramificação produzidas pelos domíníos e subdomínios a que pertence. A Figura 7.1ilustra esse conceito. Nessa figura, tem-se o domínio raiz “.”. Em um segundo nível, tem-sedomí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 computadorestá associado. O nome do computador fica em uma das folhas da árvore. De acordo com
Serviços de Informação em Redes 67
a árvore da Figura 7.1, tem-se que ginux.comp.ufla.br., zeus-pub.kernel.org. ewww.freshmeat.net. são FQDNs válidos.
Abaixo do nível raiz “.”, encontram-se os domínios genéricos de alto nível. Os domíniosmais 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çasrecentes na política de nomes atribuíram que esses domínios são globais por natureza. Oquinto 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.
.
ww
wrp
mfin
d
.net
.spe
akea
sy.fr
eshm
eat
kern
el
zeus
−pu
b
debi
an
ww
w
linux
ww
w
.org
.com
.red
hat
.sla
ckw
are
ww
ww
ww
.ufla
.com
p
.br
.uni
cam
p.c
om
ober
on.c
onec
tiva
barn
eygi
nux
ftp
Figura 7.1: Árvore DNS
Além dos domínios apresentados na Tabela 7.1, também são utilizados domínios as-sociados aos países. Nesse caso, adota-se o código de duas letras definidos na ISO-3166. 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 re-lação dos domínios de países mais comuns é apresendado na A Tabela 7.2.
68 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 organizações e companhias comerciaisorg organizações não comerciaisnet gateways e provedoresedu instituições educacionaisarpa âncora para árvore de endereços IPmil intituições militaresint organizações internacionaisgov agências governamentais
Tabela 7.2: Domínios de Países
Domínio País
au Austráliaca Canadábr Brasilde Germanyfi Finlândiafr Françajp Japãose Suéciach Suíçahu Hungrianl Holandauk Reino Unidous Estados Unidos
Algumas observações importantes se fazem necessárias. Em geral, os países adotamcomo subdomínios aqueles apresentados na Tabela 7.1. No Brasil, isso é parcialmente ver-dadeiro, uma vez que se adota .com.br, .org.br e .gov.br. Entretanto, as instituiçõeseducacionais, 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 quecada país é livre para organizar a árvore de DNS abaixo de seu domínio.
Serviços de Informação em Redes 69
Por razões históricas, o domínio .us ainda não é muito utilizado. Mas dado seu baixocusto (ou mesmo gratuidade) frente a domínios globais, é de se esperar que ele se difundaainda mais. Alguns domínios de países tem sido utilizados fora desses países. Isso ocorreporque o domínio associado a esses países são extremamente atrativos para determinadosgrupos. Exemplos de domínios desse tipo são o .to, .tm e .tv. Consulte a ISO-3166 parasaber 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álidosna 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 dessetipo é ilustrado na Figura 7.2. Como se vê nessa figura, a cada IP é associado um ou maisnomes.
127.0.0.1 localhost localhost.localdomain
202.231.25.1 servidor1.tuix.com.br www mail
202.231.25.2 servidor2.tuix.com.br ftp
192.168.0.1 maq01.tuix.com.br maq01
192.168.0.2 maq02.tuix.com.br maq02
192.168.0.3 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 nomesde máquinas serão resolvidos. Essa resolução de nomes é feita pela biblioteca resolver,principalmente pelas rotinas gethostbyname() e gethostbyaddr(). As funções deresolução lêem os arquivos de configuração do sistema que informam onde consultasde 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 desejadapara a consulta de nomes. A Figura 7.3 ilustra um exemplo desse arquivo. Nesse exem-plo, 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, emestações sem uso de NIS, recomenda-se a configuração order hosts,bind. A título deinformação, o nome do servidor DNS mais utilizado é o BIND, donde esse valor para DNSno /etc/host.conf. Observe que NIS será visto mais à frente, neste mesmo capítulo.
70 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, comoilustrado 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 poderosoe flexível para configuração de resolução de nomes. O conceito de serviços de nomes foiextendido para incluir uma variedade maior de informações. Configurações para diferentesbases 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 paraobtenção de informações de sistema. A Figura 7.4 apresenta um exemplo de um arquivo/etc/nsswitch.conf.
passwd: files ldap nisplus
shadow: files ldap nisplus
group: files ldap nisplus
hosts: files nisplus dns
networks: files
protocols: files nisplus
rpc: files
services: 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, emgeral, a forma:
informação: base1 base2 ...
Serviços de Informação em Redes 71
As informações compartilhadas com freqüência são listadas na Tabela 7.3. Os tipos debases utilizadas, por sua vez, são listadas na Tabela 7.4. Para maiores detalhes, consultea 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 é igno-rada
group grupos de usuáriospasswd dados de usuáriosshadow senhas de usuárioshosts nomes e endereços de máquinasnetworks nomes e endereços de redesprotocols nomes de protocolosrpc nomes e números de chamadas de procedimentos remotos (rpcs)services serviços de redesbootparams parâmetros de inicialização do sistema
Tabela 7.4: Bases Utilizadas no /etc/nsswitch.conf
database Descrição
files arquivos locaisdb base de dados localnisplus ou nis+ NIS+ (NIS versão 3)nis ou yp NIS, também chamado de YP (NIS versão 2)compat NIS em modo de compatibilidadehesiod Hesiod é um serviço de compartilhamento de informações baseado no BINDdns usa o DNS para serviços de nomes
Quando se configura a biblioteca resolver para utilizar o DNS para resolução de no-mes, é 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 es-senciais ao bom uso do sistema. A diretiva search informa quais os domínios que podemser anexados automaticamente a uma busca. Assim, caso seja feita uma busca para amáquina pt01 e não for encontrada resposta, automaticamente essa busca será estendidapara 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.
72 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 (BerkeleyINternet Domain service). BIND foi criado em 1985 por Kevin Dunlap e é mantido atual-mente 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 RFC1034 (MOCKAPETRIS, 1987a) e RFC 1035 (MOCKAPETRIS, 1987b). Entretanto, váriasoutras RFCs mais recentes adicionaram novas funcionalidades ao serviço, o que pode serverificado com facilidade em http://www.rfc-editor.org/. O servidor de nomes doBIND é o named.
Um servidor named pode operar de diversas formas em uma dada zona. Uma zona é umdomí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”, ondedeveria ser usado o termo “zona”. Um mesmo servidor named pode exercer diferentespapéis em diferentes zonas. A Tabela 7.5 apresenta uma taxionomia de servidores denomes com relação a uma dada zona. Optou-se, nessa tabela, por manter os termos emlíngua inglesa, para simplificar o processo de compreensão da configuração de um servidornamed.
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 odomínio. Cada zona tem um servidor mestre, que mantém os dados em arquivo. A alteraçãode 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ésde um processo denominado “transferência de zonas” (zone transfers). Uma zona pode terinúmeros servidores escravos e deveria ter ao menos um. Um servidor stub é um tipo es-pecial de servidor slave que apenas copia dados de nomes de servidores. Já um servidorcaching apenas lê o endereço de servidores para o domínio raiz e faz cache das respostasdas consultas a que é submetido. Esse tipo de servidor não possui dados e, portanto, nãotem autoridade sobre nenhuma zona. Observe que servidores mestres e escravos têm au-
1ISC: http://www.isc.org/
Serviços de Informação em Redes 73
Tabela 7.5: Taxionomia de Servidores de Nomes
Tipo de Servidor Descrição
authoritative representante oficial de uma zonamaster repositório primário dos dados de uma zona, obtendo os dados
de um arquivoslave copia seus dados de um servidor mestrestub similar ao slave, mas copia apenas o nome do servidor (não
copiando dados de máquinas)distribution um servidor que é visível apenas dentro de um domínionoauthoritative responde uma consulta do cache sem saber se o dado ainda é
válidocaching armazena dados de consultas anteriores; geralmente não possui
zonas locaisforwarder faz consultas em nome de vários clientes, construíndo um
grande cacherecursive faz consulta em seu próprio nome até que possa retornar uma
resposta ou um errononrecursive recorre a outro servidor se não pode responder uma consulta
toridade sobre suas próprias zonas, mas não para informações que armazenam de outrosservidores.
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 (geral-mente no diretório /var/named). O arquivo named.conf consiste de uma série de de-clarações, cada uma terminada por um ponto-e-vírgula. Informações nesse arquivo sãoagrupadas, dentro de um contexto específico, pelo uso de chaves. A Figura 7.6 apresentaum 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 ser-vidor de nomes através do uso de seções. Cada seção especifica uma funcionalidade doservidor. As opções usadas são descritas na Tabela 7.6. Comentários podem ser feitoscomo 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 corretaconfiguração do named. Elas serão descritas em mais detalhes a partir de agora, tomando-
74 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 aconfiguraçã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 oarquivo de configuração seja dividido em vários outros arquivos, especialmente útil em ser-vidores cujo arquivo de configuração seja relativamente grande. A segunda e melhor fun-cionalidade é 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 parauso em autenticação.
Opções gerais do servidor são configuradas na seção options. Atualmente, mais de50 opções estão disponíveis. As mais importantes são listadas na Tabela 7.7. À opçãodirectory geralmente é atribuído o valor /var/named, como exemplifica a Figura 7.6.
Serviços de Informação em Redes 75
Tabela 7.6: Seções Usadas no /etc/named.conf
Seção Funcionalidade
include inclui um arquivooptions opções padrões do servidorserver especifica as configurações de um servidor remotokey define informações de autenticaçãoacl especifica lista de controle de acessozone configura uma zonatrusted-keys chaves pré-configuradascontrols define canal usado para controlar o servidorlogging especifica categorias de logs e seus destinosview 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 confiarnesse recurso como proteção contra ataques
directory especifica o caminho absoluto utilizado pelo named
forwarders especifica uma lista de servidores para consultas externasnotify especifica se o servidor mestre deve notificar alterações a servidores escra-
vosalso-notify especifica uma lista extra de servidores (não necessariamente escravos)
para notificaçãorecursion habilita recursão (o servidor irá fazer consultas em nome dos clientes a ou-
tros servidores)files especifica o número máximo de arquivos que podem ser abertos pelo namedlisten-on espefica a porta e a interface onde named irá escutar as consultasallow-query lista os IPs das máquinas que podem consultar o servidorallow-transfer lista os IPs das máquinas que podem efetuar transferências de zonasblackhole lista servidores aos quais não irá repassar consultas
A opção forwarders, também exemplificada na Figura 7.6, é útil em servidores de zo-nas que são subdomínios de outros servidores locais. Toda consulta a qual o servidor localnã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
76 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
mais leves. Observe que para um forwarder valer a pena, é essencial que ele possa seracessado rapidamente pelo servidor local.
Quando se utiliza servidores de nomes escravos, a opção notify serve para informarao servidor mestre para notificar servidores escravos sempre que houver alteração nosdados das zonas pelas quais é responsável. A configuração padrão é ter a notificaçãoativa, o que é desejável na maioria dos casos. Caso se queira notificar também servidoresnã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 adicionalde segurança ao servidor DNS. Com allow-query, é possível especificar quais máquinaspodem utilizar o servidor para consultas de nomes. Já allow-transfer informa quais osservidores escravos que podem fazer transferência de zonas. Se não especificados, entãoa permissão é dada a todos os computadores na internet. A especificação pode ser feita daseguinte forma:
allow-query {ip1; ip2; ...; ipn;};
onde ip1 pode tanto ser o endereço IP de uma máquina que pode usar o servidor DNSpara 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 utilizaro 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 permitea configuração de inúmeros itens do servidor named. Recomenda-se uma olhada na páginade manual do named.conf para maiores detalhes.
A seção acl permite especificar um conjunto de endereços para utilização em opçõesdo 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 únicapassada. Assim, a declaração de um acl deve vir antes de seu uso. Além disso, algumas
Serviços de Informação em Redes 77
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 (paraas 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. Nes-sas seções, são configuradas as zonas que o servidor de nomes tem acesso. A Figura 7.7apresenta 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 uti-lizadas em zonas, como notify, forwarders, allow-query e allow-transfer. Aconfiguração dessas opções já foi abordada na seção anterior. A opção path permite quese 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 daFigura 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 acordocom o já discutido na Seção 7.2.2. O leitor não deve encontrar dificuldades para a configu-ração de servidores tipo master, slave e stub. Uma observação é que, para a configu-ração de DNS reverso, utiliza-se uma zona cuja raiz é “.IN-ADDR.ARPA”, como mostra aFigura 7.6.
Por DNS reverso, compreende-se a tarefa de descobrir qual o nome associado a umdado IP. Observe que nesse caso, o IP da rede é escrito de forma que a parte mais signifi-cativa está mais próxima da raiz. Assim, por exemplo, a rede 233.222.111 teria associadaa ela a zona 111.222.233.in-addr.arpa.
78 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 osforwarders sejam outros servidores que não os padrões.
Para acessar zonas sobre as quais o servidor não tem conhecimento, o servidor namedprecisa conhecer os servidores padrões para o domínio raiz (o domínio “.”). Isso é feitoatravé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á listaros 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 arquivoslocais para configuração (ou cache, no caso de um servidor escravo) das zonas sobreas quais o servidor tem autoridade. Como já comentado, esses arquivos costumam serarmazenados no diretório /var/named. Esses arquivos consistem a base de dados dessaszonas. A Figura 7.8 e a Figura 7.9 apresentam exemplos de arquivos de configuração deDNS direto e reverso, respectivamente.
O arquivo da base de dados contém dois tipos de entradas: comandos de parser eregistros de recursos. Os comandos de parser são diretivas globais para o named no que serefere à zona do arquivo em questão. Essas diretivas iniciam-se com o caracter “$”. Existemquatro diretivas: ORIGIN, TTL, INCLUDE e GENERATE. Dessas, as mais importantes sãoas duas primeiras.
Quando da configuração de uma máquina na base DNS, o named adiciona aos nomesque 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 estejaconfigurado no arquivo de configuração, as máquinas da Figura 7.8 terão adicionados azona comp.ufla.br. em seus nomes.
A diretiva TTL, por sua vez, configura o tempo de vida padrão dos registros da base emquestão. Esse tempo de vida, em segundos, especifica o tempo que o dado em questãopode 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 79
$TTL 86400
$ORIGIN comp.ufla.br.
@ IN SOA assembly.comp.ufla.br root.comp.ufla.br (
2003022801 ; serial (d.adams)
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
@ IN NS assembly
@ IN MX 5 assembly
ansi_c IN A 200.131.251.2
assembler IN A 200.131.251.3
assembly IN A 200.131.251.1
assembly IN MX 5 assembly
awk IN A 200.131.251.9
bash IN A 200.131.251.7
ftp IN CNAME awk.comp.ufla.br.
ginux IN CNAME bash.comp.ufla.br.
www.ginux IN CNAME bash.comp.ufla.br.
ftp.ginux IN CNAME bash.comp.ufla.br.
www IN 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 queoutros servidores possam demorar a atualizar as informações (em cache) sobre essas zo-nas. Recomenda-se que a configuração desse valor seja próxima do prazo com que asinformações são alteradas na base.
Configurada as diretivas, se for o caso, deve-se passar à configuração dos registrosDNS 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 oudomí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.
80 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
$TTL 86400
@ IN SOA assembly.comp.ufla.br. root.comp.ufla.br. (
2003012201 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ; default_ttl
)
@ IN NS assembly.comp.ufla.br.
1 IN PTR assembly.comp.ufla.br.
2 IN PTR ansi_c.comp.ufla.br.
3 IN PTR assembler.comp.ufla.br.
7 IN PTR bash.comp.ufla.br. ;ginux
9 IN 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 Bindsendo utilizada. Hesiod, por sua vez, é um serviço de informação equivalente ao NISque é 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. Utilizando-se 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 arquivonamed.conf ou na diretiva ORIGIN). Tem-se que a classe desse registro é internet (IN).
Serviços de Informação em Redes 81
Tabela 7.8: Tipos de Registros DNS
Tipo Nome Função
Registros de ZonaSOA Start of Autority Define uma zona de autoridade DNSNS Name Server Indica um servidor de nomes e delega autoridade
Registros BásicosA IPv4 Address Atribui um IP a um nome (DNS Direto)A6 IPv6 Address Atribui um IPv6 a um nomePTR Pointer Atribui um nome a um IP (DNS Reverso)MX Mail Exchanger Controla rota de e-mail
Registros de SegurançaKEY Public Key Chave pública para um nome DNSSIG Signature Assinatura para zona autenticada
Registros OpcionaisCNAME Canonical Name Apelido (nome alternativo) de uma máquinaSRV Services Indica localização de serviços mais conhecidosTXT 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 respon-sável por ela. Observe que no e-mail, ao invés do @, utiliza-se ponto, dado o significadodo @ 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. Podeser qualquer valor inteiro incremental, mas geralmente adota-se um formato que indiquea data da alteração da base. Assim, 2003022803 significa a terceira alteração do dia 28de fevereiro de 2003. Recomenda-se o uso dessa estratégia. Observe que se a basefor alterada e não for alterado o serial, os servidores escravos não serão informados daalteração e manterão a base antiga.
O parâmetro refresh indica de quanto em quanto tempo os servidores escravos devemchecar o servidor mestre em busca de alterações. O parâmetro retry indica quanto tempoapós uma tentativa o servidor escravo deve tentar uma reconexão ao servidor mestre. Naausência do servidor mestre, o servidor escravo irá assumir o domínio por um prazo máximoestabelecido no parâmetro expire. O parâmetro minimum, por sua vez informa a outrosservidores qual o TTL para respostas negativas do DNS. Recomenda-se valores superioresa quatro horas para evitar sobrecarga na rede.
82 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 é feitacom 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 auma 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, usadopara 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 dadodomínio. O uso de registro MX facilita o roteamento de e-mail entre domínios. Para DNSreverso, utiliza-se registros do tipo PTR, ilustrado na Figura 7.9 que possui sintaxe muitopróxima a um registro do tipo A, invertendo-se a ordem do endereço com o nome apenas esubstituí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 83
# 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. IN A
;; ANSWER SECTION:
ginux.comp.ufla.br. 86346 IN CNAME bash.comp.ufla.br.
bash.comp.ufla.br. 86346 IN A 200.131.251.5
;; AUTHORITY SECTION:
comp.ufla.br. 86400 IN NS assembly.comp.ufla.br.
;; ADDITIONAL SECTION:
assembly.comp.ufla.br. 86400 IN A 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 deconfiguração. Nesse caso, pode ser interessante fazer com que esses perfis sejam com-partilhados de alguma forma. Isso é verdadeiro principalmente com relação às informaçõesarmazenadas nos arquivos passwd, shadow, group, hosts, services e aliases nodiretório /etc. Para o compartilhamento desse tipo de informação, duas abordagens sãopossíveis:
1. Manter uma cópia matriz da configuração em algum servidor e distribuí-la às máquinasque precisam estar de acordo com esse perfil.
84 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 qual-quer ambiente UNIX. Para isso, basta fazer uso de estratégias baseadas em NFS ou nosaplicativos rdist, rsync ou expect. Também não é complicado a um programador inter-mediário em C/C++ construir um mini-servidor para envio dos arquivos de configuração deum 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 utilizaralgum sistema de compartilhamento de informações em rede, como NIS ou LDAP. Uma dasdesvantagens dessa abordagem é que as estações ficam dependentes do servidor parafuncionar adequadamente. Mas com certeza a maior desvantagem dessa estratégia é ofato de que no momento os sistemas de compartilhamento de informação possuem sériasdeficiências, como será visto mais à frente.
O primeiro sistema de compartilhamento de informações é o NIS (Network InformationSystem), 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 existemprofissionais que usam esse termo para o NIS. Por causa desse motivo, a maioria dosaplicativos 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 redepode se tornar o servidor de um dado domínio, enviando dados não-confiáveis a clientesNIS. 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 umambiente NIS. Em resumo: se o administrador está preocupado com segurança ele nãodeve usar NIS. Isso é principalmente válido em um ambiente de compartilhamento de dadosde usuários, onde seria mais útil. Por esses motivos, este texto não irá abordar o uso econfiguração de NIS.
Uma alternativa mais promissora ao NIS é o LDAP (Lightweight Directory Access Pro-tocol). LDAP é uma implementação do serviço de diretório X.500. Um serviço de diretóriopossui semelhanças com serviços de bancos de dados, mas otimizado para busca de in-formações relativamente pequenas e simples. Assim, um serviço de diretório possui asseguintes características:
• dados armazenados são relativamente pequenos;
• informações são baseadas em atributos;
Serviços de Informação em Redes 85
• 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 compartilhamentode informações em rede. Em (DOMINGUES; SCHNEIDER; UCHÔA, 2001), podem ser vis-tas instruções de uso do LDAP para autenticação de usuários, usando SSL no tráfego dedados. Esse artigo é baseado em experiências no laboratório de computação do DCC/U-FLA. Entretanto, em implementações mais recentes, usando-se a mesma estratégia nãofoi possível utilizar SSL com LDAP para autenticação. Em partes isso ocorre porque LDAPainda é 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 menosque o administrador realmente precise desse tipo de serviço, recomenda-se um pouco maisde espera até que o uso de LDAP esteja mais fácil. O administrador, entretanto, deve estaratento, pois essa tecnologia promete bastante funcionalidade para o compartilhamento deinformaçõ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 dis-poníveis publicamente, ele sofre dos mesmos problemas do NIS: mesmo que se consigaconfigurar uma zona segura, a segurança de uso de senhas sombreadas é perdida. Ob-serve que Hesiod não foi pensado originalmente para autenticação distribuída e sim paracompartilhar outros tipos de informação.
Informações básicas sobre usuários em uma rede pode ser fornecido com o servidorfingerd. Esse serviço permite compartilhar em rede informações básicas sobre um dadousuário. Em geral, esse serviço deve ser configurado para impedir seu uso por usuáriosexternos à rede interna. Caso contrário, essas informações poderão ser usadas para ob-tenção de logins de usuários para uso em tentativas de invasão ou envio de SPAM. Aconfiguraçã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 dentrode 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áriasinformações como, por exemplo:
86 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 é uti-lizar um servidor DHCP para compartilhar as três primeiras. Para Linux, existem doisclientes: 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 configu-ração, como netconfig ou linuxconf. De qualquer forma, basta-se editar o arquivo/etc/sysconfig/network-scripts/ifcfg-eth0, ou o relacionado à interface queserá usada, modificar o parâmetro BOOTPROTO para o valor dhcp e remover as entradasIPADDR, NETMASK, NETWORK e BROADCAST desse arquivo. Além disso, deve-se removeras entradas HOSTNAME e GATEWAY do arquivo /etc/sysconfig/network.
Antes de instalar um servidor DHCP, o administrador deve pesar os prós e contras dessatecnologia. Com o uso normal do DHCP, qualquer usuário pode plugar uma máquina narede e fazer uso dela. Assim, na forma de uso mais comum do DHCP, o administrador podemais 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 útilquando há mais máquinas que IP em uma dada rede, mas nem todas as máquinas estãoligadas 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 exemplodesse arquivo é ilustrado na Figura 7.11. A configuração ilustrada nesse arquivo faz comque 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 eos servidores de nomes são as máquinas com IP 192.168.1.1 e 192.168.1.2. Alémdisso, o domínio utilizado pela máquina será o mydomain.org. O servidor WINS utilizadonessa 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 entre192.168.1.10 e 192.168.1.100 e entre 192.168.1.150 e 192.168.1.200. Alémdisso, como mostra essa mesma figura, é possível usar o DHCP para atribuir automatica-mente um endereço específico a uma dada máquina. No caso, a máquina com placa derede possuidora do endereço MAC 08:00:2b:4c:59:23 receberá o nome dbowie e oendereço 192.168.1.111.
Serviços de Informação em Redes 87
# 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 derede. 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. Noteque o endereço MAC de uma dada máquina host1 pode ser verificado através do comandoarp -a host1.
7.5 SERVIDORES DE BANCOS DE DADOS
Existem vários servidores de bancos de dados (SGBDs) para Linux. Entre os comer-ciais, o destaque recai para o Oracle. Entretanto existem alternativas gratuitas de grandequalidade, como o PostgreSQL ou o Firebird (implementação gratuita do Interbase). Entreos gratuitos, o PostgreSQL possui a mais poderosa implementação, suportanto inclusiveconstruções básicas orientadas a objetos. Além disso, possui suporte a triggers e tran-sações. O Firebird vem crescendo aos poucos sua participação no mercado de softwarelivre.
88 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
Um outro SGBD muito usado é o mySQL, relativamente mais rápido para consultasmais simples, mas sem suporte a transações. Para uso em bases mais simples (como deconsultas na internet), o mySQL pode ser a melhor escolha. Caso pretenda-se algo maiselaborado ou poderoso, a escolha deve recair preferencialmente sobre o PostgreSQL. OFirebird é uma alternativa atraente aos que já trabalham com o Interbase e também é umaboa escolha.
A configuração de um SGBD depende de qual será o servidor adotado. Assim, cada umdesses servidores possui configurações e ferramentas próprias. Em geral, essas ferramen-tas permitem: criar e remover bases de dados, criar e remover usuários para acessar asbases, fazer cópia de segurança e restauração de dados. Em geral, os servidores (princi-palmente 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 con-figuração de SGBDs em Linux.
8SERVIDORES DE ACESSO REMOTO
8.1 COMENTÁRIOS INICIAIS
Uma das maiores vantagens do UNIX sobre outros sistemas operacionais é a possi-bilidade de execução de comandos de forma remota. Somente recentemente o Windows2000 incorporou um recurso semelhante (o Windows Terminal Server), mas sem a mesmafuncionalidade 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 oserviço de Telnet é inseguro, esta apostila não irá entrar em detalhes sobre ele. O serviçode SSH, entretanto é abordado na Seção 8.2. Observe que o SSH oferece os mesmosserviços do Telnet, porém de forma criptografada.
Além do SSH, esse capítulo também aborda os conceitos básicos necessários paraconfiguraçã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 imple-mentação utiliza a OpenSSL para fazer o tunelamento criptográfico de dados. Uma outraversão muito usada é disponibilizada em http://www.ssh.com/, gratuita para fins nãocomerciais. Os autores deste texto recomendam o uso do OpenSSH.
Uma vez instalado o OpenSSH, sua configuração é relativamente simples. Os arquivosde configuração ficam no diretório /etc/ssh. Além dos arquivos de configuração, essediretó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
90 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 verdadeiroreside 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 seguinteforma:
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 seudiretó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 ma-nual. Assim, esta seção irá abordar apenas a configuração global, uma vez que a sintaxedo arquivo de configuração pessoal é idêntica. A Figura 8.2 mostra um exemplo de con-figuração global do ssh. Nesse arquivo, o trecho comentado refere-se às configuraçõespadrões.
Note, no exemplo da Figura 8.2, a habilitação de execução de aplicações gráficas remo-tas para todas as máquinas, com o uso da diretiva ForwardX11 habilitada. Note também
Servidores de Acesso Remoto 91
que, por padrão, é habilitado autenticação por senha ou por chave RSA. Mais detalhespodem 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çõesnão ilustradas nessa figura, apenas as mais importantes. Observe que foi habilitado aexecução remota automática de aplicações gráficas e o servidor sftp (Secure FTP), umaalternativa mais segura ao serviço de FTP.
Uma vez habilitado o serviço de sftp, os usuários do sistema podem utilizar os coman-dos scp e sftp para transferência de arquivos. Consulte as páginas de manuais dessescomandos para maiores detalhes.
92 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-sehabilitar o PPP para receber chamadas remotas. Observe que isso é feito pelo pppd, omesmo 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 clientee a de servidor é feita pelo mesmo aplicativo. Recomenda-se, nesse caso, a leitura doPPP-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 deacesso dos usuários, o que é feito geralmente com o uso do protocolo RADIUS (RemoteAuthentication 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 excelentedocumentação orientando sua configuração e uso, sendo recomendada sua leitura por ad-ministradores interessados.
1http://www.tldp.org/HOWTO/PPP-HOWTO/index.html
REFERÊNCIAS BIBLIOGRÁFICAS
ANONYMOUS. Maximum Linux Security: A Hacker’s Guide to Protecting Your Linux Serverand 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 sistemasLinux usando OpenLDAP. In: Semac2001 - XII Semana da Computação - IV Workshopem 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 LinuxDocumentation Project [WWW]. URL: http://www.ibiblio.org/pub/Linux/docs/HOWTO/NIS-HOWTO. Disponível em: <http://www.tldp.org/pub/Linux/docs/HOWTO/NIS-HOWTO>.
MANN, S.; MITCHELL, E. L. Linux System Security: An Administrator’s Guide to OpenSource Security Tools. New Jersey: Prentice-Hall, 2000.
MOCKAPETRIS, P. Domain Names – Concepts and Facilities. Internet EngineeringTask Force (IETF), Novembro 1983. (Request for Comments: 882). URL: http://www.ietf.org/.
MOCKAPETRIS, P. Domain Names – Implementation and Specification. InternetEngineering Task Force (IETF), Novembro 1983. (Request for Comments: 883). URL:http://www.ietf.org/.
94 EDITORA - UFLA/FAEPE - Serviços de Redes em Linux
MOCKAPETRIS, P. Domain Names – Concepts and Facilities. Internet EngineeringTask Force (IETF), Novembro 1987. (Request for Comments: 1034). URL: http://www.ietf.org/.
MOCKAPETRIS, P. Domain Names – Implementation and Specification. InternetEngineering 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 dePós Graduação “Lato Sensu” (Especialização) a Distância em Administração em RedesLinux).
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çãoem Redes Linux).
WIRZENIUS, L.; OJA, J.; STAFFORD, S. The Linux System Administrator’s Guide; Version0.7. [S.l.]: The Linux Documentation Project, 2001. URL: http://www.tldp.org/guides.html.