1. KERNEL A P O STI L A

Transcrição

1 1. KERNEL Kernel de um sistema operacional é entendido como o núcleo deste ou, numa tradução literal, cerne. Ele representa a camada mais baixa de interface com o Hardware, sendo responsável por gerenciar os recursos do sistema computacional como um todo. É no kernel que estão definidas funções para operação com periféricos (mouse, disco, impressora, interface serial/interface paralela), gerenciamento de memória, entre outros. Resumidamente, o kernel é um conjunto de programas que fornece para os programas de usuário (aplicativos) uma interface para utilizar os recursos do sistema. Quanto à sua arquitetura, o kernel pode ser monolítico - em um único bloco, com todas as funcionalidades carregadas na memória - ou modular (micro-kernel) - com os módulos específicos para cada tarefa carregados opcionalmente, dinamicamente. O kernel é a parte mais importante do sistema operacional, pois, sem ele, a cada programa novo que se criasse seria necessário que o programador se preocupasse em escrever as funções de entrada/saída, de impressão, entre outras, em baixo nível, causando uma duplicação de trabalho e uma perda enorme de tempo. Como o kernel já fornece a interface para que os programas possam acessar os recursos do sistema de um nível mais alto e de forma transparente, fica resolvido o problema da duplicação do trabalho. Quando há periféricos ou elementos de um sistema computacional que o kernel não cobre, então se faz necessário escrever a interface para eles, os chamados device drivers. Geralmente, os kernels oferecem uma função para se executar chamadas de sistema, como por exemplo a ioctl(), função essa que podemos denominar de I/O Control do Linux. Valendo-se dessa função, podem-se escrever rotinas para qualquer dispositivo. 1.1 Kernel monolítico. Kernel monolítico ou mono-bloco é um kernel que implementa um interface de alto nível para possibilitar chamadas de sistema específicas para gestão de processos, concorrência e gestão de memória por parte de módulos dedicados que são 1

2 executados com privilégios especiais. Alguns exemplos deste tipo de kernel: BSD Linux 1.2 Micro-Kernel. Micro-kernel é um termo usado para caracterizar o sistema cujas funcionalidades do sistema saíram do kernel e foram para servidores, que se comunicam com um núcleo mínimo, usando o mínimo possível o "espaço do sistema" (nesse local o programa tem acesso a todas as instruções e a todo o hardware) e deixando o máximo de recursos rodando no "espaço do usuário" (no espaço do usuário, o software sofre algumas restrições, não podendo acessar alguns hardwares, nem tem acesso a todas as instruções). Alguns exemplos deste tipo de kernel: Hurd Minix Microsoft Windows NT 2

3 1.3 Recompilando o Kernel. A recompilação do kernel tem de ser extremamente observada. É nela que você poderá colocar suporte a muitos tipos de hardwares, habilitar recursos do kernel (como firewall e compartilhamento NAT), entre outras coisas. Muitas distribuições incluem kernels já compilados e prontos para usar, mas é sempre recomendado que você compile o seu kernel para otimizá-lo conforme suas necessidades. Alguns pacotes precisam ser instalados antes da recompilação do kernel, entre eles, os pricipais são o gcc-4.0, initrd-tools, automake1.9, make e libncurses5-dev. Pacotes de descompactação também serão necessários, portanto devemos instalar os pacotes tar, bzip2 e gzip. Descompactando o kernel Em primeiro lugar, vamos baixar uma imagem e descompactá-la em algum diretório, para depois começarmos a configurar a compilação. Os códigos-fonte do kernel em suas várias versões podem ser todos encontrados através do seguinte endereço: Página oficial do Kernel ftp://ftp.kernel.org FTP oficial do Kernel Acesso HTTP ao FTP oficial do Kernel ftp://ftp.br.kernel.org Mirror Brasileiro do FTP do kernel Para facilitar, vamos um browser em modo texto para baixar a última versão do kernel, para isso deveremos instalar o links através do apt-get com o seguinte comando: # apt-get install links Para acessarmos a página do kernel devemos digitar o seguinte comando no shell: # links Vamos baixar a última versão disponível do kernel, utilizando a seta de direcionamento para baixo até chegarmos a letra F (Full), em seguida precione a letra D (download) e em seguida pressione a tecla enter para iniciar o download. Terminado o download, utilizaremos o comando mv para mover o pacote do kernel para o diretório /usr/src. # mv linux-v.x.y.z.tar.bz2 /usr/src Agora, portanto é hora de descompactarmos o código fonte do kernel, para isso 3

4 utilizaremos a seguinte linhas de comando: # cd /usr/src # tar -xvjf linux-v.x.y.z.tar.bz2 Para facilitar, criaremos um link simbólico do diretório nos quais os fontes do kernel foram extraidos. # ln -s linux-v.x.y.z linux No proximo passo, iniciaremos a configuração para posteriormente compilarmos o kernel. # cd linux # make menuconfig É extremamente necessário que você tenha todo o conhecimento sobre o hardware utilizado no computador, e serviços para os quais ele deverá atender. Para verificarmos uma listagem simplificada de hardware, utilizaremos o segundo terminal disponível, apertando as teclas Alt+F2. Em seguida, digitaremos o seguinte comando: # lspci 4

5 Desta forma saberemos quais são os principais hardwares instalados no computador para que possamos passar informações corretas ao kernel. Sabendo qual é o tipo de hardware existente no computador, retornaremos à janela de configuração do kernel pressionando as teclas Alt+F1. Dentro das configurações do kernel Linux, podemos setar as opções como build in (compilado diretamente dentro de uma única estrutura do kernel, sendo carregado sempre que o computador for iniciado e é representado por um *) ou podemos ainda setar as opções como modules (modulos que podem ou não ser carregados pelo kernel em sua inicialização e é representado pela letra M). Após todas as modificações necessárias, iremos salvar o arquivo de configuração selecionando a opção Save Configuration to an Alternate File Agora iremos salvar as configurações do kernel com o nome de config-meu-kernel (pode ser qualquer outro nome desde que se recorde posteriormente). 5

6 Agora é só sair selecionando a opção Exit ele irá questionar se deseja salvar, selecione Yes. Com o kernel configurado, iniciaremos a compilação com o seguinte comando: # make bzimage Se todas as configurações do kernel estiverem corretas, o kernel já estará compilado e será salvo dentro do diretório /usr/src/linux/arch/i386/boot/, caso contrário, deveremos reconfigurá-lo identificando na mensagem de erro qual o causador do problema e rodar novamente o comando acima descrito. O próximo passo é instalar os módulos. Para isso utilizaremos os seguintes comandos: # make modules # make modules_install Vamos agora copiar a imagem do kernel compilado, do nosso arquivo de configurações e um arquivinho chamado System.map para o diretório /boot nota-se que o nome do kernel geralmente iniciá-se por vmlinuz, portanto ao copiarmos o arquivo bzimage, já estaremos renomeando-o com esse prefixo mais sua versão tudo isso com os seguintes comandos: 6

7 # cp /usr/src/linux/arch/i386/boot/bzimage /boot/vmlinuz-v.x.y.z # cp /usr/src/linux/system.map /boot # cp /usr/src/linux/config-meu-kernel /boot Agora é necesário criarmos uma imagem initrd, que é uma imagem relativa aos procedimentos de inicialização do sistema, para isso usaremos o seguinte comando: # mkinitrd /lib/modules/v.x.y.z/ -o /boot/initrd-v.x.y.z.img Para organizar a estrutura de kernels, uma vez que pode-se ter mais de um no sistema operacional GNU/Linux, vamos criar links simbólicos no diretório raiz com os seguintes comandos: # ln -s /boot/vmlinuz-v.x.y.z / # ln -s /boot/initrd.v.x.y.z.img / Agora é só adicionar as linhas no /etc/lilo.conf e redar o comando lilo ou adicionar em menu.lst dentro do diretório /boot/grub/ conforme já aprendido acima. CUIDADO!!! Lembre-se de sempre adicionar uma nova entrada em seu arquivo de configuração do kernel, não é seguro substituí-las, pois, o novo kernel pode não funcionar após a próxima reinicialização. 7

8 2. SERVIDOR DHCP O DHCP (Dynamic Host Control Protocol) é um protocolo utilizado para endereçamento dinâmico de hosts. Através do DHCP, é possível endereçar uma grande quantidade de hosts de uma rede, sem perder um grande tempo configurando estações de trabalho. Existe um serviço no GNU/LINUX chamado dhcpd que pode ser configurado para fornecer endereços IP's automaticamente para os clientes da rede. Com isso, o administrador da rede ganha tempo, tem uma configuração mais confiável e muito mais estável em todas as suas estações. Além disso, é possível ter um controle dos endereços utilizados pelos hosts da rede e fornecer algumas configurações adicionais, tais como, endereço de gateway, servidor de DNS primário, servidor de DNS secundário, entre outros. 2.1 Instalando o servidor e cliente dhcp. Para instalar o servidor e o cliente de dhcp, devemos usar o seguinte comando: # apt-get install dhcp3-server dhcp3-common dhcp-client Instalado o servidor, daremos início à sua configuração, seu arquivo encontra-se dentro do diretório /etc/dhcp3/dhcpd.conf As linhas que contiverem # na frente, não serão lidas pelo servidor DHCP, pois estarão comentadas. # vi /etc/dhcp3/dhcpd.conf ddns-update-style none; Esta opção especifica se o servidor DHCP deverá tentar atualizar o DNS quando um arrendamento é aceito ou devolvido. Na implementação da ISC, esta opção é obrigatória. option domain-name "marcioleonardi.com.br"; 8

9 Esta opção especifica o domínio que será fornecido aos clientes como o principal domínio de busca. option domain-name-servers , ; Esta opção especifica uma lista separada por vírgulas de servidores DNS que o cliente deve utilizar. default-lease-time 600; Um cliente pode requerer um período de tempo específico válido para um arrendamento. Senão o servidor deverá fazer um arrendamento com este prazo de expiração (em segundos). max-lease-time 7200; Se você tiver mais endereços IP do que máquinas os endereços IP das estações raramente vai precisar mudar. Mas, no caso de uma rede congestionada, o " maxlease-time" determina o tempo máximo que uma estação pode usar um determinado endereço IP. Isso foi planejado para ambientes onde haja escassez de endereços IP, em condições normais estas duas opções não são muito importantes. authoritative; Em uma rede com 2 servidores DHCP, esta opção o torna padrão da rede local. subnet netmask { range ; option routers ; } A opção "range" determina a faixa de endereços IP que será usada pelo servidor. Se você utiliza a faixa de endereços até por exemplo, pode reservar os endereços de a para estações configuradas com IP fixo e usar os demais para o DHCP. A opção routers declara o gateway padrão que será fornecido aos clientes. host Marcio { hardware ethernet 00:0C:6E:8E:F7:9A; fixed-address ; 9

10 } O endereço MAC de um sistema (de forma que o servidor DHCP possa reconhecêlo quando dele receber uma solicitação). Especifica que o sistema sempre deve receber o mesmo endereço IP. Note que um hostname funciona aqui, desde que o servidor DHCP seja capaz de resolver o nome via DNS antes de responder à solicitação com as informações do arrendamento. Desta forma estará finalizada a configuração do seu servidor DHCP devendo iniciálo através do seguintes comandos: # /etc/init.d/dhcp3-server stop # /etc/init.d/dhcp3-server start 10

11 3. SERVIDOR FTP FTP significa File Transfer Protocol (Protocolo de Transferência de Arquivos), e é uma forma bastante rápida e versátil de transferir arquivos, sendo uma das mais usadas na internet. Pode referir-se tanto ao protocolo quanto ao programa que implementa este protocolo (neste caso, tradicionalmente aparece em letras minúsculas, por influência do programa de transferência de arquivos do Unix). A transferência de dados em redes de computadores envolve normalmente transferência de arquivos e acesso a sistemas de arquivos remotos (com a mesma interface usada nos arquivos locais). O FTP (RFC 959) é baseado no TCP, mas é anterior à pilha de protocolos TCP/IP, sendo posteriormente adaptado para o TCP/IP. É o standard da pilha TCP/IP para transferir arquivos, é um protocolo genérico independente de hardware e do sistema operacional e transfere arquivos por livre arbítrio, tendo em conta restrições de acesso e propriedades dos arquivos. Existem diversos servidores FTP disponível para GNU/Linux, vamos utilizar o ProFTPd como exemplo para nossa experiência. 3.1 Instalando o ProFTPd. Como já vimos antes, vamos instalar o servidor através do comando apt, com os seguintes parâmetros: # apt-get install proftpd proftpd-common 3.2 Configurando o ProFTPd. Como todo daemon de um sistema GNU/Linux e Unix, o ProFTPd é configurado através de um arquivo texto, o /etc/proftpd.conf. Com um simples editor de texto é possível efetuar sua configuração. É interessante observar que o ProFTPd apenas lê seu arquivo de configuração ao ser iniciado. Portanto após cada modificação deveremos reiniciá-lo. A sintaxe do arquivo /etc/proftpd.conf é simples. O ProFTPd usa o conceito de contextos em sua configuração e nestes contextos temos as chamadas diretivas. Contexto é uma configuração global de um certo comportamento do ProFTPd 11

12 enquanto as diretivas são as sub-opções que configuram os contextos. Contextos do ProFTPd. Basicamente temos dois contextos principais: Contexto Principal: Contém as configurações default que serão utilizados inclusive por outros contextos. Contexto <Directory DIR >: Determina o comportamento do ProFTPd quando acessando e/ou servindo o diretório DIR. Abaixo temos um exemplo de configuração do ProFTPd (perceba que é a configuração default de nossa versão customizada). Exemplo 1. exemplo do configuração do ProFTPd #Configuração do ProFTPd ServerName ServerType DefaultServer ServerAdmin "FTP-TESTE" standalone on root@localhost #Para efetuar download aos pedaços AllowRetrieveRestart on #porta 21 padrão port 21 #Umask 022 é um bom padrão pra prevenir que novos diretórios e arquivos #sejam graváveis pelo grupo de usuários Umask 022 #Quantidade máxima de instâncias MaxInstances 10 #Usuário e grupo para o servidor no caso de especificação 12

13 especifica #User #Group nobody nobody #Autenticação de usuário...utilizando o usuário do própio server GNU/Linux AuthUserFile /etc/passwd #login como root RootLogin on #Faz com que o usuário apenas acesse seu diretório $HOME DefaultRoot ~ <Directory /*> Todas as devias alterações realizadas vamos reiniciar o processo com o seguinte comando: # /etc/init.d/proftpd stop # /etc/init.d/proftpd start 13

14 Algumas diretivas do contexto principal: 14

15 Algumas diretivas do contexto <Directory> 15

16 4. SERVIDOR OPENSSH O Secure Shell ou SSH é, simultaneamente, um programa de computador e um protocolo de rede que permite a conexão com outro computador na rede, de forma a executar comandos de uma unidade remota. Possui as mesmas funcionalidades do TELNET, com a vantagem da conexão entre o cliente e o servidor ser criptografada. As redes de computadores são uma mídia inerentemente insegura. A menos que você tem certeza que seus pacotes nunca irão passar por um roteador ou computador que você não controle direto sobre, seus dados não estão seguros. Eles podem ser visualizados por sysadmins pouco confiáveis ou por um script kiddie, ele pode ser alterado em trânsito, ou pode ser interceptado e trocado por dados completamente diferentes. 4.1 Criptografia e Assinaturas Digitais. Como mensionado anteriormente, você não pode simplesmente confiar em qualquer dado que passe pela Internet sem algum método para garantir que o dado que você envia é o mesmo dado que é recebido do outro lado. Isto parece paranóico, e na maioria dos casos é, mas é sempre melhor estar seguro que ter problemas. É muito fácil para qualquer um falsificar os seus dados durante o trânsito. E se você tem dados que são sensíveis ou privados, certamente você não vai querer que J. Random Hacker ou H. Bored Sysadmin leia o mesmo. É aqui onde a criptografia e a assinatura digital entram. Vejamos um exemplo concreto de um problema típico de segurança. Suponha que o servidor A deseje envia uma mensagem ao servidor B. Se a mensagem for enviada descriptografada e passa pelo roteador C, qualquer informação enviada é visível a root@c. Se root@c é hostil, ele pode resolver ler o que o servidor A está tentando enviar para o servidor B, e, em vez de repassar a mensagem, enviar uma mensagem falsa para B, e fazer a mesma coisa no retorno de B para A. Este é o ataque conhecido como "man-in-the-midle" ou "intermediário". 16

17 Dados Sensíveis Tipicamente os pacotes enviados pela Internet viajam por vários roteadores antes de chegar a seu destino. Cada um destes roteadores é um perigo potencial e possui completo acesso a seus dados. Esta é, claramente, uma situação inaceitável para muitos dados importantes ou sensíveis. Infelizmente as pessoas constantemente estão enviando segredos da empresa, informações pessoais, senhas, números de cartão de crédito, e outros dados privados não criptografados pela internet. Ou elas não percebem o perigo disto ou simplesmente não acreditam que valha o esforço a própria proteção. Autenticação Outra área em que a técnica de criptografia é usada é na área de autenticação como eu fico sabendo que você é quem você diz ser? Um nome de login e senha podem ter sido seguros há 20 anos atrás, mas eles são facilmente roubados ou violados. E um esquema de login e senha pode fornecer um serviço básico de autenticação, mas uma vez autenticado, eles não garantem que os dados recebidos sejam exatamente os mesmos que foram enviados. Criptografia e assinaturas digitais são extremamente importantes para resolver estes problemas (particularmente sistemas de chave pública). Criptografia de Chave Privada vs. Pública Tradicionalmente a criptografia têm se baseado em um segredo compartilhado, conhecido como chave. Esta chave é usada em uma fórmula matemática para embaralhar a informação em questão de forma que ela não possa ser desembaralhada facilmente sem o conhecimento da chave secreta. Enquanto esta técnica pode ser bem segura quando estiver em uso um bom algoritmo e uma chave de tamanho razoável, ela introduz o problema da troca de chaves. Como você pode se comunicar com um host remoto na Internet quando você não tem um canal seguro de comunicação que você possa utilizar para transferir a chave de criptografia em primeiro lugar? Este problema tem sido resolvido tipicamente pela transferência das chaves pessoalmente. A presunção que a criptografia requer o compartilhamento do conhecimento de uma chave está tão entranhado que ele geralmente não é reconhecido. Simplesmente é assumido pela maioria que este é um defeito das técnicas de criptografia. Entretanto, tudo mudou em 1976 quando Martin Hellman, Whitfield Diffie, e Ralph Merkle apresentaram a idéia da criptografia de chave pública na Stanford University. A criptografia de chave pública aborda diferente. Aqui temos 2 chaves cuidadosamente, e uma chave pública, chave pública pode ser derivada da o problema de um ângulo completamente uma chave privada, que é protegida que pode ser passada a quem a quiser. A chave privada, mas não vice-versa. Os 17

18 algoritmos de chave pública possuem a propriedade que os dados criptografados pela chave pública podem ser somente descriptografados pela chave privada correspondente. Com esta descoberta, o problema da troca de chaves está praticamente resolvido. Não há mais necessidade de uma mídia segura para a transferência inicial de chaves, mas você pode simplesmente criptografar os dados com a chave pública do recipiente e ter certeza que os dados só podem ser recuperados com a chave privada dele, a qual nunca precisa sair do controle dele. Isto também resolve o problema mencionado acima da autenticação - se você quer ter certeza que alguém é quemdiz ser, simplesmente criptografe uma pequena quantia de dados (conhecida como "desafio") usando sua chave pública, e envie a esta pessoa. Esta pessoa então descriptografa a mesma com sua chave privada e envia de volta (possivelmente criptografada com tua chave pública). Se os dados que você receber são idênticos aos dados originalmente enviados, você sabe que ele é quem diz ser. Então por quê a criptografia de chave privada ainda é utilizada? A razão tem a ver com eficiência. Os métodos atuais de criptografia com chave pública são muito mais lentos que os métodos de chave privada, tornando, desta forma, impraticável a criptografia de enormes quantias de dados. Frequentemente, (como com o SSH), um método de chave pública pode ser utilizado para autenticação e para a troca de uma chave privada. Se tudo der certo com estes dois passos, a criptografia de chave privada pode ser usada. Funções de Hash Uma função de Hash é simplesmente uma função que pega uma enorme quantia de dados e encolhe a mesma para um tamanho bem menor. É uma função de uma via (ou seja, a informação original não pode ser determinada a partir do hash resultante). Funções criptográficas de hash tem a propriedade adicional que uma pequena alteração nos dados originais resulta em uma grande alteração no hash resultante, o que torna extremamente difícil alterar os dados e manter o mesmo hash resultante. Assinaturas Digitais Assinaturas digitais fazem uso das funções de hash criptográficas para mostrar que o que o recipiente vê é, de fato, a informação que foi originalmente enviada. Algoritmos de assinatura digital típicos são baseados na criptografia de chave pública, e uma visão simplificada de como funcionam é mostrada no seguinte exemplo: A pessoa A compõe um para a pessoa B. Quando o está pronto para ser enviado, ele é passado por um algoritmo criptográfico de hash e o hash resultante é criptografado com a chave privada de A e anexado ao . Quando a pessoa B recebe o , ela descriptografa a assinatura com a chave pública de A e passa o 18

19 pelo mesmo algoritmo de hash. Se o hash resultante é idêntico ao hash descriptografado, a pessoa B pode confiar que o não foi adulterado durante o transporte. Mesmo pequenas alterações, como o acréscimo de pontuações ou espaços irá resultar em um hash completamente diferente. Assinaturas digitais são uma exigência legal em alguns estados por que são (praticamente) impossíveis de serem forjadas - certamente são muito mais difíceis de forjar que uma assinatura física. Uma aplicação popular para a criação e verificação de assinaturas digitais (bem como criptografar e descriptografar) é o PGP, ou sua alternativa livre, o GnuPG. 4.2 Instalação do OpenSSH Para instalarmos o OpenSSH, serão necessários 3 (três) pacotes, que deverão ser instalados via apt-get com o seguinte comando: # apt-get install openssh-server openssh-client ssh 4.3 OpenSSH Básico O OpenSSH é uma implementação livre dos protocolos SSH, versão 1 e 2. O nome secure shell é um pouco equivocado, uma vez que o mesmo não é um shell da mesma forma que o bash ou do tcsh são shell, mas é mais do tipo do rsh. Ele é usado quando é preciso fazer um acesso remoto seguro a uma máquina Unix, mas devido à prevalência de script kiddies que adorariam conseguir sua senha e ober acesso livre a teus servidores, é uma boa idéia usar o mesmo sempre que você precisar fazer algum acesso remoto. O uso mais básico do ssh, e a forma que ele é usado pela maioria das pessoas, é como substituto do telnet. O telnet transmite toda comunicação, incluindo o login e senha, em texto plano, e esta informação pode facilmente ser interceptadapor qualquer um que tenha acesso físico a qualquer rede ou roteador em que os seus pacotes passarem. Qualquer coisa transmitida pela Internet em texto plano é jogo fácil para qualquer um, por isto você tem que ser cuidadoso. Usar o ssh ao invés do telnet torna muito mais difícil sua informação ser capturada. O uso básico do ssh é simples. Vamos por exemplo conectar via SSH no nosse endereço de loop-back , e com nosso usuário comum desta forma você pode usar o seguinte comando: $ ssh acc@ Dependendo de sua versão do ssh, você pode também ver uma mensagem mostrando a fingerprint da chave do host remoto. Esta está ligada a um hash da chave, e se você estiver sendo extremamente cuidadoso você vai trocar as fingerprints com o administrador do host remoto através de uma linha segura (tipo um telefone ou pessoalmente) antes de fazer a conexão, e então verificar se as 19

20 fingerprints são idênticas. Isto é para proteger-se de um ataque "man-in-the-middle" que eu discuti acima, onde alguém fica entre você e o servidor, trocando as chaves e criptografando e descriptografando suas comunicações de uma forma que é transparente tanto para você quanto para o servidor, mas permitindo-o ver (e alterar) toda a comunicação. Uma vez que o ssh tenha feito a conexão, ele irá pedir pela sua senha. Esta é a senha associada à conta de usuário na máquina remota que é idêntica ao username que você forneceu ao ssh (se você não fornecer um username, o ssh assume que você quer usar o username no qual você está logado atualmente na sua máquina). Quando você informar a senha, o ssh criptografa a mesma e a envia para o servidor remoto. Se a senha for idêntica à senha associada à conta remota, o ssh cria um login shell e loga você na máquina remota. A partir deste ponto, você pode usar a máquina como se estivesse logado no console. Existem duas versões diferentes do protocolo ssh - ssh1 e ssh2 (ambos são suportados pelo OpenSSH). Várias vulnerabilidades foram descobertas no ssh1, e a recomendação em geral é que se use o ssh SSH Port Forwarding O telnet e outros mecanismos de login estão longe de serem os únicos protocolos de rede que tem o mau hábito de transmitir informações descriptografadas. Muitos protocolos comuns, como HTTP, POP3, ou IMAP, transmitem as informações em texto plano, possivelmente incluindo logins e senhas. Enquanto cada um destes protocolos tem uma versão protegida pelo SSL, as versões seguras não são tão comuns quanto as versões não protegidas. Além disto, a instalação de versões protegidas pelo SSL requer o uso de privilégios de superusuário, e se, por exemplo, você lê seu via IMAP de um servidor remoto para o qual você não tem controle direto, você não pode instalar o IMAP-S. O SSH vem para o resgate aqui. Desde que você tenha acesso shell ao servidor que você deseja se conectar, o SSH pode criar um tunel criptografado para você usar como canal para suas conexões de rede. Ele faz isto criando uma conexão segura ao servidor, abrindo uma porta na sua máquina local, e canalizando tudo que recebe na porta local para uma porta específica no servidor remoto. Vamos usar o IMAP com exemplo, já que é ele que eu uso para verificar meu . Digamos que você queira recuperar seus s de um servidor de nome "vacuum". vacuum está rodando um servidor IMAP, mas não um protegido pelo SSL, e você prefere não transmitir seu username e senha descriptografados. Você pode chamar o ssh com o seguinte comando: $ ssh -L2001:vacuum:143 bob@vacuum 20

21 Este comando diz ao ssh para abrir a porta local 2001 e repassar a conexão para a porta 143 em vacuum, e logar em vacuum como bob para isto. Uma vez que você consiga fazer o login com sucesso no servidor remoto, você tem um tunel ssh para brincar. Para checar seu agora, simplesmente informe seu cliente IMAP para ler seu a partir de localhost, porta O ssh irá fazer uma conexão transparente para o servidor remoto. 4.5 Autenticação de chaves. Enquanto usar o ssh com uma senha é muito mais seguro que o telnet ou rsh, ainda não o é sem algumas armadilhas. Ao mesmo tempo que sua senha é criptografada e mantida segura de outros olhos durante o trânsito pela rede, uma vez que ela chegue no servidor remoto ela é descriptografada novamente para texto plano antes da autenticação. Se o servidor remoto foi comprometido, um atacante pode substituir o sshd por uma versão corrompida que funciona como um cavalo-de-tróia, coletando senhas. Um método muito mais seguro de autenticação é a autenticação baseada em chaves. A autenticação de chaves SSH é baseada nos princípios da criptografia de chave pública. Você tem uma chave privada que você mantém protegida e que é posteriormente criptografada com uma senha de acesso, e você tem uma chave pública que é mantida em cada servidor que você deseja acessar. Quando você desbloqueia sua chave privada e tenta conectar a um servidor para o qual você tenha dado a sua chave pública, sua chave é usada para autenticação em vez de sua senha. Isto significa que suas senhas nunca são enviadas à máquina remota, removendo desta forma toda a possibilidade de ataques de roubo de senha. Aqui temos uma visão básica de como este processo funciona. Quando você conecta-se a um servidor remoto, o servidor checa para ver se sua chave pública está no arquivo authorized_keys da sua conta remota. Se ele está, então o servidor criptografa algum dado aleatório com sua chave pública e o envia a você. Você descriptografa estes dados, criptografa o mesmo com a chave pública do servidor remoto, e manda-os de volta. Se o servidor descriptografar e ver que é idêntico ao que ele enviou originalmente a você, então ele sabe que você é quem você diz ser, e deixa você entrar sem precisar de senha. Para criar um par de chaves ssh (um conjunto de chaves, uma pública, e uma privada), tudo que você precisa fazer é executar o seguinte comando: $ ssh-keygen -t rsa Este comando vai pedir por uma senha para criptografar a chave primária e vai salvar a mesma por padrão em ~/.ssh/identity. Mantenha esta chave cuidadosamente guardada! Se alguém conseguir pegar a chave e a senha que você usou para criptografar a mesma, este alguém pode fazer logon como se fosse você 21

22 em todos os servidores que estiverem configurados para aceitar suas chaves! Depois que o comando é enviado: Generating public/private rsa key pair. Enter file in which to save the key (/home/acc/.ssh/identity): Created directory '/home/acc/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/acc/.ssh/identity. Your public key has been saved in /home/acc/.ssh/identity.pub. The key fingerprint is: e8:96:e0:80:06:b5:e5:e4:22:30:3b:76:47:93:95:73 acc@debianserver Isto é tudo que você precisa fazer! Uma vez que seu keypar tenha sido gerado, você pode pegar o conteúdo de identity.pub e acrescentar ao seu ~/.ssh/authorized_keys no servidor remoto. Uma vez que ele tenha sido acrescentado, tente conectar-se ao servidor remoto novamente. Quando você faz a conexão, em vez de pedir sua senha, ele irá perguntar pela senha que você usou para proteger sua chave privada: $ ssh acc@debian-server Enter passphrase for RSA key 'acc@debian-server': Quando você informar a senha para desbloquear sua chave, o ssh usará então sua chave para fazer sua autenticação com o servidor remoto - sua senha nunca é transmitida, e nenhuma informaçõ é transmitida pela linha que possa ser mais tarde usada por um atacante para obter acesso a sua conta. Desde que você mantenha sua chave privada em segurança, sua conta está segura. A autenticação de chaves tem outros benefícios, como a possibilidade de várias pessoas utilizarem a conta root sem conhecer a senha de root. Simplesmente acrescente as chaves públicas de cada usuário a ~/.ssh/authorized_keys, e elas poderão fazer o login como aquele usuário. ssh-agent A autenticação baseada em chaves também traz outras possibilidades interessantes. Por exemplo, se você está certo que ninguém que não seja de confiança irá usar sua sessão de login atual, você pode usar um programa chamado ssh-agent para manter uma cópia desbloqueada de sua chave privada na memória, de forma que você não precise escrever sua senha toda vez que faz um ssh para algum lugar. É consideravelmente mais seguro que simplesmente usar uma chave privada sem 22

23 senha pois, mesmo quando sua chave está desbloqueada, o ssh-agent não irá dar a chave privada para você - ele somente assina ou descriptografa dados com ela (como no caso do desafio do servidor). Além disso, outras pessoas que estejam logadas em seu servidor (fora o root, é claro) não tem acesso ao seu ssh-agent. O ssh-agent é usado conforme abaixo: $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-XXvknpQ6/agent.23799; export SSH_AUTH_SOCK; SSH_AGENT_PID=23800; export SSH_AGENT_PID; echo Agent pid 23800; A saída do ssh-agent foi feita para ser examinada pelo seu shell para acrescentar as variáveis de ambiente apropriadas. Ou copie e cole a saída na mesma janela de terminal, ou execute algo assim (assumindo que você está usando um shell bash): bash$ eval `ssh-agent` Agent pid 23800; O ssh-agent está agora rodando e as variáveis de ambiente apropriadas foram configuradas de forma que o ssh e os vários utilitários ssh podem agora acessar o mesmo. Uma vez que o agente esteja rodando você pode acrescentar suas chaves privadas com comandos semelhantes ao abaixo: $ ssh-add Need passphrase for /home/acc/.ssh/identity Enter passphrase for acc@debian-server Identity added: /home/acc/.ssh/identity (acc@debian-server) Agora, quando você fizer um ssh a um servidor remoto que está configurado para aceitar sua chave, você não precisa fornecer uma senha, você simplesmente faz a conexão. Obviamente, neste ponto você precisa ser extremamente cuidadoso sobre deixar pessoas que não são de confiançausar sua sessão de login (ssh-add -D faz o ssh-agent esquecer a senha se você precisar deixar o computador). scp O método tradicional de transferência de arquivos de uma máquina para outra por uma rede é usando o protocolo FTP. O FTP, como o IMAP e outros, transfere as informações de autenticação em texto plano, que pode não ser desejável. Infelizmente, devido à estrutura do protocolo FTP, é muito difícil fazer um tunel para o mesmo através de uma conexão ssh. 23

24 O SSH vem com um programa chamado 'scp', que significa 'secure copy' (cópia segura). Ele vem bem a calhar quando você quer transferir arquivos de um computador para outro de forma segura (ele também pode usar compressão se você usar a opção -C, que é boa para transferência de teto ou outro formato de dado que pode ser comprimido). Ele não usa um protocolo separado, mas envia os dados através de uma conexão ssh normal, e por isso ele aceita authorized_keys e conversa com o ssh-agent. O uso do scp é bem simples. A sintaxe é: scp file1 file2 file3... destination Cada um dos argumentos pode ser um arquivo local ou remoto. Por exmeplo, pra compiar seu arquivo.bashr do servidor vacuum para o computador local: $scp vacuum:.bashrc. vacuum:.bashrc é a sintaxe que você usa para copiar de ou para um host remoto host:arquivo. Se você não especificar um diretório, ele utiliza por padrão o diretório home. O destino é dado como ".", que significa o diretório atual. 24

25 5. SERVIDOR SAMBA O Samba é o servidor que permite compartilhar arquivos e acessar compartilhamentos em máquinas Windows. Ele é dividido em dois módulos, o servidor Samba propriamente dito e o smbclient, que permite acessar compartilhamentos em outras máquinas. Usando o Samba, o servidor Linux se comporta exatamente da mesma forma que uma máquina Windows, compartilhando arquivos e impressoras e executando outras funções, como autenticação de usuários. Você pode configurar o Samba até mesmo para tornar-se um controlador de domínio. A primeira versão do Samba, disponibilizada em 1992, foi escrita por Andrew Tridgell, um Australiano que na época era estudante de ciências da computação. Como na época a especificação do SMB utilizada pela Microsoft ainda era fechada, Andrew desenvolveu um pequeno programa, batizado de clockspy, para examinar os pacotes de dados enviados por uma máquina Windows e assim ir implementando uma a uma as chamadas de sistema utilizadas, um trabalho extremamente complexo para ser feito por uma única pessoa. O resultado foi um programa que rodava no Solaris e era capaz de responder às chamadas SMB como se fosse um servidor Windows. Este arquivo ainda pode ser encontrado em alguns dos FTPs do com o nome "server-0.5". O objetivo desta primeira versão era apenas resolver um problema doméstico, interligar um PC rodando o Windows 3.1 ao servidor Solaris. Na época isso já era possível utilizando um dos clientes NFS comerciais para DOS, mas Andrew precisava de suporte a NetBIOS para um aplicativo que pretendia utilizar, o WindX, um servidor X para Windows, que permitia rodar aplicativos via rede a partir do servidor Unix. Até aí o objetivo era apenas fazer o programa funcionar, não criar um sistema de compartilhamento de arquivos. Depois de algum tempo Andrew recebeu um contando que o programa também funcionava com o LanManager da Microsoft, permitindo compartilhar arquivos de um servidor Unix com máquinas rodando o DOS. Andrew só acreditou depois de testar, mas ficou tão maravilhado com o que havia conseguido que criou o 25

26 projeto "NetBios for Unix", e começou a recrutar voluntários através da Usenet. Mais tarde o projeto passou a usar o nome Samba, que foi adotado não em apologia ao Carnaval, mas apenas porque é uma das poucas palavras do dicionário do Aspell que possui as letras S, M e B, de "Server Message Blocks". Em 94 a Microsoft liberou as especificações do SMB e do NetBios, o que permitiu que o desenvolvimento do Samba desse um grande salto, tanto em recursos quanto em compatibilidade, passando a acompanhar os novos recursos adicionados ao protocolo da Microsoft, que novamente deixou de ser aberto. Hoje, além de ser quase 100% compatível com os recursos de rede do Windows 98, NT e 2000, o Samba é reconhecido por ser mais rápido que o próprio Windows na tarefa de servidor de arquivos. Um dos pontos fortes do Samba é que o projeto foi todo desenvolvido sem precisar apelar para qualquer violação de patentes. Todas as chamadas (com exceção das que a Microsoft tornou públicas em 94) foram implementadas monitorando as transmissões de dados através da rede, uma espécie de engenharia reversa que não tem nada de ilegal. É como se você descobrisse como funciona um código de encriptação apenas examinando arquivos encriptados por ele. Matemáticos fazem isso a todo instante e muitas vezes são bem pagos para isso. Graças a este "detalhe", o Samba não corre o perigo de sofrer restrições devido a ações judiciais. Naturalmente já houveram problemas legais com a Microsoft, cujo resultado apenas confirmou esta invulnerabilidade. De qualquer forma, não existem sinais de que a Microsoft pretenda declarar guerra ao Samba, pelo contrário, foi a existência do Samba que permitiu que a Microsoft conseguisse colocar PCs rodando o Windows em muitos nichos onde só entravam Workstations Unix, já que com o Samba os servidores Unix existentes passaram a ser compatíveis com as máquinas Windows. Ou seja, de certa forma o Samba é vantajoso até mesmo para a Microsoft. 5.1 Instalando o Samba O Samba é dividido em dois módulos. O servidor propriamente dito e o cliente, que permite acessar compartilhamentos em outras máquinas (tanto Linux quanto Windows). Os dois são independentes, permitindo que você mantenha apenas o cliente instalado num desktop e instale o servidor apenas nas máquinas que realmente forem compartilhar arquivos. Isto permite melhorar a segurança da rede de uma forma geral. Para instalarmos o servidor do Samba, será necessário o seguinte comando: # apt-get install samba samba-doc swat 26

27 Lembre-se de que você deve instalar todos os pacotes apenas no servidor e em outras máquinas que forem compartilhar arquivos. O Swat ajuda bastante na etapa de configuração, mas ele é opcional, pois você pode tanto editar manualmente o arquivo smb.conf, quanto usar um arquivo pronto, gerado em outra instalação. Nos clientes que forem apenas acessar compartilhamentos de outras máquinas, instale apenas o cliente. 5.2 Cadastrando usuários. Depois de instalado, o próximo passo é cadastrar os logins e senhas dos usuários que terão acesso ao servidor. Esta é uma peculiaridade do Samba: ele roda como um programa sobre o sistema e está subordinado às permissões de acesso deste. Por isso ele só pode dar acesso para usuários que, além de estarem cadastrados no Samba, também estão cadastrados no sistema. Existem duas abordagens possíveis. Você pode criar usuários "reais" usando o comando adduser ou um utilitário como o "user-admin" (disponível no Fedora e no Debian, através do pacote gnome-system-tools). Ao usar o adduser, o comando fica: # adduser maria Uma segunda opção é criar usuários "castrados", que terão acesso apenas ao Samba. Esta abordagem é mais segura, pois os usuários não poderão acessar o servidor via SSH ou Telnet, por exemplo, o que abriria brecha para vários tipos de ataques. Neste caso, você cria os usuários adicionando os parâmetros que orientam o adduser a não criar o diretório home e manter a senha desativada até segunda ordem: # adduser --disabled-login --no-create-home maria Isto cria uma espécie de usuário fantasma que, para todos os fins, existe e pode acessar arquivos do sistema (de acordo com as permissões de acesso), mas, por outro lado, não pode fazer login (nem localmente, nem remotamente via SSH), nem possui diretório home. De qualquer uma das duas formas, depois de criar os usuários no sistema, você deve cadastrá-los no Samba, usando o comando "smbpasswd -a", como em: # smbpasswd -a maria Se você mantiver os logins e senhas sincronizados com os usados pelos usuários nos clientes Windows, o acesso aos compartilhamentos é automático. Caso os logins ou senhas no servidor sejam diferentes, o usuário precisará fazer login ao acessar. 27

28 Um detalhe importante é que, ao usar clientes Windows 95 ou 98, você deve marcar a opção de login como "Login do Windows" e não como "Cliente para redes Microsoft" (que é o default) na configuração de rede (Painel de controle > Redes). Depois de criados os logins de acesso, falta agora apenas configurar o Samba para se integrar à rede e compartilhar as pastas desejadas; trabalho facilitado pelo Swat. A segunda opção é editar manualmente os arquivos de configuração do Samba, o "/etc/samba/smb.conf", como veremos mais adiante. Neste caso, o ideal é começar a partir de um arquivo pré-configurado, alterando apenas as opções necessárias. 5.3 Configurando o Samba usando o Swat O Samba pode ser configurado através do Swat, um utilitário de configuração via web, similar ao encontrado nos modems ADSL. Isso permite que ele seja acessado remotamente e facilita a instalação em servidores onde o X não está instalado. Esta mesma abordagem é utilizada por muitos outros utilitários, como o Webmin e o Pagode. Manter o X instalado e ativo num servidor dedicado é considerado um desperdício de recursos, por isso os desenvolvedores de utilitários de configuração evitam depender de bibliotecas gráficas. Deste modo, mesmo distribuições minimalistas podem incluí-los. No Debian, Slackware e também no Gentoo, o Swat é inicializado através do inetd. A função do inetd e xinetd é parecida, eles monitoram determinadas portas TCP e carregam serviços sob demanda. Isto evita que utilitários que são acessados esporadicamente (como o Swat) precisem ficar ativos o tempo todo, consumindo recursos do sistema. Apesar disso, a configuração dos dois é diferente: no caso das distribuições que usam o inetd, você ainda precisa adicionar (ou descomentar) a linha abaixo no arquivo de configuração do inetd, o "/etc/inetd.conf": swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat Para que a alteração entre em vigor, reinicie o inetd com o comando: # /etc/init.d/inetd restart Para acessar o Swat, basta abrir um Browser disponível e acessar o endereço No prompt de login, forneça a senha de root para acessar. Ao abrir o Swat, você verá um menu com vários links para a documentação disponível sobre o Samba, que você pode consultar para se aprofundar no sistema. Na parte de cima, estão os links para as seções da configuração, que é o que nos interessa. 28

29 Na seção Password, você pode cadastrar usuários, substituindo o uso manual do comando "smbadduser -a". Neste caso, você precisará primeiro cadastrar os usuários utilizando comando adduser; o Swat apenas cadastra os usuários no Samba. Em seguida, acesse a seção "Globals", que engloba todas as configurações de rede e acesso. Nas opções "workgroup" e "netbios name", você deve colocar o nome do 29

30 computador e o grupo de trabalho a que ele pertence, como faria numa máquina Windows. Você pode tanto utilizar o mesmo grupo de trabalho em todas as máquinas da rede, quanto agrupar suas máquinas em grupos distintos como "diretoria", "vendas", etc. A opção "netbios aliases" permite criar "apelidos" para o servidor, de modo de que ele possa ser acessado por mais de um nome. Usando um alias, o servidor realmente aparece duas vezes no ambiente de rede, como se fossem duas máquinas. Em geral isso acaba confundindo mais do que ajudando, mas pode ser útil em algumas situações, quando, por exemplo, um servidor é desativado e os compartilhamentos movidos para outro. O novo servidor pode responder pelo nome do servidor antigo, permitindo que os usuários que não foram avisados da mudança continuem acessando os compartilhamentos. A seguir temos a opção "interfaces", que permite limitar os acessos ao servidor se você tiver mais de uma placa de rede. É o caso, por exemplo, de quem acessa via ADSL ou cabo e possui uma segunda placa de rede para compartilhar a conexão com os micros da rede local. Nestes casos a placa da web será reconhecida como eth0, enquanto a placa da rede local será reconhecida como eth1, por exemplo. Você pode, então, preencher o campo com o endereço da placa da rede local (eth1), assim o Samba só aceitará conexões vindas dos micros da rede local, descartando automaticamente todas as tentativas de acesso vindas da internet. Caso o campo permaneça vazio, o Samba permite acessos vindos de todas as placas de rede, e é necessário bloquear os acessos provenientes da internet usando o firewall. 30

31 Na seção Security Options chegamos a uma das decisões mais importantes, decidir entre entre utilizar segurança com base no login do usuário (user) ou com base no compartilhamento (share). A opção share oferece um nível de segurança semelhante ao de uma máquina Windows 98. Os compartilhamentos podem ser acessados por todos os usuários, através da conta guest. Em compensação, esta opção é a mais simples de configurar e pode ser útil em pequenas redes onde não há necessidade de segurança. A opção user é a mais recomendável, pois permite especificar exatamente quais usuários terão acesso a cada compartilhamento, como num servidor NT ou Windows Naturalmente, para que isso funcione, é necessário que você tenha registrado todos os usuários no Linux e no Samba (como vimos anteriormente), e que os clientes Windows efetuem login na rede usando estes mesmos logins e senhas, ou os forneçam na hora de acessar os compartilhamentos. Escolhendo este modo, as permissões de acesso aos compartilhamentos do samba ficam condicionadas às permissões de acesso de cada usuário. Por exemplo, se você compartilhar a pasta /home/maria/arquivos, por default apenas a usuária maria terá permissão para gravar novos arquivos e alterar o conteúdo da pasta. Para que outros usuários tenham acesso à pasta, você deve dar permissão a eles, criando um novo grupo e dando permissão de escrita para os integrantes do grupo ou adicionando os demais usuários no grupo "maria" (que é criado juntamente com o login de acesso) e configurando as permissões de acesso de forma que o grupo possa escrever na pasta. Se você não está tão preocupado com a segurança, pode fazer do jeito "fácil", alterando a opção "outros" nas permissões de acesso da pasta, que dá acesso a todo mundo. Isto faz com que qualquer usuário local do sistema (ou logado via SSH) tenha acesso aos arquivos da pasta, mas não permite necessariamente que outros usuários do Samba possam acessar, pois neste caso ainda são usadas as permissões de acesso no Samba. Ou seja, é necessário fazer com que os usuários do grupo, ou todos os usuários do sistema possam escrever na pasta, evitando que as permissões do sistema conflitem com as permissões configuradas no Samba. Se configuro o Samba para permitir que o usuário "joao" possa escrever no compartilhamento, mas a configuração das permissões da pasta compartilhada não permitem isso, o Joao vai continuar sem conseguir escrever. Ao criar compartilhamentos no Samba, é preciso se preocupar com as duas coisas. Mais abaixo, temos a opção Encrypt Password. Ela também é importantíssima, e deve ser configurada de acordo com a versão do Windows que rodar nas máquinas 31

32 clientes. O Windows 95 original não suporta encriptação de senhas, por isso só poderá se conectar ao servidor caso a opção seja configurada com o valor "No". Porém, o Windows 95 OSR/2, Windows 98/SE/ME, Windows NT, Windows 2000 e Windows XP utilizam senhas encriptadas, então, ao utilizar máquinas com qualquer um destes sistemas (que é o mais provável) a opção deve ser configurada como "Yes", caso contrário o Samba simplesmente não conseguirá conversar com as máquinas Windows. A partir do Samba 3 existe a opção de fazer com que o próprio Samba mantenha as senhas dos usuários sincronizadas em relação às senhas dos mesmos no sistema. Antigamente, sempre que você alterava a senha de um usuário no Samba, usando o "smbpasswd", precisava alterar também a senha do sistema, usando o comando "passwd". As duas senhas precisam ficar em sincronismo, do contrário caímos no problema das permissões, onde o Samba permite que o usuário acesse o compartilhamento, mas o sistema não permite que o Samba acesse os arquivos no disco. Para ativar este recurso, ative a opção "unix password sync" no Swat. Originalmente, esta opção fica desativada e aparece apenas dentro das opções avançadas. Para chegar até ela você deve clicar no botão "Change View To: Advanced" no topo da tela. Depois de alterar, clique no Commit Changes". Para que tudo funcione, é necessário que as opções "passwd program" e "passwd chat" estejam configuradas com (respectivamente) os valores: "/usr/bin/passwd %u" e "*Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n.". Estes já são os valores padrão no Swat, mas não custa verificar. 32

33 A opção "Hosts Allow" deve incluir os endereços IP de todos os computadores que terão permissão para acessar o servidor. Se quiser que todos os micros da rede tenham acesso, basta escrever apenas a primeira parte do endereço IP, como em " ", onde todos os endereços dentro do escopo serão permitidos. Se for incluir mais de um endereço ou mais de um escopo de endereços, separe-os por um espaço, como: " , , ". Caso o campo permaneça vazio, a opção fica desativada, e todos os micros que tiverem acesso ao servidor Samba poderão acessar. A opção "Hosts Deny" por sua vez permite especificar máquinas que não terão permissão para acessar o servidor. Você pode usar o Hosts Deny para estabelescer exceções ao dito na opção Hosts Allow. Por exemplo, imagine que você queira que toda a rede local, que usa a faixa 33

34 x, tenha acesso ao servidor, com exceção dos endereços e Neste caso, a configuração ficaria assim: Hosts Allow: Hosts Deny: , Numa rede Windows, uma das máquinas fica sempre responsável por montar e atualizar uma lista dos compartilhamentos disponíveis e enviá-la aos demais, conforme solicitado. O host que executa esta função é chamado de "Master Browser". Na seção Browse Options, a opção "OS Level" permite especificar qual chance o servidor Linux terá de ser o Master Browser do grupo de trabalho ou domínio. Sempre que você estiver configurando o Samba para ser o servidor principal, é desejável que ele seja o master browser. Para isso, configure esta opção com um valor alto, 100 por exemplo, para que ele sempre ganhe as eleições. O default dessa opção é 20, que faz com que ele perca para qualquer máquina Windows NT, Windows 2000 ou Windows XP. Para completar, deixe a opção "Local Master" e "Preferred Master" como "Yes". A configuração do OS Level é muito importante. Caso não seja o Master Browser, você poderá ter problemas para acessar seu servidor Linux a partir de outras máquinas Windows, principalmente rodando o NT/2000/XP. Com o valor 100, sempre que uma das máquinas Windows tentar ser o Master Browser da rede, o Samba convocará uma nova eleição e a máquina Linux sempre ganhará. Abaixo, deixe a opção Wins Support ativada (Yes). A opção Wins Server deve ser deixada em branco, a menos que exista na rede algum servidor Wins (rodando o NT server ou o 2K server) ao qual o servidor Linux esteja subordinado. Caso o único servidor seja a máquina Linux, você pode configurar as máquinas 34

35 Windows para utilizá-la como servidor Wins, para isto basta colocar o seu endereço IP no campo "Servidor Wins" na configuração de rede das estações. Terminando, pressione o botão "Commit Changes" no topo da tela para que as alterações sejam salvas no arquivo "/etc/samba/smb.conf". Uma observação importante é que o Swat lê o arquivo smb.conf ao ser aberto, lendo as opções configuradas e mostrando-as na interface, mas gera um novo arquivo sempre que você clica no "Commit Changes". Ao ler o arquivo, ele procura por trechos específicos de texto, ignorando tudo que for diferente. Isso faz com que ele remova qualquer tipo de comentário incluído manualmente no arquivo. Em geral, quem tem o hábito de editar manualmente o smb.conf, acaba nunca usando o Swat e vive-versa. Depois de cadastrar os usuários no sistema e no Samba e configurar a seção Globals, falta apenas configurar as pastas que serão compartilhadas com as estações, através da seção "Shares". Cada usuário válido cadastrado no sistema possui automaticamente um diretório home. Estas pastas ficam dentro do diretório /home e podem ser usadas para guardar arquivos pessoais, já que, a menos que seja estabelecido o contrário, um usuário não terá acesso à pasta pessoal do outro. Além dos diretórios home, você pode compartilhar mais pastas de uso geral. Para criar um compartilhamento, basta escrever seu nome no campo no topo da tela e clicar no botão "Create Share". Depois de criado um compartilhamento, escolha-o na lista e clique no botão "Choose 35

36 Share" para configurá-la. Você verá uma lista de opções, contendo campos para especificar usuários válidos e inválidos, usuários que podem ou não escrever no compartilhamento, nomes ou endereços de máquinas entre outras opções. O campo "path" é o mais importante, pois indica justamente qual pasta do sistema será compartilhada. O nome do compartilhamento diz apenas com que nome ele aparecerá no ambiente de rede, que não precisa necessariamente ser o mesmo nome da pasta. A opção "comment" permite que você escreva um breve comentário sobre a pasta que também poderá ser visualizado pelos usuários no ambiente de rede. Este comentário é apenas para orientação, não tem efeito algum sobre o compartilhamento. A opção "read only" determina se a pasta ficará disponível apenas para leitura (opção Yes) ou se os usuários poderão também gravar arquivos (opção No). Você pode também determinar quais máquinas terão acesso ao compartilhamento através das opções "Hosts Allow" e "Hosts Deny". As configurações feitas aqui subscrevem as feitas na seção global. Se, por exemplo, a máquina possui permissão 36

37 para acessar o sistema, mas foi incluída na campo Hosts Deny do compartilhamento programas, ela poderá acessar outros compartilhamentos do sistema, mas não o compartilhamento programas especificamente. A opção "browseable" permite configurar se o compartilhamento aparecerá entre os outros compartilhamentos do servidor no ambiente de rede, ou se será um compartilhamento oculto, que poderá ser acessado apenas por quem souber que ele existe. Isso tem uma função semelhante a colocar um "$" numa pasta compartilhada no Windows 98. Ela fica compartilhada, mas não aparece no ambiente de rede. Apenas usuários que saibam que o compartilhamento existe conseguirão acessá-lo. Esta opção tem efeito apenas sobre os clientes Windows, pois no Linux a maior parte dos programas clientes (como o Smb4k) mostram os compartilhamentos ocultos por padrão. Finalmente, a opção "available" especifica se o compartilhamento está ativado ou não. Você pode desativar temporariamente um compartilhamento configurando esta opção como "No". Fazendo isso, ele continuará no sistema e você poderá torná-lo disponível quando quiser, alterando a opção para "Yes". Um detalhe importante é que os usuários só terão permissão para acessar pastas que o login permite acessar. Por exemplo, no Linux o único usuário que pode acessar a pasta /root é o próprio root, ou outro autorizado por ele. Mesmo que você compartilhe a pasta root através do Samba, os demais usuários não poderão acessá-la. Para editar as permissões de uma pasta, basta abrir o gerenciador de arquivos e, nas propriedades da pasta, acessar a guia "Permissões". As permissões podem ser dadas apenas ao usuário, para todos os usuários pertencentes ao grupo do usuário dono da pasta, ou para todos os usuários. A opção "Aplicar mudanças a todas as subpastas e seus conteúdos" deve ficar marcada para que as permissões sejam aplicadas também às subpastas. Terminadas as configurações, o servidor já irá aparecer no ambiente de rede, como se fosse um servidor Windows. Os compartilhamentos podem ser acessados de acordo com as permissões que tiverem sido configuradas, mapeados como unidades de rede, entre outros recursos. Para compartilhar uma impressora já instalada na máquina Linux, o procedimento é o mesmo. Dentro do Swat, acesse a seção printers, escolha a impressora a ser compartilhada (a lista mostrará todas as instaladas no sistema), configure a opção available como "yes" e configure as permissões de acesso como vimos anteriormente. 5.4 Configurando o Samba manualmente - /etc/samba/smb.conf Toda a configuração do Samba, incluindo as configurações gerais do servidor, 37

38 impressoras e todos os compartilhamentos, é feita num único arquivo de configuração, o "/etc/samba/smb.conf". Programas de configuração, como o Swat, simplesmente lêem este arquivo, "absorvem" as configurações atuais e depois geram o arquivo novamente com as alterações feitas. Isto permite que o Swat coexista com a edição manual do arquivo. Como o formato é bastante simples e conciso, muitas vezes é mais rápido e até mais simples editar diretamente o arquivo do que através do Swat. O smb.conf possui as mesmas seções mostradas no swat: global, homes, printers, etc. Para iniciar a edição do arquivo de configuração do smb.conf utilisamos o seguinte comando: # vi /etc/samba/smb.conf Confira abaixo um exemplo do smb.conf e em seguida a explicaçao de cada parâmetro presente nas seçoes: [global] comment = Servidor SAMBA workgroup = EMPRESA security = user os level = 100 announce as = NT Server domain logons = yes logon script = %U.bat logon path = \\%L\Profiles\%U domain master = yes local master = yes preferred master = yes guest account = nobody # wins server = wins support = yes keep alive = 20 debug level = 3 winpopup command = csh -c ''xedit %s;rm %s'' & log file = /var/log/samba_log.%u null passwords = no unix password sync = yes socket options = IPTOS_LOWLAY TCP_NOLAY printing = bsd printcap name = /etc/printcap 38

39 load printers = yes hosts allow = hosts deny = [homes] comment = Pastas dos Usuarios public = no browseable = yes writeable = yes hosts deny = [printers] comment = Impressoras Linux public = no browseable = yes printable = yes read only = yes create mode = 0700 path = /var/spool/samba admin users = admin, usuario1 [netlogon] comment = Compartilhamento de Scripts path = /etc/scripts public = no browseable = yes writeable = no [diretoria] comment = Grupo Diretoria path = /home/diretoria public = no browseable = yes writeable = yes write list force create mode = 0777 force directory mode = 0777 [comercial] comment = Grupo Comercial path = /home/comercial public = yes browseable = yes 39

40 writeable = yes write list read list force create mode = 0777 force directory mode = 0777 [transf] comment = Area de Transferencia path = /home/transf public = yes browseable = yes writeable = yes write list force create mode = 0777 force directory mode = 0775 max disk size = 200 [oculto$] comment = Especifico do Admin path = /home/admin/oculto copy = homes max connections = 1 Parâmetros Funçoes comment Comentário para este Host na Rede. workgroup Especifica o Domínio ou Workgroup a que o Host pertence na Rede. security Por padrao o SAMBA utiliza a segurança a nível de usuário (security = user), mas existem outras opçoes: security = share -> Senhas de acesso serao solicitadas por cada recurso compartilhado e nao por usuário, ou seja, cada diretório ou impressora poderá ter uma senha única conhecida pelos usuários autorizados. security = user -> As permissoes sao dadas de acordo com o login do usuário, ou através dos grupos (@grupo). security = server -> O SAMBA tentará validara senha do usuário enviando os dados para outro servidor SMB, como outro servidor SAMBA ou um servidor Windows. Deve-se incluir o parâmetro.password server = x.x.x.x. na seçao [global] do smb.conf. security = domain -> Usado se o Host for adicionado a um 40

41 Domínio Windows através do comando smbpasswd. Neste caso as informaçoes de usuário e senha serao enviadas para o PDC da rede, exatamente como o servidor NT faria. Note que é necessário que a conta do usuário exista tanto no Linux quanto no servidor primário. os level Este parâmetro nao é obrigatório se voce nao possui um servidor Windows na rede, mas deve ser usado caso tenha um ou mais. A variável é um número de 1 a 255, onde 65 é a mesma variável utilizada pelo servidor Windows. Especifique um número maior que este (como 100 por exemplo) para garantir que o servidor SAMBA seja eleito na escolha de validaçao do login das estaçoes. announce as Permite especificar o tipo de servidor NetBios (nmbd) que será divulgado na rede. As opçoes aceitas pelo SAMBA: "NT Server", "NT Workstation", "Win95" ou "WfW". domain logons Usado para validar o login na rede, apenas para estaçoes Windows. logon script Indica qual arquivo de logon script será executado para os usuários. A variável %u corresponde ao usuário na rede. Deve também ser criado um compartilhamento de nome [netlogon] apontando para o diretório dos scripts. logon path Indica o caminho do perfil remoto do usuário. A variável %L corresponde ao nome do servidor NetBios (que pode ser o próprio SAMBA). O logon path é útil quando usuários costumam efetuar logon em mais de um Host na rede, pois seu perfil é trazido com o logon. No caso do exemplo, o diretório "Profiles" deve conter os scripts (em formato Microsoft usando NET USE e etc) e os scripts devem ser criados com o notepad do Windows por exemplo, a fim de conservar o formato do arquivo. domain master Indica se o Host será o Domain Master Browser da rede inteira (WAN). local master Indica se o Host será o Master Browser da rede local. preferred master Este parâmetro força a eleiçao do SAMBA como Master Browser para o workgroup. É recomendável utilizar este parâmetro em conjunto com o.domain master = yes. para garantir a eleiçao. Mas tome cuidado: se voce possui uma rede com servidores Windows e SAMBA e já possui um 41

42 servidor como Domain Master, nao use esta opçao e deixe o parâmetro.os level = 65. para haver equilíbrio. guest account O SAMBA trabalha melhor em redes Microsoft com a existencia de uma conta guest (visitante em ingles). Por padrao a conta usada é.nobody. wins server Indica qual o servidor de Wins da rede. Se o próprio Host for o servidor de Wins entao nao utilize este parâmetro, pois haverá um loop e o sistema travará! wins support Permite ao SAMBA ser o servidor de Wins na rede. Isto significa que o SAMBA terá uma tabela com o ambiente completo da rede, garantindo que as estaçoes tenham acesso a estas informaçoes e ganho em velocidade para encontrar e acessar os compartilhamentos e impressoras. O Wins Server deve ser especificado na configuraçao de rede (TCP/IP) das estaçoes, que é o endereço IP do servidor. keep alive Como máquinas rodando Windows tendem a travar de tempos em tempos, este parâmetro é usado para verificar o estado da conexao, evitando tráfego desnecessário na rede. Também pode ser usado para estaçoes Linux. debug level Parâmetro usado para dar flexibilidade a configuraçao do sistema. Permite ao SAMBA trabalhar corretamente com algumas situaçoes de erro, por exemplo. winpopup command Especifica qual commando será executado quando o servidor receber mensagens Winpopup. Aqui, muitas opçoes podem ser usadas de acordo com a preferencia do Administrador. Se sua rede utiliza mensagens deste tipo, é interessante definir um comando para o parâmetro, evitando assim possíveis mensagens de erro para quem enviou a mensagem ao servidor. log file Indica o arquivo de log do SAMBA. A variável %u corresponde ao nome de logon do usuário. null passwords Indica se será ou nao possível que usuários tenham senha nula de logon (logon sem senha). unix password sync Se este parâmetro for ativado (= yes) entao clientes SMB (como estaçoes Windows) poderao trocar sua senha de login. socket options Este parâmetro permite configuraçoes extras para o 42

43 protocolo, possibilitando uma melhor performance do servidor em lidar com os pacotes na rede. printing Indica qual o sistema de impressao padrao utilizado pelo Linux. printcap name Indica o arquivo impressoras. load printers Disponibiliza as impressoras para a rede. hosts allow Indica quais máquinas tem acesso ao servidor SAMBA. Pode-se utilizar o endereço IP ou o nome da máquina. Para garantir acesso a toda uma rede por exemplo, escreva: "hosts allow = ". hosts deny Como em "hosts allow", mas para restringir o acesso ao servidor SAMBA. para busca das definiçoes das A seçao [homes] define os parâmetros para as pastas pessoais dos usuários na rede (home dir): Parâmetros Funçoes comment Comentário para este compartilhamento. public Também conhecido como.guest ok., permite ou nao acesso de outros usuários. browseable Define se o compartilhamento será ou nao visível para o Ambiente de Rede. Estaçoes Windows95 versao C nao aceitam esta opçao, onde uma possível soluçao é utilizar o nome do compartilhamento seguido de $ (teste$ por exemplo), como faz-se no Windows. writeable Indica se o usuário poderá ou nao ecrever em sua pasta pessoal (home dir). As demais seçoes correspondem a compartilhamentos presentes na rede. Os parâmtros abaixo sao apenas alguns dos possíveis: Parâmetros comment Funçoes Comentário para o compartilhamento. 43

44 path Caminho do diretório compartilhado writeable Indica se será ou nao possível criar ou excluir arquivos ou diretórios do compartilhamento. public / guest ok Indica se será ou nao permitido o acesso de outros usuários. browseable Define se o compartilhamento será ou nao visível para o Ambiente de Rede. write list Define os usuários e/ou grupos com acesso de escrita no compartilhamento. Para mais de um usuário, separe os nomes por vírgula (user1, user2, etc) e para grupos antes do nome do grupo. read list Como em.write list., mas define quem terá permissao de apenas leitura. force create mode Diz ao SAMBA para forçar o tipo de permissao dos arquivos criados (o mesmo que usar o chmod). Esta permissao tem menor prioridade que os parâmetros.write list. e.read list.. force directory mode O mesmo que.force create mode., mas para os diretórios criados no compartilhamento. admin users Indica quais sao os usuários com permissao completa para o compartilhamento (permissao de root). copy Permite copiar os parâmetros de outra seçao, como um template por exemplo, útil se utiliza compartilhamentos semelhantes. Para alterar parâmetros basta informá-los na seçao atual. hosts allow Indica quais máquinas podem acessar o compartilhamento. Pode-se utilizar o endereço IP ou o nome da máquina. Para garantir acesso a toda uma rede classe C por exemplo, escreva: "hosts allow = ". hosts deny Como em "hosts allow", mas para restringir o acesso ao compartilhamento. max connections Permite especificar o número máximo de conexoes simultâneas ao compartilhamento. max disk size Permite especificar qual o limite de espaço em disco que o compartilhamento pode utilizar. Este valor é definido em Mb 44

45 (megabytes). A próxima apresenta variáveis que podem ser usadas em parâmetros: Variáveis Funçoes %S Nome do Serviço (compartilhamento) atual. %u Nome do usuário. %g Nome do grupo. %H Nome do diretório pessoal do usuário (home dir). %m Nome da máquina cliente fornecido pelo NetBios. %L Nome do servidor NetBios, permitindo que a configuraçao desejada seja alterada de acordo com o cliente que vai acessar o sistema. %M Nome Internet da máquina cliente. %a Sistema Operacional da máquina remota, onde os reconhecidos sao WfW, WinNT e Win95. %I O endereço IP da máquina cliente. %T Data e horário. Exemplo de um smb.conf básico para teste e implementação: [global] workgroup = Workgroup server string = Samba server ;wins support = no ###debugging### log file = /var/null syslog only = no security = share guest account = nobody [homes] 45

46 browseable = no creat mask = 0700 directory mask = 0700 ###file sharing### [Compartilhado] path =/mnt/hdb/mpl/ browseable = yes security = user public = yes writable = yes 5.5 O smbclient Da mesma forma que o SAMBA permite que o Linux atue como servidor em redes Microsoft, ele também permite atuar como estaçao, sem que nenhuma configuraçao seja necessária no servidor Microsoft. Com o smbclient é possível acessar dados em um servidor Windows (lembra o comando net da Microsoft, mas os comandos utilizados sao similares aos de FTP). Ele pode ser usado para receber e enviar arquivos, listar diretórios, navegar pelos diretórios, renomear e apagar arquivos, entre outros. Diretórios compartilhados por um servidor SAMBA sao acessados da mesma forma. Para verificar quais compartilhamentos estao disponíveis em um determinado Host, execute: #/usr/sbin/smbclient -L host_desejado A resposta será uma lista de serviços, ou seja, nomes de dispositivos ou impressoras que podem ser compartilhados com os usuários na rede. A menos que o servidor SMB nao tenha itens de segurança configurados, será solicitada uma senha antes de mostrar as informaçoes. Exemplo: #smbclient -L servidor1 A resposta será semelhante a: Server time is Fri Dec 22 15:58: Timezone is UTC+10.0 Password: Domain=[EMPRESA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] Server=[servidor1] User=[] Workgroup=[EMPRESA] Domain=[] 46

47 Sharename Type Comment ADMIN$ Disk Remote Administration Public Disk Public C$ Disk Default Share Print$ Disk Printer Control Para acessar uma pasta compartilhada, basta especificar o caminho na rede, conforme abaixo: $smbclient //maquina/pasta1 senha Onde "senha" é literalmente a senha de acesso. Se o caminho estiver correto a resposta será algo como: Server time is Fri Dec 22 16:01: Timezone is UTC+10.0 Domain=[EMPRESA] OS=[Windows NT 4.0] Server=[NT LAN Manager] smb:\> Digite help para obter ajuda sobre os comandos do smbclient. 47

48 6. SERVIDOR DNS BIND9 Boa parte da usabilidade da Internet vem da facilidade que temos para localizar um computador conectado. Apesar da maioria dos computadores só conseguirem localizar outros através de endereços IP, nós humanos podemos localizá-los facilmente através de um nome inteligível. É o que acontece, por exemplo, quando acessamos a página oficial do sistema operacional Linux através do nome ao invés de precisarmos usar o número que, cá entre nós, é bem mais feio. Esta conversão de nome para números é feita automaticamente através do mecanismo de DNS (sigla de Domain Name System). Os administradores de rede gostam de colocar uns nomes um tanto quanto criativos nas suas máquinas. Alguns usam nomes de cidades da região em que a LAN está localizada (como Olinda, Buíque e Jaboatão). Outros gostam de usar nomes de personagens de quadrinhos como Mônica, Cebolinha, Cascão, Magali. Outros preferem nomes de grandes nomes da música brasileira como Raul Seixas, Elis Regina e Tom Jobim. Assim como o DNS é usado na Internet, pode também ser usado em uma rede interna para facilitar sua utilização. Isso permite, por exemplo que ao invés de digitarmos ssh , possamos digitar simplesmente ssh raulseixas, uma seqüência bem mais fácil de ser memorizada. Vamos aprender aqui a configurar uma máquina em uma rede para saber localizar as demais pelo nome, ou seja, servir de "telefonista" para nossa rede. Ela vai receber pedidos do tipo "Estou querendo falar com raulseixas. Qual o endereço dele?" e vai responder "Para falar com o maluco beleza, tente ". Neste artigo vamos utilizar o programa named, que é parte do pacote BIND, disponível em praticamente todas as distribuições Linux. Ele é o programa que vai ficar rodando para receber requisições de mapeamento de nomes em endereços IP e, claro, respondê-las adeqüadamente. 6.1 Instalação do BIND9 Obter e instalar o named em uma máquina Debian é fácil. Basta procurar em seu gerenciador de pacotes preferidos pelo pacote bind9. Não é obrigatório, mas é sempre bom obter a documentação, que está no pacote bind9-doc. Para instalar usando o apt, podemos fazer como no exemplo. # apt-get install bind9 bind9-doc dnsutils O apt vai então nos mostrar algumas mensagens e instalar os pacotes que queremos. Depois que ele completar seu trabalho, já teremos nosso servidor DNS 48

49 funcionando. Para tirar a prova, podemos pedir a ele o endereço para alguns nomes. Para isso vamos usar o dig, um programa que faz parte do pacote dnsutils. Poderíamos também editar o arquivo /etc/resolv.conf para utilizar o novo servidor de nomes, mas é mais higiênico fazermos isso somente no final, quando tudo estiver funcionando perfeitamente. # dig ; <<>> DiG <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEAR<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN A ;; AUTHORITY SECTION: linux.org. linux.org IN IN NS NS ns0.aitcom.net. ns.invlogic.com. ;; ;; ;; ;; Query time: 7 msec SERVER: #53( ) WHEN: Sun Dec 11 01:45: MSG SIZE rcvd: 104 O que pedimos foi para o programa dig obter o endereço IP da máquina de nome utilizando para isso o servidor de nomes localizado em (este é o endereço da máquina onde o comando foi executado, ou seja, seu próprio computador). Ele nos respondeu que o endereço é (olhe a seção ANSWER SECTION). Note que não informamos ao nosso servidor em lugar nenhum o endereço IP da máquina mesmo assim ele conseguiu nos fornecer um número. Ele foi capaz de fazer isso porque se comunicou com uma das máquinas chamadas de servidores-raiz. O endereço IP dessas máquinas fica, em um sistema Debian, gravado em um arquivo chamado, sugestivamente, de db.root. O problema é que esses endereços podem mudar com o tempo, apesar disso não ser muito freqüente. Da última vez que instalei o pacote bind9, ele veio com um db.root de Felizmente, é fácil atualizar o arquivo. Só precisamos usar o dig (se você não instalou ainda, faça agora). Vamos pedir a ele que obtenha a localização atual dos servidores-raiz e vamos gravar a resposta em um arquivo. 49

50 Devemos estar dentro do diretório de configuração do bind para que funcione perfeitamente para isso entre em /etc/bind/. # cd /etc/bind/ # dig > db.root.new Isso vai gravar a resposta do servidor a.root-servers.net. no arquivo db.root.new. Se este servidor não responder, tente um dos outros (b.root-servers.net, c.root.servers.net e assim por diante). Se estiver curioso, você pode dar uma olhada no conteúdo do arquivo. O próximo passo é substituir o arquivo antigo pelo novo e reiniciar o programa servidor de nomes para que ele leia o novo arquivo. Note que essas instruções são para uma instalação Debian padrão, sua configuração pode ser um pouco diferente. # mv db.root db.root.old # mv db.root.new db.root # /etc/init.d/bind9 restart Stopping domain name service: named. Starting domain name service: named. Com isso nosso servidor DNS já pode resolver os nomes dos computadores na Internet. Precisamos disso porque vamos substituir o servidor DNS antigo (que deve ser uma máquina do seu provedor de Internet) por um novo e queremos que ele continue sendo capaz de fazer o que o antigo fazia. Porém essa configuração ainda não inclui os nomes das máquinas internas, para estas ainda precisamos dos endereços IP. Para "batizar" nossas máquinas vamos precisar de um domínio interno. 6.2 Configurando um domínio. O serviço de nomes (DNS) é organizado hierarquicamente em domínios, deste modo isola-se o conjunto de nomes pertencentes a um domínio dos nomes de outro. O controlador do domínio pode adicionar quaisquer nomes dentro deste domínio e não haverá perigo de colisão de nomes acidental. Estes nomes podem ser subdomínios (nomes que aceitam mais nomes subordinados) ou hosts (nomes de máquinas específicas, sem subordinados). Para ficar mais claro, vamos tomar como exemplo o domínio debianfordummies.org. Subordinados a este domínio podem ser registrados vários sub-nomes como, por exemplo, o o ftp.debianfordummies.org e o mail.debianfordummies.org. Vamos usar um domínio para identificar nossas máquinas. Neste exemplo, todas 50

51 elas estarão abrigadas sob o mesmo domínio, mas é fácil registrar mais de um domínio uma vez que você pega o jeito. Recomenda-se utilizar um domínio controlado por você, para evitar bloquear acidentalmente outro domínio externo. Daqui em diante vamos utilizar um domínio chamado de meudominio.org.br, que ainda não existe. Para fazer isso no nosso sistema Debian, vamos precisar modificar um pouco o conteúdo do diretório /etc/bind. Primeiramente vamos adicionar uma zona correspondente ao nosso domínio, adicionando o trecho abaixo ao final do arquivo named.conf.local. # vi /etc/bind/named.conf.local zone "meudominio.org.br" { type master; file "/etc/bind/db.meudominio"; }; A segunda linha (type master) diz ao named que ele possui os endereços para a zona meudominio.org.br e não precisa consultar ninguém para responder por ela. A terceira indica o caminho do arquivo no sistema de arquivos local onde ele vai encontrar o mapeamento de nomes para endereços IP. É este arquivo que vamos criar agora. Digamos que na nossa rede temos serviços web e ftp localizados na máquina , um servidor de nomes na máquina e um serviço de numa terceira máquina Esquematizando, temos o mapeamento abaixo. Ftp ----> > servidor ftp www --> > servidor web ns -----> > servidor dns secundario mail ----> > servidor de O que precisamos fazer é traduzir este mapeamento para a linguagem entendida pelo named. Crie o arquivo /etc/bind/db.meudominio com o seguinte conteúdo. # vi /etc/bind/db.meudominio $TTL IN SOA ns.meudominio.org.br. minhamaquina.meudominio.org.br. ( ; Serial ; Refresh 51

52 ) meudominio.org.br. ftp.meudominio.org.br. ns.meudominio.org.br. meudominio.org.br. mail.meudominio.org.br. IN IN IN IN IN IN ; Retry ; Expire ; Minimum NS A A A MX 10 A ns.meudominio.org.br mail.meudominio.org.br As quatro últimas linhas especificam nosso mapeamento, exatamente como definimos anteriormente. Sempre que quisermos adicionar novos nomes, só precisamos editar este arquivo. Se, por exemplo, quisermos adicionar endereços para as máquinas dos personagens imaginários André e Beto, localizadas nos IPs e , respectivamente, basta adicionarmos ao final do arquivo /etc/bind/db.meudominio o trecho abaixo. andre.meudominio.org.br. beto.meudominio.org.br. IN IN A A Observe ainda que é possível especificar que o mesmo IP responderá por mais de um nome. A máquina do nosso exemplo está respondendo pelos nomes ftp e www simultaneamente. O contrário, especificar vários endereços para o mesmo nome, também é possível. Agora que terminamos de editar nossos arquivos é hora de fazer uma revisão rápida neles e reiniciar o serviço de nomes, para que ele carregue os novos dados. # /etc/init.d/bind9 restart Stopping domain name service: named. Starting domain name service: named. Para testar nossa configuração, vamos usar novamente o dig. Do mesmo modo que consultamos anteriormente o endereço para uma máquina na rede externa ( agora vamos consultar o endereço para um nome de máquina na rede interna. $ dig ; <<>> DiG <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEAR<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: 52

53 ;ftp.meudominio.org.br. IN A ;; ANSWER SECTION: ftp.meudominio.org.br IN A ;; AUTHORITY SECTION: meudominio.org.br IN ;; ADDITIONAL SECTION: ns.meudominio.org.br IN ;; ;; ;; ;; NS ns.meudominio.org.br. A Query time: 6 msec SERVER: #53( ) WHEN: Tue Dec 27 10:08: MSG SIZE rcvd: Configurando o DNS reverso. O DNS reverso é um meio de que outras maquinas podem ter certeza de que você é você, por exemplo, é normal servidores de , checarem se o seu dns é mesmo valido, um exemplo pra voce ver como isso funciona seria usando o comando host. # host terra.com.br ele retornará a seguinte saída: terra.com.br has address terra.com.br mail is handled by 10 mx.terra.com.br. Fazendo o contrário: # host obtemos o seguinte resultado: in-addr.arpa domain name pointer Então esse é o dns reverso. Para configurar isso, inicialmente vamos configurar o arquivo /etc/bind/named.conf.local (em nosso exemplos, usamos apenas ips internos, então vou continuar com este padrão). # vi /etc/bind/named.conf.local zone " in-addr.arpa" { type master; 53

54 file "/etc/bind/db.11"; } Note que se usamos o ip no nosso servidor, entao a zone será in-addr.arpa, isso corresponde ao ip ao contrario sem o ultimo numero Fizemos referencia ao arquivo db.11, portanto é preciso cria-lo e dentro dele entraremos com o as informações a seguir: # vi /etc/bind/db.11 ; ; BIND reverse data file for meudominio.org.br ; IN SOA meudominio.org.br. ns.meudominio.org.br. ( 1 ; Serial ; Refresh ; Retry ; Expire ) ; Negative Cache TTL ; 11 IN IN NS PTR meudominio.org.br. ns.meudominio.org.br. Olhando com atenção nas duas ultimas linhas, podemos ver o seguinte: IN NS meudominio.org.br. É o dominio principal 11 IN PTR ns.meudominio.org.br. O ip e o host.dominio da maquina Agora com tudo configurado, podemos reiniciar o bind. # /etc/init.d/bind9 restart Stopping domain name service: named. Starting domain name service: named. Agora para testar, vamos usar o comando host, substituindo /etc/resolv.conf para nosso servidor DNS. # vi /etc/resolv.conf 54

55 search meudominio.org.br nameserver # host ns.meudominio.org.br ns.meudominio.org.br has address Está finalizado a confguração de um servidor DNS utilizando o Bind9. 55

56 7. SERVIDOR POSTFIX O Postfix é um sistema composto por várias estruturas e processos que tratam as mensagens. Sua arquitetura resulta em um MTA rápido, robusto e seguro. O Postfix é composto por filas, tabelas de pesquisa e programas. Alguns programas tratam as mensagens enquanto outros gerenciam a atividade do sistema, agindo de forma mais independente possível. O é parte integrante da sociedade moderna. A amplitude de sua utilização ao recdor do mundo o caracteriza como uma das mais importantes aplicações da rede mundial. Sua origem é anterior ao surgimento da Internet e sua tecnologia vem evoluindo constantemente para poder servir as novas necessidades e fazer frente aos desafios e riscos envolvidos na transmissão de mensagens pela Internet. 7.1 Protocolos. Existe um conjunto de protocolos a termos específicos ao transito de . As aplicações envolvidas se dividem em: MTA Mail Transfer Agent MDA Mail Delivery Agent MUA Mail User Agent MTA é a aplicação responsável pelo transito de mensagens entre servidores usando o protocolo SMTP. Um dos MTAs mais seguros é o PostFIX, que pode ser configurado com facilidade por um administrador que não tenha grande experiência com servidores de . A responsabilidade da aplicação MDA é arquivar em um servidor os s transportados pelo MTA. O MTA não é responsável pelo tráfego de mensagens entre os servidores nem pela manipulação do pelo usuário. O MUA é utilizado para ler e redigir os s, sendo a ferramenta do usuário final. A comunicação entre os equipamentos ocorre com a utilização dos seguintes protocolos específicos: 56

57 SMTP Simple Mail Transfer Protocol O SMTP é utilizado para transferir s entre os servidores. Uma aplicação cliente de correio eletrônico deve especificar um servidor de SMTP para poder enviar o para outros servidores. Observe que entre os servidores de o protocolo SMTP e utilizado para receber e enviar. O protocolo SMTP não exige a autenticação do usuário que esta enviando o POP Post Office Protocol Uma aplicação cliente utiliza a POP para transferir o de um servidor para o espaço de armazenamento da aplicação. Normalmente uma aplicação cliente POP apaga os s do servidor. O POP exige autenticação. IMAP Uma das características do IMAP é que os s ficam Internet Message Access no servidor e não são transferidos para o espaço de Protocol armazenamento da aplicação cliente. Ele é útil quando o usuário acessa seus s por mais de uma maquina. 7.2 Instalação do Postfix A instalação do Postfix distribui em diversos diretórios os executáveis dos comandos e as filas de processamento de mensagens. Para darmos início a instalação dos postfix utilizaremos o seguinte comando: # apt-get install postfix 57

58 Vamos selecionar a opção Internet Site. Esta tela, apresenta uma carcterística do Postfix, no qual pode-se criar um alias para o envio de mensagens do sistema root a outros usuários. 58

59 Deixemos a opção padrão, caso contrário, bastaria colocar um usuário qualquer existente. Como exemplo, iremos colocar o domínio marcioleonardi.com.br 59

60 Deixaremos em branco uma vez que não haverá outros domínios virtuais como gateway de . Como estamos usando um sistema de arquivos com journalling selecionaremos a opção Não. Finalizada a instalação do Postfix, iremos iniciar a instalação do courier-imap e do 60

61 courier-pop para entrega local de s. Para instalarmos os pacotes devemos usar o seguinte comando: # apt-get install courier-imap courier-pop Selecionaremos a opção Sim, caso desejar configurar o Postfix através da web depois. 7.3 Configurando o Postfix O postfix contém um arquivo chamado main.cf, no qual estão as configurações gerais do daemon, localizado no diretório "/etc/postfix", pela instalação padrão. Vamos editar esse arquivo e colocar as configurações para que funcione em perfeito estado. # vi /etc/postfix/main.cf # See /usr/share/postfix/main.cf.dist for a commented, more complete version smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending.domain is the MUA's job. append_dot_mydomain = no 61