Linux Network Administration COMPLETA

Linux NetworksAdministration

www.3way.com.br

Apostila

Linguagem de Programação Java

Seja um Profissional Aprendendo com Profissionaiswww.3way.com.br

12

//atribuindo valor a variável referênciaCarro carro1 = new Carro();carro1.ano = "2001";carro1.modelo= "fusca";carro1.cor = "prata";

Figura 2.4 – Layout Memória após inicialização

//criando novo aliasCarro carro2 = carro1;

Figura 2.5 – Layout Memória duas variáveis referência para o mesmo objeto

2.3 Membros de InstânciaCada objeto criado deverá ter sua própria instância de variáveis

(atributos) definidas pela classe. Os métodos definem o comportamento de umobjeto. Isto é importante, pois denota que um método pertence a cada objeto daclasse. Porém não devemos confundir isto com a implementação do método, queé compartilhada por todas as instâncias da classe.

2.3.1 Invocação de MétodosObjetos se comunicam pela troca de mensagens, isto significa que um

objeto pode ter que mostrar um comportamento particular invocando umaoperação apropriada que foi definida no objeto. Em Java, isto é feito pelachamada de um método em um objeto usando o operador binário "." (ponto),devendo especificar a mensagem completa: o objeto que é o recebedor damensagem, o método a ser invocado e os argumentos para o método (se houver).O método invocado no recebedor pode também enviar informações de volta aoobjeto chamador através de um valor de retorno. O método chamado deve serum que esteja definido pelo objeto.

Os valores das variáveisem um objeto constituem

o seu estado.Dois objetos distintos têmo mesmo estado se suasvariáveis membro têm os

mesmos valores.

2Todos os direitos reservados a 3Way Networks

Linux Network Administration

Este material não pode ser distribuído. Somente poderá ser utilizado por alunos da 3Way Networks.

www.3way.com.br

Seja um Profissional Aprendendo com Profissionais 1

Sumário Convenções ......................................................................................................................................... 6

Legendas........................................................................................................................................... 6 Cenário ............................................................................................................................................. 6

1. Redes TCP/IP ................................................................................................................................. 8 1.1. Introdução ................................................................................................................................. 8

1.1.1. TCP/IP ................................................................................................................................ 8 1.2. Conceitos básicos ...................................................................................................................... 9 1.3. O protocolo IP ......................................................................................................................... 11 1.4. O Protocolo TCP ..................................................................................................................... 11 1.5. Protocolos de rede ................................................................................................................... 12

1.5.1. O modelo OSI .................................................................................................................. 13 1.5.2. Modelo TCP/IP ................................................................................................................. 14

1.6. O Endereço IP ......................................................................................................................... 16 1.7. Classes de Endereçamento IP .................................................................................................. 16 1.8. Endereços de Rede e Broadcast .............................................................................................. 17 1.9. Máscara de rede ....................................................................................................................... 18 1.10. Sub-rede ................................................................................................................................ 18 1.11. Endereços IP para redes privadas .......................................................................................... 21 1.12. O Número de Porta ................................................................................................................ 21 1.13. Roteamento ........................................................................................................................... 21 1.14. DNS ....................................................................................................................................... 22 1.15. Arquivos Gerais .................................................................................................................... 22 1.16. Configuração TCP/IP ........................................................................................................... 23

1.16.1. Hostname ........................................................................................................................ 23 1.16.2. Interface de Rede ............................................................................................................ 24 1.17.3. Configuração das rotas ................................................................................................... 26 1.17.4. Resolução de Nomes ...................................................................................................... 28

1.18. Inetd / Xinetd ......................................................................................................................... 28 1.19. Utilitários de redes ............................................................................................................... 31

1.19.1. host ................................................................................................................................. 31 1.19.2. netstat ............................................................................................................................. 31 1.19.3. tcpdump .......................................................................................................................... 32 1.19.4. traceroute ........................................................................................................................ 33 1.19.5. nmap ............................................................................................................................... 33

1.20. Laboratório ........................................................................................................................... 35 1.21. Exercícios ............................................................................................................................. 37

2. Servidor SSH ................................................................................................................................ 39 2.1. Instalação e configuração ........................................................................................................ 39 2.2. Laboratório ............................................................................................................................. 40 2.3. Exercícios ................................................................................................................................ 41

3. Sistema de Nomes de Domínio .................................................................................................... 42 3.1. Serviços de Nomes - DNS ...................................................................................................... 42 3.2. Instalação do BIND ................................................................................................................. 43

3.2.1. Instalação código fonte ..................................................................................................... 43 3.2.2. Instalação automatizada .................................................................................................... 44

3.3. Hierarquia DNS ....................................................................................................................... 44 3.3.1 Hierarquia de Consultas DNS ........................................................................................... 45



www.3way.com.br
















Curso Especialista em [email protected] | (62) 3232 9333

666888910111113151616171718202222222324242526282832323233343436394141424345454646474748



12











mesmos valores.




www.3way.com.br


3.3.2. Cache de consultas ........................................................................................................... 49 3.4. O arquivo named.ca................................................................................................................. 50 3.5. Configurando o cliente DNS ................................................................................................... 51

3.5.1. Definir o servidor de DNS ................................................................................................ 51 3.5.2. Definir a ordem de consulta ............................................................................................. 52

3.6. Zonas e Domínios ................................................................................................................... 53 3.7. Servidores DNS ....................................................................................................................... 54 3.8. Servidor de cache .................................................................................................................... 56 3.9. Servidor primário .................................................................................................................... 59

3.9.1 Registros de Recursos ....................................................................................................... 60 3.9.2 O arquivo de RR ................................................................................................................ 61

3.10. Arquivo da Zona Reversa ..................................................................................................... 64 3.11. Ferramentas de Teste ............................................................................................................. 66

3.11.1. nslookup ......................................................................................................................... 66 3.11.2. dig ................................................................................................................................... 66

3.12. Servidor Secundário .............................................................................................................. 67 3.15. Laboratório ........................................................................................................................... 70 3.16. Exercícios ............................................................................................................................. 74

4. DHCP ............................................................................................................................................ 75 4.1. Protocolo DHCP ...................................................................................................................... 75 4.2 Instalando o DHCP................................................................................................................... 78

4.2.1. Instalação código fonte .................................................................................................... 78 4.2.2. Instalação automatizada .................................................................................................... 78

4.3. Configuração servidor DHCP ................................................................................................ 79 4.4 Configuração Cliente DHCP ................................................................................................... 82 4.5. Gerenciando Sub-redes ........................................................................................................... 83

4.5.1. Configuração Servidor dhcrelay ....................................................................................... 83 4.5.2. Configuração para gerenciar sub-redes ........................................................................... 84

4.6. Integração DHCP e DNS ......................................................................................................... 85 4.7. Laboratório ............................................................................................................................. 89 4.8. Exercícios ............................................................................................................................... 91

5. NTP ................................................................................................................................................ 92 5.1. Instalação ................................................................................................................................. 93

5.1.1. Instalação código fonte .................................................................................................... 93 5.1.2. Instalação automatizada .................................................................................................... 93

5.2. Configuração ........................................................................................................................... 94 5.3. Ferramentas ............................................................................................................................. 95 5.4. Laboratório ............................................................................................................................. 97 5.5. Exercícios ............................................................................................................................... 99

6. Sistema de Arquivo de rede ....................................................................................................... 100 6.1. Instalação ............................................................................................................................... 100

6.1.1. Instalação código fonte ................................................................................................... 101 6.1.2. Instalação automatizada .................................................................................................. 101

6.2. Autenticação e permissões .................................................................................................... 102 6.3. Montando compartilhamentos NFS ...................................................................................... 102

6.3.1 Montagem automática .................................................................................................... 103 6.4. O servidor NFS ..................................................................................................................... 104 6.6. Laboratório ........................................................................................................................... 108



www.3way.com.br

















5252545455555659616364666868696973777878808181818485858787929495969696979899100102102102103103104105106110



12











mesmos valores.




www.3way.com.br


6.6. Exercícios ............................................................................................................................. 110 7. Samba .......................................................................................................................................... 111

7.1. Visão Geral ............................................................................................................................ 111 7.2. O Protocolo SMB ................................................................................................................. 113 7.3. O protocolo NETBEUI.......................................................................................................... 114 7.4. Instalando o Samba .............................................................................................................. 114

7.4.1. Instalando código fonte ................................................................................................. 114 7.4.2. Instalação automatizada .................................................................................................. 115

7.5. Configuração ......................................................................................................................... 115 7.5.1. Seção global .................................................................................................................. 116 7.5.2. Seção homes ................................................................................................................... 122

7.6. Samba como PDC ................................................................................................................. 123 7.7. Conta de usuário Samba ....................................................................................................... 124 7.8. Conta de máquina Samba ...................................................................................................... 126 7.9. Servidor samba em um domínio........................................................................................... 127 7.10. Compartilhamentos de arquivos .......................................................................................... 128 7.11. Controle de acesso a nível de senha .................................................................................... 129 7.12. Controle de acesso a nível de usuário ................................................................................. 130 7.14. O Utilitário testparm ........................................................................................................... 132 7.15. Script de logon .................................................................................................................... 132 7.16. Servidor Wins ...................................................................................................................... 135

7.16.1. Samba como cliente WINS ......................................................................................... 135 7.16.2. Samba como Servidor WINS ...................................................................................... 136

7.17. Compartilhando Impressoras............................................................................................... 136 7.18. Samba como cliente ............................................................................................................ 137 7.19. Samba no cliente Windows ................................................................................................. 138 7.20. Laboratório ......................................................................................................................... 140 7.21. Exercícios ........................................................................................................................... 143

7. FTP (File Transfer Protocol) ..................................................................................................... 144 7.1. Introdução ............................................................................................................................. 144 7.2. Protocolo FTP ....................................................................................................................... 145 7.3. Instalação ............................................................................................................................... 146


7.4. Usuários FTP ......................................................................................................................... 147 7.5. Firewall e ip_conntrack ......................................................................................................... 148 7.6. Arquivos de log do FTP ........................................................................................................ 148 7.7. Executando o cliente FTP ..................................................................................................... 149 7.8. Laboratório ........................................................................................................................... 152 7.9. Exercícios ............................................................................................................................. 153

8. Servidor Web .............................................................................................................................. 154 8.1. World Wide Web ................................................................................................................... 155 8.2. O Apache ............................................................................................................................... 156 8.3. Instalando o Apache .............................................................................................................. 156


8.4. Protocolo HTTP .................................................................................................................... 157 8.5. Publicação da Home-Page ..................................................................................................... 159



www.3way.com.br

















112113113115115116116116117118123124127128130131131132134134137137137138140141142144145145145146147147147148149149152153154155157157157158158160



12











mesmos valores.




www.3way.com.br


8.6. Configuração do Apache ....................................................................................................... 160 8.7. Laboratório ........................................................................................................................... 167 8.8. Exercícios ............................................................................................................................. 169

9. Servidor de Email ....................................................................................................................... 170 9.1. Servidor de Mensagens ........................................................................................................ 170 9.2. Agentes de mensagens ........................................................................................................... 170 9.3. Instalando o Servidor de Email ............................................................................................. 172

9.3.1. Instalação código fonte .................................................................................................. 172 9.3.2. Instalação automatizada ................................................................................................. 173

9.4. Configuração ......................................................................................................................... 173 9.5. Aliases ................................................................................................................................... 176 9.6. Redirecionamento.................................................................................................................. 177 9.7. Laboratório ........................................................................................................................... 178 9.10. Exercícios ........................................................................................................................... 180

10. Servidor Proxy .......................................................................................................................... 181 10.1. SQUID ................................................................................................................................. 183 10.2. Instalação ............................................................................................................................. 183

10.2.1. Instalação código fonte ................................................................................................ 183 10.2.2. Instalação automatizada................................................................................................ 184

10.3. Configuração ....................................................................................................................... 184 10.3.1. squid.conf ..................................................................................................................... 184 10.3.2. Caching ......................................................................................................................... 185 10.3.3. Restrições de Acesso .................................................................................................... 188 10.3.4. Restrição das redes ....................................................................................................... 189 10.3.5. Restrição por sites......................................................................................................... 190 10.3.6. Restrição por termos em URLs .................................................................................... 190 10.3.7. Autenticação ................................................................................................................. 191

10.4. Proxy Transparente .............................................................................................................. 193 10.4.1. IP Masquerade .............................................................................................................. 194 10.4.2. Proxy Transparente com Squid ..................................................................................... 195

10.5. SARG .................................................................................................................................. 198 10.5.1. Instalação ...................................................................................................................... 198 10.5.2. Configuração ................................................................................................................ 198 10.5.3. Geração de relatórios .................................................................................................... 199

10.6. Laboratório ......................................................................................................................... 200 10.7. Exercícios ........................................................................................................................... 202



www.3way.com.br

















161168171172172172174174175175177178180182183185185185186186186187191191192193193195196197201201201202203205



12











mesmos valores.




www.3way.com.br


CONVENÇÕES LEGENDAS

Este documento possui algumas legendas que ajudam a ilustrar e facilitar o entendimento.

Significa um comentário importante sobre determinado assunto. Acrescenta informação relevante ao tema.

Acrescenta detalhes técnicos que podem fazer diferença no momento de uma implementação ou ser relevantes em exames de certificação.

Apresenta uma linha de comando ou código referente às distribuições RHEL (RedHat Enterprise Linux) e CentOS.

Semelhante ao anterior, porém apresentando códigos ou linhas de comando para as distribuições Debian e Ubuntu.

CENÁRIO

O cenário do curso está baseado em quatro máquinas virtuais, sendo três Linux e uma Windows.

As duas primeiras máquinas Linux fazem parte da rede do laboratório 192.168.1.0/24 e seus IPs (192.168.1.X e 192.168.1.Y) serão definidos pelo instrutor no início do curso, bem como se eles serão endereços fixos ou dinâmicos.

As duas máquinas clientes farão parte da rede 10.0.0.0/24 e seus IPs poderão ser determinados manualmente ou por DHCP, isso vai depender do assunto que está sendo estudado.

A nomenclatura das máquinas vai depender do domínio a ser adotado pelo instrutor para o curso, esse material vai adotar o domínio 3waylocal.net.br. Portanto as máquinas terão os nomes no seguinte formato:

maq<final-do-IP>.3waylocal.net.br Por exemplo para uma máquina que utilize o IP 192.168.1.150 seu nome de host será

maq150.3waylocal.net.br. A figura abaixo ilustra o cenário do curso.




12











mesmos valores.




www.3way.com.br


O ambiente acima será integralmente virtualizado por ferramentas como VirtualBox ou VMWare Server.

A máquina maqX.3waylocal.net.br será muito utilizada no primeiro módulo (Linux System Administrator), já a máquina maqY.3waylocal.net.br será utilizada nos outros dois módulos (Linux Network e Security Administrator) juntamente com as máquinas clientes Windows (10.0.0.W) e Linux (10.0.0.Z).




12











mesmos valores.




www.3way.com.br


1. REDES TCP/IP

Este capítulo é uma introdução aos conceitos do protocolo TCP/IP, tal como

números IP, portas TCP, serviços, roteamento, ferramentas, etc.

1.1. INTRODUÇÃO

1.1.1. TCP/IP

A pilha de protocolos TCP/IP foi originada nos Estados Unidos na ARPANET, uma rede militar americana, e pouco a pouco foi sendo ampliada por centenas de universidades e repartições públicas que foram sendo conectadas a ela através de linhas telefônicas privadas e outros meios de comunicação. Mais tarde essa rede deu origem a grande rede mundial de computadores, a Internet.

O objetivo do TCP/IP era conectar várias redes locais e esse é o motivo de o nome ser Internet (ou seja, inter-redes). Na verdade, o acrônimo TCP/IP refere-se a uma grande família de protocolos que funciona em conjunto para permitir uma comunicação completa que englobam os protocolos TCP, IP e outros como o ARP (Address Resolution Protocol), ICMP (Internet Control Message Protocol), DNS (Domain Name Service) e outros.

O projeto TCP/IP teve sua origem por volta de 1969, porém, esta rede tornou-se operacional somente a partir de 1975 quando sua funcionalidade já estava comprovada. Por volta de 1983, o novo modelo de referência TCP/IP estava completamente padronizado e disponível publicamente, permitindo sua rápida popularização.

Atualmente é utilizada a versão 4 do protocolo, no entanto, a versão 6 já foi concebida para suprir falhas e limitações da versão anterior. Já é possível ver endereçamentos IPv6 em pleno funcionamento e equipamentos que já trabalham com




12











mesmos valores.




www.3way.com.br


essa nova pilha de protocolos. Esse material abordará a versão 4.

1.2. CONCEITOS BÁSICOS

Todo computador em uma rede TCP/IP é denominado host e para entender melhor uma rede, é necessário classificar cada host que a compõe, cada um desenvolve tarefas específicas e variadas dentro desse contexto. Podemos classificá-los como: servidor, cliente, roteador (gateway) e firewall.

O que diferencia um servidor de um cliente é o fato de o primeiro sempre estar aguardando solicitações vindas do segundo ou de outro servidor (neste caso atuando como cliente). Por exemplo, um servidor Web (HTTP) retornará o conteúdo de uma página Web quando algum cliente requisitá-lo.

Cliente/Servidor

Um roteador tem a função de repassar pacotes de uma rede para outra através

da checagem dos endereços de destino. Dentro desta funcionalidade o roteador funciona como uma ligação entre uma rede e outra, portanto geralmente utiliza de tecnologias e protocolos diferentes.

Interligação de duas redes por um roteador

Um firewall é um computador conectado a uma rede local e ao mesmo a




12











mesmos valores.




www.3way.com.br


tempo à uma rede externa. Ele possui a função de filtrar determinados serviços que a rede interna não necessita compartilhar externamente, ou seja, o firewall pode permitir ou negar determinados serviços para uma rede externa.

Filtragem de uma rede interna por fillustração de um firewall filtrando uma rede interna.

A verdade é que, em uma rede TCP/IP, um hospedeiro pode ter a função de

qualquer uma dos itens descritos anteriormente. Um mesmo computador pode ser um servidor para um serviço ao mesmo tempo que atua como cliente de outro e ao mesmo tempo ele pode estar realizando roteamento de pacotes de uma rede para outra.

1.3. O PROTOCOLO IP

O protocolo IP (Protocolo Internet) é a chave da interligação de redes que utilizam tecnologias e hardwares diferentes. Uma das características mais importantes do Protocolo IP é a divisão da informação a ser transportada de um ponto ao outro em fragmentos denominados datagramas.

Todo datagrama é dividido em cabeçalho e corpo. No cabeçalho encontra-se informações como: origem do pacote, destino do pacote e informações específicas do protocolo; já o corpo do datagrama é utilizado para armazenar os dados, ou seja, ao mandar um email a junção do corpo de todos os datagramas formará, no destino, a mensagem original do email enviada pela origem.

O datagrama tem uma estrutura padronizada pelo protocolo IP que faz com que o endereçamento seja independente do hardware utilizado. A principal vantagem do IP está na transformação de redes diferentes e fisicamente separadas em uma rede funcionalmente homogênea.




12











mesmos valores.




www.3way.com.br


1.4. O PROTOCOLO TCP

O protocolo TCP (Protocolo de Controle de Transmissão) tem como objetivo controlar os dados quando estão em tráfego de forma que todos dados enviados de uma máquina devem ser divididos em pacotes pelo emissor, podendo trafegar por caminhos distintos e finalmente serem remontados corretamente pelo receptor. O protocolo também cuida da perda de pacotes no trajeto entre um ponto ao outro, solicitando a retransmissão do pacote ao remetente.

Vejamos um exemplo: duas redes compartilham um mesmo roteador, ponto de passagem entre elas. Se várias máquinas de uma rede enviarem pacotes para outra máquina na outra rede, obviamente estes pacotes passarão pelo roteador e se o tráfego gerado for intenso e acima da capacidade de repasse do roteador, este poderá ficar sem espaço livre no buffer, sendo incapaz de retransmiti-los, pois o protocolo IP simplesmente descarta os pacotes excedentes. Porém, o protocolo TCP faz com que a máquina cheque a integridade dos dados e solicita a retransmissão dos faltantes em caso de erros. Assim, toda vez que um pacote é enviado na rede, o protocolo TCP cuida das confirmações de recebimento. Por essa característica é dito que o protocolo TCP é um serviço confiável sobre o protocolo IP.

Outra característica importante do TCP é o controle de fluxo. Ao enviar dados na rede, a parte receptora indica à parte transmissora a quantidade de bytes que podem ser recebidos após os últimos dados recebidos, assim evita-se ultrapassar o limite da capacidade de buffer da máquina receptora.

1.5. PROTOCOLOS DE REDE

Para toda comunicação existe uma linguagem. Comunicação é impossível sem algum tipo de linguagem ou código preestabelecido. Em redes de computadores, estes códigos de comunicação são chamados de protocolos. É, portanto, através das regras estabelecidas pelos protocolos que os dados fluem de modo organizado e sem perdas.

A hierarquia de Protocolo é importante e está baseada em uma série de camadas (ou níveis) que são dispostas uma a cima da outra, de forma semelhante a uma pilha de protocolos. O número, o nome, o conteúdo e a função de cada camada difere de uma rede para outra. Porém, o objetivo de cada camada é oferecer determinados serviços para as camadas superiores, tornando-se um filtro e conversor de dados para a camada superior.

No âmbito lógico da rede, a camada n comunica com a camada n da outra máquina. As regras e convenções usadas nessa comunicação são chamadas de protocolo. Resumidamente, um protocolo é um conjunto de regras sobre o modo como se dará a comunicação entre as partes envolvidas. Assim, ao comunicar-se com




12











mesmos valores.




12











mesmos valores.




www.3way.com.br


determinada máquina existem regras que devem ser respeitadas conjuntamente. Caso isto não venha a acontecer, a comunicação será dificultada e em alguns casos pode impossibilitá-la, ocorrendo o que chamamos de violação do protocolo.

Comunicação através de camadas.

O conjunto de camadas de um protocolo é chamada de arquitetura de rede.

Entre cada par de camadas adjacentes existe uma interface. A interface consiste nas operações e serviços que a mesma deve prover para camada superior a ela. A especificação de uma arquitetura deve conter informações suficientes para permitir que um desenvolvedor crie um programa ou construa um hardware de cada camada de modo que ela transmita-o corretamente ao protocolo adequado.

1.5.1. O MODELO OSI

O modelo de referência OSI (Open System Interconnection) é conhecido como o modelo de padronização de tecnologias de redes de computadores. O modelo OSI teve como objetivo estabelecer uma regra e direcionamento no desenvolvimento de modelos de arquiteturas de redes. O modelo OSI define 7 camadas. Estas camadas estão dispostas da seguinte forma:




12











mesmos valores.




www.3way.com.br


Modelo de referência OSI

Física Esta camada tem como função adaptar o sinal de comunicação com o meio de transmissão.

Esta camada possui acesso físico ao meio de transmissão e, portanto, trata de fatores como especificação elétrica, mecânica e outros fatores físicos que fazem a interface entre o equipamento e o meio de transmissão.

Enlace de dados Esta camada trata a organização dos dados em pacote. Quando um pacote é enviado, esta

camada é responsável pelo último empacotamento antes da transmissão. Quando um pacote é recebido, este verifica, em primeira instância, a integridade do pacote. Se o pacote apresentar erros, este será descartado.

Rede Responsável pela tabela de roteamento, portanto esta camada controla o envio de pacotes

para os dispositivos corretos e deve garantir que o pacote chegue ao dispositivo correto. Transporte Esta é uma camada intermediária que tem a função de corrigir as eventuais deficiências

provenientes do nível rede. Sessão Esta camada fornece serviços como controle de comunicação (diálogo), gerenciamento de

token (sinalização) e gerenciamento de tarefas. Apresentação Esta camada tem como objetivo manipular dados antes do envio ao próximo nível, ou seja,

neste nível várias transformações são feitas, por exemplo: criptografia, compressão, etc. Aplicação Este nível oferece os meios de aplicação para que seja possível a comunicação através do

protocolo OSI. Nesta camada são definidos as funções de gerenciamento e mecanismos que tem como finalidade dar suporte ao desenvolvimento de aplicações em rede para o usuário.




12











mesmos valores.




www.3way.com.br


1.5.2. MODELO TCP/IP

O protocolo TCP/IP foi desenvolvido na plataforma UNIX e, atualmente, é o protocolo mais utilizado no mundo. Ele, na verdade, é uma pilha de protocolos, não se limitando somente ao TCP e IP. A sigla TCP/IP se refere aos dois principais protocolos: o TCP (camada de transporte) e o IP (camada de rede). O protocolo IP permite a comunicação de dois pontos da rede sem a necessidade destes estarem no mesmo meio físico. Já o TCP fornece uma conexão confiável sobre o IP.

Modelo TCP/IP

Acesso de Rede Similar a camada física do protocolo OSI. Tem a função de determinar as características

elétricas e mecânicas do meio de transmissão. Enfim, especificar os aspectos físicos da comunicação.

Rede Nesta camada o IP é o protocolo mais importante, ele tem a função de tornar as redes

homogêneas entre si, ou seja, tem a função de reunir redes com arquiteturas diferentes, fazendo com que sejam transparentes.

Transporte Nesta camada encontram-se os protocolos TCP e UDP. Esta camada tem a

responsabilidade de transmitir e controlar o envio de dados de um nó ao outro. Aplicação Aplicação é a camada que interage com o usuário. Ela oferece serviços como

smtp(email), o telnet (terminal remoto), o ftp (transferência de arquivos), etc.




12











mesmos valores.




www.3way.com.br


Comparação do modelo TCP/IP com o OSI.

1.6. O ENDEREÇO IP

Todo host tem um endereço exclusivo que o identifica na Internet ou mesmo na rede local. O endereço IPv4 é um número de 32 bits dividido de 4 porções de 8 bits (octetos) decimais. No IPv6, esse número de 128 bits composto por 16 octetos hexadecimais. Possui a capacidade de endereçar muito mais endereços que a versão 4. Por exemplo, uma única máquina pode ter um endereço de IP geralmente expresso de 3 formas: Endereços Descrição

149.76.12.4 Notação decimal de quatro partes, é a mais utilizada e mais legível.

0x954C0C04 Notação hexadecimal.

10010101.01001100.00001100.00000100 Notação binária.

1.7. CLASSES DE ENDEREÇAMENTO IP

Ao iniciar a distribuição dos números IP para empresas, os criadores do TCP/IP perceberam que era vantajoso definir blocos de endereços contíguos, no sentido de facilitar a administração. Verificaram também que as empresas tinham portes diferentes, e com isto surgiram as classes, que além de definir tipos de redes de tamanhos diferentes. Quando alguma empresa necessitava de números IP, era fornecido um bloco contíguo de endereços IP de uma classe adequada à sua necessidade, baseada na quantidade de hosts a serem identificados com números IP.

Foram definidos 5 tipos de classes: A, B, C, D e E. Para se identificar uma




12











mesmos valores.




www.3way.com.br


classe, procurou-se definir algo que seria melhor implementado em nível de hardware. Por isto, cada classe, foi definida baseando-se no primeiro dos quatro bytes do número IP, como segue:

Classe Valor binário

do 1o. byte Faixa de valores expresso em binário do 1o. byte

Faixa de valores expresso em decimal do 1o. byte

A 0XXXXXXX 00000000 a 01111111 0 a 127

B 10XXXXXX 10000000 a 10111111 128 a 191

C 110XXXXX 11000000 a 11011111 192 a 223

D 1110XXXX 11100000 a 11101111 224 a 239

E 11110XXX 11110000 a 11110111 240 a 254

Assim, para se identificar se um número IP pertence a classe A basta saber o

valor do bit do primeiro byte. Caso seja 0 pode-se concluir imediatamente que refere-se à classe A, caso contrário deve-se testar o segundo bit. Se o segundo bit for 0, conclui-se que refere-se à classe B, e assim sucessivamente até chegar a classe E.

Quando este valor binário é convertido em valor decimal, podemos compreender melhor a faixa de endereços IP definidos por cada classe. Por exemplo, todo endereço IP de classe A tem o primeiro byte localizado na faixa de 0 a 127.

1.8. ENDEREÇOS DE REDE E BROADCAST

Assim como foi padronizado que os endereços 127.X.X.X e 0.0.0.0 são utilizados respectivamente para endereços de localhost (loopback) e rede padrão, também foram padronizados os seguintes endereços especiais:

broadcast É o endereço utilizado para enviar mensagens para todos da mesma rede.

Assim como ocorre nos transmissores de rádio, através do processo denominado radiodifusão. O endereço de broadcast é obtido atribuindo-se o valor 1 a todos os bits da parte de host do endereço IP. Por exemplo, para o endereço 10.1.2.3 (classe A), o endereço de broadcast é 10.255.255.255.

Rede É o endereço utilizado para especificar a rede e não um host específico. O

endereço de broadcast é obtido atribuindo-se o valor 0 a todos os bits da parte de host do endereço IP. Por exemplo, para o endereço 10.1.2.3 (classe A), o endereço de rede é 10.0.0.0.

1.9. MÁSCARA DE REDE

Um conceito muito importante introduzido após a padronização das classes




12











mesmos valores.




www.3way.com.br


foi o conceito de máscara de rede. A máscara de rede é utilizada para delimitar a parte referente ao endereço de rede e de host de um endereço IP. Por exemplo, para o endereço IP 10.1.2.3 (classe A), a máscara de rede é 255.0.0.0. Abaixo pode-se observar alguns exemplos:

Endereço de rede Endereço de host

Número IP 10. 1.2.3

Máscara de rede (em binário) 11111111. 00000000.00000000.00000000

Máscara de rede (em decimal) 255. 0.0.0

Máscara de rede (quantidade de 1's) 8

A máscara é um valor de 32 bits, exatamente como um endereço IP, podendo

ser expresso também na forma decimal e na forma hexadecimal. A máscara de rede por padrão define todos os bits do primeiro byte iguais a 1 (equivale ao valor 255) para o endereço de rede. Para os endereços de hosts ela deverá ter todos os bits iguais a 0 (número 0 na forma decimal). Pode-se expressar a máscara através da quantidade de bits 1, para a classe A o valor é 8 (10.1.2.3/8 ou 10.1.2.3/255.0.0.0).

Classe A: 255.0.0.0 ou valor 8 Classe B: 255.255.0.0 ou valor 16 Classe C: 255.255.255.0 ou valor 24

1.10. SUB-REDE

Ao se utilizar o esquema de classes acima, na prática percebeu-se que a quantidade de hosts disponibilizada por uma rede de uma classe ora era muito pouca ou era excessiva para o uso de uma entidade. Lembre-se que a faixa de endereços classe A, B e C correspondem a 65 milhões, 65 mil e 255 endereços de hosts respectivamente e que quando uma rede de uma destas classes era fornecido para uma entidade, pecava-se pelo excesso, desperdiçando uma quantidade enorme de endereços IP. Para resolver este problema, surgiu a ideia de sub-rede, lançada na RFC950, que proporcionou um melhor aproveitamento do conjunto de números IP disponíveis, fornecendo faixas de endereços IP sob medida de acordo com a necessidade de cada entidade.

O novo esquema é baseado no deslocamento dos bits da máscara para direita ou para esquerda do esquema de máscara antigo para aumentar ou diminuir a quantidade de hosts/subredes. Por exemplo, para o IP 10.1.2.3 de classe A, com a máscara alterada para 255.255.0.0, possibilita o aumento da porção de subredes e a diminuição do número de hosts tendo como base o padrão.




12











mesmos valores.




www.3way.com.br


Classe Primeiro byte Segundo byte Terceiro byte Quarto byte

A Bit 0 + 7 bits de endereço de rede 24 bits disponíveis

B bits 10 + 14 bits de endereço de rede 16 bits disponíveis

C bits 110 + 21 bits de endereço de rede 8 bits disponíveis

Note neste quadro acima, que em endereços IP classe A, B, C, temos 24, 16 e

8 bits disponíveis respectivamente para o avanço da máscara de sub-rede e endereço de host. Portanto, a máscara de sub-rede pode avançar somente até o antepenúltimo bit, pois se avançamos até o penúltimo bit, teremos disponível somente 1 bit para número de host, o que seria insuficiente para identificar hosts reais, uma vez que o bit 0 seria para identificar a rede e o bit 1 para broadcast. Da mesma forma, se avançarmos até o último bit, não teríamos mais bits disponíveis para identificar hosts. Portanto, para a máscara de sub-rede, para as classes A, B e C, temos disponível para avançar 22, 14 e 6 bits respectivamente.

Outro conceito importante a ser notado é o número de sub-rede. Antes da sub-rede, todo número IP era do tipo número da rede.número do host, com o uso de sub-redes, o endereço IP pode ser expresso de uma forma diferente: número da rede.número da sub-rede.número do host. Por exemplo, suponha que tenhamos um número IP 10.1.2.3, com máscara de sub-rede 255.255.0.0. Este número proporciona o valor de 10 como número de rede, 1 como número de sub-rede e 2.3 como número de host.

Um equívoco muito comum é determinar a classe de um endereço baseado na máscara que um endereço IP utiliza. O que define a classe em que um endereço IP pertence é o valor do seu primeiro octeto.

Até o momento somente foram abordadas máscaras de sub-rede que ocupam

totalmente um octeto, porém é possível manipular outros bits dessas máscaras, por exemplo 255.255.255.248. Com essa máscara o esquema ficaria da seguinte forma:

255. 255. 255. 248

11111111. 11111111. 11111111. 11111000

Quando se é utilizada máscaras de sub-rede como esta, tem-seum cálculo

mais complexo. Supondo que se tenha a rede 200.163.79.0, se for utilizada a máscara de sub-rede 255.255.255.248, a parte referente a rede será aumentada e a parte de hosts será diminuída. Para esse endereço tem-se as sub-redes variando de




12











mesmos valores.




www.3way.com.br


00000000=0 a 11111000=248.

sub-rede (em binário) sub-rede (em decimal)

00000000 0

00001000 8

00010000 16

00011000 24

... ...

11111000 248

Note que para obter as sub-redes, simplesmente soma-se recursivamente o

valor de 8 (equivalente a 1000 binário) ao valor da primeira sub-rede 00000000. Se essa regra for aplicada a esta regra, obtem-se as seguintes sub-redes: 0, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96, 104, 112, 120, 128, 136, 144, 152, 160, 168, 176, 184, 192, 200, 208, 216, 224, 232, 240, 248, ou seja 32=25 sub-redes, ou seja 2n sub-redes, onde n é a quantidade de bits disponibilizados a mais para formação de sub-rede.

Após a obtenção das sub-redes e considerando o IP 200.163.79.10, o quadro abaixo mostra o cálculo para esse endereço:

Endereço IP 200.163.79.9

Endereço de rede 200.163.79

Endereço de sub-rede 8 = 1000

Endereço de host 2 = 010

Endereço IP (em binário) 11001000.10100011.01001111.00001010

Máscara de sub-rede (em binário) 11111111.11111111.11111111.11111000

1.11. ENDEREÇOS IP PARA REDES PRIVADAS

Todo computador da Internet deve ter um endereço IP único, no entanto, em uma rede local é preciso utilizar endereços únicos, mas que não sejam válidos na Internet. Existem blocos de endereços que foram reservados para as redes privadas. Os endereços de rede apresentados abaixo podem ser utilizados em qualquer rede local:

Classe Faixa

A de 10.0.0.0 a 10.255.255.255




12











mesmos valores.




12











mesmos valores.




www.3way.com.br


B de 172.16.0.0 a 172.31.255.255

C de 192.168.0.0 a 192.168.255.255

1.12. O NÚMERO DE PORTA

Embora o endereço IP seja suficiente para localizar um computador, é necessário localizar também determinado aplicativo naquele computador. Por exemplo, se a mensagem que está sendo recebida for uma correspondência eletrônica, ela precisará ser enviada para o leitor de correio. Se a mensagem recebida for uma solicitação de página Web, ela precisa ser roteada para o programa que envia páginas Web.

Existe um número de identificação, chamado número da porta, que é enviado em cada mensagem. É necessário que o remetente também saiba o número da porta. Existem portas que são notadamente conhecidas por serem utilizadas por serviços conhecidos, essas portas são chamadas de portas baixas ou conhecidas. Por exemplo, todo navegador faz requisições na porta 80 de todo servidor Web, e a maioria dos clientes SSH fazem requisições na porta 22 do servidor SSH.

Os clientes também se comunicam com os servidores através de portas, normalmente essas portas são acima de 1024 (portas não conhecidas).

1.13. ROTEAMENTO

Redes de computadores roteiam os pacotes baseando-se no sistema de correios, ou seja, deseja-se comunicar com um destino, então os pacotes são entregues um a um para o primeiro roteador (primeira agência dos correios) e este encarrega-se de entregar ao roteador de destino (agência de destino). Durante esse trajeto os pacotes podem passar por vários outros roteadores intermediários até encontrar o roteador final.

A vantagem de utilizar esta forma estruturada está no fato de não haver uma preocupação com o caminho que o pacote irá percorrer, a única preocupação está limitada a origem e ao destino. Toda a Internet consiste em um número de redes próprias que são denominadas como redes autônomas. Cada rede necessita de um roteamento interno que tem a tarefa de entregar o datagrama para a rede da máquina de destino.

1.14. DNS

Raramente os programas fazem referência a hosts, e-mail e outros recursos utilizando seus endereços IP, eles utilizam com frequência os nomes (strings em ASCII), então é necessário algum tipo de mecanismo para converter os strings ASCII




12











mesmos valores.




www.3way.com.br


em endereços IP. A função do DNS é justamente essa: converter nomes em endereço IP.

1.15. ARQUIVOS GERAIS

Existe um grande número de arquivos de configuração e informações que se referem a rede. Estes arquivos armazenam números de portas, endereços usados nas comunicações, etc. A seguir será apresentado alguns arquivos:

/etc/protocols Define os protocolos de baixo nível utilizados nas comunicações de redes

TCP/IP. Quando um pacote é enviado, ele necessita ser encapsulado em um tipo de protocolo, este arquivo serve como referência para saber como desempacotá-lo. Essa referência é feita através da ID (Identificação) do protocolo.

Protocolo ID Nome Alternativo Descrição ip 0 IP #internet protocol,pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # Internet Group Management ggp 3 GGP # gateway-gateway protocol ipencap 4 IP-ENCAP # IP encapsulated in IP (officially “IP”) st 5 ST # ST datagram mode tcp 6 TCP # transmission control protocol egp 8 EGP # exterior gateway protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol hmp 20 HMP # host monitoring protocol . . .

/etc/services Define os números de porta de cada serviço. Ter uma entrada neste arquivo

não indica necessariamente que o programa estará sendo executado, pois este arquivo apenas controla o número de porta que o processo/programa é executado.

Serviço Porta/Protocolo Descrição Tcpumx1 1/tcp #rfc-1078 echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users daytime 13/tcp daytime 13/udp netstat 15/tcp ...

Este arquivo é baseado na lista port numbers (disponível on-line no endereço




12











mesmos valores.




www.3way.com.br


http://www.isi.edu/in-notes/iana/assignments/port-numbers). /etc/hosts Define uma forma de resolução de nomes que relaciona nomes de máquinas

com endereços IP. Endereço IP Hostname Alias 127.0.0.1 localhost 10.1.0.101 maq1.3waylocal.net.br maq1 10.1.0.102 maq2. 3waylocal.net.br maq2 10.1.0.103 maq3. 3waylocal.net.br maq3 10.1.0.2 servidor. 3waylocal.net.br servidor

1.16. CONFIGURAÇÃO TCP/IP

A configuração de informações TCP/IP constituem um dos passos mais importantes para tornar uma máquina operacional em uma rede. É preciso atentar-se para as seguintes configurações: Hostname (Nome da Máquina), Interface de Rede (Placa de Rede), Rotas e Resolução de Nomes (DNS).

1.16.1. HOSTNAME

No protocolo TCP/IP existe uma padronização para nomes de hosts. Os nomes das máquinas devem seguir o padrão FQDN (Nome Totalmente Qualificado) que nada mais é que o nome da máquina com o seu respectivo domínio DNS. O nome servidor.3waylocal.net.br é um exemplo de nome totalmente qualificado, onde servidor é o nome da máquina e 3waylocal.net.br é o domínio.

O comando abaixo configura o nome da máquina: hostname servidor.3waylocal.net.br

Para verificar se a configuração foi executada com êxito, execute somente

hostname para ver como ficou o nome da máquina: hostname servidor.3waylocal.net.br

Entretanto, este comando configura o nome da máquina temporariamente, ou

seja, se esta máquina for reiniciada, ela perderá a configuração. No CentOS/RHEL deve-se editar a diretiva HOSTNAME do arquivo /etc/sysconfig/network, no Debian/Ubuntu basta alterar o arquivo /etc/hostname com o nome da máquina, todos eles produzem mudanças permanentes de hostname. Abaixo está um exemplo do arquivo do CentOS/RHEL:

NETWORKING=yes NETWORKING_IPV6=no HOSTNAME=servidor.3waylocal.net.br




12











mesmos valores.




www.3way.com.br


As diretivas NETWORKING e NETWORKING_IPV6 significam que esta

máquina está em uma rede IPV4 e IPV6 respectivamente. Ainda é possível encontrar outras diretivas além de HOSTNAME nesse arquivo, tais como GATEWAY e GATEWAYDEV que define, na mesma ordem, qual será o roteador padrão para a máquina e qual dispositivo dará acesso a esse roteador.

1.16.2. INTERFACE DE REDE

Esta configuração está baseada na detecção da placa de rede, configuração do endereço IP e máscara de rede e outras diretivas.

Interface Ethernet O kernel é responsável pela interação com todo hardware, inclusive placas de

rede. Para que o kernel reconheça a interface de rede, é necessário que a placa de rede seja de um tipo conhecido e que a placa possua um módulo (driver) que a faça funcionar. O Linux possui um grande número de módulos para placas de rede, porém pode ser necessário compilar algum módulo. Para carregar módulos compilados é utilizado comando modprobe.

Exemplo: #modprobe rtl8139. Configuração O comando ifconfig pode ser utilizado para configurar em tempo de

execução as informações de rede. Para configuração permanente é preciso utilizar arquivos de configuração específicos da distribuição. Digitando ifconfig sem parâmetros, obte-se a lista das interfaces ativas na máquina.

ifconfig eth0 Link encap: Ethernet Hwaddr 00:90:06:54:05:11 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST LOOPBACK RUNNING MTU: 1500 Metric:1 RX packets: 421 errors:0 dropped:0 overruns:0 frame:0 TX packets:75 errors:0 dropped:0 overruns:0 carrier:0 lo Link encap: Local loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU: 3584 Metric:1 RX packets: 460 errors:0 dropped:0 overruns:0 frame:0 TX packets:460 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0

Exemplo: ifconfig eth0 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255

up




12











mesmos valores.




www.3way.com.br


Este comando atribui a interface eth0 o endereço IP 192.168.1.10, a máscara de rede 255.255.255.0 e endereço de broadcast 192.168.1.255.

ifconfig eth0 down

Desativa a interface. No CentOS/RHEL existe o diretório /etc/sysconfig/network-

scripts que armazena todos os arquivos relacionados às interfaces de rede presentes na náquina (ifcfg-eth0, ifcfg-eth1, etc). Basta editá-los para criar configurações de rede permanentes.

Em distribuições baseadas no Debian/Ubuntu o arquivo que deverá ser editado para todas as interfaces presentes, é o /etc/network/interfaces.

/etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=none IPADDR=192.168.1.x NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 GATEWAY=192.168.1.y ONBOOT=yes /etc/init.d/network restart

/etc/network/interfaces auto eth0 iface eth0 inet static address 192.168.1.x netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.y /etc/init.d/networking restart

1.17.3. CONFIGURAÇÃO DAS ROTAS

A configuração de rotas é necessária em um cenário que possui sub-redes. Ela serve para fazer com que uma rede consiga acessar outras ou até mesmo a Internet.

Para configurar rotas deve-se ter consciência de alguns conceitos como rede




12











mesmos valores.




www.3way.com.br


de alcance e roteador. O primeiro refere-se a rede de destino que se quer ter acesso (rede interna ou a Internet) já o segundo conceito define a máquina que dará acesso à rede de alcance.

O comando route é utilizado para trabalhar com rotas. Visualizando rotas route Tabela de Roteamento IP do Kernel Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default roteador.3waylocal.net.br 0.0.0.0 UG 0 0 0

eth0

Cada coluna da saída acima possui um significado. A primeira coluna

representa a rede de destino, a segunda é o roteador para acesso à rede de destino, a terceira é a máscara da rede de destino, a quarta informa se a rota está ativa (U), se o alvo é um host (H), um roteador (G), etc. A quinta coluna representa a métrica (metric), que é a distância até o alvo (geralmente contada em hops), a sexta é o número de referências à rota, a sétima é a contagem de procuras por essa rota e por último (oitava), qual a interface pelos quais os pacotes IP serão enviados.

Existem três entradas na tabela de roteamento do kernel. Entretanto, as duas primeiras são adicionadas pelo sistema, isto é assim porque por padrão cada interface de rede exige uma rota. Para saber quais rotas foram adicionadas pelo sistema, observe quais entradas têm um * na coluna referente ao Roteador.

A última entrada cuja primeira coluna está definido como default é uma rota padrão que foi adicionado pelo administrador. No campo Roteador está definido a máquina roteador.3waylocal.net.br. Quando o route é executado sem nenhuma opção o mesmo tentará apresentar o nome da máquina ao invés de seu endereço IP e quando não é possível apresentar o nome, ele tenta até expirar o tempo limite (timeout).

Adicionando rotas route add -net 192.168.1.0/24 gw 192.168.1.1

Este comando adicionará uma rota para a rede 192.168.1.0/24 através do

roteador 192.168.1.1. A opção gw é utilizada para atribuir o IP do roteador. O número 24 de 192.168.1.0/24 especifica a máscara de rede.

Removendo rotas Para excluir uma rota, basta executar: route del -net 192.168.1.0/24




12











mesmos valores.




www.3way.com.br


É necessário especificar novamente a máscara, porém não é necessário

especificar o número IP do roteador. Rotas estáticas O comando para adicionar rota deve ser executado toda vez que for

inicializada a máquina, portanto é necessário adicionar este comando nos scripts de inicialização do sistema.

No CentOS/RHEL, pode ser criado o arquivo /etc/sysconfig/network-

scripts/route-eth0 que pode ser utilizado para adicionar uma rota estática, deve-se, portanto, inserir a seguinte linha: 192.168.1.0 via 192.168.1.1.

Após a realização da configuração, basta reiniciar o serviço de rede: /etc/init.d/network restart

No Debian/Ubuntu é necessário editar o arquivo /etc/network/interfaces com

entradas para adicionar e remover parecidas com as abaixo: Adicionar up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1

Remover down route del -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1

Após a realização da configuração, basta reiniciar o serviço.

1.17.4. RESOLUÇÃO DE NOMES

O servidor de DNS é definido no arquivo /etc/resolv.conf. /etc/resolv.conf nameserver 192.168.1.1 nameserver 200.242.140.5

1.18. INETD / XINETD

Inetd O serviço inetd é considerado um super serviço, pois ele controla vários

outros serviços. O inetd lê entradas em um arquivo de configuração chamado




12











mesmos valores.




www.3way.com.br


/etc/inetd.conf. Através deste arquivo o serviço inetd tem controle sobre demais serviços.

É importante o seu uso para serviços que não precisam sempre estar constantemente ouvindo requisições. Quem fará isso é o Inetd, que interceptará a requisição e chamará o serviço solicitado, poupando recursos do servidor.

/etc/inetd.conf ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Shell, login, exec, comsat and talk are BSD protocols. # #shell stream tcp nowait root /usr/sbin/tcpd in.rshd #login stream tcp nowait root /usr/sbin/tcpd in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd in.rexecd . . . #imap stream tcp nowait root /usr/sbin/tcpd imapd #

Para que o inetd inicie qualquer um dos serviços definidos no arquivo, a linha

referente ao mesmo deve estar descomentada. Após descomentá-la, basta reiniciar o Inetd.

Xinetd O Xinetd foi escrito com o objetivo de ser um substituto avançado para o

Inetd. Versão recentes de distribuições GNU/Linux já o utilizam por padrão no lugar do Inetd, embora algumas ainda suportem ambos.

As principais características deste novo super servidor são:

Suporte nativo ao Tcp_wrappers; Controle de acesso mais refinado; Possui um arquivo principal de configuração que pode incluir

outros; Informações de log mais detalhadas; Suporte a redirecionamento de serviços.




12











mesmos valores.




12











mesmos valores.




www.3way.com.br


O arquivo /etc/xinetd.conf é responsável pela configuração geral do xinetd e no diretório /etc/xinetd.d/ estão as configurações específicas. A diferença entre xinetd e o inetd é que o primeiro possui um arquivo de configuração para cada serviço.

A configuração do servidor telnet pode ser feita usando o Xinetd da seguinte maneira:

/etc/xinetd.d/telnetd service telnet { disable = yes flags = REUSE socket_type = stream protocol = tcp wait = no user = root server = /etc/sbin/in.telnetd log_on_failure += USERID }

Parâmetros do Xinetd

disable Indica se o serviço está desabilitado (“yes”) ou habilitado (“no”). flags Controla vários parâmetros. Podem estar acumulados.

socket_type Aceita “stream”, “dgram” , “raw” e “seqpacket”. Normalmente “stream” está relacionado a tcp e “dgram” para udp.

protocol Protocolo válido que deve estar presente em /etc/protocols. Normalmente é tcp ou udp.

wait Se “yes”, indica serviços single-threaded, dispara e espera o serviço terminar para lançar outras instâncias ou outros serviços. Se “no”, ele não espera para lançar outras instâncias/serviços.

user Determina o usuário sob o qual o serviço será executado. group Especifica o group pelo qual o serviço será executado. server Indica o programa responsável pelo serviço. server_args Especifica os argumentos do programa citado acima. log_on_failure Determina quais informações de erros vão compor o log de erros.

instances Quantidade de instâncias simultâneas deste serviço são permitidas. Por padrão não há limites.

access_times Especifica o horário em que conexões a este serviço serão aceitas (formato: hora:minuto-hora:minuto).

per_source Quantidades permitidas de conexões por IP.

cps

Forma de limitar a taxa de conexões. Usa dois argumentos. O primeiro controla o número de conexões por segundo, e o segundo limita quanto tempo o serviço permanecer desativado se o primeiro argumento for excedido.




12











mesmos valores.




www.3way.com.br


nice Valor de nice inicial para os processos.

1.19. UTILITÁRIOS DE REDES

1.19.1. HOST

Obtém informações de máquinas pertencentes a um domínio ou sub-domínio. Utiliza o serviço de nomes como fonte de suas consultas.

Consulta Simples host www.linux.org www.linux.org is an alias for linux.org linux.org has address 184.173.230.160 linux.org mail is handled by 0 linux.org

Transferência de Zona host -l linux.org

Consulta Detalhada host -a www.registro.org

As opções -l e -a são respectivamente para fazer a transferência de zona de

um domínio qualquer e para realizar uma consulta que contenha todas as opções juntas. Para saber todas as opções deste e de todos os comandos, basta utilizar o manual (comando man).

1.19.2. NETSTAT

Esta ferramenta é utilizada também para obter informações de rede, mais precisamente para checar a configuração e atividade de uma rede.

Consulta da Tabela de Roteamento netstat -nr Tabela de Roteamento IP do Kernel Destino Roteador MáscaraGen. Opções MSS Janela irtt Iface 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 192.168.1.0 0.0.0.0 255.255.255.0 UH 0 0 0 eth0

netstat (parâmetros)




12











mesmos valores.




www.3way.com.br


-a Lista todas as portas em escuta ou não. -t Lista portas tcp. -u Lista portas udp. -r Opção para mostrar a tabela de roteamento. -n Não faz resolução de nomes, e sim, exibe os endereços IP. -i Mostrar todas as interfaces presentes ou alguma especificada (--interface=iface). -m Mostra a lista de todas as conexões mascaradas. -s Exibe estatísticas divididas por cada protocolo. -c Provoca a exibição contínua das informações (por segundo). -p Mostra o PID de cada processo. -e Exibe informações adicionais. Pode ser usada duplamente para mais informações.

Mais opções sobre o utilitário netstat podem ser vistas no manual do

comando através do comando man netstat.

1.19.3. TCPDUMP

Este utilitário é um farejador de conexões TCP/IP. O monitoramento é através da especificação da interface desejada: eth0, eth1, ppp0, etc. A saída do comando é o tráfego de pacotes enviados e recebidos, endereços de origem, de destino e outras informações.

Monitorando todo tráfego tcpdump -i eth0 O tcpdump, devido ao sua capacidade de capturar os pacotes de um meio compartilhado,

pode ser utilizado para fins ilícitos, como capturar senhas não-criptografadas que trafegam na rede. Mas também pode ser utilizado para fins lícitos, como ferramenta de análise de protocolos.

Monitorando um host tcpdump -i eth0 host maq1.3waylocal.net.br

Neste exemplo, apenas os pacotes enviados pelo maq1 ou a ele destinados serão monitorados.

tcpdump -i eth0 src host maq1.3waylocal.net.br

Para monitorar somente os dados que estão sendo enviados por maq1 é preciso utilizar o parâmetro src.

Para monitorar apenas os pacotes que estão sendo enviados para maq1. tcpdump -i eth0 dst host maq1.3waylocal.net.br




12











mesmos valores.




www.3way.com.br


É possível monitorar pacotes que tenham passado por um gateway específico,

definindo seu nome, como mostrado a seguir: tcpdump -i eth0 gateway [roteador]

Para monitorar tantos pacotes UDP quanto os TCP que sejam endereçados a uma porta específica, você pode especificar o número da porta, como no exemplo abaixo:

tcpdump -i eth1 host maq2.3waylocal.net.br and port 80

O tcpdump possui inúmeras opções que podem ser utilizadas para o monitoramento das conexões TCP/IP, para obter mais informações consultar o manual do comando.

1.19.4. TRACEROUTE

Este aplicativo indica por quais roteadores um pacote passou antes de atingir seu destino. O exemplo abaixo mostra quantos roteadores existem a partir do computador em que se executa o comando até o destino.

traceroute www.linuxdoc.org traceroute to linuxdoc.org (152.19.254.81), 30 hops max, 40 byte packets 1 roteador (10.2.0.5) 0.872 ms 0.334 ms 0.320 ms 2 10.1.0.7 (10.1.0.7) 1.049 ms 0.815 ms 0.843 ms 3 ppp254-gnace7004.telebrasilia.net.br (200.163.76.254) 16.285 ms 18.032 ms 16.100 ms 4 200.193.193.193 (200.193.193.193) 16.884 ms 18.170 ms 16.307 ms 5 200.199.245.5 (200.199.245.5) 24.378 ms 26.340 ms 24.531 ms 6 200.193.234.1 (200.193.234.1) 26.033 ms 24.762 ms 24.778 ms 7 200.193.234.66 (200.193.234.66) 47.527 ms 49.635 ms 49.128 ms 8 BrT-G3-0.cta-border.telepar.net.br (200.163.207.129) 47.849 ms 50.174 ms 49.365 ms 9 brasiltelecom-A0-0-0-32-dist01.cta.embratel.net.br (200.250.208.57) 53.094 ms

Entre a fonte e o destino podem existir muitos roteadores pelos quais o pacote

atravessa antes de atingir seu destino. Muitos roteadores não respondem a ping, técnica utilizada para testar os roteadores, então pode ocorrer de as respostas não saírem na forma de milissegundos (ms), e sim, três * (asteriscos).

1.19.5. NMAP

O comando nmap é um scanner de portas, ou seja, ele mostra quais portas de comunicação estão abertas.

Sintaxe do comando NMAP

nmap [opções] <endereço>




12











mesmos valores.




www.3way.com.br


opções

-sS – Scanner silencioso. -sP – Scanner de ping. -sT – Scanner tcp -sU – Scanner udp

endereço Endereço IP ou Hostname da máquina alvo.

O exemplo abaixo mostra quais são as portas (e serviços) que estão momentaneamente abertas na máquina local.

nmap 127.0.0.1 #Starting nmap V. 2.54BETA21 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1535 ports scanned but not shown below are in state: closed) Port State Service 80/tcp open http 111/tcp open sunrpc 119/tcp open nntp 443/tcp open https 515/tcp open printer 878/tcp open unknown 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 1 second




12











mesmos valores.




www.3way.com.br


1.20. LABORATÓRIO

Esse laboratório tem o intuito promover a prática sobre a configuração TCP/IP, Xinetd e

utilitários de rede.

A) Preparar a máquina com as configurações TCP/IP necessárias. Hostname hostname aluno1.3waylocal.com.br vi /etc/sysconfig/network HOSTNAME=aluno1.3waylocal.com.br Interface de rede ifconfig eth0 192.168.1.101 netmask 255.255.255.0 broadcast 192.168.1.255

up vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 ONBOOT=yes BOOTPROTO=none" IPADDR=192.168.1.101 NETMASK=255.255.255.0

Rotas Normalmente as rotas são criadas automaticamente, incluindo a padrão, mas se por acaso

isso não acontecer, podemos criá-la com o comando: route add default gw 192.168.1.254

Resolução de nomes echo "nameserver 192.168.1.254" > /etc/resolv.conf

Desse ponto em diante, a máquina já possui conectividade na rede, já é possível navegar.

B) Configurar o serviço imap no xinetd para acesso local e da rede 192.168.1.0/24 no servidor de email e usando banner específico para usuários bloqueados.

service imap { socket_type = stream protocol = tcp wait = no user = root only_from = 192.168.1.0 localhost banner = /usr/local/etc/deny_banner server = /usr/local/sbin/imapd }

C) Testar alguns utilitários de rede para extrair mais informações da mesma.




12











mesmos valores.




www.3way.com.br


Resolução de nomes host www.3way.com.br

Conexões ativas netstat -ano

Forjando conexões ICMP tcpdump icmp

Traçando a rota até um ponto traceroute www.3way.com.br

Varredura de Portas nmap -sS 192.168.1.101 nmap -sT 192.168.1.102 nmap -sU 192.168.1.103 nmap -sP -O 192.168.1.*




12











mesmos valores.




12











mesmos valores.




www.3way.com.br


1.21. EXERCÍCIOS

1) Tendo como base a rede 192.168.20.0/255.255.255.0, calcular: a) Notação CIDR b) Broadcast c) Número de endereços disponíveis para dispositivos

2) Considerando a rede 192.168.10.0/255.255.255.240, calcular os mesmo

itens do exercício anterior. 3) Interpretar a tabela de roteamento abaixo, respondendo algumas

perguntas: Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface 10.1.1.23 192.168.10.253 255.255.255.255 UGH 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0 192.168.10.140 192.168.10.254 255.255.240.0 UG 0 0 0 eth0 127.0.0.1 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 eth0

a) Se um pacote tiver o destino a 176.16.0.12 para qual roteador ele será enviado? b) E com destino 192.168.10.150? c) Destino 10.1.1.23?

4) Converter os números IP:

a) 10.20.30.40 em hexadecimal e binário b) 11100111.11100111.10000001.00001010 em decimal e hexadecimal c) 0x11C4C040 em binário e decimal

5) Por que os endereços IP foram divididos em classes? Quais são as

classes e como identificamos um número IP como pertencente a uma classe? 6) Qual é a quantidade de endereços de classe A matematicamente possíveis? E de

classe B e C? 7) Conceituar e da exemplos sobre os endereços especiais:

a) broadcast b) rede c) privado d) localhost e) rede padrão (todas redes)

8) O que é sub-rede? Qual a sua utilidade? Como criar uma sub-rede? 9) O que são portas TCP? Para que servem? Citar pelo menos 5 número de

portas com seus respectivos serviços padrões.




12











mesmos valores.




www.3way.com.br


10) O que é uma rota? Qual é o comando para se definir uma rota? 11) O que é um DNS? Para que serve um DNS? Qual é o endereço IP dos

hosts: www.3waylocal.net.br, www.globo.com, www.uol.com.br? 12) Para que servem os arquivos: /etc/protocols,

/etc/services, /etc/hosts? 13) O que é FQDN? Qual a utilidade do comando hostname? 14) Para que serve o arquivo /etc/resolv.conf? 15) Qual é a utilidade do serviço inetd/Xinetd? Quando devemos utilizá-lo?




12











mesmos valores.




www.3way.com.br


2. SERVIDOR SSH O OpenSSH é uma implementação do protocolo SSH (Secure

SHell) para o Linux que possui o objetivo de criptografar sessões de shell para máquinas remotas, mas pode ser usado para transferência de arquivos e criar túneis para outros protocolos.

2.1. INSTALAÇÃO E CONFIGURAÇÃO

A instalação do cliente e servidor OpenSSH é feita através do comando:

yum install openssh openssh-server

Todos os arquivos de configuração se localizam na árvore /etc/ssh/. Os arquivos ssh_config e sshd_config configuram, respectivamente, o cliente e o servidor SSH. Algumas opções do servidor serão listadas a seguir:

Opções sshd_config Port 22 Define a porta que o servidor espera conexões. O padrão é a 22. Protocol 2 Indica qual a versão do protocolo o OpenSSH dá suporte. O padrão é o 2, devido a

algumas falhas da versão 1.

PermitRootLogin yes Habilita/Desabilita o login do usuário root. O padrão é yes, com a opção estando comentada.

SSH – Conecta remotamente a um host informado. Sintaxe: ssh nome_de_usuario@ip_ou_nome_host ou ssh ip_ou_nome_host.

Exemplos

ssh [email protected]

Conecta via ssh ao host 192.168.0.150 com o usuário user1 através da porta padrão de conexão. Obs.: A senha do usuário user1 será solicitada para completar a conexão.

ssh 192.168.0.150 Tenta uma conexão ssh no host 192.168.0.150 com o usuário logado no momento, caso ele não exista, exibirá mensagem de erro.

ssh user2@maq1 Conecta via ssh ao host maq1 com o usuário user2 através da porta padrão de conexão. O nome maq1 deve resolvido localmente (/etc/hosts) ou por um DNS, caso contrário a conexão não será completada.

ssh -p 1022 user2@maq1 Faz uma conexão ssh com user2 no host de nome maq1 através da porta 1022.




12











mesmos valores.




www.3way.com.br


2.2. LABORATÓRIO

Este laboratório tem o objetivo de mostrar e testar a configuração do servidor SSH na máquina virtual.

Você usará a máquina hospedeira para se conectar à VM, configurar o servidor e testá-lo.

1) Antes de qualquer coisa, verifique a conectividade entre as duas máquinas através de um ping. (vamos supor que a máquina hospedeira tem o endereço 192.168.0.103 e a máquina virtual 192.168.0.123)

Estando na hospedeira: ping 192.168.0.123 Estando na VM: ping 192.168.0.103 2) Se houver conectividade, conecte-se à VM com o usuário root. ssh [email protected]

3) Se o logon tiver sucesso, faça a seguinte configuração no servidor: vi /etc/ssh/sshd_config

Port 41001

Protocol 2

PermitRootLogin no

Essas configurações mudaram a porta de acesso ao servidor e o protocolo do SSH (protocolo 2) e removeram a permissão do usuário root de se logar remotamente.

4) Reinicie o servidor para que as alterações passem a valer. service sshd reload

5) Naturalmente espera-se que a conexão estabelecida com a VM caia, pois afinal retiramos a permissão do usuário root de se conectar remotamente. Porém, as alterações começam a valer somente para as novas conexões, precisando assim finalizar os processos anteriores a essa configuração que acabamos de efetuar.

ps aux | grep sshd

kill -9 pid_da_conexao_ssh

6) A conexão cairá instantaneamente, conecte-se novamente já com as novas configurações.

ssh -p 41001 [email protected]




12











mesmos valores.




www.3way.com.br


2.3. EXERCÍCIOS

O que é o openSSH? Qual o comando utilizado para instalá-lo (Cliente e Servidor)? Qual é o arquivo de configuração do servidor e do cliente openSSH?

Descreva as principais diretivas. Explique com detalhes o que faz o comando abaixo: ssh -p 41002 [email protected]


Siga-nos também no Twitter!twitter.com/3waynet



12











mesmos valores.




www.3way.com.br


3. SISTEMA DE NOMES DE DOMÍNIO

O Sistema de Nomes de Domínio (DNS) trata de um dos serviços mais

fundamentais para o funcionamento da Internet. Ele traduz nomes de hosts em números IP e vice-versa.

3.1. SERVIÇOS DE NOMES - DNS

O DNS se enquadra nos principais serviços de redes TCP/IP. A finalidade do DNS é converter nomes como www.registro.br em endereços IP como 200.160.2.3. É importante salientar que o DNS faz também a resolução reversa, ou seja, converte endereços IP para nomes.

Nos sistemas Linux existem duas técnicas para fazer resoluções, a primeira forma é através de uma tabela de hosts (/etc/hosts), a outra é feita através da consulta a um servidor de nomes (DNS). O DNS é um banco de dados com servidores distribuídos e organizados de forma hierárquica, espalhados por toda Internet; de forma que todo servidor de nomes é também cliente de outro, pois caso um não consiga resolver um nome (traduzir para um número IP), este consultará outro e assim por diante.

O servidor de nomes padrão na maioria das distribuições de Linux é o software named que está incluso no pacote BIND (Berkeley Internet Name Domain). O pacote BIND, além do servidor DNS, oferece também: biblioteca em linguagem C para ser utilizada em clientes DNS chamada de biblioteca resolver, o utilitário para administração rndc (remote name daemon control program) e os utilitários nslookup e host para consulta em servidores DNS.




12











mesmos valores.




www.3way.com.br


Resolução de nomes

3.2. INSTALAÇÃO DO BIND

Há basicamente duas formas que podem ser utilizadas para instalar um sistema no Linux.

3.2.1. INSTALAÇÃO CÓDIGO FONTE

Deve-se baixar o código fonte do programa, encontrado no site http://www.isc.org, compilar e instalar. Geralmente estes programas vem compactados e serão compilados através do comando make. Para cada programa você deve seguir as instruções dos arquivos README e INSTALL, que vem junto com código fonte.

Para instalar o BIND: cp bind-9.x.x.tar.gz /usr/local/src cd /usr/local/src tar xvfz bind-9.x.x.tar.gz cd bind-9.x.x ./configure --prefix=/usr/local/bind-9.x.x make make install ln -s /usr/local/bind-9.x.x /usr/local/bind

O comando make compila o código-fonte e o comando make install

instala os binários compilados no diretório indicados. O ln -s /usr/local/bind-9.x.0 /usr/local/bind cria um link simbólico chamado /usr/local/bind; este procedimento pode tornar a sua instalação mais versátil, pois caso seja necessário atualizar o BIND, somente será necessário atualizar o link para a versão mais nova.




12











mesmos valores.




www.3way.com.br


Sempre que encontrar algum problema com a compilação e instalação, veja o arquivos README e INSTALL que acompanham o pacote.

3.2.2. INSTALAÇÃO AUTOMATIZADA

Um pacote de instalação é um conjunto de arquivos binários provenientes do código-fonte compilado para uma plataforma específica. Portanto, deve-se utilizar o pacote específico para cada sistema operacional. Outra alternativa é usar ferramentas de gerenciamento de pacotes como o YUM (para CentOS/RedHat) e APT (para Debian/Ubuntu). Essas ferramentas gerenciam a principal desvantagem dos arquivos binários: as dependências.

yum install bind

apt-get install bind9

3.3. HIERARQUIA DNS

O DNS se baseia em um banco de dados distribuído e hierárquico, onde as informações são distribuídas em uma topologia em árvore invertida, onde o ponto de partida para toda consulta de nomes é denominado domínio raiz "." (suportado por vários servidores raízes, ao todo são 13 atualmente). Nenhum servidor raiz responde diretamente à solicitação de resolução de um endereço. Em vez disso, ele delega a responsabilidade de resolver nomes para um outro servidor, delegando parte do domínio (um sub-domínio).

Abaixo do domínio raiz há diversos Domínios de Alto Nível (TLDs - Top Level Domains), sendo os mais conhecidos: o org, net, com e edu (origem americana); alguns domínios de fora dos Estados Unidos que denominam países e possuem somente duas letras: br (Brasil), ar (Argentina), de (Alemanha); entre outros. Segue abaixo um diagrama desta hierarquia:




12











mesmos valores.




www.3way.com.br


Hierarquia DNS

3.3.1 HIERARQUIA DE CONSULTAS DNS

Vários aplicativos são clientes DNS (navegadores, clientes FTP, ping, etc). Se o endereço www.3way.com.br for solicitado pelo serviço FTP, o DNS irá consultar os servidores raízes sobre o sub-domínio br., no caso este servidor o conheça, o próximo passo é encontrar o com.br., e assim por diante até atingir o servidor que realmente tem a autoridade do sub-domínio para resolver seus endereços IP.

A figura abaixo ilustra o processo de resolução de nomes para o endereço

www.3way.com.br.




12











mesmos valores.




www.3way.com.br


Hierarquia de consultas DNS Para simular a consulta que o DNS local faz com o servidor raiz, utiliza-se o comando

nslookup (que será estudado detalhadamente mais adiante). 1) O servidor local consulta o servidor raiz; 2) O servidor raiz fornece o(s) servidor(es) responsável(is) pelo domínio .br;

Dentro do prompt do nslookup define-se o servidor a ser consultado, este

será um servidor raiz. nslookup Default Server: localhost Address: 127.0.0.1 >

Por padrão o nslookup utiliza como DNS configurado localmente (/etc/resolv.conf) como consulta (Default Server), neste caso específico o próprio host (localhost) é o DNS padrão. Uma vez executado o nslookup, ele fica aguardando comandos, indicado por um prompt (>).

Simulando o trajeto da figura, deve-se consultar primeiramente um servidor raiz sobre o domínio br e, para isto, consulta-se o arquivo named.ca (arquivo Hints), que é instalado pelo próprio BIND e contém a lista de todos os root hints (servidores raiz). O opção server define o servidor da consulta, neste caso a.root-servers.net.

> server 198.41.0.4 Default Server: a.root-servers.net Address: 198.41.0.4#53 >

A seguir define-se o tipo da consulta. Neste caso uma pesquisa de registros

NS (registros de servidores de nomes) para encontrar o servidor de nomes autoritativo do domínio ".br".

> set type=ns

As versões mais antigas do BIND usavam a instrução set q=ns ao invés de set type=ns.

Todos estes comandos devem ser executados dentro do prompt do nslookup.

O próximo comando pergunta pelos servidores responsáveis pelo br.




12











mesmos valores.




www.3way.com.br


> br. Server: a.root-servers.net Address: 198.41.0.4 Authoritative answers can be found from: br nameserver = NS.DNS.br br nameserver = NS1.DNS.br br nameserver = NS2.DNS.br br nameserver = NS3.NIC.FR br nameserver = NS-EXT.VIX.COM NS.DNS.br internet address = 143.108.23.2 NS1.DNS.br internet address = 200.255.253.234 NS2.DNS.br internet address = 200.19.119.99 NS3.NIC.FR internet address = 192.134.0.49 NS-EXT.VIX.COM internet address = 204.152.184.64

A frase “Authoritative answers can be found from” indica

que as máquinas NS.DNS.br, NS1.DNS.br, NS2.DNS.br, NS3.NIC.FR, e NS-EXT.VIX.COM são os servidores autorizados responsáveis pelo domínio br. Deve-se agora selecionar qualquer uma destas máquinas e prosseguir com a consulta do próximo passo, fornecendo o número IP de um destes servidores de nomes.

> server 143.108.23.2 Default server: NS.DNS.br Address: 143.108.23.2#53

Assim como foi feito para o domínio br., faremos a consulta para o domínio com.br. Vejamos:

> com.br. Server: NS.DNS.br Address: 143.108.23.2#53 com.br nameserver = NS1.DNS.br. com.br nameserver = NS2.DNS.br. com.br nameserver = NS-EXT.VIX.COM. com.br nameserver = NS.DNS.br.

A própria máquina NS.DNS.br, além de responder pelo domínio br. também responde pelo domínio .com.br. Logo, podemos prosseguir a consulta usando o mesmo servidor definido anteriormente, agora para o domínio 3way.com.br.:

> 3way.com.br. Server: NS.DNS.br Address: 143.108.23.2#53 Non-authoritative answer: 3way.com.br nameserver = intranet.3way.com.br. 3way.com.br nameserver = ns.3way.com.br.




12











mesmos valores.




www.3way.com.br


Authoritative answers can be found from: intranet.3way.com.br internet address = 200.163.79.1 ns.3way.com.br internet address = 200.178.101.252

Descobrimos, neste caso, que o hospedeiro intranet.3way.com.br é o servidor de nomes primário (é o primeiro da lista) pelo domínio 3way.com.br e seu endereço IP é 200.163.79.1. Ainda existe outro hospedeiro responsável pelo domínio 3way.com.br, que é o hospedeiro ns.3way.com.br,também denominada como o servidor secundário do domínio 3way.com.br.

Prosseguindo com o processo, o próximo servidor é o host intranet.3way.com.br que será definido como servidor de consulta:

> server 200.163.79.1 Default server: 200.163.79.1 Address: 200.163.79.1#53 Agora só falta consultar o servidor responsável diretamente pelo domínio 3way.com.br

sobre o nome www.3way.com.br. > www.3way.com.br Server: 200.163.79.1 Address: 200.163.79.1#53 www.3way.com.br canonical name = intranet.3way.com.br.

O nome www.3way.com.br é apenas um apelido (alias) para o nome canônico (real) do hospedeiro intranet.3way.com.br, ou seja, ambas são a mesma máquina. Caso contrário, o comando retornaria simplesmente o endereço IP de www.3way.com.br.




12











mesmos valores.




www.3way.com.br


3.3.2. CACHE DE CONSULTAS

Sistema cache de consulta.

Um conceito também importante a ser compreendido, é que o servidor de nomes armazena

todas as consultas realizadas em cache de memória por um período estipulado pelo fornecedor da consulta. Este período é denominado TTL (Time-To-Live, o qual será visto mais adiante), de forma que quando este tempo expira, a informação da consulta é retirada do próprio cache. Assim, quando o cliente necessita de uma informação, se o servidor de nomes já possui a consulta em cache, este não irá consultar seus superiores na hierarquia. Assim evita-se consultar um servidor raiz ou outro servidor acima na hierarquia em toda consulta.

3.4. O ARQUIVO NAMED.CA

Este arquivo contém uma lista de nomes de servidores raízes, espalhados em todo o mundo e é usado pelo seu servidor DNS como ponto de partida de consulta. É fortemente recomendável não editar ou modificar este arquivo, a não ser para atualizar suas informações que são raramente alteradas.

O local desse arquivo depende da distribuição ou de como o bind foi instalado, mas não será difícil encontrá-lo. Normalmente ele estará em /var/named/named.ca ou caso ele estiver em uma jaula chroot em /var/named/chroot/var/named/named.ca.

/var/named/chroot/var/named/named.ca

; formerly NS.INTERNIC.NET ;




12











mesmos valores.




www.3way.com.br


. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10

Este arquivo contém apenas registros de servidor de nome (NS) e de endereço (A). Cada um destes registros NS identifica um Servidor de Nome (Name Server) para o domínio raiz que é dominado com um (.). O registro A define o endereço IP dos Servidores de Nomes Raízes.




12











mesmos valores.




www.3way.com.br


3.5. CONFIGURANDO O CLIENTE DNS

Utilização da biblioteca resolver na resolução de nomes.

O pacote BIND fornece uma biblioteca chamada resolver, que é

considerada o cliente DNS, pois é através dela é que vários programas fazem suas operações de resolução de nome para número IP e vice-versa. A configuração do cliente resume-se em definir o endereço do servidor DNS que fará a resolução das consultas.

3.5.1. DEFINIR O SERVIDOR DE DNS

Para definir o servidor a ser consultado, deve-se editar o arquivo /etc/resolv.conf. Vejamos um exemplo do arquivo /etc/resolv.conf:

/etc/resolv.conf search 3waylocal.net.br nameserver 192.168.1.101 nameserver 192.168.1.102

A opção search é seu domínio de pesquisa padrão, ou seja, ao entrar com o host maq10 com

o telnet ( ) será a mesma coisa que utilizar maq10.3waylocal.net.br. O parâmetro nameserver define o endereço IP do servidor de nomes que a máquina irá utilizar para fazer consultas.

Caso a própria máquina for um servidor DNS e quiséssemos usá-lo para consultas, bastaria entrar com o endereço IP da máquina local ou ip de loopback no arquivo /etc/resolv.conf:




12











mesmos valores.




www.3way.com.br


/etc/resolv.conf search 3waylocal.net.br nameserver 127.0.0.1

Para obter o IP do servidor de nomes de um determinado domínio, digitar: host -l dominio.com.br

Para saber mais informações sobre o utilitário host, basta consultar o manual do comando host. Ex.: man host

3.5.2. DEFINIR A ORDEM DE CONSULTA

Existem dois métodos de resoluções de nomes: o arquivo /etc/hosts e o DNS. A definição da ordem de quais serão utilizados está no arquivo /etc/nsswitch.conf e em versões mais antigas /etc/host.conf.

/etc/nsswitch.conf hosts: files dns A diretiva hosts define a ordem de consulta, que neste caso é primeiramente será feito a

consulta no arquivo (/etc/hosts) para somente depois consultar o DNS (bind) no caso do arquivo não consiga resolver o nome.

/etc/host.conf order hosts,bind multi on

No /etc/host.conf, a opção multi on permite que uma mesma máquina tenha múltiplos endereços IPs (o DNS por padrão já suporta esta opção).

3.6. ZONAS E DOMÍNIOS

No estudo de servidores de domínio surge o termo zona (zone) que é comumente confundida com o termo domínio (domain).

Domínio Define um espaço de nomes onde encontra-se várias zonas. Zona É definida como uma região de um domínio, pode ser entendida como um sub-domínio.

Por exemplo o domínio .br tem uma possível zona chamada com.br, enquanto esta zona pode ser




12











mesmos valores.




www.3way.com.br


um domínio para outras possíveis zonas como: 3way.com.br ou teste.com.br.

Entendendo Zona e Domínio

Domínio e sub-domínio (zona) faz analogia com diretório e sub-diretório

quando refere-se a sistemas de arquivo.

3.7. SERVIDORES DNS

Existem basicamente três tipos de servidores DNS: o servidor caching (caching-server), o servidor primário (master server) e o servidor secundário (slave server).

Servidor caching Definido como um servidor que guarda em cache consultas que já foram

anteriormente solicitadas, não sendo responsável por nenhuma zona, de forma a melhorar a performance da resolução de nomes.

Servidor Primário É um servidor autorizado (que tem autoridade sobre uma zona), ou seja, que

mantém a base de dados de uma determinada zona. Este servidor além de fazer consultas a servidores raízes também é consultado por outros servidores DNS como




12











mesmos valores.




www.3way.com.br


responsável pela zona em que foi delegada. Servidor Secundário Este servidor é definido como uma cópia do servidor primário. É utilizado

pelos clientes quando o servidor master, por algum motivo, parar de funcionar.

Três tipos de servidores DNS.

Cinco arquivos diferentes são necessários para a configuração do named.

Todas as configurações requerem estes três arquivos básicos: named.conf, named.ca, named.local e os arquivos de zona e zona reversa.

named.conf É o arquivo de configuração principal. Define parâmetros básicos e aponta

para as fontes de informação do banco de dados do domínio (arquivos locais ou servidores remotos). Os arquivos hints e localhost reverso (named.ca e named.local, respectivamente) que vão ser citados a seguir são exemplos de arquivos de banco de dados.

named.ca Fornece os nomes e endereços dos servidores de nomes raízes (root servers). named.local É o arquivo localhost reverso. Por padrão o arquivo /etc/hosts, só tem uma




12











mesmos valores.




www.3way.com.br


entrada para indicar que o nome localhost ou localhost.localdomain refere-se ao IP 127.0.0.1. Este arquivo indicando que o IP 127.0.0.1 é refere-se ao nome localhost.

Arquivo de zona É usado para mapear os nomes de hosts para endereços IP, para identificar

servidores de mensagem e para fornecer uma variedade de outras informações de domínio.

Arquivo de zona reversa Este arquivo é utilizado para mapear endereços IPs para nomes de hosts. Ele

faz o serviço contrário ao arquivo zone.

3.8. SERVIDOR DE CACHE

A instalação do servidor cache se dá com a instalação dos seguintes pacotes: bind-libs, bind-utils e bind.

yum install bind bind-utils bind-libs caching-nameserver

apt-get install bind9 bind9-docs dnsutils

Este tipo de servidor necessita de três arquivos de configuração: named.conf, named.ca e

named.local. Os procedimentos para configuração estão descritos abaixo: Especificar o diretório para o ambiente chroot (/var/named/chroot) na variável

ROOTDIR do arquivo /etc/sysconfig/named. /etc/sysconfig/named ROOTDIR=/var/named/chroot

Fazer uma cópia do arquivo /etc/named.caching-nameserver.conf com nome

named.conf no o diretório etc do ambiente chroot (/var/named/chroot/var/named) e mudar a propriedade desse arquivo para root.named. Agora é só criar um link simbólico para o /etc.

cp /etc/named.caching-nameserver.conf /var/named/chroot/etc/named.conf chgrp .named /var/named/chroot/etc/named.conf ln –sf /var/named/chroot/etc/named.conf /etc/named.conf




12











mesmos valores.




www.3way.com.br


Iniciar o serviço. /etc/init.d/named start

named.conf O arquivo named.conf tem uma sintaxe baseada em sentenças (statements), com opções

para cada sentença em um bloco delimitado por chaves ({}). Cada opção também tem uma sintaxe específica para determinar seus argumentos. Os arquivos de configuração do BIND, suporta comentários em bloco, no estilo C++ (/* comentário */); comentários de linha, no estilo C++ (// comentário); comentários no estilo perl ou bash (# comentário); e finalmente, comentários de linha utilizando-se ponto-e-vírgula no início do comentário (; comentário). Veja como é a estrutura deste arquivo:

/* Este é um bloco de comentário, estilo C++ */ <sentença1> <argumentos_sentença1> { // Isto também é um comentário, mas de somente uma linha. Estilo C++

<opção1> <argumentos1>; <opção2> <argumentos2>; }; <sentença2> <argumentos_sentença2> { ; isto também é um comentário # esta também é outra opção de comentário. Estilo bash ou perl. <opção1> <argumentos1>; <opção2> <argumentos2>; }

Abaixo temos um exemplo concreto: /etc/named.conf options { listen-on port 53 { 127.0.0.1; IP_DA_INTERFACE; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; }; allow-query-cache { localhost; }; }; acl local_nets { ENDEREÇO_DA_REDE_LOCAL; }; view localhost_resolver { match-clients { localhost; }; match-destinations { localhost; }; recursion yes; include "/etc/named.rfc1912.zones"; }; view rede_local {




12











mesmos valores.




www.3way.com.br


match-clients { localhost; local_nets; }; allow-query { localhost; local_nets; }; allow-query-cache { localhost; local_nets; }; allow-recursion { localhost; local_nets; }; include "/etc/named.rfc1912.zones"; };

As únicas mudanças na configuração do named.conf a serem feitas são na

diretiva listen-on para especificar o endereço IP da interface de rede que receberá as requisições, a criação da view rede_local habilitando a rede local a fazer consultas e a acl local_nets para especificar quais serão as redes locais a serem configuradas. Após essas configurações deve-se inicializar o serviço de DNS.

/etc/init.d/named start

O servidor já está atendendo às solicitações dos clientes configurados. Pode-

se definir, para efeitos de teste, o próprio servidor como cliente de si mesmo no /etc/resolv.conf.


Para testar o servidor basta executar o comando abaixo: nslookup Default Server: localhost Address: 127.0.0.1 > www.ufg.br Server: localhost Address: 127.0.0.1 Name: www.ufg.br Address: 200.137.221.67

O servidor de cache retornou corretamente o endereço que foi solicitado e isso ocorrerá para qualquer endereço válido na Internet, pois este consultará os servidores raízes, e estes, por sua vez, consultarão os servidores de nível mais abaixo na hierarquia até chegar nos responsáveis por determinado domínio. No entanto, ele não será capaz de resolver nomes da rede local. Para resolver esse tipo de consulta, será precisará criar um servidor primárrio que responda por essa rede.

3.9. SERVIDOR PRIMÁRIO

A configuração do servidor primário será feita em uma máquina cujo hostname será ns1.3waylocal.net.br. O arquivo /etc/named.conf desta máquina deverá ser semelhante ao que está logo abaixo.




12











mesmos valores.




www.3way.com.br


/etc/named.conf options { listen-on port 53 { 127.0.0.1; IP_DA_INTERFACE; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; }; allow-query-cache { localhost; }; }; acl local_nets { ENDEREÇO_DA_REDE_LOCAL; }; view localhost_resolver { match-clients { localhost; }; match-destinations { localhost; }; recursion yes; include "/etc/named.rfc1912.zones"; zone "DOMINIO_A_SER_IMPLEMENTADO" { type master; file "NOME_ARQUIVO_DE_ZONA"; allow-transfer { none; }; }; zone "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST.in-addr.arpa" { type master; file "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST.in-addr.arpa"; allow-transfer { none; }; }; }; view rede_local { match-clients { localhost; local_nets; }; allow-query { localhost; local_nets; }; allow-query-cache { localhost; local_nets; }; allow-recursion { localhost; local_nets; }; include "/etc/named.rfc1912.zones"; zone "DOMINIO_A_SER_IMPLEMENTADO" { type master; file "3waylocal.net.br.direto"; allow-transfer { none; }; }; zone "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST.in-addr.arpa" { type master; file "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST.in-addr.arpa"; allow-transfer { none; }; }; };




12











mesmos valores.




www.3way.com.br


Nesta nova configuração do arquivo surgem as zonas dominio_a_ser_implementado e a endereço_inverso_de_rede-sem_parte_de_host.in-addr.arpa. Pode-se observar a ocorrência da instrução file que define o arquivo da base de dados de domínio. Nesta base de dados encontram-se os RRs (Registros de Recursos) do DNS que definem servidores de nomes, endereço IP de hosts, etc. Esses registros são usados quando se cria os arquivos de banco de dados, tanto primário quanto secundário.

3.9.1 REGISTROS DE RECURSOS

Registros de Recursos são também conhecidos e abreviados por RR. Formato: [name] [ttl] IN type data

Onde: name Identifica o objeto de domínio afetado por este registro. Pode ser um host individual ou

domínio inteiro. ttl Este campo é chamado de time-to-live, que define a duração em segundos que este

registro de recurso deve ser mantido em memória (cache) por outros servidores DNS externos que fizerem consultas no servidor. Um valor TTL baixo é adequado para RRs com maior freqüência de mudança. TTL muito baixo gera um aumento de tráfego para o servidor.

Alguns servidores definem alguns valores TTL como zero, para que servidores externos não armazenem em cache. Um valor de 43200 (12 horas) mantém a consulta realizada em cache por 43200 segundos até a sua expiração.

class Existem três valores possíveis para este campo: IN, HS, CH. Atualmente é utilizado apenas

o IN que é característico de redes TCP/IP e servidores Internet. Os outros dois possíveis são padrões antigos de redes.

type Este campo define o tipo do registro fonte. Veja abaixo os mais comuns.

Nome do Registro Tipo Descrição

Início de Autoridade [Start Of Authority]

SOA Marca o começo dos dados de zona e define parâmetros globais

Servidor de Nomes e Domínio [Name Server]

NS Identifica um servidor de nomes autorizado.




12











mesmos valores.




www.3way.com.br


Nome do Registro Tipo Descrição

Endereço [Address] A Converte nome de hospedeiro - host - para endereço IP

Ponteiro [Pointer] PTR Converte endereço IP para um nome de hospedeiro-host.

Mail Exchanger [Repassador de email] MX Identifica o servidor de email para este domínio

data Este último campo no registro de recurso é o campo de dados, o mesmo comporta os dados

que são específicos para cada tipo de registro de recurso, ou seja, cada formato e dado deste campo é diferente para cada tipo de registro, exemplo: em um tipo de registro A o campo data deve conter o endereço IP.

3.9.2 O ARQUIVO DE RR

O RR (Registro de Recurso) é o identificador de cada registro. Dentre outras coisas, sua principal finalidade é converter nomes de hosts em endereços IP. Dando continuidade ao exemplo, na máquina maq1, que será o servidor basta executar os passos abaixo.

Crie o arquivo com nome referente a instrução file que está na zona

3waylocal.net.br. Logo o arquivo deve ser criado no diretório /var/named/ (ou a esse diretório relativo à jaula) e deve conter o nome 3waylocal.net.br.direto.

$TTL 43200 @ IN SOA 3waylocal.net.br. root.3waylocal.net.br. ( 2012011702 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN MX 10 maq1.3waylocal.net.br. @ IN NS maq1.3waylocal.net.br. @ IN NS maq2.3waylocal.net.br. maq1 IN A 192.168.1.101 maq2 IN A 192.168.1.102 maq3 IN A 192.168.1.103 maq4 IN A 192.168.1.104 maq5 IN A 192.168.1.105 maq6 IN A 192.168.1.106 maq7 IN A 192.168.1.107 www IN CNAME maq1 ns1 IN CNAME ns1

Nas versões mais recentes do BIND, foi acrescentado a possibilidade de se

declarar diretivas. As diretivas são de sintaxe $DIRETIVA <valor> e são declaradas na primeira linha do arquivo de zona. Na primeira linha temos como primeiro caso o




12











mesmos valores.




www.3way.com.br


parâmetro $TTL 43200. Esta entrada define o tempo de vida padrão para os registro de recursos que vierem definidos no arquivo. Em seguida teremos os registro de recursos, na sintaxe definida anteriormente.

Registro SOA

Esse registro define informações sobre a autoridade. O parâmetro @ faz referência ao domínio da zona definido no arquivo /etc/named.conf, ou seja, ele se refere ao domínio 3waylocal.net.br. Outro parâmetro desta linha define o inicio de autoridade - SOA -, o nome de máquina maq1.3waylocal.net.br define o servidor que tem “Autoridade sobre a zona”. Já root.3waylocal.net.br define o endereço de e-mail da pessoa responsável por este domínio, neste arquivo o @ do email é substituído um (.), pois como visto, o @ tem outra finalidade.

Em seguida tem-se: 2012011702 Este é o número serial que diz ao servidor secundário (slave) se este arquivo de registro

de recurso foi atualizado. Toda vez que o DNS for atualizado, deve-se alterar este número para um número maior para que seja detectada pelo secundário que houve alteração, então a atualização ocorrerá dinamicamente. Não existe uma regra para edição desse número, na verdade existem algumas práticas mais difundidas. O exemplo acima representa 2012 (ano), 01 (Janeiro), 17 (dia) e 02 (segunda edição do dia). Porém é possível também iniciar com o número 1 e simplesmente incrementá-lo em uma unidade toda vez que for feita uma alteração.

3600 Este é o período em segundos que o secundário verifica o serial e consequentemente faz a

atualização. 900 Este é o ciclo de tentativas. O ciclo de tentativas determina o tempo que o servidor slave

deve esperar por uma nova solicitação quando o servidor primário falhar na resposta de um registro SOA.

1209600 Este é o tempo limite, o período em segundos que o servidor secundário deve continuar

respondendo mesmo que não consiga atualizar o arquivo zone, ou seja, mesmo que o servidor mestre não esteja respondendo.

43200 Define o tempo de vida (time-to-live) em segundos que outro servidor de nomes irá

armazenar em cache a informação de uma consulta de domínio não existente (no such domain – NXDOMAIN).

Registro NS - definindo servidores de nome O RR NS define os servidores de nome oficiais para o domínio. Neste exemplo

encontramos dois servidores de nome. O primeiro nome, maq1 é o servidor de nomes primário e




12











mesmos valores.




www.3way.com.br


maq2.3waylocal.net.br é o secundário. Registro MX - definindo Servidores de Mensagens O RR MX define os servidores de mensagens para este domínio. Neste caso a máquina

maq1 também é o servidor de mensagens. Os registros MX redirecionam mensagens endereçadas para o domínio 3waylocal.net.br. A título de ilustração, todo e-mail enviado para [email protected] será recebido pela máquina maq1 e pode ser repassado de acordo com a configuração do servidor de mensagens para outros hosts. O número existente após MX define a prioridade do servidor de email. Quanto menor for o número, maior será a prioridade do servidor.

Registro A - Definindo os hosts e seus IPs Acima de todas as funções o objetivo final deste arquivo é mapear nomes para endereços

IP. Tem-se um exemplo das próximas linhas do arquivo: maq1 IN A 192.168.1.101 Podemos traduzir esta linha para: Máquina maq1 em rede TCP/IP possui endereço IP

192.168.1.101. Registro CNAME Este registro é utilizado para atribuir apelidos (aliases) para um host. CNAME indica qual

é o nome canônico para um alias. Nome canônico é o nome real da máquina. Deve-se notar que um nome canônico sempre tem um registro A associado para definir o seu endereço IP, portanto um registro CNAME sempre é acompanhado de um host que teve seu número IP referenciado por um registro A, nunca outro alias.

3.10. ARQUIVO DA ZONA REVERSA

Assim como o DNS é capaz de converter nomes para endereço IP, o DNS também é capaz de converter números IP para nomes. Alguns serviços, como por exemplo o ftp, utilizada a resolução reversa para registrar o nome do host cliente ftp em vez de seu número ip em seu histórico (log) .

Para que o DNS forneça este serviço precisamos criar o arquivo da base de dados da zona reversa. Antes disto, devemos criar uma zona reversa no arquivo /etc/named.conf e posteriormente criar o arquivo de banco de dados.

A zona reversa já foi criada com nome de 1.168.192.in-addr.arpa. Esse também é o arquivo da base de dados definido para esta zona, seu o nome é 1.168.192.in-addr.arpa.reverso, embora possa ser utilizado qualquer outro nome.

Através do arquivo named.conf e da zona definida no exemplo, deve-se

criar este arquivo dentro do diretório /var/named, o arquivo deverá ter o nome 0.168.192.in-addr.arpa.reverso. Segue abaixo a configuração deste




12











mesmos valores.




www.3way.com.br


arquivo: $TTL 43200 @ IN SOA 3waylocal.net.br. root.3waylocal.net.br. ( 2012011702 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN NS maq1.3waylocal.net.br. 101 IN PTR maq1.3waylocal.net.br. 102 IN PTR maq2.3waylocal.net.br. 103 IN PTR maq3.3waylocal.net.br. 104 IN PTR maq4.3waylocal.net.br. 105 IN PTR maq5.3waylocal.net.br. 106 IN PTR maq6.3waylocal.net.br. 107 IN PTR maq7.3waylocal.net.br.

O arquivo da base de dados da zona reversa também possui um registro SOA

e um NS, geralmente os mesmos parâmetros utilizados no arquivo de banco de dados de zona. A finalidade da resolução reversa é se obter o nome canônico de um host, baseado em IP. Para isto utiliza-se o registro de recurso PTR, que associa um endereço IP a um nome de host. O endereçamento reverso utiliza um domínio fictício convencionado como in-addr.arpa e um número IP na forma reversa.

Depois de feito todo esse procedimento, basta reiniciar o serviço.

/etc/init.d/named restart

/etc/init.d/bind9 restart

Durante e até depois inicializar o named, é interessante verificar possíveis

erros. Isso pode ser feito verificando o arquivo de logs principal. tail -n20 /var/log/messages Jan 17 16:02:10 maq1 named[848]: master zone "3waylocal.net.br" (IN) loaded

(serial 2012011702) Jan 17 16:02:10 maq1 named[848]: Zone "0.168.192.in-addr.arpa" (file

0.168.192.in-addr.arpa.reverso): No default TTL set using SOA minimum instead Jan 17 16:02:10 maq1 named[848]: master zone "0.168.192.in-addr.arpa" (IN) loaded (serial 2012011702) Jan 17 16:02:10 maq1 named[848]: listening on [127.0.0.1].53 (lo)




12











mesmos valores.




www.3way.com.br


Jan 17 16:02:10 maq1 named[848]: listening on [192.168.1.101].53 (eth0) Jan 17 16:02:10 maq1 named[848]: Forwarding source address is [0.0.0.0].1024 Jan 17 16:02:10 maq1 named[849]: group = named Jan 17 16:02:10 maq1 named[849]: user = named Jan 17 16:02:10 maq1 named[849]: Ready to answer queries. Jan 17 16:02:10 maq1 named: named startup succeeded

Caso a saída do comando não registre nenhum erro a configuração está

correta.

O arquivo /etc/resolv.conf do servidor deve ficar com a seguinte configuração:


search 3waylocal.net.br Este parâmetro é utilizado quando se digitar apenas o nome da máquina, o domínio

3waylocal.net.br será automaticamente acrescentado. nameserver 127.0.0.1 Indica a utilização do endereço 127.0.0.1 para que o servidor utilize seu próprio

endereço. Nas máquinas clientes devem ser colocados o endereço IP do servidor.

3.11. FERRAMENTAS DE TESTE

3.11.1. NSLOOKUP

Para verificar o funcionamento do servidor DNS é interessante usar o utilitário nslookup, que faz pesquisas interativas e não-interativas em servidores DNS.

Sintaxe: nslookup [-opções ... ] [host_a_ser_encontrado | -[servidor ] ]

Exemplo: nslookup Default Server: localhost Address: 127.0.0.1 > maq1.3waylocal.net.br Server: localhost Address: 127.0.0.1 Name: maq1.3waylocal.net.br Address: 192.168.1.101




12











mesmos valores.




www.3way.com.br


Para conhecer as opções do comando é interessante ler o manual do comando: man nslookup

3.11.2. DIG

O DIG é um utilitário para consultas a DNS. Ele é utilizado para identificar problemas de DNS, pois é de fácil utilização e o retorno das pesquisas é bem compreensível.

Sintaxe: dig @servidor dominio_a_ser_consultado tipo_consulta

Exemplo: dig @192.168.1.101 www.ufg.br A

Vale a pena consultar no manual do comando a procura de mais tipos de consultas, pois eles é que vão dar a qualidade nas respostas.

man dig

3.12. SERVIDOR SECUNDÁRIO

Este tipo de servidor é considerado também um servidor autoritativo, pois tem um completo banco de dados de domínio que ele transfere do servidor primário.

O servidor primário extrai seus dados diretamente de seus arquivos de registro

de banco de dados (arquivos locais), enquanto o servidor secundário carrega os dados por meio de outro servidor DNS, através de um processo chamado de transferência de zona.

A grande vantagem de utilizar o servidor secundário é a manutenção do

servidor. Com o servidor secundário você precisa manter a informação atualizada apenas no servidor primário, pois o servidor secundário faz uma transferência de zona do servidor primário. Alterando o servidor primário esta configuração será refletida consequentemente no servidor secundário, assim a manutenção é totalmente centralizada no servidor primário.




12











mesmos valores.




www.3way.com.br


Servidor secundário interagindo com o primário

Para configurar o named.conf do servidor escravo, você pode partir do servidor de cache e adicionar mais duas zonas.

Partindo-se do servidor de cache todas as alterações estão em negrito, ou seja, as que devem ser alteradas ou adicionadas.

/etc/named.conf options { listen-on port 53 { 127.0.0.1; IP_DA_INTERFACE; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; }; allow-query-cache { localhost; }; }; acl local_nets { ENDEREÇO_DA_REDE_LOCAL; }; view localhost_resolver { match-clients { localhost; }; match-destinations { localhost; }; recursion yes; include "/etc/named.rfc1912.zones"; zone "DOMINIO_A_SER_IMPLEMENTADO" { type slave; file "slaves/NOME_ARQUIVO_DE_ZONA"; masters { ENDEREÇO_DO_PRIMARIO; }; }; zone "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST.arpa"




12











mesmos valores.




www.3way.com.br


{ type slave; file "slaves/ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST.in-

addr.arpa"; masters { ENDEREÇO_DO_PRIMARIO; }; }; }; view interna { match-clients { localhost; local_nets; }; allow-query { localhost; local_nets; }; allow-query-cache { localhost; local_nets; }; allow-recursion { localhost; local_nets; }; include "/etc/named.rfc1912.zones"; zone "DOMINIO_A_SER_IMPLEMENTADO" { type slave; file "slaves/NOME_ARQUIVO_DE_ZONA"; masters { ENDEREÇO_DO_PRIMARIO; }; }; zone "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST-addr.arpa" { type slave; file "slaves/ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST.in-

addr.arpa"; masters { ENDEREÇO_DO_PRIMARIO; }; }; };

É importante ressaltar que o servidor primário também deve sofrer alterações que permitam que os secundários realizem transferências de zona. Isso é feito inserindo-se os endereços IP dos servidores secundários na diretiva allow-transfer do primário. Agora é só reiniciar o servidor.

É importante verificar os logs, como foi dito anteriormente, a procura da causa de eventuais erros. Na maioria absoluta dos casos é possível identificá-los.




12











mesmos valores.




www.3way.com.br


3.15. LABORATÓRIO Essa prática tem como objetivo implementar uma estrutura de servidores DNS (primário e secundário) para o domínio 3wayteste.net. Siga os passos a seguir pra concluir essa atividade. Antes de iniciar será preciso mudar o hostname na sessão atual (com o comando hostname), em /etc/sysconfig/network e /etc/hosts, para finalizar editar o resolver para o próprio servidor no /etc/resolv.conf.

hostname maq1.3wayteste.net

/etc/sysconfig/network HOSTNAME=maq1.3wayteste.net

/etc/hosts 127.0.0.1 maq13wayteste.net maq1 localhost.localdomain localhost

/etc/resolv.conf search 3wayteste.net nameserver 127.0.0.1

/etc/nsswitch.conf hosts: dns files

A) Instalação dos pacotes necessários à implementação (servidor primário e secundário).

yum install bind bind-libs bind-utils caching-nameserver

B) Configurar o dns incluindo uma view interna para que as máquinas da rede local possam utilizar o servidor DNS.

/etc/named.conf options { listen-on port 53 { 127.0.0.1; IP_DA_INTERFACE; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; }; allow-query-cache { localhost; }; }; acl local_nets { 192.168.1.0/24; }; view localhost_resolver { match-clients { localhost; }; match-destinations { localhost; }; recursion yes; include "/etc/named.rfc1912.zones"; zone "3waynet.net" { type master; file "3waynet.net.direto";




12











mesmos valores.




www.3way.com.br


}; zone "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST-addr.arpa" { type master; file "1.168.192.in-addr.arpa"; }; }; view interna { match-clients { localhost; local_nets; }; allow-query { localhost; local_nets; }; allow-query-cache { localhost; local_nets; }; allow-recursion { localhost; local_nets; }; include "/etc/named.rfc1912.zones"; zone "3waynet.net" { type master; file "3waynet.net.direto"; }; zone "ENDEREÇO_INVERSO_DE_REDE-SEM_PARTE_DE_HOST-addr.arpa" { type master; file "1.168.192.in-addr.arpa"; }; };

C) Inicie o servidor caching. /etc/init.d/named start

D) Partindo-se da configuração da configuração de caching podemos iniciar a configuração do servidor primário. Mas para isso, adapte o named.conf como o exposto abaixo.

/etc/named.conf ... view localhost_resolver { match-clients { localhost; }; match-destinations { localhost; }; recursion yes; include "/etc/named.rfc1912.zones"; zone "3wayteste.net" { type master; file "3wayteste.net.direto"; }; zone "1.168.192.in-addr.arpa" { type master; file "1.168.192.in-addr.arpa"; }; }; view interna { match-clients { localhost; local_nets; }; allow-query { localhost; local_nets; }; allow-query-cache { localhost; local_nets; }; allow-recursion { localhost; local_nets; }; include "/etc/named.rfc1912.zones"; zone "3wayteste.net" { type master; file "3wayteste.net.direto";




12











mesmos valores.




www.3way.com.br


}; zone "1.168.192.in-addr.arpa" { type master; file "1.168.192.in-addr.arpa"; }; };

E) Em seguida crie os arquivos de zona do servidor primário.

/var/named/3wayteste.net.direto $TTL 43200 @ IN SOA 3wayteste.net. webmaster.3wayteste.net. ( 2012012201 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN MX 5 maq1.3wayteste.net. @ IN NS maq1.3wayteste.net. @ IN NS maq2.3wayteste.net. maq1 IN A 192.168.1.101 maq2 IN A 192.168.1.102 maq3 IN A 192.168.1.103 maq4 IN A 192.168.1.104 www IN CNAME maq1 ns1 IN CNAME maq1 mail IN CNAME maq1 ns2 IN CNAME maq2

/var/named/1.168.192.in-addr.arpa $TTL 43200 @ IN SOA 3wayteste.net. webmaster.3wayteste.net. ( 2012012201 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN NS maq1.3wayteste.net. 101 IN PTR maq1.3wayteste.net. 102 IN PTR maq2.3wayteste.net. 103 IN PTR maq3.3wayteste.net. 104 IN PTR maq4.3wayteste.net.

F) Até este ponto já podemos reiniciar o servidor de nomes para verificar o funcionamento. /etc/init.d/named restart

G) Caso não ocorra nenhum erro de implementação, os testes podem ser feitos localmente ou a partir de outras máquinas.

Local Tendo como certa as configurações do item anterior. Teste a conectividade com quaisquer máquinas configuradas nos arquivos de zona. ping aluno1 ping aluno4

Remotos




12











mesmos valores.




www.3way.com.br


A partir de outra máquina (que não seja o servidor DNS), configure o resolver para resolver consultas através do seu servidor DNS e execute os mesmos testes. /etc/resolv.conf search 3wayteste.net nameserver 192.168.1.101 ping aluno3




12











mesmos valores.




www.3way.com.br


3.16. EXERCÍCIOS

1) Qual é a definição de DNS? Qual é sua principal finalidade? Quais os tipos de servidores de DNS existem e quais suas principais características?

2) Qual a diferença entre zona e domínio?

3) Defina Servidor Autorizado.

4) Qual a diferença entre um servidor de nomes: caching, primário [master] e secundário [slave]?

5) Suponha que necessitamos de configurar um domínio chamado teste.com.br, para um servidor de nomes primário de nome ns.teste.com.br e endereço IP 200.1.2.3. O endereço IP deste servidor é 200.1.2.3 e o IP do servidor web deste domínio é o mesmo do servidor secundário de nome ns2.teste.com.br, com número IP 200.1.2.4. E o servidor SMTP (mail) é o mesmo do DNS primário. Apresente a configuração para esta situação, indicando quais são e um possível conteúdo destes arquivos.

6) O que são RR - Registros de Recursos? Qual é a sintaxe? Para que servem? Cite e explique alguns tipos de RRs.

7) Qual é a função dos servidores de nome raízes [root-servers]? Por que eu preciso de manter um arquivo dos endereços IP's dos servidores de nome raízes? Como eu posso atualizar este arquivo?

8) Qual é a função da diretiva $TTL? Qual é a vantagem e a desvantagem de se ter um valor de TTL - Time To Live - alto ou baixo?




12











mesmos valores.




www.3way.com.br


4. DHCP

Este capítulo trata o protocolo DHCP (servidor e cliente) que permitem que configurações de rede TCP/IP sejam atribuídas dinamicamente para estações de trabalho de uma rede.

4.1. PROTOCOLO DHCP

Processo de requisição de configurações TCP/IP

DHCP é um acrônimo para Protocolo de Configuração Dinâmica de

Computador (Dinamic Host Configuration Protocol). É um protocolo cliente/servidor, que possibilita computadores clientes recebam configurações TCP/IP dinamicamente. Esta funcionalidade tem muita importância em grandes redes, pois o controle das configurações TCP/IP são feitas de forma centralizada, tornando esta configuração praticamente transparente para o administrador.

O cliente quando iniciado, envia um pedido de configuração (request) em broadcast e espera a resposta de um servidor. O pedido de configuração deve obrigatoriamente conter solicitação de um endereço IP e máscara de sub-rede, podendo também solicitar roteador padrão, nome de domínio de pesquisa, servidor DNS, etc. E a resposta do servidor são as informações específicas propriamente ditas. O servidor escuta a porta 67 e transmite na porta 68.

Uma vez que o cliente, antes da inicialização, não possui endereço IP, como




12











mesmos valores.




www.3way.com.br


ele pode comunicar com o servidor? Na verdade, toda comunicação inicial entre o cliente e o servidor independe do protocolo IP, utilizando protocolo a nível de enlace (camada 2) para que um cliente e o servidor negocie os parâmetros de configuração necessários. Esta negociação é realizada por mensagens transmitidas por difusão (broadcast) na sub-rede, sendo limitada a estações fisicamente conectadas na mesma rede. Uma vez estabelecido esta negociação inicial, a comunicação pode ser baseada no protocolo IP.

O DHCP é baseado no protocolo BOOTP (camada 2). Esse protocolo permite

que estações sem disco rígido inicializem-se através da rede. O protocolo DHCP é considerado como uma extensão do BOOTP, por ser apenas um sub-conjunto do complexo protocolo BOOTP.




12











mesmos valores.




www.3way.com.br


Arquitetura Cliente/Servidor do DHCP

O DHCP também é um protocolo essencial para provedores Internet, uma vez

que permite que clientes obtenham dinamicamente seus parâmetros quando se conectam no provedor, via linha discada, por exemplo. Assim, toda vez que um cliente estabelece uma conexão com o servidor, geralmente um novo endereço IP é obtido. Se o DHCP não for utilizado, todo cliente seria configurado estaticamente, cada um com um número IP exclusivo, o que na prática seria inviável. Para um provedor com 1000 clientes, por exemplo, deveria se ter disponível 1000 endereços IP's, o que seria impraticável levando-se em conta a escassez dos endereços IP. Além disto, seria totalmente inviável a administração destes IPs, com a entrada e saída de novos clientes.

Não existem muitas implementações de DHCP para Linux licenciados sob a GPL, talvez seja devido ao grande sucesso do DHCP do ISC, disponível em quase todas as distribuições Linux. Além deste software além de ser considerado muito bom, é totalmente disponibilizado sob a GPL.

4.2 INSTALANDO O DHCP

O DHCP está disponível em diversos formatos: código fonte do programa, arquivos pré-compilados (binários) RPM / DEB e ferramentas avançadas como




12











mesmos valores.




www.3way.com.br


YUM / APT.

4.2.1. INSTALAÇÃO CÓDIGO FONTE O código-fonte está disponível no endereço www.isc.org. Esta implementação

engloba o servidor dhcpd, assim como o cliente dhclient. cp dhcp-versao.tar.gz /usr/local/src cd /usr/local/src tar xvfz dhcp-versao.tar.gz cd dhcp-versao ./configure make make install

Este comando instala o daemon em /usr/sbin/dhcpd, o cliente em

/usr/sbin/dhclient, o arquivo de configuração em /etc/dhcpd.conf, etc.


Os pacotes RPMs são disponibilizados por várias distribuições, tais como, CentOS/RHEL, SUSE, etc, e podem ser instalados através do comando abaixo:

yum install dhcp

apt-get install dhcp3-server

O pacote do ISC DHCP fornece o software dhclient que faz as requisições de configurações de rede para clientes DHCP.

4.3. CONFIGURAÇÃO SERVIDOR DHCP

O arquivo de configuração padrão do DHCP é o dhcpd.conf e se localiza no diretório /etc. Este arquivo pode ser criado inicialmente vazio e editado com qualquer editor de texto, mas existe um arquivo de configuração de exemplo no diretórios de documentação (/usr/share/doc/dhcp-versao/dhcpd.conf-sample).

Arquivo /etc/dhcpd.conf Este é o arquivo de configuração do daemon dhcpd, quando inicializamos o




12











mesmos valores.




www.3way.com.br


serviço dhcpd, o mesmo lê este arquivo e estabelece as devidas configurações. O arquivo que se segue nos mostra a configuração de como transmitir dinamicamente endereços IP para o cliente DHCP em uma sub-rede.

#Define valores globais para todo o sistema ddns-update-style ad-hoc; max-lease-time 604800; default-lease-time 86400; option domain-name "3waylocal.net.br"; #Define faixa de endereços dinâmicos para a sub-rede subnet 10.0.0.0 netmask 255.255.255.0 { option routers 10.0.0.254; option domain-name-servers 10.0.0.240, 10.0.0.241; option broadcast-address 10.0.0.255; range 10.0.0.100 10.0.0.150; default-lease-time 21600; max-lease-time 43200; # Define os hosts que devem obter endereços IPS estáticos # host maq10 { # hardware ethernet 00:80:c7:aa:a8:04; # fixed-address 192.168.1.10; #} #host maq11 { # hardware ethernet 00:00:c0:a1:5e:10; # fixed-address 192.168.1.11; #} }

No Debian/Ubuntu o nome do arquivo de configuração do DHCP é diferente (/etc/default/dhcp3-server), portanto tenha cuidado para não confundir.

Se mais de uma interface de rede está conectada no sistema e se quer

especificar qual interface irá prover o serviço, basta especificá-la na diretiva DHCPDARGS do arquivo /etc/sysconfig/dhcpd.

/etc/sysconfig/dhcpd DHCPDARGS=eth1 Isso é útil em uma máquina Firewall com duas insterfaces de rede. Uma pode

estar configurada com IP público e a outra para prover endereçamento IP para a rede local atrás do Firewall. Essa configuração protegeria a rede interna, uma vez que não atenderia clientes provenientes da Internet.




12











mesmos valores.




www.3way.com.br


Principais opções max-lease-time Determina qual é o tempo máximo que um certo endereço pode ser alugado (lease) por um

cliente, em segundos. Neste exemplo, o parâmetro é uma semana. default-lease-time Define o tempo que um certo endereço IP será alugado caso o cliente não envie o tempo

de aluguel desejado. No exemplo acima, o default é estabelecido para um dia (86400 segundos). No cliente pode-se especificar qual o tempo de aluguel requerido em sua configuração. Se

for especificado o servidor utilizará até max-lease-time, se não o servidor utilizará o tempo de default-lease-time.

option subnet-mask Define a máscara da sub-rede, neste caso a máscara é 255.255.255.0 option domain-name Determina o domínio padrão, no nosso exemplo o domínio é 3waylocal.net.br. O

domínio padrão é acrescentado ao nome quando não se especifica um domínio para um host. Por exemplo, caso você executasse o comando ping www, seria equivalente a executar ping www.3waylocal.net.br, apesar de não ter sido especificado um domínio.

option domain-name-servers Define os servidores DNS - Domain Name Service. option routers Estabelece os roteadores padrões. subnet e netmask Determina a sub-rede e a sua máscara de sub-rede respectivamente. option broadcast-address Define o endereço de broadcast. range Define a faixa de IP que podem serem atribuídas dinamicamente para os hosts desta sub-

rede. hardware Neste parâmetro você deve especificar o endereço MAC. Esta opção suporta ethernet e

token-ring. É através deste endereço MAC que o serviço localizará a máquina na rede. fixed-address É usado para atribuir o endereço IP estático para host.




12











mesmos valores.




www.3way.com.br


use-host-decl-name Este parâmetro faz com que o cliente receba o nome de host como indicado logo após a

diretiva host. Valores: true ou false; host maq101 { hardware ethernet 00:80.c7:aa:a8:04; ... } Neste caso o host cujo endereço MAC for 00:80.c7:aa:a8:04 receberá o nome maq101. host As definições host, group e subnet podem conter todas as outras opções e as

opções que não estiver delimitadas por estas são chamadas de opções globais. O servidor trabalha do específico para o geral, ou seja, quando vai configurar os clientes, o servidor procura por opções dentro de um agrupamento host, depois em group, em subnet e finalmente nas opções globais. Prevalecendo do host para as globais.

Depois de feita a configuração deste arquivo o próximo passo é inicializar o daemon dhcpd. Veja o comando abaixo:

service dhcpd start

/etc/init.d/dhcp3-server start

O DHCP também usa o arquivo /var/lib/dhcpd/dhcpd.leases para armazenar o banco de dados dos empréstimos de clientes.

4.4 CONFIGURAÇÃO CLIENTE DHCP

Por padrão o cliente obtém as configurações provenientes do arquivo de configuração do servidor, mas quando o cliente dhclient é inicializado, ele lê, se existir, o arquivo /etc/dhclient.conf tornando o processo mais flexível.

Para configurar o linux para receber endereço IP dinamicamente, basta




12











mesmos valores.




www.3way.com.br


lembrar do arquivo de configuração da interface ethernet a qual irá receber configurações IP dinamicamente. Este arquivo é o /etc/sysconfig/network-

scripts/ifcfg-ethX (CentOS/RHEL) ou /etc/network/interfaces (Debian/Ubuntu).

/etc/sysconfig/network-scripts/ifcfg-eth0 ONBOOT="yes" BOOTPROTO="dhcp"

/etc/network/interfaces auto eth0 iface eth0 inet dhcp

Para configurar uma estação Windows para receber suas configurações

TCP/IP de um servidor DHCP é preciso marcar Obter um endereço IP automaticamente nas configurações da interface de rede.

As informações sobre leasing (locação) de IPs são armazenadas nos arquivos

dhclient.leases e dhcpcd.leases. Este último somente quando houver o daemon servidor. No CentOS/RHEL o caminho para esses arquivos são /var/lib/dhclient/ e /var/lib/dhcpd/ respectivamente. No Debian/Ubuntu o caminho é /var/lib/dhcp3/ para ambos os arquivos.

4.5. GERENCIANDO SUB-REDES

Em uma rede com muitas sub-redes há um maior trabalho a ser feito em relação a configuração do DHCP. O ideal é ter um servidor central na rede principal, pois quando os clientes são inicializados, eles enviam por difusão mensagens com solicitações de configurações DHCP. Como este servidor não pertence a esta sub-rede e obviamente não está no mesmo barramento, é necessário a implementação de agentes retransmissores, os chamados servidores dhcrelay.

4.5.1. CONFIGURAÇÃO SERVIDOR DHCRELAY

O servidor dhcrelay, também chamado de agente retransmissor DHCP, faz parte do pacote dhcpd. O agente retransmissor identifica solicitações DHCP em uma sub-rede e as retransmite para o servidor DHCP em uma outra sub-rede.

Para que o servidor DHCP forneça o serviço para toda a rede (incluindo as sub-redes), é preciso utilizar os agentes retransmissores: DHCP Relay. O servidor dhcrelay deve ser ligado na mesma sub-rede do cliente para que ele consiga escutar




12











mesmos valores.




www.3way.com.br


as requisições que vem por broadcast e encaminhá-las para o servidor. Quando o servidor receber a requisição, o mesmo a processará e, intermediado pelo DHCP Relay, começará o processo de empréstimo da configuração TCP/IP.

Para configurar o serviço dhcrelay o comando dhcrelay deverá ser utilizado. Abaixo está a sintaxe do comando:

dhcrelay <opcoes> <endereco IP do servidor dhcp>

Veja este exemplo de comando: dhcrelay 192.168.1.101

Este comando sem opções seria o bastante. Em um servidor dhcrelay este

comando deve ser executado quando a máquina é inicializada, para que isto aconteça, no caso do CentOS/RHEL, é necessário configurar as interfaces de escuta na diretiva INTERFACES do arquivo /etc/sysconfig/dhcprelay.

/etc/sysconfig/dhcprelay INTERFACES=”eth0” DHCPSERVER=”” Para iniciar o agente DHCP Relay basta executar o comando abaixo:

/etc/init.d/dhcprelay start

/etc/init.d/networking start

No exemplo é interessante usar roteadores para serem os agentes

retransmissores DHCP, apesar de não ser obrigatoriamente necessário. Logo, o roteador deverá possuir mais de uma interface e ser configurado para fornecer o serviço DHCP retransmissor para a interface correta. A interface eth1 do roteador está conectada às sub-redes que possuem os clientes DHCP e que precisam do serviço DHCP retransmissor, o comando dhcrelay para este caso seria:

dhcrelay -i eth1 10.0.0.254

Ambos os roteadores desta rede terão a mesma configuração e,

consequentemente, usarão o comando apresentado acima. Este comando pede ao




12











mesmos valores.




www.3way.com.br


dhcrelay somente listar as requisições DHCP na interface eth1. Então quando receber as requisições, ele os transmitirá para 10.0.0.254.

4.5.2. CONFIGURAÇÃO PARA GERENCIAR SUB-REDES

Esta é uma extensão da configuração apresentada no item Configuração Servidor DHCP.

#Define valores globais para todo o sistema ddns-update-style ad-hoc; max-lease-time 604800; default-lease-time 86400; #Define faixa de endereços dinâmicos para a sub-rede subnet 10.0.0.0 netmask 255.255.255.0 { option domain-name "3waylocal-0.net.br"; option routers 10.0.0.254; option domain-name-servers 10.0.0.240, 10.0.0.241; option broadcast-address 10.0.0.255; range 10.0.0.100 10.0.0.150; host maq1 { hardware ethernet 00:80:c7:aa:a8:04; fixed-address 10.0.0.1; } } subnet 10.0.1.0 netmask 255.255.255.0 { option domain-name "3waylocal-1.net.br"; option routers 10.0.1.254; option domain-name-servers 10.0.1.240, 10.0.1.241; option broadcast-address 10.0.1.255; range 10.0.1.150 10.0.1.200; host maq10 { hardware ethernet 00:80:c7:ff:aa:51; fixed-address 10.0.0.10; } } subnet 10.0.2.0 netmask 255.255.255.0 { option domain-name "3waylocal-2.net.br"; option routers 10.0.2.254; option domain-name-servers 10.0.2.240, 10.0.2.241; option broadcast-address 10.0.2.255; range 10.0.2.200 10.0.2.230; host maq20 { hardware ethernet 00:80:c7:ef:1b:c2; fixed-address 10.0.0.20; } }

Depois de configurado o servidor DHCP e os agentes retransmissores (dhcrelay) falta apenas a configuração dos clientes DHCP.

4.6. INTEGRAÇÃO DHCP E DNS




12











mesmos valores.




www.3way.com.br


A integração do serviço de DHCP com o DNS é importante, pois permite que o DHCP faça atualizações dinâmicas no DNS em nome dos seus clientes. Quando o cliente obtém um endereço IP, o servidor registra o nome e o endereço IP do cliente no servidor DNS.

Normalmente os clientes Windows (2000, XP, 2003 e 2008) atualizam automaticamente seus registros A no servidor DNS. Porém, esses clientes não conseguem atualizar os registros PTR. Por esse motivo que a integração entre esses dois serviços é necessária.

Para que essa integração seja feita é necessária a criação de uma chave de segurança comum aos dois serviços para que eles possam se comunicar e trocar informações. Para a geração da chave basta utilizar o utilitário dnssec-keygen, como mostrado abaixo:

dnssec-keygen -a HMAC-MD5 -b 128 -n USER chave

Onde: -b 128 refere-se ao tamanho da chave em bits. O comando acima produzirá no diretório atual os arquivos Kchave.+157+53416.key e

Kchave.+157+53416.private. O primeiro arquivo é de onde será extraída a chave. O comando abaixo simulará essa extração, a chave é a parte da saída que está em negrito-itálico.

cat Kchave.+157+53416.key chave. IN KEY 0 2 157 mYWhWjs2haILAfiRq/ciyA==

Neste caso a chave é a sequência mYWhWjs2haILAfiRq/ciyA== De posse da chave é o momento de configurar o servidor DHCP. Para isso é preciso

editar o arquivo /etc/dhcpd.conf como mostrado a seguir: /etc/dhcpd.conf option domain-name-servers 10.0.0.240, 10.0.0.241; default-lease-time 432000; max-lease-time 864000; log-facility local7; #parametros de atualização ddns-updates true; ddns-update-style interim; ddns-ttl 86400; #chave de atualização dinâmica key nomedachave { algorithm HMAC-MD5; secret "mYWhWjs2haILAfiRq/ciyA=="; }; zone 3waylocal.net.br. { primary 10.0.0.254; key nome_da_chave; } zone 1.168.192.in-addr.arpa. { primary 192.168.1.1; key nome_da_chave; } subnet 10.0.0.0 netmask 255.255.255.0 { range 10.0.0.100 10.0.0.150; default-lease-time 256000;




12











mesmos valores.




www.3way.com.br


max-lease-time 256000; option broadcast-address 10.0.0.255; one-lease-per-client on; option domain-name "3waylocal.net.br"; option routers 10.0.0.254; option subnet-mask 255.255.255.0; }

Além do DHCP, é necessária a configuração do servidor DNS: /etc/named.conf options { listen-on port 53 { 127.0.0.1; 10.0.0.254; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; }; allow-query-cache { localhost; }; }; acl local_nets { 10.0.0.0/24; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { nome_da_chave; }; }; key nome_da_chave { algorithm hmac-md5; secret "mYWhWjs2haILAfiRq/ciyA=="; }; view localhost_resolver { match-clients { localhost; }; match-destinations { localhost; }; recursion yes; include "/etc/named.rfc1912.zones"; }; view rede_local { match-clients { localhost; local_nets; }; allow-query { localhost; local_nets; }; allow-query-cache { localhost; local_nets; }; allow-recursion { localhost; local_nets; }; include "/etc/named.rfc1912.zones"; zone "3waylocal.net.br" IN { type master; notify no; check-names ignore; file "3waylocal.net.br.direto"; allow-update { key nome_da_chave; }; }; zone "1.168.192.in-addr.arpa" IN { type master; notify no; check-names ignore; file "1.168.192.in-addr.arpa.reverso"; allow-update { key nome_da_chave; }; };




12











mesmos valores.




www.3way.com.br


};

Faltam ainda a configuração dos arquivos de zona 3waylocal.direto e 1.168.192.in-addr.arpa.reverso para finalizar a integração.

/var/named/3waylocal.net.br.direto $ORIGIN . $TTL 43200 @ IN SOA 3waylocal.net.br. root.3waylocal.net.br. ( 2012011703 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN NS maq1.3waylocal.net.br. @ IN NS maq2.3waylocal.net.br. $ORIGIN 3waylocal.net.br. /var/named/chroot/var/named/1.168.192.in-addr.arpa.reverso $ORIGIN . $TTL 43200 @ IN SOA 3waylocal.net.br. root.3waylocal.net.br. ( 20010328003 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN NS maq1.3waylocal.net.br. $ORIGIN 1.168.192.in-addr.arpa. 1 IN PTR maq1.3waylocal.net.br.

Depois de feitas as configurações do DHCP e do DNS, basta reinicializar os serviços e

monitorar o funcionamento ou algum erro de configuração através do /var/log/messages. /etc/init.d/dhcpd restart /etc/init.d/named restart tail -f /var/log/messages

É comum ocorrerem erros de permissão na atualização dos arquivos de zona. Para que isso

não ocorra é necessário que o diretório /var/named (da jaula) tenha permissão de escrita para o usuário named.




12











mesmos valores.




www.3way.com.br


4.7. LABORATÓRIO Este laboratório irá configurar um servidor DHCP dedicado com dois cenários simples: um com DHCP dinâmico e outro estático. Detalhes das máquinas virtuais - Tanto a máquina Linux (Servidor) quanto o cliente Windows (cliente) terão suas interfaces configuradas no modo Rede Interna para não haver problemas na rede do laboratório. Informações da implementação do Servidor Endereço IP do Servidor: 192.168.3.1 Sub-rede e sub-máscara: 192.168.3.0 e 255.255.255.0 Gateway: 192.168.3.254 Servidores DNS: 192.168.3.253, 192.168.3.252 e 8.8.8.8 Nome do Domínio: 3waylocal.net.br Faixa: 192.168.1.10 - 50 A. Configuração de DHCP Dinâmico - Edição do /etc/dhcpd.conf ddns-update-style ad-hoc; ignore client-updates; subnet 192.168.3.0 netmask 255.255.255.0 { # --- Gateway padrão --- option routers 192.168.3.254; option subnet-mask 255.255.255.0; option domain-name "3waylocal.net.br"; option domain-name-servers 192.168.3.242 , 192.168.3.253 , 8.8.8.8 # --- Faixa de IPs 192.168.3.10 192.168.3.50 --- range 192.168.3.10 192.168.3.50; default-lease-time 21600; max-lease-time 43200; }

- Reinicialização do serviço /etc/init.d/dhcpd restart

- Configure a estação cliente para receber endereços dinamicamente B. Configuração de DHCP Estático - Edição do /etc/dhcpd.conf ddns-update-style ad-hoc; ignore client-updates; subnet 192.168.3.0 netmask 255.255.255.0 { # --- Gateway padrão --- option routers 192.168.3.254; option subnet-mask 255.255.255.0; option domain-name "3waylocal.net.br"; option domain-name-servers 192.168.3.242 , 192.168.3.253 , 8.8.8.8 # --- Faixa de IPs 192.168.3.10 192.168.3.50 --- range 192.168.3.10 192.168.3.50; default-lease-time 21600;




12











mesmos valores.




www.3way.com.br


max-lease-time 43200; # --- Seção DHCP Estático --- # – Estação do Gerente - host gerente { hardware ethernet 00:14:0B:41:9b:81; fixed-address 192.168.3.41; } # - Estação do Sysadmin - host sysadmin { hardware ethernet 00:24:81:B2:53:F1; fixed-address 192.168.3.42; } # - Estação do Contador - host contador { hardware ethernet 00:22:5f:23:61:12; fixed-address 192.168.3.43; } }

- Reinicialização do serviço /etc/init.d/dhcpd restart

- Configure as estações clientes para buscar endereçamento IP pela rede. Use na sequência as opções release e renew do comando ipconfig para testar a renovação dos endereços.

No DHCP estático é imprescindível que os endereços físicos (MAC) das máquinas clientes correspondam aos que estão no arquivo de configuração. Caso o endereço físico não bater, a estação obterá endereços dinâmicos.




12











mesmos valores.




www.3way.com.br


4.8. EXERCÍCIOS

1. Se inicialmente o cliente não tem número IP, como é feita a comunicação de solicitação-resposta DHCP?

2. Quais são os valores padrões das diretivas unkown-clients, bootp e booting?

3. Queremos configurar a interface ethernet de um host em nossa rede para que sempre possua o IP 192.168.1.2. Seu endereço MAC é ee:f4:e2:aa:c9:00. Como poderíamos fazer isto no arquivo /etc/dhcpd.conf?

4. O que são opções globais? Quando se tem opções globais e opções especificas, subnet, group ou host, para um host, qual a ordem de precedência das opções?

5. O que é retransmissão DHCP? Por que é utilizada?




12











mesmos valores.




www.3way.com.br


5. NTP

O NTP (Protocolo de Tempo de Rede) é responsável por manter um sistema

de tempo (horário), o que é muito importante em muitos ambientes porque muitos serviços dependem do tempo para funcionar corretamente, como por exemplo, logs, mensagens de erro, aplicações, etc. Existem alguns papéis que o sistema de tempo pode desempenhar ao usar NTP. São eles:

Servidor NTP Primário Esse tipo de servidor provê horário para os secundários ou outros clientes.

Servidor NTP Secundário Provê horário para clientes ajudando a balancear a carga dos primários.

Par NTP Tanto provê quanto recebe horário de algum servidor.

Cliente NTP Recebe horário de servidores primários ou secundários. Os servidores primários e secundários sincronizam seus relógios de servidores

hierarquicamente superiores chamados Stratum. Eles estão organizados em vários níveis, de 1 a 15, sendro que os stratum 1 são os mais precisos da hierarquia.

A configuração de servidores primários e secundários servem para ajudar no balanceamento e redundância dos strutum 1 ou 2 e ainda pode ser muito útil na rede local, uma vez que os servidores podem sincronizar tempo localmente.

O NTP.br através de seus servidores públicos ajuda a manter computadores sincronizados com a Hora Legal Brasileira e com o Tempo Universal Coordenado (UTC). Os servidores do NTP.br são os seguintes:




12











mesmos valores.




www.3way.com.br


Nome Endereço a.st1.ntp.br 200.160.7.186 e 2001:12ff:0:7::186

b.st1.ntp.br 201.49.148.135

c.st1.ntp.br 200.186.125.195

d.st1.ntp.br 200.192.232.8

a.ntp.br 200.160.0.8 e 2001:12ff::8

b.ntp.br 200.189.40.8

c.ntp.br 200.192.232.8

gps.ntp.br 200.160.7.193 e 2001:12ff:0:7::193

O serviço NTP utiliza as portas UDP/TCP 123, portanto elas necessitam estar liberadas em no firewall.

5.1. INSTALAÇÃO


As principais vantagens da instalação dos fontes é ter a versão mais atual do software e sem modificações de terceiros. A versão mais atual está disponível em www.ntp.org/downloads.html.

wget www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-versao/ntp-versao.tar.gz tar zxvf ntp-versao.tar.gz cd ntp-versao ./configure make make install


yum install ntp

apt-get install ntp




12











mesmos valores.




www.3way.com.br


5.2. CONFIGURAÇÃO

Do arquivo de configuração principal, destacam-se as seguintes opções: /etc/ntp.conf … server 0.centos.pool.ntp.org prefer server 1.centos.pool.ntp.org server 2.centos.pool.ntp.org … server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10

As três primeiras linhas são NTP públicos da Internet que se pode sincronizar

o tempo. A quarta opção server é utilizada para sincronizar o relógio local (normalmente baseado no BIOS). A última opção fudge é para definir o nível hierarquico do servidor (no caso stratum 10).

Essa configuração sincroniza com os servidores de tempo da Internet. Da forma com está, essa configuração sincroniza o tempo com os servidores

da Internet. Por enquanto será iniciado o serviço com essa configuração.

/etc/init.d/ntp start

/etc/init.d/ntp start

A configuração para sincronizar com algum servidor de tempo do NTP.br é a

que está logo abaixo. /etc/ntp.conf … #server 0.centos.pool.ntp.org #server 1.centos.pool.ntp.org #server 2.centos.pool.ntp.org restrict 10.0.0.0 mask 255.255.255.0 nomodify notrap server a.st1.ntp.br … server 127.127.1.0 # local clock




12











mesmos valores.




www.3way.com.br


fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift A nova diretiva adicionada driftfile é utilizada como parâmetro para

checagem de erros e precisão de relógio. É recomendada para resultados melhores, mas não obrigatório.

Para que a nova configuração funcione, basta reiniciar o serviço:

/etc/init.d/ntp restart

/etc/init.d/ntp restart

5.3. FERRAMENTAS

Para testar o servidor NTP ou mesmo solucionar problemas pode-se utilizar alguns comandos.

ntpdate [opcoes] <servidor> Sincroniza em tempo de execução algum servidor NTP. Ex.: ntpdate a.st1.ntp.br ntpq [opcoes] É o programa padrão para realização de consultas NTP. Ex.: ntpq -p ntptrace [opcoes] <servidor> Verifica o caminho para a obtenção do relógio NTP. Ex.: ntptrace a.st1.ntp.br




12











mesmos valores.




www.3way.com.br


5.4. LABORATÓRIO Este laboratório irá configurar um servidor NTP, cujo IP será 10.0.0.254, usando os servidores a.st1.ntp.br (preferido), b.st1.ntp.br, c.st1.ntp.br e d.st1.ntp.br como seus servidores de sincronização externa para a rede interna 10.0.0.0/24.

SERVIDOR /etc/ntp.conf … restrict 10.0.0.0 mask 255.255.255.0 nomodify notrap server a.st1.ntp.br prefer server b.st1.ntp.br server c.st1.ntp.br server d.st1.ntp.br … server 127.127.1.0 # local clock

fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift CLIENTES Linux /etc/ntp.conf … server 10.0.0.254 … server 127.127.1.0 # local clock

# fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift

/etc/init.d/ntdp start Windows Esse passos abaixo são válidos para servidores Windows. Abrir o Prompt de comandos em Iniciar / Todos os Programas / Acessórios. Executar os seguintes comandos: C:\> net time /setsntp:”10.0.0.254” C:\> net stop w32time C:\> net start w32time C:\> net time /querysntp Os comandos acima definem o servidor 10.0.0.254 como servidor NTP, reinicia o serviço de horário do Windows (Windows Time Service), por último verifica se o Windows está sincronizando com o servidor NTP.




12











mesmos valores.




www.3way.com.br


5.5. EXERCÍCIOS

1. Como se organizam os servidores NTP? Como eles são categorizados?

2. Enumere as vantagens de se ter um servidor NTP em uma rede interna.

3. Caso o servidor esteja protegido por um firewall, quais são as providências que devem ser tomadas para que os clientes façam uso das funcionalidades desse servidor?




12











mesmos valores.




www.3way.com.br


6. SISTEMA DE ARQUIVO DE REDE

O NFS é um sistema de arquivos que permite o compartilhamento de dados

em uma rede, de forma que os clientes possam acessar árvores de diretórios em servidores como se estivessem acessando localmente.

Esse protocolo foi projetado para ser independente de qualquer hardware, sistema operacional ou sistema de arquivos. Para tornar o NFS independente de sistemas, ele usa a RPC (Chamada de Procedimento Remoto) em conjunto com uma representação de dados chamada eXternal Data Representation (XDR).

Funcionamento do servidor NFS

6.1. INSTALAÇÃO

Basicamente os pacotes necessários para instalação do NFS são o portmap, nfs-utils e nfs-server, sendo o primeiro deles um dos requisitos mais importantes para a instalação.


A instalação via código fonte não difere muito das outras instalação feitas anteriormente.




12











mesmos valores.




www.3way.com.br


Deve-se preocupar com a instalação dos pré-requisitos (que podem ser vistos nos arquivos README ou INSTALL) e, salvo raríssimas excessões, executar os comandos configure, make e make install dentro da raiz do diretório descompactado do NFS.


Os pacotes do NFS provavelmente estão disponíveis na mídia de instalação e repositórios das distribuições Linux mais conhecidas. Basicamente os pacotes necessários para instalação do NFS são o portmap, nfs-utils e nfs-server.

yum install nfs-utils nfs-utils-lib

apt-get install portmap nfs-kernel-server nfs-common

O portmap é o serviço que geralmente escuta a porta 111, recebe um número identificador do rpc e retorna um número de porta com a qual o cliente se conecta para a partir de então, se comunicar através de chamadas de procedimentos remotos - RPC.

6.2. AUTENTICAÇÃO E PERMISSÕES

Sistema de autenticação e permisões de arquivo em NFS

O NFS é baseado em chamadas RPC e para todo procedimento RPC é




12











mesmos valores.




www.3way.com.br


passado como parâmetro o uid e gid (identificação de usuário Unix) do usuário que realizou a operação de I/O no diretório montado via NFS, e que é utilizada na avaliação de permissão no servidor, de acordo com as permissões locais do servidor.

Em todo o esquema de chamada RPC da figura acima e de avaliação da permissão de acesso, os números de ID de usuário e de grupo é que são realmente utilizados. Portanto, os nomes não garantem a autenticação dos usuários. Desta forma, é conveniente fazer com que os usuários do cliente NFS tenham os mesmos uid's e gid's equivalentes no servidor NFS (de forma que no nosso diagrama, o o uidn e gidn seriam iguais ao gidk e gidk, respectivamente). Isto geralmente é realizado mais facilmente com um servidor NIS, ou manualmente simplesmente mantendo os dois arquivos /etc/passwd iguais.

6.3. MONTANDO COMPARTILHAMENTOS NFS

Para uma máquina cliente montar um volume NFS o serviço portmap deve estar ativo, pois é este serviço que mapea os números de programa RPC em portas TCP.

O comando para montar um compartilhamento remoto segue abaixo: mount -t nfs servidor:/compartilhamento /ponto_de_montagem

Montando compartilhamento NFS




12











mesmos valores.




www.3way.com.br


Este comando monta o diretório /compartilhamento da máquina servidora no ponto de montagem local /ponto_de_montagem na máquina cliente. A opção -t especifica o sistema de arquivos a ser utilizado. A montagem é semelhante à montagem de dispositivos locais.

Para desmontar um volume NFS, basta utilizar: umount /ponto_de_montagem

6.3.1 MONTAGEM AUTOMÁTICA

É interessante em uma rede fazer a montagem NFS automaticamente durante a inicialização. Isso é necessário em uma rede onde os usuários devam compartilhar mesmos arquivos e diretórios. Para isso utiliza-se o arquivo /etc/fstab.

/etc/fstab /dev/hda7 / ext2 defaults 1 1 /dev/hda2 /boot ext2 defaults 1 2 /dev/hda5 swap swap defaults 0 0 /dev/fd0 /mnt/floppy ext2 noauto 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,ro 0 0 none /proc proc defaults 0 0 none /dev/pts devpts mode=0622 0 0 192.168.1.15:/compartilhado /mnt nfs auto 0 0

A primeira coluna se refere ao dispositivo de montagem, a segunda ao ponto de montagem, a terceira ao sistema de arquivo do dispositivo, a quarta coluna define os parâmetros de montagem. Este arquivo é usado para configurar o lado do cliente, ou seja, estamos considerando que o servidor está configurado para ser requisitado.

Com essa configuração, o cliente montará o diretório /compartilhado do servidor de IP 192.168.1.15 no seu diretório /mnt usando o sistema de arquivo de rede NFS. O parâmetro auto é para que este sistema de arquivo seja montado automaticamente.

O serviço portmap deve estar rodando na máquina cliente e as configurações de rede estarem corretas para que a montagem funcione. É altamente recomendável configurá-los para que sejam inicializados no boot.

chkconfig --level 35 portmap on

update-rc.d rpc defaults




12











mesmos valores.




www.3way.com.br


6.4. O SERVIDOR NFS

O arquivo /etc/exports O arquivo /etc/exports é usado pelo servidor NFS para especificar quais

diretórios devem ficar disponíveis publicamente e quais restrições devem ser aplicadas. O formato do arquivo permite que qualquer diretório seja exportado para um ou mais hospedeiros e permite que as permissões de acesso sejam configuradas especificadamente para cada hospedeiro.

recurso_local host1(permissoes1) host2(permissoes2) ...

Neste exemplo, recurso_local é o que vai ser compartilhado com os hosts 1 e 2 com suas respectivas permissões de acesso.

/home/ftp/pub maq1(rw,all_squash) maq2(ro)

O diretório /home/ftp/pub está disponível para o host maq1 com acesso tanto

para leitura como para gravação e os números de ID de usuário e de grupo são mapeados automaticamente para o usuário anônimo (opção all_squash).

O mesmo diretório também está disponível para o host maq2, mas com acesso somente de leitura (opção ro).

É preciso ter cuidado para não deixar espaços na definição das máquinas e suas opções de compartilhamento. Caso isso seja feito será dado acesso total a esta máquina. Este é um erro comum.

É possível utilizar os símboles * e ? para aumentar as combinações possíveis,

ou seja, funcionar como curinga. /inst/instrutor *3waylocal.net.br(rw)

Neste exemplo do arquivo /etc/exports, o diretório /inst/instrutor estará exportado para todas as máquinas do domínio 3waylocal.net.br.

O nome da máquina pode ser seguido por uma lista de opções, entre

parêntesis e separadas por vírgulas (nunca espaços). Estas opções têm os seguintes valores:




12











mesmos valores.




www.3way.com.br


insecure Permite o acesso não autenticado a partir desta máquina. root_squash Esta é uma característica de segurança que proíbe o super-usuário dos clientes de ter qualquer direito de acesso especial no servidor. Caso o cliente acesse o diretório compartilhado através do usuário root, o servidor irá mapear o ID 0 (de root) para 65534 (-2), que representa o usuário nobody. no_root_squash Não mapeia requisições do usuário com identificação 0, ou seja, o usuário root dos clientes acessam diretório exportado do servidor como usuário root e terão todos os privilégios de root neste diretório do servidor. Este tipo de opção jamais é aconselhável por motivos de segurança. ro Monta hierarquicamente os arquivos somente para leitura. É o padrão. rw Monta hierarquicamente os arquivos, com autorizações para leitura e gravação. É possível especificar ainda uma rede específica através da seguinte entrada. /home/ftp/pub 192.168.1.0/255.255.255.0(rw)

Este comando exportará o diretório para todos hosts pertencentes a rede 192.168.1.0/24. O próximo passo é inicializar o serviço nfs.

/etc/init.d/nfsd start

/etc/init.d/portmap start /etc/init.d/nfs-kernel-server start /etc/init.d/nfs-common start

Depois de iniciado o serviço nfs, é preciso exportar a configuração do

/etc/exportfs para a rede.




12











mesmos valores.




www.3way.com.br


exportfs -v

Outro aplicativo muito utilizado para monitoração do serviço NFS é o showmount. Vejamos alguns exemplos de sua aplicação:

showmount --export 192.168.1.2 Export list for 192.168.1.2 /usr/local/apache/htdocs 192.168.1.2/255.255.255.0 /usr/local/apache/htdocs_s/intranet 192.168.1.2/255.255.255.0 /home 192.168.1.0/255.255.255.0 /dc 192.168.1.0/255.255.255.0

A saída deste comando fornece quais clientes NFS estão utilizando os diretórios que estão

compartilhados no servidor 192.168.1.2.




12











mesmos valores.




www.3way.com.br


6.6. LABORATÓRIO Neste laboratório vamos exportar três diretórios em forma de compartilhamento. O primeiro será de leitura para duas estações específicas com mapeamento de usuário. O segundo será de escrita para toda a rede, porém mapeando os usuários e os grupos das estações clientes para acessos não privilegiados no servidor. E o terceiro terá permissão de escrita para toda a rede 192.168.3.0/24, sem restrição de mapeamento de usuários e grupos. O IP do servidor será 192.168.1.10. A. No servidor, editar o arquivo /etc/exports da seguinte maneira:

/etc/exports /departamento estacao1(ro) estacao2(ro,root_squash) /comercial 192.168.1.0/255.255.255.0(rw,all_squash) /publico 192.168.3.0/255.255.255.0(rw,no_root_squash)

B. Reiniciar o serviço NFS no servidor.

/etc/init.d/nfsd start

C. Exportar os diretórios para os hosts de destino.

exportfs -v

D. Agora serão feitos os testes nos clientes. Antes disso tenha certeza que o serviço portmap esteja ativo na máquina cliente e monte o compartilhamento desejado.

/etc/init.d/portmap status /etc/init.d/portmap start

Estação 1 e 2 mount -t nfs 192.168.1.10:/departamento /mnt/departamento

Estação da rede 192.168.1.0/24 mount -t nfs 192.168.1.10:/comercial /mnt/comercial

Estação da rede 192.168.3.0/24 mount -t nfs 192.168.1.10:/publico /mnt/publico




12











mesmos valores.




www.3way.com.br


Seria recomendável em cada cliente que o mesmo montasse durante o boot os seus compartilhamentos. Caso esse seja o desejo, fazer a configuração no /etc/fstab.




12











mesmos valores.




www.3way.com.br


6.6. EXERCÍCIOS

1. Dê a configuração correta do /etc/exports para exportar um diretório chamado /cartorio em modo somente leitura para as máquinas da rede 192.168.20.0/16.

2. Qual seria a configuração para exportar o diretório /dados/exportacoes no modo leitura e escrita para as máquinas do domínio 3wayteste.net.br e modo leitura para qualquer máquina?

3. Faça a configuração para exportar o diretório /dados/importacoes para a rede 10.1.1.0/24 em modo escrita e leitura e sem mapeamento de root para usuário não privilegiado (nobody).

4. Faça configuração para inicialização automática no /etc/fstab dos três primeiros exercícios.




12











mesmos valores.




www.3way.com.br


7. SAMBA

7.1. VISÃO GERAL

A finalidade do serviço Samba é permitir que estações Linux e Windows compartilhem recursos entre si em uma rede. Através do Samba, o Linux pode servir clientes Windows, tornando-se:

Servidor de arquivo Servidor de impressão Servidor de autenticação ou autorização Servidor de nomes Windows O Samba permite que uma estação de trabalho Linux se torne um membro

totalmente funcional de uma rede Microsoft para incluir compartilhamento de unidades de disco e impressoras, integração com grupos de trabalho e participação como cliente ou servidor em domínios Windows.




12











mesmos valores.




www.3way.com.br


Estrutura de uma rede com samba

O Samba utiliza-se basicamente dois daemons: smbd e nmbd. smbd Este é o daemon que fornece serviços como compartilhamento de arquivos e impressão,

além da autenticação e autorização. nmbd Este é o daemon de Serviço de Nome NetBIOS. O mesmo pode ser utilizado para

responder solicitações NetBIOS sobre resolução de nomes Windows em números IP. Estes serviços trabalham sob o protocolo SMB (Server Message Block),

atualmente CIFS (Common Internet File System). Este é o protocolo utilizado pelo Windows para compartilhar recursos em uma rede.

Antes de existir o Samba, o compartilhamento de recursos em uma rede Unix e Windows era problemático pelo fato de ter que instalar nos clientes Windows protocolos tradicionalmente de Unix como NFS e LDAP. Toda esta necessidade é fruto do Windows utilizar o conjunto de protocolos atualmente conhecido por CIFS que é o protocolo utilizado para compartilhar serviços de arquivos e impressão. O Samba surgiu para suprir a necessidade de uma solução de integração de Linux na rede Windows.

A maior parte das funcionalidades dos servidores Windows são oferecidas pelo Samba. Com ele é possível imprimir em impressoras Linux, mapear drives remotos de compartilhamentos que estão no Linux, bem como atuar como controlador de domínios (PDC ou BDC).




12











mesmos valores.




www.3way.com.br


O PDC pode estar acompanhado de um BDC de forma que caso o PDC tenha algum problema e não possa responder alguma solicitação de login, a tarefa é então repassada para ele.

Interação Linux/Windows

7.2. O PROTOCOLO SMB

O SMB é o protocolo cliente/servidor da camada de aplicação que é responsável pelo compartilhamento de arquivos, impressoras, autenticação, etc. É através do protocolo dele que os clientes se conectam ao servidor para ler e escrever arquivos no servidor. O acrônimo CIFS é a especificação pública do SMB que tem o objetivo de torná-lo um protocolo de acesso a arquivos para ser utilizado na Internet. Na verdade, o ele é a evolução do SMB.

7.3. O PROTOCOLO NETBEUI

Inicialmente os sistemas operacionais da Microsoft ofereciam o NetBEUI (NetBIOS Enhanced User Interface) como protocolo padrão. Ele foi desenvolvido inicialmente pela IBM e depois aperfeiçoado pela Microsoft. É também considerado uma versão melhorada do NetBIOS.




12











mesmos valores.




www.3way.com.br


7.4. INSTALANDO O SAMBA

7.4.1. INSTALANDO CÓDIGO FONTE

Inicialmente é necessário instalar todos os requisitos para a compilação do samba. Essa informações estão presentes nos arquivos README e INSTALL do código fonte. Depois disso, basta obter o código fonte no site do produto e realizar a instalação propriamente dita. Neste material a versão utilizada foi a 3.0.20.

tar zxvf samba-versao.tar.gz -C /usr/local/src cd /usr/local/src/samba-versao/source ./configure make make install

Os principais programas que acompanham o pacote do Samba são:

Programas

Descrição

nmbd Daemon que permite a tradução de nomes Windows em seus endereços IP.

nmblookup Aplicativo cliente para consultas à servidores WINS, traduz nomes CIFS em IP.

smbclient Programa semelhante ao cliente FTP que utilizado para acessar compartilhamentos CIFS remotos.

smbd Daemon principal do Samba que permite compartilhamento de arquivos, impressão e autenticação.

smbstatus Mostra o status atual das conexões no servidor Samba.

testparm Verifica o arquivo de configuração do Samba por sintaxe errada.


yum install samba samba-client samba-doc




12











mesmos valores.




www.3way.com.br


apt-get install samba smbclient samba-doc

7.5. CONFIGURAÇÃO

O arquivo de configuração do Samba é o smb.conf. Por padrão, este arquivo se encontra no diretório /etc/samba/ e pode ser editado diretamente usando o editor de texto puro de sua preferência. Ainda é possível utilizar alguns utilitários visuais como o SWAT, que é uma ferramenta de administração do samba através de interface Web.

O arquivo smb.conf é dividido em seções, onde cada seção é identificada por um identificador único cercado por colchetes [ ], onde cada seção define as características individuais de cada diretório ou de impressoras compartilhadas. Entre cada seção e outra, existem diretivas definidas por palavras-chaves seguidos do sinal de igual = e o seu valor em seguida. Para se desabilitar uma diretiva ou criar um comentário, simplesmente insira um ponto-e-vírgula ; ou uma cerquilha # no início de cada linha. Veja a seguir, as três seções especiais que por padrão já vem configuradas:

Seção Global Define os parâmetros de configuração gerais padrões para o servidor como um todo.

Qualquer opção configurada nesta seção será aplicada a todo compartilhamento. Entretanto, se houver no compartilhamento um tipo de definição que já exista na seção global, esta não será sobreposta pelos parâmetros globais.

Seção homes Define individualmente os parâmetros para os diretórios pessoais (/home/usuario) dos

usuários. Na verdade, esta seção permite que os usuários acessem seus diretórios home no servidor Samba. Por padrão, esta seção já vem pré-configurada de forma que os usuários do Samba tenham acessos ao seus diretórios pessoais.

Seção Printers Define os parâmetros para todas as impressoras compartilhadas pelo servidor. É a partir

destas definições que se compartilha impressoras na rede. Além destas seções padrão, podem existir também as seções criadas pelo administrador.

Seção Profile Define um perfil quando o servidor samba é usado como PDC de domínio.




12











mesmos valores.




www.3way.com.br


7.5.1. SEÇÃO GLOBAL

É iniciada com [global] e logo abaixo estão as suas opções. Abaixo são apresentadas as entradas mais básicas desta seção:

[global] workgroup = SAMBA server string = Samba Server

Na verdade, existem mais opções que são apresentadas neste momento por

questões didáticas. O manual de configuração do comando (man smb.conf) mostra com detalhes as diretivas que podem ser usadas na confecção desse arquivo.

Nesta primeira parte note as três primeiras diretivas: workgroup Determina o grupo de trabalho ou o domínio que esse servidor representa ou é membro. Neste caso, o valor para essa diretiva é SAMBA. Grupo de trabalho é um grupo de computadores que compartilham recursos entre si e são listados de forma agrupada, quando é solicitado a lista de computadores do grupo de trabalho. Domínio é um grupo de trabalho que possui um servidor PDC que mantém a lista de usuários e senhas, de forma que os recursos compartilhados baseiam suas permissões de acesso, na identificação dos usuários do domínio, etc.

server string Configura uma descrição do servidor. Por exemplo, no caso de um servidor de impressão, poderíamos substituir o padrão “Samba Server” por “Servidor de impressão”, isso ajuda a identificação da função de um computador em uma rede, uma vez que esse nome irá aparecer quando se passar o mouse sobre o ícone que representa o servidor. As próximas linhas são parâmetros globais relacionados à impressora. printcap name = /etc/printcap load printers = yes printing = bsd

printcap name Define o arquivo de configuração da impressora, ou seja, onde elas estão definidas no Linux, sendo por padrão o arquivo /etc/printcap. O arquivo printcap é o arquivo principal do Linux para configuração de impressoras, definindo os nomes, drivers (filtros),




12











mesmos valores.




www.3way.com.br


dentre outros parâmetros para as impressoras. load printers Faz com que o samba leia automaticamente o arquivo padrão /etc/printcap e forneça a lista das impressoras baseadas neste arquivo, para os clientes que procurem na rede as impressoras disponíveis no servidor samba. printing Configura valores padrões para todas as opções de comunicação sistemas UNIX em que o Samba pode ser instalado. É um modo de compatibilidade entre eles.

Caso a instalação seja no Linux, deverá ser usado o valor printing=BSD, o valor printing=LPRNG é para a impressão baseada em LPRng, ou a opção printing=CUPS para a impressão baseada no CUPS (opção mais utilizada atualmente).

Em seguida tem-se mais opções: log file = /var/log/samba/log.%m max log size = 50

log file Define o arquivo de registro de log no samba. A variável %m pode ser utilizada para arquivos de log separados por máquina, ou seja, como esta opção temos logs no formato /var/log/samba/log.nome-da-maquina. max log size Define o tamanho máximo do arquivo de log. No exemplo acima o tamanho máximo atribuído é 50KB. Se o tamanho máximo exceder, o smbd fecha o log e o renomeia com a extensão .old. security O parâmetro security merece atenção especial, pelo fato de definir e controlar o nível de segurança e senhas do Samba. Esta entrada define como o usuário pode ter acesso ao servidor e consequentemente aos compartilhamentos. Há quatro tipos de opções: share, user, server e domain.

security = share A característica principal deste tipo de segurança é definir uma senha que será utilizada para autenticar quem deseja acessar o recurso, independente do usuário.




12











mesmos valores.




www.3way.com.br


É semelhante ao compartilhamento em nível de senha do Windows, com dois níveis de acesso diferentes: somente leitura, ou completo (leitura e escrita). Em sistemas Unix, isto acontece de forma diferente, pois internamente todos recursos são acessados por um processo tendo um usuário identificado como dono. security = user Define a segurança a nível de usuário, onde o Samba tentará validar o usuário solicitante por meio de um ID de usuário existente no Linux e sua senha. security = server Define que um servidor externo irá fazer a autenticação da senha. Este servidor é definido pela opção password server. Quando um cliente faz uma requisição para acessar um recurso do servidor, a autenticação de usuários é repassada para o servidor definido pela entrada password server, podendo ser tanto um PDC ou BDC. security = domain

É semelhante à opção anterior (security = server), porém existem algumas vantagens e é necessário registrar o servidor samba no domínio do Windows. Neste esquema, o servidor Linux é cadastrado no domínio do Windows e utiliza o PDC Windows como o servidor que aprova nomes de usuário e senhas. Neste caso também é necessário utilizar a opção password server para definir o PDC Windows. A seguir mais opções para a seção global: ; password server = NomeServidorWindows encrypt passwords = yes smb passwd file = /etc/smbpasswd

password server Usado somente em conjunto com as opções server e domain da entrada security, especifica o servidor de autenticação. encrypt passwords É usado para que o Samba possa autenticar uma senha criptografada. Para isso ele precisa ter acesso a versão criptografada da senha. Há duas maneiras de conseguir isso: A primeira é conseguir configurar o parâmetro security para server e deixar que um outro servidor valide a senha, para que isso funcione, você precisa configurar também o parâmetro encrypt passwords como yes e garantir que o parâmetro password server




12











mesmos valores.




www.3way.com.br


esteja configurado com o nome de um servidor Windows que possa validar as senhas dos usuários. No segundo caso você deve-se fazer com que o Samba mantenha o próprio arquivo de senhas criptografadas. No arquivo smb.conf o parâmetro security deve ser configurado com a opção user e o parâmetro encrypt passwords como yes. O arquivo de senha do samba é definido pelo parâmetro smb passwd file. smb passwd file Define o arquivo de senha do samba. Este arquivo é análogo ao /etc/passwd, tendo a mesma função, porém é utilizado somente pelo samba. ; include = /etc/smb.conf.%m socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 ; interfaces = 192.168.1.2/24 192.168.1.2/24

include Permite que parâmetros adicionais de configuração sejam especificados em outros arquivos específicos. Por exemplo, se essa opção for configurada como no exemplo acima, o samba poderá processar arquivos particulares por máquina. Por exemplo, caso exista o arquivo /etc/smb.conf.comercial, significa que este arquivo será incluído à configuração do samba e possuirá diretivas válidas somente para o cliente comercial.

local master = no ; os level = 33 ; domain master = yes ; preferred master = yes local master Quando se quer que o servidor Samba seja candidato à eleição de Local Master (Localizador Mestre Local) pelos computadores da sub-rede, atribuir o valor yes. os level Serve para diminuir ou aumentar as chances do Servidor Samba ser eleito. O valor 32 corresponde ao Widows Server. preferred master Caso se queira que o servidor Samba sempre seja eleito, atribua valor yes para este parâmetro. Esta opção deverá ser acompanhada com a opção domain master. domain master Permite que o Samba atue como localizador Master Domain para o domínio. Ele irá, então, coletar e manter listas de computadores fornecidas pelos Local Masters da rede local. Caso já exista um PDC na rede em que se estiver trabalhando, desative essa opção, pois o Linux pode entrar em conflito com o PDC, sempre forçando uma reeleição, gerando




12











mesmos valores.




www.3way.com.br


tráfego intenso e prováveis conflitos e problemas na listagem de computadores da rede. Os próximos parâmetros permitem que o Linux de suporte a scripts de logon e

perfis de usuários.

; domain logons = yes ; logon script = %m.bat ; logon script = %U.bat ; logon path = \\%L\Profiles\%U domain logons Permite que o Samba autentique os clientes Windows que seja pertencentes a esse domínio. Portanto, esta opção é essencial para quando o Linux estiver atuando como um PDC.

Além da opção domains logon, a seção [netlogon] também deverá estar habilitada quando o Linux estiver atuando como PDC, pois os clientes acessam este compartilhamento no servidor quando efetuam o logon.

logon script Permite que os clientes executem o script de logon especificado, logo depois que o logon é efetuado. logon path Usado para configurar o diretório onde os perfis ambulantes para os clientes Windows 95 e 98 são armazenados. Cada perfil, armazena as informações pessoais de cada usuário. A vantagem da primeiro método é menos tráfego na rede e logon na rede mais rápido; a vantagem do segundo método é que todas as alterações realizadas em uma máquina estarão disponíveis quando se efetuar logon em outra máquina, levando consigo o seu perfil, daí a denominação “perfil ambulante” ou “móvel”. Para se configurar esta opção, podem ser utilizadas as variáveis citadas anteriormente. A variável %L é substituída pelo nome do próprio servidor samba atuando como PDC. Por exemplo, suponha que o seu servidor samba que esteja atuando como PDC tenha nome comercial e esta opção seja especificada como logon path=\\%L\perfis\%U, então, o servidor comercial será utilizado para armazenar os perfis dos usuários no compartilhamento perfis, em diretórios específicos por usuário, por exemplo, \\comercial\perfis\fulano. Os próximos parâmetros controlam a capacidade do Samba para trabalhar

com o WINS (Windows Internet Naming Service). Pois o Samba pode atuar como servidor WINS para uma sub-rede. Para isso um servidor de WINS irá manter uma relação das máquinas de sua rede, seus nomes NetBIOS e endereços IPs para responder às consultas.

; wins support = yes




12











mesmos valores.




www.3way.com.br


; wins server = w.x.y.z ; wins proxy = yes dns proxy = no

wins support Este parâmetro determina que o samba deve atuar como um servidor WINS da sub-rede. wins server Este parâmetro é utilizado caso já se tenha um servidor WINS na sua sub-rede. O Servidor WINS informa ao samba quem ele é, e permite que o samba comunique-se com ele. Na verdade, este parâmetro permite que o Linux seja um cliente WINS. wins proxy Esta opção é utilizada para que o samba atue como um procurador (proxy), repassando as resoluções de nome da sub-rede, para outro servidor WINS. O “verdadeiro” servidor WINS deverá estar devidamente preparado para receber as informações de resolução de nomes, e geralmente fica localizado em outra sub-rede, sendo indicado pela opção wins server. dns proxy Permite que o Samba use consultas DNS para verificar nomes CIFS (SMB) enquanto atua com um servidor WINS. Ou seja, caso o nome de um host não seja encontrado via WINS, o nmbd utilizará consultas DNS para resolver os nomes. Caso não se tenha um servidor DNS na rede, é melhor certificar-se que esse parâmetro seja configurado como no.

7.5.2. SEÇÃO HOMES

Esta seção permite que os usuários tenham acesso aos seus diretórios base. Através desta entrada todos usuários do samba terão acesso a sua pasta que está dentro do diretório /home.




12











mesmos valores.




www.3way.com.br


Compartilhamento do diretório /home para estação de trabalho Windows.

Ao usuário efetuar logon, o samba mapeará o arquivo passwd, e descobrirá

através de seu UID o seu diretório base. Este acesso é feito através do smbd. [homes] comment = Diretorios Pessoais browseable = no writable = yes

comment Permite fornecer uma descrição a este compartilhamento. browseable Quando assinalado com a opção yes permite que os usuários visualizem o diretórios base

de todos os usuários. Quando assinalado com a opção no, não será possível visualizá-la, esta é a opção mais segura, pois não há necessidade de que os usuários vejam os diretórios de seus colegas.

writable Quando assinalado com a opção yes, o compartilhamento pode ser escrito. Com a opção

no, o compartilhamento apenas pode ser lido.

7.6. SAMBA COMO PDC




12











mesmos valores.




www.3way.com.br


Linux como controlador de domínio primário.

Neste tópico apresentaremos uma configuração básica do arquivo

smb.conf, ou seja, um resumo de quais opções devem ser alteradas para que o Linux se torne o PDC da rede. Nessa configuração todos os usuários deverão ser autenticados para terem acesso aos compartilhamentos no Samba.

Será necessário efetuar o cadastramento dos usuários na base Samba, pois o algoritmo utilizado no SMB não é o mesmo que do Linux.

workgroup = 3waynet server string = PDC do domínio "3waynet" security = user encrypt passwords = yes smb passwd file = /etc/smbpasswd local master = yes domain master = yes preferred master = yes domain logons = yes [homes] comment = Diretorios Pessoais browseable = no writable = yes

Sempre que for alterado o arquivo de configuração do samba será necessário

reiniciar o serviço samba.




12











mesmos valores.




www.3way.com.br


/etc/init.d/smb restart

/etc/init.d/samba restart

7.7. CONTA DE USUÁRIO SAMBA Após configurar os compartilhamentos, é necessário criar contas de usuários

para o samba. Estas contas são definidas em arquivo diferente do passwd do Linux. Estes usuários são cadastrados no arquivo /etc/smbpasswd, através da sequência de comandos abaixo:

adduser fulano smbpasswd -a fulano

O segundo comando cria um novo usuário samba através da opção -a. Para adicionar as máquinas no domínio será necessário habilitar o usuário

administrativo do servidor samba. Esse usuário é o root, no entanto, não é o mesmo do sistema, inclusive as senhas deverão ser diferentes.

smbpasswd -a root




12











mesmos valores.




www.3way.com.br


Administração de usuários do Samba.

Este usuário também deve estar criado anteriormente na base Linux. Tanto no passwd quanto no smbpasswd os UIDs do usuário devem ser os mesmos. Esse costuma ser um problema muito comum em servidores Samba.

O comando smbpasswd também permite outras opções de manutenção de

contas, tais como: alteração de senha de um usuário: smbpasswd usuario

remoção de uma conta de usuário: smbpasswd -x usuario

desabilitar uma conta de usuário: smbpasswd -d usuario

7.8. CONTA DE MÁQUINA SAMBA




12











mesmos valores.




www.3way.com.br


Administração de contas de máquinas

Para clientes Windows poderem participar de um domínio controlado por um servidor samba, deve-se criar contas de máquinas para estas estações. Segue um exemplo:

useradd -g nobody -c "Conta de maquina samba" -s /bin/false maq$ smbpasswd -a -m maq$

O primeiro comando cria a conta para máquina maq. O sinal $ deve ser acrescentado, pois se trata de uma conta de máquina. As outras opções, adicionam esta conta no grupo nobody através da opção -g, a opção -c insere um comentário, a opção -s define o shell para este usuário, como o mesmo é uma conta de máquina, ele não necessita de um shell válido. O segundo comando adiciona a conta de máquina no samba, a opção -m é utilizada para atribuir a conta de máquina.

Um Windows Server configurado como servidor autônomo (sem controlar nenhum domínio) também pode participar de um domínio controlado por um servidor samba, sendo também necessário criar uma conta de máquina, de forma idêntica a criação de contas de máquina para estações.




12











mesmos valores.




www.3way.com.br


7.9. SERVIDOR SAMBA EM UM DOMÍNIO

Servidor Samba como parte de um domínio.

Como foi dito anteriormente, quando especificamos no arquivo smb.conf a

opção security=domain, significa que o servidor samba irá fazer parte do domínio, repassando todos os pedidos de permissão de acesso ao PDC (podendo ser Linux ou Windows). Para que o servidor samba possa fazer parte do domínio é preciso configurar o servidor samba adequadamente, configurando as opções do arquivo smb.conf, com as seguintes configurações:

[global] security = domain workgroup = dominioteste password server = pdcteste

Será necessário criar uma conta de máquina no servidor o Samba como descrito anteriormente. Também será preciso executar o comando smbpasswd para adicionar o servidor samba ao domínio especificado.

smbpasswd -j dominioteste -r pdcteste




12











mesmos valores.




www.3way.com.br


7.10. COMPARTILHAMENTOS DE ARQUIVOS

Para definir os compartilhamentos de arquivos no Samba é preciso criar seções personalizadas. Todos os compartilhamentos são definidos através de diretórios que estão na árvore de diretórios do Linux. Pode-se ter compartilhamentos sob vários níveis de segurança: share, user, server e domain. O primeiro tipo é classificado como compartilhamento com controle de acesso a nível de senha, pois somente se é exigido uma senha para ser acessada, enquanto que as opções restantes são considerados compartilhamentos com controle de acesso a nível de usuário, pois exige-se que os usuários sejam autenticados.

7.11. CONTROLE DE ACESSO A NÍVEL DE SENHA

Controle de acesso à nível de senha.

Abaixo seguem as alterações que se deve fazer para ter uma configuração de

controle de acesso em nível de senha. [global] security = share [docs] path=/documentos username = usuario force user = usuario write list = usuario

O usuário usuario é um usuário Unix válido, com senha definida no arquivo de senhas do samba e que é utilizada para validar o acesso ao compartilhamento docs.




12











mesmos valores.




www.3way.com.br


A diretiva path informa qual diretório está sendo compartilhado, o qual deverá ter as devidas permissões de escrita para o usuário usuario. A diretiva username é utilizada quando o cliente não fornecer o usuário, mas também não restringe quando algum outro for fornecido. A diretiva force user tem a função de informar qual usuário será utilizado como dono do processo que acessa o sistema de arquivos, ou seja, todas as permissões do diretório compartilhado deverão estar de acordo com este usuário. A diretiva write list informa quais são os usuários com permissão de escrita neste compartilhamento; esta opção não sobrepõe as permissões do sistema de arquivo, portanto o sistema de arquivo também tem que permitir permissão de escrita para esta lista de usuários.

7.12. CONTROLE DE ACESSO A NÍVEL DE USUÁRIO

No compartilhamento a nível de usuário, ou seja, com a opção security=user, os usuários são identificados, geralmente efetuando logon no servidor Samba que atua como PDC, e portanto, os processos que acessam o sistema de arquivos rodam também com o usuário identificado como dono, desta maneira, além de inicialmente serem verificadas as permissões de cada compartilhamento, as permissões do sistema de arquivo serão também aplicáveis ao usuário identificado na autenticação. Por exemplo, caso um usuário em um cliente Windows efetue logon em um servidor como usuário usuario e senha abc123, o servidor PDC (Samba) irá criar um processo smbd para atender este usuário, com o usuario como dono; desta forma todas permissões do sistema de arquivos, onde as informações de compartilhamentos se encontram, devem ter as permissões devidamente configuradas para o usuário usuario.

Controle de acesso ao servidor através de usuário e senha




12











mesmos valores.




www.3way.com.br


Segue as opções que deverão ser alteradas para ser criado um compartilhamento com controle de acesso a nível de usuário.

[global] ... security = user domain logons = yes ... [tmp] comment = Diretório temporario path = /tmp writable = no browseable = yes public = yes [docs] comment = Documentos path = /dados/documentos public = no writable = yes create mode = 0750 directory mode = 0744 valid users = usuario @diretoria @coordenacao hosts allow = maq1

Estas seções definem compartilhamentos. O primeiro define um compartilhamento de um diretório temporário e o segundo um diretório de documentações. Abaixo estão denominados os parâmetros que ainda não foram apresentados:

path Define o caminho do compartilhamento no Servidor Samba. public Permite qualquer um acessar este compartilhamento create mode Todo arquivo criado neste compartilhamento terá as permissões definidas através deste parâmetro. Neste exemplo temos os parâmetros octais igual a 0750. Onde o primeiro número indica os atributos de SUID, SGID ou stick bit. directory mode É análogo ao parâmetro create mode, a única diferença é que as permissões definidas por este parâmetro serão aplicadas a todos os diretórios criados a partir deste compartilhamento. hosts allow




12











mesmos valores.




www.3way.com.br


Estabelece políticas de acesso baseado em endereços IP ou através de nomes de máquinas Windows. Coloque apenas o primeiro nome não utilize o nome + domínio. Todos acessos ao servidor são estabelecidos através de usuário e senha, com este parâmetro é permitido estabelecer também quais máquinas podem acessar este compartilhamento. valid users Restringe o acesso a determinados usuários, mas ainda pode-se especificar um grupo. Para isto, coloque o caractere @ no início do nome do grupo, por exemplo valid users = @treina. Isto fará que apenas usuários do grupo treina tenham acesso ao compartilhamento.

7.14. O UTILITÁRIO TESTPARM

Este utilitário é utilizado para detecção de erros no arquivo de configuração smb.conf. O formato do testparm segue o exemplo abaixo:

testparm Load smb config files from /etc/smb.conf Processing section "[homes]" Processing section "[tmp]" Processing section "[docs]" Loaded services file OK. Press enter to see a dump of your service definitions

Se a sintaxe deste arquivo estiver correta, a execução deste programa mostra inicialmente a listagem das seções. Se for pressionado <enter>, uma longa lista das diretivas associadas à cada seção é apresentada, inclusive com opções padrões da seção [global].

O utilitário testparm não é muito rigoroso na verificação da sintaxe, pois ele verifica apenas os erros mais evidentes.

7.15. SCRIPT DE LOGON

A opção logon script indica o script que é executado no cliente logo depois que este efetua logon. Portanto, ela só é válida quando o samba estiver atuando como PDC. Para se criar um script de logon, deve-se primeiro na seção global do arquivo de configuração do samba, habilitar as linhas referentes ao scripts de logon:

# logon script = %m.bat # run a specific logon batch file per username # logon script = %U.bat logon script = teste.bat




12











mesmos valores.




www.3way.com.br


Neste exemplo, deve-se criar um simples executável denominado teste.bat. A seção [netlogon] também deverá ser habilitada, uma vez que todo cliente

que efetua logon no domínio, por padrão acessa o compartilhamento netlogon, conforme é visto a seguir.

[netlogon] comment = Network Logon Service path = /usr/local/samba/lib/netlogon guest ok = yes writable = no share modes = no

É preciso habilitar o compartilhamento [netlogon] e criar o diretório netlogon

(path=/usr/local/samba/lib/netlogon). Dentro do compartilhamento netlogon deve existir o arquivo "teste.bat" (nome aleatório, mas deve ser o indicado na configuração). Também é preciso observar as permissões deste compartilhamento, pois elas devem estar disponíveis para todos, inclusive convidados (guest=ok), mas não deve ser gravável (writable=no) para ninguém. A última opção especificada neste arquivo (share modes=no) desabilita qualquer tentativa de clientes obterem leitura ou escrita exclusiva em algum dos arquivos disponíveis neste compartilhamento.

mkdir -p /usr/local/samba/lib/netlogon

O Samba possui duas opções não muito utilizadas para definir scripts, são as

opções logon script=%m.bat e logon script=%u.bat, sendo que respectivamente, scripts por usuários e por máquinas. É recomendável habilitar apenas uma delas por vez, retirando o sinal de comentário ; que a precede.

Se for habilitada a opção por máquina, termos então: %m.bat, onde o %m é uma variável que será substituída automaticamente pelo Samba quando um usuário efetuar logon via Samba. Deste modo, torna-se necessário manter um script para cada máquina. Por exemplo, se existirem duas máquinas com os nomes maq01 e maq02, então deverá construir dois scripts com os nomes maq01.bat e maq02.bat.

Caso seja habilitada a opção %u.bat, torna-se necessário manter um script para cada usuário, e a variável %u será substituída pelo nome do usuário. Por exemplo, se tivermos dois usuários, jose e maria, teria-se então que construir um script para cada, com os nomes jose.bat e maria.bat.




12











mesmos valores.




www.3way.com.br


Esquema de execução do script de logon

Para criar o script de logon será utilizado um editor de textos puro, o vi, por exemplo. No entanto é preciso lembrar que o Unix possui um formato de texto-puro diferente do Windows. O Unix demarca cada final de linha com o caractere especial denominado retorno de carro, representado pelo caractere de escape \r, enquanto que o Windows utiliza o retorno de carro em conjunto com o nova linha (este representado representado pelo \n). Para solucionar esse problema basta converter o arquivo criado no Linux para um formato legível no Windows com a ferramenta unix2dos ou criar esse arquivo no Windows com o notepad ou outra editor de texto puro.

Uma tarefa muito realizada por scripts de logon é mapear uma unidade de rede em máquinas Windows. Mapear uma unidade de rede é criar um atalho no Windows que aponte para um diretório que esteja em alguma máquina da rede. Por exemplo, é possível criar um atalho no Windows chamado H: que leve diretamente para o diretório do usuário no servidor Samba, deste modo, quando o usuário estiver trabalhando em sua estação Windows ele poderá acessar seu diretório no servidor apenas clicando em H: no Windows Explorer.

A linha de comando abaixo deve ser inserida no logon script para realizar o mapeamento de um compartilhamento:

net use H: \\servidor\usuario

Deste modo, ao ser executado, esse script iria criar uma unidade de rede

chamada H: que levaria diretamente para o diretório do usuário usuario no servidor e a sincronização do relógio do cliente com o servidor seria realizada.




12











mesmos valores.




www.3way.com.br


7.16. SERVIDOR WINS

O servidor WINS surgiu da necessidade de resolução de nomes no protocolo NetBIOS (SMB) para endereços IP. Neste protocolo a resolução de nomes é feito através de broadcast. No WINS todas as máquinas registram seu endereço IP, o seu nome e a função no servidor WINS. Assim, o servidor WINS mantém uma relação de nomes e endereços IPs de todas as máquinas da rede.

Funcionamento do Servidor Wins

7.16.1. SAMBA COMO CLIENTE WINS

Esta configuração é baseada na alteração de duas instruções na seção global do arquivo de configuração.

wins server = 192.168.1.10 name resolve order = wins lmhosts bcast

A primeira linha é utilizada para definir o endereço IP do servidor WINS. A

segunda linha define a ordem de consulta para resolução de nomes.

7.16.2. SAMBA COMO SERVIDOR WINS

Configure as seguintes entradas que estão na seção global do arquivo de




12











mesmos valores.




www.3way.com.br


configuração do samba: wins support = yes name resolve order = wins lmhosts bcast

A primeira entrada configura o samba para funcionar como Servidor WINS.

Por questões óbvias as opções wins server e wins support não podem ser utilizadas simultaneamente. O parâmetro name resolve order define a ordem de resolução de nomes Windows.

7.17. COMPARTILHANDO IMPRESSORAS

Servidor Samba compartilhando impressora

Da mesma forma que o Samba compartilha diretórios, o Samba permite

compartilhar Impressoras. Por padrão o smb.conf já vem com a seção [printers], esta seção é utilizada para definir compartilhamentos de impressora. O único esforço, caso não queira atribuir políticas de segurança, seria descomentar os parâmetros e deixar assim como apresentado:

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

printable Faz com que o Samba trate este compartilhamento como uma impressora, esta opção deve estar assinalada com yes. guest ok




12











mesmos valores.




www.3way.com.br


Define se as contas guest tem permissão ou não de acessar o recurso.

7.18. SAMBA COMO CLIENTE

Os comandos abaixos são muitos utilizados para manutenção, teste, verificação, etc. Segue abaixo alguns do principais utilitários do Samba:

smbclient Este utilitário é utilizado para transferir e receber arquivos, de forma semelhante a um

cliente FTP. Veja um exemplo:

smbclient //maq3/c -U usuario -I 192.168.1.2

Este comando solicita acesso no compartilhamento c da máquina maq3. A opção -U indica o usuário que fará a autenticação. Quando o compartilhamento permite acesso de usuário convidado essa opção não será necessária. A opção -I indica o número IP da máquina maq3. Quando o WINS está corretamente configurado, isto também não é necessário. Outra opção também útil é a opção -L, que lista os compartilhamentos do servidor, por exemplo, smbclient -L //maq3 -I 192.168.1.2.

Uma vez conectado em um compartilhamento, os comandos são semelhantes aos de um cliente FTP, por exemplo, os comandos: help, ls, get, mget, put, mput, cd, rm, mkdir, pwd são válidos.

smbmount Este comando permite montar compartilhamentos SMB, de forma que os

compartilhamentos montados são tratados como parte do sistemas de arquivo Linux. smbmount //maq4/d /mnt/comp -o username=usuario ip=192.168.1.102 mount -t smbfs -o username=jonas //maq105/C /mnt/samba

O primeiro parâmetro é a máquina remota seguido de seu compartilhamento d, esta

máquina remota pode ser uma estação Windows que está com o drive d compartilhado. O outro parâmetro /mnt/comp define o ponto de montagem. A opção -o é para utilizar os parâmetros username e ip. O parâmetro username é utilizado quando o compartilhamento exige um usuário e senha, o parâmetro ip é utilizado para especificar o endereço IP da máquina maq4.

As permissões deste diretório montado serão de acordo com o usuário que foi fornecido. Para desmontar o diretório montado, você pode utilizar o comando smbumount ou o próprio comando umount.

smbumount /mnt/comp

ou umount /mnt/comp




12











mesmos valores.




www.3way.com.br


7.19. SAMBA NO CLIENTE WINDOWS

Depois de ter configurado o servidor Samba corretamente, basta ingressar normalmente as máquinas Windows no domínio, como se o Samba fosse um controlador de domínio nativo. A única restrição acontece em máquinas Windows 7. As versões do Samba que já possuem suporte são:

Samba 3.4 ou superior Samba 3.3.5 ou superior Samba 3.3.2, 3.3.3 e 3.3.4 Samba 3.2.12 ou superior

Se a versão utilizada é mais antiga que as descritas acima, provavelmente será o Windows retornará mensagens de erro tais como “A relação de confiança entre a estação e o controlador de domínio falhou”, porém esse inconveniente é contornável ao se fazer as alterações abaixo na Registry do cliente:

HKLM\System\CCS\Services\LanmanWorkstation\Parameters DWORD DomainCompatibilityMode = 1 DWORD DNSNameResolutionRequired = 0

O Samba também traz no seu código fonte um arquivo de correção, o endereço desse arquivo é $SOURCE/docs-xml/registry/Win7_Samba3DomainMember.reg ou no Samba Bugzilla (https://bugzilla.samba.org/attachment.cgi?id=4988&action=view). Após a aplicação da correção é necessário reiniciar a máquina ou o serviço LanmanWorkstation.




12











mesmos valores.




www.3way.com.br


7.20. LABORATÓRIO

Este laboratório implementa o Samba como PDC para compartilhamento de pastas e autenticação de usuários. As máquinas virtuais deverão ser usadas para a implementação. O Linux será o servidor e o Windows será o cliente. Descrição do Ambiente - Tanto a máquina Linux (Servidor PDC) quanto o cliente Windows XP (Cliente) terão suas interfaces configuradas no modo Rede Interna para não haver problemas na rede do laboratório. - Servidor Endereço IP: 192.168.3.1 Sub-rede e sub-máscara: 192.168.3.0 e 255.255.255.0 Gateway: 192.168.3.254 Servidores DNS: 192.168.3.253, 192.168.3.252 Domínio Samba: 3WAYLOCAL Compartilhamentos: /dados/planilhas e /opt/softwares

A. No servidor abrir o arquivo /etc/samba/smb.conf e faça a seguinte configuração:

/etc/samba/smb.conf [global] # --- Nome do seu Servidor --- comment = Servidor SAMBA PDC # --- Domínio do servidor PDC --- workgroup = 3WAYLOCAL # --- Configuracao para uso de usuário e senha --- security = user os level = 100 domain logons = yes # --- Determina o script logon --- logon script = %U.bat # --- Opções de PDC --- domain master = yes local master = yes preferred master = yes encrypt passwords = yes debug level = 3 log file = /var/log/samba_log.%u unix password sync = yes # --- Secao de Compartilhamentos --- [netlogon]




12











mesmos valores.




www.3way.com.br


comment = Scripts # --- Caminho para os scripts --- path = /etc/samba/scripts/ public = no browseable = no writeable = no [planilhas] comment = Planilhas path = /dados/planilhas browseable = yes writeable = yes force create mode = 0770 force directory mode = 0770 [softwares] comment = Softwares path = /dados/softwares browseable = yes writeable = no force create mode = 0700 force directory mode = 0700

B. Reiniciar o servidor para efetivar as configurações.

chkconfig smb on /etc/init.d/smb start

C. Criar uma conta de usuário e de máquina. addgroup maquinas useradd -d /dev/null -g maquinas -s /bin/false maquina$ smbpasswd -a -m maquina

D. Criar senha administrativa do Samba. Essa senha deverá ser diferente do superusuário.

smbpasswd -a root

E. Agora é adicionar o Windows XP ao domínio 3WAYLOCAL. Usar a senha administrativa do Samba para ingressar a máquina no domínio.




12











mesmos valores.




www.3way.com.br


7.21. EXERCÍCIOS

1. Escreva o comando para montar em um cliente Linux, um compartilhamento chamado docs de um computador de nome serv1 para o ponto de montagem /var/documentos. O número IP do servidor é 10.1.0.2 e o usuário é fulano.

2. Como faço para: a) visualizar quais são os compartilhamentos de um servidor de arquivos Windows através do Linux? b) Visualizar um conteúdo de um compartilhamento CIFS pelo Linux, sem montar o diretório no Linux?

3. Quais são as opções para a diretiva security e quais as diferenças entre elas?

4. Qual são os passos necessários para se fazer um servidor Samba atuar simplesmente como um servidor de arquivos, sem identificar os usuários, porém com autenticação por senha? E para um PDC, com autenticação de senhas?

5. Preciso fazer com que todos arquivos e diretórios criados no compartilhamento vendas sejam criados como pertencentes ao grupo vendas, e também que todos os arquivos tenham permissão de escrita e leitura para o grupo e os diretórios tenham permissões de leitura, acesso e escrita. Como isto poderia ser feito?

6. Qual as semelhanças e diferenças do WINS e do DNS? Como se configura um servidor WINS no samba?

7. Quais são os passos necessários para se compartilhar uma impressora no Linux?

8. Descreva as características dos protocolos: SMB, NetBEUI, NetBIOS. O que é CIFS? E o que é NetBT?

9. Quais seriam os passos para se incluir uma estação Windows NT Workstation em um domínio controlado pelo Samba? Quais seriam os passos para se incluir um servidor samba em um domínio pré-existente, tendo um PDC Samba? E se o PDC for Windows NT?

10. O que é o serviço localizador [browsing] e qual é a sua função em um grupo de trabalho? Quais são os tipos de localizadores em um domínio? Como você pode influenciar uma votação de um localizador através da configuração de um servidor samba? Se já existir um PDC na rede, é conveniente configurar o samba como localizador mestre do domínio?




12











mesmos valores.




www.3way.com.br


7. FTP (FILE TRANSFER PROTOCOL)

7.1. INTRODUÇÃO

O FTP é acrônimo de File Transfer Protocol (Protocolo de Transferência de Arquivos) e está entre os mais antigos serviços do UNIX, sendo até hoje um dos protocolos de maior utilização na Internet. Sua principal finalidade é transferir arquivos entre estações, tanto enviando quanto recebendo arquivos.

7.2. PROTOCOLO FTP

Servidor FTP

O protocolo FTP é definido por várias RFCs, mas a principal e mais atual é a

RFC 959, e se caracteriza-se por utilizar duas portas para conexão, uma porta é




12











mesmos valores.




www.3way.com.br


utilizada para autenticação do cliente e a outra é utilizada para transferência de dados, ou seja, ao cliente solicitar uma conexão a um servidor de ftp, primeiramente ele utilizará a porta de autenticação do cliente, somente depois da autenticação o cliente passará a utilizar a porta de transferência de dados e então poderá enviar e receber arquivos. A porta de autenticação do cliente é uma porta para controle, nesta porta é possível enviar comandos e receber os resultados dos comandos. Existem dois canais distintos de comunicação para proporcionar um melhor controle. Por exemplo, se no canal de dados estiver baixando um arquivo, sem nenhuma interferência é possível cancelar esta operação de download, através do canal de controle.

O arquivo /etc/services define no sistema as portas que serviço ftp utiliza. cat /etc/services | grep ftp ftp-data 20/tcp ftp 21/tcp

A primeira entrada é a porta ftp-data responsável pela transferência de dados. A segunda é a porta de autenticação de usuários. Os números das portas são 20 e 21 respectivamente.

Processo de comunicação Cliente/Servidor FTP

O serviço FTP é geralmente controlado pelo super-daemon xinetd/inetd. Ou

seja, eles podem controlar o serviço, de forma que quando um cliente solicita uma conexão com a porta 21, o super-daemon automaticamente cria uma nova instância do daemon ftp para atender a solicitação do cliente.

7.3. INSTALAÇÃO

Os principais servidores FTP disponíveis para o Linux são: vsftpd, proftpd, wu-ftpd e o pure-ftp.




12











mesmos valores.




www.3way.com.br


O vsftpd é um dos mais seguros servidores de FTP utilizados em sistemas UNIX e será o utilizado para demonstração.

Padrões Vsftpd

Portas padrão: TCP/UDP – 21 e 20 O principal arquivo de configuração: /etc/vsftpd/vsftpd.conf Os usuários que não têm permissão para logar via ftp: /etc/vsftpd/ftpusers


Uma vez obtido o código fonte (vsftpd.beasts.org), mova o código fonte para um diretório conveniente. Verificar os pré-requisitos do software nos arquivos README ou INSTALL antes de iniciar a compilação, normalmente são o gcc, make e bibliotecas padrão do C.

tar zxf vsftpd-versao.tar.gz -C /usr/local/src cd /usr/local/src/vsftpd-versao make make install


yum install vsftpd

apt-get install vsftpd

7.4. USUÁRIOS FTP

O FTP trabalha praticamente com 2 tipos de usuários: anonymous (Anônimo) e real (Real). A diferença entre eles será descrita adiante.

Usuário Anônimo Não se precisa de senha com esse tipo de usuário. Essa implementação se dá

com a edição do arquivo /etc/vsftpd/vsftpd.conf da seguinte maneira: /etc/vsftpd/vsftpd.conf listen=YES #listen_address=IP_da_interface_de_escuta




12











mesmos valores.




www.3way.com.br


local_enable=NO anonymous_enable=YES write_enable=NO anon_root=/var/ftp/pub xferlog_enable=YES xferlog_file=/var/log/xferlog

/etc/init.d/vsftpd start

Usuário Real Este usuário é caracterizado por ter uma conta normal no sistema Linux, ou seja, possui um

login e uma senha para acessar o sistema. Este usuário pode navegar por toda a árvore de diretório do Linux desde que tenha as devidas permissões. Por padrão, quando o usuário é criado no sistema ele terá imediatamente acesso ao servidor FTP.

O serviço FTP não criptografa as senhas que trafegam pela rede, portanto, é recomendável que o super-usuário não possa acessar o serviço como cliente. Em alguns casos, é necessário até desabilitar os usuários reais para não correr riscos. O arquivo que faz essas restrições é /etc/ftphosts.

Uma implementação básica desse tipo de usuário será apresentada abaixo:

/etc/vsftpd/vsftpd.conf listen=YES #listen_address=IP_da_interface_de_escuta local_enable=YES anonymous_enable=NO connect_from_port_20=YES write_enable=YES xferlog_enable=YES xferlog_file=/var/log/xferlog ftpd_banner=Servidor FTP 3WayLocal userlist_enable=YES /etc/init.d/vsftpd restart

7.5. FIREWALL E IP_CONNTRACK

Para o perfeito funcionamento do FTP é importante configurar o módulo ip_conntrack_ftp e criar algumas regras de firewall como se segue:

/etc/sysconfig/iptables-config IPTABLES_MODULES="ip_conntrack_ftp"

/etc/sysconfig/iptables -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT /etc/init.d/iptables restart




12











mesmos valores.




www.3way.com.br


7.6. ARQUIVOS DE LOG DO FTP

O Principal arquivo de log é o /var/log/xferlog. O conteúdo desse arquivo apresenta algo semelhante ao trecho abaixo:

/var/log/xferlog Thu Mar 28 00:32:11 2012 1 192.168.1.118 79 /documento.doc b _ o a

[none_given] ftp 0 * c Thu Apr 11 01:00:16 2012 1 192.168.1.110 15 /texto.txt b _ o r antonio

ftp 0 * c

Neste arquivo é possível notar informações como o usuário que acessou o servidor, data e

hora de acesso, arquivo que este enviou ou obteve. A primeira linha desta saída é referente ao usuário anonymous. A segunda linha é referente ao usuário antonio.

Os logs do FTP também são observados no arquivo /var/log/messages que é utilizado pelo syslogd.

tail -n6 /var/log/messages Apr 11 00:34:18 maq19 ftpd[1511]: FTP LOGIN FROM maq10.3waylocal.net.br

[192.168.1.110], main Apr 11 00:37:28 maq19 ftpd[1511]: FTP session closed Apr 11 00:53:35 maq19 ftpd[1567]: FTP LOGIN FROM maq13.3waylocal.net.br

[192.168.1.113], antonio Apr 11 00:59:52 maq19 ftpd[1575]: FTP LOGIN FROM

maq10.3waylocal.net.br[192.168.1.110], maria Apr 11 01:00:19 maq19 ftpd[1575]: FTP session closed Apr 11 01:07:15 maq19 ftpd[1567]: FTP session closed

7.7. EXECUTANDO O CLIENTE FTP

A conexão em um servidor FTP via linha de comando é feita de acordo com a sintaxe abaixo:

ftp hostname_ou_IP_servidor

Exemplo: ftp maq1.3waylocal.net.br A execução deste comando apresentará uma interface que pedirá autenticação.

O usuário para a conexão como anônimo é anonymous e sua senha é nula. Já os outros usuários utilizarão suas senhas de sistema.

Os comandos disponíveis para o cliente podem ser visualizados através da

ajuda (help) do ftp no seu próprio prompt.




12











mesmos valores.




www.3way.com.br


Processo de transferência de arquivo entre Cliente/Servidor FTP

Abaixo estão os principais comandos que podem ser utilizados em uma sessão

ftp. CD Muda o diretório de trabalho na máquina remota para diretório-remoto. Exemplo: cd diretorio CHMOD Muda as permissões do arquivo nome_do_arquivo no sistema remoto para permissoes. Exemplo: chmod 640 documento.odt CLOSE Termina a sessão FTP com o servidor remoto e retorna ao interpretador de comandos local. Pode também ser utilizado quit. Exemplo: close DELETE Apaga o arquivo arquivo-remoto na máquina remota. Exemplo: delete documento.odt MGET Permite receber arquivos da máquina remota. O arquivo será copiado para máquina local no diretório onde o usuário estava ao executar o ftp. Isto pode ser mudado através do comando lcd. Exemplo: mget documento.odt MPUT Permite enviar arquivos da máquina local para a máquina remota.




12











mesmos valores.




www.3way.com.br


Exemplo: mput /opt/arquivos/relatorios.pdf SIZE Retorna o tamanho do nome_do_arquivo na máquina remota. Exemplo: size relatorios.pdf SIZE Retorna o tamanho do nome_do_arquivo na máquina remota. Exemplo: size relatorios.pdf SYSTEM Mostra o tipo do sistema operacional utilizado na máquina remota. Exemplo: system




12











mesmos valores.




www.3way.com.br


7.8. LABORATÓRIO

Essa implementação não será mais difícil da que já foi vista, pois aqui terá maior enfoque nos testes do servidor. Configuração

/etc/vsftpd/vsftpd.conf listen=YES #listen_address=IP_da_interface_de_escuta local_enable=YES anonymous_enable=NO connect_from_port_20=YES write_enable=YES xferlog_enable=YES xferlog_file=/var/log/xferlog banner_file=/etc/vsftpd/issue userlist_enable=YES /etc/init.d/vsftpd restart

Criação do banner /etc/vsftpd/issue NOTA PARA USUARIOS O uso desse serviço implica no consentimento de monitoramentos e testes. Todas as atividades serão gravadas com o seu endereço IP e nome de host.

Inicialização automática no boot

chkconfig vsftpd on /etc/init.d/vsftpd start netstat -tulpn | grep :21

Executando os testes a partir dos clientes

$ftp ip_servidor system ls mput /etc/printcap size printcap




12











mesmos valores.




www.3way.com.br


7.9. EXERCÍCIOS

1. Qual é a diferença entre os usuários real, convidado e anônimo?

2. Quais são as portas que um servidor FTP utiliza e qual a função delas?

3. Quais seriam os passos necessários para se habilitar o acesso anônimo ao servidor FTP? Qual seria o(s) possível(is) procedimento(s) para desabilitar ftp anônimo?

4. Como eu poderia impedir que determinados usuários pudessem efetuar logon no servidor ftp? Qual seria um possível motivo para impedir algum usuário de efetuar logon no servidor ftp?

5. Suponha que você deseje que todos usuários reais tenham acesso negado, mas liberando somente usuários anônimos. Mostre pelo menos duas formas de implementar esta opção. Qual seria a forma mais simples? Cite uma situação onde este tipo de configuração seria conveniente.

6. Como eu habilitaria que um usuário anônimo pudesse fazer envio de arquivos (upload) em um diretório específico? Quais riscos de segurança poderia ter esta permissão e o quais medidas de segurança poderiam ser feitas tornar essa permissão mais segura?




12











mesmos valores.




www.3way.com.br


8. SERVIDOR WEB

A principal função de um servidor web é disponibilizar dados, podendo ser imagens, vídeos, áudio, ou arquivos em geral. Estes dados são passados para os clientes de forma que estes possam exibir as informações. O cliente de um Servidor Web é o browser ou navegador (por exemplo, Internet Explorer, Mozilla Firefox, Google Chrome, Opera, Lynx, eLinks, etc) e o formato entendido por eles é o HTML (HyperText Markup Language) que é a linguagem utilizada para formatar e definir páginas da Internet.

Processo de requisição de uma página web na Internet

O servidor web utiliza-se do protocolo HTTP (HyperText Transport Protocol),

o protocolo mais conhecido da Internet, que utiliza-se de hiper-textos, que são textos com referências (links) que levam a outros textos, formando uma teia de páginas interligadas, daí vem o nome WWW que significa World Wide Web (Grande Teia Mundial).




12











mesmos valores.




www.3way.com.br


8.1. WORLD WIDE WEB

A World Wide Web (WWW) é a estrutura pela qual documentos espalhados por todo mundo são acessados na Internet. Em seus primórdios, os documentos eram formados somente de texto, mas com o tempo foi-se agregando figuras (jpeg, gif, etc), animações gráficas (Flash, gifs animados, etc), áudio (.au, .wav, .MP3, etc), vídeo (MPEG, divx, etc), desta maneira, os documentos tornaram-se mais poderosos e de interface mais amigável, repercutindo em sua enorme popularidade atual.

Dentro da vertente cliente/servidor, tem-se como cliente, o navegador, no lado servidor tem-se os processos servidores que escutam a porta 80 do protocolo TCP, aguardando por solicitações de clientes. Devido à principal funcionalidade do protocolo, a de servir conteúdo aos clientes, este se baseia em solicitação e resposta através de conexões temporárias com duração suficiente para solicitar o conteúdo e baixar o conteúdo solicitado. Este protocolo baseado em solicitação e resposta é o HTTP.

Procedimento de acesso ao Servidor Web.

1. O navegador pergunta ao DNS: Qual é o endereço IP de www.3way.com.br?

2. O DNS responde: o endereço IP é 67.20.58.196.

3. O navegador estabelece uma conexão com a máquina 67.20.58.196 na porta 80 através do protocolo HTTP.

4. Em seguida, o navegador envia um comando HTTP: GET /jpaulo/apostilarede.html




12











mesmos valores.




www.3way.com.br


5. O servidor www.3way.com.br envia o arquivo apostilarede.html para o cliente.

6. O navegador, depois de baixar o arquivo solicitado, faz a formatação apresentação do mesmo em HTML (apostilarede.html)

8.2. O APACHE

O servidor apache é o servidor Web mais popular no mundo devido ao seu desempenho, portabilidade, flexibilidade e baixo custo. Ele foi desenvolvido a partir do servidor Web mais popular antigamente, chamado o daemon httpd, de domínio público e desenvolvido por Rob McCool no NCSA - Nacional Centre for Supercomputing Aplications. O desenvolvimento deste servidor Web estagnou-se quando seu autor deixou a NCSA. A partir deste momento, vários voluntários (webmasters) que conheciam o daemon httpd se interessaram em dar seguimento ao projeto. Estes colaboradores formaram o que é chamado de Projeto Apache. Em menos de um ano de trabalho, o servidor Apache, em sua versão 1.0 lançada em abril de 1995, superou o servidor httpd da NCSA, tornando o Servidor Web mais utilizado na Internet. Para maiores detalhes ler sobre o projeto em http://www.apache.org.

8.3. INSTALANDO O APACHE

Há basicamente duas formas gerais que podem ser utilizadas para instalar o Apache. Através de pacotes ou compilando-se o código fonte.


O código fonte do apache pode ser encontrado no endereço httpd.apache.org/download.cgi. Uma vez obtivo o código fonte, basta satisfazer os requisitos para instalação e executar os comandos abaixo.

tar zxf httpd-versao-tar.gz -C /usr/local/src cd /usr/local/src/httpd-versao ./configure --prefix=/usr/local/httpd-versao make make install

A opção --prefix do script de configuração de ambiente (./configure), indica qual é o diretório sob o qual será criada toda árvore de diretórios, inclusive com todos os arquivos de configuração, binários, etc. Neste caso o diretório escolhido foi /usr/local/httpd-versao, onde versao representa a versão do apache desejada. O comando make compila o código fonte do apache e o comando make install copia os arquivos gerados para a árvore de diretórios criados em




12











mesmos valores.




www.3way.com.br


/usr/local/httpd-versao. Para informações mais detalhadas sobre o procedimento de instalação podem ser vistas nos

arquivos README ou INSTALL que se encontram na raiz do diretório extraído.


yum install httpd

apt-get install apache2 apache2-utils

8.4. PROTOCOLO HTTP

Este é o protocolo padrão de transferência de conteúdo nos Servidores Web. Para conhecer mais a fundo a sintaxe deste protocolo, será utilizado o utilitário telnet, pois através dele pode-se realizar uma comunicação a nível de protocolo HTTP com o servidor web.

telnet localhost 80 GET /index.html HTTP/1.0 <enter>




12











mesmos valores.




www.3way.com.br


Procedimento de acesso ao Servidor Web através HTTP

Através desta experiência, podemos notar que: O HTTP é baseado em solicitações: note o comando GET e a resposta (conteúdo do arquivo /index.html); Conexões HTTP são temporárias: uma vez fornecido o conteúdo solicitado pelo GET (note no argumento do GET o arquivo /index.html) o servidor desconecta automaticamente o cliente. Note no final da transferência do arquivo, a mensagem do telnet “Connection closed by foreign host” no final da resposta do servidor; Existem diferentes versões do HTTP: note que o parâmetro HTTP/1.0 significa qual protocolo está sendo utilizado pelo cliente e qual é a versão de HTTP que está sendo utilizada pelo cliente; Uma linha vazia marca o final da solicitação: apesar de termos enviado inicialmente para o servidor o comando “GET /index.html HTTP/1.0”, o servidor só entende que terminou a solicitação quando for enviado uma linha vazia, verifique que o servidor só respondeu quando foi teclado <ENTER>; A resposta HTTP é formada de cabeçalho e conteúdo: note também o formato da resposta do servidor web, formada de cabeçalho e conteúdo. O




12











mesmos valores.




www.3way.com.br


cabeçalho é formado de informações de controle, necessárias para a correta interpretação do conteúdo. Veja o formato do cabeçalho:

HTTP/1.1 200 OK Informação que a solicitação resultou com código de sucesso 200, que significa OK e a versão do protocolo HTTP do servidor (versão 1.1)

Date: Sun, 07 Apr 2002 16:29:51 GMT A data do servidor Server: Apache/1.3.14 (Unix) (CentOS/Linux) PHP/4.0.3pl1 mod_ssl/2.7.1 OpenSSL/0.9.6

Informações detalhadas do servidor, além das funcionalidades implementadas no servidor (PHP e SSL).

Last-Modified: Thu, 02 Nov 2000 22:00:35 GMT Última modificação do conteúdo solicitado

Content-Length: 2908 tamanho do conteúdo em bytes

Content-Type: text/html; charset=iso-8859-1

Tipo do conteúdo da resposta, juntamente com o tipos de caracteres utilizados

<linha em branco> Serve para separar o cabeçalho do conteúdo.

<linha em branco> Serve para separar o cabeçalho do conteúdo.

<conteúdo> O próprio arquivo solicitado

Este cabeçalho fornecido pelo servidor também é utilizado pelo navegador

(cliente) em uma conexão HTTP, porém não é apresentado para o usuário. O cabeçalho tem bastante utilidade para o cliente, pois permite que tenha uma noção melhor do conteúdo fornecido.

8.5. PUBLICAÇÃO DA HOME-PAGE

O objetivo será publicar o exemplo de página HTML simples, sem a sofisticação das páginas vistas nos mais famosos portais. Para isso deverá ser feito o seguinte:

Criação de um arquivo com extensão html, pode ser teste.html Em seguida, mover este arquivo para o diretório /var/www/html

No Debian/Ubuntu o diretório para hospedagem das páginas web é somente /var/www e o daemon

Depois, inicializar o serviço do Apache, seu nome é httpd. service httpd start




12











mesmos valores.




www.3way.com.br


Na instalação compilada do Apache não é fornecido script de inicialização do serviço, é preciso utilizar os comandos apachectl start e apachectl stop para inicializá-lo ou pará-lo respectivamente.

Agora é só abrir um navegador, e digitar como URL http://localhost/teste.html e a página será exibida.

8.6. CONFIGURAÇÃO DO APACHE

O arquivo de configuração do Apache fica dentro do diretório /etc/httpd/conf (no CentOS/RHEL) e seu nome é httpd.conf, já no Debian/Ubuntu ele fica em /etc/apache2/ com o nome de apache2.conf. A árvore do diretório de configuração do Debian/Ubuntu é bem diferente do CentOS, pois ao invés de dispor toda configuração em quase um arquivo apenas, a mesma encontra-se em vários sub-diretórios.

Em outra distribuição, basta localizar (comandos find ou locate) por algum desses nomes que se terá uma noção exata do caminho específico.

As diretivas de configuração mais comuns do Apache serão comentadas a seguir:

ServerAdmin Define o endereço de e-mail do administrador do servidor WEB. ServerAdmin [email protected]

ServerName Define o hostname completo do servidor e a porta em que ele está atendendo solicitações. ServerName www.3waylocal.net.br:80

DocumentRoot Estabelece o local onde os documentos Web serão armazenados para exibição nos clientes. DocumentRoot /var/www/html

DirectoryIndex Indica quais serão os arquivos de índice que serão fornecidos aos clientes quando do acesso ao servidor (via browser). Podem ser colocados vários arquivos, mas se algum desses arquivos não existir, o servidor retornará erro ou algum conteúdo não desejado. DirectoryIndex index.htm index.html index.php default.pl




12











mesmos valores.




www.3way.com.br


Listen Esta diretiva especifica quais interfaces e portas o servidor vai escutar. Abaixo temos dois exemplos, o primeiro especifica a interface e a porta, já o segundo somente a porta. Listen 192.168.1.101:80 Listen 7007

UseCanonicalName Força o uso de nomes canônicos ao invés de endereços IPs. Exemplo: supondo que o cliente use o endereço IP 67.20.58.196, se o servidor web estiver configurado para usar nomes canônicos, imediatamente o endereço www.3way.com.br irá substituir esse IP. UseCanonicalName on

ServerRoot Esta diretiva define o diretório onde deverão ser armazenados os arquivos de configuração, erros e logs de acessos do servidor Web. ServerRoot /etc/httpd

CustomLog Define qual é o arquivo de logs de acesso e qual é o formato dos logs que este arquivo seguirá. CustomLog /var/log/httpd/access_log common

Este arquivo é utilizado por analisadores de log como o webalizer para se obter estatísticas de acesso do servidor. Os analizadores de logs normalmente produzem relatórios HTML muito úteis para a administrar o servidor.

LogFormat Define o formato dos logs, ou seja, o que vai ser registrado nos arquivos de log. Para isso existe uma série de variáveis que podem ser utilizadas para facilitar a construção desses formatos. A baixo tem-se uma tabela de variáveis mais úteis. Variável Descrição

%A Endereço IP local. %a Endereço IP remoto. %b Bytes transmitidos. %f Nome do Arquivo.




12











mesmos valores.




www.3way.com.br


Variável Descrição %h Host remoto. %H Protocolo Requisitado. %l Nome de usuário remoto, se foi fornecido. %r Primeira linha da solicitação. %s Status do retorno. %t Data e Hora. %T Tempo gasto no atendimento da requisição. %u Nome de usuário, obtido de uma autenticação.

Exemplos: LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""

combined LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent

ErrorLog Define o arquivo de log de erros. O diretório fornecido como argumento desta diretiva (httpd/error_log) é um caminho relativo ao da diretiva ServerRoot. Ou seja, a localização absoluta padrão deste arquivo seria /var/log/httpd/error_log. ErrorLog /var/log/httpd/error_log

User / Group Define respectivamente o usuário dono e grupo dos processos filhos do servidor Web. O dono do processo pai sempre é o super-usuário (root).User apache Group apache

Userdir Permite que cada usuário do servidor tenha sua própria página Web. Assim, cada usuário poderá publicar seus trabalhos, curriculum, documentários, etc. A diretiva que implementa esta funcionalidade é a UserDir. UserDir public_html

1. Criar o sub-diretório na raiz do diretório home chamado public_html com as permissões 755; 2. Modificar as permissões do home do usuário para 711, para que o processo httpd tenha acesso de leitura no diretório para o usuário apache. 3. Postar os documentos html que se deseja dentro de public_html.




12











mesmos valores.




www.3way.com.br


Alias




12











mesmos valores.




www.3way.com.br


Permite definir apelidos para diretórios não usuais. Esses apelidos são digitados após a própria URL do site e levam a qualquer diretório do filesystem definido na configuração. Normalmente vem antes de uma diretiva Directory (que determina a configuração dos diretórios).

Directory A diretiva Directory serve para agrupar um conjunto diretivas associadas a um

diretório especificado. Ela possui um um formato diferente das demais.

<Directory "/var/www/html"> Options Indexes FollowSymLinks Includes AllowOverride None Order allow,deny Allow from all </Directory>

<Directory "/dados/3way/ensino_a_distancia"> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory> <Directory "/3way/atendimento/www/docs”> Options -FollowSymLinks Includes AllowOverride None Order deny,allow Deny from all Allow from 192.168.1.110 </Directory>

Basicamente as diretivas associadas ao diretório são relativas à segurança: Options - define várias opções relativas à permissão: listar diretórios (Indexes), acessar links simbólicos (FollowSymLinks) e permitir executar tags padrões do servidor (Includes). AllowOverride - permite ou impede as opções (por padrão, nenhuma opção, veja opção None) do arquivo de configuração de acesso à diretórios .htaccess. Geralmente o .htaccess é utilizado para definir senhas de acesso à diretórios. Order - Define a ordem em que serão avaliadas as permissões de acesso a este servidor por redes ou hosts específicos. No nosso caso, será permitir acesso (por padrão allow) para depois proibir (por padrão deny).




12











mesmos valores.




www.3way.com.br


Allow - Define quais servidores (por padrão todos, veja opção all) terão acesso permitido a este servidor. ScriptAlias Definir diretórios dedicados para se executar aplicativos CGI. Para que esta diretiva funcione é necessário habilitar a execução de aplicativos CGI neste diretório, através da diretiva Directory. ScriptAlias /cgi-bin/ "/dados/3way/ensino_a_distancia/cgi-bin/" <Directory "/dados/3way/ensino_a_distancia/cgi-bin"> AllowOverride None Options ExecCGI Order allow,deny Allow from all </Directory>

Basta agora criar um script cgi no diretório específico para isso e depois executá-lo através de uma URL semelhante a esta http://localhost/cgi-

bin/script.sh. VirtualHost Faz com que um mesmo servidor Web responda por mais de um domínio, não precisando de uma máquina para cada um. Este é o recurso utilizado pelos provedores de armazenamento de páginas. <VirtualHost 192.168.1.101:80> ServerAdmin [email protected] DocumentRoot /var/www/html # ServerName www.3waylocal.net.br ErrorLog /var/log/httpd/error_log TransferLog /var/log/httpd/access_log </VirtualHost>

Esta definições são necessárias para o próprio servidor Web primário que

responde por www.3waylocal.net.br. As próximas entradas definirão novos domínios virtuais.

<VirtualHost 192.168.1.101:80> ServerAdmin [email protected] DocumentRoot /var/www/html/info ServerName www.info.3waylocal.net.br ErrorLog /var/log/httpd/info_error_log TransferLog /var/log/httpd/info_access_log </VirtualHost>




12











mesmos valores.




www.3way.com.br


Foi criado no exemplo acima o sub-domínio info.3waylocal.net.br, cuja opção ServerName ilustra. Como a máquina www.info.3waylocal.net.br não existe, será preciso criar uma entrada CNAME no DNS. Caso o DNS seja o BIND, a entrada será semelhante a que está abaixo.

@ IN SOA maq1.3waylocal.net.br. root.maq1.3waylocal.net.br. ( 2012021201; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN MX 5 maq1.3waylocal.net.br. @ IN NS maq1.3waylocal.net.br. maq1 IN A 192.168.1.101 ... www IN CNAME maq1 www.info IN CNAME maq1

A nova linha adicionada está em negrito. Assim a máquina maq1 responderá

por www.3waylocal.net.br e www.info.3waylocal.net.br, o trabalho de carregar o cliente para página (diretório) correspondente será do Servidor Web.




12











mesmos valores.




www.3way.com.br


8.7. LABORATÓRIO

Este laboratório será destinado a criação de dois domínios: 3wayteste.com e 3waylocal.com. Vamos supor nesse laboratório que o IP do servidor é 192.168.1.101.

Domínio 3wayteste.com

/etc/httpd/conf/httpd.conf ... <VirtualHost 192.168.1.101:80> ServerAdmin [email protected] ServerName www.3wayteste.net DocumentRoot /var/www/html/3wayteste_com DirectoryIndex index.htm CustomLog /var/www/html/3wayteste_com/access_log common ErrorLog /var/www/html/3wayteste_com/error_log </VirtualHost>

Domínio 3waylocal.com

... <VirtualHost 192.168.1.101:80> ServerAdmin [email protected] ServerName www.3waylocal.com DocumentRoot /var/www/html/3waylocal_com DirectoryIndex index.html CustomLog /var/www/html/3waylocal_com/access_log common ErrorLog /var/www/html/3waylocal_com/error_log </VirtualHost>

O DNS também deverá ser feita para que ambos os donínios apontem para a mesma máquina.

/etc/named.conf ... zone “3wayteste.com” { type master; file “3wayteste.com.direto”; } ...

/var/named/chroot/var/named/3wayteste.com.direto @ IN SOA 3wayteste.com. webmaster.maq1.3wayteste.com. ( 2012021202; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN MX 5 maq1.3wayteste.com. @ IN NS maq1.3wayteste.com. maq1 IN A 192.168.1.101 www IN CNAME maq1




12











mesmos valores.




www.3way.com.br


/var/named/chroot/var/named/3waylocal.com.direto @ IN SOA 3waylocal.com. admin.maq1.3waylocal.com. ( 2012021202; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN MX 5 maq1.3waylocal.com. @ IN NS maq1.3waylocal.com. maq1 IN A 192.168.1.101 www IN CNAME maq1

/etc/init.d/named restart

/etc/init.d/httpd restart




12











mesmos valores.




www.3way.com.br


8.8. EXERCÍCIOS

1. Existe diferença entre DocumentRoot e ServerRoot? Explique.

2. Suponha o seguinte caso:

DocumentRoot /usr/local/apache/htdocs ServerName www.exercicio3.com.br

O que devo fazer para acessar documentos que estão em /docs quando digitar a URL:

www.exercicio3.com.br/docs

3. Considere as opções acima e certifique-se de que o diretório /usr/local/apache/htdocs esteja com opção de indexação (Option Indexes). Remova os arquivos de exibição automática (index.html). Observe a ultima linha (identificação do servidor) com a opção UseCanonicalName On e UseCanonicalName Off quando digitado a URL localhost e 127.0.0.1.

4. O que são Domínios Virtuais?

5. Crie um diretório /sa/atendimento/cgi-bin e execute um script cgi de script-teste, através do endereço http://localhost/atendimento/cgi-bin/script-teste.sh.




12











mesmos valores.




www.3way.com.br


9. SERVIDOR DE EMAIL 9.1. SERVIDOR DE MENSAGENS

Um servidor de mensagens eletrônicas é responsável pela recepção e envio de mensagens. Dentro deste processo há vários mecanismos utilizados pelo servidor antes da mensagem chegar até o remetente. Atualmente o maior responsável pelo tráfego na Internet é, sem dúvida, o e-mail.

O SMTP (Simple Mail Transport Protocol) é o protocolo de transporte de mensagens utilizado em redes TCP/IP. Um servidor de mensagens oferece outros serviços além de transporte, este deve prover serviços como fornecer apelidos para usuários e fazer roteamento de mensagens.

Como principais Servidores de Mensagens para Linux temos o Sendmail, o Qmail e o Postfix. Os dois últimos são servidores SMTP que surgiram como possíveis substitutos ao Sendmail, pelo fato do sendmail apresentar algumas deficiências: dificuldade de administrar e maior risco de segurança, pois seus processos utilizam o super-usuário como dono.

9.2. AGENTES DE MENSAGENS

No processo de troca de mensagens existem basicamente três agentes de mensagens: MTA (Mail Transport Agent), MUA (Mail User Agent) e MDA (Mail Delivery Agent).

MTA




12











mesmos valores.




www.3way.com.br


Sua finalidade é transportar um e-mail de um MTA até outro MTA. Como exemplo de MTA temos: sendmail, postfix, qmail, Lotus Notes, MS Exchange Server, etc. MUA O Agente de e-mail do usuário é um programa utilizado pelo usuário e tem as finalidades básicas de compor, ler e enviar e-mail. Exemplo de MUA: MS Outlook, Lotus Notes Messenger, Netscape Messenger, elm, mailx (ou mail), mutt, pine, Eudora, Pegasus, etc. MDA Este agente tem como finalidade entregar localmente no servidor a mensagem para seu dono, ou seja, quando o e-mail chega no MTA(Servidor de e-mail), este agente irá armazenar o e-mail na caixa postal do destinatário. O MDA ainda pode fazer mais: filtrar e-mails indesejáveis, responder e-mails automaticamente (por exemplo, estou de férias...), encaminhar um e-mail automaticamente para outro, etc. Como exemplos de MDA, temos: procmail, maildrop, mailagent e sensible-mda.

Alguns servidores de e-mail, tal como o Lotus Notes e MS Exchange Server, desconsideram a separação de MTA e MDA. Estes servidores trabalham como um todo, não separando a funcionalidade de MTA e MDA.

Um processo típico de envio de e-mail pode ser resumido da seguinte

maneira:




12











mesmos valores.




www.3way.com.br


Exemplo de comunicação

9.3. INSTALANDO O SERVIDOR DE EMAIL


Postfix O código fonte do postfix pode ser encontrado em www.postfix.org. Para

compilá-lo, basta seguir os passos abaixo: Criação de grupos e usuários groupadd postdrop adduser -s /bin/false postfix

Prepação da compatibilidade mv /usr/sbin/sendmail /usr/sbin/sendmail.old mv /usr/sbin/newaliases /usr/sbin/newaliases.old mv /usr/sbin/mailq /usr/sbin/mailq.old chmod 755 /usr/sbin/sendmail.old chmod 755 /usr/sbin/newaliases.old chmod 755 /usr/sbin/mailq.old tar xzpvf postfix-versao.tar.gz cd postfix-versao make make install

Seguir as opções padrão da instalação. Dovecot




12











mesmos valores.




www.3way.com.br


O código fonte do Dovecot pode ser encontrado em www.dovecot.org. Para compilá-lo, basta seguir os passos abaixo:

tar zxvf dovecot-versao.tar.gz -C /usr/local/src/ cd /usr/local/src/dovecot-versao ./configure make make install CPPFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib -ldl" ./configure

useradd -s /sbin/nologin dovenull useradd -s /sbin/nologin pop3-login useradd -s /sbin/nologin dovecot


É preciso desabilitar o sendmail antes de efeturar a instalação Postfix.

yum install postfix dovecot

apt-get install postfix dovecot-imap

9.4. CONFIGURAÇÃO

Postfix O arquivo de configuração do Postfix é o /etc/postfix/main.cf. Ele vem com

suas configurações padrão. Abaixo está um exemplo das principais diretivas presentes neste arquivo.

/etc/postfix/main.cf

queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix mail_owner = postfix myhostname = servidor.3waylocal.net.br mydomain = 3waylocal.net.br myorigin = $mydomain inet_interfaces = all mydestination = $myhostname, localhost.$mydomain, $mydomain unknown_local_recipient_reject_code = 500 mynetworks_style = host




12











mesmos valores.




www.3way.com.br


mynetworks = 127.0.0.0/8, 10.0.0.0/24 #mynetworks = $config_directory/mynetworks alias_maps = hash:/etc/aliases home_mailbox = Mailbox mail_spool_directory = /var/spool/mail smtpd_banner = $myhostname $mail_name ($mail_version) sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-versao/samples

Dovecot Dovecot é um servidor POP3 e IMAP de código livre para sistemas

Linux/Unix, criado sob a premissa da segurança. O arquivo de configuração do Dovecot é o /etc/dovecot.conf no CentOS/RHEL e o /etc/dovecot/dovecot.conf no Debian/Ubuntu.

/etc/dovecot.conf

protocols = imap imaps pop3 pop3s mail_location = maildir:~/Maildir pop3_uidl_format = %08Xu%08Xv # Opcional para kernels 32bit, obrigatória para 64 bits login_process_size = 64

Inicialização dos Serviços

/etc/init.d/postfix start

/etc/init.d/dovecot start

/etc/init.d/postfix start

/etc/init.d/dovecot-imap start

Testes SMTP e POP3 Para testar a configuração do SMTP e do POP3 será preciso realizar um telnet

nas portas 25 e 110 respectivamente, seguido dos comandos de conversação dos protocolos em questão. Abaixo tem-se os testes para ambos os protocolos.

Teste de Envio $ telnet localhost 25 220 localhost ESMTP Postfix (versao) ehlo localhost 250-localhost




12











mesmos valores.




www.3way.com.br


250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: usuario1_do_servidor 250 2.1.0 Ok rcpt to: usuario2_do_servidor 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> Subject: Assunto de Email Corpo do Email . 250 2.0.0 Ok: queued as D6D306CA52 quit 221 2.0.0 Bye

Teste de Recebimento $ telnet localhost 110 +OK Dovecot Ready USER beltrano +OK PASS senhabeltrano123 +OK Logged in. LIST +OK 2 messages: 1 466 2 578 . RETR 1 ... Corpo da mensagem … QUIT +OK Logging out.

Para realizar o teste podem ser utilizados Agentes de E-mail de Usuário

(MUA), que são bem mais amigáveis. São exemplos de MUA: Mozilla Thunderbird, Outlook, Zimbra Collaboration (OSE), Evolution, Kmail, etc.

9.5. ALIASES

Para definir aliases (apelidos) para mensagens podemos usar o arquivo aliases. No Linux, normalmente esse arquivo é /etc/aliases.

Alguns exemplos de alias: /etc/aliases # Aliases de systemas padrão, estes DEVEM estar presentes. MAILER-DAEMON: postmaster postmaster: root # Redirecionamentos gerais para contas falsas




12











mesmos valores.




www.3way.com.br


bin: root daemon: root nobody: root # Apelidos bem conhecidos: manager: root dumper: root operator: root # Pessoas quem devem ler os e-mails do root root: usuario #System admisnistrator mailing list treinamento: usuario,virgilio,guilherme,fulano,ciclano coordenacao: usuario,gomes

É importante ressaltar que o postfix não lê diretamente este arquivo, ele faz a

leitura de um banco de dados gerado através do comando newaliases, então toda vez que for feita alguma alteração em /etc/aliases, será necessário executar o comando newaliases para que as alterações sejam efetuadas.

newaliases

É preciso reinicializar o postfix após a alteração. /etc/init.d/postfix restart

9.6. REDIRECIONAMENTO

O redirecionamento de mensagens é muito útil no caso de se ter várias contas de e-mail e querer ler e-mails somente em uma delas. Para redirecionar um e-mail basta criar um arquivo .forward dentro do diretório home de cada usuário e adicionar o e-mail (ou os emails) de destino das mensagens.

cd /home/usuario echo "[email protected]" > .forward

O arquivo deverá ficar semelhante ao abaixo: ~/.forward [email protected]




12











mesmos valores.




www.3way.com.br


9.7. LABORATÓRIO Este laboratório implementará de maneira simples servidor de E-mail (postfix), servidor POP (dovecot), criação de mail boxes e aliases. Configuração do Servidor de E-mails

/etc/postfix/main.cf myhostname = maq1.3waylocal.com mydomain = 3waylocal.com myorigin = $mydomain inet_interfaces = all mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mynetworks = 192.168.1.0/24, 127.0.0.0/8 relay_domains = home_mailbox = Maildir/

Configuração do Servidor POP

/etc/dovecot.conf protocols = imap imaps pop3 pop3s mail_location = maildir:~/Maildir pop3_uidl_format = %08Xu%08Xv #login_process_size = 64

Criação de Usuários Mailbox - Deverá ser criada no diretório home de cada usuário. Aqui criaremos para o usuário usuario.

mkdir /home/usuario/Maildir chown john:john /home/usuario/Maildir chmod -R 700 /home/usuario/Maildir

Criação de Alias - O usuário usuario possui seu endereço de e-mail no formato [email protected], porém ele deseja receber e-mails com os endereços alternativos [email protected] e [email protected]. Então serão criados os seguintes aliases para ele:

/etc/aliases # Person who should get root's mail root: usuario # User aliases j.souza: usuario jef.sou: usuario




12











mesmos valores.




www.3way.com.br


newaliases

Reinicialização do Servidor

/etc/init.d/postfix restart; /etc/init.d/dovecot restart




12











mesmos valores.




www.3way.com.br


9.10. EXERCÍCIOS

1. Mostre o passo-a-passo para enviar através do comando telnet um email via protocolo SMTP para um usuário de sua máquina local chamado “fulano”. Também com o comando telnet, verifique o conteúdo da caixa postal de “fulano”.

2. Como eu poderia configurar o sendmail para que todo email por ele enviado para o usuário root, além de ser armazenado na caixa postal local do root, seja também enviado para o usuário local fulano e para o beltrano, de email [email protected]?

3. Suponha que o seu servidor esteja atualmente enviando e-mail com identificação de remetentes do tipo [email protected], o que deveria ser feito para que isto fosse trocado por simplesmente [email protected]?

4. Defina com suas próprias palavras, os termos MUA, MDA e MTA? O MDA é sempre encontrado nos servidores de email (cite exemplos)? Qual é a diretiva do sendmail que define qual MDA é utilizado?

5. Como eu poderia liberar uma rede de computadores para fazer redirecionamento pelo meu servidor SMTP? Que incoveniência teria em liberar todas redes (sem restrição de relay)?

6. Qual é a funcionalidade e diferenças entre os protocolos SMTP, POP e IMAP? Mostre brevemente como seria a instalação de cada um destes protocolos.

7. O que é o comando mail? Para que serve? Como posso utilizá-lo para enviar , receber e-mail? Como seria utilizado para testar mais detalhadamente o envio de um e-mail?




12











mesmos valores.




www.3way.com.br


10. SERVIDOR PROXY

O proxy surgiu da necessidade de conectar uma rede local à Internet através

de um computador da rede que compartilha sua conexão com as demais máquinas da rede. Em outras palavras, ao considerar que a rede local é uma rede interna e a Internet é uma rede externa, podemos dizer que o proxy é que permite outras máquinas terem acesso externo.

Geralmente, máquinas da rede interna não possuem endereços válidos na Internet e, portanto, não tem uma conexão direta com ela. Assim, toda solicitação de conexão de uma máquina da rede local para um host externo é direcionada ao proxy, este, por sua vez, realiza o contato com o host desejado, repassando a resposta à solicitação para a máquina da rede local. Por este motivo, é que é utilizado o termo proxy (intermediário) para este tipo de serviço.

Um exemplo muito comum de compartilhamento de Internet é baseado em: um servidor proxy com duas interface de rede, geralmente um modem e uma interface Ethernet, sendo que a interface do modem é a interface de saída para Internet, enquanto a interface de rede é a interface de acesso às máquinas da rede local.

O compartilhamento de Internet apresentado se refere ao serviço básico de um proxy. Mas um bom proxy deve ainda prover várias outras funcionalidades complementares tais como:

Cache

Permite armazenar no próprio proxy as páginas visitadas com mais frequência, ou seja, quando um usuário solicita um site na Internet, o proxy armazena o seu conteúdo em cache, juntamente com a sua data. Caso o usuário, depois de um certo tempo, solicite-a novamente, o proxy obtém a data da página remota e caso não seja mais atual que a página que está em cache, este fornece para o cliente a página em cache, sem a necessidade de baixar novamente a página solicitada. Esta funcionalidade aumenta bastante o desempenho do acesso à páginas, uma vez que o




12











mesmos valores.




www.3way.com.br


acesso às páginas em cache são muito mais rápidas que as páginas remotas. Autenticação

Permite autenticar clientes através de login, baseados em usuário e senha. Listas de controles de acesso

Também conhecidas como acls, permite que administrador restrinja o acesso a determinados sites baseados em critérios estipulados em listas de controles. Os critérios podem ser expressos em regras baseadas no login, palavras-chave na URL, palavras-chave no conteúdo do site, horário de acesso, etc.

Proxy transparente

Com o proxy transparente não é preciso configurar o navegador, facilitando a administração da rede. Isto é realizado através de configurações no roteador padrão da rede local, de forma que toda solicitação de tráfego externo é direcionada para o proxy. Assim, o proxy funciona de forma transparente para o usuário, sem necessitar configurar explicitamente o seu uso.

Proxy para SSL SSL é acrônimo de Secure Socket Layer que que permite que um navegador e

o servidor Web estabeleçam uma comunicação segura para realizar transações. O SSL é um camada que criptografa o protocolo HTTP, por isso quando utilizados em conjunto, é chamado também de HTTPS (HTTP Seguro). O proxy, além de comunicar através de protocolo HTTP, também deve permitir comunicação segura de HTTP sobre SSL (HTTPS).




12











mesmos valores.




www.3way.com.br


Arquitetura com proxy

10.1. SQUID

Existem vários softwares proxy de características diferentes, cada um mais especializado que o outro. Dentre os vários proxies existentes para Linux pode ser citado o Squid. Por ser o mais popular, ele será o software abordado nesta sessão.

Squid é um animal cefalópode (como uma lula, polvo, etc) de dez braços, encontrado nas costas marítimas americanas. Ele é o símbolo do software proxy Squid, cujo site é o www.squid.org.

10.2. INSTALAÇÃO


Primeiramente é necessário obter o código fonte do Squid que está disponível no endereço www.squid-cache.org.

tar zxf squid-versao.tar.gz /usr/local/src cd /usr/local/src cd squid-versao ./configure --prefix=/usr/local/squid-versao make all




12











mesmos valores.




www.3way.com.br


make install ln -s /usr/local/squid-versao /usr/local/squid


yum install squid

apt-get install squid

10.3. CONFIGURAÇÃO

O servidor Squid fornece serviço proxy para os principais protocolos utilizados por navegadores, como: FTP, HTTP e HTTPS. Portanto nossas configurações estarão relacionadas a estes dois protocolos.

Depois de instalado, o squid cria o diretório /etc/squid onde armazena seus arquivos, dentre eles encontramos seu principal arquivo de configuração: squid.conf.

10.3.1. SQUID.CONF

Este arquivo é bastante auto-explicativo, contando com muitos comentários sobre as diretivas nele presentes, por esse motivo serão tratadas somente as opções mais importantes.

http_port 3128 Esta parâmetro define a porta que o serviço squid usará. Por padrão, esta opção estará comentada, não é preciso descomentá-la, caso a intenção seja manter a porta padrão. cache_mem 32M

Este parâmetro define a quantidade de cache que o servidor usará. É recomendável deixar uma quantidade considerável da memória física, algo em torno da metade. A performance do servidor proxy é proporcional a quantidade de memória física destinada a ele. cache_dir ufs /var/spool/squid 100 16 256

Este parâmetro define o diretório onde o squid alocará os arquivos para cache, neste caso será o diretório /var/spool/squid. A opção ufs define uma forma de armazenamento do cache, podendo ser utilizados outros formatos, somente por questões de otimização. Existem outras opções de otimização (consultar o arquivo de configuração para saber mais). O valor 100 define o tamanho máximo (em MB) que o diretório pode ter. O valor 16 define a quantidade de sub-diretórios do diretório /var/spool/squid e, por último, o valor 256 define a quantidade de sub-diretórios dos 16 diretórios já mencionados.




12











mesmos valores.




www.3way.com.br


cache_access_log /var/log/squid/access.log Define o arquivo de log de acessos ao servidor proxy. Através dele é possível saber quais usuários (ou IPs) acessaram conteúdo no servidor. cache_mgr endereco_de_email Tem a finalidade de especificar o email do administrador do Proxy. Caso o serviço squid venha a ser terminado de forma anormal, o usuário terá como entrar em contato e informar sua experiência mal-sucedida com o proxy. cache_effective_user usuario Determina qual o usuário pelo qual o proxy executará as solicitações feitas a ele. Por motivos de segurança, não é recomendável utilizar o UID de root (0). Normalmente o usuário utilizado tem o nome squid. cache_effective_group grupo Semelhante a diretiva anterior, porém referente ao GID do grupo que executará as solicitações do proxy. visible_hostname hostname Determina o hostname quer ficará visível.

Se ao iniciar o squid a mensagem “FATAL: Could not determine fully qualified hostname. Please set 'visible_hostname”

aparecer. O daemon do squid não inicializará, para resolver esse problema, basta adicionar o hostname na diretiva visible_hostname.

10.3.2. CACHING

Essa modalidade de proxy apenas provê o caching de páginas, não oferencendo recursos como autenticação, restrições, limitação de banda, etc. Para essa implementação basta configurar a linha http_access deny all, que já está presente no arquivo de configuração, como o valor allow.

O arquivo abaixo apresenta uma configuração básica do servidor proxy para cache de páginas web, cuja principal vantagem é o aumento da velocidade de acesso.

/etc/squid/squid.conf

http_port 3128 cache_mem 32M cache_dir ufs /var/spool/squid 100 16 256 cache_access_log /var/log/squid/access.log cache_mgr endereco_de_email cache_effective_user usuario cache_effective_group grupo visible_hostname saida_comando_hostname




12











mesmos valores.




www.3way.com.br


#http_access deny all http_access allow all

Após essa configuração, basta reiniciar o serviço: /etc/init.d/squid restart

Deste momento em diante o cliente proxy, normalmente um navegador (browser) na máquina cliente, já pode ser configurado para utilizar o servidor proxy.

Configuração do Cliente A configuração do cliente é muito simples, varia de acordo com o navegador

escolhido. Neste caso será utilizado o navegador Mozilla Firefox (versão 10.0.1). 1. Botão Firefox (canto superior esquerdo) – Opções (Options) – Opções

(Options). Será aberta a janela Opções. 2. Aba Avançado (Advanced) – Rede (Network) – Configurações (Settings) Outra janela entitulada Propriedades da Conexão (Connection Settings) será

aberta. 3. Na opção Configuração manual de proxy (Manual proxy configuration), colocar o endereço IP (ou hostname) do proxy e a porta que atende às solicitações.

Para que todas os outros protocolos sejam tratados pelo servidor proxy, é recomendável marcar a opção Usar este servidor proxy para todos os protocolos.




12











mesmos valores.




www.3way.com.br


Configuração do cliente proxy no Firefox (parte 1)

Configuração do cliente proxy no Firefox (parte 2)




12











mesmos valores.




www.3way.com.br


10.3.3. RESTRIÇÕES DE ACESSO

O Squid permite uma grande flexibilidade em sua configuração de acesso. Essa flexibilidade é dada através das acl (Lista de Controle de Acesso). Com as acl é possível restringir o uso de determinados recursos, como web sites, as máquinas que podem acessar conteúdo externo, horários de acesso, usuários autorizados (ou negados), etc. Abaixo segue alguns tipos de ACL que podem ser utilizados:

src Endereço IP de origem. Utilizado para restringir quais clientes podem fazer

uso do proxy. dst Endereço IP de destino. Utilizado para restringir os servidores que podem ser

acessados. dstdomain Domínio de destino. Utilizado para restringir o acesso a um determinados

domínios. time Restinge por Hora do dia e Dia da semana. port Número da porta de destino. Usado para restringir a porta de acesso do

servidor. url_regex Utilizado para restringir determinadas URLs. A comparação de URL é baseada em expressão regular (regex). proto Restrição por protocolo de transferência. proxy_auth Usado para requerer autenticação de usuário.

10.3.4. RESTRIÇÃO DAS REDES

Na configuração de caching ficou faltando especificar quais são as redes




12











mesmos valores.




www.3way.com.br


autorizadas a utilizar o servidor proxy. Da forma como ficou configurada, qualquer rede pode acessá-lo, para que restringir o proxy a somente a rede local, basta efeturar as configurações listadas a seguir.

Substituir a linha: http_access allow all

Por: acl all src 10.0.0.0/255.255.255.0 http_access allow all

Pelo trecho que foi acrescentado/modificado, all é o nome da acl que com a opção src define a rede 10.0.0.0/255.255.255.0. A diretiva http_access allow all permite o uso do proxy pela rede definida na acl all.

Resumindo, toda solicitação que for originada na rede 10.0.0.0/255.255.255.0 será autorizada, enquanto que as solicitações originadas por outras redes serão automaticamente negadas.

10.3.5. RESTRIÇÃO POR SITES

Esta funcionalidade tem como objetivo evitar que os usuários acessem determinados URLs que ferem a política de segurança da empresa. Essas alterações também são baseadas na configuração anterior. A parte em negrito será acrescentada no arquivo de configuração.


... acl listanegra url_regex "/etc/squid/listanegra.txt" http_access deny listanegra acl all src 10.0.0.0/255.255.255.0 http_access allow all ...

A ordem das ACL de configuração são avaliadas de cima para baixo, portanto deve-se atentar pela ordem em que elas são escritas. É sempre interessante negar o acesso a certos recursos para depois liberar os que necessitam de liberação.

Neste caso a acl url_regex define o arquivo /etc/squid/listanegra.txt, que

possui uma lista de URLs baseadas em expressões regulares. A linha seguinte define que as URLs ou palavras chave desse arquivo que forem encontrados nas URLs digitadas nos navegadores clientes serão negadas.




12











mesmos valores.




www.3way.com.br


10.3.6. RESTRIÇÃO POR TERMOS EM URLS

Esta configuração permite negar todos os sites que tenham na URL uma palavra que case com a palavra definida por uma acl.

Novamente, as linhas em negrito devem ser acrescentadas ao arquivo de configuração.


... acl palavra url_regex -i sex http_access deny palavra acl listanegra url_regex "/etc/squid/listanegra.txt" http_access deny listanegra acl all src 10.0.0.0/255.255.255.0 http_access allow all ...

Neste exemplo encontramos a opção -i para o tipo url_regex, esta opção não faz a diferenciação de maiúscula e minúscula verificando a ocorrência de uma palavra similar a sex na URL. Assim, qualquer site que em sua URL contenha a palavra sex será negado. São exemplos de URLs que serão negados: www.sexteste.com.br, www.sexm.com.br, www.sexoesaude.com.br, etc.

10.3.7. AUTENTICAÇÃO

Esta funcionalidade permite que se crie contas de usuários para acesso a Internet. Assim cada usuário além de ter uma conta de acesso à Internet. A solicitação de usuário e senha será feito quando o usuário abrir o navegador e digitar o endereço desejado, se esta página for externa, o proxy requisitará autenticação.




12











mesmos valores.




www.3way.com.br


Processo de autenticação do Proxy Squid

Ao instalar o Squid, o mesmo já traz um programa autenticador, este

programa tem a função de autenticar o usuários de acesso a Internet através do Squid. O próximo passo será adicionar uma linha no arquivo de configuração do proxy que habilite o uso desse programa autenticador. Para isso deve-se procurar por alguma entrada auth_param como a que se segue:

/etc/squid/squid.conf ...

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/credenciais

...

A configuração acima é encontrada a partir da versão 2.6 do squid. Versões inferiores usam authenticate_program /usr/bin/ncsa_auth /etc/squid/credenciais. Plataformas x86_64 usam auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/credenciais.

O programa utilizado nos exemplos acima é o NCSA e o arquivo credenciais

conterão os nomes de usuário (e suas senhas) dos usuários habilitados a acessarem o proxy. Esse arquivo bem como as credenciais dos usuários deverão ser criadas pelo aplicativo htpasswd como no exemplo abaixo.

htpasswd -c /etc/squid/credenciais aluno

A opção -c é usada para criar o arquivo de autenticação, caso ele não exista.

Se ele já existir e a intenção seja mudar a senha de algum usuário ou mesmo criar outro, a opção -c não deverá ser informada. Então a mudança de senha de algum




12











mesmos valores.




www.3way.com.br


usuário seria feita da seguinte forma: htpasswd /etc/squid/credenciais aluno

Depois de feito isto, o próximo passo é adicionar uma acl para esta nova

funcionalidade. Logo, na seção acl do arquivo squid.conf deve-se adicionar a seguinte linha:


... acl password proxy_auth REQUIRED http_access allow password ...

Esta lista de acesso tem a função de liberar o acesso ao proxy somente através

da autenticação do usuário. É importante frisar que esta regra pode ser usada juntamente com as outras sem nenhum prejuízo para o funcionamento do proxy, pois o efeito até então é cumulativo, ou seja, as regras vão se complementado.

Para que estas regras tenham efeito, deve-se reinicializar o serviço proxy (squid):

/etc/init.d/squid restart

/etc/init.d/squid restart

10.4. PROXY TRANSPARENTE

O proxy transparente é aquele proxy que dispensa a configuração do navegador para funcionar, ou seja, por não haver configuração no cliente ele dá a impressão que não existe. Entre outras vantagens do uso desse tipo proxy tem-se:

1. Não é necessário configuração do navegador cliente, o que é muito bem vindo em uma rede com muitos clientes; 2. O uso do proxy transparente força o cliente usar o proxy sem que ele ao




12











mesmos valores.




www.3way.com.br


menos saiba disso; 3. Com a configuração do proxy transparente, todos os serviços ficam disponíveis aos seus clientes.

Representação do Proxy Transparente

10.4.1. IP MASQUERADE

O IP Masquerade é conhecido como NAT (Network Address Translator), assim como o proxy, o IP masquerade tem a finalidade de compartilhar Internet. O IP masquerade não é um proxy, pois trabalha a nível de pacotes TCP, enquanto o proxy trabalha a nível de conexão TCP na camada de aplicação. Entretanto ambos tem a finalidade de compartilhar um conexão com a Internet.

Sabe-se que em uma rede local os endereços IP não são válidos na Internet, e ainda que todo pacote no protocolo TCP/IP enviado deve ser é retornado até o hospedeiro de origem, no sentido de estabelecer uma comunicação. Quando o pacote é direcionado à Internet o mesmo passará pelo o gateway que estará provendo o NAT, então o pacote, na verdade, atinge o host de destino com o número IP do gateway que, por sua vez, possui endereço válido na Internet. Logo esta máquina retornará o pacote para o gateway da rede local que, por sua vez, encaminha-o para a devida máquina que está na rede local.




12











mesmos valores.




www.3way.com.br


O IP masquerade suporta perfeitamente serviços como WWW e E-mail, o que explica o seu grande uso, pois estes serviços são os mais utilizados. Entretanto, o IP masquerade não tem nenhuma funcionalidade de auditoria, autenticação e segurança de acesso, o NAT pode ser utilizado sem o proxy, simplesmente permitindo acesso total à Internet. O IP masquerade tem uma desvantagem quando usado para prover NAT para o serviço WEB, pois o mesmo não conta com o serviço de cache para WWW, o IP masquerade também não conta com a funcionalidade de listas de controles de acesso que o squid fornece.

A ideia aqui é fazer com que o proxy e o IP masquerade trabalhem juntos para prover uma solução viável para o uso em uma rede local, seja qual for a sua dimensão.

Compartilhamento de Internet usando o NAT

10.4.2. PROXY TRANSPARENTE COM SQUID

O IP masquerade faz com que os serviços oferecidos pelo Linux fique transparente aos seus clientes quando os mesmos estão em uma rede local, pois não é necessário configurar o navegador do cliente.

Agora observe sobre os seguintes questionamentos:




12











mesmos valores.




www.3way.com.br


Como utilizar o Squid e não precisar configurar o browser do cliente? Como utilizar o Squid e não ficar restrito aos protocolos HTTPS, HTTP, FTP e gopher? A resposta para primeira pergunta é redirecionar a porta 80 para a porta 3128, porta onde tradicionalmente o squid trabalha. A resposta da última reside em utilizar o squid e o IP masquerade conjuntamente. Logo, surge uma nova pergunta: Como utilizar do IP Masquerade e ao mesmo tempo utilizar o Squid para o acesso a WEB? Se o IP Masquerade estiver rodando e o squid também, o cliente ao solicitar

uma página WEB, o fará através de uma requisição na porta 80 do gateway onde está o IP masquerade, para isto o cliente deve estar com uma rota padrão definida cujo o gateway será o proxy, o gateway buscará a página na Internet e entregará para o cliente utilizando o IP masquerade, logo este cliente não utilizará o Squid, pois o Squid utiliza a porta 3128.

A solução é redirecionar a porta 80 para a porta 3128. Pois assim, toda requisição feita na porta 80 do servidor será direcionada para a porta 3128. Então, não será mais necessário configurar o navegador do cliente.




12











mesmos valores.




www.3way.com.br


Processo de redirecionamento de porta

O proxy transparente não funciona em conjunto com o sistema de autenticação. Caso seja a intenção não será possível implementá-los em conjunto.

A configuração para implementar do proxy transparente nesse novo cenário

que usa o iptables está descrita em detalhes logo abaixo.

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

iptables -t nat -A PREROUTING -i eth1 -p udp --dport 80 -j REDIRECT --to-port

3128

Neste comando há duas considerações: a interface que está sendo utilizada

para fazer o serviço de proxy é a eth0, ou seja, esta interface é a interface de entrada, ou seja, que dá acesso à outra rede; a outra consideração é relativa a porta onde o squid está escutando, neste exemplo estamos utilizando a porta padrão de comunicação do squid (porta 3128).

Agora devemos fazer o IP masquerade através do iptables. Os comandos

serão:




12











mesmos valores.




www.3way.com.br


iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d 0.0.0.0/0 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward

Após essa configuração, basta alterar o arquivo squid.conf somente alterando

a diretiva http_port como está abaixo: /etc/squid/squid.conf ... http_port 3128 transparent ...

10.5. SARG

O SARG é um gerador de relatórios do squid que serve para facilitar a manutenção do serviço. Ele apresenta relatórios HTML dos acessos à internet, bem como tempo de acesso, e outros parâmetros administrativos.

A instalação e configuração do SARG será vista abaixo para a distribuição oficial do curso.

10.5.1. INSTALAÇÃO

O download do código-fonte deverá ser feito do sarg.sourceforge.net.

tar -zxf sarg-versao.tar.gz cd sarg-versao/ ./configure make make install

10.5.2. CONFIGURAÇÃO

A configuração é feita editando-se o arquvios sarg.conf de /usr/local/etc/ e /etc/httpd/conf/.

/usr/local/etc/sarg.conf access_log /var/log/squid/access.log graphs yes graph_days_bytes_bar_color orange title “Relatório de Acessos do Squid” temporary_dir /tmp output_dir /var/www/html/reports/ /etc/httpd/conf.d/sarg.conf Alias /sarg /var/www/html/reports/daily <Directory /var/www/html/reports/daily> DirectoryIndex index.html Order deny,allow Deny from all




12











mesmos valores.




www.3way.com.br


Allow from 10.0.0.X </Directory>

10.5.3. GERAÇÃO DE RELATÓRIOS

A criação do script de geração diária de estatísticas é feita para automatizar o processo de geração de relatórios.

/etc/cron.daily/sarglog.sh #!/bin/bash #Pega a data atual HOJE=$(date +%d/%m/%Y) #Pega um dia antes de hoje ONTEM=$(date –date “1 day ago” +%d/%m/%Y) /usr/local/bin/sarg -l /var/log/squid/access.log -o

/var/www/html/reports/daily -z -d $ONTEM-$HOJE exit 0 chmod 770 /etc/cron.daily/sarglog.sh

Agora é só acessar o relatório de acessos pelo url http://10.0.0.1/sarg




12











mesmos valores.




www.3way.com.br


10.6. LABORATÓRIO

Este laboratório irá implementar um servidor proxy com as opções de caching e autenticação de usuários. Três usuários específicos: João, Maria e Pedro.

A lista de sites negados irá conter: www.uol.com.br, www.globo.com e www.terra.com.br.

A lista de palavras não permitidas em URLs será: sex, sau e bri.

O servidor deverá ter duas interfaces de rede: uma configurada como Bridge (IPs da rede local do laboratório) e a outra como Rede Interna configurada para a rede 10.0.0.0/24. A) Arquivo de configuração

/etc/squid/squid.conf http_port 3128 cache_mem 128M cache_dir ufs /var/spool/squid 100 16 256 cache_access_log /var/log/squid/access.log cache_mgr [email protected] cache_effective_user squid cache_effective_group squid auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/senhas acl password proxy_auth REQUIRED http_access allow password acl palavra url_regex -i sex sau bri http_access deny palavra acl listanegada url_regex "/etc/squid/listanegada.txt" http_access deny listanegada acl redelocal src 10.0.0.0/255.255.255.0 http_access allow redelocal

B) Criação Arquivos - Autenticação

htpasswd -c /etc/squid/senhas joao htpasswd /etc/squid/senhas maria htpasswd /etc/squid/senhas pedro

- Lista Negada

/etc/squid/listanegada.txt www.uol.com.br www.globo.com www.terra.com.br




12











mesmos valores.




www.3way.com.br


Reiniciar o serviço /etc/init.d/squid restart

C) Configuração dos clientes




12











mesmos valores.




www.3way.com.br


10.7. EXERCÍCIOS

1. Qual a finalidade do Proxy? O Proxy Squid trabalha com quais protocolos? Explique a função de cada um destes protocolos.

2. Explique o funcionamento do proxy, relatando como o proxy é capaz de compartilhar seu acesso a Internet com máquinas que não possuem endereço válido na Internet.

3. Como implementar restrições ao meu servidor Proxy? Como eu poderia restringir acesso ao meu servidor proxy através de autenticação de usuários?

4. Qual é o arquivo de Log do Proxy onde posso obter informações sobre sites acessados e negados?

5. O que é proxy transparente? Como criar um proxy transparente? Qual a sua vantagem?

6. O que é NAT? Qual ferramenta pode ser utilizada para implementar o NAT? Explique a vantagem do NAT em relação ao proxy.

7. Como funciona o NAT (IP Masquerade)?

8. Como utilizar o Proxy e o IP Masquerade conjuntamente, sendo que o proxy será utilizado apenas para trabalhar com o protocolo HTTP e o IP Masquerade para trabalhar com os demais protocolos?

9. Qual as vantagens e as desvantagens do proxy em relação ao IP Masquerade?


Linux Network Administration COMPLETA

Documents

Transcript of Linux Network Administration COMPLETA