Manual Administração da Rede de Computadores do Curso de. Ciência da Computação

Transcrição

1 Manual para a Administração da Rede de Computadores do Curso de Alfenas, Abril de 2010

2 Apresentação Este manual tem como objetivo apresentar de uma forma detalhada todas as decisões tomadas sobre a topologia da rede local de computadores do curso de da Unifal-MG. Estas decisões vão desde decisões sobre os servidores de redes a serem usados e os respectivos serviços oferecidos por eles a uma ampla gama de clientes tanto localmente nos laboratórios quanto remotamente para que alunos e professores consigam manipular seus experimentos a qualquer momento. Assim sendo, este manual serve como guia para os estagiários no papel de administradores dos servidores da rede como para os estagiários dos laboratórios do BCC. De maneira mais específica, todos os passos adotados durante as configurações de servidores de arquivos, servidores web e Proxy, cotas de usuários, etc. estão documentadas neste manual. Também documentamos as decisões de design e arquitetura consideradas na fase de planejamento da estrutura da rede. Um dos principais objetivos deste manual é auxiliar de uma forma bastante ampla a manutenção e conservação deste sistema, durante a troca entre professores administradores e estagiários que estejam vinculados a este processo. O assunto abordado neste manual envolve todo o processo de administração estabelecido e presente nas máquinas que estejam vinculadas ao BCC. Assim, foram descritos os processos de instalação dos servidores com o sistema Linux, mais especificamente na distribuição Debian 5.4, codinome Lenny. Modelos de 2

3 compartilhamentos de arquivos entre Linux/Windows, servidor Proxy, etc. também estão documentados. Este manual começou a ser escrito em abril de Após finalização, sugere-se sua atualização constante na medida que haja um rodízio entre professores, técnicos e estagiários ou até mesmo, alguma política adotada aqui, seja substituída ou atualizada. Cordialmente Tiago Silveira Rodrigo Martins Pagliares 3

4 Sumário Estrutura Física e Configuração de Hardware dos Laboratórios do BCC Introdução D D LInC LP&D Laboratório de Engenharia de Software e Computação Gráfica Laboratório de Redes de Computadores Configurações de Hardware e dos Serviços oferecidos pelos servidores do BCC Introdução Turing Configuração de Hardware Sistema Operacional Serviços oferecidos Gödel Configuração de Hardware Sistema Operacional Serviços oferecidos Comentário final Instalação do Debian Netinst Introdução Debian NetInst Instalando o Debian NetInst Obtendo a imagem Iniciando a instalação Configurações iniciais Configurações iniciais da rede Host Domínio Horário

5 Particionamento (SERÁ QUE NÃO COMPENSA PARTICIONAR COM VOLUMES LÓGICOS - LVM??? Será que compensa deixar um espaço livre em disco para particionamentos futuros? Quando formos fazer a instalação definitiva, deveremos tirar screeshots e atualizar este documento) Tipo de particionamento realizado (ESTAS, COMO AS OUTRAS FIGURAS, SERÃO ATUALIZADAS POSTERIORMENTE) Tabela de partições Começando a criar as partições Planejamento dos Tipos e tamanho das Partições utilizadas Partição / Partição /home Partição /var/ Partição swap Gravando as partições criadas Instalação do Debian Configuração de usuários e senhas Localização do repositório Problema no espelho de rede Continuando a instalação Seleção do software Carregador de inicializações - GRUB Fim do processo de instalação Verificando a instalação Gerenciamento de Pacotes no Debian Lenny Introdução O utilitário APT Sources.list Configurando o arquivo /etc/apt/sources.list APT via Proxy Problemas encontrados após a instalação do Sistema Introdução Mudança de eth0 para eth1 e vice-versa a cada reboot Placa de rede reconhecida, mas não operante Migração de informações para os novos servidores Introdução

6 Política de backup dos usuários, grupos e pasta /home Script para automação das tarefas Servidor Turing Antigo Primeiro passo Criar um diretório para armazenar o backup Segundo passo Criar uma cópia dos arquivos de configuração Terceiro passo Fazendo o backup do diretório /home Automação das tarefas Servidor Turing Novo Configuração do SSH para acesso remoto Introdução Instalando o SSH no Debian Configuração dos arquivos de configuração Configuração do cliente Compressão dos dados transmitidos Manutenção da conexão por um maior intervalo de tempo Porta Configuração do servidor Controle de acesso Protocolo Usuários e senhas Arquivo /etc/hosts Acesso remoto através do SSH Incrementando a segurança Transferência de arquivos Aplicativos em modo texto SFTP SCP Outros comandos Aplicativos em modo gráfico Nautilus Putty WinSCP Finalizando o assunto de SSH Arquivos de configuração do SSH Servidor de Quotas

7 Introdução Configurando as quotas DHCP Introdução O que é o DHCP? DHCP em Linux Configurando o dhcpd.conf Cliente DHCP DHCP com IP fixo Configurando para IP fixo IPV Arquivo de configuração do DHCP Servidor Proxy Introdução Configurando o Proxy no Browser Firefox IE Chrome Tipos de Proxy Proxy Transparente Proxy Não-Transparente Squid Instalação Arquivo /etc/squid/squid.conf Configuração básica Testando uma configuração Abrindo a porta no firewall Iniciando as configurações avançadas Repasse direto Cache de páginas e arquivos Configurando o tamanho do cache da RAM Configurando o tamanho do cache do HD Configurando o arquivo de log

8 Padrão de atualização Restrições de acesso Por domínio e palavras Erro pertinente a um acesso sem permissão Por horário Exceções de acesso por IP Exceções por formatos de arquivos Gerenciando o uso de banda Configurando um Proxy com autenticação Módulos para autenticação ncsa_auth smb_auth Outros módulos Configurando um Proxy transparente Configuração do compartilhamento Incrementando a segurança Redirecionamento da porta Configuração do arquivo /etc/squid/squid.conf Considerações importantes Configuração automática de Proxy nos clientes Configuração no cliente Configurando o Firefox Configurando o IE e o Chrome Configuração automática Arquivo de configuração do Squid Monitoramento de acesso Sarg ntop Bloqueio de páginas impróprias por conteúdo SquidGuard Obtenção das listas negras Configuração do SquidGuard Configuração do Squid

9 Criando listas brancas Arquivo de configuração do SquidGuard DansGuardian Utilizando o DansGuardian Configurando o DansGuardian Configurando a filtragem Utilizando após as configurações Atualizando as blacklists Proxy transparente com o DansGuardian Arquivo de configuração do DansGuardian Firewall DNS Samba Novo Tópico Configurações Específicas Introdução Função de autocompletar comandos Outros comandos Anexo I Configurações de SSH Cliente Servidor Configurações de DHCP Cliente Servidor Configurações de Proxy Servidor Squid SquidGuard DansGuardian

10

11 Estrutura Física e Configuração de Hardware dos Laboratórios do BCC Introdução Apesar da grande importância das configurações de software que um servidor desempenha para as atividades de uma instituição que possui uma máquina que atua como servidor para os clientes, a disposição física de todos os dispositivos necessários para o funcionamento de uma rede de computadores, no qual atuará este servidor, terá uma grande importância também, pois poderá influenciar diretamente no desempenho desta rede. Assim, visando explicitar a estrutura física de todos os dispositivos da rede interna dos laboratórios vinculados ao BCC, facilitando o entendimento desta estrutura de rede, um esquema visual foi desenvolvido, indicando todas as configurações presentes atualmente nesta rede interna. Para isto, foi utilizado o programa Microsoft Office Visio 2007, estando indicados os seguintes laboratórios: D303; D304; LInC; LP&D; Laboratório de Engenharia de Software e Computação Gráfica; Laboratório de Redes de Computadores. Outro ponto abordado será a configuração de hardware. A configuração das máquinas de cada laboratório também é importante para um administrador de redes, pois, a partir destas, pode vir a tomar certas decisões de configuração que otimize o desempenho da rede, melhorando o trabalho de todos os usuários. Desta forma, tais configurações também estão explicitadas neste capítulo. Todos os arquivos esquemáticos destes laboratórios estarão disponíveis para os futuros estagiários e administradores de redes para possíveis modificações, caso seja necessário. Em seguida, serão apresentadas as estruturas de cada laboratório citado. 11

12 D303 O laboratório D303 é o laboratório de uso geral para o curso de. Está localizado no 3º andar do prédio da reitoria, sendo este o andar que será de exclusividade do curso do BCC futuramente. Este laboratório está em uso para atividades individuais dos alunos e para aulas práticas das matérias do curso. A disposição física é descrita segundo a próxima figura: 12

13 D304 O laboratório D304 será um laboratório de uso geral para o curso de. Está localizado no 3º andar do prédio da reitoria. Este laboratório está em processo de configuração estrutural e futuramente será utilizado para atividades individuais dos alunos do BCC. A disposição física é descrita segundo a próxima figura: Lab D304 - Laboratório Específico da Computação Switch ethernet 1Gbps Servidor do BCC Configurações X Máquinas Pentium(R) Dual Core CPU 2.50Ghz HD - 300Gb Memoria Ram : 2.00 Gb Sistema Opracional - Windows 7 32 Bits Versao , Ubuntu 9.04 Tipo do sistema - X86-based pc Versao da Bios - American Megatrends Inc Placa de Rede - VIA Rhine II Fast Ethernet Adapter Endereços IP, via DHCP, na faixa x.x Acesso Restrito a alunos do curso de 13

14 LInC O LInC (Laboratório de Inteligência Computacional) é um laboratório de uso específico do curso de. Está localizado no 3º andar do prédio da reitoria, na sala D306. Este laboratório está em uso para atividades de pesquisa nas linhas de Inteligência Artificial e Pesquisa Operacional. O seu uso está restrito a alunos com iniciação científica nesta área. A disposição física é descrita segundo a próxima figura: Lab D306 - Laboratório Temático de Inteligência Computacional Ethernet 100MBps Configurações 8 máquinas Intel(R) Core(TM) 2 Quad Cpu 2.83Ghz 8Gb de RAM Hd - 465GB Máquinas Ubuntu 9.10 Video - Intel(R) G45/ G43 Express Chipset Versao da Bios - Intel Corp. GTG4310H.86A Placa de Rede - Intel(R) 82567V-2 Gigabit Network Connection Roteador Wireless D-Link DIR-655 Xtreme N Gigabit Endereços IP, via DHCP, na faixa x.x Switch ethernet 1Gbps, localizando no LINC Servidor do BCC Acesso Restrito a alunos envolvidos em projetos de Pesquisa 14

15 LP&D O LP&D (Laboratório de Pesquisa e Desenvolvimento) é um laboratório de uso específico do curso de. Está localizado no 2º andar do futuro prédio do CPD (prédio K), na sala K205. Este laboratório está em uso para atividades de desenvolvimento de aplicações nas linhas de Inteligência Artificial e Pesquisa Operacional, alcançando, futuramente, o status de encubador de projetos da Unifal-MG nesta área. O seu uso está restrito a alunos com iniciação científica nesta linha de pesquisa. A disposição física é descrita segundo a próxima figura: Lab K205 - Laboratório Temático de Pesquisa e Desenvolvimento Cabeamento para o switch ethernet 1Gbps, localizando no prédio V Prédio V Ethernet 100MBps Configurações 8 máquinas Intel(R) Core(TM) 2 Quad Cpu 2.83Ghz 8Gb de RAM Hd - 465GB Máquinas Ubuntu 9.10 Video - Intel(R) G45/ G43 Express Chipset Versao da Bios - Intel Corp. GTG4310H.86A Placa de Rede - Intel(R) 82567V-2 Gigabit Network Connection Roteador Wireless D-Link DIR-655 Xtreme N Gigabit Endereços IP, via DHCP, na faixa x.x Acesso Restrito a alunos envolvidos em projetos de Pesquisa Cabeamento de fibra óptica para o Servidor do BCC Prédio D 15

16 Laboratório de Engenharia de Software e Computação Gráfica O Laboratório de Engenharia de Software e Computação Gráfica é um laboratório de uso específico do curso de. Está localizado no 3º andar do prédio da reitoria, na sala D305. Este laboratório está em uso para atividades de pesquisa nas linhas de Engenharia de Software e Computação Gráfica. O seu uso está restrito a alunos com iniciação científica nesta linha de pesquisa. A disposição física é descrita segundo a próxima figura: Lab D305 - Laboratório Temático de Engenharia de Software e Computação Gráfica Ethernet 100MBps Configurações Computação Gráfica 7 máquinas Intel(R) Core(TM) 2 Quad Cpu 2.83Ghz 8Gb de RAM HD - 500GB Sistema Operacional - Ubuntu 9.04 Video - nvidia Corporation GT200b [GeForce GTX 285] Placa de Rede - Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller Engenharia de Software 5 máquinas Intel(R) Core(TM) 2 Quad Cpu 2.83Ghz 8Gb de ram Video - Intel(R) G45/ G43 Express Chipset Versao da Bios - Intel Corp. GTG4310H.86A Placa de Rede - Intel(R) 82567V-2 Gigabit Network Connection Hd - 465GB Endereços IP, via DHCP, na faixa x.x Acesso Restrito a alunos envolvidos em projetos de Pesquisa Cabeamento para o switch ethernet 1Gbps, localizando no LINC Servidor do BCC Switch do LInC 16

17 Laboratório de Redes de Computadores O Laboratório de Redes de Computadores será um laboratório de uso específico do curso de. Está localizado no 3º andar do prédio da reitoria, na sala D309. Este laboratório será utilizado para atividades de pesquisa na linha de Redes de Computadores, Programação Paralela e Sistemas Distribuídos. O seu uso será restrito a alunos com iniciação científica nesta linha de pesquisa. A disposição física é descrita segundo a próxima figura: 17

18

19 Configurações de Hardware e dos Serviços oferecidos pelos servidores do BCC Introdução Para suprir as necessidades do curso do BCC, foram necessárias duas máquinas distintas para atuarem como máquinas servidoras. Elas possuem configurações específicas, pois cada uma estará encarregada a fazer um tipo de serviço pré-determinado dentro da rede interna criada para o BCC. Como de praxe, as máquinas servidoras do BCC receberam nomes em homenagem a pessoas importantes na história da computação, sendo elas: Turing; Gödel; As informações listadas nesta seção correspondem a um resumo das principais características de hardware do ponto de vista do administrador do sistema. Estas informações são úteis caso o administrador necessite reinstalar o sistema operacional no servidor e algum dispositivo não seja reconhecido. Esses dados, em sua maioria, foram adquiridos através do software Everest disponibilizado em Outra característica importante serão os serviços que serão disponibilizados por cada uma destas máquinas. Como contamos com 2 máquinas distintas para a tarefa de servidores, a configuração dos serviços de cada uma destas será específico para um melhor desempenho da rede. Outro ponto importante desta separação é que, tendo o conhecimento do que cada máquina servidora irá oferecer, o administrador da rede terá uma gerência mais facilitada durante o seu trabalho. A seguir, a composição de hardware e os serviços disponibilizados por cada uma destas são elencados. Turing Configuração de Hardware Placa-Mãe IBM 4367 Chipset Intel Bigby

20 Processador: QuadCore Intel Xeon X3320, 2500 MHz (7.5 x 333) Memória RAM 8GB (DDR2-667 ECC DDR2 SDRAM) 4 Pentes de 2GB Placa de vídeo ATI ES1000 (16 MB) com acelerador 3D ATI ES1000 (RN50) Disco Rígido LSILOGIC Logical Volume SCSI Disk Device (278 GB) Placas de Rede Broadcom NetXtreme Gigabit Ethernet Realtek RTL8169/8110 Family PCI Gigabit Ethernet NIC (NDIS 6.0) Sistema Operacional Devido à estabilidade, optamos por utilizar a distribuição Debian Lenny 5.4 netinst para a plataforma AMD/64bits. O tipo de instalação netinst foi usado por questões de segurança e customização já que nesta forma de instalação, temos a opção de instalarmos somente um subconjunto básico de serviços. Decidimos, inclusive, não instalar o servidor X (Ambiente desktop). Serviços oferecidos Em seguida, serão mostrados os serviços oferecidos pela máquina Turing, com uma breve introdução do que corresponde este serviço. Todas as configurações adotadas para cada serviço serão detalhadas em capítulos posteriores, dispensando explicações nesta seção. Assim, entre os serviços disponibilizados por este servidor, teremos: Servidor de Quotas O servidor de quotas atua como um sistema que controla a quantidade de espaço no seu HD que será permitida para cada cliente armazenar seus dados dentro de uma rede. Servidor DHCP 20

21 O DHCP, Dynamic Host Configuration Protocol, é um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host e outros parâmetros de configuração para clientes de rede. Servidor Proxy Proxy é um servidor que atende a requisições repassando os dados do cliente a frente. Um usuário (cliente) conecta-se a um servidor Proxy, requisitando algum serviço, como um arquivo, conexão, website, ou outro recurso disponível em outro servidor. Servidor DNS O DNS (Domain Name System - Sistema de Nomes de Domínios) é um sistema de gerenciamento de nomes hierárquico e distribuído operando para resolver nomes de domínios em endereços de rede (IPs). Servidor de Arquivos Um servidor de arquivos é um computador conectado a uma rede que tem o objetivo principal de proporcionar um local para o armazenamento compartilhado de arquivos, que podem ser acessados de qualquer máquina dentro de uma rede de computadores. Gödel Configuração de Hardware Sistema Operacional Serviços oferecidos Entre os serviços disponibilizados por este servidor, teremos: Servidor Web Servidor... 21

22 Comentário final Diante de todas as características apresentadas, serão abordados nos próximos capítulos todos os processos realizados para a configuração atual dos servidores do BCC, desde a instalação do SO até os serviços disponibilizados por ambos os servidores, assim como toda a configuração adotada e os problemas encontrados e possíveis soluções destes empecilhos. 22

23 Instalação do Debian Netinst Introdução Uma das principais características almejadas para um servidor está relacionado a sua segurança. Utilizar-se de softwares que forneçam esta segurança torna-se, assim, uma característica indispensável para um servidor estável. Visando esta característica, os sistemas GNU/Linux trazem um excelente retrospecto, relacionado tanto à segurança, quanto também ao desempenho. Cientes disto, vários administradores de rede optam por utilizar de sistemas operacionais GNU/Linux para trabalharem como servidores da rede de computadores. Seguindo este mesmo raciocínio, este manual fornecerá os passos necessários para instalação e configurações das duas máquinas disponíveis para atuarem como servidores do BCC-Unifal- MG. Por razões de estabilidade, optamos por usar a distribuição Debian 5.04, Lenny. Por segurança, optamos por uma instalação mínima, sem ambiente gráfico e minimalista que será customizada com os serviços indispensáveis discutidos neste documento. Debian NetInst O Debian é uma distribuição do Sistema Operacional GNU/Linux, livre e de código aberto, podendo ser utilizado em praticamente qualquer computador. Devido ao seu bom histórico de estabilidade e segurança, acabou ganhando bastantes usuários, tanto especialmente em servidores de redes. Atualmente, sua versão estável é a 5.0 1, construída sobre o kernel (VERIFICAR A VERSAO DO KERNEL)(uname a),. Esta é a versão utilizada na demonstração dos passos necessários para a instalação no decorrer deste documento. Devido a essa grande aceitação, a distribuição Debian conta hoje com mais de pacotes contendo softwares pré-compilados que podem ser instalados. Esse é um número bastante grande e que certamente ocupará vários CDs/DVDs de instalação. Contudo, para intuito de instalação em servidores, uma mera imagem de cd com menos de 200MB é suficiente. Esta distribuição mínima é conhecida como Debian NetInst. Com o Debian NetInst (netinst significa instalação via rede ), o usuário terá apenas os pacotes necessários para o funcionamento do sistema. Se desejarmos ter as funcionalidades de servidores de arquivos, de interface gráfica, etc. iremos instalar manualmente estes pacotes/serviços. A distribuição NetInst do Debian é bastante interessante para administradores de redes e usuários avançados, pois não inchará o sistema com pacotes que nunca serão utilizados, além do aumento de segurança no sistema, pois podem existir pacotes instalados que acabam abrindo brechas e comprometendo a segurança do sistema. 1 Versão estável em abril de

24 Instalando o Debian NetInst Obtendo a imagem Universidade Federal de Alfenas O primeiro passo para esta tarefa é obter o CD de instalação do Debian netinst. Isso pode ser feito com através do link escolhendo a imagem para a arquitetura do processador que estamos utilizando. Em nosso caso, iremos utilizar um processador (repassar para o Tiago as configuração do Worstation IBM), sendo uma arquitetura baseada em 64 bits. Neste caso, foi feito o download a partir do link amd64, que apesar do nome, é a versão compatível para este tipo de processador. Para uma arquitetura de 32 bits, a escolha seria a partir do link i386. Iniciando a instalação Após este primeiro passo, ao dar o boot pelo CD de instalação, teremos a seguinte tela: Como nossa missão é instalar um sistema da forma mais enxuta possível, podemos selecionar a opção Install, para uma instalação em modo texto. Assim, já podemos ir nos familiarizando com nosso novo mundo de trabalho do nosso sistema operacional. Configurações iniciais Iniciando a instalação, devemos selecionar o idioma a ser utilizado no processo de instalação, sendo este o idioma nativo para o sistema após a instalação. No nosso caso, podemos selecionar a opção Português do Brasil. 24

25 Para o teclado, selecionamos a opção referente ao padrão brasileiro com layout ABNT2 (caso o seu teclado tenha a tecla cedilha). Vale a pena ressaltar que, a maioria das decisões tomadas dentro do processo de instalação podem ser redefinidas quando o sistema operacional estiver em execução. Configurações iniciais da rede A partir deste momento, o processo de instalação começa a fazer as configurações necessárias para o início do processo de particionamento e instalação. Uma das configurações é a da rede via DHCP (IP dinâmico). Como a máquina de instalação está conectada em uma rede local, o endereço IP foi obtido automaticamente via o servidor DHCP da rede. 25

26 Host O passo agora é configurar o nome do nosso host, ou seja, o nome que nossa máquina vai ser identificada na rede. Domínio (MUDAR FIGURA PARA FICAR COM O NOME turing Como o processo de instalação ocorreu dentro da LAN do BCC ( X) que possui um servidor com DNS configurado (máquina GODEL, endereço IP), podemos neste momento definir o nome completo de nossa máquina, incluindo o sufixo de domínio (bcc.unifalmg.edu.br). Em seguida, escolhemos o domínio no qual a rede vai estar vinculada. Vamos utilizar o domínio do BCC, como o nome de bcc.unifal.com.br. Atualmente, o servidor DNS, configurado através do pacote bind, está localizado na máquina GODEL, juntamente com o Servidor Web Apache e com o SGBD MySQL. 26

27 Horário A configuração de horário é feita neste momento. Se a rede foi descoberta, a configuração do relógio será feita automaticamente (como foi neste caso). Caso contrário, devemos informar o horário em relação ao GMT. Em seguida, informamos qual o fuso-horário o sistema estará vinculado, o que fará o ajuste correto do horário. Para a nossa região, o fuso-horário utilizado será o de São Paulo. Particionamento (SERÁ QUE NÃO COMPENSA PARTICIONAR COM VOLUMES LÓGICOS - LVM??? Será que compensa deixar um espaço livre em disco para particionamentos futuros? Quando formos fazer a instalação definitiva, deveremos tirar screeshots e atualizar este documento) Finalmente, entramos no processo de particionamento do disco. Particionaremos o disco de forma a acomodar apenas o sistema operacional escolhido, o Debian. Uma característica importante para servidores, e que será adotada nesta formatação, é o uso de LVM. A sigla LVM significa: Logical Volume Manager. Ele é um gerenciador de discos que trabalha com comadas lógicas, que podem ser redimensionadas, aumentando ou diminuindo sem prejudicar o funcionamento do sistema. A necessidade de se usar LVM é para que possamos aproveitar ao máximo o tamanho do HD ou de vários HDs. Para trabalhar com LVM as partições precisam estar formatadas com o tipo LVM. O LVM trabalha com grupos de volumes para alocar as partições que estão definidas como volumes físicos do LVM. Esses volumes físicos serão divididos em vários volumes lógicos como se fossem uma divisão de um disco (partição) para alocar o determinado ponto de montagem, e isso vai trazer a flexibilidade para redimensionar a determinada partição. Um sistema com LVM tem seu desempenho um pouco reduzido quanto ao acesso a disco, devido as camadas adicionais de acesso aos dados. Entretanto, o desempenho de leitura e gravação de blocos é melhorado consideravelmente após a adoção do LVM. O LVM também garante que o sistema não mostre sintomas de paradas durante o esvaziamento de cache de disco, mantendo sempre certa constância na transferência de dados mesmo em operações pesadas de I/O no disco. No momento da utilização do disco como LVM, serão mostrados os passos de configuração. 27

28 Mostrar esta configuração feita em um site pro Rodrigo... este é um exemplo no youtube de como foi formatado o sistema com raid1 e lvm... Tipo de particionamento realizado Para melhor customização das partições, selecionamos na figura abaixo a opção Manual. Após a seleção do tipo de particionamento como manual, devemos selecionar o HD disponível que será utilizado na instalação. Neste caso, o HD mestre da IDE1 (SUBSTITUIR DEPOIS PELOS HD SCSI DA WORKSTATION IBM) será utilizado: 28

29 (ESTAS, COMO AS OUTRAS FIGURAS, SERÃO ATUALIZADAS POSTERIORMENTE) Tabela de partições Neste passo, temos a oportunidade de criar uma nova tabela de partições vazia no disco. Como o nosso disco está sendo particionado pela primeira vez, devemos aceitar a opção de criação de uma nova tabela de partições: Agora, efetivamente temos uma partição no HD selecionado para criarmos nossas futuras partições. Note que se houvessem partições no HD que acabamos de criar a nova tabela de partições, estas seriam apagadas e seria criada uma tabela com a única partição que acabou de ser criada. Começando a criar as partições Agora que criamos uma tabela de partições vazia, podemos criar nossas partições propriamente ditas. Devemos, agora, selecionar o espaço livre alocado após o passo anterior. É neste espaço que vamos criar todas as nossas partições. 29

30 Ao selecionar o espaço livre, somos questionados em como utilizá-lo. Selecione Criar uma nova partição. Com isso, devemos estabelecer o tamanho da partição que desejamos criar. Esta etapa é importante. Então, antes disso, vale a pena planejar o número de partições a serem criadas, o tamanho e tipo de cada uma, antes de continuarmos o processo de criação de partições. (Atualizar a seção abaixo para os valores de HD da máquina que substituirá a Turing, primeiramente) Planejamento dos Tipos e tamanho das Partições utilizadas Vamos supor para o nosso HD de 8GB. Estas proporções deverão ser estendidas para capacidades diferentes de HD. O sistema de arquivo utilizado em todas (exceto a swap) será ext3. A primeira partição, a /, é a principal partição do sistema onde serão instalados os arquivos do sistema. Em servidores, esta partição não tende a crescer muito, necessitando de cerca de 20% do espaço total. Aqui, uma quantidade de 2GB é suficiente. Deve ser uma partição primária, pois será bootável. As demais não necessitam desta característica. A segunda é a /home, que contém arquivos dos usuários. Geralmente possui a maior quantidade, especialmente no nosso caso onde existe a política de permitir um espaço livre de 200 MB para cada aluno e professor do BCC, controlado por um sistema de cotas cuja configuração será explicada no decorrer deste manual. Pode-se estabelecer cerca de 40-50% 30

31 do espaço total. No nosso caso, utilizaremos somente 2GB, para espaço para as outras partições. (Atualizar) A terceira é a /var, que irá armazenar arquivos de log, páginas de internet, arquivos de e banco de dados do MySQL. A ocupação desta tende a crescer com o tempo em servidores web, e deverá deixar um espaço maior para esta partição. Cerca de 30-40% é uma quantidade interessante. Novamente, no nosso caso utilizaremos apenas 2GB. (Este parágrafo será atualizado depois pois estou verificando se há vantagem em se ter HD ou máquina específcia para log com todos os serviços redirecionando seus logs para esta outra máquina ou HD SYSLOG e Logrotate) Por fim, a partição swap, que será utilizada como área de troca no caso de preenchimento da memória RAM. A quantidade de swap depende da utilização deste sistema, e da quantidade de memória RAM disponível para este. Logo, estes valores podem variar entre 2-8GB para servidores que atendem a uma quantidade razoável de requisições, como no nosso caso. Nesta configuração utilizaremos apenas 1GB (Atualizar). Partição / Desse modo, nosso sistema de partição ficou da seguinte forma (para 8GB): / 2GB /home 3GB /var 2GB swap 1GB Tendo feito o planejamento, podemos agora proceder com o particionamento. Primeiro selecionamos o tamanho da partição: Que será do tamanho que definimos, sendo primária: 31

32 Devemos colocá-la no início do espaço disponível também, para que a pasta /boot fique no início do HD, de forma a não prejudicar a inicialização: Como esta é uma partição de boot, devemos alterar a flag de iniciação para ligado : O sistema de arquivos não será alterado, sendo o ext3 definido por default. Podemos agora gravar estes dados configurados, na opção Finalizar a configuração da partição : A partição / foi criada: 32

33 Partição /home Selecionemos o espaço livre: Próximos passos (passo já indicados): Criar uma nova partição; Definir o tamanho da partição (3GB); Tipo de Partição (lógica já que não daremos boot por esta partição -/home): Espaço a ser criada: início do espaço disponível. Nesse momento, o assistente no traz as configurações já definidas para o /home 33

34 Podemos Finalizar a configuração da partição. Partição /var/ Próximos passos (passo já indicados): Selecionar o espaço livre; Criar uma nova partição; Definir o tamanho da partição (2GB); Tipo de Partição (lógica); Espaço a ser criado: início do espaço disponível. Agora precisamos mudar o ponto de montagem para /var, na linha indicada abaixo: Marcando: 34

35 Podemos Finalizar a configuração da partição. Partição swap Próximos passos (passo já indicados): Selecionar o espaço livre; Criar uma nova partição; Definir o tamanho da partição (Espaço restante); Tipo de Partição (lógica); Devemos agora criar a swap, alterando o seu sistema de arquivos: Selecionamos a opção que mostra caracteriza a swap, a área de troca (swap) : 35

36 Podemos Finalizar a configuração da partição. Gravando as partições criadas O processo, visto até agora, gera todas as partições na tabela de partições, mas nenhuma formatação para criação do sistema de arquivos foi efetivada. Devemos, então, finalizar o processo de particionamento para que as partições criadas sejam formatadas e os sistemas de arquivos criados em todas as partições. Devemos fazer o seguinte: Nesta opção, teremos a seguinte mensagem: 36

37 Neste momento, podemos encerrar o processo de particionamento, fazendo a formatação das partições. Observe que após esta confirmação, caso existam dados no HD, eles serão perdidos!!!. Como esta é uma instalação em um HD vazio, podemos prosseguir com a formatação. Assim, o processo de formatação é feito. Neste momento, começa a instalação do sistema. Instalação do Debian Com todos os passos anteriores feitos, os arquivos da distribuição Debian começam a ser instalados no HD, sendo um processo bem rápido, já que o Debian netinst tem um volume reduzido de arquivos: Configuração de usuários e senhas Esta nesta parte da configuração que serão estabelecidos os possíveis usuários do sistema. No Debian, será necessário, ao menos um administrador, conhecido como root, e um usuário comum, que será criado para utilizar-se dos recursos do sistema, possuindo assim, um acesso mais restritivo a certos recursos. Assim, o primeiro passo é definir a senha de root, redigitando para sua confirmação: 37

38 Em seguida, passamos para a configuração dos usuários do sistema. São necessários os seguintes dados: Nome completo: Nome de usuário para a conta: Senha (digitação e redigitação): 38

39 Conforme discutido na seção Script para automação das tarefas Servidor Turing Antigo, em vez de criar todos os usuários manualmente, iremos usar uma política para reaproveitamento dos usuários cadastrados no servidor atual, em execução. Localização do repositório Os repositórios são endereços de Internet onde o Sistema poderá buscar por atualizações de pacotes instalados, novos pacotes e patches de segurança. O ideal é buscar sempre endereços mais próximos de nossa localidade, para uma maior velocidade de download, apesar disso não ser necessariamente uma regra pois a velocidade de download depende de outros fatores, além da distância geográfica. Em seguida, escolhemos um repositório. Neste caso, podemos utilizar um espelho padrão, geralmente o primeiro da lista. Caso desejarmos alterar tais repositórios, basta fazer as alterações no arquivo /etc/apt/sources.list. Isso será mostrado em outro momento. 39

40 Se no momento de instalação estivermos com nossa máquina conectada à rede local da Unifal, já será possível fazer o download de atualizações de pacotes e patches de segurança. Para isso, já que o acesso à Internet na rede do BCC é feita via Proxy, basta inserir estas informações na figura abaixo (Isso poderá ser feito após a instalação se preferirmos). Quando formos falar sobre o gerenciamento de pacotes no Debian, discutiremos como configurar o acesso aos repositórios via Proxy. De qualquer forma, se preferir, já pode inserir o endereço do servidor Proxy: onde é o endereço do servidor Proxy e 3128 a porta usada para comunicação com este serviço. Esta indicação de Proxy não será fornecida neste momento, sendo mostrada a sua forma de configuração na seção APT via Proxy. Logo em seguida, o APT será configurado: Problema no espelho de rede Se algum problema de configuração de espelho ocorrer, não se preocupe, pois iremos solucioná-lo posteriormente. A mensagem abaixo nos foi mostrada pois não configuramos o servidor de Proxy duas telas atrás. 40

41 Como o servidor Proxy não foi indicado anteriormente, não será possível utilizar qualquer espelho de rede, restando apenas deixar esta configuração para mais tarde: Continuando a instalação Durante o processo de instalação, os espelhos de rede contendo atualizações de pacotes de segurança são consultados. Como anteriormente não configuramos o endereço Proxy (algumas telas atrás), estamos sem acesso à Internet e, por isso, a mensagem de alerta abaixo. Isto poderá ser solucionado posteriormente, ao configurarmos corretamente o gerenciador de pacotes para funcionar com o servidor Proxy. Seleção do software A partir de agora, o instalador vai nos indicar quais partes do sistema desejamos que sejam instaladas. 41

42 Como este é o Debian netinst, nos será fornecido apenas a opção de sistema básico, pois esta versão só contém o software necessário para o funcionamento do sistema, como já foi comentado. Algum outro software para as nossas necessidades deverá ser baixado para que seja instalado em nosso sistema. Contudo, isto não será um problema, pois tudo pode ser feito facilmente através do APT. Em seguida, são instalados todos os componentes básicos para o funcionamento do sistema: Carregador de inicializações - GRUB O assistente continua com a instalação do software básico, até que chega à configuração do carregador de iniciação do Debian, ou seja, o GRUB. Este é carregador padrão do Debian. Neste instante, o assistente verifica a presença de outros sistemas operacionais no disco. No nosso caso, devido a máquina ser configurada somente para o Debian, devemos selecionar a opção de instalação do GRUB na MBR (Mater Boot Record), que é um setor específico do HD que cujo conteúdo é executado logo após o término de verificação de hardware e teste de memória feita pelo firmware(bios). 42

43 Fim do processo de instalação Universidade Federal de Alfenas Por fim, depois de todo este longo processo, finalmente temos agora o Debian instalado em nossa máquina, disponível apenas da configuração necessária para seu funcionamento. Neste momento, devemos retirar o CD de instalação e reiniciar a máquina, para que a instalação possa vigorar: Verificando a instalação Reiniciando o computador, o GRUB torna-se nosso gerenciador de boot, nos dando a opção de iniciar como usuário normal ou como mono-usuário (utilizado em casos de manutenção devido à algum problema detectado). Para utilização do sistema, utilizaremos o modo normal: Em seguida, temos todos os recursos necessários para manipulação de nosso sistema, podendo interagir com o sistema através de uma simpática interface em modo texto, conhecida como Shell ou terminal. No caso do Debian, o shell default é o BASH (Born Again Shell) 43

44 A partir deste momento, podemos logar no sistema com uma das contas criadas no processo de instalação passar a utilizar o sistema. Nos próximos capítulos deste manual, descreveremos como configurar os serviços essenciais à rede do BCC além de fazermos uma sintonia fina em nossa instalação fornecendo um ambiente mais seguro e conveniente para o administrador de redes. 44

45 Gerenciamento de Pacotes no Debian Lenny Introdução O objetivo da instalação do Debian netinst é de se ter um sistema enxuto, com o mínimo de pacotes possíveis para que o sistema funcione com o maior nível de segurança possível. Porém, devido a este mínimo de software no sistema, para que o Debian seja útil para nosso servidor, será necessária a instalação de vários pacotes que supram nossas necessidades. Logo, teremos que fazer o download dos mesmos de algum lugar (repositórios na terminologia adotada por sistemas baseados no Debian). A primeira alternativa é baixar todos os pacotes existentes do repositório do Debian, presentes no site oficial ( gravá-los em CDs (que por sinal serão vários, mais de 20 na versão atual!) e fazer a instalação a partir destes. Tudo funciona muito bem assim. Contudo, uma maneira mais prática para este processo será a instalação a partir de um aplicativo do Debian que faz instalação via rede, chamado APT (existe uma alternativa ao APT chamada aptitude que discutiremos em momento oportuno). Este comando será bastante útil para fazermos o download do pacote(s), instalar e atualizar nosso sistema. O utilitário APT O APT é um gerenciador de pacotes, nativo do Debian, que tem a finalidade de fazer instalação, atualização e remoção de pacotes do sistema. O grande benefício em relação ao DPKG (outro gerenciador de pacotes do Debian) é a instalação de pacotes através da rede; ou seja, não precisamos baixar o pacote que desejamos instalar de um site que o contenha (como no DPKG) para depois instalarmos no sistema. Basta apenas sabermos o nome do pacote desejado, termos uma lista de pacotes atualizada em nosso sistema, e acesso à Internet disponível para download e instalação dos pacotes. Outro benefício do APT é que não precisamos no preocupar com quaisquer dependências que um pacote tenha, pois o APT resolve isto automaticamente, através da geração de árvores de dependência. Para que o APT consiga encontrar o pacote que desejamos e possa instalá-lo em nosso sistema, ele faz o uso de um arquivo, o chamado sources.list, localizado em /etc/apt/. Sources.list Este arquivo é a base do funcionamento do APT. Ele contém endereços de Internet no qual o APT deverá buscar para fazer o download de um pacote que desejamos. Tais endereços são chamados de repositórios. 45

46 Como já dito, este arquivo é muito importante para que o APT possa ter um funcionamento correto. Logo, sua correta configuração torna-se algo essencial de ser feito. Configurando o arquivo /etc/apt/sources.list Após a instalação, o conteúdo do arquivo sources.list deverá ser similar ao apresentado abaixo: # # deb cdrom: [Debian GNU/Linux _Lenny_ - Official i386 NETINST Binary :06]/ lenny main deb cdrom: [Debian GNU/Linux _Lenny_ - Official i386 NETINST Binary :06]/ lenny main # Line commented out by installer because it failed to verify: # deb lenny/updates main # Line commented out by installer because it failed to verify: # deb-src lenny/updates main Observe as linhas comentadas (as que iniciam com #) dos repositórios de segurança do Debian. Isso aconteceu pois no momento de instalação, estávamos sem acesso à Internet por não termos configurado o acesso via servidor Proxy (vide capítulo sobre instalação do Debian). Como visto, apenas o repositório do APT referente a instalação a partir do CD (linha 3) está descomentada. Isso aconteceu porque durante a instalação o assistente não conseguiu se conectar nos repositórios das linhas 5 e 7, fazendo com que estas fossem comentadas. Para resolvermos este problema, vamos descomentar as linhas contendo os repositórios de segurança e configurar o gerenciador de pacotes para usar um servidor Proxy para acesso à web (todo acesso à web no bcc é feito via Proxy) # # deb cdrom: [Debian GNU/Linux _Lenny_ - Official i386 NETINST Binary :06]/ lenny main deb cdrom: [Debian GNU/Linux _Lenny_ - Official i386 NETINST Binary :06]/ lenny main # Repositorios padrao de seguranca deb lenny/updates main contrib non-free deb-src lenny/updates main contrib nonfree # Repositorios padrao de pacotes deb lenny main contrib non-free deb-src lenny main contrib non-free Com isso, teremos tanto a opção por repositório que utiliza o CD como fonte, quanto os repositórios padrão de pacotes do sistema e de segurança, sendo estes os repositórios padrão mais utilizados para atualização de nosso sistema. 46

47 APT via Proxy Como a rede interna do BCC possui um servidor Proxy com autenticação que controla todo o acesso à Internet, não será possível fazer qualquer atualização no Debian, caso alguma configuração adicional não seja feita. Esta configuração se trata de indicar para o APT que existe um servidor Proxy com esta característica, devendo indicar o usuário e senha válidos para autenticação neste servidor Proxy, para que seja possível o acesso à Internet. Para resolver este empecilho, o comando export será utilizado, no qual irá configurar a variável de ambiente de Proxy, com o Proxy da rede. Isto é feito da seguinte forma: $ export http_proxy= Este comando deverá sempre ser feito caso a máquina for reiniciada. Para evitar este processo, este comando poderia ser colocado dentro do arquivo ~/.bashrc ou /etc/profile (para todos os usuários), pois seria executado à cada boot. 47

48

49 Problemas encontrados após a instalação do Sistema Introdução Nem tudo são as flores para um administrador de redes. Alguns problemas possivelmente serão um empecilho para o responsável pela rede, mas nada que tire o seu sono por mais de uma semana :D. Este capítulo irá abordar alguns erros que surgiram após a instalação do Debian NetInst, indicando as soluções que foram tomadas para sanar estes problemas. Imagina-se que este capítulo seja de grande utilidade para futuros administradores, sendo fundamental a documentação de quaisquer problemas que venham a ocorrer. Mudança de eth0 para eth1 e vice-versa a cada reboot Ao utilizar o Debian Lenny, é importante fixar as interfaces de redes após configuração. Isso acontece, pois no lenny as interfaces mudam de posição a cada reset em servidores com mais de uma placa de rede. A placa eth0 passa então a ser eth1 e vice-versa. Isso acaba sendo um complicador para administradores de rede que configuram serviços para placas específicas e que não devem ser alteradas de eth0 para eth1. O problema pode ser solucionado através do ifrename. Para instalá-lo usamos o aptitude: # aptitude install ifrename Após instalado o ifrename e configuradas as placas de rede, verifique os endereços Mac de cada uma pelo comando: # ifconfig a Crie o arquivo /etc/iftab com o seguinte conteúdo: eth0 mac enderecomac eth1 mac enderecomac Uma vez criado, o arquivo é criado a cada boot e a configuração se torna persistente. Observação: no micro do lab de redes a placa de rede eth0 é a Intel com Mac 00:1c:c0:f2:1a:fc A placa de rede realtek, não funcionou após a instalação. Ela vai ser a eth1 com Mac 00:23:cd:b1:66:5f 49

50 Placa de rede reconhecida, mas não operante Após instalação, apenas a placa de rede onboard Broadcom Nextreme BCM5722 Gigabit Ethernet PCI Express foi identificada e funcionou corretamente. A placa de rede Realtek RTL 8169 Gigabit Ethernet (ver 10) aparece na listagem do comando lspci (não achei esse utilitário no debian netinst nem nos repositórios), mas não funciona. Para resolver este problema, seguir os passos abaixo: Ir no site da Realtek e fazer o download do driver. &Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#5,7,8,10,982 As instruções para compilar o driver estão no arquivo read-me.txt, mas antes, precisamos preparar o ambiente, conforme descrito em aptitude install make apitude install linux-headers-$(uname r) Agora, podemos executar os passos presentes no readme: Verifique se o driver default está instalado. o # lsmod grep r8169 o O comando lsmod exibe o status de módulos no kernel do linux Se estiver instalado, remova-o o rmmod r8169 Descompacte o driver o $ tar xvfj r tar.bz2 Entre no diretório descompactado o # cd r # make clean modules o Capturar a saída deste comando para informações gerais. Não deu erro e parece que o nome do driver é r8169.ko em /lib/modules/ amd64/kernel/drivers/net/ # make install o Capturar a saída deste comando para informações gerais. 50

51 # depmod a o O comando depmod gera um lista de dependências adequada para o utilitário modprobe # modprobe r8169 o modprobe é um programa para adicionar ou remover módulos do kernel do linux O driver neste momento foi carregado. Isso pode ser verificado com o # lsmod grep r8169 o # ifconfig a o Se houver um nome de dispositivo, ethx (eth1 no nosso caso), o driver Linux foi carregado. Podemos usar então o seguinte comando para ativá-lo Suponhamos que o nome do dispositivo seja eth1. Nesse caso, podemos ativá-lo com o # ifconfig eth1 up Mesmo após todos os passos acima, a interface não funciona. Ainda precisamos instalar um pacote para auxiliar na configuração final: # aptitude install ethtool Após instalado, devemos modificar o arquivo /etc/network/interfaces e inserir a linha pre-up /usr/sbin/ethtool -s eth1 autoneg off na configuração da placa desejada (eth1 no nosso caso) iface eth1 inet static pre-up /usr/sbin/ethtool -s eth1 autoneg off address (verificar qual será o endereço) netmask (demais configurações) FUNCIONOU! APENAS INVESTIGAR A MENSAGEM DE ERRO NO BOOT SOBRE O IFRENAME PARA ETH0 (Também fazer experimentos para ver se está funcionado a 1000 Mb) 51

52

53 Migração de informações para os novos servidores Introdução No momento de configurar este servidor, já existia um servidor operante, embora com um hardware limitado. Dessa forma, inicialmente, optou-se por clonar os serviços existentes no servidor limitado, fazendo uma sintonia fina em configurações que julgamos necessárias. Assim sendo, as informações listadas neste documento, quando necessárias, serão exibidas na forma como elas estão configuradas no servidor atual e, logo em seqüência, numa listagem de como ela foi implementada no Workstation IBM. Assim, este roteiro foi criado para tornar mais fácil a migração dos servidores GNU/Linux do BCC para novos servidores. Tal migração se torna necessária quando, por exemplo, desejarmos substituir os computadores destinados aos servidores por outros com um hardware melhor. A migração também se torna importante quando, simplesmente, desejamos ter um backup de servidores, colocando a rede novamente em atividade mesmo em caso de problemas sérios de hardware nos servidores em funcionamento. Política de backup dos usuários, grupos e pasta /home Seria tedioso se toda vez que formatássemos o servidor ou simplesmente mudássemos a máquina como está previsto neste documento (o atual servidor Turing está sendo atualizado, momentaneamente por uma máquina melhor, emprestada do laboratório de redes pelo professor Flávio), tivéssemos que cadastrar todos os usuários do sistema novamente. Para evitar isso, decidimos criar um roteiro para migração de contas e dados dos usuários do servidor antigo para o novo. Para exemplificar, suponha que o endereço IP do servidor novo sendo configurado é o Dessa forma, podemos usar o comando SCP, parte integrante da suíte SSH para a cópia dos arquivos remotos presentes na máquina turing. Teoricamente, seria necessário copiar os arquivos /etc/shadow, /etc/passwd e /etc/group, além do backup da pasta /home, que contém os dados dos usuários cadastrados no servidor. Infelizmente, algumas considerações adicionais devem ser levadas em consideração além da simples cópia dos arquivos. Um pequeno problema surgiu na cópia da conta de root. Uma primeira consideração a ser observada é que os servidores antigos usam Ubuntu e, devido à estabilidade e segurança, optamos por migrar os serviços destes servidores para servidores novos com o Debian 5.04 Netinst Lenny. O Ubuntu, diferentemente do Debian, desabilita a conta de root por padrão. Dessa forma ao se copiar o /etc/passwd, /etc/shadow e /etc/group da máquina Turing antiga para a nova com o Debian, conseguimos logar com todos os usuários, menos com o root já que durante o processo de cópia, é copiado um arquivo com o usuário root desativado. Isso faz com se torne impossível logar como root na máquina nova. 53

54 Para resolver esse problema, decidimos temporariamente habilitar a conta de root na máquina turing antiga, fazer o procedimento de cópia dos arquivos /etc/passwd, etc., conforme descrito anteriormente para a máquina Turing nova e depois desativar novamente a conta de root no ubuntu. Assim, conseguimos fazer o procedimento normalmente e, mais importante, logar como root no debian. Usando o mesmo raciocínio, decidimos fazer um backup da pasta /home para que os dados de todos os usuários sejam mantidos no novo servidor. Script para automação das tarefas Servidor Turing Antigo De forma a tornar mais fácil ainda a vida do administrador, criou-se um Shell script para automatizar os passos necessários backup dos arquivos essenciais presentes na máquina Turing antiga. Abaixo o conteúdo completo do arquivo scriptbackupcontasusuarios. Após a listagem é feita uma explicação do funcionamento do mesmo. Lembre-se que este script deverá ser executada na máquina turing antiga. #! /bin/bash mkdir /root/backup/ cd /root/backup/ export UGIDLIMIT=1000 awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/backup/passwd.backup awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/backup/group.backup awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/passwd tee - egrep -f - /etc/shadow > /root/backup/shadow.backupmig cp /etc/gshadow /root/backup/gshadow.backup Segue o roteiro: Habilitando temporariamente a conta de root no ubuntu (máquina Turing) $ sudo passwd root Se aparecer um erro informando que a conta do usuário root expirou, restaure-a antes com o comando: $ sudo passwd u root Para melhor entendimento das tarefas do script, uma breve descrição referente aos diretórios e arquivos essenciais para o gerenciamento de usuários e grupos e, conseqüentemente para a migração, é exibida abaixo: Arquivo /etc/passwd Contém informações para cada conta do usuário Arquivo /etc/shadow contém a senha criptografada para as contas dos usuários e informações opcionais de expiração de senhas 54

55 Arquivo /etc/group define os grupos os quais os usuários pertencem Arquivo /etc/gshadow arquivo shadow dos grupos (senhas criptografadas para os grupos) Diretório /home/ Todos os dados dos usuários estão armazenados sob este diretório Precisamos fazer o backup de todos estes arquivos e diretórios presentes no servidor antigo para serem restaurados no novo servidor. Faremos isso em três passos: primeiramente, criaremos um diretório no servidor antigo para armazenamos o backup dos arquivos de configuração essenciais e para os dados dos usuários. Em seguida, criaremos uma cópia dos arquivos de configuração. Finalmente, faremos o backup da pasta /home, usando o comando tar. Esses passos estão presentes no conteúdo do script descrito anteriormente e estão detalhados em sequência. Primeiro passo Criar um diretório para armazenar o backup mkdir /root/backup/ Após criado, vamos entrar no diretório: cd /root/backup/ Segundo passo Criar uma cópia dos arquivos de configuração Para esse passo, necessitaremos de uma série de comandos. Inicialmente, vamos configurar um filtro para os identificadores de usuário (UID), para que façamos o backup apenas de usuários normais e não usuários de sistemas. No caso do Ubuntu e do Debian, as contas de usuários normais iniciam a partir do UID export UGIDLIMIT=1000 Copiaremos agora as contas presentes em /etc/passwd para /root/backup/passwd.backup usando o utilitário awk para filtrar as contas do sistema (copiar apenas contas de usuários). Se você preferir, pode seguir este roteiro passo a passo executando os comandos descritos. Dessa forma, não é necessária a execução do script, apesar do script facilitar as coisas. Se optar por digitar os comandos uma a um, lembre-se que quando o comando não couber em uma linha do shell, poderemos usar uma barra no final da linha ( / ) e continuar o comando na linha seguinte. Outra alternativa é colocar o comando dentro de um arquivo texto e atribuir permissão de execução para ele (por exemplo, chmod 700 arquivocomcomandolongo) e executá-lo (lembre-se apenas de executar os comandos como usuário root). (CONFIRMAR POIS ACHO QUE ROOT É ID 0. Se isso for verdade, o comando abaixo deverá funcionar mesmo se não habilitarmos a conta de root no ubuntu. Mesmo assim talvez 55

56 compense usar isso pois tive problemas no momento de copiar via scp, tendo que dar um chown pagliares.pagliares) awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/backup/passwd.backup O utilitário awk facilita a criação de filtros para serem usados no momento de parsing do arquivo. No exemplo acima, criamos um arquivo /root/backup/passwd.backup, contendo apenas usuários com UIDs entre 1000 e (limite do Debian), descartando o usuário root (UID 0) e usuários do sistema (UIDs entre 1 e 999). Podemos agora fazer a cópia do arquivo /etc/group, com o mesmo raciocínio desenvolvido anteriormente. awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/backup/group.backup No comando acima, a variável UGIDLIMIT é passada para o comando awk usando a opção -v (ela atribui o valor da variável do Shell UGIDLIMIT para o programa a variável chamada LIMIT). A opção F configura o separador de campos como sendo : (dois pontos). Finalmente o comando awk lê cada linha do arquivo /etc/passwd, filtra as contas do sistema e gera um novo arquivo /root/backup/passwd.backup. Faremos o mesmo para o arquivo /etc/shadow: awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/passwd tee - egrep -f - /etc/shadow > /root/backup/shadow.backup EXPLICAR MELHOR AS OPÇÕES ACIMA! O arquivo /etc/gshadow, raramente usado, poderá ser copiado: cp /etc/gshadow /root/backup/gshadow.backup Terceiro passo Fazendo o backup do diretório /home cd /root/backup/ tar -zcvpf home.tar.gz /home PAREI AQUI! (o script não está independente de diretório) 56

57 Automação das tarefas Servidor Turing Novo Tendo feito o backup dos arquivos importantes e dados dos usuários no servidor antigo, podemos começar a migração para o servidor novo, também chamado Turing. Para essa cópia, usaremos o scp conforme comandos abaixo listados: # mkdir /root/migração && cd /root/migração # scp -r pagliares@ :/root/backup/ /root/migração é o endereço do servidor antigo. novo: Por questão de segurança, vamos fazer um backup dos usuários atuais do servidor # mkdir /root/backupservidornovo # cp -a /etc/passwd /etc/shadow /etc/group /etc/gshadow /root/ backupservidornovo A opção a mantém os privilégios de acesso presentes nos arquivos de origem. Vamos agora restaurar os arquivos do servidor antigo para o diretório /etc/ # cd /root/migração/backup # cat passwd.backup >> /etc/passwd # cat group.backup >> /etc/group # cat shadow.backup >> /etc/shadow # cp gshadow.backup /etc/gshadow Note que estamos usando o operador para inserção no final do arquivo >> (append) e não > (criar) redirecionamento do shell. Vamos agora extrair o arquivo home.tar.gz para a pasta home do novo servidor # cd / # tar xvf /root/migracao/home.tar.gz Vamos agora reiniciar o sistema. Após isso, o procedimento estará finalizado e poderemos logar normalmente com qualquer usuário cadastrado no sistema antigo, incluindo o usuário root que somente está habilitado no servidor debian novo. # reboot Para finalizar, vamos desativar novamente a conta de root no ubuntu: $ sudo passwd -l root 57

58 58

59 Configuração do SSH para acesso remoto Introdução Uma das vantagens de utilizar um SO Linux em relação a outros, apontada por muitos administradores, é a facilidade e segurança obtida para controlar o sistema remotamente. E para isso, de uma forma ou de outra, mesmo sem a explícita percepção, teremos o auxílio de um aplicativo chamado SSH. O SSH é um aplicativo multi-uso, que possui uma enorme variedade de utilizações envolvendo comunicação remota com segurança. Entre suas funcionalidades, ele nos permite acessar máquinas remotas de forma que consigamos até executar aplicativos gráficos e transferir arquivos de um servidor. O SSH é um sistema cliente-servidor. Inicialmente neste manual, iremos habilitar o servidor SSH para que consigamos acessar remotamente a máquina servidora. Em momento oportuno discutiremos sobre clientes SSH tanto em modo texto quanto em modo gráfico para que consigamos gerenciar nossos servidores remotamente usando tanto clientes SSH para Windows quanto para GNU/Linux. Instalando o SSH no Debian Para o funcionamento do SSH, precisamos de 2 configurações específicas: a configuração do SERVIDOR e a do CLIENTE. Do mesmo modo que um servidor trabalha, a configuração do servidor do SSH irá disponibilizar os arquivos da máquina servidora, para aqueles que requisitam estes recursos, ou seja, os clientes. No Debian, por padrão em qualquer CD de instalação, o SSH cliente já vem como pacote base e será instalado juntamente com os outros componentes do sistema. Com isso, o módulo do SSH do cliente, chamado de ssh, já deverá estar em funcionamento no momento que estivermos utilizando o sistema. Para confirmar, podemos usar o seguinte comando: # which ssh Caso a tela de saída seja parecida com a abaixo, estamos com o cliente ssh instalado. Caso não esteja, podemos obtê-lo pelo APT. Uma boa prática é primeiramente pesquisar pelo pacote: # apt-cache search ssh 59

60 Dentre os pacotes listados, selecionamos o desejado para instalação, que no nosso caso é o openssh-client: # apt-get install openssh-client Se você achar que a pesquisa pelo pacote ssh retornou muitos pacotes tornando a decisão difícil, vale a pena tentar o aptitude: # aptitude search ssh O aptitude é compatível com o apt-get, funcionando de forma similar com o benefício de ser melhor padronizado e de permitir uma interação com o usuário via uma interface de comandos e menus em modo texto. Discutiremos melhor o aptitude posteriormente. (mudar este parágrafo para a seção de instalação do ssh Server) Mas por quê? O ssh é parte do cliente e não do servidor!! Caso o módulo do cliente do SSH não esteja funcionando, podemos ativá-lo pelo comando: # /etc/init.d/ssh start O que nos falta, agora, é instalar o servidor na máquina que desejamos fornecer o acesso remoto. Podemos nos perguntar por que o servidor do SSH não vem por padrão como pacote base do CD de instalação do Debian, já que ele é tão útil. E a resposta é muito fácil! Nem toda máquina necessita ter um servidor SSH. Somente naquelas máquinas que serão servidoras é que precisamos instalar tal serviço. Como a meta é deixar o sistema o mais enxuto possível, somente habilitaremos o servidor ssh para as máquinas que atuarão como servidores de redes do bcc. Contudo, isto é muito fácil, sendo tudo feito pelo APT. Basta digitar: # apt-get install openssh-server sshd. Isto irá instalar o servidor SSH na máquina, sendo o módulo do servidor chamado de 60

61 Lembre-se que se você não souber o nome do pacote, basta usar o apt-cache search partenomepacote ou aptitude search partenomepacote. Uma observação importante para administradores de rede é sobre a porta utilizada pelo serviço de SSH. Por padrão, será utilizada a porta 22 do servidor. Porém, outra porta poderá ser utilizada sem nenhum problema, mas deverá ser liberada no firewall do servidor. Discutiremos melhor a mudança de porta do SSH no capítulo sobre segurança, presente neste manual. Uma maneira de se confirmar que o serviço está rodando é utilizando um dos dois comandos abaixo: # ps aux grep ssh ou # netstat ant grep sendo este se o SSH tiver configurado para ouvir na porta 22. Configuração dos arquivos de configuração Como clientes e servidores possuem total independência em sistemas Linux, a configuração dos arquivos do SSH também terão uma configuração específica, cada um. Ambos os arquivos de configuração são bastante extensos e, com isso, serão mostradas apenas as modificações feitas no arquivo padrão que é gerado durante a instalação. Uma listagem completa dos arquivos de configuração do SSH bem com o de outros serviços utilizados na administração de redes pode ser encontrada nos anexos deste manual. Configuração do cliente Durante a ativação, o padrão para o servidor SSH é permitir acesso usando qualquer uma das contas de usuários do sistema, fazendo apenas a requisição da respectiva senha. Contudo, se alguma vez você for tentar e esta operação não for permitida, significa que você foi bloqueado pelo administrador daquele servidor. Este tipo de configuração será visto no arquivo de configuração do servidor SSH. Como dito, todas as configurações apresentadas aqui serão feitas no arquivo /etc/ssh/ssh_config. Uma observação importante é que quase todas as configurações feitas neste arquivo podem ser feitas durante a conexão com o servidor. Logo, se percebermos que 61

62 alguma configuração está faltando, basta descobrirmos a opção correta para ativá-la durante a conexão. Compressão dos dados transmitidos Podemos aliviar um pouco do consumo da banda da rede aplicando a compressão de dados através do gzip. Para isso, basta ativar a compressão no arquivo do cliente, da seguinte forma: Compression = yes Manutenção da conexão por um maior intervalo de tempo O SSH, assim como um site que requer autenticação (por exemplo, um site de serviço de online), padroniza certo tempo para fechamento de conexão, caso a mesma esteja ociosa. Isso acaba gerando uma maior segurança para o usuário, porém muitas vezes é algo incômodo para o mesmo, por ter que sempre estar digitando novamente seu login e senha. Diante disso, podemos configurar um procedimento neste arquivo de configuração, de modo sempre estar enviando pacotes de dados, para que a conexão não se encerre. Isso é feito através do seguinte procedimento: ServerAliveInterval 120 Isso faz com que, a cada intervalo de 120 segundos, o cliente mande um pacote de dados para o servidor, de modo a manter a conexão entre ambos. Porta Como já comentado, a porta padrão do servidor é a 22, para comunicação entre clientes e servidores, através do SSH. Contudo, se o administrador do servidor estabelecer outra porta para comunicação, esta deverá ser alterada no cliente antes da tentativa de conexão. Podemos alterá-la no cliente da seguinte forma: Port 9999 Para o servidor do BCC, a porta 22 será a padrão. (Vamos discutir isto melhor) Configuração do servidor Para servidores ssh, o arquivo de configuração é o /etc/ssh/sshd_config. Como não é o servidor quem requisita conexão, neste caso as opções descritas aqui não serão possíveis durante a conexão do cliente. Controle de acesso Permite limitar o SSH a uma única interface de rede. Isto é útil para servidores com mais de uma placa de rede. Por exemplo, podemos fazer com que o SSH fique disponível apenas em uma rede local, mas não na Internet. 62

63 Exemplificando, para um controle do SSH apenas para uma rede local. Suponha que o servidor use o endereço na rede local. Faríamos da seguinte maneira: ListenAddress Para o servidor do BCC, esta configuração não será feita, pois a intenção será disponibilizar as máquinas através da Internet. Protocolo Especifica o tipo de protocolo que será utilizado durante a comunicação entre servidor e cliente de uma conexão via SSH. Atualmente, o SSH está na versão 2, que é mais seguro que sua antiga versão, o protocolo 1. Para permitir apenas a conexão com o uso deste protocolo, será configurado o arquivo da seguinte forma: Protocol 2 Usuários e senhas Esta opção é interessante no caso do usuário administrador do sistema. Existe uma opção deste arquivo que indica se o usuário root pode fazer o login via SSH diretamente, sem se autenticar como usuário comum antes disso. Isso deve ser pensado com cuidado, pois permitir isso acaba diminuindo um pouco a segurança do sistema. Por exemplo, se o login direto como root, via SSH, não fosse permitido, um usuário que quisesse invadir o sistema deveria ter que quebrar duas senhas antes disso, a do usuário normal e a de root. Observando isso, é mais precavido não deixar essa configuração habilitada. Para isso, fazemos da seguinte forma: (Acho que podemos adotar isso após configurado o servidor) PermitRootLogin no Outra forma de incrementar a segurança é elencar os usuários permitidos para conexão via SSH. Isso pode ser feito da forma: (Acho que podemos adotar isso após configurado o servidor) AllowUsers fulano ciclano Se esta lista for muito grande, em vez de permitir, podemos negar acesso a certos usuários. Isto é feito da forma: DenyUsers beltrano mariano 63

64 Outra questão relacionada a segurança é a questão de senhas vazias. Isso nunca é bom para uma rede. Podemos negar usuários que tenhas esta característica da forma: (Acho que podemos adotar isso após configurado o servidor) PermitEmptyPassswords no Esta última é importante, pois a única forma existente de burlar o SSH é através da descoberta da senha do usuário. Assim, excluindo usuários que não têm preocupação alguma em proteger a própria conta é algo importante para manter a consistência do sistema. Arquivo /etc/hosts Toda conexão que precisamos fazer em um servidor, pelo modo visto até agora, necessita que seja informado o endereço IP do servidor para efetivar esta conexão. Isto porque o endereço IP é uma identificação única, e será a forma com que encontraremos o computador correto dentro de uma rede. Todavia, isso nem sempre é agradável dentro de uma rede local, assim como nem mesmo em algum endereço de um site (por exemplo, alguém sabe um IP do site do Google?). Por isso deixamos de chamar a máquina pelo IP, mas por um nome ou domínio. Logo, existe uma forma de configurarmos nomes para máquinas, de modo que quando formos acessá-la remotamente, não a chamaremos pelo IP, mas pelo seu próprio nome. Isto é possível através do arquivo /etc/hosts. (Vamos verificar a relação deste arquivo com o BIND) Para um entendimento rápido, este arquivo funciona como uma base para domínios. Assim, quando precisarmos fazer um acesso remoto, o sistema varrerá este arquivo procurando pelo domínio passado como parâmetro. Se este existir, ele será substituído pelo seu respectivo endereço IP. Ou seja, a responsabilidade em se passar o endereço IP correto não será mais responsabilidade do usuário, mas do próprio sistema, que o faz automaticamente. Para esta configuração, o procedimento é simples: basta indicar o endereço IP seguido do domínio deste. Um exemplo de arquivo seria: localhost maquinatiago maquinarodrigo turing É importante lembrar sempre que a configuração deste arquivo /etc/hosts vale apenas para a sua própria máquina, funcionando apenas como um arquivo de aliases. Caso o desejo seja que a configuração de apelidos seja válida para as demais máquinas da rede, dever-se-á configurar um servidor DNS, fugindo do escopo deste arquivo. Discutiremos a implementação do servidor DNS com Bind (Berkeley Internet Name Domain) no capítulo x. Acesso remoto através do SSH Após todas as configurações feitas anteriormente, o SSH está pronto para ser utilizado. Esta configuração é a mais básica para uma utilização do SSH de forma rápida e segura. Resta agora 64

65 mostrarmos a forma de se fazer o login no servidor, acessando um usuário cadastrado previamente. A sintaxe do SSH é fácil, pois leva em conta apenas o nome do usuário cadastrado no servidor, e o IP ou domínio do servidor. Temos as seguintes formas de acesso através do SSH: ssh tiago@ no qual tiago é o usuário que desejamos logar, e é o endereço IP do servidor. Poderíamos também acessar o servidor através de um domínio, ao invés do endereço IP, como comentado na seção anterior (Arquivo /etc/hosts), definindo um alias para este endereço através do arquivo /etc/hosts. Contudo, isso fica a critério do administrador de redes. Outra forma de acesso através do SSH é utilizando o comando: ssh l tiago Nesse caso, a opção l indica que o login será explicitado, seguido do IP ou domínio do servidor. Incrementando a segurança Mesmo que um administrador de redes faça cuidadosamente todos estes passos mostrados até aqui, nada o resguarda de ataques que buscam quebrar a senha de usuários do sistema. Entretanto, mesmo sendo a questão de senha (quando descoberta) o ponto fraco do SSH, existem utilitários que auxiliam nesta questão de segurança. Um exemplo é o fail2ban, um pequeno daemon que monitora os arquivos de log do servidor e bloqueia os endereços IP dos atacantes por regras de firewall. O fail2ban pode ser facilmente conseguido através do APT: (acho que compensa adotarmos este serviço, o que acha? SIM. Se adotarmos temos que falar isso explicitamente no documento)... Mas já estamos falando, não?.. até mostro como instala e configura... # apt-get install fail2ban Toda configuração deste aplicativo é feita no arquivo /etc/fail2ban/jail.conf, que indica os arquivos de log que serão monitorados, o número máximo de tentativas antes de aplicar o bloqueio etc. Por padrão, este arquivo está configurado para banir por 10 minutos aqueles endereços que tiveram 5 tentativas fracassadas. Outras fontes de monitoramento são os arquivos de log do Apache, servidores de e de FTP. Isso fará que, por exemplo, um ataque do tipo força-bruta torne-se definitivamente inviável. Diante de todas estas configurações padrão, podemos alterar tais configurações no arquivo /etc/fail2ban/jail.conf, de modo a fazer uma personalização que esteja de acordo 65

66 com as nossas necessidades. Por exemplo, o tempo de banimento pode ser alterado da seguinte forma: bantime = que é contado em segundos. Podemos especificar também o número de tentativas de autenticação para cada serviço do sistema. Isto pode ser feito criando uma seção separada no arquivo, da seguinte forma: [ssh] enable = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6 Por fim, podemos criar uma lista branca de usuários, ou seja, indicar endereços que nunca serão bloqueados, independente do número de tentativas feitas. Isto pode ser feito da forma: Ignoreip = No qual colocaríamos a sequência dos endereços livres de banimento um após o outro. Finalmente, caso fizermos qualquer alteração neste arquivo, para que as novas políticas entrem em vigor, será necessário reiniciar o serviço. Para isso, basta digitar o comando: # /etc/init.d/fail2ban restart Transferência de arquivos Outra grande funcionalidade do SSH, além das descritas e das inúmeras que não serão comentadas neste manual, está relacionada à transferência de arquivos entre servidor e cliente. Assim como toda a aplicação descrita até o momento, contamos com aplicativos em modo texto, que é de grande importância em servidores que não contam com interface gráfica; e os aplicativos em modo gráfico, que auxiliam bastante a vida de um usuário não tão experiente e familiarizado com as linhas de comando para este serviço. Apenas uma observação que deve ser levada em consideração é que, para qualquer protocolo mostrado a seguir que utilize o SSH como base, só será permitido a transferência de arquivos de tamanho máximo de 2GB. Isso acaba sendo uma limitação do SSH. Porém, o arquivo pode ser quebrado em blocos menores, sendo possível, então, sua transferência. Mostrando resumidamente, podemos quebrar arquivos com o comando split ($ split b 1000m arquivo.iso) e recombiná-los com o comando cat ($ cat xaa xab xac > arquivo.iso). O 66

67 importante neste caso é que, após estes passos, devemos verificar o arquivo para comprovar que este não foi corrompido. Isto pode ser feito com o uso do md5sum. Em seguida, serão apresentados os possíveis aplicativos que poderão ser utilizados para a transferência de arquivos, utilizando os aplicativos em modo texto e em modo gráfico, sendo este apenas para clientes Windows. Aplicativos em modo texto SFTP A forma mais básica para realizar a transferência de arquivos entre servidores e clientes é através do sftp. O sftp é um pequeno utilitário que faz parte do pacote padrão do SSH, oferecendo uma interface similar à dos antigos programas de FTP em modo texto. Para conexão com um servidor usando sftp, temos: $ sftp usuario@servidor Uma possível opção utilizada, caso o servidor esteja configurado para escutar uma porta diferente da 22 (padrão SSH), deve-se usar a opção -o port=, indicando a porta definida no servidor: $ sftp -o port=3333 tiago@bcc.unifal-mg.edu.br Isso nos levará ao prompt de comando do sftp, dando-nos a possibilidade de utilizar um de seus comandos (no servidor): put : faz upload de um arquivo; get: faz download de um arquivo para a pasta local; cd : para navegar entre pastas ou subir um diretório; ls: listar arquivos; pwd : verificar o diretório atual no servidor; Note que em todos estes comandos anteriores, estaremos alterando algo no servidor, tanto mudando de pastas, quanto fazendo download ou upload de arquivos. Mas se quisermos mudar, criar ou listar algo na máquina cliente, ou seja, aquela que requisita os serviços ao servidor? Isso é simples, sendo que para isso, temos comandos específicos. Por exemplo: lcd : comando cd no cliente; lls : comando ls no cliente; lmkdir : comando mkdir no cliente; lpwd : comando pwd no cliente; 67

68 Como visto, todos os comandos que serão feitos em arquivos e diretórios do cliente, devemos preceder o respectivo comando com um l, indicando que este deve ser feito localmente, ou seja, no cliente. SCP Como visto, a grande limitação do sftp (e possíveis interfaces gráficas que utilizam este utilitário) é que ele exige intervenção manual, e com isso, impossibilita o uso de scripts para transferências automatizadas. Assim, visando eliminar este empecilho, temos um utilitário chamado scp. O scp é um cliente ainda mais primitivo, que gera a possibilidade para especificarmos na sua linha de comando o login e o endereço do servidor, junto com o arquivo que será transferido. Logo, tem a seguinte sintaxe: $ scp arquivo_local login@servidor:pasta_remota O utilitário scp ainda permite algumas opções para a transferência de arquivos, que podem ser bastante úteis. A opção -p preserva as permissões de acesso e datas de criação e modificação do arquivo; a opção -r permite copiar pastas recursivamente; a opção -v indica o verbose, ou seja, mostra todos os passos realizados; e a opção -C ativa a compressão de dados. Um exemplo da utilização destas opções seria: $ scp -prvc /home/tiago/arquivo.txt tiago@bcc.unifalmg.edu.br:/var/www/download Outros comandos Além dos comandos comentados, existem outros com esta mesma funcionalidade, porém, assumindo suas próprias características. Entre eles podemos destacar o rsync, que permite sincronizar uma pasta local com uma pasta do servidor, tendo a característica de transferir apenas os trechos dos arquivos que formam modificados, tornando-o indicado para backup de pastas com grande volume de dados. Outro comando bastante utilizado é o rssh. Ele é bem interessante para aumentar a segurança no servidor. Isso porque ele permite que o usuário tenha acesso ao servidor apenas para transferência de arquivos via sftp ou scp, sem ter como executar comandos adicionais, ao contrário do sftp, que permite todas estas funcionalidades. Aplicativos em modo gráfico Evidentemente, como já salientado, existem meios mais práticos de transferir os arquivos, usando programas gráficos que trabalham com transferência de arquivos. Com isso, serão mostrados 3 aplicativos para isso, sendo 1 no próprio sistema Linux, e os outros 2 para clientes gráficos de plataforma Windows. 68

69 Nautilus Para o caso do Debian ou Ubuntu, que têm com padrão a interface do Gnome, o Nautilus é uma forma direta de transferência de arquivos sem nenhum pacote adicional, pois já vem embutido nesta interface do sistema. O Nautilus é a interface de visualização de arquivos e diretórios do Gnome, que além de ser gerenciador de arquivos, suporta o uso de diversos protocolos de transferência. Para utilizar o Nautilus no Ubuntu, por exemplo, fazemos os seguintes procedimentos: Em seguida, teremos várias opões de protocolos de transferência, no combobox de Tipo de Serviço. 69

70 Como estamos interessados em explorar o SSH, devemos marcar esta opção: 70

71 Em seguida, devemos informar o servidor, a porta do SSH (a padrão é a 22), a pasta que desejamos acessar e o nome do usuário no servidor. Se tudo estiver de acordo até o momento, isso vai criar um ícone de acesso, que aparece tanto no Desktop quanto na barra Locais do Nautilus. 71

72 Para efetivar o acesso, deverá ser fornecida a senha para que o acesso ao servidor seja estabelecido. Após estes passos, teremos o acesso pelo SSH ao servidor, usando para isso o protocolo sftp, como mostrado na figura abaixo: Putty Um dos exemplos de cliente simples e gratuito é o Putty. Sua grande vantagem é que ele não precisa ser instalado para se conectar a servidores Linux, bastando apenas baixá-lo e executálo. Por exemplo: 72

73 Para uma conexão SSH, com as configurações default do Putty, basta informarmos o endereço do servidor, a porta e então abrir a conexão (Open). Isso nos redirecionará para o servidor, que nos pedirá o nome de usuário e senha, similar ao SSH. Por exemplo: O Putty, além da sua característica de cliente SSH para Windows, inclui também um cliente SFTP, permitindo a transferência de arquivos usando os comandos de transferência já vistos anteriormente (put, get, cd, lcd, pwd, lpwd, etc.). Mas como usar tais comandos se eles são feitos para modo texto e o Putty é em modo gráfico? Bom, eis uma boa questão a respeito do Putty. O Putty é, em partes, em modo gráfico. Temos sim, boa parte deste, a possibilidade de configuração através de uma interface gráfica, como mostra o painel Category da tela principal do Putty, com configurações de Sessão, Terminal, Janela e Conexão. Após a conexão feita, toda a interação com o servidor será em modo texto. WinSCP Este será o último utilitário apresentado, que age como um cliente SSH para Windows. O WinSCP é um utilitário capaz de trabalhar com os protocolos sftp e ftp, como o Putty, além do protocolo ftp. O WinSCP tem suas semelhanças com o Putty, sendo até mais intuitivo e mais fácil manuseio, pois fornece toda a interação com o usuário através de interface gráfica (o que o diferencia do Putty). 73

74 Na sua tela principal, para uma conexão com o servidor, devemos informar o nome do servidor, o número da porta, o nome do usuário, senha e o tipo de protocolo utilizado (a chave privada somente se for necessária para a conexão). Com isso, o WinSCP irá fazer a conexão com o servidor, apresentando-nos a seguinte tela: Como visto, apesar da conexão com o protocolo SFTP, temos uma tela semelhante a um cliente FTP, que nos permite a transferência de arquivos apenas movendo os arquivos, da primeira tela (descrita como C:\Users\Tiago\Documents, representando o lado cliente da 74

75 conexão) para a segunda tela (descrita como /home/tiago, representando o lado servidor), ou vice-versa. Note a facilidade de transferência de arquivos com este utilitário. Finalizando o assunto de SSH Como visto, muitos aspectos do SSH foram abordados neste capítulo. Porém, apenas uma pequena parte de suas reais funcionalidades foram mostradas, pois esgotar este assunto seria algo bastante longo. Assim, para mais funcionalidades, principalmente para os clientes gráficos mostrados, outros tutoriais ou manuais específicos são recomendados, a fim de sempre estar facilitando a nobre e cansativa missão do administrador e estagiário de redes :D. Arquivos de configuração do SSH Os arquivos de configurações, tanto dos clientes quanto do servidor do BCC, podem ser encontrados no Anexo I, na seção Configurações de SSH. 75

76

77 Servidor de Quotas Introdução Através do serviço quota, é possível limitar a quantidade de espaço em disco disponível para cada usuário. Usamos este serviço no servidor antigo, permitindo que cada aluno possa usar no máximo 200MB de espaço em disco. Para tal, configuramos o quota para atuar sobre a partição /home já que é essa partição que os usuários possuem acesso para gravação de dados. Configurando as quotas Primeiramente, podemos verificar a presença/ausência do pacote quota com o comando dpkg l grep quota (dois ii antes do nome do pacote indica que está instalado). Para sabermos se o serviço está rodando, podemos usar ps aux grep quota. Outra alternativa é usar aptitude search quota (um indicador i na coluna anterior ao nome do pacote indica que o mesmo está instalado). Todas essas possibilidades foram executadas no servidor Turing antigo conforme figura abaixo. Caso ainda não esteja instalado, para que o quota funcione, é necessário instalar os pacotes quota e quotatool, que contém um conjunto de utilitários para verificar as quotas de disco. Para instalá-los, digite o comando: # apt-get install quota quotatool Em seguida é necessário carregar o módulo quota_v2 para ativar o suporte necessário no kernel e para que o mesmo seja carregado no momento de boot. Uma das formas de fazer isso, é incluir a linha quota_v2 no final do arquivo /etc/modules. 77

78 O quota é utilizado através do sistema de arquivos, para ativá-la temos que editar o arquivo /etc/fstab e adicionar as opções "usrquota" e "grpquota". No screenshot abaixo, adicionamos em /dev/sda5, que está sendo utilizado para o /home: Verificar o que é a opção relatime, presente no /etc/fstab Precisamos agora, criar dois arquivos de controle, o aquota.user e aquota.group, com permissão de leitura e escrita somente para o root, observando que os arquivos devem ser criados no ponto de montagem do sistema de arquivos, neste caso "/home". # cd /home # touch aquota.user aquota.group # chmod 600 aquota.user # chmod 600 aquota.group Devemos reiniciar o sistema para que a quota entre em vigor. Após reiniciado podemos verificar o status com: # repquota -av Colar figura Para definir uma cota para um usuário no sistema, devemos primeiramente definir o editor que será usado via linha de comando: # EDITOR=nano Para criar a quota para um usuário, use a opção -u : # edquota -u pagliares Basta agora inserir os valores sob as colunas soft e hard (terceira e quartas colunas). O valor soft é um limite de advertência, inferior ao valor hard. Sempre que ultrapassar este valor, o usuário receberá uma mensagem de alerta, mas o usuário ainda poderá gravar, até que atinja o limite estabelecido na coluna hard, quando a gravação dos novos arquivos é bloqueada. Podemos também especificar o Grace period, que é o tempo máximo que o usuário pode ficar acima do limit soft. No exemplo abaixo pagliares tem uma quota de 200Mb(hard) sendo gerado um alerta quando atingir 150MB(soft). Não definimos o grace period: 78

79 Figura A criação individual de cotas para todos os usuários (alunos, professores, etc..) demanda muito tempo. Uma alternativa é criar a cota por grupos. Por exemplo, todos os alunos cadastrados no sistema pertencem ao grupo aluno, o que pode ser verificado pelo comando no Turing antigo. # cat /etc/group grep aluno Assim sendo, podemos criar uma cota de 200MB para todos os alunos do grupo com o comando: # edquota g aluno Conforme figura acima, estamos adicionando uma cota de 200MB por aluno individual pertencente ao grupo aluno, com alerta após 150MB ser ocupado. Após criada a cota para o grupo, devemos reiniciar o serviço ou o servidor: # /etc/init.d/quota force-reload... ou # reboot Após reiniciado, podemos verificar a mudança nas cotas para todos os alunos cadastrados no grupo aluno: # quota g aluno... ou # repquota av 79

80 ... ou # repquota /home Colar figura Na saída da figura acima, a coluna Grace é o tempo limite da cota adicional. Se quisermos mudar este tempo podemos usar o comando edquota com o parâmetro -t 80

81 DHCP Universidade Federal de Alfenas Introdução Atualmente, quase todas as redes utilizam algum tipo de servidor DHCP. Em geral, eles são ativados automaticamente ao compartilhar a conexão ou junto com algum outro serviço, de modo que pouco se conhece sobre sua configuração. Para sanar este problema, serão abordadas neste capítulo as principais características do servidor DHCP, especificando as configurações que serão adotadas para o seu funcionamento no servidor do BCC da Unifal-MG. O que é o DHCP? O DHCP, Dynamic Host Configuration Protocol, é um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host e outros parâmetros de configuração para clientes de rede. Ou seja, é, resumidamente, o serviço que nos dá condições (de uma forma automática) para adquirir uma identificação na rede, sendo possível, se não houver algum empecilhos, ter o acesso à Internet. De um modo geral, o funcionamento de um servidor DHCP é bastante simples. Ele responde aos pacotes de broadcast das estações, enviando um pacote com um dos endereços IP disponíveis e os demais dados da rede. Os pacotes de broadcast são endereçados ao endereço e são retransmitidos pelo switch da rede para todas as portas. Uma funcionalidade inerente ao servidor DHCP é que este, periodicamente, verifica se as estações ainda estão lá, exigindo uma renovação do aluguel do endereço IP (lease time). Isso permite que os endereços IP sejam gastos apenas com quem realmente estiver online, o que evita o esgotamento de endereços IP disponíveis. DHCP em Linux O servidor DHCP mais usado no Linux é o ISC DHCP, sendo este pacote, para as distribuições derivadas do Debian, nomeado de dhcp3-server. No Debian NetInst, este pacote não vem com um pacote padrão e deverá ser instalado para oferecer este serviço. Isso pode ser feito pelo APT: # apt-get install dhcp3-server 81

82 Durante a instalação, a configuração do DHCP indica que a versão 3 deste pacote não vem configurada com servidor autoritário, ou seja, se um cliente requisita um endereço que o servidor desconhece e esteja errado, ele não acusará nenhum erro. Porém, isso poderá ser configurado para que não ocorra este problema, posteriormente no arquivo de configuração do DHCP. Com isso, será gerado o arquivo de configuração /etc/dhcp3/dhcpd.conf, que especificará todas as configurações básicas para o seu funcionamento. Configurando o dhcpd.conf Como dito, o arquivo dhcpd.conf, localizado em /etc/dhcp3/dhcpd.conf, contém todas as configurações necessárias para o funcionamento do servidor DHCP. A seguir, será mostrado o arquivo de configuração básico de um servidor DHCP: # /etc/dhcp3/dhcpd.conf ddns-update-style none; default-lease-time 600; max-lease-time 7200; authoritative; subnet netmask { range ; option routers ; option domain-name-servers , ; option broadcast-address ; } Para este arquivo, temos as seguintes especificações: A opção default-lease-time controla o tempo de renovação dos endereços IP, indicando o tempo em segundos. Esta opção é importante para redes que possuem um baixo número de IPs disponíveis, pois evita que estes se esgotem, mesmo que nem todos os endereços estejam efetivamente sendo usados. 82

83 A opção max-lease-time determina o tempo máximo que uma estação pode usar um determinado endereço IP. Esta opção também auxilia para que os endereços IP não se esgotem, a partir da rotação dos endereços IPs entre as máquinas. A opção range determina a faixa de endereços IP que será usada pelo servidor DHCP para atribuir aos clientes. Neste caso, podemos especificar uma faixa menor ou igual aos endereços possíveis na rede. Por exemplo, se temos disponíveis endereços de até , podemos reservar entre até a para IPs fixos, e o restante para ser atribuído pelo DHCP. A opção option routers especifica o gateway da rede, que é o endereço do servidor que está compartilhando a conexão. A opção option domain-name-servers contém o(s) servidor(es) DNS utilizado(s) pelas estações. Em caso de mais de um endereço, estes deverão ser separados por vírgula. Geralmente é configurado o próprio endereço DNS do provedor. Após qualquer modificação no arquivo de configuração do servidor, deveremos reiniciar o serviço DHCP, usando o comando: # /etc/init.d/dhcp3-server restart Cliente DHCP Com a configuração DHCP feita, podemos testar a configuração em algum cliente Linux, com o dhclient. Para alguma configuração específica no cliente, utilize a opção help, para ajuda. Basicamente, este comando nos mostra (entre outras informações): DHCPACK from bound to renewal in 3000 seconds. Estas informações nos mostram o endereço do servidor DHCP que o cliente irá solicitar o endereço e o endereço IP a ele fornecido dinamicamente, respectivamente. Uma observação é que ao configurar um servidor com duas placas de rede, devemos configurar o servidor DHCP para escutar apenas na placa da rede local. No Debian, devemos configurar o arquivo /etc/default/dhcp3-server, colocando a linha: INTERFACES= eth0 local).... para que o servidor DHCP possa escutar na placa local (eth0 é um exemplo de placa 83

84 DHCP com IP fixo Apesar do nome, o servidor DHCP pode determinar sempre um endereço IP fixo para os clientes que solicitam este serviço. Para isso, o servidor DHCP relaciona um determinado endereço IP com o endereço MAC do respectivo micro que solicita um IP. Isso faz com que ele sempre obtenha o mesmo endereço a partir do servidor DHCP, com se tivesse sido configurado para usar IP fixo. A vantagem desta configuração em relação à configuração manual de IP é que todo sistema irá continuar a receber o mesmo IP, mesmo que o sistema de um micro seja reinstalado (isso só não será possível se tal micro trocar também a sua placa de rede, pois isso irá alterar o seu endereço MAC). Configurando para IP fixo Para esta configuração, o arquivo que iremos alterar será o arquivo DHCP do servidor, ou seja, o /etc/dhcpd3/dhcpd.conf visto anteriormente. Antes disso, a configuração de cada host, que contará com esta característica de IP fixo, ficará da seguinte forma: host nomehost { hardware ethernet 00:0F:B0:55:EA:13; fixed-address ; } Com esta configuração feita no servidor, o host nomeado nomehost, identificado pelo endereço MAC de sua placa de rede, receberá o endereço IP que foi estabelecido. Esta configuração vai no arquivo dhcpd.conf, dentro da seção que contém as chaves que ditam configurações da rede. Por exemplo: # /etc/dhcp3/dhcpd.conf ddns-update-style none; default-lease-time 600; max-lease-time 7200; authoritative; subnet netmask { range ; option routers ; option domain-name-servers , ; option broadcast-address ; host Silveira { hardware ethernet 00:0F:B0:55:EA:13; fixed-address ; } } 84

85 Lembre-se que toda vez que este arquivo de configuração do servidor for atualizado, o serviço de DHCP deverá ser reinicializado IPV6 O IPV6 é a nova versão do protocolo IP, que utiliza endereços de 128 bits. Em relação ao IPV4 que atualmente é o mais utilizado, o IPV6 sofreu algumas mudanças e existem configurações diferentes para o funcionamento deste. Porém, como em toda a rede da Unifal-MG nenhuma alteração do IPV4 será feita até o momento, este assunto ficará para os próximos administradores e estagiários de redes, assim que o IPV6 tornar-se obrigatório em todas as dependências dos laboratórios. Arquivo de configuração do DHCP Os arquivos de configurações, tanto dos clientes quanto do servidor do BCC, podem ser encontrados no Anexo I, na seção Configurações de DHCP. 85

86

87 Servidor Proxy Universidade Federal de Alfenas Ilustração de uma arquitetura de rede que utiliza servidor Proxy. Introdução Proxy é um servidor que atende a requisições repassando os dados do cliente para frente. Um usuário (cliente) conecta-se a um servidor proxy, requisitando algum serviço, como um arquivo, conexão, website, ou outro recurso disponível em outro servidor. Usar um Proxy é diferente de simplesmente compartilhar a conexão diretamente, via NAT. Isso porque ao compartilhar via NAT, os micros da rede acessam a Internet diretamente, sem restrições. O servidor apenas repassa as requisições recebidas, como um garoto de recados. O Proxy é como um burocrata que não se limita a repassar as requisições: ele analisa todo o tráfego de dados, separando o que pode ou não pode passar e guardando informações para uso posterior. Para que o Proxy realmente funcione em uma rede, alguns aspectos adicionais são necessários. Tais aspectos se diferenciam dos passos necessários de, por exemplo, configurar o compartilhamento de uma conexão via NAT, pois ao usar o Proxy, além da configuração da rede, é necessário configurar o navegador e cada outro programa que for acessar a Internet (em cada um dos clientes da rede) para usar o Proxy (esta configuração será mostrada a seguir). Além disso, se for preciso reinstalar o sistema, será preciso fazer a configuração novamente :(. 87

88 Entretanto, o uso de um servidor Proxy trás vários benefícios a uma rede de acesso à Internet. Dentre eles, podemos destacar: Imposição de restrições de acesso com base no horário, login, endereço IP da máquina e outras informações, além de bloquear páginas com o conteúdo indesejado (com o uso do SquidGuard ou DansGuard, que serão vistos posteriormente); Funcionamento como um cache de páginas e arquivos, armazenando as informações já acessadas, e disponibilizando-as quando uma nova requisição a estes elementos é feita, desde que estes não tenham sofrido alterações. Isso acaba economizando banda, tornando o acesso mais rápido; Outra vantagem é que loga todos os acessos realizados através dele. Assim, todo o log gerado poderá ser visualizado a fim de verificar os acessos feitos através do Proxy pelos usuários (para a visualização destes logs, uma ferramenta poderá ser utilizada, com o Sarg, por exemplo, que também será vista posteriormente). Assim, o Proxy será um serviço bastante útil tanto para os administradores de rede quanto para todos os usuários que irão utilizar a rede dos laboratórios do BCC. Configurando o Proxy no Browser Existe uma configuração específica para cada navegador, pois estes disponibilizam suas configurações em seções específicas. Logo, serão mostradas as configurações para acesso à servidores Proxy em 3 navegadores: Firefox, IE e o Chrome. Firefox Utilizamos os seguintes passos: Editar > Preferências 88

89 Avançado > Rede > Configurar Conexão Finalmente, podemos informar o endereço do servidor Proxy, para que todos os acessos possam ser feitos através dele. 89

90 Note que devemos marcar a opção Configuração manual de Proxy, informando em seguida o endereço do Proxy para o protocolo HTTP e a porta. É importante marcar a opção Usar este Proxy para todos os protocolos, pois todos deverão passar também através deste Proxy. IE Com o OK, encerramos a configuração manual para o Firefox. Para o Internet Explorer, fazemos os seguintes procedimentos: Alt (se não estiver aparecendo a barra de ferramentas do IE) > Ferramentas > Opções da Internet Conexões > Configurações da LAN 90

91 No campo de Servidor Proxy, selecionamos a opção para usar o servidor Proxy na rede local, informando o seu endereço e porta utilizados. 91

92 Depois disso, devemos ainda escolher a opção Avançadas, para definir o Proxy para os outros protocolos. Chrome Confirmando todas as opções, teremos a configuração do Proxy feita. Neste navegador, devemos tomar os seguintes passos: Personalizar > Opções Configurações Avançadas > Alterar Configurações de Proxy 92

93 O restante pode ser feito de acordo com a seção de configuração do IE, em Configurações da LAN. 93

94 Tipos de Proxy Existem basicamente, de acordo com a questão de autenticação, 2 tipos de servidores Proxy. São eles, o Proxy transparente e o Proxy não-transparente. Proxy Transparente O proxy transparente é uma arquitetura que permite que o navegador cliente não saiba da existência do proxy. Ele acha que está solicitando o recurso diretamente ao servidor original; o proxy encarrega-se de capturar e processar a solicitação. A principal vantagem nesta arquitetura é que não é necessária a configuração de proxy nos navegadores cliente. Outra (incorretamente) alegada vantagem é que o proxy não transparente não impede a conexão direta à Internet. Assim, durante uma requisição de página de Internet, por exemplo, não será necessária qualquer autenticação para que seja feito o acesso às páginas ou arquivos armazenados através deste servidor. Por se portar com um tipo de servidor com menos empecilhos para os usuários realizarem suas tarefas, este tipo de Proxy será utilizado nos laboratórios temáticos do BCC, pois imagina-se que estes usuários estejam mais voltados especificamente para a área de sua pesquisa e, com isso, o rastreamento de seus atos poderá ser mais flexível. Proxy Não-Transparente Ao contrário do anterior, em um servidor Proxy não-transparente todo o acesso que terá intermédio deste servidor exigirá o reconhecimento de quem está requisitando algum serviço por este servidor. Assim, deverá ser feita uma autenticação de usuário (com senha), para que fiquem registrados todos os passos de sua utilização. Por agir de uma forma mais fácil para o controle dos atos dos usuários pelo administrador de rede, este tipo de Proxy será utilizado em todos os laboratórios de uso geral do BCC. Squid O Squid é um servidor proxy que suporta HTTP, HTTPS, FTP e outros. Ele reduz a utilização da conexão e melhora os tempos de resposta fazendo cache de requisições freqüentes de páginas web, como foi dito anteriormente. O Squid conta com várias configurações, que deverão ser feitas no arquivo de configuração daquela máquina que atuará como um servidor Proxy, sendo expostas a seguir. Instalação O Squid é composto de um único pacote, fazendo com que sua instalação seja bastante simples. Pelo APT, temos: # apt-get install squid 94

95 Arquivo /etc/squid/squid.conf Universidade Federal de Alfenas Toda a configuração do Squid é feita em um único arquivo, o /etc/squid/squid.conf. Uma característica deste arquivo é que contém todas as informações sobre sua configuração. Porém, isso torna este arquivo demasiadamente grande e inviável transcrevê-lo por completo aqui. Logo, explicitaremos as configurações mais utilizadas para este arquivo, assim como todas as configurações feitas para o Squid no servidor do BCC. Uma observação importante é que nas próximas seções iremos alterar as configurações deste arquivo. Então, uma boa alternativa será fazer um backup deste arquivo original, a fim de não perder estas informações que poderão ser mais bem compreendidas futuramente. Configuração básica Ao invés de utilizar todas as configurações do arquivo original, comecemos utilizando o arquivo squid.conf com esta configuração: http_port 3128 visible_hostname nome_servidor acl all src / http_access allow all Isso faz com que as demais opções omitidas assumam seus valores default. Para estas linhas de configuração, temos as seguintes explicações: http_port 3128 : indica a porta onde o Squid vai ficar disponível. A 3128 é a default do Squid, mas qualquer outra permitida pode ser utilizada; visible_hostname nome_servidor : mostra o nome do servidor, sendo o mesmo que foi definido na configuração da rede. Este nome pode ser obtido pelo comando hostname ; acl all src / e http_access allow all : criam uma acl (política de acesso) chamada all, incluindo os endereços IP possíveis. Testando uma configuração Como em qualquer outro serviço, qualquer configuração que seja feita em seus arquivos de configuração, o serviço deverá ser reiniciado. Para o Squid, temos: # /etc/init.d/squid restart Para testar o Proxy, devemos configurar um navegador para acessar o servidor que instalou este serviço. Devemos fazer semelhante a seções anteriores, para a utilização de Proxy pelo navegador. Se quisermos testar no próprio servidor que foi instalado o Squid (desde que este tenha uma interface gráfica e um navegador de Internet), podemos configurar para o acesso do Proxy através do endereço (ou localhost), pela porta

96 Outra forma de aplicar as mudanças feitas no arquivo de configuração do Squid é: # /etc/init.d/squid reload A opção reload é menos autoritária. Isso porque o restart força um reinício completo do Squid, onde o Proxy precisa finalizar todas as conexões abertas, finalizar todos os processos e desativar o cache, para só então ler a configuração e carregar todos os componentes novamente. Isso pode deixar o acesso dos clientes alguns segundos ou até minutos fora do ar. Assim, a opção reload permite que o Squid continue respondendo aos clientes e aplique a nova configuração apenas às novas requisições. Ele é suportado por diversos outros serviços onde o restart causa interrupção do serviço, como no caso do Apache. Abrindo a porta no firewall Por algum motivo, a porta que o servidor Squid utiliza pode estar fechada pelo firewall, o que torna impossível a comunicação com este. Com isso, caso necessário, abra a porta 3128 na configuração do firewall, para que o Squid possa receber as conexões. Um exemplo de regra manual do Iptables para abrir a porta do Squid apenas para a rede local (para a interface eth0) seria: Iptables -A INPUT -i eth0 -p tcp --dport j ACCEPT Iniciando as configurações avançadas Para as configurações apresentadas anteriormente, o servidor Squid funcionará normalmente, porém ficará aberto a qualquer um na Internet, tendo um acesso irrestrito a todas as páginas. E isso não é o desejado, devendo este ficar ativo apenas para a rede local. Assim, assumiremos uma configuração mais parruda, permitindo que apenas os micros da rede local possam usar o Proxy e definir mais algumas políticas de segurança. Este novo arquivo irá permitir o acesso a apenas alguma portas específicas e não mais a qualquer coisa: http_port 3128 visible_hostname debian acl all src / acl manager proto cache_object acl localhost src / acl SSL_ports port acl Safe_ports port 80 #http acl Safe_ports port 21 #ftp acl Safe_ports port # http, snews acl Safe_ports port 70 #gopher acl Safe_ports port 210 #wais acl Safe_ports port 280 #http-mgmt acl Safe_ports port 488 #gss-http acl Safe_ports port 591 #filemaker acl Safe_ports port 777 #multiling http 96

97 acl Safe_ports port 901 #swat acl Safe_ports port #portas altas acl purge method PURGE acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access allow purge localhost http_access deny purge http_access deny!safe_ports http_access deny CONNECT!SSL_ports acl redelocal src /24 http_access allow localhost http_access allow redelocal http_access deny all Este arquivo será a base das explicações a seguir. As acl s SSL_ports e a Safe_ports são as responsáveis por limitar as portas que podem ser usadas através do Proxy. Porém, todas foram explicitadas em linhas diferentes do arquivo, tornando-o mais extenso. O mesmo resultado pode ser obtido, colocando todas as portas da mesma acl na mesma linha, separando-as por um espaço, como em: acl Safe_ports port A acl localhost contém o endereço , que é utilizada ao fazer o uso do Proxy localmente (ao navegar usando o próprio servidor), e a acl redelocal inclui os demais micros da rede local. Note que a forma de indicar o endereço é IP/Máscara. A máscara pode ser apresentada da forma estendida (como em localhost, com ) ou da forma compacta (com em redelocal, com 24). Assim, poderíamos também ter representado as Máscaras com 32 e para localhost e redelocal, respectivamente. Com estas políticas de acesso feitas, devemos especificar, ao final do arquivo, que os micros que se enquadram nelas poderão usar o Proxy, com os comandos: http_access allow localhost http_access allow redelocal Ao final do arquivo, é feito algo diferente da primeira configuração. Ao invés de permitir qualquer usuário, todos aqueles que não se enquadram nas acl s anteriores serão excluídos, ou seja, não poderão utilizar o Proxy. Isto é feito em: http_access deny all Uma observação importantíssima deste arquivo de configuração do Squid é a respeito da ordem que são colocadas as permissões e negações de acesso. Sempre, o Squid interpreta as regras na ordem em que estão colocadas no arquivo. Assim, se colocarmos que o micro X 97

98 pode acessar o Proxy, mesmo que abaixo venha outra regra negando este acesso, este micro terá o acesso. Repasse direto Alguns sites podem não tem um bom funcionamento quando o acesso é feito através de um Proxy. Isso não está vinculado à problemas no Proxy, mas ao próprio sistema do site acessado, que possui algum recurso fora do padrão. Assim, podemos permitir que estes sites não passem por esse problema, orientando o servidor Proxy a repassar as requisições destinadas ao site diretamente. Podemos fazer esta configuração usando a opção always_direct, da seguinte forma: acl site dstdomain siteproblematico.com always_direct allow site Note que, se utilizada, esta regra deve vir antes da regra que libera os acessos provenientes da rede local. Cache de páginas e arquivos Um dos pontos mais importantes para um bom desempenho do servidor Proxy será aplicar uma configuração de modo a otimizar o tráfego da rede. E isto está diretamente ligado à configuração dos caches de páginas e arquivos. A função destes caches no Squid (assim como em outros servidores Proxy) será de armazenar as páginas e os arquivos já acessados, de forma a fornecê-los rapidamente quando solicitados novamente, pois não será necessário (caso não haja modificações nestes) obtê-los do seu domínio da Internet. O Squid trabalha com 2 tipos de cache: Cache de RAM, no qual é usada parte da memória RAM do servidor Proxy; Cache de HD, no qual é usado espaço no HD do Proxy. Estas caches podem ser facilmente diferenciadas: a primeira, por utilizar a RAM, possui a característica de ser mais rápida, porém ter um menor espaço de armazenamento. Com isso, será ideal para armazenar arquivos pequenos, como páginas HTML e imagens, que devem ser entregues instantaneamente aos clientes; a segunda, será mais lenta, porém com um espaço de armazenamento mais generoso, pois utilizará da memória física. Isto a idealiza como um cache para arquivos grandes, como download e possíveis atualizações. Em seguida serão mostradas algumas configurações que poderão ser aplicadas ao arquivo de configuração do Squid. Configurando o tamanho do cache da RAM Para a configuração do cache da RAM, utiliza-se a opção cache_mem, da seguinte forma: cache_mem 64 MB 98

99 Isso reservaria 64MB da RAM para o Squid. A regra básica para a quantidade de memória oferecida, neste caso, será de 32 ou 64 MB para servidores não-dedicados e até 1/3 da RAM no caso de um servidor Proxy dedicado. Ora, neste último caso, se a função do servidor será rodar apenas o Squid, por que não reservar toda a memória para ele? Isso tem uma explicação muito simples: além da RAM reservada ao cache em memória, o Squid precisa de RAM para diversas outras tarefas, sem contar com a quantidade de RAM necessária consumida pelo SO. Assim, se reservarmos muita memória para o cache, o sistema poderá ser obrigado a utilizar memória swap, o que acaba reduzindo o desempenho ao invés de aumentar. O cache da RAM do servidor do BCC está configurado em 128MB. Outra opção relacionada à cache da RAM é em relação ao tamanho máximo de um elemento nesta. Isto é possível através da opção maximum_object_size_in_memory. Devido ao tamanho mais limitado da RAM, sua configuração leva um valor menor, sendo que se tal elemento ultrapassar o valor definido, ele será armazenado no cache do disco (se também não for maior que este). Como exemplo, temos: maximum_object_size_in_memory 64 KB Isto indica um tamanho máximo de um elemento com 64KB na RAM. Para o servidor do BCC, este tamanho anterior foi utilizado. Configurando o tamanho do cache do HD Para a configuração do cache na HD, utilizam-se as opções maximum_object_size e minimum_object_size, da forma: maximum_object_size 512 MB minimum_object_size 0 KB Isso indica que serão permitidos downloads de até 512MB para ocuparem o HD para o Squid. Note que também indicamos o tamanho mínimo do objeto a ser armazenado, que, neste caso, terá o tamanho 0. Assim, até mesmo as figuras e páginas HTML poderão ser armazenadas neste cache. Note que, desta forma, após o primeiro acesso, todos os elementos de uma página serão buscados no HD, pois estarão armazenados lá, devido esta condição do tamanho mínimo do objeto. Desta forma, se o acesso ao disco for mais lento que baixar diretamente da Internet, o desempenho nos clientes será prejudicado. Neste caso, recomenda-se aumentar o tamanho mínimo do objeto, para que elementos pequenos sejam baixados diretamente através da Internet, pois não prejudicaria muito o consumo de banda por causa do tamanho destes. Por exemplo: minimum_object_size 2 KB 99

100 Isso eliminaria o problema levantado antes. Como dito anteriormente, este cache tem uma velocidade menor em relação ao cache da RAM, por ser feito em um dispositivo mais lento. Assim, é uma boa prática definir certa porcentagem de uso do cache que fará o Squid começar a descartar os arquivos mais antigos. Por padrão, sempre que o cache atingir 95% de uso, serão descartados arquivos antigos, até que a percentagem volte a um nível abaixo de 90%. Isto também pode ser explicitado com as opções cache_swap_low e cache_swap_high, da seguinte forma: cache_swap_low 90 cache_swap_high 95 No servidor do BCC, este é o porcentual utilizado. Outra configuração relacionada a este cache, é em relação ao local de armazenamento desses elementos. Isto é feito através da opção cache_dir ufs, que é composta por 4 valores. O primeiro indica a pasta onde o Squid armazena os arquivos do cache, como /var/spool/squid ; o segundo, indica a quantidade de espaço no HD (em MB) que será usada para o cache; e o terceiro e quarto parâmetros indicam o número de pastas e subpastas (dentro destas) que serão criadas dentro do diretório. Logo, sua configuração seria da forma: cache_dir ufs /var/spool/squid Esta é a configuração no servidor do BCC, também. O diretório utilizado aqui é o padrão utilizado pelo Squid. Podemos alterar para outro diretório de nossa preferência fazendo alguns procedimentos básicos. Primeiramente, o Squid não permite que utilizemos qualquer diretório para o armazenamento diretamente; ele exige que tal diretório seja de propriedade do usuário proxy" e do grupo proxy", além de uma formatação apropriada para o diretório do cache. Dessa forma, para estabelecer o cache em outro diretório, precisaríamos proceder com os seguintes passos: # /etc/init.d/squid stop # chown -R proxy.proxy /mnt/sda2/squid # squid -z # /etc/init.d/squid start Esses passos nos dizem o seguinte: se o Squid estiver em atividade, ele deverá ser encerrado para que possamos alterar o usuário e o grupo do diretório que queremos adotar como o novo cache do HD, que neste caso será o /mnt/sda2/squid. Feito isso, será feita a formatação apropriada, com o comando squid -z. Depois disso, o Squid poderá entrar em funcionamento novamente, com a configuração feita. Não se esqueça, para qualquer diretório que se deseja adicionar como cache do HD, este procedimento deverá ser feito! Por fim, uma última observação para este tipo de cache é que mesmo ao usar uma partição separada, não poderemos reservar mais do que 80% do espaço total da partição para ele, pois o Squid precisa de um pouco de espaço extra para manter um arquivo com o status 100

101 do cache e para operações de organização em geral, etc. Assim, se reservássemos todo o espaço disponível, em pouco tempo o Squid iria travar e parar de funcionar :( Outro ponto relacionado a isso é que o volume reservado para esta cache tem efeito direto sobre o volume de memória RAM consumido pelo Squid, pois este precisa manter carregadas informações sobre os arquivos armazenados no cache para localizá-los de forma eficiente. Logo, tem-se que para cada 1GB de espaço em disco reservado para o cache, o Squid consome cerca de 10MB a mais de memória RAM (20GB para cache => + 200MB consumo de RAM). Devido a isso, não é recomendável usar um cache em disco muito grande, deixando de seguir esta regra somente em caso de alta necessidade. Configurando o arquivo de log Por padrão, o Squid possui um arquivo de log localizado em /var/log/squid/access.log. Esta opção pode ser adicionada da seguinte forma no arquivo de configuração: cache_access_log /var/log/squid/access.log Padrão de atualização A opção refresh_pattern indica o padrão de atualização do cache. Em outras palavras, indica o momento que o Squid deverá buscar na Internet uma página que ele está armazenando, mas que pode já ter sido atualizada. Para o seu funcionamento, deverá ser explicitado no arquivo de configuração do Squid o padrão para os protocolos http, ftp e gopher. Se alguma for eliminada, o Squid usará a configuração padrão. aqui. Como o servidor do BCC não utiliza este padrão, não será mostrado nenhum exemplo Restrições de acesso Em um ambiente de estudo, a idéia é que os funcionários usem a Internet exclusivamente para fins de Ensino, Pesquisa e Extensão, conforme a norma estabelecida pela Coordenadoria do BCC. É evidente que algumas outras atividades deverão ser permitidas, como o acesso de contas pessoais, pois podem estar relacionadas ao propósito inicial. Porém, a partir desse ponto o acesso estará fora de cogitação, sendo o limite estabelecido. Diante disso, chegamos, então, às regras para restrição de acesso, que são uma necessidade para a boa administração da rede. Por domínio e palavras Existe 2 formas de bloqueio pelo Squid: por domínio e por palavras. Bloqueio por domínio O bloqueio de sites indesejados é feito de uma forma bastante simples, usando o parâmetro dstdomain. Ele permite que criemos acls contendo endereços de sites que devem ser bloqueados ou permitidos. Isso é feito em duas partes: primeiro cria-se a acl (especificando os 101

102 endereços) e, em seguida, utiliza-se o parâmetro http_access para bloquear ou liberar o acesso a eles. Por exemplo: acl bloqueados dstdomain orkut.com globo.com http_access deny bloqueados Neste caso, cria-se a acl bloqueados, negando-lhe o acesso em seguida. É importante observar que os domínios bloqueados são aqueles que aparecem exatamente da forma que foram digitados para a formação da acl. Ou seja, se alguém fizer o acesso ao Orkut pelo domínio o Squid não irá bloqueá-lo! Para isso, deve-se utilizar todo domínio possível para um site no momento de criação da acl. Podemos criar uma acl com vários domínios, desde que estes estejam separados por espaço ( ) e estejam na mesma linha. Porém, esta acl poderá assumir um tamanho muito grande se precisarmos incluir vários domínios. Para isso, temos a possibilidade de inclusão através da indicação do caminho de um arquivo que contenha todos os domínios necessários (um após o outro, separado por um ENTER). Assim, criamos o arquivo contendo os domínios, sendo um domínio para cada linha deste, e com a opção url_regex i, fazemos a criação desta acl. Por exemplo: acl bloqueados url_regex -i /etc/squid/dominiosbloqueados http_access deny bloqueados Dessa forma, todos os domínios dentro do arquivo dominiosbloqueados serviriam para a criação da acl bloqueados, sendo em seguida negado o acesso a esta acl. Fazendo o caminho inverso, poderíamos criar acls com certos domínios que seriam permitidos os acessos. Esse controle seria muito mais fácil que o anterior, pois poderíamos elencar domínios básicos para acessos, sendo estes em uma quantidade menor do que a lista que seria criada de domínios bloqueados. Para isso, devemos criar o arquivo com os domínios que serão permitidos, a respectiva acl e, em seguida, permitir estes domínios, negando acesso aos demais. Por exemplo: acl permitidos url_regex -i /etc/squid/dominiospermitidos http_access allow permitidos http_access deny all Isso permitiria apenas os domínios que estivessem elencados no arquivo dominiospermitidos. Uma última forma de bloquear domínios é através de seus endereços IP. Isto pode ser feito com a opção dst". Esta opção é útil para bloquear/permitir acesso a servidores que ainda não possuem domínio registrado. Logo, poderíamos fazer o bloqueio da seguinte forma: acl ips_bloqueados dst http_access deny ips_bloqueados 102

103 Caso seja necessário descobrir o IP de algum domínio para incluir nesta acl, pode-se utilizar o comando host, da seguinte forma: $ host nome_dominio Como exemplo, se utilizássemos o comando host google.com, teríamos a seguinte resposta: google.com A google.com A google.com A Finalizando, todas estas regras devem vir também antes das regras que abrem tudo para a rede local (http_access allow redelocal). Bloqueio por palavras Outra forma de bloqueio/permissão está baseada em palavras incluídas na URL de acesso. Isto pode ser feito com a opção dstdom_regex, que age de uma forma mais geral. Com isso, podemos, por exemplo, bloquear todas as páginas cujo endereço inclua a palavra orkut". Porém, tal bloqueio/permissão estará vinculado apenas ao domínio do site, e não ao conteúdo e/ou subpastas desse domínio. Uma característica deste tipo de bloqueio é que o Squid utiliza de expressão regular para o casamento de caracteres, ou seja, qualquer domínio que contiver parte desta palavra também será bloqueado/permitido. Por isso, utilize-o com cuidado! Assim, similar ao bloqueio por domínio, podemos criar a acl com a lista de palavras ou com a utilização de um arquivo que contenha o conjunto das palavras que serão utilizadas como referência para a criação da acl. Como exemplo, para um bloqueio com o uso de um arquivo deste tipo, teríamos: acl palavrasproibidas dstdom_regex /etc/squid/palavrasproibidas http_access deny palavrasproibidas Isso faria com que todos os domínios que contenham uma parte de seu domínio similar a alguma das palavras do arquivo palavrasproibidas sejam bloqueados. Note que neste caso não se utiliza a opção -i para indicar o caminho do arquivo. Uma vantagem deste tipo de restrição de acesso é que ela permite bloquear facilmente páginas dinâmicas, onde a palavra é passada como parâmetro da URL. Por exemplo, o Orkut (de novo :D), onde há um redirecionamento da página do Google para aquela, sendo passada como parâmetro pela URL. 103

104 Erro pertinente a um acesso sem permissão Incluídas as regras, os clientes passam a ver uma mensagem de erro ao tentar acessar páginas que se enquadrem nos bloqueios: A mensagem de erro, por padrão, está configurada para ser exibida em inglês. Para alterar esta mensagem que é mostrada ao usuário, adicione a seguinte linha no arquivo de configuração do Squid: error_directory /usr/share/squid/errors/portuguese/ Isto irá resolver o problema dos desprovidos do idioma inglês :D Aproveitando a oportunidade, esta pasta de erro contém todos os erros que serão mostrados aos usuários na ocorrência de uma falha. 104

105 Por horário A última restrição do Squid está relacionada ao horário de acesso. Podemos definir regras para períodos específicos e combiná-las para bloquear/permitir todos os horários em que não queiramos que o Proxy seja usado ou vice-versa. Isto pode ser feito através da opção time. Por exemplo: acl madrugada time 00:00-06:00 http_access deny madrugada acl almoco time 12:00-14:00 http_access allow almoco Estas duas regras criam as seguintes condições: a acl madrugada, seguida da negação pelo http_access, negaria todos os acessos entre 0 e 6 horas; e a acl almoco, seguida da permissão pelo http_access, permitira o acesso entre 12 e 14 horas. Se utilizada em conjunto com a restrição pela URL, a restrição por horário deverá vir antes desta e da permissão de rede local. Por exemplo: acl almoco time 12:00-14:00 http_access allow almoco acl bloqueados url_regex -i /etc/squid/bloqueados http_access deny bloqueados... Assim, os acessos que forem aceitos pela regra do almoço não passarão pelas regras que fazem o bloqueio. Outra forma de combinação é com o uso de palavras ou domínios com as regras de bloqueio por horário, permitindo que os usuários acessem um determinado site apenas no horário de almoço, por exemplo. Neste caso, teríamos: acl almoco time 12:00-14:00 acl orkut dstdomain orkut.com http_access allow orkut almoco http_access deny orkut Desta forma, o acesso ao site do Orkut seria permitido apenas durante o horário de almoço. Note que ao utilizar duas acls na mesma linha de atribuição de permissão, segue-se a condição lógica e, devendo acontecer os dois ao mesmo tempo. Exceções de acesso por IP É possível também criar regras de exceção para endereços IP específicos, que poderão fazer downloads sem passar por qualquer filtro. Neste caso, deverá ser utilizada a opção src, similar a utilização para a criação da acl para rede local. Porém, neste caso, ignora-se a Máscara de sub-rede, indicando apenas o endereço IP. Por exemplo: 105

106 acl chefe src http_access allow chefe Dessa forma, podemos permitir/bloquear endereços específicos. Se utilizada em conjunto com outras regras, esta deverá vir antes de qualquer acl com restrição de acesso. Exceções por formatos de arquivos Por fim, mais um tipo de bloqueio útil é com relação a formatos de arquivos. Muitas vezes é necessário bloquear o download de arquivos.exe ou.sh para dificultar a instalação de programas nas estações, ou bloquear arquivos.avi ou.wmv para economizar banda da rede, por exemplo. Para isso, podemos utilizar a mesma opção para controle na URL, a url_regex, porém, indicando extensões de arquivos específicos. Por exemplo: acl extensaoproibida url_regex -i \.avi \.exe \.mp3 \.torrent http_access deny extensaoproibida Da mesma forma, podemos indicar um arquivo externo ao invés das extensões diretamente. Deve-se observar que cada tipo deve vir em um linha deste arquivo, sendo escritas da mesma forma anterior, com o \.extensão. Gerenciando o uso de banda O Squid oferece uma forma simples de limitar o uso da banda disponível e definir o quanto cada usuário pode usar. Como exemplo deste serviço, imagine que se tenha um link de 1Mb para uma rede com 20 usuários. Se cada um puder ficar baixando o que quiser, é provável que a rede fique saturada em determinados horários, deixando a navegação lenta para todo mundo. Assim, isso pode ser evitado, limitando a banda que cada usuário pode usar e a banda total, que todos os usuários somados poderão usar, simultaneamente. Esta é uma alternativa bastante interessante no Squid. Porém, como ainda não está implementada no servidor do BCC, não será detalhada. Posteriormente, caso seja necessário esta política, os detalhes poderão ser transcritos nesta seção. Configurando um Proxy com autenticação Além de todas as restrições mostradas anteriormente, podemos aumentar o controle e a segurança sobre o nosso sistema com a exigência de autenticação no Proxy. Com isso, é possível controlar quem tem acesso à Internet e, assim, auditar os acessos em caso de necessidade. 106

107 Módulos para autenticação Para o serviço de autenticação, o Squid conta com alguns módulos que irão auxiliar neste serviço. Vejamos alguns: ncsa_auth A forma mais simples de implementar a autenticação no Squid é usando o módulo ncsa_auth, que faz parte do pacote principal. Ele utiliza um sistema simples, baseado em um arquivo de senhas, onde pode-se cadastrar os possíveis usuários. Para criar o arquivo de senhas, deve-se utilizar o script htpasswd, que faz parte do pacote apache2-utils. Logo, pelo APT, podemos obtê-lo da seguinte forma: # apt-get install apache2-utils Em seguida, precisamos criar um arquivo vazio, que irá conter as senhas dos usuários. Por exemplo, pelo comando touch, iremos criar o arquivo passwd para o Squid: # touch /etc/squid/passwd A partir desse momento, podemos cadastrar os logins usando o htpasswd, especificando o arquivo que acabou de criar e o login que será cadastrado, da seguinte forma: # htpasswd /etc/squid/passwd tiago Em seguida, deve-se informar a senha para cada usuário que é passado como parâmetro deste comando. Feito o cadastro dos possíveis usuários, deve-se agora modificar o arquivo de configuração do Squid, informando a utilização deste módulo e permitindo apenas os usuários cadastrados. A alteração é feita da seguinte forma: auth_param basic realm Autentique-se auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd acl autenticados proxy_auth REQUIRED http_access allow autenticados A primeira linha informa a mensagem que aparecerá na janela de autenticação dos clientes. Para o Firefox, apresentará a seguinte tela: 107

108 A segunda linha indica a localização da biblioteca responsável pela autenticação, seguido pela localização do arquivo de usuários e senhas cadastrados. O caminho da localização da biblioteca ncsa_auth pode ser obtido pelo comando # locate ncsa_auth. A terceira linha cria a acl autenticados, que irá conter apenas o usuário que possuir uma autenticação válida. E, por fim, a última linha permite o acesso à acl autenticados. Uma questão importante a se observar é a respeito da localização destas configurações no arquivo de configuração do Squid. Elas deverão estar localizadas antes de qualquer outra regra que libera o acesso, pois se este acesso fosse liberado antes da autenticação, esta não teria efeito no caso de uma falha de autenticação, devido o acesso já permitido anteriormente. Uma característica interessante que pode ser adotada através da realização da autenticação é que podem ser criadas regras de acesso com base nos logins de usuários e não mais apenas com base nos endereços IP. E isto (juntamente com as outras regras de restrição de acesso) pode proporcionar mais flexibilidade aos usuários. Um exemplo disso seria o seguinte: deseja-se que apenas 2 usuários da rede tenha acesso irrestrito ao Proxy. Os demais (depois de autenticados) poderão acessar apenas no horário do almoço e quem não tiver login válido não terá qualquer permissão de acesso. O arquivo de configuração ficaria assim: auth_param basic realm Autentique-se auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd acl autenticados proxy_auth REQUIRED acl permitidos proxy_auth tiago tux alc almoco time 12:00-13:00 http_access allow permitidos http_access allow autenticados almoco Contudo, apesar dessa característica, a autenticação através do módulo ncsa_auth exige que todos os usuários estejam cadastrados em um arquivo próprio, como foi feito inicialmente. Assim, se utilizarmos um sistema de autenticação distribuído, como o NIS ou o SAMBA, precisaríamos ter 2 arquivos de autenticação diferentes, sendo um para o Proxy e o outro para o sistema de autenticação utilizado, o que exigiria 2 autenticações diferentes. Logo, uma alternativa mais elegante será vista em seguida. 108